Eliot Courtney [Mon, 25 May 2026 13:57:21 +0000 (22:57 +0900)]
gpu: nova-core: vbios: avoid reading too far in read_more_at_offset
Fix bug where `read_more_at_offset` would unnecessarily read more data.
This happens when the window to read has some part cached and some part
not. It would read `len` bytes instead of just the uncached portion,
which could read past `BIOS_MAX_SCAN_LEN`.
Fixes: 6fda04e7f0cd ("gpu: nova-core: vbios: Add base support for VBIOS construction and iteration") Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-3-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Eliot Courtney [Mon, 25 May 2026 13:57:20 +0000 (22:57 +0900)]
gpu: nova-core: vbios: use checked arithmetic for bios image range end
`read_bios_image_at_offset` is called with a length from the VBIOS
header, so we should be more defensive here and use checked arithmetic.
Fixes: 6fda04e7f0cd ("gpu: nova-core: vbios: Add base support for VBIOS construction and iteration") Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-2-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Eliot Courtney [Mon, 25 May 2026 13:57:19 +0000 (22:57 +0900)]
gpu: nova-core: vbios: stop scanning at BIOS_MAX_SCAN_LEN
Current code lets `current_offset` go to `BIOS_MAX_SCAN_LEN` which is
one byte too far.
Fixes: 6fda04e7f0cd ("gpu: nova-core: vbios: Add base support for VBIOS construction and iteration") Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-1-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Ronak Jain [Wed, 20 May 2026 09:36:54 +0000 (02:36 -0700)]
firmware: zynqmp: Add dynamic CSU register discovery and sysfs interface
Add support for dynamically discovering and exposing Configuration
Security Unit (CSU) registers through sysfs. Leverage the existing
PM_QUERY_DATA API to discover available registers at runtime, making
the interface flexible and maintainable.
Key features:
- Dynamic register discovery using PM_QUERY_DATA API
* PM_QID_GET_NODE_COUNT: Query number of available registers
* PM_QID_GET_NODE_NAME: Query register names by index
- Automatic sysfs attribute creation under csu_registers/ group
- Read operations via existing IOCTL_READ_REG API
- Write operations via existing IOCTL_MASK_WRITE_REG API
The sysfs interface is created at:
/sys/devices/platform/firmware:zynqmp-firmware/csu_registers/
The dynamic discovery approach allows firmware to control which
registers are exposed without requiring kernel changes, improving
maintainability and security.
The firmware does not currently expose per-register access mode
information, so the kernel cannot distinguish read-only registers
from read-write ones at discovery time. All discovered registers are
therefore created with sysfs mode 0644, and the firmware is
responsible for rejecting writes to registers it treats as read-only
(for example idcode and pcap-status); that error is propagated back
to userspace from the store callback. If a per-register access-mode
query is added to the firmware in the future, sysfs permissions can
be tightened to match.
CSU register discovery is an optional feature: on firmware that lacks
support for PM_QID_GET_NODE_COUNT or PM_QID_GET_NODE_NAME, the probe
returns gracefully without exposing any sysfs entries. To keep the
memory footprint minimal on that path, partial devm allocations made
during discovery are explicitly released on failure so that no memory
lingers until device unbind when the feature is unavailable.
Read operations use the existing IOCTL_READ_REG firmware interface,
while write operations use IOCTL_MASK_WRITE_REG.
Access control is enforced by the firmware. Write attempts to
read-only registers are rejected by firmware even though the sysfs file
permissions allow writes.
Here is the set of patches, that fixes one of the isssue reported by
Richard Acayan, while doing fix for the reported issue, found various
other issues in the existing code.
This set contains some of those cleanups along with few trivial coding
style patches which looked uncomfortable to read.
Patch 1 should be enough to fix the issue reported.
ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params
Fix error handling in q6asm_dai_compr_set_params() and q6asm_dai_prepare()
for both CMD_CLOSE and q6asm_unmap_memory_regions().
In both the functions, we are doing q6asm_audio_client_free in failure
cases, which means if prepare or set_params fail, we can never recover.
Now open and close are done in respective dai_open/close functions.
ASoC: qcom: q6asm-dai: close stream only when running
q6asm_dai_close() and q6asm_dai_compr_free() currently issue CMD_CLOSE
whenever prtd->state is non-zero.
After prepare() closes an existing stream, the state is updated to
Q6ASM_STREAM_STOPPED. Since this state is also non-zero, the close and
free paths can send CMD_CLOSE again for a stream that has already been
closed.
Restrict CMD_CLOSE to the Q6ASM_STREAM_RUNNING state so the command is
sent only when the ASM stream is still active.
ASoC: qcom: q6asm-dai: do not set stream state in event and trigger callbacks
The q6asm-dai stream state is used by prepare() to decide whether an
existing stream setup needs to be closed before opening/configuring a new
one. Updating the state from trigger or asynchronous DSP callbacks can make
that state stale or incorrect relative to the actual setup lifetime.
In particular, setting Q6ASM_STREAM_STOPPED on STOP or EOS completion can
make prepare() believe there is no active setup to close, which can result
in opening/configuring the same stream more than once.
Keep stream state updates tied to prepare(), where the stream is actually
closed and reopened, and stop changing it from trigger and EOS callbacks.
Fixes: bfbb12dfa144 ("ASoC: qcom: q6asm-dai: perform correct state check before closing") Cc: Stable@vger.kernel.org Closes: https://lore.kernel.org/all/afS7rTHdc9TyIeLx@rdacayan/ Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260518092347.3446946-2-srinivas.kandagatla@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
The MAX98090 codec driver currently exposes a custom
max98090_mic_detect() helper for machine drivers to register a headset
jack.
This series converts the driver to use the standard component
.set_jack callback and updates the mt8173-max98090 machine driver to use
snd_soc_component_set_jack() instead of the codec-specific helper.
Using the standard callback removes the need for a custom exported
symbol and allows machine drivers to use the common ASoC jack
registration interface. This also improves compatibility with machine
drivers, such as Qualcomm platforms, that already rely on
snd_soc_component_set_jack().
ASoC: codecs: max98090: use component set_jack callback
The MAX98090 driver provides a custom max98090_mic_detect() helper for
machine drivers to register a jack.
This can be implemented using the standard component set_jack callback
instead. Doing so allows machine drivers to use
snd_soc_component_set_jack(), which is also the interface used by
machine drivers including Qualcomm ones.
Convert max98090_mic_detect() to a component set_jack callback and remove
the exported helper.
Mark Brown [Mon, 25 May 2026 12:37:18 +0000 (13:37 +0100)]
ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
Chancel Liu <chancel.liu@nxp.com> says:
Some audio systems require specific DAPM widgets to remain powered
during system suspend. Introduce a generic and reusable mechanism in
the ASoC core to mark selected DAPM widgets as ignore_suspend.
The unified mechanism consists of two parts:
1. Parse and store the name list of widgets to ignore suspend in
struct snd_soc_card
The list of widgets can be provided either by the machine driver or
parsed from Device Tree. Different machines have different routing and
power requirements. Each machine can specify its own widgets to ignore
suspend through DT property. It enables flexible policy without hard
code. A new helper, snd_soc_of_parse_ignore_suspend_widgets() is added
for this purpose.
2. Apply ignore_suspend flags during snd_soc_bind_card()
After all components have been probed and all DAPM widgets have been
registered, snd_soc_bind_card() performs a unified lookup of the
configured widget names across all DAPM contexts of the card and marks
the matching widgets with ignore_suspend = 1.
Switch to use core ignore-suspend-widgets support for imx-rpmsg driver.
Chancel Liu (3):
ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts
ASoC: soc-core: Add core support for ignoring suspend on selected DAPM
widgets
ASoC: fsl: imx-rpmsg: Switch to core ignore-suspend-widgets support
Chancel Liu [Thu, 7 May 2026 01:36:54 +0000 (10:36 +0900)]
ASoC: fsl: imx-rpmsg: Switch to core ignore-suspend-widgets support
The imx-rpmsg machine driver currently implements its own logic to
parse ignore-suspend-widgets from Device Tree and manually traverse
DAPM widgets to mark them as ignore_suspend.
It also has a potential issue that some widgets listed in the property
(e.g. "Headphone Jack") belong to card or CPU DAI DAPM context.
Switch to use snd_soc_of_parse_ignore_suspend_widgets() with the
introduction of a generic ignore-suspend-widgets mechanism in the ASoC
core.
Chancel Liu [Thu, 7 May 2026 01:36:53 +0000 (10:36 +0900)]
ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
Some audio systems require specific DAPM widgets to remain powered
during system suspend. Introduce a generic and reusable mechanism in
the ASoC core to mark selected DAPM widgets as ignore_suspend.
The unified mechanism consists of two parts:
1. Parse and store the name list of widgets to ignore suspend in
struct snd_soc_card
The list of widgets can be provided either by the machine driver or
parsed from Device Tree. Different machines have different routing and
power requirements. Each machine can specify its own widgets to ignore
suspend through DT property. It enables flexible policy without hard
code. A new helper, snd_soc_of_parse_ignore_suspend_widgets() is added
for this purpose.
2. Apply ignore_suspend flags during snd_soc_bind_card()
After all components have been probed and all DAPM widgets have been
registered, snd_soc_bind_card() performs a unified lookup of the
configured widget names across all DAPM contexts of the card and marks
the matching widgets with ignore_suspend = 1.
Chancel Liu [Thu, 7 May 2026 01:36:52 +0000 (10:36 +0900)]
ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts
Currently dapm_find_widget() manually constructs a prefixed widget name
based on the provided DAPM context and compares it using strcmp(). This
happens to work in most cases because callers usually know which DAPM
context the target widget belongs to and pass in the matching DAPM
context.
However, this assumption breaks when search_other_contexts is enabled.
In such cases, callers may intentionally pass a different DAPM context,
while searching for a widget that actually belongs to another DAPM
context.
For example, when searching for a "DAC" widget, the widget belongs to
the codec DAPM and be registered with a codec prefix, while the caller
passes card->dapm and intends to search across all DAPM contexts. The
current implementation incorrectly applies the caller card DAPM causing
the lookup to fail even though the widget exists on the card.
Improve the matching strategy to support both use cases:
1. When the caller provides a fully qualified name with prefix, perform
exact string matching. This preserves the ability to use prefixes for
disambiguation.
2. When the caller provides a bare widget name without prefix, try exact
matching first, then fall back to prefix-stripped comparison using
snd_soc_dapm_widget_name_cmp().
To determine whether the pin name includes a prefix, a new helper
function snd_soc_dapm_pin_has_prefix() is introduced. It checks if the
pin name starts with any known component prefix on the card.
This fixes widget lookup failures when searching across different DAPM
contexts while maintaining backward compatibility for explicitly
prefixed lookups.
Fixes: ae4fc532244b ("ASoC: dapm: use component prefix when checking widget names") Signed-off-by: Chancel Liu <chancel.liu@nxp.com> Assisted-by: Cody:Claude-4.5-Sonnet Link: https://patch.msgid.link/20260507013654.2945915-2-chancel.liu@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
Cássio Gabriel [Tue, 19 May 2026 16:51:47 +0000 (13:51 -0300)]
ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors
byt_cht_es8316_init() enables MCLK before configuring the codec sysclk
and creating the headset jack. If either of those later steps fails, the
function returns without disabling MCLK, leaving the clock enabled after
card registration fails.
Track whether this driver enabled MCLK and disable it on the init error
paths. Add the matching DAI link exit callback so the same clock enable
is also balanced when ASoC cleans up a successfully initialized link.
Imre Deak [Fri, 22 May 2026 16:05:14 +0000 (19:05 +0300)]
drm/i915/dp: Detect changes in common link parameters
Detect DPRX capability changes without a long HPD or RX_CAP_CHANGED
signal and queue a corresponding link params reset.
Besides detecting the above unexpected capability changes, this also
avoids races between queuing and handling a deferred link params reset.
v2: (Ville)
- Query/set intel_dp::reset_link_params instead of using helpers for
these.
- Assert matching types for old/new common rate elements as well.
- Add TODO: for adding a struct tracking both rates and number of rates.
Imre Deak [Fri, 22 May 2026 16:05:13 +0000 (19:05 +0300)]
drm/i915/dp: Cache max common lane count
Cache the maximum common lane count together with the common link
rates.
This is safe because the cached value is updated:
- during driver probe, before the connector is registered and can be
used for mode validation or modesetting
- during resume, before output HW state readout can query it
- during connector detection, right after updating the sink/link
capabilities
Caching the value allows detecting max common lane count changes in
a follow-up change and keeps the tracking of max common lane count
aligned with that of common rates.
Imre Deak [Fri, 22 May 2026 16:05:11 +0000 (19:05 +0300)]
drm/i915/dp: Reset link params after a DPRX capability change
There is no reason to distinguish between DPRX capability changes
signaled via a long HPD and via an RX_CAP_CHANGED HPD IRQ.
Both cases result in reading out the DPRX capabilities and updating the
corresponding sink and common capabilities cached in intel_dp, however
only the long HPD resets the link training/recovery state and MST link
probe parameters correspondingly. The link training/recovery state may
contain reduced maximum link rate/lane count values left over from a
previous link training failure.
Based on the above after an RX_CAP_CHANGED increased the link rate, lane
count parameters the maximum link rate/lane count in the link
training/recovery state may remain below these, leaving the newly added
valid configurations unavailable for subsequent modesets in an
inconsistent way.
Handle RX_CAP_CHANGED IRQs the same way as long HPDs and reset the link
recovery state and MST link probe parameters in that case as well.
v2: Set intel_dp::reset_link_params instead of using a helper for this.
(Ville).
- Drop CONFIG_MPLS_IPTUNNEL=m (depends on LWTUNNEL, which is no longer
auto-enabled since since commit 309b905deee59561 ("ipv6: convert
CONFIG_IPV6 to built-in only and clean up Kconfigs")),
- Drop CONFIG_HID_ITE=n and CONFIG_HID_REDRAGON=n (disabled by default
since commit 3d39be2a76d1dfed ("HID: drop 'default !EXPERT' from
tristate symbols")),
- Enable modular build of the CMAC, MD5, SHA-512, and SHA-3 algorithms
(no longer auto-enabled since commits 4c1c07820a0e4d82 ("smb:
client: Remove obsolete cmac(aes) allocation"), 7aa0f56d4b48fb1a
("scsi: iscsi_tcp: Remove unneeded selections of CRYPTO and
CRYPTO_MD5"), commit 4061bc8c03975e64 ("crypto: rng - Don't pull in
DRBG when CRYPTO_FIPS=n"), resp. ce260754bb435aea ("crypto:
jitterentropy - Use SHA-3 library")),
- Drop CONFIG_CRYPTO_DRBG_HASH=y and CONFIG_CRYPTO_DRBG_CTR=y (depend
on CRYPTO_DRBG_MENU, which is no longer auto-enabled since commit 4061bc8c03975e64 ("crypto: rng - Don't pull in DRBG when
CRYPTO_FIPS=n")),
- Enable modular build of all CRC functions and crypto library code
for KUnit tests,
- Enable benchmarking in the (modular) string functions KUnit test,
- Enable modular build of the new test module for stress/performance
analysis of workqueue.
Berkant Koc [Sat, 23 May 2026 13:27:47 +0000 (15:27 +0200)]
drm/hyperv: validate VMBus packet size in receive callback
hyperv_receive_sub() reads msg->vid_hdr.type and dispatches into one
of four message-type branches without knowing how many bytes the host
wrote into hv->recv_buf. The completion path then runs
memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE), so the consumer that
wakes on wait_for_completion_timeout() can read up to 16 KiB of
residue from a prior message as if it were the response payload.
Pass bytes_recvd into hyperv_receive_sub() and reject any packet that
does not cover the pipe + synthvid header. A single switch on
msg->vid_hdr.type then computes the type-specific payload size: the
three completion-driving types (SYNTHVID_VERSION_RESPONSE,
SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) fall through
to a shared exit that requires that size before memcpy/complete, while
SYNTHVID_FEATURE_CHANGE validates its own payload and returns before
reading is_dirt_needed. Unknown types are dropped.
SYNTHVID_RESOLUTION_RESPONSE is variable length: the host fills
resolution_count entries, not the full SYNTHVID_MAX_RESOLUTION_COUNT
array. Validate the fixed prefix first so resolution_count can be
read, bound it against the array, then require only the count-sized
array, so the shorter responses the host actually sends are accepted.
Only run the sub-handler when vmbus_recvpacket() returned success. The
memcpy length is bytes_recvd, which is bounded by VMBUS_MAX_PACKET_SIZE
only on a successful receive; on -ENOBUFS vmbus_recvpacket() instead
reports the required length, which can exceed hv->recv_buf, so copying
bytes_recvd would read and write past the 16 KiB buffers. Gating on the
success return keeps the copy bounded. The nonzero-return path is itself
a malformed-message case and is now logged rather than silently skipped;
channel recovery is not attempted.
Rejected packets are reported via drm_err_ratelimited() rather than
silently dropped, matching the CoCo-hardened pattern in
hv_kvp_onchannelcallback().
Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Berkant Koc <me@berkoc.com> Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/8200dbc199c7a9b75ac7e8af6c748d2189b5ebd5.1779542874.git.me@berkoc.com
Berkant Koc [Tue, 19 May 2026 20:08:17 +0000 (22:08 +0200)]
drm/hyperv: validate resolution_count and fix WIN8 fallback
A SYNTHVID_RESOLUTION_RESPONSE with resolution_count > 64 walks past
the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the
parse loop. Bound resolution_count against the array size, folded
into the existing zero-check.
When the WIN10 resolution probe fails, the caller in
hyperv_connect_vsp() left hv->screen_*_max / preferred_* unpopulated,
which sets mode_config.max_width / max_height to 0 and makes
drm_internal_framebuffer_create() reject every userspace framebuffer
with -EINVAL. The pre-WIN10 branch had the same gap for
preferred_width / preferred_height. Use a single post-probe fallback
guarded by screen_width_max == 0 so both paths converge on the WIN8
defaults.
Signed-off-by: Berkant Koc <me@berkoc.com> Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Cc: stable@vger.kernel.org # 5.14+ Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/6945b22419c7d404b4954a113de2ac9c900dba93.1779542874.git.me@berkoc.com
On some SoCs (e.g. SpacemiT K3), multiple I2S controllers share the
same physical BCLK. When one controller is already streaming, the
others must use hw_params that result in the same BCLK rate, otherwise
the shared clock would be reconfigured and corrupt the active stream.
This series adds framework-level support for this constraint:
Patch 1 adds the dt-bindings for the spacemit,k3-i2s compatible.
The K3 SoC uses the same I2S IP as K1 but requires additional clocks:
a dedicated sysclk_div, along with c_sysclk and c_bclk which are
shared across multiple I2S controllers.
Patch 2 adds a DEFINE_GUARD wrapping snd_soc_card_mutex_lock() and
snd_soc_card_mutex_unlock() so that scope-based locking picks up the
SND_SOC_CARD_CLASS_RUNTIME lockdep subclass.
Patch 3 adds the constraint logic in soc-pcm.c. During PCM open,
every DAI that has a bclk clock pointer gets a hw_rule registered
unconditionally. The rule callback runs at hw_refine time: it scans
the card for an active peer sharing the same physical BCLK (via
clk_is_match()) that has already completed hw_params, then constrains
the current stream's rate to match the established BCLK rate. The
first DAI to complete hw_params is unconstrained; subsequent DAIs
must match. Two modes are supported:
- Default (I2S): BCLK = rate * channels * sample_bits. The rule
derives the valid rate range from the current channel and
sample_bits intervals.
- Explicit ratio (TDM): if the driver sets dai->bclk_ratio
(e.g. slots * slot_width), the rule computes the single valid
rate as active_bclk_rate / bclk_ratio.
This series was prompted by review feedback on the SpacemiT K3 I2S
series, where a vendor-specific fixed-sample-rate property was rejected
in favor of a generic framework solution:
https://lore.kernel.org/all/afFqgF6ZRwYdfUmL@sirena.co.uk/
Troy Mitchell [Fri, 22 May 2026 13:33:59 +0000 (21:33 +0800)]
ASoC: soc-pcm: constrain hw_params when DAIs share the same BCLK
When multiple CPU DAIs on the same sound card share the same physical
BCLK, add a hw_rule during PCM open that constrains the sample rate so
the resulting BCLK rate stays consistent across all sharing DAIs.
The rule callback scans all DAIs on the card at hw_refine time, looking
for an active peer that shares the same physical BCLK (via
clk_is_match()) and has already completed hw_params (checked via
dai->symmetric_rate != 0). This ensures the constraint uses the real
BCLK rate established by the peer's clk_set_rate() in hw_params, not a
stale boot-time default.
The first DAI to complete hw_params is unconstrained (no active peer
yet); subsequent DAIs are constrained to match.
The rule supports two modes:
- If the DAI has an explicit bclk_ratio set (e.g. for TDM where
BCLK = rate * slots * slot_width), the rate is constrained to
active_bclk_rate / bclk_ratio.
- Otherwise, the default formula BCLK = rate * channels * sample_bits
is used to derive the valid rate range.
The constraint is purely additive: DAIs that do not set a bclk clock
pointer are completely unaffected.
Troy Mitchell [Fri, 22 May 2026 13:33:58 +0000 (21:33 +0800)]
ASoC: soc-pcm: add DEFINE_GUARD for snd_soc_card_mutex
Define a guard class wrapping snd_soc_card_mutex_lock() and
snd_soc_card_mutex_unlock() so that scope-based locking can be used
while still picking up the SND_SOC_CARD_CLASS_RUNTIME lockdep subclass.
Troy Mitchell [Fri, 22 May 2026 13:33:57 +0000 (21:33 +0800)]
ASoC: soc-dai: add shared BCLK clock for cross-DAI rate constraints
Add a bclk field to struct snd_soc_dai and a helper function
snd_soc_dai_set_bclk_clk() that platform drivers can use to declare
which clock is their BCLK.
Also cache the bclk_ratio in snd_soc_dai_set_bclk_ratio() so that
the framework can use it later in hw_rule evaluation for TDM
configurations where BCLK = rate * slots * slot_width.
When multiple DAIs on the same card share the same physical BCLK
(detected via clk_is_match()), the ASoC core can automatically
constrain their hw_params so that the resulting BCLK rates are
compatible. This commit adds the data structure support; the actual
constraint logic follows in the next patch.
Ankit Nautiyal [Sun, 17 May 2026 14:27:53 +0000 (19:57 +0530)]
drm/i915/psr: Allow SCL=0 on platforms with always-on VRR TG
For Legacy timing generator, if there are no panel replay/sel_update or
other SRD constraints, the Set context latency (SCL) window should be
at least 1.
However, for VRR timing generator the SCL window can be 0. It has other
guardband constraints, but that are checked during guardband computation.
Allow SCL to be 0 for platforms that have VRR TG always on.
Marek Vasut [Mon, 4 May 2026 14:43:27 +0000 (16:43 +0200)]
soc: renesas: Identify R-Car R8A779MD M3Le SoC
Add support for identifying the R-Car M3Le (R8A779MD) SoC.
The Renesas R-Car R8A779MD M3Le SoC is a variant of the already
supported R-Car M3-N SoC with reduced peripherals.
Enable support for the M3Le SoC through already existing ARCH_R8A77965
configuration symbol. PRR reads 0x67c05501.
Jouni Högander [Tue, 12 May 2026 08:00:22 +0000 (11:00 +0300)]
drm/i915/display: Handle odd position for planar formats in selective fetch
Since Lunarlake there is no restriction planar planes has to be even
positions. Due to this we may end up having odd offset for UV-plane in
selective fetch configuration. Add handling for this case into selective
fetch configuration.
Jouni Högander [Wed, 20 May 2026 10:49:44 +0000 (13:49 +0300)]
drm/i915/psr: Use DC_OFF wake reference to block DC6 on vblank enable
We are observing following warnings:
*ERROR* power well DC_off state mismatch (refcount 0/enabled 1)
gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE
as DC_OFF power well being enabled. Fix this by using wakeref for the
purpose.
To achieve this we need to modify notification code as well. Currently it
is possible that PSR gets notified vblank enable/disable twice on same
status. This is currently not a problem as it is just triggering call to
intel_display_power_set_target_dc_state with same target state as a
parameter. When using wakeref this becomes a problem due to reference
counting. Fix this storing vbank status on last notification and use that
to ensure there are no more than one notification with same vblank status.
v2: ensure there is no subsequent notifications with same status
Fixes: aa451abcffb5 ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Cc: <stable@vger.kernel.org> # v6.13+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-2-jouni.hogander@intel.com
Jouni Högander [Wed, 20 May 2026 10:49:43 +0000 (13:49 +0300)]
drm/i915/psr: Block DC states on vblank enable when Panel Replay supported
Currently we are blocking DC states only when Panel Replay is enabled on
vblank enable. It may happen that Panel Replay is getting enabled when
vblank is already enabled. Fix this by blocking DC states always if Panel
Replay is supported.
While at it take care of possible dual eDP case by looping all encoders
supporting PSR.
Fixes: 0c427ac78a1d ("drm/i915/psr: Add interface to notify PSR of vblank enable/disable") Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-1-jouni.hogander@intel.com
Thomas Hellström [Wed, 20 May 2026 10:16:16 +0000 (12:16 +0200)]
drm/exec, drm/xe, drm/amdgpu: Add an accessor for struct drm_exec::ticket
Drivers were accessing this drm_exec member directly.
While that may seem harmless, it will require action if
the drm_exec utility is made a subclass of a dma-resv transaction
utility as outlined in the cover-letter.
Provide an accessor, drm_exec_ticket() to avoid that.
Thomas Hellström [Wed, 20 May 2026 10:16:15 +0000 (12:16 +0200)]
drm/exec, drm/xe: Avoid abusing the drm_exec retry pointer
The xe driver was using the drm_exec retry pointer directly to
restart the locking loop after out-of-memory errors. This is
relying on undocumented behaviour.
Instead add a drm_exec_retry() macro that can be used in this
situation, and that also warns if the struct drm_exec is
not newly (re-)initialized.
Use that macro in xe.
v2:
- Only allow if the drm_exec context is newly initialized.
(Christian)
Thomas Hellström [Wed, 20 May 2026 10:16:13 +0000 (12:16 +0200)]
drm/exec: Remove the index parameter from drm_exec_for_each_locked_obj[_reverse]
Nobody makes any use of it. Possible internal future users can
instead use the _index variable. External users shouldn't use
it since the array it's pointing into is internal drm_exec state.
v2:
- Use a unique id for the loop variable (Christian)
Thomas Gerner [Thu, 14 May 2026 18:32:01 +0000 (20:32 +0200)]
riscv: dts: thead: Enable wifi on the BeagleV-Ahead
The BeagleV-Ahead board uses an AP6203BM WiFi chip from AMPAK Technology
Inc. connected to SDIO1. The chip is compatible to the broadcom wireless
driver.
The AP6203BM is a dual-band 2.4GHz/5GHz Wi-Fi 4 (802.11a/b/g/n) and
Bluetooth 5.4 module. Bluetooth is not enabled by this patch.
Signed-off-by: Thomas Gerner <thomas.gerner@muenchen-mail.de> Signed-off-by: Drew Fustini <fustini@kernel.org>
MoeLeak [Fri, 8 May 2026 11:44:14 +0000 (19:44 +0800)]
riscv: dts: thead: Enable WiFi on Lichee Pi 4A
The Lichee Pi 4A has an RTL8723DS WiFi module connected to the TH1520
SDIO1 controller. The module reset line is driven through a PCA9557 GPIO
expander on the I2C1 bus.
Enable I2C1 for the GPIO expander and configure SDIO1 as a non-removable
4-bit SDIO bus using an mmc-pwrseq-simple reset sequence so the WiFi
device can be powered and enumerated.
Karol Wachowski [Fri, 22 May 2026 09:32:09 +0000 (11:32 +0200)]
accel/ivpu: Document why full JSM message size is always used
Firmware expects IPC messages to always carry the full fixed
sizeof(struct vpu_jsm_msg) size. Sending the full struct also
ensures unused fields are zeroed, which maintains compatibility
when existing commands are extended with new fields in the future.
Replace the misleading TODO comment with an explanation of the
actual intent.
ACPI: button: Add missing device class clearing on probe failures
Commit e18947038bf4 ("ACPI: driver: Do not set acpi_device_class()
unnecessarily") modified acpi_button_remove() to clear the device class
field in struct acpi_device on driver removal, but it should also have
updated the rollback path in acpi_button_probe(), which it didn't do,
so do it now.
Fixes: e18947038bf4 ("ACPI: driver: Do not set acpi_device_class() unnecessarily") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/6167713.MhkbZ0Pkbq@rafael.j.wysocki
ACPI: button: Enable wakeup GPEs for ACPI buttons at probe time
Prior to commit 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake()
for buttons"), ACPI button wakeup GPEs having handler methods remained
enabled after acpi_wakeup_gpe_init(), but currently they are not enabled
because acpi_setup_gpe_for_wake() disables them.
That causes function keys to stop working on some systems [1] and there
may be other related issues elsewhere.
To address that, make the ACPI button driver enable wakeup GPEs for ACPI
buttons so long as they have handler methods. While this does not
restore the old behavior exactly (the ACPI button driver needs to be
bound to the button devices for the GPEs to be enabled), it should be
sufficient to restore the missing functionality.
For this purpose, introduce acpi_enable_gpe_cond() that enables
a GPE if its dispatch type matches the supplied one and modify
acpi_button_probe() to use that function for enabling the GPEs in
question.
Fixes: 57c31e6d620f ("ACPI: scan: Use acpi_setup_gpe_for_wake() for buttons") Reported-by: Nick <nick@kousu.ca> Closes: https://lore.kernel.org/linux-acpi/E2OXET.4X5GTP37VTNC3@kousu.ca/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Nick <nick@kousu.ca> Cc: 7.0+ <stable@vger.kernel.org> # 7.0+ Link: https://patch.msgid.link/9629117.CDJkKcVGEf@rafael.j.wysocki
ACPI: button: Fix ACPI GPE handler leak during removal
Commit a7e23ec17fee ("ACPI: button: Install notifier for system events
as well") changed the ACPI notify handler type for ACPI buttons to
ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect
that change. This leads to leaking the notify handler past driver
removal, which may cause a kernel crash to occur if ACPI notify on
the given device is triggered after removing the driver, and causes a
subsequent probe of the given device with the same driver to fail.
Address this by updating the acpi_remove_notify_handler() call in
acpi_button_remove() as appropriate.
Fixes: a7e23ec17fee ("ACPI: button: Install notifier for system events as well") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Cc: 6.15+ <stable@vger.kernel.org> # 6.15+ Link: https://patch.msgid.link/7954431.EvYhyI6sBW@rafael.j.wysocki
Judith Mendez [Wed, 13 May 2026 23:11:54 +0000 (18:11 -0500)]
pinctrl: mcp23s08: Read spi-present-mask as u8 not u32
The binding (microchip,mcp23s08) specifies microchip,spi-present-mask
as uint8, but driver would read u32, causing type mismatch. Use
device_property_read_u8 to match binding spec, hardware (8 chips max),
& prevent probe failure.
Judith Mendez [Wed, 13 May 2026 23:11:53 +0000 (18:11 -0500)]
pinctrl: mcp23s08: Initialize mcp->dev and mcp->addr before regmap init
Regmap initialization triggers regcache_maple_populate() which attempts
SPI read to populate cache. SPI read requires mcp->dev and mcp->addr to
be set, without them, NULL pointer dereference occurs during probe.
Move initialization before mcp23s08_spi_regmap_init() call.
Cc: stable@vger.kernel.org Fixes: f9f4fda15e72 ("pinctrl: mcp23s08: init reg_defaults from HW at probe and switch cache type") Signed-off-by: Judith Mendez <jm@ti.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Len Bao [Sun, 24 May 2026 16:52:48 +0000 (16:52 +0000)]
ALSA: drivers: Mark some variables as __ro_after_init
Some variables in the 'ALSA/drivers' are initialized only during the
init phase in the '__init' functions and never changed. So, mark them
as __ro_after_init to reduce the attack surface.
Len Bao [Sun, 24 May 2026 16:29:13 +0000 (16:29 +0000)]
ALSA: core: Mark some variables as __ro_after_init
Some variables in the 'ALSA/core' are initialized only during the init
phase in the '__init' functions and never changed. So, mark them as
__ro_after_init to reduce the attack surface.
Len Bao [Sun, 24 May 2026 15:40:49 +0000 (15:40 +0000)]
ALSA: isa: Mark '*_registered' variables as __ro_after_init
The '*_registered' variables are initialized only during the init
phase in the '__init' functions and never changed. So, mark them as
__ro_after_init to reduce the attack surface.
ALSA: hda/realtek: Limit mic boost on Positivo DN140
The internal mic boost on the Positivo DN140 is too high.
Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine
to limit the gain.
ALSA: scarlett2: Fix 2i2 Gen 4 direct monitor gain on firmware 2417
Firmware 2417 for the Scarlett 4th Gen 2i2 moved the direct monitor
gain parameter by 4 bytes, from offset 0x2a0 to 0x2a4, breaking the
"Direct Monitor X Mix Y" controls.
Special-case the offset in the get/set config helpers when the
running firmware is 2417 or later.
Fixes: 4e809a299677 ("ALSA: scarlett2: Add support for Solo, 2i2, and 4i4 Gen 4") Cc: <stable@vger.kernel.org> Signed-off-by: Geoffrey D. Bennett <g@b4.vu> Link: https://patch.msgid.link/ahIWTueUlWA5xiV+@m.b4.vu Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cássio Gabriel [Sat, 23 May 2026 01:09:40 +0000 (22:09 -0300)]
ALSA: pcm: oss: Fix setup list UAF on proc write error
snd_pcm_oss_proc_write() links a newly allocated setup entry into the
OSS setup list before duplicating the task name. If the task-name
allocation fails, the error path frees the already linked entry and
leaves setup_list pointing at freed memory.
A later OSS device open can then walk the stale list entry in
snd_pcm_oss_look_for_setup() and dereference freed memory.
Allocate the task name and initialize the setup entry before publishing
the entry on setup_list. Also fetch the initial proc read iterator only
after taking setup_mutex, so all setup_list traversal follows the same
list lifetime rules.
Cássio Gabriel [Fri, 22 May 2026 12:49:30 +0000 (09:49 -0300)]
ALSA: hda: cs35l56: Fix system name string leaks
cs35l56_hda_read_acpi() gets an allocated ACPI _SUB string from
acpi_get_subsystem_id(). On success, that string is used to create the
firmware system name.
Several error paths after the _SUB lookup can return without releasing
the allocated string. This includes speaker ID lookup errors other than
-ENOENT, and errors after a firmware system name has been allocated.
Use scoped cleanup for the temporary _SUB string and make
cs35l56->system_name device-managed. This releases the temporary _SUB
string on every error path and lets devres release the firmware system
name on probe failure and device removal.
Fixes: 6f03b446cbae ("ALSA: hda: cs35l56: Add support for speaker id") Fixes: 40b1c2f9b299 ("ALSA: hda/cs35l56: Workaround bad dev-index on Lenovo Yoga Book 9i GenX") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260522-alsa-cs35l56-system-name-leak-v4-1-a6154dd09cd9@gmail.com
Kris Kater [Fri, 22 May 2026 06:09:02 +0000 (08:09 +0200)]
ALSA: hda/realtek: Add HDA_CODEC_QUIRK for Lenovo Yoga Slim 7 14AGP11
The BIOS on the Lenovo Yoga Slim 7 14AGP11 (AMD Ryzen AI / Kraken
Point chassis; board LNVNB161216, product 83QS) programs the PCI
subsystem ID of the HDA function as 17aa:0000. As a result no entry
in alc269_fixup_tbl[] matches via SND_PCI_QUIRK, the fixup falls back
to the generic auto-routing path, and the bass speaker pin is left
mis-routed. Laptop speakers sound noticeably thin.
The codec's own internal subsystem ID register reports 0x17aa394c
correctly, so an HDA_CODEC_QUIRK entry (which matches on the codec
SSID rather than on the PCI SSID) binds the chassis to the existing
ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN fixup. This mirrors the same
workaround already in place for the closely-related Yoga 7 2-in-1
14AKP10 and 16AKP10 entries earlier in the table.
With this change the kernel log goes from
ALC287: picked fixup for PCI SSID 17aa:0000
to
ALC287: picked fixup alc287-yoga9-bass-spk-pin
and speaker routing matches what the firmware intended. Verified by
the reporter against the equivalent modprobe override
(model=,alc287-yoga9-bass-spk-pin).
Zhang Heng [Fri, 22 May 2026 06:07:42 +0000 (14:07 +0800)]
ALSA: hda/realtek: Fix incorrect comment for ALC299_FIXUP_PREDATOR_SPK
The comment for the pin configuration 0x21 in the fixup
ALC299_FIXUP_PREDATOR_SPK states "use as headset mic, without its own
jack detect", but the fixup name and the actual usage indicate that the
pin is meant to be used as internal speaker. Correct the comment to
avoid confusion.
The register DSP event queue is updated under parser->lock, but
snd_motu_register_dsp_message_parser_count_event() reads pull_pos and
push_pos without the lock.
snd_motu_register_dsp_message_parser_copy_event() also reads both queue
positions before taking the lock.
Protect these accesses with parser->lock as well. This keeps the hwdep
poll/read path consistent with the producer side and with the cached
meter/parameter accessors.
Fixes: 634ec0b2906e ("ALSA: firewire-motu: notify event for parameter change in register DSP model") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20260521-alsa-firewire-motu-event-locking-v1-1-708e1c2b5e56@gmail.com
Commit 792d2b9a1259 ("drm: drop mtrr from i915"), added this comment,
drop it since it since MTRR no longer exists since 2013 and is removed
by commit 281856477cda ("drm: rip out drm_core_has_MTRR checks").
Luka Gejak [Mon, 18 May 2026 14:23:11 +0000 (16:23 +0200)]
wifi: rtw88: usb: fix memory leaks on USB write failures
When rtw_usb_write_port() fails to submit a USB Request Block (URB)
(e.g., due to device disconnect or ENOMEM), the completion callback is
never executed.
Currently, the driver ignores the return value of rtw_usb_write_port()
in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these
functions rely on the completion callback to free the socket buffers
(skbs) and the transaction control block (txcb), a submission failure
results in:
1. A memory leak of the allocated skb in rtw_usb_write_data().
2. A memory leak of the txcb structure and all aggregated skbs in
rtw_usb_tx_agg_skb().
Fix this by checking the return value of rtw_usb_write_port(). If it
fails, explicitly free the skb in rtw_usb_write_data(), and properly
purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb().
The issue was discovered in practice during device disconnect/reconnect
scenarios and memory pressure conditions. Tested by verifying normal TX
operation continues after the fix without regressions.
Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260518142311.10328-2-luka.gejak@linux.dev
Luka Gejak [Mon, 18 May 2026 14:23:10 +0000 (16:23 +0200)]
wifi: rtw88: increase TX report timeout to fix race condition
The driver expects the firmware to report TX status within 500ms.
However, a timeout can be triggered when the hardware performs
background scans while under TX load. During these scans, the firmware
stays off-channel for periods exceeding 500ms, delaying the delivery of
TX reports back to the driver.
When this occurs, the purge timer fires prematurely and drops the
tracking skbs from the queue. This results in the host stack
interpreting the missing status as packet loss, leading to TCP window
collapse. In testing with iperf3, this causes throughput to drop from
~90 Mbps to near-zero for approximately 2 seconds until the connection
recovers.
Increase RTW_TX_PROBE_TIMEOUT to 2500ms for RTL8723DU. This duration is
sufficient to accommodate off-channel dwell time during full background
scans, ensuring the purge timer only trips during genuine firmware
lockups and preventing unnecessary TCP retransmission cycles.
Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Luka Gejak <luka.gejak@linux.dev> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260518142311.10328-1-luka.gejak@linux.dev
Ping-Ke Shih [Fri, 15 May 2026 01:44:33 +0000 (09:44 +0800)]
wifi: rtw89: 8922d: add quota for RTL8922DE variant
The existing quota set is for RTL8922DE-VS, so rename the existing tables.
Add new quota set for RTL8922DE, containing more memory to yield better
performance, so rearrange quota accordingly.
Ping-Ke Shih [Fri, 15 May 2026 01:44:32 +0000 (09:44 +0800)]
wifi: rtw89: mac: consolidate quota into a struct for variant chips
RTL8922D has many variants, using different quota tables. Consolidate the
quota data into a struct, and then select corresponding table for the
chip variant.
Po-Hao Huang [Fri, 15 May 2026 01:44:29 +0000 (09:44 +0800)]
wifi: rtw89: correct drop logic for malformed AMPDU frames
The previous commit aims to fix issue caused by malformed AMPDU frames.
But the drop logic fails to deal with the first AMPDU packet paired with
certain range of sequence number, and leads to unexpected packet drop.
It is more likely to encounter this failure when there are busy traffic
during rekey process and could lead to disconnection from the AP.
Fix this by adding a initial state judgement and only reset status
during pairwise rekey.
Chin-Yen Lee [Fri, 15 May 2026 01:44:28 +0000 (09:44 +0800)]
wifi: rtw89: wow: send ARP reply packets instead of Null packets to keep alive
In WoWLAN mode, the firmware periodically sends Null packets to the AP
to keep the connection alive and prevent the AP from disconnecting the
client due to inactivity. However, it was observed that certain APs,
such as TP-Link Archer BE800, do not recognize Null packets as
valid activity and still drop the connection. Replacing Null packets
with ARP reply packets effectively resolves this compatibility issue
and maintains the connection.
Specifically, while the firmware typically handles standard ARP
offloads by dynamically modifying target IP/MAC fields, these
keep-alive ARP reply packets are pre-filled by the driver with the
DUT's own MAC and IP addresses for both sender and target fields.
In this case, the firmware transmits the packets as-is without
further modification. This approach ensures compatibility with APs
that require valid Layer 3 traffic for activity monitoring while
simplifying the firmware's processing logic during WoWLAN mode.
Dian-Syuan Yang [Fri, 15 May 2026 01:44:24 +0000 (09:44 +0800)]
wifi: rtw89: pci: enable LTR based on pcie control register
Originally, driver always transmits LTR (Latency Tolerance Reporting) to
pcie host, but it may cause pcie link down on some platforms because
LTR is not supported. As a result, driver will check the control
register of LTR setting to decide whether to enable LTR feature.
This applies to Wi-Fi 6 chips only. For Wi-Fi 7 chips, although the
driver still issues LTR, the hardware has its own internal logic
to determine whether to actually transmit it to pcie host.
Zong-Zhe Yang [Fri, 15 May 2026 01:44:23 +0000 (09:44 +0800)]
wifi: rtw89: fw: dump status of H2C command and C2H event for SER
When SER (system error recovery) happens, there may be some handshake
between FW and SW, e.g. SER Level 1. These handshake are based on H2C
commands and C2H events. Dump the status of them to enhance SER debug.
Zong-Zhe Yang [Fri, 15 May 2026 01:44:22 +0000 (09:44 +0800)]
wifi: rtw89: debug: Wi-Fi 7 update simulation of SER L0/L1 by halt H2C command
Wi-Fi 7 FW fixes support of triggering SER L0/L1 simulation via halt H2C
command on v0.35.108.0. After that, the halt H2C command trigger for
Wi-Fi 6 and Wi-Fi 7 can be the same. Update FW feature table and share the
halt H2C command trigger function between Wi-Fi 6 and Wi-Fi 7.
Nicolás Antinori [Sun, 24 May 2026 15:40:16 +0000 (12:40 -0300)]
opp: rust: mark OPP methods as inline
When building the kernel using llvm-19.1.7-rust-1.85.0-x86_64, the
following symbols are generated:
$ nm vmlinux | grep ' _R'.*OPP | rustfilt ffffffff81801560 T <kernel::opp::OPP>::freq ffffffff81801540 T <kernel::opp::OPP as kernel::sync::aref::AlwaysRefCounted>::dec_ref ffffffff81801520 T <kernel::opp::OPP as kernel::sync::aref::AlwaysRefCounted>::inc_ref
However, these Rust symbols are trivial wrappers around the
`dev_pm_opp_get`, `dev_pm_opp_put` and `dev_pm_opp_get_freq_indexed`
functions. It doesn't make sense to go through a trivial wrapper for
these functions.
After applying this patch, the above command will produce no output.
The register address was already validated for read operations in
regmap_sunxi_rsb_reg_read before being truncated to a u8. Write operations
have the same set of possible addresses, and the address is being truncated
from u32 to u8 here as well, so the same check is needed.
Signed-off-by: Samuel Holland <samuel@sholland.org> Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus") Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20260301144939.1832806-1-andrej.skvortzov@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Mark Brown [Sun, 24 May 2026 22:35:39 +0000 (23:35 +0100)]
regulator: add support for SGM3804 Dual Output driver
Neil Armstrong <neil.armstrong@linaro.org> says:
Add support for the SG Micro SGM3804 Single Inductor Dual Output
Buck/Boost Converter used to power LCD panels a provide positive
and negative power rails with configurable voltage and active
discharge function for each output.
The SGM3804 is powered by the enable GPIO pins inputs and only
supports I2C write messages.
In order to add flexibility and simplify the driver, the
regmap cache is enabled and populated with default values
since we can't write registers when the 2 GPIOs are down.
This regulator is used to provide vsn and vsn power to the
Ayaneo Pocket S2 dual-DSI LCD panel.
KancyJoe [Fri, 22 May 2026 13:09:13 +0000 (15:09 +0200)]
regulator: add SGM3804 Dual Output driver
Add support for the SG Micro SGM3804 Single Inductor Dual Output
Buck/Boost Converter used to power LCD panels a provide positive
and negative power rails with configurable voltage and active
discharge function for each output.
The SGM3804 is powered by the enable GPIO pins inputs and only
supports I2C write messages.
In order to add flexibility and simplify the driver, the
regmap cache is enabled and populated with default values
since we can't write registers when the 2 GPIOs are down.
Neil Armstrong [Fri, 22 May 2026 13:09:12 +0000 (15:09 +0200)]
regulator: dt-bindings: document the SGM3804 Dual Output regulator
Document the SG Micro SGM3804 Single Inductor Dual Output Buck/Boost
Converter used to power LCD panels a provide positive and negative
power rails with configurable voltage and active discharge function
for each output.
Thomas Weißschuh [Thu, 21 May 2026 17:31:04 +0000 (19:31 +0200)]
tools/nolibc: add ftruncate()
On architectures with 32-bit longs, call the compat syscall
__NR_ftruncate64. As off_t is 64-bit it must be split into 2 registers.
Unlike llseek() which passes the high and low parts in explicitly named
arguments, the order here is endian independent.
Some architectures (arm, mips, ppc) require this pair of registers to
be aligned to an even register, so add custom _sys_ftruncate64()
wrappers for those.
A test case for ftruncate is added which validates negative length or
invalid fd return the appropriate error, and checks the length is
correct on success.
Co-developed-by: Jordan Richards <jordanrichards@google.com> Signed-off-by: Jordan Richards <jordanrichards@google.com> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Reviewed-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260521-nolibc-ftruncate-v1-3-5384a83b2402@weissschuh.net
Daniel Palmer [Fri, 22 May 2026 09:07:26 +0000 (18:07 +0900)]
tools/nolibc: stackprotector: Avoid stalling program startup if crng is not init yet
We are using the getrandom syscall to get a random seed for the
stack protector canary but we are calling it with no flags which means
it'll block until there is some real randomness to return.
This means that if the crng is not ready yet program startup will
block and if you are unlucky that could be for a long time and
look like the program has crashed.
Even if the call to getrandom does not yield any random data,
we will still initialize the canary.
Fixes: 7188d4637e95 ("tools/nolibc: add support for stack protector") Signed-off-by: Daniel Palmer <daniel@thingy.jp> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260522090726.726985-1-daniel@thingy.jp Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
The avx2 lookup routines get the next map index to process passes as a
function argument, but this isn't obvious because it's hidden in the
lookup macro.
Additionally, a recent LLM review pointed out following "bug":
-------------------------------------------------------------
> b = nft_pipapo_avx2_refill(i_ul, &map[i_ul], fill, f->mt, last);
> if (last)
> - return b;
> + ret = b;
>
> if (unlikely(ret == -1))
> ret = b / XSAVE_YMM_SIZE;
Does this change introduce a logic error when last=true and no match is
found? [..]
Should this be changed to an else-if structure instead?
-------------------------------------------------------------
LLM sees a control-flow change, but there is none:
All call sites invoke nft_pipapo_avx2_refill() only when at least one
bit in the map is set, i.e. nft_pipapo_avx2_refill() never returns -1.
Add a runtime debug check that fires if we'd return -1 as additional
documentation and also make the suggested change, code might be easier
to understand this way.
In commit 17a20e09f086 ("netfilter: nft_set: remove one argument from
lookup and update functions") I incorrectly moved the "ret" scope into
the loop.
This has no effect on the correctness, but it can (depending on map sizes)
cause a redundant repeat of an earlier processing step.
Restore the intended 'pass map index' instead of always-0. Note that I
did not see any change in performance numbers, but Stefano correctly
points out that the existing perf test likely lack a sparse intermediate
bitmap (between fields) with a lot of leading zeroes.
parse_dcc() treats data_end as an inclusive end pointer, but its only
caller passes data_limit = ib_ptr + datalen, which points one past the
last valid byte.
The newline search loop iterates while tmp <= data_end, so when no
newline is present, *tmp is read at tmp == data_end, one byte beyond
the region filled by skb_header_pointer().
irc_buffer is kmalloc'd as MAX_SEARCH_SIZE + 1 bytes and datalen is
capped at MAX_SEARCH_SIZE, so the stray read does not fault. The byte
is uninitialized or stale; if it contains an ASCII digit, simple_strtoul
will consume it and produce a wrong DCC IP or port in the conntrack
expectation. The extra allocation byte is also a fragile guard: if the
cap or allocation size changes, this becomes a real out-of-bounds read.
Change the loop and its post-loop check to use strict less-than,
consistent with the caller's exclusive-end convention. Update the
function comment accordingly.
David Carlier [Sat, 11 Apr 2026 18:57:21 +0000 (19:57 +0100)]
netfilter: nfnl_cthelper: apply per-class values when updating policies
When a userspace conntrack helper with multiple expectation classes is
updated via nfnetlink, every class ends up with the first class's
max_expected and timeout values.
nfnl_cthelper_update_policy_all() validates each new policy into the
corresponding slot of the temporary new_policy array, but the second
loop that commits the values into the live helper dereferences
new_policy as a pointer instead of indexing it, so every iteration
reads new_policy[0] regardless of i. An update that changes per-class
values is silently collapsed onto class 0's values with no error
returned to userspace.
Index the temporary array by i in the commit loop so each class gets
its own validated values.
netfilter: nft_set_rbtree: remove dead conditional
net/netfilter/nft_set_rbtree.c:399 __nft_rbtree_insert()
warn: 'removed_end' is not an error pointer
Since commit : 087388278e0f ("netfilter: nf_tables: nft_set_rbtree: fix
spurious insertion failure") __nft_rbtree_insert() can no longer fail
and this condition is always false. Remove it.
Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/netfilter-devel/adjSaolTji0mPgqx@stanley.mountain/ Signed-off-by: Florian Westphal <fw@strlen.de>
Pratham Gupta [Tue, 5 May 2026 05:11:57 +0000 (22:11 -0700)]
netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump
Commit 02a3231b6d82 ("netfilter: nf_conntrack_expect: store netns and zone in expectation")
introduced exp->net so RCU-only expectation paths no longer need to
dereference exp->master for netns lookups.
Commit 3db5647984de ("netfilter: nf_conntrack_expect: skip expectations in other netns via proc")
updated the proc path accordingly, but ctnetlink_exp_dump_table() still
compares against nf_ct_net(exp->master).
Use nf_ct_exp_net(exp) here as well so the netlink dump path matches
the rest of the March 2026 expectation netns/RCU cleanup.
Fixes: 02a3231b6d82 ("netfilter: nf_conntrack_expect: store netns and zone in expectation") Cc: stable@vger.kernel.org Signed-off-by: Pratham Gupta <pratham36gupta@gmail.com> Signed-off-by: Florian Westphal <fw@strlen.de>
netfilter: nf_conncount: use per-rule hash initval
As-is, different netns will use same slots if the key is the same.
OVS uses this infrastructure to limit conntrack counts per zones.
Those can easily overlap. Make them hash to different slots internally.
Netfilter has its own netlink multiplexer, initially only a few
subsystem were using it, most notably conntrack, queue and log,
later in time nf_tables. These days it is the control plane of
preference.
Just remove modular support for this, allow it built-in only.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de> Signed-off-by: Florian Westphal <fw@strlen.de>
projects / thirdparty / kernel / linux.git / log
