init and exit do nothing interesting that module_usb_driver doesn't
already handle. Just use module_usb_driver to simplify the code.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260507015457.239807-1-rosenp@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
__ieee80211_recalc_chanctx_min_def() currently does not attempt
to find the min def for S1G widths, meaning the BW will never change.
However, the following call into ieee80211_chan_bw_change() will
lead to a WARN within ieee80211_chan_width_to_rx_bw(). Not only that,
this entire path is geared towards 20MHz based channels, so it doesn't
make sense anyway. For now, return early when calculating the mindef
for S1G channels.
Fixes: d879d4da45 ("wifi: mac80211: clean up initial STA NSS/bandwidth handling")
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260506131925.2088353-3-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently there is no S1G STA bandwidth support throughout mac80211
as existing support is all based on 20MHz widths. With the recent
STA NSS/BW handling rework, S1G associations now hit the new WARN within
ieee80211_chan_width_to_rx_bw() as the chandef is not a 20MHz based
width. For now, skip initialisating link_sta->pub->bandwidth for
S1G chandefs to avoid the WARN though this should at some point be
properly implemented since there are vendors that offer differing
maximum bandwidths.
Additionally, currently all S1G hardware out there is 1SS so rather
then introducing new parsing code which wouldn't be used anyway, just
initialise the NSS related fields to 1 and skip initialising the STA
bandwidth for S1G chandefs within ieee80211_sta_init_nss_bw_capa().
Fixes: d879d4da45 ("wifi: mac80211: clean up initial STA NSS/bandwidth handling")
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20260506131925.2088353-2-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If an interface changes to/from MLD, then all stations related
to it must have been removed first. This is just natural since
we go from having links to not (or vice versa), but not doing
so also causes crashes in debugfs since vif changing to/from
MLD removes the entire debugfs for the vif, including stations.
Delete all stations but warn in this case, other code should
be handling it, in effect fail fast rather than doing a double
free or use-after-free in debugfs.
Link: https://patch.msgid.link/20260505151731.3d7cbb8b952c.I4ce7b536e8af26d7b115e82fd733734446cc56a4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of being creative with devm, allocate with rt2x00dev by using a
flexible array member. Simplifies code slightly.
It's worth noting that in 25369b2222 , the
proper device was set to the devm call as it seems there was confusion
there.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260430232206.141461-1-rosenp@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently we set the Notification Timeout field in ROUTER_CS_4 for USB4
routers to 10 ms, which is unnecessarily short and may cause unnecessary
retransmissions of Hot Plug packets by the router in case of slow
software response.
Increase the timeout to 255 ms, aligning with Thunderbolt 3 routers
and providing adequate time for software to process Hot Plug Events.
While there, fix the comment describing the Notification Timeout
field to match the USB4 specification.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
After setting the Configuration Valid bit (ROUTER_CS_5.CV), the USB4
Connection Manager guide specifies a 500 ms timeout for the router to
set the Configuration Ready bit (ROUTER_CS_6.CR). The current timeout
is shorter than specified. While there, fix the kernel-doc typo.
Increase the timeout to match the CM guide recommendation.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 Connection Manager guide specifies that after enumerating a
router, the Connection Manager shall verify that the Router Ready bit
(ROUTER_CS_6.RR) has been set to ensure hardware configuration has completed.
Currently, this step is missing from the enumeration sequence.
Add this check to follow the Connection Manager guide more closely.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
The USB4 Connection Manager guide suggests that a PCIe downstream and
PCIe upstream adapters of the USB4 router is in the Detect state before
setting up a PCIe tunnel.
Add this check by verifying the LTSSM field in ADP_PCIE_CS_0 before
tunnel setup.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently, path activation starts from the last hop (destination adapter)
and iterates backwards to the first hop (source adapter). This does not
follow the order suggested in the USB4 Connection Manager guide and could
potentially cause issues with tunnelled protocols.
Reverse the activation order to start from the first hop (source adapter)
and end at the last hop (destination adapter), as suggested in the
Connection Manager guide.
Adjust the rollback in the failure path to deactivate from the first
hop, since hops are now activated starting at the source.
Fix kernel-doc accordingly.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Currently if lane bonding is not possible or not supported, we continue
and read the updated number of Total Buffers from lane adapters unnecessarily
and incorrectly log the bonding as successful.
Fix this by bailing out early when bonding is not possible, avoiding
the unnecessary read and the misleading log message.
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
USB4 Lane 1 adapters do not have accessible path config space. Skip the
path config space cleanup in tb_switch_reset_host() for these ports. The
check is for USB4 switches only. Thunderbolt 1-3 Lane 1 adapters stay as
is because we do need to program their path config space.
Co-developed-by: Rene Sapiens <rene.sapiens@linux.intel.com>
Signed-off-by: Rene Sapiens <rene.sapiens@linux.intel.com>
Signed-off-by: Pooja Katiyar <pooja.katiyar@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
When 3 monitors are connected through Thunderbolt dock to the system at
once, one of the monitors might fail to establish DisplayPort tunnel.
This happens during DP bandwidth negotiation - each monitor takes
maximum bandwidth that is supported and there might not be enough for
3rd display. In this case Thunderbolt driver drops DP tunnel and
'forgets' about it but with DP bandwidth allocation mode, that comes in
later, some bandwidth might be freed.
Make Thunderbolt driver check again if DP tunnel can be established
after DP bandwidth consumption changed.
Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
cfg80211_wext_siwfreq() constructs a channel definition for monitor
mode but passes it to cfg80211_set_monitor_channel() without first
validating it with cfg80211_chandef_valid(). This causes a WARN_ON
in cfg80211_chandef_dfs_required() when it receives an invalid chandef.
Add the missing cfg80211_chandef_valid() check before calling
cfg80211_set_monitor_channel() to return -EINVAL early on invalid
channel definitions, consistent with how other callers handle this.
Reported-by: syzbot+02a1a03b8622d3c7d1c9@syzkaller.appspotmail.com
Signed-off-by: Kartik Nair <contact.kartikn@gmail.com>
Link: https://patch.msgid.link/20260510202437.7857-1-contact.kartikn@gmail.com
[clarify subject]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ath10k:
- avoid sending any commands to firmware when it is wedged
ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart
ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCagxz9AAKCRAsFbugiYzL
e3AAAQCeNy0XjAPSMZp0vqlMZkCIXSOy03/BNLTk0o5fT4NE3QD+IRa0coCLXlf1
eQRObBHnzKMA/y5oSEKdS4/5b+ExEgE=
=Xvqo
-----END PGP SIGNATURE-----
Merge tag 'ath-current-20260519' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git update for v7.1-rc5
ath10k:
- avoid sending any commands to firmware when it is wedged
ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart
ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_tid_to_link_map_size_ok() validates negotiated TTLM elements
against the number of link-map entries indicated by link_map_presence.
ieee80211_parse_neg_ttlm() must consume the same layout.
The parser advanced its cursor for every TID, including TIDs whose
presence bit is clear and therefore have no map bytes in the element.
A sparse map can then make a later present TID read past the validated
element.
The bad bytes land in neg_ttlm->{up,down}link[tid] but are gated by
valid_links before being applied to driver state, so a peer cannot
turn the read into a policy change. Under KUnit + KASAN with an
exact-sized element allocation the OOB read is reported as a
slab-out-of-bounds; whether the same trigger fires under the
production RX path depends on surrounding allocator state.
Advance the cursor only when the current TID has a map present.
Fixes: 8f500fbc6c ("wifi: mac80211: process and save negotiated TID to Link mapping request")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Link: https://patch.msgid.link/20260515151719.1317659-2-michael.bommarito@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wilc_wlan_firmware_download() allocates dma_buffer with kmalloc() at
the top of the function and uses a 'fail:' label to free it via
kfree(dma_buffer) on error.
All later error paths correctly use 'goto fail' to route through this
cleanup. However, the early failure path after the first acquire_bus()
call uses a bare 'return ret;', which leaks dma_buffer whenever the bus
acquire fails.
Replace the early return with goto fail so the existing cleanup path
runs.
Found via a custom Coccinelle semantic patch hunting for kmalloc'd
locals leaked on early-return error paths in driver firmware-download
code.
Fixes: 1241c5650f ("wifi: wilc1000: Fill in missing error handling")
Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260511042732.998311-1-shitalkumar.gandhi@cambiumnetworks.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_invoke_fast_rx() reads RX status through
IEEE80211_SKB_RXCB(skb), which aliases the same skb->cb storage
that ieee80211_rx_mesh_data() reuses as IEEE80211_TX_INFO. In the
unicast forward path, mesh_data does:
info = IEEE80211_SKB_CB(fwd_skb);
memset(info, 0, sizeof(*info));
on the same skb the caller still names via rx->skb, then either
queues the skb for TX (success) or kfree_skb()'s it (no-route)
before returning RX_QUEUED. The caller's RX_QUEUED arm then
calls sta_stats_encode_rate(status) on memory that is either
zeroed (success path) or freed (no-route path). The latter is
KASAN slab-use-after-free in ieee80211_prepare_and_rx_handle.
Fix by encoding the rate from status before invoking
ieee80211_rx_mesh_data(), so the RX_QUEUED arm consumes a value
captured while status was still backed by valid memory.
Fixes: 3468e1e0c6 ("wifi: mac80211: add mesh fast-rx support")
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
Link: https://patch.msgid.link/20260509043427.60322-2-enderaoelyther@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When parsing a beacon, mac80211 erroneously inherits any
reconfiguration or EPCS multi-link elements from the outer
elements into the multi-BSSID profile that's requested, if
connected to a non-transmitted BSS, unless that profile
has a non-inheritance element.
This also happens if parsing a multi-BSSID profile that
doesn't have a non-inheritance element.
Fix this by having an empty non-inheritance element so
cfg80211_is_element_inherited() is invoked in these cases
and causes the parser to skip the elements that should
never be inherited.
Fixes: cf36cdef10 ("wifi: mac80211: Add support for parsing Reconfiguration Multi Link element")
Fixes: 24711d60f8 ("wifi: mac80211: Support parsing EPCS ML element")
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260508091032.92184c0a3f08.I3c43b0b63d2cef8a4ddddaef1c2faaeb1de711ad@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If either reconf or EPCS multi-link element (MLE) is contained in
a non-transmitted profile, the defragmentation routine is called
with a pointer to the defragmented copy, but the original elements.
This is incorrect for two reasons:
- if the original defragmentation was needed, it will not find the
correct data
- if the original frame is at a higher address, the parsing will
potentially overrun the heap data (though given the layout of
the buffers, only into the new defragmentation buffer, and then
it has to stop and fail once that's filled with copied data.
Fix it by tracking the container along with the pointer and in
doing so also unify the two almost identical defragmentation
routines.
Fixes: 4d70e9c548 ("wifi: mac80211: defragment reconfiguration MLE when parsing")
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260508091031.8a6c34613178.I4de16ebbce2d27f2f8f98fc49949c7a376c2fe8d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In client mode, the extended capabilities are handled by the kernel
looking at the association frame. When the supplicant installs the keys
it calls sta_apply_parameters and it doesn't include the extended
capabilities since those can't change after association.
As a result, we overrode the max_amsdu_subframes that we set after
association.
Check that the ext_capa coming from the user space is valid before
looking at it. If the ext_capa is NULL, it really means that the
extended capabilities are not changed (as opposed to cleared).
The default value for max_amsdu_subframes is 0, which means there is no
limit. This value is valid and in case the association response frame
does not have extended capabilities, this is the value we should use.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221079
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260513170623.828dbb58c782.Ifd2bfc190c26140e919127adb02ffddd7b551499@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
IEEE80211_MLE_STA_EPCS_CONTROL_LINK_ID is 0x000f, so link_id extracted
from a PRIO_ACCESS ML element PER_STA_PROFILE subelement can be 0..15.
sdata->link[] has IEEE80211_MLD_MAX_NUM_LINKS (15) entries (indices 0..14),
making index 15 out-of-bounds.
A connected WiFi 7 AP can trigger this by sending an EPCS Enable Response
action frame with a PER_STA_PROFILE subelement where link_id = 15. The
unsolicited-notification path (dialog_token = 0) is reachable any time
EPCS is already enabled, without any prior client request.
sdata->link[15] reads into the first word of sdata->activate_links_work
(a wiphy_work whose embedded list_head is non-NULL after INIT_LIST_HEAD),
so the NULL check on the result does not catch the invalid access. The
garbage pointer is then passed to ieee80211_sta_wmm_params(), which
dereferences link->sdata and crashes the kernel.
The same class of bug was fixed for ieee80211_ml_reconfiguration() by
commit 162d331d83 ("wifi: mac80211: bounds-check link_id in
ieee80211_ml_reconfiguration").
Fixes: de86c5f608 ("wifi: mac80211: Add support for EPCS configuration")
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
Link: https://patch.msgid.link/20260515102908.1653088-1-hossu.alexandru@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Powercap protocol v2 keeps local enable and last-cap state per domain.
The v2 enable helpers and disabled-domain cap_set path indexed that state
before checking that the supplied domain id was valid.
Validate the domain before touching the per-domain state.
Link: https://patch.msgid.link/20260517-scmi_fixes-v1-4-d86daec4defd@kernel.org
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
SENSOR_UPDATE carries one or more sensor readings after the fixed
notification header. The parser derives the expected reading count
from the sensor description, but it did not verify that the received
payload contains those entries before parsing them.
Reject truncated update notifications before reading the variable
array.
Link: https://patch.msgid.link/20260517-scmi_fixes-v1-3-d86daec4defd@kernel.org
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
BASE_ERROR_EVENT carries a variable number of message reports,
with the count encoded in error_status. The notification parser used
that count without checking whether the received payload contained all
reported entries.
Reject truncated payloads before copying the report array.
Link: https://patch.msgid.link/20260517-scmi_fixes-v1-2-d86daec4defd@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
The SENSOR_CONFIG_GET response contains a 32-bit sensor_config field,
and the xfer is initialized with a 4-byte RX buffer. Reading it with
get_unaligned_le64() can consume bytes past the returned payload.
Use get_unaligned_le32() to match the protocol layout and the allocated
response size.
Fixes: 7b83c5f410 ("firmware: arm_scmi: Add SCMI v3.0 sensor configuration support")
Link: https://patch.msgid.link/20260517-scmi_fixes-v1-1-d86daec4defd@kernel.org
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Commit 5f9c23abc4 ("firmware: smccc: Support optional Arm SMCCC SOC_ID
name") introduced the SOC_ID name string call, which reports a human
readable string describing the SoC, as returned by firmware.
The SMCCC spec v1.6 describes this feature as AArch64 only, since we rely
on 8 characters to be transmitted per register. Consequently the SMCCC
call must use the AArch64 calling convention, which requires bit 30 of
the FID to be set. The spec is a bit confusing here, since it mentions
that in the parameter description ("2: SoC name (optionally implemented for
SMC64 calls, ..."), but still prints the FID explicitly as 0x80000002.
But as this FID is using the SMC32 calling convention (correct for the
other two calls), it will not match what any SMCCC conformant firmware is
expecting, so any call would return NOT_SUPPORTED.
Add a 64-bit version of the ARCH_SOC_ID FID macro, and use that for the
SoC name version of the call to fix the issue.
Fixes: 5f9c23abc4 ("firmware: smccc: Support optional Arm SMCCC SOC_ID name")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250902172053.304911-1-andre.przywara@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Correct the uboot partition node name to match its actual offset.
Fixes: 2829823956 ("riscv: dts: spacemit: enable QSPI and add SPI NOR on Milk-V Jupiter")
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260519041458.3287843-6-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
Add complete SD card controller support with UHS high-speed modes.
- Enable sdhci0 controller with 4-bit bus width
- Configure card detect GPIO with pull-up
- Connect vmmc-supply to buck4 for 3.3V card power
- Connect vqmmc-supply to aldo1 for 1.8V/3.3V I/O switching
- Add dual pinctrl states for voltage-dependent pin configuration
- Support UHS-I SDR25, SDR50, and SDR104 modes
- Alias it as mmc1
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260519041458.3287843-5-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
The Milk-V Jupiter board has a connector for an eMMC module. Add an
entry for it in the device tree and alias it mmc0.
Mark the device as non-removable as eMMC modules have no CD pin and are
not supposed to be inserted or removed while the system is running. On
systems without an eMMC module installed, the kernel emits the following
informational message during boot:
mmc0: SDHCI controller on d4281000.mmc [d4281000.mmc] using ADMA
mmc0: Failed to initialize a non-removable card
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260519041458.3287843-4-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
Because the default console's baud rate is not set, defconfig kernels do
not have any serial output on this platform. Set the baud rate to
115200, matching what is used by U-Boot etc on this platform.
See-also: 24c12ca43b ("dts: spacemit: set console baud rate on bpif3")
Fixes: 5b90a3d609 ("riscv: dts: spacemit: Add Milk-V Jupiter board device tree")
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Yixun Lan <dlan@kernel.org>
Link: https://patch.msgid.link/20260519041458.3287843-2-aurelien@aurel32.net
Signed-off-by: Yixun Lan <dlan@kernel.org>
Remove the 'assert(entry)' call. In the atomisp driver, assert() is a
wrapper around BUG(), which intentionally crashes the entire kernel.
This is dangerous and inappropriate for a simple null pointer check
during stream teardown. Replace it with a safe 'if (!entry) continue;'
check.
Change the early 'return' to a 'continue'. In a destruction
path, it is better to proceed with cleaning up as many resources as
possible rather than aborting early, which would result in memory leaks
for the remaining pipes.
Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
To reduce indentation and improve the readability of
ia_css_stream_destroy(), extract the ISP2401-specific cleanup block into
a new static helper function, ia_css_stream_destroy_isp2401().
Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The nested loop inside the IS_ISP2401 block incorrectly uses the same
variable 'i' as the outer loop. This shadows the outer loop variable
and causes premature termination or skipped array elements.
Change the inner loop to use a new variable 'j' to prevent this.
Fixes: 113401c673 ("media: atomisp: sh_css: Removed #ifdef ISP2401 to make code generic")
Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Replace open-coded ternary min expressions with umin() in
strscpy() calls, as suggested by Dan Carpenter.
Signed-off-by: Michael Ugrin <mugrinphoto@gmail.com>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
gmin_cfg_get_dsm() iterates over ACPI _DSM package elements as
key/value pairs using obj->package.count - 1 as the loop bound.
If package.count is 0, the subtraction underflows and may lead
to out-of-bounds access.
Use i + 1 < obj->package.count instead.
Signed-off-by: Mohamad El Harake <mohamedharake2006@gmail.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The function configure_isp_from_args() contained a duplicate call to
ia_css_output0_configure() using the same output frame index. Remove the
redundant call to simplify the configuration path.
The ia_css_output0_configure() function acts as a configuration setter.
It populates a struct ia_css_output0_configuration from the frame info
and caches it in the binary parameters. Calling it twice with the same
out_frame[0] pointer merely overwrites the exact same state with
identical values. It has no cumulative state, neither does its order
matter relative to ia_css_copy_output_configure().
ia_css_configure_output0() writes into binary->mem_params.params[], a
software-side DMEM parameter buffer in kernel memory. The ISP firmware
receives these parameters later as a batch, not at the time of the call.
Calling a pure memory write twice with the same pointer and same value
simply overwrites the same location with identical data, there is no
hardware interaction that could require repetition.
Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The FIXME comment noted that delay_frames can be NULL for certain
pipeline configurations, without knowing why. The reason is that when a
binary does not enable ref_frame, delay frame allocation is
intentionally skipped to save memory, leaving the pointers NULL by
design.
The ISP feature flags in binary->info->sp.enable accurately reflect
which features are active for a given binary. Using enable.ref_frame and
enable.tnr as the predicate for their respective configuration steps
ensures the configuration path stays in sync with what was actually
built into the pipeline
Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Merge declaration of const GP_TIMER_BASE split across 2 lines to improve
readability.
Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Replace usage of uint32_t with u32 to comply with kernel coding
style guidelines.
Reported by checkpatch.pl.
CHECK: Prefer kernel type 'u32' over 'uint32_t'
Signed-off-by: Abinash Singh <abinashsinghlalotra@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
gc2235_probe() handles its error paths incorrectly.
If media_entity_pads_init() fails, gc2235_remove() is called, which
tears down the subdev and frees dev, but then still falls through to
atomisp_register_i2c_module(). This results in use-after-free.
If atomisp_register_i2c_module() fails, the media entity and control
handler are left initialized and dev is leaked.
gc2235_remove() unconditionally calls media_entity_cleanup() and
v4l2_ctrl_handler_free(), but these are not initialized at every
error path in gc2235_probe().
Replace gc2235_remove() calls in the probe error paths with explicit
unwind labels that free only the resources initialized at each point
of failure, in reverse order of initialization.
Fixes: a49d25364d ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The struct ia_css_region definition is redundant as struct v4l2_rect
provides the same functionality (left, top, width, height) and is the
standard V4L2 type.
Replace usage of ia_css_region with v4l2_rect in ia_css_dz_config
and remove the definition of ia_css_region from ia_css_types.h.
Also remove historical comments referencing the addition of zoom_region
and include <linux/videodev2.h> to support the v4l2_rect type.
Signed-off-by: Karthikey Kadati <karthikey3608@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Fix checkpatch.pl warnings in sh_css_param_shading.c regarding block
comment formatting.
The warning was:
- Block comments use a trailing */ on a separate line
This change also moves text from the first line of block comments to
subsequent lines to adhere to the standard Linux kernel coding style.
Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Existing comments in mmu_public.h used Doxygen syntax and had
inconsistent formatting.
Convert the function documentation to the standard kernel-doc format to
adhere to the Linux kernel coding style.
Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The function mmu_get_page_table_base_index() accepts only one argument
mmu_ID_t, the block comment for it shows an erroneous additional
argument base_index[in]. Similarly, mmu_reg_load() only accepts two
arguments, however the block comment explaining it shows an erroneous
argument 'value[in]'.
Remove incorrect documentation lines.
Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Fix checkpatch.pl warnings regarding block comments.
Add missing asterisks to block comments to adhere to the kernel coding
style.
Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Fix checkpatch.pl warnings regarding lines ending with "(" and improper
spacing for indentation.
This change fixes the function signatures for both function prototypes
and static inline function definations in mmu_public.h.
The kernel coding style prefers arguments to start immediately after
the open parenthesis.
Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
