Split out two helpers functions to make the function more readable and
to avoid conditional locking.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://patch.msgid.link/20260323071156.2940772-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
Svyatoslav Ryhel [Thu, 12 Mar 2026 08:52:56 +0000 (10:52 +0200)]
dt-bindings: mfd: max77620: Convert to DT schema
Convert max77620 Device Tree bindings from TXT to YAML format. This patch
does not change any functionality; the bindings remain the same. The
thermal bindings are incorporated into the binding. GPIO controller
function in MAX77620 has no dedicated node and is folded into the parent
node itself.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Acked-by: Daniel Lezcano <daniel.lezcano@kernel.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260312085258.11431-4-clamor95@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
mfd: ezx-pcap: Avoid rescheduling after destroying workqueue
Driver allocates workqueue and then registers additional interrupt
handler with devm interface. This means that device removal will not
use a reversed order, but first destroy workqueue and then, via devm
release handlers, free the interrupt.
The interrupt handler registered with devm does not directly
use/schedule work items on the workqueue and the remove() function
correctly removes other IRQs handlers, however the code mixing devm and
non-devm interfaces is difficult to analyze and read.
Make the code flow much more obvious by using devm interface for
allocating the workqueue, so it will be freed with the rest of devm
resources.
Change is not equivalent in the workqueue itself: use non-legacy API
which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is
used to update device registers, thus there is no point to run it for
memory reclaim.
Phil Elwell [Fri, 6 Mar 2026 23:41:22 +0000 (00:41 +0100)]
mfd: bcm2835-pm: Add BCM2712 PM device support
The BCM2712 SoC includes a power management block that serves as the
power domain for the V3D graphics block. Unlike other PM blocks in
the BCM2835 family, it does not feature an ASB register space.
Conditionally register the PM device depending on the SoC variant.
Signed-off-by: Phil Elwell <phil@raspberrypi.com> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/c0b5793868f138bf5c928a12b2763d3e183e2e59.1772839224.git.andrea.porta@suse.com Signed-off-by: Lee Jones <lee@kernel.org>
Phil Elwell [Fri, 6 Mar 2026 23:41:21 +0000 (00:41 +0100)]
mfd: bcm2835-pm: Introduce SoC-specific type identifier
Power management blocks across the BCM2835 family share a common
base but require variant-specific handling. For instance, the
BCM2712 lacks ASB register space, yet it manages the power domain
for the V3D graphics block.
Add a hardware type identifier to the driver's private data. This
allows the driver to distinguish between SoC models and implement
custom quirks or features as needed.
Signed-off-by: Phil Elwell <phil@raspberrypi.com> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/c4bb218654e91f312a01b419d3d408e5131f7673.1772839224.git.andrea.porta@suse.com Signed-off-by: Lee Jones <lee@kernel.org>
The ROHM BD79300 is almost identical to the BD72720. Main differences
are the initial values for some of the registers. Thus, it appears the BD79300 can be handled with same software as BD72720.
Adding the compatible for the BD79300 enables people to use the real IC
type in the device-tree instead of claiming it is BD72720. This does
also help differentiating the ICs if appears it is needed.
Add own compatible for the BD73900 and mark BD72720 as a fall-back.
Randy Dunlap [Mon, 9 Mar 2026 21:42:23 +0000 (14:42 -0700)]
mfd: si476x: Fix kernel-doc warnings
Add kernel-doc entries for missing fields or correct some typos
in names to eliminate kernel-doc warnings:
Warning: include/linux/mfd/si476x-core.h:156 struct member 'regmap' not
described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:156 struct member 'power_state'
not described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:156 struct member 'supplies' not
described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:156 struct member 'is_alive' not
described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:156 struct member 'rds_fifo_depth'
not described in 'si476x_core'
Warning: include/linux/mfd/si476x-core.h:170 function parameter 'core' not
described in 'si476x_core_lock'
Warning: include/linux/mfd/si476x-core.h:179 function parameter 'core' not
described in 'si476x_core_unlock'
Warning: include/linux/mfd/si476x-core.h:259 struct member 'firmware' not
described in 'si476x_func_info'
Warning: include/linux/mfd/si476x-core.h:335 struct member 'rds' not
described in 'si476x_rds_status_report'
I don't know what the 'ble' field is so I didn't add a kernel-doc comment
for it:
Warning: include/linux/mfd/si476x-core.h:335 struct member 'ble' not
described in 'si476x_rds_status_report'
Randy Dunlap [Mon, 9 Mar 2026 21:42:21 +0000 (14:42 -0700)]
mfd: kempld: Fix kernel-doc struct member names
Correct the struct member names to avoid kernel-doc warnings:
Warning: include/linux/mfd/kempld.h:114 struct member 'gpio_base' not
described in 'kempld_platform_data'
Warning: include/linux/mfd/kempld.h:114 struct member 'get_hardware_mutex'
not described in 'kempld_platform_data'
Warning: include/linux/mfd/kempld.h:114 struct member
'release_hardware_mutex' not described in 'kempld_platform_data'
Randy Dunlap [Mon, 9 Mar 2026 21:42:20 +0000 (14:42 -0700)]
mfd: congatec: Fix kernel-doc struct member names
Correct the struct member names to avoid kernel-doc warnings:
Warning: include/linux/mfd/cgbc.h:38 struct member 'version' not
described in 'cgbc_device_data'
Warning: ../include/linux/mfd/cgbc.h:38 struct member 'lock' not
described in 'cgbc_device_data'
Johan Hovold [Thu, 5 Mar 2026 10:40:51 +0000 (11:40 +0100)]
mfd: viperboard: Drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Subhash Rawat [Tue, 3 Mar 2026 18:32:36 +0000 (18:32 +0000)]
mfd: dln2: Switch to managed resources and fix bare unsigned types
Convert dln2_probe and dln2_setup_rx_urbs to use devm_kzalloc() and
devm_kmalloc() respectively. This simplifies resource management by
allowing the removal of manual kfree() calls in dln2_free() and
dln2_free_rx_urbs().
Additionally, update bare 'unsigned' types to 'unsigned int' to satisfy
checkpatch.pl warnings and comply with the Linux kernel coding style.
Hector Martin [Tue, 17 Feb 2026 10:47:26 +0000 (21:47 +1100)]
mfd: macsmc: Wire up Apple SMC power driver
Add the cell for the macsmc-power driver so it is probed by the
MFD core.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com> Link: https://patch.msgid.link/20260217-b4-macsmc-power-v7-2-4a4d63664362@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
The current configuration incorrectly uses the revision code as the CID.
Therefore, the driver cannot detect the same PMIC of different revisions.
(E1/E2 for MT6328, E1/E3 for MT6331/MT6332)
Based on these, the CID of MT6328, MT6331 and MT6332 should be corrected.
Additionally, the incorrect MT6331/MT6332 CID overlaps with the MT6320's
actual CID:
Add supply properties that match the P1 PMIC's actual hardware topology
where each buck converter has its own VIN pin and LDO groups share
common input pins. Supply names are defined according to the pinout
names in the P1 datasheet.
The existing "vin-supply" is dropped from the binding document as the
updated spacemit P1 driver no longer parses it. Only the per-rail names
("vin1-supply", "vin2-supply", ...) are supported.
mfd: lpc_ich: Expose the GPIO controller cell's software node
One of the users of this driver - meraki-mx100 - abuses the software
node API by setting up a dummy software node without any logical link to
this GPIO controller and uses the fact that the GPIO core matches the
controller's label against the swnode's name to make the lookup work.
We want to remove this behavior from GPIOLIB in favor of actual matching
of firmware nodes but that would break this user. To facilitate that:
create a software node for the GPIO controller cell and expose its
address in the provided MFD header.
mfd: atmel-hlcdc: Fetch LVDS PLL clock for LVDS display
The XLCDC IP supports parallel RGB, MIPI DSI and LVDS Display.
The LCD Generic clock (sys_clk) is used for Parallel RGB and MIPI
displays, while the LVDS PLL clock (lvds_pll_clk) is used for LVDS
displays.Since both the clocks cannot co-exist together in the DT
for a given display, this patch tries sys_clk first (RGB/MIPI),
fallback to lvds_pll_clk (LVDS).
Johan Hovold [Thu, 5 Mar 2026 13:03:58 +0000 (14:03 +0100)]
mfd: dln2: Drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Marek Vasut [Thu, 22 Jan 2026 11:13:21 +0000 (12:13 +0100)]
mfd: stpmic1: Attempt system shutdown twice in case PMIC is confused
Attempt to shut down again, in case the first attempt failed.
The STPMIC1 might get confused and the first regmap_update_bits()
returns with -ETIMEDOUT / -110 . If that or similar transient
failure occurs, try to shut down again. If the second attempt
fails, there is some bigger problem, report it to user.
Cc: stable@vger.kernel.org Fixes: 6e9df38f359a ("mfd: stpmic1: Add PMIC poweroff via sys-off handler") Signed-off-by: Marek Vasut <marex@nabladev.com> Link: https://patch.msgid.link/20260122111423.62591-1-marex@nabladev.com Signed-off-by: Lee Jones <lee@kernel.org>
Kexin Sun [Sat, 21 Mar 2026 10:57:59 +0000 (18:57 +0800)]
iommufd: update outdated comment for renamed iommufd_hw_pagetable_alloc()
The function iommufd_hw_pagetable_alloc() was renamed to
iommufd_hwpt_paging_alloc() by commit 89db31635c87
("iommufd: Derive iommufd_hwpt_paging from
iommufd_hw_pagetable"). Update the stale reference in
iommufd_device_auto_get_domain().
ASoC: dt-bindings: mediatek,mt2701-wm8960: Correctly use additionalProperties
The binding does not reference any other schema, thus should use
"additionalProperties: false" to disallow any undocumented properties.
Correct the code and place this after "required:" block to match
convention expressed in example-schema.yaml.
kbuild: uapi: move some compiler arguments out of the command definition
Simplify the definition of cmd_hdrtest by moving some of it to a new
variable. This will both enable the upcoming reuse of those flags
and also the extension of cmd_hdrtest.
Shuming Fan [Wed, 25 Mar 2026 09:20:17 +0000 (17:20 +0800)]
ASoC: SDCA: remove the max count of initialization table
The number of the initialization table may exceed 2048.
Therefore, this patch removes the limitation and allows the driver to
allocate memory dynamically based on the size of the initialization table.
drm/msm/dsi: Add support for RGB101010 pixel format
Add video and command mode destination format mappings for RGB101010,
and extend the VID_CFG0 DST_FORMAT bitfield to 3 bits to accommodate
the new format value.
Make sure this is guarded behind MSM_DSI_6G_VER >= V2.1.0 as anything
older does not support this.
Required for 10 bit panels such as the BOE BF068MWM-TD0 found on the
Nothing Phone (3a).
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Patchwork: https://patchwork.freedesktop.org/patch/713721/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-5-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
drm/msm/dsi: rename MSM8998 DSI version from V2_2_0 to V2_0_0
The MSM8998 DSI controller is v2.0.0 as stated in commit 7b8c9e203039
("drm/msm/dsi: Add support for MSM8998 DSI controller"). The value was
always correct just the name was wrong.
Rename and reorder to maintain version sorting.
Fixes: 7b8c9e203039 ("drm/msm/dsi: Add support for MSM8998 DSI controller") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Patchwork: https://patchwork.freedesktop.org/patch/713717/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-3-ff6afc904115@pm.me Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Which seems to hint that the vma we are re-inserting for the ops unwind
is either invalid or overlapping with something already inserted in the
vm. It shouldn't be invalid since this is a re-insertion, so must have
worked before. Leaving the likely culprit as something already placed
where we want to insert the vma.
Following from that, for the case where we do something like a rebind in
the middle of a vma, and one or both mapped ends are already compatible,
we skip doing the rebind of those vma and set next/prev to NULL. As well
as then adjust the original unmap va range, to avoid unmapping the ends.
However, if we trigger the unwind path, we end up with three va, with
the two ends never being removed and the original va range in the middle
still being the shrunken size.
If this occurs, one failure mode is when another unwind op needs to
interact with that range, which can happen with a vector of binds. For
example, if we need to re-insert something in place of the original va.
In this case the va is still the shrunken version, so when removing it
and then doing a re-insert it can overlap with the ends, which were
never removed, triggering a warning like above, plus leaving the vm in a
bad state.
With that, we need two things here:
1) Stop nuking the prev/next tracking for the skip cases. Instead
relying on checking for skip prev/next, where needed. That way on the
unwind path, we now correctly remove both ends.
2) Undo the unmap va shrinkage, on the unwind path. With the two ends
now removed the unmap va should expand back to the original size again,
before re-insertion.
v2:
- Update the explanation in the commit message, based on an actual IGT of
triggering this issue, rather than conjecture.
- Also undo the unmap shrinkage, for the skip case. With the two ends
now removed, the original unmap va range should expand back to the
original range.
v3:
- Track the old start/range separately. vma_size/start() uses the va
info directly.
Add MIPI_DSI_FMT_RGB101010 for 30 bit (10,10,10 RGB) pixel format,
corresponding to the packed 30 bit pixel stream defined in MIPI DSI
v1.3 Section 8.8.17.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Patchwork: https://patchwork.freedesktop.org/patch/713714/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-1-ff6afc904115@pm.me
[Acked by Maxime to be merged through msm-next on IRC on dri-devel]
[DB: moved RGB101010 to the end of enum mipi_dsi_pixel_format] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Damon Ding [Tue, 11 Nov 2025 02:21:03 +0000 (10:21 +0800)]
drm/bridge: analogix_dp: Reuse &link_train.training_lane[] to set DPCD DP_TRAINING_LANEx_SET
In analogix_dp_link_start(), &link_train.training_lane[] is used to
set phy PE/VS configurations, and buf[] is initialized with the same
values to set DPCD DP_TRAINING_LANEx_SET.
It makes sense to reuse &link_train.training_lane[] to set DPCD
DP_TRAINING_LANEx_SET, which can remove the redundant assignments
and make codes more concise.
Which seems to hint that the vma we are re-inserting for the ops unwind
is either invalid or overlapping with something already inserted in the
vm. It shouldn't be invalid since this is a re-insertion, so must have
worked before. Leaving the likely culprit as something already placed
where we want to insert the vma.
Following from that, for the case where we do something like a rebind in
the middle of a vma, and one or both mapped ends are already compatible,
we skip doing the rebind of those vma and set next/prev to NULL. As well
as then adjust the original unmap va range, to avoid unmapping the ends.
However, if we trigger the unwind path, we end up with three va, with
the two ends never being removed and the original va range in the middle
still being the shrunken size.
If this occurs, one failure mode is when another unwind op needs to
interact with that range, which can happen with a vector of binds. For
example, if we need to re-insert something in place of the original va.
In this case the va is still the shrunken version, so when removing it
and then doing a re-insert it can overlap with the ends, which were
never removed, triggering a warning like above, plus leaving the vm in a
bad state.
With that, we need two things here:
1) Stop nuking the prev/next tracking for the skip cases. Instead
relying on checking for skip prev/next, where needed. That way on the
unwind path, we now correctly remove both ends.
2) Undo the unmap va shrinkage, on the unwind path. With the two ends
now removed the unmap va should expand back to the original size again,
before re-insertion.
v2:
- Update the explanation in the commit message, based on an actual IGT of
triggering this issue, rather than conjecture.
- Also undo the unmap shrinkage, for the skip case. With the two ends
now removed, the original unmap va range should expand back to the
original range.
v3:
- Track the old start/range separately. vma_size/start() uses the va
info directly.
Antonio Hickey [Thu, 19 Mar 2026 09:35:28 +0000 (10:35 +0100)]
rust: pin-init: replace `addr_of_mut!` with `&raw mut`
`feature(raw_ref_op)` became stable in Rust 1.82.0 which is the current
MSRV of pin-init with no default features. Earlier Rust versions will
now need to enable `raw_ref_op` to continue to work with pin-init.
This reduces visual complexity and improves consistency with existing
reference syntax.
Hamdan-Khan [Thu, 19 Mar 2026 09:35:27 +0000 (10:35 +0100)]
rust: pin-init: implement ZeroableOption for NonZero* integer types
Add a macro for implementing `ZeroableOption` for `NonZero*` types.
`Option<NonZero*>` now automatically implements `Zeroable` trait by
implementing `ZeroableOption` for `NonZero*` types, which serves as a
blanket impl.
Gary Guo [Thu, 19 Mar 2026 09:35:26 +0000 (10:35 +0100)]
rust: pin-init: doc: de-clutter documentation with fake-variadics
Currently the doc for `Zeroable` and `ZeroableOption` are filled with the
generated impl of tuples and fn pointers. Use the internal
"fake_variadics" feature to improve the rendered quality.
This makes use of an internal feature, however this is of minimal risk as
it's for documentation only, not activated during normal build, gated
behind `USE_RUSTC_FEATURES`, and can be removed at any time. This feature
is already used by serde and bevy to improve documentation quality.
For compilers that cannot use this feature, we still hide most generated
impls, and the existence of them are hinted by doc comments on the single
non-hidden impl.
Benno Lossin [Thu, 19 Mar 2026 09:35:25 +0000 (10:35 +0100)]
rust: pin-init: properly document let binding workaround
The three let bindings (in the bodies of `cast_init`, `cast_pin_init`
and the `init!` macro) are used to avoid the following compiler error in
Rust 1.78.0, 1.79.0, 1.80.0, 1.80.1, and 1.81.0 (just showing the one
for `cast_init`, the others are similar):
error[E0391]: cycle detected when computing type of opaque `cast_init::{opaque#0}`
--> src/lib.rs:1160:66
|
1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> {
| ^^^^^^^^^^^^^^^
|
note: ...which requires borrow-checking `cast_init`...
--> src/lib.rs:1160:1
|
1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...which requires const checking `cast_init`...
--> src/lib.rs:1160:1
|
1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: ...which requires computing whether `cast_init::{opaque#0}` is freeze...
= note: ...which requires evaluating trait selection obligation `cast_init::{opaque#0}: core::marker::Freeze`...
= note: ...which again requires computing type of opaque `cast_init::{opaque#0}`, completing the cycle
note: cycle used when computing type of `cast_init::{opaque#0}`
--> src/lib.rs:1160:66
|
1160 | pub const unsafe fn cast_init<T, U, E>(init: impl Init<T, E>) -> impl Init<U, E> {
| ^^^^^^^^^^^^^^^
= note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information
Once we raise the nightly-MSRV above 1.81, we can remove this
workaround.
Gary Guo [Thu, 19 Mar 2026 09:35:24 +0000 (10:35 +0100)]
rust: pin-init: build: simplify use of nightly features
We use some features that are already stable in later versions of Rust,
but only available as unstable features in older Rust versions that the
kernel needs to support.
Instead of checking if a feature is already stable, simply enable them
and allow the warning if the feature is already stable. This avoids the
need of hardcoding whether a feature has been stabilized at a given
version.
`#[feature(...)]` is used when cfg `USE_RUSTC_FEATURES` is enabled. The
build script automatically does this when a nightly compiler is detected
or `RUSTC_BOOTSTRAP` is set.
arm64: tegra: defconfig: Drop redundant ARCH_TEGRA_foo_SOC
All CONFIG_ARCH_TEGRA_132_SOC-like symbols are now default for
ARCH_TEGRA, so drop redundant lines from defconfig. Tested with
comparing include/generated/autoconf.h.
ARM: tegra: defconfig: Drop redundant ARCH_TEGRA_foo_SOC
All CONFIG_ARCH_TEGRA_2x_SOC-like symbols are now default for
ARCH_TEGRA, so drop redundant lines from defconfigs. Tested with
comparing include/generated/autoconf.h.
soc/tegra: Make ARCH_TEGRA_SOC_FOO defaults for NVIDIA Tegra
By convention, only one globally selectable ARCH_PLATFORM is expected
for given SoC platform, defined in arch/arm64/Kconfig.platforms or
arch/arm/mach-*/Kconfig, because we target a single multi-platform
kernel image.
Platforms wanting different granularity, e.g. due to size constraints on
their devices, should be sure that globally only one ARCH_PLATFORM is
selected in defconfig. Change Tegra per-SoC Kconfig entries to default
to ARCH_TEGRA allowing removal of these per-SoC parts from defconfigs.
wifi: iwlwifi: reduce the number of prints upon firmware crash
When the firmware crashes, we print data to be able to know what
happened. The problem is that those prints became excessive as during
the course of the years, we added more data without ever removing the
prints that were no longer useful.
Instead of spamming the log with data that will not help anyone, limit
the prints to what is really needed.
Avinash Bhatt [Sat, 21 Mar 2026 17:29:18 +0000 (19:29 +0200)]
wifi: iwlwifi: mld: block EMLSR during TDLS connections
TDLS (Tunneled Direct Link Setup) requires single-link operation
for direct peer-to-peer communication, which is incompatible with
EMLSR (Enhanced Multi-Link Single Radio) mode where the radio
switches between multiple links.
Block EMLSR when the first TDLS peer is added and unblock when
the last TDLS peer is removed. The block/unblock APIs handle
exiting EMLSR and triggering link selection automatically.
wifi: iwlwifi: mld: update the TLC when we deactivate a link
We hit a problem in the channel switch flow.
We had link 0 using PHY 0, so the TLC object in the firmware is using
PHY 0.
Then we switched channel, so mac80211 / iwlmld:
* deactivated link 0
* removed PHY 0
* added PHY 1
* modified link 0 to use PHY 1
* activated link 0.
The TLC object was not updated and the firmware was unhappy that the TLC
was still trying to use PHY 0.
Fix that by letting the TLC know about the PHY context before the link
activation.
When we are de-activating a link, let the TLC know so that it'll send a
TLC configuration command with an invalid PHY context to remove the
relationship between the TLC object and the PHY that is going to be
removed.
That last part is not implemented yet in the firmware, so leave this as
a TODO for now.
Miri Korenblit [Sat, 21 Mar 2026 17:29:15 +0000 (19:29 +0200)]
wifi: iwlwifi: add a macro for max FW links
Currently we use IWL_FW_MAX_LINK_ID + 1 to indicate the maximum number
of link that the fw supports. This is a bit confusing.
Add a macro that indicates the number if maximum links that the FW
supports and use it instead.
Miri Korenblit [Sat, 21 Mar 2026 17:29:14 +0000 (19:29 +0200)]
wifi: iwlwifi: mld: always assign a fw id to a vif
We used to have a fw id assignment in iwl_mld_init_vif since all interface
types that were added to the driver was immediately added to the FW as
well.
Since NAN was introduced, this is no longer the case - the NAN interface
is not added to the fw until a local schedule is configured.
For this vif we don't assign a fw id so it is 0 by default.
But later, when the vif is removed from the driver, we think that it has
a valid fw id (0) and we point fw_id_to_vif[0] to NULL.
fw_id_to_vif[0] might actually point to another vif with a valid fw id
0. In this case, we end up messing fw_id_to_vif.
Fix this by initializing a vif with a special invalid fw id, and by
exiting iwl_mld_rm_vif early for NAN interfaces.
Miri Korenblit [Sat, 21 Mar 2026 17:29:13 +0000 (19:29 +0200)]
wifi: iwlwifi: mld: use the dedicated helper to extract a link
There is a helper, iwl_mld_fw_id_to_link_conf, that converts a fw link
id into the bss_conf structure. Use it in two more places instead of
retrieving the bss_conf directly from the fw-id-to-bss_conf mapping array.
This required changing the loop bound in iwl_mld_process_per_link_stats()
to ucode_capa.num_links, to avoid hitting a IWL_FW_CHECK for link ids
> ucode_capa.num_links and < ARRAY_SIZE(fw_id_to_bss_conf), but this
change makes sense anyway (there is no reason to iterate links that
cannot be valid).
Johannes Berg [Sat, 21 Mar 2026 17:29:12 +0000 (19:29 +0200)]
wifi: iwlwifi: add MAC context command version 4
Due to NAN additions, this command needs to grow. In iwlmvm
we just need to use the old _v3 (or v2) version, but iwlmld
needs to handle the difference and send both. Do that as a
first step towards adding NAN support.
Avinash Bhatt [Sat, 21 Mar 2026 17:29:11 +0000 (19:29 +0200)]
wifi: iwlwifi: handle NULL/ERR returns from ptp_clock_register()
ptp_clock_register() returns NULL when PTP support is disabled and may
return an ERR_PTR() on other failures. Reduce Log severity for NULL
return cases to avoid misleading errors when PTP is unavailable.
Johannes Berg [Sat, 21 Mar 2026 17:29:09 +0000 (19:29 +0200)]
wifi: iwlwifi: mld: make alloc functions not forced static
In preparation for NAN needing the link ID allocation, have
the macro not automatically make the ID allocation functions
static so we can remove that later from the link allocation
function.
Johannes Berg [Fri, 20 Mar 2026 08:09:18 +0000 (10:09 +0200)]
wifi: iwlwifi: mld: remove type argument from iwl_mld_add_sta()
This is used only in a single place, and the caller always sets
the type to STATION_TYPE_PEER right now. We need to change some
of this for NAN in the future, removing the type argument will
simplify that.
Johannes Berg [Fri, 20 Mar 2026 08:09:16 +0000 (10:09 +0200)]
wifi: iwlwifi: pcie: don't dump on reset handshake in dump
When a FW dump happens, possibly even because of a reset handshake
timeout, there's no point in attempting to dump again. Since all the
callers of the function outside the transport itself are from the FW
dump infrastructure, just split the internal function and make the
external one not dump on timeout.
Johannes Berg [Fri, 20 Mar 2026 08:09:15 +0000 (10:09 +0200)]
wifi: iwlwifi: use IWL_FW_CHECK for sync timeout
This could be a firmware issue, it didn't send all the responses
quickly enough. There are other potential issues (interrupts not
being delivered, etc.) but the FW debug data will at least give
some better information, and it's not a WARN condition anyway.
Prevent potential issues when newer BIOS revisions
are used with firmware that doesn't support them for
PER_PLATFORM_ANT_GAIN_CMD.
Without this check, the driver may attempt to use
BIOS configurations that are incompatible with the
current firmware version, leading to dropping of
command in firmware without any failure notification
to driver.
Miri Korenblit [Fri, 20 Mar 2026 08:09:13 +0000 (10:09 +0200)]
wifi: iwlwifi: validate the channels received in iwl_mcc_update_resp_v*
Check with IWL_FW_CHECK that the FW doesn't send a channel that we don't
support. Otherwise, the center frequency will be 0, leading to a
warning since is_valid_reg_rule will return false, of course.
Although the warning is verbose enough, the IWL_FW_CHECK will spare some
of the debug.
Avinash Bhatt [Fri, 20 Mar 2026 08:09:12 +0000 (10:09 +0200)]
wifi: iwlwifi: add CQM event support for per-link RSSI changes
Implement CQM RSSI threshold handling by tracking the last reported RSSI
and issuing CQM low/high events when the RSSI crosses the configured
threshold with the required hysteresis. This provides proper CQM support
and enables userspace to receive per-link RSSI notifications.
wifi: iwlwifi: fw: Add TLV support for BIOS revision of command
Add support for newer firmware API versions that support
multiple BIOS revisions. Use the new TLV provided by
firmware to determine which BIOS revision it supports.
Future patches will use this information to either
drop commands when the BIOS revision is higher than
supported or convert commands based on the command
specific implementation.
Since we are including now nvm-reg.h in img.h, this causes a
re-definition error of IWL_NUM_CHANNELS which is also defined in
eeprom.c, so rename IWL_NUM_CHANNELS to IWL_NUM_CHANNELS_V2
Johannes Berg [Fri, 20 Mar 2026 08:09:07 +0000 (10:09 +0200)]
wifi: iwlwifi: mld: support changing iftype at runtime
While the interface isn't really operating, which is already
required by mac80211, we can simply remove the MAC and add
it again to change the type. Implement this simple handling.
We could almost consider moving this to mac80211 itself, as
this kind of flow should be supportable by any device, but
for now keep it here.
wifi: iwlwifi: support PER_CHAIN_LIMIT_OFFSET_CMD v6
This includes support for UNII-9.
Store the source of the WGDS table in the firmware runtime object to be
able to pass the information to the firmware.
Prefer to use ARRAY_SIZE when we check array-length.
Make sure num_profile isn't bigger than the number of profiles we can
actually store in the firmware runtime object.
Same of the number of bands.
wifi: iwlwifi: uefi: open code the parsing of the WGDS table
We will soon add support for UNII-9 band in the WGDS table. We need to
decouple the UEFI code from the firmware runtime code.
The firmware runtime is just a software object which will need to grow
and UEFI objects need a new revision to grow. Existing systems will keep
the same UEFI objects.
Just like PPAG and SAR, stop using structures to parse the UEFI tables
since the layout depends on the revision.
The support for the new revision will be added in the next patch, for
now, just do the ground work.
wifi: iwlwifi: mld: support version 11 of REDUCE_TX_POWER_CMD
This introduces support for UNII-9.
After we increased the size of the arrays of the subbands in SAR
structure, we now support the new firmware command.
wifi: iwlwifi: uefi: support the new WRDS and EWRD tables
Those tables now have support for UNII-9 subband.
Refactor iwl_uefi_set_sar_profile to get an array of values that makes
it easier to use when the number of subbands can vary.
Revamp a bit the code that fetches the tables to ask for the smaller
table, then we can check the size of the object that we got and compare
to the expected sizes to determine what revision to expect.
Johannes Berg [Thu, 19 Mar 2026 18:48:42 +0000 (20:48 +0200)]
wifi: iwlwifi: restrict TOP reset to some devices
Due to the Bluetooth implementation needing to match, not all
devices can actually do TOP reset. Restrict it to Sc2/Sc2f or
later, with Wh RF or later.
wifi: iwlwifi: uefi: add support for PPAG table rev5
This table has another subband for UNII-9.
Add defines for the sizes of rev4 and rev5 to easily know how much data
to ask from iwl_uefi_get_verified_variable.
In case rev5 doesn't exist, fallback to rev4.
Check that the revision advertised by the fetched table matches the size
that we got.
This adds support for UNII9 which requires to add a subband.
Just increase the number of subbands that we need to read.
Replace the usage of the IWL_NUM_SUB_BANDS_VX macros in acpi.h since
those macros are defined in the firmware API and ACPI declarations have
nothing to do the firmware API.
projects / thirdparty / kernel / stable.git / log
