Guoniu Zhou [Tue, 19 May 2026 02:07:41 +0000 (10:07 +0800)]
media: synopsys: Add PHY stopstate wait for i.MX93
Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
ensures proper PHY initialization by verifying that the clock lane and
all active data lanes have entered the stop state before proceeding with
further operations.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Guoniu Zhou [Tue, 19 May 2026 02:07:40 +0000 (10:07 +0800)]
media: synopsys: Add support for multiple streams
The current driver only supports single stream operation. Add support
for multiple concurrent streams by tracking enabled streams with a
bitmask and only initializing the hardware once for the first stream.
This enables use cases such as surround view systems where multiple
camera streams need to be processed simultaneously through the same
CSI-2 receiver interface.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Guoniu Zhou [Tue, 19 May 2026 02:07:39 +0000 (10:07 +0800)]
media: synopsys: Add support for RAW16 Bayer formats
Add higher bit-depth raw image data support for the sensors, which supports
16-bit output.
Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Guoniu Zhou [Tue, 19 May 2026 02:07:38 +0000 (10:07 +0800)]
media: synopsys: Fix IPI using hardcoded datatype
The imx93_csi2rx_dphy_ipi_enable() function configures the IPI datatype
using csi2->formats->csi_dt, which is initialized during probe but never
updated in set_fmt(). This causes the IPI to always use the probe-time
default datatype, ignoring the actual media bus format negotiated at
runtime. When userspace requests a different format, the IPI hardware is
configured with the wrong datatype, resulting in incorrect image output.
Fix by updating csi2->formats in the set_fmt callback to reflect the
currently negotiated format, ensuring the IPI configuration matches the
runtime datatype.
Fixes: ec40b431f0ab ("media: synopsys: csi2rx: add i.MX93 support") Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Martin Hecht [Fri, 8 May 2026 09:59:03 +0000 (11:59 +0200)]
media: i2c: alvium: fix critical pointer access in alvium_ctrl_init
The current implementation of alvium_ctrl_init creates several controls in
function alvium_ctrl_init and uses the returned pointer without check. That
can cause write access over NULL-pointer for several controls. The reworked
code checks the pointers before adding flags.
Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable@vger.kernel.org Signed-off-by: Martin Hecht <mhecht73@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Jack Yu [Wed, 20 May 2026 05:32:43 +0000 (13:32 +0800)]
ASoC: rt722-sdca: Add a control to support CAE firmware update
Realtek CAE requires specific tuning parameters based on
the system vendor and SKU.
This patch adds a kcontrol to trigger the firmware loading process.
Zhang Cen [Wed, 20 May 2026 10:32:49 +0000 (18:32 +0800)]
ALSA: seq: Serialize UMP output teardown with event_input
seq_ump_process_event() borrows client->out_rfile.output without
synchronizing with the first-open and last-close transition in
seq_ump_client_open() and seq_ump_client_close().
The last output unuse can therefore drop opened[STR_OUT] to zero and
release the rawmidi file while an in-flight event_input callback is still
inside snd_rawmidi_kernel_write(). That leaves the rawmidi substream
runtime exposed to teardown before the write path has taken its own
buffer reference.
Add a per-client rwlock for the event_input-visible output file. Publish
a newly opened output file under the write side, and hold the read side
from the output lookup through snd_rawmidi_kernel_write(). The last
output close copies and clears the visible output file under the write
side, then drops the lock and releases the saved rawmidi file. Use
IRQ-safe rwlock guards because event_input can also be reached from
atomic sequencer delivery.
The buggy scenario involves two paths, with each column showing the
order within that path:
path A label: event_input path path B label: last unuse path
1. seq_ump_process_event() reads 1. seq_ump_client_close()
client->out_rfile.output. drops opened[STR_OUT] to zero.
2. snd_rawmidi_kernel_write1() 2. snd_rawmidi_kernel_release()
has not yet pinned runtime. closes the output file.
3. The writer continues using 3. close_substream() frees
the borrowed substream. substream->runtime.
This keeps the output substream and runtime alive for the full
event_input write while keeping rawmidi release outside the rwlock.
KASAN reproduced this as a slab-use-after-free in
snd_rawmidi_kernel_write1(), with allocation through
seq_ump_use()/snd_seq_port_connect() and free through
seq_ump_unuse()/snd_seq_port_disconnect().
staging: media: atomisp: replace msleep() with fsleep() in atomisp-gc2235.c
Replace msleep(5) with fsleep(5000) to avoid sleeping longer than
necessary. msleep() with values less than 20ms may sleep for up to
20ms due to timer granularity. fsleep() selects the appropriate sleep
function automatically.
Signed-off-by: Oskar Ray-Frayssinet <rayfraytech@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
staging: media: atomisp: fix map and vmap leaks in stat buffer allocation
There are memory leaks in
drivers/staging/media/atomisp/pci/atomisp_compat_css20.c.
In atomisp_css_allocate_stat_buffers(), s3a_map is allocated by
ia_css_isp_3a_statistics_map_allocate() and its backing memory is
mapped via hmm_vmap(). When dis_buf allocation fails, the error path
frees s3a_data but does not unmap or free s3a_map. Similarly, when
md_buf allocation fails, neither s3a_map nor dvs_map (and their hmm
vmaps) are freed.
Add the missing hmm_vunmap() and map free calls on both error paths,
matching the cleanup order used in atomisp_css_free_3a_buffer() and
atomisp_css_free_dis_buffer().
Signed-off-by: Huihui Huang <hhhuang@smu.edu.sg> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Timo Röhling [Tue, 15 Jul 2025 11:23:26 +0000 (13:23 +0200)]
media: atomisp: style fix for trailing statements
Fix checkpatch errors "ERROR: trailing statements should be on next line"
in drivers/staging/media/atomisp/pci/sh_css_params.c.
Signed-off-by: Timo Röhling <roehling@debian.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
LiangCheng Wang [Sat, 26 Jul 2025 07:53:14 +0000 (15:53 +0800)]
staging: media: atomisp: fix indentation in bh host files
Fix inconsistent tab/space usage and bring function definitions
into a single-line format, matching kernel coding style.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
LiangCheng Wang [Sat, 26 Jul 2025 07:53:13 +0000 (15:53 +0800)]
staging: media: atomisp: use designated initializer in anr config
Improve readability by using designated initializer for
default_anr_config.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
LiangCheng Wang [Sat, 26 Jul 2025 07:53:12 +0000 (15:53 +0800)]
staging: media: atomisp: fix indentation in anr files
Fix inconsistent tab/space usage and bring function definitions
into a single-line format, matching kernel coding style.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
LiangCheng Wang [Sat, 26 Jul 2025 07:53:11 +0000 (15:53 +0800)]
staging: media: atomisp: improve kernel-doc for ia_css_aa_config
Move kernel-doc comment for strength field in
ia_css_aa_config from inline to structure-level comment
for better readability and tooling compatibility.
Signed-off-by: LiangCheng Wang <zaq14760@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Feng Ning [Sun, 12 Apr 2026 00:05:08 +0000 (00:05 +0000)]
staging: media: atomisp: use array3_size() for overflow-safe allocation
Replace open-coded width * height * sizeof() multiplications with
array3_size() to prevent integer overflow in buffer allocations.
The atomisp driver computes DVS, morphing table, shading table and
statistics buffer sizes using unchecked arithmetic. When dimensions
are attacker-controlled or simply large, the product can silently wrap,
causing kvmalloc() to allocate an undersized buffer.
array3_size() saturates to SIZE_MAX on overflow, so kvmalloc() returns
NULL instead of succeeding with too few bytes.
Signed-off-by: Feng Ning <feng@innora.ai> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Arnd Bergmann [Wed, 20 May 2026 10:19:01 +0000 (12:19 +0200)]
Merge tag 'renesas-drivers-for-v7.2-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers
Renesas driver updates for v7.2
- Add Multifunctional Interface (MFIS) mailbox and product register
support for R-Car X5H,
- Miscellaneous fixes and improvements.
* tag 'renesas-drivers-for-v7.2-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
soc: renesas: Convert to of_machine_get_match()
soc: renesas: Add R-Car X5H PRR support
soc: renesas: Add Renesas R-Car MFIS driver
dt-bindings: soc: renesas: Document MFIS IP core
soc: renesas: r9a09g057-sys: Move common code to a helper
soc: renesas: r9a09g056-sys: Move common code to a helper
soc: renesas: r9a09g047-sys: Move common code to a helper
soc: renesas: r9a08g046-sysc: Move common code to a helper
soc: renesas: r9a08g045-sysc: Move common code to a helper
arm64: defconfig: Enable PCI M.2 power sequencing driver
POWER_SEQUENCING_PCIE_M2 driver handles power supply to the PCIe M.2
connectors and is required on wide variety of ARM64 platforms such as
Qcom Snapdragon X Elite laptops and Mediatek Dojo Chromebooks.
The load_primary_binaries() function is overly complex and has som large
variables on the stack, which can cause warnings depending on CONFIG_FRAME_WARN
setting:
drivers/staging/media/atomisp/pci/sh_css.c: In function 'load_primary_binaries':
drivers/staging/media/atomisp/pci/sh_css.c:5260:1: error: the frame size of 1560 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
Half of the stack usage is for the prim_descr[] array, but only one
member of the array is used at any given time.
Reduce the stack usage by turning the array into a single structure.
Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Arnd Bergmann [Wed, 20 May 2026 10:12:33 +0000 (12:12 +0200)]
Merge tag 'renesas-dts-for-v7.2-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt
Renesas DTS updates for v7.2
- Add GPU support for R-Car M3-W(+)-based ULCB and Salvator-X(S)
development boards,
- Add Ethernet, OPP table, interrupt, pin control, and watchdog
support for the RZ/G3L SoC and the RZ/G3L SMARC SoM board,
- Add Coresight support for the R-Mobile A1 and APE6 SoCs, and the
Armadillo-800 EVA and APE6EVM development boards,
- Miscellaneous fixes and improvements.
arm64: Kconfig: drop unneeded dependency on OF_GPIO for ARCH_MVEBU
OF_GPIO is selected automatically on all OF systems. Any symbols it
controls also provide stubs so there's really no reason to select it
explicitly. ARCH_MVEBU already selects GPIOLIB, drop the redundant
OF_GPIO dependency.
platform/x86: classmate-laptop: Convert keys 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_keys_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.
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 ipml 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_ipml_acpi_driver in the Classmate
laptop driver from an ACPI driver to a platform one.
After this change, the backlight and rfkill devices registered by the
driver will appear under the platform device used for driver binding.
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 tablet 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_tablet_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.
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 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
projects / thirdparty / linux.git / log
