platform/x86: classmate-laptop: Convert accel driver to a platform one
In all cases in which a struct acpi_driver is used for binding a driver
to an ACPI device object, a corresponding platform device is created by
the ACPI core and that device is regarded as a proper representation of
underlying hardware. Accordingly, a struct platform_driver should be
used by driver code to bind to that device. There are multiple reasons
why drivers should not bind directly to ACPI device objects [1].
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert cmpc_accel_acpi_driver in the Classmate
laptop driver from an ACPI driver to a platform one.
After this change, the input device registered by the driver will
appear under the platform device used for driver binding, but the sysfs
attribute added by the driver under the ACPI companion of that device
will stay there in case there are utilities in user space expecting
it to be present there.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
platform/x86: classmate-laptop: Convert v4 accel driver to a platform one
In all cases in which a struct acpi_driver is used for binding a driver
to an ACPI device object, a corresponding platform device is created by
the ACPI core and that device is regarded as a proper representation of
underlying hardware. Accordingly, a struct platform_driver should be
used by driver code to bind to that device. There are multiple reasons
why drivers should not bind directly to ACPI device objects [1].
Overall, it is better to bind drivers to platform devices than to their
ACPI companions, so convert cmpc_accel_acpi_driver_v4 in the Classmate
laptop driver from an ACPI driver to a platform one.
After this change, the input device registered by the driver will
appear under the platform device used for driver binding, but the sysfs
attributes added by the driver under the ACPI companion of that device
will stay there in case there are utilities in user space expecting
them to be present there.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
To facilitate subsequent conversion of the driver to using struct
platform_driver instead of struct acpi_driver, make it install its ACPI
notify handlers directly instead of using struct acpi_driver .notify()
callbacks.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/1856277.VLH7GnMWUR@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: classmate-laptop: Rename two helper functions
Since cmpc_add_acpi_notify_device() and cmpc_remove_acpi_notify_device()
have been modified to take a plain struct device pointer as the first
argument, then have nothing to do with ACPI in principle, so rename
them to cmpc_add_notify_device() and cmpc_remove_notify_device(),
respectively, and consolidate white space around the call sites of
the former.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/3338539.5fSG56mABF@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: classmate-laptop: Pass struct device pointer to helpers
To facilitate subsequent conversion of the driver to using struct
platform_driver instead of struct acpi_driver, modify two helper
functions in it, cmpc_add_acpi_notify_device() and
cmpc_remove_acpi_notify_device(), to take a struct device pointer
argument instead of a struct acpi_device pointer argument and update
their callers accordingly.
While at it, change the return type of cmpc_remove_acpi_notify_device()
to void because its return value is never checked.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/9615385.CDJkKcVGEf@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: classmate-laptop: Unify probe rollback and remove code
To facilitate subsequent modifications, change code ordering in
cmpc_accel_add_v4(), cmpc_accel_add(), and cmpc_accel_remove_v4()
so that the ordering of the probe rollback code is the same as the
ordering of the corresponding removal code.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/2036641.PYKUYFuaPT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: classmate-laptop: Address memory leaks on driver removal
Switch over cmpc_accel_add_v4() and cmpc_accel_add() to using
devm_kzalloc() for allocating the accel object which will cause it
to be freed automatically on device removal, so it won't be leaked
any more.
This also simplifies the rollback paths in these functions somewhat.
Fixes: 529aa8cb0a59 ("classmate-laptop: add support for Classmate PC ACPI devices") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://patch.msgid.link/10846403.nUPlyArG6x@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: xo15-ebook: Use devres-based resource management
Use devm_kzalloc() and devm_input_allocate_device() in
ebook_switch_probe() for allocating the button object and the
input device, respectively, to simplify the rollback path in
that function and ebook_switch_remove().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/6015220.DvuYhMxLoT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: wireless-hotkey: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 wireless-hotkey driver.
Fixes: 8507277ef132 ("platform/x86: wireless-hotkey: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/3899916.MHq7AAxBmi@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: toshiba_haps: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 toshiba_haps driver.
Fixes: 3a96c7915d93 ("platform/x86: toshiba_haps: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2285136.Mh6RI2rZIc@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: toshiba_bluetooth: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 toshiba_bluetooth driver.
Fixes: 553b2ac59fbb ("platform/x86: toshiba_bluetooth: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2715450.Lt9SDvczpP@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: toshiba_acpi: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 toshiba_acpi driver.
Fixes: 246d6cefe525 ("platform/x86: toshiba_acpi: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/1973170.CQOukoFCf9@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: system76: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 system76 driver.
Fixes: 80b8f68b94ab ("platform/x86: system76: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2072699.usQuhbGJ8B@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: sony-laptop: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add requisite ACPI_COMPANION() checks against NULL to the
platform/x86 sony-laptop driver.
Fixes: 138db7ee58c0 ("platform/x86: sony-laptop: Convert PIC driver to a platform one") Fixes: 14004dd31caa ("platform/x86: sony-laptop: Convert NC driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/1871155.VLH7GnMWUR@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: panasonic-laptop: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 panasonic-laptop driver.
Fixes: de6837243af0 ("platform/x86: panasonic-laptop: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/3353471.5fSG56mABF@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: lg-laptop: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 lg-laptop driver.
Fixes: 2d9cb20610f7 ("platform/x86: lg-laptop: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/3706551.iIbC2pHGDl@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: intel/smartconnect: Check ACPI_HANDLE() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the
platform/x86 intel/smartconnect driver.
Fixes: 8a44bd3ffdb2 ("platform/x86: intel/smartconnect: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/7956676.EvYhyI6sBW@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: intel/rst: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 intel/rst driver.
Fixes: 163a68a31f74 ("platform/x86: intel/rst: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2051525.PYKUYFuaPT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: fujitsu-tablet: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add requisite ACPI_COMPANION() checks against NULL to the
platform/x86 fujitsu-tablet driver.
Fixes: bd13b265d386 ("platform/x86: fujitsu-tablet: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/10861611.nUPlyArG6x@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: fujitsu: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add requisite ACPI_COMPANION() checks against NULL to the
platform/x86 fujitsu-laptop driver.
Fixes: 6da22b031a3c ("platform/x86: fujitsu: Convert laptop driver to a platform one") Fixes: d5c9212ccfaa ("platform/x86: fujitsu: Convert backlight driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jonathan Woithe <jwoithe@just42.net> Link: https://patch.msgid.link/3430329.44csPzL39Z@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: eeepc-laptop: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 eeepc-laptop driver.
Fixes: 079b59fd2d79 ("platform/x86: eeepc-laptop: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/3056852.e9J7NaK4W3@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: dell/dell-rbtn: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 dell-rbtn driver.
Fixes: 19ebacfb442b ("platform/x86: dell/dell-rbtn: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2276487.irdbgypaU6@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: asus-laptop: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 asus-laptop driver.
Fixes: ba19eb10170b ("platform/x86: asus-laptop: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/5083741.GXAFRqVoOG@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Arnd Bergmann [Thu, 7 May 2026 21:24:50 +0000 (23:24 +0200)]
p54spi: convert to devicetree
The Prism54 SPI driver hardcodes GPIO numbers and expects users to
pass them as module parameters, apparently a relic from its life as a
staging driver. This works because there is only one user, the Nokia
N8x0 tablet.
Convert this to the gpio descriptor interface and DT based probing
to improve this and simplify the code at the same time.
Arnd Bergmann [Thu, 7 May 2026 21:24:49 +0000 (23:24 +0200)]
dt-bindings: net: add st,stlc4560/p54spi binding
The SPI version of Prism54 was sold under a couple of different
names and supported by the Linux p54spi driver, but there was
never a DT binding for it.
Document the four known names of this device and the properties
that are sufficient for its use on the Nokia N8x0 tablet.
As I don't have this hardware or documentation for it, this is
purely based on existing usage in the driver.
platform/x86: acer-wireless: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 acer-wireless driver.
Fixes: f7e648027d7e ("platform/x86: acer-wireless: Convert ACPI driver to a platform one") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/4746824.LvFx2qVVIh@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Daniel Gabay [Fri, 15 May 2026 11:28:06 +0000 (14:28 +0300)]
wifi: mac80211: allow cipher change on NAN_DATA interfaces
ieee80211_key_link() rejects pairwise key installation when the
cipher differs from the existing PTK. Per Wi-Fi Aware version 4.0
section 7.4, the ND-TKSA between the same NDI pair shall be updated
when a new NDP requires a stronger cipher suite.
Exempt NL80211_IFTYPE_NAN_DATA from the same-cipher enforcement so
the PTK can be replaced with a different cipher.
Ilan Peer [Fri, 15 May 2026 11:15:16 +0000 (14:15 +0300)]
wifi: mac80211_hwsim: Do not declare NAN support for Extended Key ID
Do not declare support for Extended Key ID for NAN, as defined in
section 7.4 in the WiFi Aware specification v4.0 (in order to support
security association upgrade).
Miri Korenblit [Wed, 13 May 2026 15:26:56 +0000 (18:26 +0300)]
wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed
In case reconfiguration of NAN fails, we call
ieee80211_handle_reconfig_failure, that marks all interfaces as not in
the driver.
Then, at the error path of the reconfig, cfg80211_shutdown_all_interfaces
is called to destroy all the interfaces.
If we have any other interface but the NAN one, for example a BSS
station, then when its state (links, stations) will be removed, we
won't tell the driver about this, because we will think that the
interfaces are not in the driver, and then drivers might remain with
dangling pointers to objects like stations and links (at least for
iwlwifi this is the case).
ieee80211_handle_reconfig_failure is meant to be called after we cleaned
up the state in the driver, there is no reason to call it for NAN
reconfiguration failure.
Fix the code to just warn in such a case, as we do in other error paths
in reconfig where it is too complicated to rewind.
Ilan Peer [Wed, 13 May 2026 14:24:22 +0000 (17:24 +0300)]
wifi: mac80211: Allow per station GTK for NAN Data interfaces
The WiFi Aware specification (v4.0) requires that NAN devices that
support security would also support per station GTK. Thus, allow
per station GTK installation to the driver on NAN Data interfaces.
Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
tested: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260513172418.37a8e259e611.I39bb9f3c1a65a8184124f531c18e121dc123d411@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wifi: mac80211_hwsim: reject NAN on multi-radio wiphys
When userspace creates a new hwsim radio with both
HWSIM_ATTR_MULTI_RADIO and HWSIM_ATTR_SUPPORT_NAN_DEVICE,
hwsim_new_radio_nl() sets BIT(NL80211_IFTYPE_NAN_DATA) in
wiphy->interface_modes while configuring the wiphy with
n_radio > 1. This violates the invariant checked in
wiphy_register():
triggering a WARN reachable from userspace via genetlink.
With panic_on_warn this becomes a denial of service.
Refuse the combination at parse time with -EINVAL and an
extack message, matching the cfg80211 constraint that NAN
is not supported on multi-radio wiphys.
Lachlan Hodges [Wed, 6 May 2026 13:19:25 +0000 (23:19 +1000)]
wifi: mac80211: don't recalc min def for S1G chan ctx
__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.
Lachlan Hodges [Wed, 6 May 2026 13:19:24 +0000 (23:19 +1000)]
wifi: mac80211: skip NSS and BW init for S1G sta
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().
Johannes Berg [Tue, 5 May 2026 13:17:31 +0000 (15:17 +0200)]
wifi: mac80211: check stations are removed before MLD change
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.
Gil Fine [Wed, 6 May 2026 12:37:09 +0000 (15:37 +0300)]
thunderbolt: Increase Notification Timeout to 255 ms for USB4 routers
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>
Gil Fine [Wed, 6 May 2026 12:37:08 +0000 (15:37 +0300)]
thunderbolt: Increase timeout for Configuration Ready bit
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>
Gil Fine [Wed, 6 May 2026 12:37:07 +0000 (15:37 +0300)]
thunderbolt: Verify Router Ready bit is set after router enumeration
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>
Gil Fine [Wed, 6 May 2026 12:37:06 +0000 (15:37 +0300)]
thunderbolt: Verify PCIe adapter in detect state before tunnel setup
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>
Gil Fine [Wed, 6 May 2026 12:37:05 +0000 (15:37 +0300)]
thunderbolt: Activate path hops from source to destination
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>
Gil Fine [Wed, 6 May 2026 12:37:04 +0000 (15:37 +0300)]
thunderbolt: Fix lane bonding log when bonding not possible
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>
Pooja Katiyar [Thu, 7 May 2026 21:46:30 +0000 (14:46 -0700)]
thunderbolt: Don't access path config space on Lane 1 adapters in tb_switch_reset_host()
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.
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>
Kartik Nair [Sun, 10 May 2026 20:24:37 +0000 (01:54 +0530)]
wifi: cfg80211: wext: validate chandef in monitor mode
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.
Contains:
wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled
wifi: iwlwifi: mld: stop TX during firmware restart
wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o BSS vif
wifi: iwlwifi: mvm: fix driver-set TX rates on old devices
wifi: iwlwifi: mld: disconnect only after 6 beacons without Rx
wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it
wifi: iwlwifi: use correct function to read STEP_URM register
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wifi: mac80211: consume only present negotiated TTLM maps
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: 8f500fbc6c65 ("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>
wifi: wilc1000: fix dma_buffer leak on bus acquire failure
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.
Zhao Li [Sat, 9 May 2026 04:34:28 +0000 (12:34 +0800)]
wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb
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.
Johannes Berg [Fri, 8 May 2026 07:10:32 +0000 (09:10 +0200)]
wifi: mac80211: fix multi-link element inheritance
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: cf36cdef10e2 ("wifi: mac80211: Add support for parsing Reconfiguration Multi Link element") Fixes: 24711d60f849 ("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>
Johannes Berg [Fri, 8 May 2026 07:10:31 +0000 (09:10 +0200)]
wifi: mac80211: fix MLE defragmentation
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.
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.
Alexandru Hossu [Fri, 15 May 2026 10:29:08 +0000 (12:29 +0200)]
wifi: mac80211: bounds-check link_id in ieee80211_ml_epcs
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 162d331d833d ("wifi: mac80211: bounds-check link_id in
ieee80211_ml_reconfiguration").
Sudeep Holla [Sun, 17 May 2026 19:02:43 +0000 (20:02 +0100)]
firmware: arm_scmi: Validate Powercap domains before state access
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.
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.
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.
Sudeep Holla [Sun, 17 May 2026 19:02:40 +0000 (20:02 +0100)]
firmware: arm_scmi: Read sensor config as 32-bit value
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.
drm/imagination: Fix missing argument in pvr_power_fw_{en,dis}able()
Commit 42577ba79fbf ("drm/imagination: Rename FW booted to FW initialised")
dropped by mistake the last argument of the functions pvr_power_fw_enable()
and pvr_power_fw_disable(), leading to the following compile error:
CC [M] drivers/gpu/drm/imagination/pvr_power.o
drivers/gpu/drm/imagination/pvr_power.c: In function ‘pvr_power_device_suspend’:
drivers/gpu/drm/imagination/pvr_power.c:382:23: error: too few arguments to function ‘pvr_power_fw_disable’; expected 3, have 2
382 | err = pvr_power_fw_disable(pvr_dev, false);
| ^~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/imagination/pvr_power.c:93:1: note: declared here
93 | pvr_power_fw_disable(struct pvr_device *pvr_dev, bool hard_reset, bool rpm_suspend)
| ^~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/imagination/pvr_power.c: In function ‘pvr_power_device_resume’:
drivers/gpu/drm/imagination/pvr_power.c:412:23: error: too few arguments to function ‘pvr_power_fw_enable’; expected 2, have 1
412 | err = pvr_power_fw_enable(pvr_dev);
| ^~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/imagination/pvr_power.c:122:1: note: declared here
122 | pvr_power_fw_enable(struct pvr_device *pvr_dev, bool rpm_resume)
| ^~~~~~~~~~~~~~~~~~~
make[6]: *** [scripts/Makefile.build:289: drivers/gpu/drm/imagination/pvr_power.o] Error 1
make[5]: *** [scripts/Makefile.build:548: drivers/gpu/drm/imagination] Error 2
make[4]: *** [scripts/Makefile.build:548: drivers/gpu/drm] Error 2
make[3]: *** [scripts/Makefile.build:548: drivers/gpu] Error 2
make[2]: *** [scripts/Makefile.build:548: drivers] Error 2
make[1]: *** [/home/javier/devel/linux/Makefile:2141: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
Andre Przywara [Tue, 2 Sep 2025 17:20:53 +0000 (18:20 +0100)]
firmware: smccc: Fix Arm SMCCC SOC_ID name call
Commit 5f9c23abc477 ("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.
Aurelien Jarno [Tue, 19 May 2026 04:12:38 +0000 (06:12 +0200)]
riscv: dts: spacemit: enable SD card support on Milk-V Jupiter
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
Aurelien Jarno [Tue, 19 May 2026 04:12:37 +0000 (06:12 +0200)]
riscv: dts: spacemit: enable eMMC on Milk-V Jupiter
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
Aurelien Jarno [Tue, 19 May 2026 04:12:35 +0000 (06:12 +0200)]
riscv: dts: spacemit: set console baud rate on Milk-V Jupiter
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: 24c12ca43b12c ("dts: spacemit: set console baud rate on bpif3") Fixes: 5b90a3d6092d9 ("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>
staging: media: atomisp: improve cleanup robustness in ia_css_stream_destroy_isp2401()
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>
staging: media: atomisp: extract ISP2401 cleanup into helper function
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>
staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()
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: 113401c67386 ("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>
Michael Ugrin [Sat, 11 Apr 2026 17:34:05 +0000 (10:34 -0700)]
staging: media: atomisp: use umin() for strscpy size arguments
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>
media: atomisp: avoid ACPI package count underflow in gmin_cfg_get_dsm
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>
media: atomisp: remove redundant call to ia_css_output0_configure()
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>
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: a49d25364dfb ("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>
Karthikey Kadati [Thu, 15 Jan 2026 03:12:07 +0000 (08:42 +0530)]
media: atomisp: replace ia_css_region with v4l2_rect
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>
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>
Systems with the atomisp ISP do not have a lot of memory for modern
standards, so these are often under memory pressure and alloc_pages_bulk()
does not try very hard to free pages before returning an amount of pages
which is less then requested. This leads to streaming from the camera
often failing with a "alloc_pages_bulk() failed" error.
vmalloc() also uses alloc_pages_bulk(), but falls back to allocating one
page at a time when that fails.
Do the same in alloc_private_pages() to avoid these errors.
While at it also drop the weird custom GFP flags and just use GFP_KERNEL
and drop the dev_err() as alloc_pages() already complaints loudly if
it fails itself.
Closes: https://github.com/jfwells/linux-asus-t100ta/issues/4 Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Zilin Guan [Tue, 3 Feb 2026 16:31:34 +0000 (16:31 +0000)]
media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()
atomisp_v4l2_framebuffer_to_css_frame() allocates memory for
temporary variable raw_black_frame, which must be released via
ia_css_frame_free() before the function returns. However, if
sh_css_set_black_frame() fails, the function returns immediately without
performing this cleanup, leading to a memory leak.
Fix this by assigning the return value of sh_css_set_black_frame() to
ret. This ensures that the error code is propagated while allowing the
execution to fall through to the ia_css_frame_free() cleanup call.
The bug was originally detected on v6.13-rc1 using an experimental
static analysis tool we are developing, and we have verified that the
issue persists in the latest mainline kernel. The tool is based on the
LLVM framework and is specifically designed to detect memory management
issues. It is currently under active development and not yet publicly
available.
We performed build testing on x86_64 with allyesconfig. Since triggering
this error path in atomisp requires specific Intel Atom ISP hardware and
firmware, we were unable to perform runtime testing and instead verified
the fix according to the code logic.
Fixes: 85b606e02ad7 ("media: atomisp: get rid of a bunch of other wrappers") Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tomasz Unger [Thu, 5 Mar 2026 13:45:27 +0000 (14:45 +0100)]
media: staging: atomisp: Remove unnecessary return statement in void function
Remove redundant 'return;' at the end of void function
ia_css_dvs_statistics_get(). Void functions do not need an explicit
return statement at the end. No other occurrences in this file.
Found with checkpatch.pl --strict.
Signed-off-by: Tomasz Unger <tomasz.unger@yahoo.pl> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Hamdan Khan [Mon, 9 Feb 2026 16:20:26 +0000 (21:20 +0500)]
staging: media: atomisp: Fix typos and formatting in headers
Update block and inline comments to follow kernel
commenting conventions, fix typos and wording, remove
redundant comments and reformat long comments for clarity
and line length consistency.
Although some comments used the /** ... */ style, they are not
kernel-doc comments and are converted to normal comment style.
No functional changes are intended.
Signed-off-by: Hamdan Khan <hamdankhan212@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tomasz Unger [Thu, 26 Feb 2026 11:16:53 +0000 (12:16 +0100)]
staging: media: atomisp: replace sprintf() with strscpy()
Auditing calls to sprintf(). This code is fine because we are
copying 9 characters into a 52 character buffer. But it would
be cleaner to use strscpy() instead. Additionally, the 2-argument
version of strscpy() checks at compile time that dst is an array,
not just a pointer.
This is the only sprintf() call in the whole driver.
Signed-off-by: Tomasz Unger <tomasz.unger@yahoo.pl> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Removing the try_vesa_interface gate caused a backlight regression on
panels whose VBT correctly reports INTEL_BACKLIGHT_DISPLAY_DDI and whose
PWM path is the actual backlight control, but whose DPCD optimistically
advertises DP_EDP_BACKLIGHT_AUX_ENABLE_CAP / _BRIGHTNESS_AUX_SET_CAP.
After the commit such panels silently bind to the VESA AUX backlight
funcs; AUX writes complete but the panel ignores them, leaving
brightness stuck (no-op backlight). Observed on at least KBL and TGL
eDP setups.
Chukun Pan [Mon, 18 May 2026 10:00:30 +0000 (18:00 +0800)]
riscv: dts: spacemit: enable USB3 on OrangePi R2S
Enable the DWC3 USB3.0 controller and its associated PHY on the
OrangePi R2S. The USB regulator provides VBUS for USB2 and USB3
ports, but the USB2 ports are handled by a separate controller.
Xueqin Luo [Fri, 15 May 2026 02:42:42 +0000 (10:42 +0800)]
cpufreq: cppc: mask Desired_Excursion when autonomous selection is enabled
According to the ACPI 6.6 specification, the Desired_Excursion field is not
utilized when autonomous selection is enabled. In this mode, the bit is
architecturally ignored and does not carry meaningful information.
Currently, the kernel exposes the raw Performance Limited register
value to userspace through the cpufreq sysfs interface. This may lead to
misinterpretation, as userspace may assume Desired_Excursion is valid
even when autonomous selection is active.
To provide a stable and semantically correct ABI, mask out the
Desired_Excursion bit when autonomous selection is enabled, so that
userspace does not observe undefined or misleading values.
Writes are left unchanged, as the field is architecturally ignored in
this mode and write attempts are harmless.
Signed-off-by: Xueqin Luo <luoxueqin@kylinos.cn> Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
projects / thirdparty / linux.git / log
