Mark Brown [Tue, 24 Mar 2026 14:25:52 +0000 (14:25 +0000)]
spi: Use after free fixes
Johan Hovold <johan@kernel.org> says:
The SPI subsystem frees the controller and any subsystem allocated
driver data as part of deregistration (unless the allocation is device
managed).
This series fixes the IMX driver that got this wrong and then converts
it to use device managed allocation.
Included are also a (preparatory) deregistration fix for the rockchip
driver and related cleanups for the tegre20-slink and rockchip drivers
that both take a controller reference during unbind.
Johan Hovold [Tue, 24 Mar 2026 08:23:22 +0000 (09:23 +0100)]
spi: imx: fix use-after-free on unbind
The SPI subsystem frees the controller and any subsystem allocated
driver data as part of deregistration (unless the allocation is device
managed).
Take another reference before deregistering the controller so that the
driver data is not freed until the driver is done with it.
Fixes: 307c897db762 ("spi: spi-imx: replace struct spi_imx_data::bitbang by pointer to struct spi_controller") Cc: stable@vger.kernel.org # 5.19 Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260324082326.901043-2-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
1) Add missing extack for XFRMA_SA_PCPU in add_acquire and allocspi.
From Sabrina Dubroca.
2) Fix the condition on x->pcpu_num in xfrm_sa_len by using the
proper check. From Sabrina Dubroca.
3) Call xdo_dev_state_delete during state update to properly cleanup
the xdo device state. From Sabrina Dubroca.
4) Fix a potential skb leak in espintcp when async crypto is used.
From Sabrina Dubroca.
5) Validate inner IPv4 header length in IPTFS payload to avoid
parsing malformed packets. From Roshan Kumar.
6) Fix skb_put() panic on non-linear skb during IPTFS reassembly.
From Fernando Fernandez Mancera.
7) Silence various sparse warnings related to RCU, state, and policy
handling. From Sabrina Dubroca.
8) Fix work re-schedule race after cancel in xfrm_nat_keepalive_net_fini().
From Hyunwoo Kim.
9) Prevent policy_hthresh.work from racing with netns teardown by using
a proper cleanup mechanism. From Minwoo Ra.
10) Validate that the family of the source and destination addresses match
in pfkey_send_migrate(). From Eric Dumazet.
11) Only publish mode_data after the clone is setup in the IPTFS receive path.
This prevents leaving x->mode_data pointing at freed memory on error.
From Paul Moses.
Please pull or let me know if there are problems.
ipsec-2026-03-23
* tag 'ipsec-2026-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:
xfrm: iptfs: only publish mode_data after clone setup
af_key: validate families in pfkey_send_migrate()
xfrm: prevent policy_hthresh.work from racing with netns teardown
xfrm: Fix work re-schedule after cancel in xfrm_nat_keepalive_net_fini()
xfrm: avoid RCU warnings around the per-netns netlink socket
xfrm: add rcu_access_pointer to silence sparse warning for xfrm_input_afinfo
xfrm: policy: silence sparse warning in xfrm_policy_unregister_afinfo
xfrm: policy: fix sparse warnings in xfrm_policy_{init,fini}
xfrm: state: silence sparse warnings during netns exit
xfrm: remove rcu/state_hold from xfrm_state_lookup_spi_proto
xfrm: state: add xfrm_state_deref_prot to state_by* walk under lock
xfrm: state: fix sparse warnings around XFRM_STATE_INSERT
xfrm: state: fix sparse warnings in xfrm_state_init
xfrm: state: fix sparse warnings on xfrm_state_hold_rcu
xfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly
xfrm: iptfs: validate inner IPv4 header length in IPTFS payload
esp: fix skb leak with espintcp and async crypto
xfrm: call xdo_dev_state_delete during state update
xfrm: fix the condition on x->pcpu_num in xfrm_sa_len
xfrm: add missing extack for XFRMA_SA_PCPU in add_acquire and allocspi
====================
Aldo Conte [Fri, 20 Mar 2026 11:23:02 +0000 (12:23 +0100)]
perf/x86/intel/p4: Fix unused variable warning in p4_pmu_init()
Build the kernel with make W=1 generates the following warning:
arch/x86/events/intel/p4.c: In function ‘p4_pmu_init’:
arch/x86/events/intel/p4.c:1370:27: error: variable ‘high’ set but not used [-Werror=unused-but-set-variable]
1370 | unsigned int low, high;
| ^~~~
This happens because, although both variables are declared and
initialized by rdmsr, only `low` is used in the subsequent if statement.
This patch uses the rdmsrq() macro instead of the rdmsr() macro.
The rdmsrq() macro avoids the use of high and low variables
because it reads the msr value in a single u64 variable.
Also, replace (1 << 7) with the proper macro.
Running `make W=1` again resolves the error.
I was unable to test the patch because
i do not have the hardware.
Marco Elver [Thu, 19 Mar 2026 13:52:38 +0000 (14:52 +0100)]
compiler: Simplify generic RELOC_HIDE()
When enabling Context Analysis (CONTEXT_ANALYSIS := y) in arch/x86/kvm
code, Clang's Thread Safety Analysis failed to recognize that identical
per_cpu() accesses refer to the same lock:
| CC [M] arch/x86/kvm/vmx/posted_intr.o
| arch/x86/kvm/vmx/posted_intr.c:186:2: error: releasing raw_spinlock '__ptr + __per_cpu_offset[vcpu->cpu]' that was not held [-Werror,-Wthread-safety-analysis]
| 186 | raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu));
| | ^
| ./include/linux/spinlock.h:276:32: note: expanded from macro 'raw_spin_unlock'
| 276 | #define raw_spin_unlock(lock) _raw_spin_unlock(lock)
| | ^
| arch/x86/kvm/vmx/posted_intr.c:207:1: error: raw_spinlock '__ptr + __per_cpu_offset[vcpu->cpu]' is still held at the end of function [-Werror,-Wthread-safety-analysis]
| 207 | }
| | ^
| arch/x86/kvm/vmx/posted_intr.c:182:2: note: raw_spinlock acquired here
| 182 | raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu),
| | ^
| ./include/linux/spinlock.h:235:2: note: expanded from macro 'raw_spin_lock_nested'
| 235 | _raw_spin_lock(((void)(subclass), (lock)))
| | ^
| 2 errors generated.
This occurred because the default RELOC_HIDE() implementation (used by
the per-CPU macros) is a statement expression containing an intermediate
'unsigned long' variable (this version appears to predate Git history).
While the analysis strips away inner casts when resolving pointer
aliases, it stops when encountering intermediate non-pointer variables
(this is Thread Safety Analysis specific and irrelevant for codegen).
This prevents the analysis from concluding that the pointers passed to
e.g. raw_spin_lock() and raw_spin_unlock() were identical when per-CPU
accessors are used.
Simplify RELOC_HIDE() to a single expression. This preserves the intent
of obfuscating UB-introducing out-of-bounds pointer calculations from
the compiler via the 'unsigned long' cast, but allows the alias analysis
to successfully resolve the pointers.
Using a recent Clang version, I observe that generated code remains the
same for vmlinux; the intermediate variable was already being optimized
away (for any respectable modern compiler, not doing so would be an
optimizer bug). Note that GCC provides its own version of RELOC_HIDE(),
so this change only affects Clang builds.
Add a test case to lib/test_context-analysis.c to catch any regressions.
Nicolin Chen [Fri, 13 Mar 2026 00:36:35 +0000 (17:36 -0700)]
iommu/tegra241-cmdqv: Update uAPI to clarify HYP_OWN requirement
>From hardware implementation perspective, a guest tegra241-cmdqv hardware
is different than the host hardware:
- Host HW is backed by a VINTF (HYP_OWN=1)
- Guest HW is backed by a VINTF (HYP_OWN=0)
The kernel driver has an implementation requirement of the HYP_OWN bit in
the VM. So, VMM must follow that to allow the same copy of Linux to work.
Add this requirement to the uAPI, which is currently missing.
Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Nicolin Chen [Fri, 13 Mar 2026 00:36:34 +0000 (17:36 -0700)]
iommu/tegra241-cmdqv: Set supports_cmd op in tegra241_vcmdq_hw_init()
vintf->hyp_own is finalized in tegra241_vintf_hw_init(). On the other hand,
tegra241_vcmdq_alloc_smmu_cmdq() is called via an init_structures callback,
which is earlier than tegra241_vintf_hw_init().
This results in the supports_cmd op always being set to the guest function,
although this doesn't break any functionality nor have some noticeable perf
impact since non-invalidation commands are not issued in the perf sensitive
context.
Fix this by moving supports_cmd to tegra241_vcmdq_hw_init().
After this change,
- For a guest kernel, this will be a status quo
- For a host kernel, non-invalidation commands will be issued to VCMDQ(s)
Fixes: a9d40285bdef ("iommu/tegra241-cmdqv: Limit CMDs for VCMDQs of a guest owned VINTF") Reported-by: Eric Auger <eric.auger@redhat.com> Reported-by: Shameer Kolothum <skolothumtho@nvidia.com> Closes: https://lore.kernel.org/qemu-devel/CH3PR12MB754836BEE54E39B30C7210C0AB44A@CH3PR12MB7548.namprd12.prod.outlook.com/ Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Shameer Kolothum <skolothumtho@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Ville Syrjälä [Mon, 23 Mar 2026 09:43:04 +0000 (11:43 +0200)]
drm/i915/de: Implement register polling in the display code
The plan is to move all the mmio stuff into the display code itself.
As a first step implement the register polling in intel_de.c.
Currently i915 and xe implement this stuff in slightly different
ways, so there are some functional changes here. Try to go for a
reasonable middle ground between the i915 and xe implementations:
- the exponential backoff limit is the simpler approach taken
by i915 (== just clamp the max sleep duration to 1 ms)
- the fast vs. slow timeout handling is similar to i915 where
we first try the fast timeout and then again the slow timeout
if the condition still isn't satisfied. xe just adds up the
timeouts together, which is a bit weird.
- the atomic wait variant uses udelay() like xe, whereas i915
has no udelay()s in its atomic loop. As a compromise go for a
fixed 1 usec delay for short waits, instead of the somewhat
peculiar xe behaviour where it effectively just does one
iteration of the loop.
- keep the "use udelay() for < 10 usec waits" logic (which
more or less mirrors fsleep()), but include an explicit
might_sleep() even for these short waits when called from
a non-atomic intel_de_wait*() function. This should prevent
people from calling the non-atomic functions from the wrong
place.
Eventually we may want to switch over to poll_timeout*(),
but that lacks the exponential backoff, so a bit too
radical to change in one go.
v2: Initialize ret in intel_de_wait_for_register() to avoid a
warning from the compiler. This is actually a false positive
since we always have fast_timeout_us!=0 when slow_timeout_us!=0,
but the compiler can't see that
Ville Syrjälä [Fri, 13 Mar 2026 11:10:27 +0000 (13:10 +0200)]
drm/i915/de: Move intel_de_wait*() into intel_de.c
intel_de_wait*() end up doing quite a bit of stuff, so the one
function call overhead from them seems insignificant. Move the
implementation intel_de.c.
Ville Syrjälä [Fri, 13 Mar 2026 11:10:26 +0000 (13:10 +0200)]
drm/i915/de: Introduce intel_de.c and move intel_de_{read,write}8() there
intel_de_{read,write}8() aren't performance critical so having them
as static inline is pointless. Introduce intel_de.c and move the
implementation there.
Ben Dooks [Tue, 24 Mar 2026 13:34:03 +0000 (13:34 +0000)]
ASoC: SOF: sof-audio: pcm_id is __le32
The pcm_id value is __le32 so convert it before passing to the dev_dbg
function to be printed. Also fixup some other uses of __le32 data and
a couple of places where %u should have been used instead of %d
Picked up by sparse prototype for variadic and printf
function checking. Fixes a large number of sparse warnings, such as:
sound/soc/sof/pcm.c:84:25: warning: incorrect type in argument 4 (different base types)
sound/soc/sof/pcm.c:84:25: expected unsigned int
sound/soc/sof/pcm.c:84:25: got restricted __le32 [usertype] pcm_id
Robin Murphy [Thu, 19 Mar 2026 15:24:34 +0000 (15:24 +0000)]
iommu/arm-smmu-v3: Update Arm errata
MMU-700 r1p1 has subsequently fixed some of the errata for which we've
been applying the workarounds unconditionally, so we can now make those
conditional. However, there have also been some more new cases
identified where we must rely on range invalidation commands, and thus
still nominally avoid DVM being inadvertently enabled.
Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
In several places in readdir.c there are calculations of the total size
of a dirent, which contains a few fixed fields plus a name field with
variable size. To add fun every dirent is of a slightly different type:
- struct old_linux_dirent
- struct linux_dirent
- struct linux_dirent64
- struct compat_old_linux_dirent
- struct compat_linux_dirent
Replace ugly size calculation by a macro called dirent_size() which
calculates the size of the structure based on the pointed type and
the name field len.
wifi: ath12k: Pass the correct value of each TID during a stop AMPDU session
With traffic ongoing for data TID [TID 0], an DELBA request to
stop AMPDU for the BA session was received on management TID [TID 4].
The corresponding TID number was incorrectly passed to stop the BA session,
resulting in the BA session for data TIDs being stopped and the BA size
being reduced to 1, causing an overall dip in TCP throughput.
Fix this issue by passing the correct argument from
ath12k_dp_rx_ampdu_stop() to ath12k_dp_arch_peer_rx_tid_reo_update()
during an AMPDU stop session. Instead of passing peer->dp_peer->rx_tid,
which is the base address of the array, corresponding to TID 0, pass
the value of &peer->dp_peer->rx_tid[params->tid]. With this, the
different TID numbers are accounted for.
wifi: ath11k: Pass the correct value of each TID during a stop AMPDU session
During ongoing traffic, a request to stop an AMPDU session
for one TID could incorrectly affect other active sessions.
This can happen because an incorrect TID reference would be
passed when updating the BA session state, causing the wrong
session to be stopped. As a result, the affected session would
be reduced to a minimal BA size, leading to a noticeable
throughput degradation.
Fix this issue by passing the correct argument from
ath11k_dp_rx_ampdu_stop() to ath11k_peer_rx_tid_reo_update()
during a stop AMPDU session. Instead of passing peer->tx_tid, which
is the base address of the array, corresponding to TID 0; pass
the value of &peer->rx_tid[params->tid], where the different TID numbers
are accounted for.
Add the Performance Monitoring Unit (PMU) node with the appropriate
compatible string and interrupt line so that perf and other
PMU-based tooling can function correctly on this SoC.
[root@SAMA7D65 ~]$ dmesg | grep -i pmu
[ 1.487869] hw-perfevents: enabled with armv7_cortex_a7 PMU driver, 5 (8000000f) counters available
[root@SAMA7D65 ~]$ perf list hw
List of pre-defined events (to be used in -e or -M):
Tvrtko Ursulin [Tue, 24 Mar 2026 08:40:18 +0000 (08:40 +0000)]
drm/xe/xelp: Expose AuxCCS frame buffer modifiers on Alderlake-P
Now that we have implemented all the related missing bits we can enable
the AuxCCS compressed modifiers which were disabled in cf48bddd31de ("drm/i915/display: Disable AuxCCS framebuffers if built for Xe").
Tested with KDE Wayland, on Lenovo Carbon X1 ADL-P:
Tvrtko Ursulin [Tue, 24 Mar 2026 08:40:17 +0000 (08:40 +0000)]
drm/xe/display: Add support for AuxCCS
Add support for mapping the auxiliary CCS buffer into the DPT page tables.
This will allow for better power efficiency by enabling the render
compression frame buffer modifiers such as
I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS in a following patch.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260324084018.20353-12-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tvrtko Ursulin [Tue, 24 Mar 2026 08:40:15 +0000 (08:40 +0000)]
drm/xe/display: Change write_dpt_remapped_tiled function signature
In preparation for adding support for the auxccs plane lets change the
function signature of write_dpt_remapped_tiled(). This will enable a
tidier way of extending it subsequent patches.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Michael J. Ruhl <michael.j.ruhl@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260324084018.20353-10-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tvrtko Ursulin [Tue, 24 Mar 2026 08:40:12 +0000 (08:40 +0000)]
drm/xe: Move aux table invalidation to ring ops
Implement the suggestion of moving the aux invalidation from a helper to a
ring ops vfunc, together with the suggestion to split the vfunc table of
video decode and video enhance engines.
With this done the LRC code will be able to access the functionality via
the newly added ring ops vfunc.
Tvrtko Ursulin [Tue, 24 Mar 2026 08:40:10 +0000 (08:40 +0000)]
drm/xe/xelp: Quiesce memory traffic before invalidating AuxCCS
According to i915 commit ad8ebf12217e ("drm/i915/gt: Ensure memory quiesced before invalidation")
quiescing of the memory traffic is required before invalidating the AuxCCS
tables.
Matt Roper [Thu, 19 Mar 2026 22:30:34 +0000 (15:30 -0700)]
drm/xe: Implement recent spec updates to Wa_16025250150
The hardware teams noticed that the originally documented workaround
steps for Wa_16025250150 may not be sufficient to fully avoid a hardware
issue. The workaround documentation has been augmented to suggest
programming one additional register; make the corresponding change in
the driver.
Tvrtko Ursulin [Tue, 24 Mar 2026 08:40:08 +0000 (08:40 +0000)]
drm/xe: Use write-combine mapping when populating DPT
The fallback case for DPT backing store is a buffer object in system
memory buffer, which by default use a write-back CPU caching policy.
If this fallback gets triggered, and since there is currently no flushing,
the DPT writes made when pinning a buffer to display are not guaranteed to
be seen by the display engine.
To fix this, since both the local memory and the stolen memory DPT
placements already use write-combine, let us make the system memory option
follow suit by passing down the appropriate flag.
Tvrtko Ursulin [Tue, 24 Mar 2026 08:40:07 +0000 (08:40 +0000)]
drm/xe: Rename XE_BO_FLAG_SCANOUT to XE_BO_FLAG_FORCE_WC
Rename XE_BO_FLAG_SCANOUT to XE_BO_FLAG_FORCE_WC so that the usage of the
flag can legitimately be expanded to more than just the actual frame-
buffer objects.
Denis Benato [Wed, 4 Mar 2026 13:26:08 +0000 (14:26 +0100)]
platform/x86: asus-wmi: do not enforce a battery charge threshold
Users are complaining for the battery limit being reset at 100% during
the boot process while the general consensus appears to not apply
unsolicited hardware changes, therefore stop resetting the battery
charge limit at boot and return -ENODATA on charge_end_threshold to
signal for an unknown limit.
Suggested-by: Antheas Kapenekakis <lkml@antheas.dev> Suggested-by: Derek J. Clark <derekjohn.clark@gmail.com> Signed-off-by: Denis Benato <denis.benato@linux.dev> Reviewed-by: Derek J. Clark <derekjohn.clark@gmail.com> Tested-by: Antheas Kapenekakis <lkml@antheas.dev> Link: https://patch.msgid.link/20260304132608.33815-1-denis.benato@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Shuvam Pandey [Tue, 17 Mar 2026 11:45:48 +0000 (17:30 +0545)]
printf: add IPv6 address format tests
printf_kunit already covers IPv4 address formatting, but the ip6()
test case is empty even though printk-formats.rst documents %pI6,
%pi6, %pI6c, and generic %pIS variants.
Add focused IPv6 checks for raw and generic formatting, compressed
output, the single-zero %pI6c corner case, and bracketed port
formatting for sockaddr_in6.
Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Tested-by: Petr Mladek <pmladek@suse.com> Link: https://patch.msgid.link/20260317114548.98919-1-shuvampandey1@gmail.com
[pmladek@suse.com: Removed non-necessary details from the commit message.] Signed-off-by: Petr Mladek <pmladek@suse.com>
Niranjan H Y [Tue, 24 Mar 2026 04:12:59 +0000 (09:42 +0530)]
ASoC: sdw_utils: add vendor_id to asoc_sdw_codec_info
struct asoc_sdw_codec_info has part_id which is not
sufficient to uniquely identify devices. This change
adds the vendor_id field and updates the codec_info
list with the corresponding vendor id as per the
Manufacturer's id in https://mid.mipi.org/
Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260324041300.784-1-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
Looks like we ended up with a typo during device tree data parsing
as part of 4f16b6351bbff ("ASoC: codecs: wcd: add common helper for wcd
codecs") patch.
This will result in not parsing the device tree data and results in
zero mic bias values.
Fix this by calling wcd_dt_parse_micbias_info instead of
wcd_dt_parse_mbhc_data.
Fixes: 4f16b6351bbff ("ASoC: codecs: wcd: add common helper for wcd codecs") Cc: Stable@vger.kernel.org Reported-by: Joel Selvaraj <foss@joelselvaraj.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260323231748.2217967-1-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
Alice Ryhl [Tue, 24 Mar 2026 10:49:59 +0000 (10:49 +0000)]
rust: regulator: do not assume that regulator_get() returns non-null
The Rust `Regulator` abstraction uses `NonNull` to wrap the underlying
`struct regulator` pointer. When `CONFIG_REGULATOR` is disabled, the C
stub for `regulator_get` returns `NULL`. `from_err_ptr` does not treat
`NULL` as an error, so it was passed to `NonNull::new_unchecked`,
causing undefined behavior.
Fix this by using a raw pointer `*mut bindings::regulator` instead of
`NonNull`. This allows `inner` to be `NULL` when `CONFIG_REGULATOR` is
disabled, and leverages the C stubs which are designed to handle `NULL`
or are no-ops.
Fixes: 9b614ceada7c ("rust: regulator: add a bare minimum regulator abstraction") Reported-by: Miguel Ojeda <ojeda@kernel.org> Closes: https://lore.kernel.org/r/20260322193830.89324-1-ojeda@kernel.org Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Link: https://patch.msgid.link/20260324-regulator-fix-v1-1-a5244afa3c15@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
Mingyou Chen [Mon, 23 Mar 2026 13:22:18 +0000 (21:22 +0800)]
platform/x86: bitland-mifs-wmi: Add new Bitland MIFS WMI driver
Add a new driver for Bitland laptops that utilize the MIFS (MiInterface)
WMI interface.
The driver implements several features through the WMI interface:
- Platform Profile: Supports "Quiet", "Balanced", "Performance", and
"Full Speed" modes. The "Full Speed" mode is intelligently restricted
based on the AC adapter type (requires DC power, not supported on
USB-C charging) as required by the hardware.
- Hwmon: Provides monitoring for CPU, GPU, and System fan speeds,
as well as CPU temperature sensors.
- Keyboard Backlight: Integrated with the LED class device for
brightness control and provides sysfs attributes for keyboard modes
(cyclic, fixed, etc.).
- GPU Mode: Allows switching between Hybrid, Discrete, and UMA
graphics modes via sysfs.
- Hotkeys: Handles WMI events for system hotkeys (Calculator, Browser,
App launch) using sparse keymaps and reports status changes for
Airplane mode, Touchpad, and CapsLock.
- Fan Boost: Provides a sysfs interface to force fans to maximum speed.
Jihed Chaibi [Sat, 21 Mar 2026 01:20:11 +0000 (02:20 +0100)]
ASoC: dt-bindings: stm32: Fix incorrect compatible string in stm32h7-sai match
The conditional block that defines clock constraints for the stm32h7-sai
variant references "st,stm32mph7-sai", which does not match any compatible
string in the enum. As a result, clock validation for the h7 variant is
silently skipped. Correct the compatible string to "st,stm32h7-sai".
Fixes: 8509bb1f11a1f ("ASoC: dt-bindings: add stm32mp25 support for sai") Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com> Reviewed-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20260321012011.125791-1-jihed.chaibi.dev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Maxime Ripard [Thu, 5 Mar 2026 09:05:06 +0000 (10:05 +0100)]
drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspace
The hdmi_colorspace enum was defined to represent the colorspace value
of the HDMI infoframes. It was later used by some HDMI drivers to
express the output format they should be setting up.
During the introduction of the HDMI helpers, it then was used to
represent it in the drm_connector_hdmi_state structure.
However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_*
defines, and now with the drm_output_color_format enum. Let's
consolidate around drm_output_color_format in drm_connector_hdmi_state
to facilitate the current effort to provide a global output format
selection mechanism.
Maxime Ripard [Thu, 5 Mar 2026 09:05:04 +0000 (10:05 +0100)]
drm/rockchip: analogix: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:05:03 +0000 (10:05 +0100)]
drm/mediatek: dp: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:05:02 +0000 (10:05 +0100)]
drm/arm: komeda: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:05:01 +0000 (10:05 +0100)]
drm/bridge: synopsys: dw-hdmi: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:05:00 +0000 (10:05 +0100)]
drm/bridge: synopsys: dw-dp: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:59 +0000 (10:04 +0100)]
drm/bridge: cadence: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:58 +0000 (10:04 +0100)]
drm/bridge: analogix: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:57 +0000 (10:04 +0100)]
drm/bridge: adv7511: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:56 +0000 (10:04 +0100)]
drm/amdgpu: display: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:55 +0000 (10:04 +0100)]
drm/display: hdmi: Convert to drm_output_color_format
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
Maxime Ripard [Thu, 5 Mar 2026 09:04:54 +0000 (10:04 +0100)]
drm/edid: Convert to drm_output_color_format enum
Now that we introduced a new drm_output_color_format enum to represent
what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
enum.
The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
drm_output_color_format is a proper enum. However, the enum was done is
such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
the transitition is easier.
The only thing we need to consider is if the original code meant to use
that value as a bitmask, in which case we do need to keep the bit shift,
or as a discriminant in which case we don't.
The EDID parsing code initially introduced the DRM_COLOR_FORMAT_*
defines to represent the sink capabilities. Since a given sink could
support multiple formats, it was first defined as a bitmask.
However, the core and drivers have since leveraged those defines to
represent both the supported formats but also the current format being
used.
Considering the latter case, the more natural, and consistent, thing to
do would be to create an enum of all the possible formats, and then list
the supported formats using a bitmask of the individual enum values.
Let's create a new enum following that pattern, drm_output_color_format,
while maintaining the DRM_COLOR_FORMAT_* compatibility to make the
transition easier.
AKASHI Takahiro [Mon, 23 Mar 2026 19:01:47 +0000 (22:01 +0300)]
gpio: gpio-by-pinctrl: add pinctrl based generic GPIO driver
The ARM SCMI pinctrl protocol allows GPIO access. Instead of creating
a new SCMI GPIO driver, this driver is a generic GPIO driver that uses
standard pinctrl interfaces.
AKASHI Takahiro [Mon, 23 Mar 2026 19:01:42 +0000 (22:01 +0300)]
gpio: dt-bindings: Add GPIO on top of generic pin control
Traditionally, firmware will provide a GPIO interface or a pin control
interface. However, the SCMI protocol provides a generic pin control
interface and the GPIO support is built on top of that using the normal
pin control interfaces. Potentially, other firmware will adopt a
similar generic approach in the future.
Document how to configure the GPIO device.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Dan Carpenter [Mon, 23 Mar 2026 19:01:37 +0000 (22:01 +0300)]
firmware: arm_scmi: Allow PINCTRL_REQUEST to return EOPNOTSUPP
The SCMI protocol specification says that the PINCTRL_REQUEST and
PINCTRL_RELEASE commands are optional. So if the SCMI server returns
-EOPNOTSUPP, then treat that as success and continue.
Dan Carpenter [Mon, 23 Mar 2026 19:01:22 +0000 (22:01 +0300)]
pinctrl: scmi: ignore PIN_CONFIG_PERSIST_STATE
The PIN_CONFIG_PERSIST_STATE setting ensures that the pin state persists
across a sleep or controller reset. The SCMI spec does not have an
equivalent command to this so just ignore it.
Dan Carpenter [Mon, 23 Mar 2026 19:01:32 +0000 (22:01 +0300)]
pinctrl: scmi: Delete PIN_CONFIG_OUTPUT_IMPEDANCE_OHMS support
The argument for PIN_CONFIG_OUTPUT_IMPEDANCE_OHMS is supposed to
be expressed in terms of ohms. But the pinctrl-scmi driver was
implementing it the same as PIN_CONFIG_OUTPUT and writing either a
zero or one to the pin.
The SCMI protocol doesn't have an support configuration type so just
delete this code instead of replacing it.
Cc: Peng Fan <peng.fan@nxp.com> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
Dan Carpenter [Mon, 23 Mar 2026 19:01:15 +0000 (22:01 +0300)]
pinctrl: scmi: Add SCMI_PIN_INPUT_VALUE
The PIN_CONFIG_LEVEL parameter represents the value of the pin, whether
reading or writing to the pin. In SCMI, the parameter is represented by
two different values SCMI_PIN_OUTPUT_VALUE for writing to a pin and
SCMI_PIN_INPUT_VALUE for reading. The current code translates
PIN_CONFIG_LEVEL as SCMI_PIN_OUTPUT_VALUE (writing).
Add a function to translate it to either INPUT or OUTPUT depending on
whether it is called from a _get or _set() operation.
Add APM mailbox clock for communicating between APM and main application
CPUs in CMU_APM unit. This clock is needed to access this mailbox
registers. This mailbox is used for ACPM communication between kernel
and APM co-processor.
Lorenzo Bianconi [Sat, 21 Mar 2026 14:41:44 +0000 (15:41 +0100)]
net: airoha: Rework the code flow in airoha_remove() and in airoha_probe() error path
As suggested by Simon in [0], rework the code flow in airoha_remove()
and in the airoha_probe() error path in order to rely on a more common
approach un-registering configured net-devices first and destroying the
hw resources at the end of the code.
Introduce airoha_qdma_cleanup routine to release QDMA resources.
Besar Wicaksono [Tue, 24 Mar 2026 01:29:51 +0000 (01:29 +0000)]
perf: add NVIDIA Tegra410 C2C PMU
Adds NVIDIA C2C PMU support in Tegra410 SOC. This PMU is
used to measure memory latency between the SOC and device
memory, e.g GPU Memory (GMEM), CXL Memory, or memory on
remote Tegra410 SOC.
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Besar Wicaksono [Tue, 24 Mar 2026 01:29:50 +0000 (01:29 +0000)]
perf: add NVIDIA Tegra410 CPU Memory Latency PMU
Adds CPU Memory (CMEM) Latency PMU support in Tegra410 SOC.
The PMU is used to measure latency between the edge of the
Unified Coherence Fabric to the local system DRAM.
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Besar Wicaksono [Tue, 24 Mar 2026 01:29:49 +0000 (01:29 +0000)]
perf/arm_cspmu: nvidia: Add Tegra410 PCIE-TGT PMU
Adds PCIE-TGT PMU support in Tegra410 SOC. This PMU is
instanced in each root complex in the SOC and it captures
traffic originating from any source towards PCIE BAR and CXL
HDM range. The traffic can be filtered based on the
destination root port or target address range.
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Besar Wicaksono [Tue, 24 Mar 2026 01:29:48 +0000 (01:29 +0000)]
perf/arm_cspmu: nvidia: Add Tegra410 PCIE PMU
Adds PCIE PMU support in Tegra410 SOC. This PMU is instanced
in each root complex in the SOC and can capture traffic from
PCIE device to various memory types. This PMU can filter traffic
based on the originating root port or BDF and the target memory
types (CPU DRAM, GPU Memory, CXL Memory, or remote Memory).
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Besar Wicaksono [Tue, 24 Mar 2026 01:29:47 +0000 (01:29 +0000)]
perf/arm_cspmu: Add arm_cspmu_acpi_dev_get
Add interface to get ACPI device associated with the
PMU. This ACPI device may contain additional properties
not covered by the standard properties.
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Besar Wicaksono [Tue, 24 Mar 2026 01:29:46 +0000 (01:29 +0000)]
perf/arm_cspmu: nvidia: Add Tegra410 UCF PMU
The Unified Coherence Fabric (UCF) contains last level cache
and cache coherent interconnect in Tegra410 SOC. The PMU in
this device can be used to capture events related to access
to the last level cache and memory from different sources.
Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Besar Wicaksono [Tue, 24 Mar 2026 01:29:45 +0000 (01:29 +0000)]
perf/arm_cspmu: nvidia: Rename doc to Tegra241
The documentation in nvidia-pmu.rst contains PMUs specific
to NVIDIA Tegra241 SoC. Rename the file for this specific
SoC to have better distinction with other NVIDIA SoC.
Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Robin Murphy [Thu, 19 Feb 2026 17:27:53 +0000 (17:27 +0000)]
perf/arm-cmn: Stop claiming entire iomem region
So far, the PMU has been the only thing of interest in the vast mass
of CMN registers, so we've gotten away with simply claiming the entire
iomem region. However, now that we can support other features like MPAM
controllers for the system caches, the PMU driver needs to stop being
selfish and learn to share. Similarly to arm-ni, requesting just the
DTC node(s) should suffice for staking our exclusive claim to the PMU
features, as requesting hundreds of tiny regions for all the individual
pmu_event_sel registers is definitely not worth the considerable bother.
As a consequence, we can also streamline the annoying CMN-600 special
cases even more. The ACPI binding has in fact always specified a strict
order for all resources, so we can reasonably drop the ancient pretence
of swapping base and cfg, which IIRC was more just a moment of doubt on
my part than anything else.
Cc: James Morse <james.morse@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Signed-off-by: Will Deacon <will@kernel.org>
James Clark [Thu, 5 Mar 2026 16:28:19 +0000 (16:28 +0000)]
arm64: cpufeature: Use pmuv3_implemented() function
Other places that are doing this version comparison are already using
pmuv3_implemented(), so might as well use it here too for consistency.
Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Colton Lewis <coltonlewis@google.com> Signed-off-by: Will Deacon <will@kernel.org>
James Clark [Thu, 5 Mar 2026 16:28:18 +0000 (16:28 +0000)]
arm64: cpufeature: Make PMUVer and PerfMon unsigned
On the host, this change doesn't make a difference because the fields
are defined as FTR_EXACT. However, KVM allows userspace to set these
fields for a guest and overrides the type to be FTR_LOWER_SAFE. And
while KVM used to do an unsigned comparison to validate that the new
value is lower than what the hardware provides, since the linked commit
it uses the generic sanitization framework which does a signed
comparison.
Fix it by defining these fields as unsigned. In theory, without this
fix, userspace could set a higher PMU version than the hardware supports
by providing any value with the top bit set.
Fixes: c118cead07a7 ("KVM: arm64: Use generic sanitisation for ID_(AA64)DFR0_EL1") Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Colton Lewis <coltonlewis@google.com> Signed-off-by: Will Deacon <will@kernel.org>
James Clark [Thu, 5 Mar 2026 16:28:17 +0000 (16:28 +0000)]
KVM: arm64: Read PMUVer as unsigned
ID_AA64DFR0_EL1.PMUVer is an unsigned field, so this skips
initialization of host_data_ptr(nr_event_counters) for PMUv3 for Armv8.8
onwards as they appear as negative values.
Fix it by reading it as unsigned. Now ID_AA64DFR0_EL1_PMUVer_IMP_DEF
needs to be special cased, so use pmuv3_implemented() which already does
it.
Fixes: 2417218f2f23 ("KVM: arm64: Get rid of __kvm_get_mdcr_el2() and related warts") Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Colton Lewis <coltonlewis@google.com> Signed-off-by: Will Deacon <will@kernel.org>
Kexin Sun [Sat, 21 Mar 2026 10:58:25 +0000 (18:58 +0800)]
net: phy: update outdated comment for removed phy_package_read/write()
The locked convenience functions phy_package_read() and
phy_package_write() were removed (as they had no users) by commit e7f984e925d2 ("net: phy: move PHY package related code from phy.h
to phy_package.c"). Update the comment to reference the existing
unlocked counterparts __phy_package_read() and __phy_package_write().
Kexin Sun [Sat, 21 Mar 2026 10:57:53 +0000 (18:57 +0800)]
hv_sock: update outdated comment for renamed vsock_stream_recvmsg()
The function vsock_stream_recvmsg() was renamed to
vsock_connectible_recvmsg() by commit a9e29e5511b9 ("af_vsock:
update functions for connectible socket"). Update the comment
accordingly.
Johannes Berg [Tue, 24 Mar 2026 09:33:26 +0000 (11:33 +0200)]
wifi: iwlwifi: mld: correctly set wifi generation data
In each MAC context, the firmware expects the wifi generation
data, i.e. whether or not HE/EHT (and in the future UHR) is
enabled on that MAC.
However, this is currently handled wrong in two ways:
- EHT is only enabled when the interface is also an MLD, but
we currently allow (despite the spec) connecting with EHT
but without MLO.
- when HE or EHT are used by TDLS peers, the firmware needs
to have them enabled regardless of the AP
Fix this by iterating setting up the data depending on the
interface type:
- for AP, just set it according to the BSS configuration
- for monitor, set it according to HW capabilities
- otherwise, particularly for client, iterate all stations
and then their links on the interface in question and set
according to their capabilities, this handles the AP and
TDLS peers. Re-calculate this whenever a TDLS station is
marked associated or removed so that it's kept updated,
for the AP it's already updated on assoc/disassoc.
wifi: iwlwifi: mvm: don't send a 6E related command when not supported
MCC_ALLOWED_AP_TYPE_CMD is related to 6E support. Do not send it if the
device doesn't support 6E.
Apparently, the firmware is mistakenly advertising support for this
command even on AX201 which does not support 6E and then the firmware
crashes.
Fixes: 0d2fc8821a7d ("wifi: iwlwifi: nvm: parse the VLP/AFC bit from regulatory") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220804 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260324113316.e171f0163f2a.I0c444d1f82d1773054e7ffc391ad49697d58f44e@changeid
Calculate MLO scan start time based on actual
scan start notification from firmware instead of recording
time when scan command is sent.
Currently, MLO scan start time was captured immediately
after sending the scan command to firmware. However, the
actual scan start time may differ due to the FW being busy
with a previous scan.
In that case, the link selection code will think that the MLO
scan is too old, and will warn.
To fix it, Implement start scan notification handling to
capture the precise moment when firmware begins the scan
operation.
Willem de Bruijn [Fri, 20 Mar 2026 19:01:46 +0000 (15:01 -0400)]
net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback
NETIF_F_IPV6_CSUM only advertises support for checksum offload of
packets without IPv6 extension headers. Packets with extension
headers must fall back onto software checksumming. Since TSO
depends on checksum offload, those must revert to GSO.
The below commit introduces that fallback. It always checks
network header length. For tunneled packets, the inner header length
must be checked instead. Extend the check accordingly.
A special case is tunneled packets without inner IP protocol. Such as
RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by
transport header either, so also must revert to the software GSO path.
Cc: stable@vger.kernel.org Fixes: 864e3396976e ("net: gso: Forbid IPv6 TSO with extensions on devices with only IPV6_CSUM") Reported-by: Tangxin Xie <xietangxin@yeah.net> Closes: https://lore.kernel.org/netdev/0414e7e2-9a1c-4d7c-a99d-b9039cf68f40@yeah.net/ Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260320190148.2409107-1-willemdebruijn.kernel@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* tag 'linux-can-fixes-for-7.0-20260323' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
can: isotp: fix tx.buf use-after-free in isotp_sendmsg()
can: gw: fix OOB heap access in cgw_csum_crc8_rel()
can: statistics: add missing atomic access in hot path
can: mcp251x: add error handling for power enable in open and resume
can: netlink: can_changelink(): add missing error handling to call can_ctrlmode_changelink()
====================
David Carlier [Fri, 20 Mar 2026 17:44:39 +0000 (17:44 +0000)]
net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path
cppi5_hdesc_get_psdata() returns a pointer into the CPPI descriptor.
In both emac_rx_packet() and emac_rx_packet_zc(), the descriptor is
freed via k3_cppi_desc_pool_free() before the psdata pointer is used
by emac_rx_timestamp(), which dereferences psdata[0] and psdata[1].
This constitutes a use-after-free on every received packet that goes
through the timestamp path.
Defer the descriptor free until after all accesses through the psdata
pointer are complete. For emac_rx_packet(), move the free into the
requeue label so both early-exit and success paths free the descriptor
after all accesses are done. For emac_rx_packet_zc(), move the free to
the end of the loop body after emac_dispatch_skb_zc() (which calls
emac_rx_timestamp()) has returned.
Fixes: 46eeb90f03e0 ("net: ti: icssg-prueth: Use page_pool API for RX buffer allocation") Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260320174439.41080-1-devnexen@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Rather than freshly getting a pointer for the TBS descriptor (because
we want to access its enhanced fields) convert the existing first_desc
basic descriptor to a pointer to the enhanced descriptor.
Add a comment explaining why it is safe to convert from the basic
descriptor pointer to the enhanced descriptor pointer.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1w3d0W-0000000DfM7-2BMA@rmk-PC.armlinux.org.uk Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
[pabeni@redhat.com: fixed comment typo] Signed-off-by: Paolo Abeni <pabeni@redhat.com>
net: stmmac: move first xmit descriptor SARC and TBS config
Move the first transmit descriptor's SARC and TBS configuration
alongside the code which populates the first descriptor, which helps
to keep all the code specific to that descriptor together.
The skb head buffer handling is delayed in stmmac_xmit() until after
the skb fragments have been populated into the descriptors. The reason
is this code used to set the OWN bit on the first descriptor, which
then allows the TX DMA to process the first and subsequent descriptors.
However, as of commit 579a25a854d4 ("net: stmmac: Initial support for
TBS") this is now separated, but the comments weren't updated.
Move the code populating the first descriptor along side the jumbo code
which also populates the first descriptor. This gives a consistent
location where we populate the descriptor(s) for the SKB head.
Sakari Ailus [Mon, 16 Mar 2026 21:34:39 +0000 (23:34 +0200)]
media: ov02a10, dw9768: Remove Dongchung's e-mail
Dongchung's e-mail address returns a permanent error:
The following message to <dongchun.zhu@mediatek.com> was
undeliverable. The reason for the problem: 5.1.0 - Unknown address
error 550-'Relaying mail to dongchun.zhu@mediatek.com is not
allowed'
Remove the address.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Tomi Valkeinen [Tue, 17 Mar 2026 12:09:42 +0000 (14:09 +0200)]
media: subdev: Split v4l2_subdev_get_frame_desc_passthrough() into locked and unlocked
The recently added v4l2_subdev_get_frame_desc_passthrough() can be used
directly as an implementation for .get_frame_desc subdev op. However, in
some cases the drivers may want to add some customizations, while the
bulk of the work is still identical to what
v4l2_subdev_get_frame_desc_passthrough() does. Current locking scheme
makes this impossible to do properly.
Split v4l2_subdev_get_frame_desc_passthrough() into two functions:
__v4l2_subdev_get_frame_desc_passthrough(), which takes a locked subdev
state as a parameter, instead of locking and getting the active state
internally. Other than that, it does the same as
v4l2_subdev_get_frame_desc_passthrough() used to do.
v4l2_subdev_get_frame_desc_passthrough(), which locks the active state
and calls __v4l2_subdev_get_frame_desc_passthrough().
In other words, v4l2_subdev_get_frame_desc_passthrough() works as
before, but drivers can now alternatively add custom .get_frame_desc
code and call v4l2_subdev_get_frame_desc_passthrough().
An example use case is with DS90UB953 serializer: in normal use the
serializer passes through everything, but when test-pattern-generator
(TPG) is used, an internal TPG source is used. After this commit, the
UB953 get_frame_desc() can lock the state, look at the routing table to
see if we're in normal or TPG mode, then either call
__v4l2_subdev_get_frame_desc_passthrough() if in normal mode, or
construct a TPG frame desc if in TPG mode.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
[Sakari Ailus: Rebase on an earlier remote source pad error code fix.] Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
projects / thirdparty / kernel / linux.git / log
