Use devm_drm_bridge_add() so the bridge is released if probe fails after
registration, and drop the manual drm_bridge_remove() in remove().
Check the return value of devm_drm_bridge_add().
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Fixes: d28726efc6 ("drm/sti: hda: add bridge before attaching")
Cc: stable@vger.kernel.org
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Acked-by: Raphaël Gallais-Pou <rgallaispou@gmail.com>
Link: https://patch.msgid.link/20260423200622.325076-1-osama.abdelkader@gmail.com
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
FORCE_TARGETS has been part of the kselftest build system for
some time but is absent from the developer documentation. Without
an entry here, users relying on kselftest in CI pipelines would
have to read the selftests Makefile directly to discover the
option.
A build that exits zero despite some targets failing can mask
real breakage and mislead automated systems into reporting
success. Add a dedicated section so that CI authors can easily
find and adopt FORCE_TARGETS=1 to turn such silent partial
failures into hard errors.
Link: https://lore.kernel.org/r/20260417-selftests-docs-v1-1-32e4a78214eb@suse.com
Signed-off-by: Ricardo B. Marlière <rbm@suse.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Driver core expects devices to be dynamically allocated and will, for
example, complain loudly if a device that lacks a release function is
ever freed.
Use root_device_register() to allocate and register the root device
instead of open coding using a static device.
Note that this also fixes a reference leak in case device_register()
fails which may be flagged by static checkers.
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: William Breathitt Gray <wbg@kernel.org>
Link: https://patch.msgid.link/20260424102400.2615677-1-johan@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The first two fixes are workarounds for buggy IPMI hardware. The
hardware says it has data for the IPMI driver to read constantly, so the
driver reads the data constantly, causing any new requests to be
blocked.
The first fix was to check for invalid data right when the data was read
from the device and stop the operation there (there was a later check
for invalid data, but it could not stop the operation at that point).
It turned out the device was providing good data, so that didn't fix the
issue, but it's still a good check.
The second fix stops fetching this data after a few fetches and allows
other operations to occur. The driver won't work very well, but at
least it won't wedge. This seems to fix the issue.
The third issue is a problem I spotted while working on the previous
issue where if a certain memory allocation failed the driver would stop
working.
The fourth issue is a problem was a missing set to NULL on a PTR_ERR()
return, introduced in the previous series for 7.1.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE/Q1c5nzg9ZpmiCaGYfOMkJGb/4EFAmn4yl8ACgkQYfOMkJGb
/4GWBw//Wt/Kqafokay7ke1t0O0SvJXljdOCPPQp159QiRlXhukxl/G3dxtecCJw
8oZb5fazuiYOaBllATt7vLa+0fKK7oJFNuRXnYqTggrX8RRkcLQVpt3S1MBIofwk
gDeDKvw4TJcbvLfmGLtEnl/p37FddNHTS4rvtpynaqOmfHfq/3MiXPYYqLjOiGPG
EiH89viNZspiSlhAl3iMPXWkkVlW72r9kVn+YASDgL2+z5C+qZPA+Us0fxpVw02n
qwHBW39RgbhS3uRKnveDSoUm8VIr7/brp14ph6m2YlNxAnZQtyG5Ul8s3NCneQFJ
zr8HrTnl6gAl7SKYliOJXKpGGmpzwDKnqGnnh9IIaQAJZnblNhCsGM2oLw/d0ySe
O3pxvpyVN1ETPgv7NubDxlRTfc+XuX8soCQq3KSyj2gj700+NKW4CSAZHSLj7xW2
95JTsWFcUDWFi8fpc/p1PX7rgnB1KAWVQWdOWleUuQValeUjNpBdl5Yn34fqbVDG
DAYlkzXWXpszynfd3QxiwAUlYEeTyue+UZf8plVR+Gw3OwN3fGbFCBZOcVD4S8aA
w6ihk5eWR05dP2JgPBv9IxDHt+kY6/2o2qQEFow/0nYZIJGZI1IQPBWZi5ux7ygB
Cduro3EkzqkP9t42zavhWMxYagtpqyUOhuLFkWEZlMrdB2hNAVA=
=jA6/
-----END PGP SIGNATURE-----
Merge tag 'for-linus-7.1-2' of https://github.com/cminyard/linux-ipmi
Pull IPMI fixes from Corey Minyard:
"Fix a number of issues that came up recently
The first two fixes are workarounds for buggy IPMI hardware. The
hardware says it has data for the IPMI driver to read constantly, so
the driver reads the data constantly, causing any new requests to be
blocked.
The first fix was to check for invalid data right when the data was
read from the device and stop the operation there (there was a later
check for invalid data, but it could not stop the operation at that
point). It turned out the device was providing good data, so that
didn't fix the issue, but it's still a good check.
The second fix stops fetching this data after a few fetches and allows
other operations to occur. The driver won't work very well, but at
least it won't wedge. This seems to fix the issue.
The third issue is a problem I spotted while working on the previous
issue where if a certain memory allocation failed the driver would
stop working.
The fourth issue is a problem was a missing set to NULL on a PTR_ERR()
return, introduced in the previous series for 7.1"
* tag 'for-linus-7.1-2' of https://github.com/cminyard/linux-ipmi:
ipmi:ssif: NULL thread on error
ipmi:si: Return state to normal if message allocation fails
ipmi: Add limits to event and receive message requests
ipmi: Check event message buffer response for bad data
Fix a spelling error in the comment for the ns_type member of struct class.
Change "detemine" to "determine".
Signed-off-by: Prabhudasu Vatala <prabhudasuvatala@gmail.com>
Link: https://patch.msgid.link/20260503141826.27462-1-prabhudasuvatala@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Some architectures link libgcc.a from the toolchain into the kernel.
gen_compile_commands trie to read the kbuild .cmd files of its
constituent object files, which are not available.
Flat out ignore libgcc.a, as it is not built as part of the kernel
anyways.
Link: https://lore.kernel.org/r/20260427-kunit-or1k-v1-1-9d3109e991e8@weissschuh.net
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
scx_task_iter's cgroup-scoped mode can return tasks whose
sched_ext_dead() has already completed: cgroup_task_dead() removes
from cset->tasks after sched_ext_dead() in finish_task_switch() and is
irq-work deferred on PREEMPT_RT. The global mode is fine -
sched_ext_dead() removes from scx_tasks via list_del_init() first.
Callers (sub-sched enable prep/abort/apply, scx_sub_disable(),
scx_fail_parent()) assume returned tasks are still on @sch and trip
WARN_ON_ONCE() or operate on torn-down state otherwise.
Set %SCX_TASK_OFF_TASKS in sched_ext_dead() under @p's rq lock and
have scx_task_iter_next_locked() skip flagged tasks under the same
lock. Setter and reader serialize on the per-task rq lock - no race.
Signed-off-by: Tejun Heo <tj@kernel.org>
a72f73c4dd ("cgroup: Don't expose dead tasks in cgroup") made
css_task_iter_advance() skip exiting tasks so cgroup.procs stays consistent
with waitpid() visibility. Unfortunately, this broke scx_task_iter.
scx_task_iter walks either scx_tasks (global) or a cgroup subtree via
css_task_iter() and the two modes are expected to cover the same set of
tasks. After the above change the cgroup-scoped mode silently skips tasks
past exit_signals() that are still on scx_tasks.
scx_sub_enable_workfn()'s abort path is one of the symptoms: an exiting
SCX_TASK_SUB_INIT task can race past the cgroup iter leaking
__scx_init_task() state. Other iterations share the same gap.
Add CSS_TASK_ITER_WITH_DEAD to opt out of the skip and use it from
scx_task_iter().
Fixes: b0e4c2f8a0 ("sched_ext: Implement cgroup subtree iteration for scx_task_iter")
Reported-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
I'm resigning from my position at Axentia.
Signed-off-by: Peter Rosin <peda@lysator.liu.se>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
A chain of commits going back to v7.0 reworked rmdir to satisfy the
controller invariant that a subsystem's ->css_offline() must not run while
tasks are still doing kernel-side work in the cgroup.
[1] d245698d72 ("cgroup: Defer task cgroup unlink until after the task is done switching out")
[2] a72f73c4dd ("cgroup: Don't expose dead tasks in cgroup")
[3] 1b164b876c ("cgroup: Wait for dying tasks to leave on rmdir")
[4] 4c56a8ac68 ("cgroup: Fix cgroup_drain_dying() testing the wrong condition")
[5] 13e786b64b ("cgroup: Increment nr_dying_subsys_* from rmdir context")
[1] moved task cset unlink from do_exit() to finish_task_switch() so a
task's cset link drops only after the task has fully stopped scheduling.
That made tasks past exit_signals() linger on cset->tasks until their final
context switch, which led to a series of problems as what userspace expected
to see after rmdir diverged from what the kernel needs to wait for. [2]-[5]
tried to bridge that divergence: [2] filtered the exiting tasks from
cgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4]
fixed the wait's condition; [5] made nr_dying_subsys_* visible
synchronously.
The cgroup_drain_dying() wait in [3] turned out to be a dead end. When the
rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g.
host PID 1 systemd reaping orphan pids that were re-parented to it during
the same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those
pids to free, the pids can't free because PID 1 is the reaper and it's stuck
in rmdir, and the system A-A deadlocks. No internal lock ordering breaks
this; the wait itself is the bug.
The css killing side that drove the original reorder, however, can be made
cleanly asynchronous: ->css_offline() is already async, run from
css_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to
make that chain start only after all tasks have left the cgroup. rmdir's
user-visible side then returns as soon as cgroup.procs and friends are
empty, while ->css_offline() still runs only after the cgroup is fully
drained.
Verified by the original reproducer (pidns teardown + zombie reaper, runs
under vng) which hangs vanilla and succeeds here, and by per-commit
deterministic repros for [2], [3], [4], [5] with a boot parameter that
widens the post-exit_signals() window so each state is reliably reachable.
Some stress tests on top of that.
cgroup_apply_control_disable() has the same shape of pre-existing race:
when a controller is disabled via subtree_control, kill_css() ran
synchronously while tasks past exit_signals() could still be linked to
the cgroup's csets, and ->css_offline() could fire before they drained.
This patch preserves the existing synchronous behavior at that call site
(kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch
will defer kill_css_finish() there using a per-css trigger.
This seems like the right approach and I don't see problems with it. The
changes are somewhat invasive but not excessively so, so backporting to
-stable should be okay. If something does turn out to be wrong, the fallback
is to revert the entire chain ([1]-[5]) and rework in the development branch
instead.
v2: Pin cgrp across the deferred destroy work with explicit
cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1
wasn't actually broken (ordered cgroup_offline_wq + queue_work order
in cgroup_task_dead() saved it) but the explicit ref removes the
dependency on those non-obvious invariants. Also note the
pre-existing cgroup_apply_control_disable() race in the description;
a follow-up will defer kill_css_finish() there.
Fixes: 1b164b876c ("cgroup: Wait for dying tasks to leave on rmdir")
Cc: stable@vger.kernel.org # v7.0+
Reported-and-tested-by: Martin Pitt <martin@piware.de>
Link: https://lore.kernel.org/all/afHNg2VX2jy9bW7y@piware.de/
Link: https://lore.kernel.org/all/35e0670adb4abeab13da2c321582af9f@kernel.org/
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
CONFIG_KUNIT_DEBUGFS is totally useless without debugfs, so it should
depend on CONFIG_DEBUG_FS.
Link: https://lore.kernel.org/r/20260425034155.53913-2-david@davidgow.net
Fixes: e2219db280 ("kunit: add debugfs /sys/kernel/debug/kunit/<suite>/results display")
Signed-off-by: David Gow <david@davidgow.net>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
The KUNIT_DEBUGFS option is currently enabled based on the value of
KUNIT_ALL_TESTS, but it really doesn't have anything to do with the set of
enabled tests, so just enable it by default anyway. In particular, this
shouldn't be only visible if KUNIT_ALL_TESTS is set, which is quite
confusing.
Link: https://lore.kernel.org/r/20260425034155.53913-1-david@davidgow.net
Fixes: beaed42c42 ("kunit: default KUNIT_* fragments to KUNIT_ALL_TESTS")
Signed-off-by: David Gow <david@davidgow.net>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
After removing of_platform_default_populate() calls the atmel-ebi driver
was affected by deferred probing. platform_driver_probe() is
incompatible with deferred probing. This led to atmel-ebi driver
eventually not being probed on at91 sam9x60-curiosity and other sam9x60
based boards. Subsequently the nand-controller driver (nand-controller
being a child node of ebi) on that platform was not probed and thus raw
NAND flash was inaccessible, preventing devices to boot with rootfs on
raw NAND flash (e.g. with UBI/UBIFS).
Fixes: 0b0f7e6539 ("ARM: at91: remove unnecessary of_platform_default_populate calls")
Cc: stable@vger.kernel.org
Suggested-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Link: https://patch.msgid.link/20260429125930.844790-1-ada@thorsis.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
The Motu 1248 (and probably other older Motu AVB interfaces) take more
than 2 seconds to switch clock. During the clock switching process the
device return that the clock is not valid. This is similar to what
already implemented for the Microbook II interface. Add the Motu
1248 usb id to the existing Motu quirk.
Signed-off-by: Nicola Lunghi <nick83ola@gmail.com>
Link: https://patch.msgid.link/20260504144520.699522-2-nick83ola@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
USB MIDI 2.0 suspend saves the endpoint running state, clears it and
kills all endpoint URBs. Resume restores the running state, but only
restarts input endpoints.
For a running output endpoint, this leaves the endpoint marked running
with an empty URB queue. Output transfer progress depends on either the
rawmidi trigger path starting the queue or an output completion refilling
it. After suspend there is no completion left, and output data that
remains queued in the raw UMP or legacy rawmidi buffer can stay stalled
until userspace happens to trigger the stream again.
Restore the saved state with atomic accessors, keep input endpoints
restarted as before, and restart output endpoints that were running before
suspend. Clear the saved suspend state after restoring it.
Fixes: ff49d1df79 ("ALSA: usb-audio: USB MIDI 2.0 UMP support")
Cc: stable@vger.kernel.org
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260504-usb-midi2-output-resume-v1-1-c089cc8ad3c6@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This enables the mute and mic-mute LEDs on the HP Envy X360 15-fh0xxx
2-in-1 laptops.
The quirk 'ALC245_FIXUP_HP_ENVY_X360_15_FH0XXX' has been created and
is now enabled for this device.
This is my first patch, and I'm still getting to grips with the code,
so there's probably a better way to implement this fix.
I apologize for any inconvenience caused by the constant release of
new versions of this patch.
Signed-off-by: Fernando Antunez Antonio <fer.antunez24antonio@gmail.com>
Link: https://patch.msgid.link/20260504-hpenvy-muteled-fix-v3-1-5567fd9b3d25@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
JBL Pebbles is a pair of desktop speakers with UAC interface. Its
Playback and Capture mixers use linear volume with val = 0/999/1 and
0/3996/4. Meanwhile, the reported sample rates are truncated to
multiples of 0x100 (i.e., 44100 => 44032), resulting in noisy kmsg, as a
warning message is printed each time a stream is opened.
Add a quirk table entry matching VID/PID=0x05fc/0x0231 and applying
linear volume and sample rate quirk flags, so that it can work properly.
Also note that the volume control knob on device is an incremental
encoder. It does nothing but sends KEY_VOLUMEUP and KEY_VOLUMEDOWN per
rotation, controlling the UAC Playback volume mixer indirectly. Hence,
the linear volume quirk flags also enable the volume control knob to
function properly.
Quirky device sample:
usb 5-1.1: new full-speed USB device number 12 using xhci_hcd
usb 5-1.1: New USB device found, idVendor=05fc, idProduct=0231, bcdDevice= 1.00
usb 5-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-1.1: Product: JBL Pebbles
usb 5-1.1: Manufacturer: Harman International Industries
usb 5-1.1: SerialNumber: 1.0.0
usb-storage 5-1.1:1.0: USB Mass Storage device detected
scsi host0: usb-storage 5-1.1:1.0
usb 5-1.1: Found last interface = 1
usb 5-1.1: 2:1: add audio endpoint 0x5
usb 5-1.1: Creating new data endpoint #5
usb 5-1.1: 2:1 Set sample rate 44100, clock 0
usb 5-1.1: current rate 44032 is different from the runtime rate 44100
usb 5-1.1: 3:1: add audio endpoint 0x84
usb 5-1.1: Creating new data endpoint #84
usb 5-1.1: 3:1 Set sample rate 44100, clock 0
usb 5-1.1: current rate 44032 is different from the runtime rate 44100
usb 5-1.1: [2] FU [PCM Playback Switch] ch = 1, val = 0/1/1
usb 5-1.1: Warning! Unlikely big volume step count (=999), linear volume or wrong cval->res?
usb 5-1.1: [2] FU [PCM Playback Volume] ch = 2, val = 0/999/1
usb 5-1.1: [5] FU [Mic Capture Switch] ch = 1, val = 0/1/1
usb 5-1.1: Warning! Unlikely big volume step count (=999), linear volume or wrong cval->res?
usb 5-1.1: [5] FU [Mic Capture Volume] ch = 2, val = 0/3996/4
input: Harman International Industries JBL Pebbles as /devices/pci0000:00/0000:00:08.3/0000:67:00.3/usb5/5-1/5-1.1/5-1.1:1.4/0003:05FC:0231.0018/input/input55
hid-generic 0003:05FC:0231.0018: input,hidraw2: USB HID v2.01 Device [Harman International Industries JBL Pebbles] on usb-0000:67:00.3-1.1/input4
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260504-uac-jbl-pebbles-v1-1-c888d592a286@rong.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
tscm_hwdep_read_queue() copies as many queued control events as fit in
the userspace buffer. When the buffer is smaller than the current
contiguous queue segment, length is rounded down to the number of bytes
that can be copied.
However, after copying that shortened length, the code advances pull_pos
to the original tail_pos, marking the whole contiguous segment as
consumed. Any events between the copied portion and tail_pos are lost.
Limit tail_pos to the position after the entries actually copied before
updating pull_pos. When the whole segment fits, this is equivalent to the
old tail_pos update; when the buffer is smaller, the remaining events
stay queued for the next read.
Fixes: a8c0d13267 ("ALSA: firewire-tascam: notify events of change of state for userspace applications")
Cc: stable@vger.kernel.org
Suggested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Co-developed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260503-alsa-firewire-tascam-read-queue-v2-1-126c6efd7642@gmail.com
The AlphaTheta EUPHONIA (VID 0x2b73, PID 0x0047) is a USB Audio
Class 2 DJ mixer that requires implicit feedback for full-duplex
operation. The capture endpoint (0x83 IN, interface 2) acts as the
implicit feedback source for the playback endpoint (0x03 OUT,
interface 1), and the device firmware does not send isochronous
data on the capture endpoint unless the host is simultaneously
sending data on the playback endpoint, i.e. playback must be
started first.
Without QUIRK_FLAG_PLAYBACK_FIRST the kernel waits for capture URBs
before submitting playback URBs, creating a deadlock: the device
waits for playback data and the host waits for capture data.
Without QUIRK_FLAG_GENERIC_IMPLICIT_FB the kernel does not detect
the implicit feedback relationship between the two interfaces.
The same flag combination is already used for the Behringer UMC202HD,
UMC204HD and UMC404HD (0x1397:0x0507/0x0508/0x0509), which exhibit
the identical implicit-feedback topology.
Tested on Raspberry Pi 5 with kernel 6.12.75; continuous full-duplex
streaming at 96 kHz / 24-bit, zero XRUNs.
Signed-off-by: Anton Swart <anton.swart.jhb@gmail.com>
Link: https://patch.msgid.link/20260503211517.14332-1-anton.swart.jhb@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
tda998x_edid_read() returns a const struct drm_edid pointer, but when
tda998x_edid_delay_wait() fails (process killed while waiting for the
HPD timeout), the integer literal 0 is returned instead of NULL,
triggering a sparse warning: "Using plain integer as NULL pointer"
Replace 0 with NULL to fix the sparse warning.
Fixes: c76a8be4fe ("drm/bridge: tda998x: Add support for DRM_BRIDGE_ATTACH_NO_CONNECTOR")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604172257.Imo6GOH9-lkp@intel.com/
Signed-off-by: Kory Maincent (TI) <kory.maincent@bootlin.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260417155446.1068893-1-kory.maincent@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
of_get_property() returns a pointer to big-endian (__be32) data, but
port_data in tda998x_get_audio_ports() was declared as const u32 *,
causing a sparse endianness type mismatch warning. Fix the declaration
to use const __be32 *.
Fixes: 7e567624dc ("drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding")
Cc: stable@vger.kernel.org
Signed-off-by: Kory Maincent (TI) <kory.maincent@bootlin.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20260428090457.121894-1-kory.maincent@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Vincent reports:
> The ath5k driver seems to do an array-index-out-of-bounds access as
> shown by the UBSAN kernel message:
> UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20
> index 4 is out of range for type 'ieee80211_tx_rate [4]'
> ...
> Call Trace:
> <TASK>
> dump_stack_lvl+0x5d/0x80
> ubsan_epilogue+0x5/0x2b
> __ubsan_handle_out_of_bounds.cold+0x46/0x4b
> ath5k_tasklet_tx+0x4e0/0x560 [ath5k]
> tasklet_action_common+0xb5/0x1c0
It is real. 'ts->ts_final_idx' can be 3 on 5212, so:
info->status.rates[ts->ts_final_idx + 1].idx = -1;
with the array defined as:
struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];
while the size is:
#define IEEE80211_TX_MAX_RATES 4
is indeed bogus.
Set this 'idx = -1' sentinel only if the array index is less than the
array size. As mac80211 will not look at rates beyond the size
(IEEE80211_TX_MAX_RATES).
Note: The effect of the OOB write is negligible. It just overwrites the
next member of info->status, i.e. ack_signal.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Reported-by: Vincent Danjean <vdanjean@debian.org>
Link: https://lore.kernel.org/all/aQYUkIaT87ccDCin@eldamar.lan
Closes: https://bugs.debian.org/1119093
Fixes: 6d7b97b23e ("ath5k: fix tx status reporting issues")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251209100459.2253198-1-jirislaby@kernel.org
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_dp_rx_deliver_msdu() currently uses hal_rx_desc_data::peer_id
parsed from mpdu_start descriptor to do peer lookup. However In an A-MSDU
aggregation scenario, hardware only populates mpdu_start descriptor for
the first sub-msdu, but not the following ones. In that case peer_id could
be invalid, leading to peer lookup failure:
ath12k_wifi7_pci 0000:06:00.0: rx skb 00000000c391c041 len 1532 peer (null) 0 ucast sn 0 eht320 rate_idx 12 vht_nss 2 freq 6105 band 3 flag 0x40d1a fcs-err 0 mic-err 0 amsdu-more 0
As a result pubsta is NULL and parts of ieee80211_rx_status structure are
left uninitialized, which may cause unexpected behavior.
Fix it by switching the normal RX path to use ath12k_skb_rxcb::peer_id
which is parsed from REO ring's rx_mpdu_desc and is always valid.
hal_rx_desc_data::peer_id is still used in
ath12k_wifi7_dp_rx_frag_h_mpdu(), which is safe since A-MSDU
aggregation does not occur for fragmented frames. Similarly,
ath12k_skb_rxcb::peer_id may be overwritten by hal_rx_desc_data::peer_id
in ath12k_wifi7_dp_rx_h_mpdu(), which only handles non-aggregated
multicast/broadcast traffic.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 11157e0910 ("wifi: ath12k: Use ath12k_dp_peer in per packet Tx & Rx paths")
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260427-ath12k-fix-peer-id-source-v1-1-b5f701fb8e88@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, the RSSI dBm conversion event handler leaves struct
ath12k_wmi_rssi_dbm_conv_info_arg uninitialized on the stack before
calling the TLV parser. If one of the optional sub-TLVs is absent, the
corresponding *_present flag retains stack garbage and later gets read
in ath12k_wmi_update_rssi_offsets(). With UBSAN enabled this triggers an
invalid-load report for _Bool:
UBSAN: invalid-load in drivers/net/wireless/ath/ath12k/wmi.c:9682:15
load of value 9 is not a valid value for type '_Bool'
Call Trace:
ath12k_wmi_rssi_dbm_conversion_params_info_event.cold+0x72/0x85 [ath12k]
ath12k_wmi_op_rx+0x1871/0x2ab0 [ath12k]
ath12k_htc_rx_completion_handler+0x44b/0x810 [ath12k]
ath12k_ce_recv_process_cb+0x554/0x9f0 [ath12k]
ath12k_ce_per_engine_service+0xbe/0xf0 [ath12k]
ath12k_pci_ce_workqueue+0x69/0x120 [ath12k]
Initialize the parsed event state to zero before passing it to the TLV
parser so missing sub-TLVs correctly leave the presence flags false.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
Fixes: 0314ee81a9 ("wifi: ath12k: handle WMI event for real noise floor calculation")
Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260427103011.2983269-1-rameshkumar.sundaram@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Commit 8a552d68a8 ("mm: memfd_luo: preserve file seals") started
preserving file seals across live update and restoring them via
memfd_add_seals() on retrieve, but the DOC header was not updated and
still listed seals under "Non-Preserved Properties" as being unsealed
on restore.
Move the Seals entry to the "Preserved Properties" section and describe
the actual behavior, including the MEMFD_LUO_ALL_SEALS restriction that
both preserve and retrieve enforce.
Fixes: 8a552d68a8 ("mm: memfd_luo: preserve file seals")
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Link: https://patch.msgid.link/20260423125648.152113-2-devnexen@gmail.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
memfd_luo_preserve_folios() declares max_folios as unsigned int and
computes it from the inode size, then passes it to memfd_pin_folios()
which itself caps max_folios at unsigned int. For files whose base-page
count exceeds UINT_MAX (larger than 16 TiB with 4 KiB pages), the
assignment truncates silently: only a prefix of the file gets pinned and
preserved, while memfd_luo_preserve() still records the full inode size
in ser->size. On retrieve the inode is restored to the full size but
only the preserved prefix repopulates the page cache, so the tail comes
back as holes and user data is silently lost across the live update.
Reject such files at preserve time with -EFBIG rather than chunk the
pin loop, which would also require enlarging the preserved folios array
well beyond what is practical.
Fixes: b3749f174d ("mm: memfd_luo: allow preserving memfd")
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Link: https://patch.msgid.link/20260423125648.152113-1-devnexen@gmail.com
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Conor Dooley <conor@kernel.org> says:
v3 with the review comment about the core handing CS_HIGH dealt with.
I noticed that in the same function there was a "raw" BIT(1), which I
replaced with a macro that the patch was already adding for use in the
setup function...
Remove inline markings from a number of functions that are called as
part of mem ops callbacks. None of them are either particularly trivial
or sensitive to overhead of a function call. Just let the compiler
decide what to do with them.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260430-serpent-stimulate-59fb860ef429@spud
Signed-off-by: Mark Brown <broonie@kernel.org>
The core will deal with reads by creating clock cycles itself, there's
no need to generate clock cycles by transmitting garbage data at the
driver level. Further, transmitting garbage data just bricks the transfer
since QSPI doesn't have a dedicated master-out line like MOSI in regular
SPI. I'm not entirely sure if the transfer is bricked because of the
garbage data being transmitted on the bus or because the core loses
track of whether it is supposed to be sending or receiving data.
Fixes: 8f9cf02c88 ("spi: microchip-core-qspi: Add regular transfers")
CC: stable@vger.kernel.org
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260430-freezing-saloon-95b1f3d9dad0@spud
Signed-off-by: Mark Brown <broonie@kernel.org>
The coreQSPI IP supports only a single chip select, which is
automagically operated by the hardware - set low when the transmit
buffer first gets written to and set high when the number of bytes
written to the TOTALBYTES field of the FRAMES register have been sent on
the bus. Additional devices must use GPIOs for their chip selects.
It was reported to me that if there are two devices attached to this
QSPI controller that the in-built chip select is set low while linux
tries to access the device attached to the GPIO.
This went undetected as the boards that connected multiple devices to
the SPI controller all exclusively used GPIOs for chip selects, not
relying on the built-in chip select at all. It turns out that this was
because the built-in chip select, when controlled automagically, is set
low when active and high when inactive, thereby ruling out its use for
active-high devices or devices that need to transmit with the chip
select disabled.
Modify the driver so that it controls chip select directly, retaining
the behaviour for mem_ops of setting the chip select active for the
entire duration of the transfer in the exec_op callback. For regular
transfers, implement the set_cs callback for the core to use.
As part of this, the existing setup callback, mchp_coreqspi_setup_op(),
is removed. Modifying the CLKIDLE field is not safe to do during
operation when there are multiple devices, so this code is removed
entirely. Setting the MASTER and ENABLE fields is something that can be
done once at probe, it doesn't need to be re-run for each device.
Instead the new setup callback sets the built-in chip select to its
inactive state for active-low devices, as the reset value of the chip
select in software controlled mode is low.
Fixes: 8f9cf02c88 ("spi: microchip-core-qspi: Add regular transfers")
Fixes: 8596124c4c ("spi: microchip-core-qspi: Add support for microchip fpga qspi controllers")
CC: stable@vger.kernel.org
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260430-hamstring-busload-f941d0347b5e@spud
Signed-off-by: Mark Brown <broonie@kernel.org>
John Madieu <john.madieu@gmail.com> says:
This series independent fixes found in the i.MX SPI driver.
These are:
1/3 fixes a precedence bug in spi_imx_dma_max_wml_find() that makes
the watermark-finding logic effectively dead code. The function
currently always returns wml = 1 because of how the !-operator
binds to the modulo expression.
2/3 fixes a missing return on the package-1 failure path in
spi_imx_dma_data_prepare(). The error path frees the
dma_data array and the package-0 buffers, then falls through
to "return 0" - the caller proceeds with a freed pointer.
3/3 makes spi_imx_setupxfer() propagate the prepare_transfer()
return value. Currently a -EINVAL from mx51_ecspi_prepare_transfer
(e.g. on a word_delay overflow) is silently swallowed and the
transfer proceeds with a partially-configured controller.
spi_imx_setupxfer() calls the per-variant prepare_transfer()
callback and returns 0 unconditionally:
spi_imx->devtype_data->prepare_transfer(spi_imx, spi, t);
return 0;
mx51_ecspi_prepare_transfer() can return -EINVAL when the requested
word_delay does not fit in MX51_ECSPI_PERIOD_MASK. The error is
detected after a partial set of register writes (CTRL: BL, clkdiv,
SMC), so the controller is left in a partially-configured state and
the transfer is then submitted as if setup succeeded.
Propagate the return value. The other variants' prepare_transfer
callbacks all return 0, so this is a no-op for them.
Fixes: a3bb4e663d ("spi: imx: support word delay")
Signed-off-by: John Madieu <john.madieu@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260501135951.2416527-4-john.madieu@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When transfer->len exceeds MX51_ECSPI_CTRL_MAX_BURST and is not a
multiple of it, spi_imx_dma_data_prepare() splits the transfer into
two DMA packages. If preparing the second package fails:
ret = spi_imx_dma_tx_data_handle(spi_imx, &spi_imx->dma_data[1],
transfer->tx_buf + spi_imx->dma_data[0].data_len,
false);
if (ret) {
kfree(spi_imx->dma_data[0].dma_tx_buf);
kfree(spi_imx->dma_data[0].dma_rx_buf);
kfree(spi_imx->dma_data);
}
}
return 0;
the function frees the package-0 buffers and the dma_data array,
then falls through to `return 0`, telling the caller the prepare
succeeded. The caller then dereferences the freed dma_data array,
producing a use-after-free.
Return the error from the failure path so the caller takes its
existing failure branch.
Fixes: faa8e404ad ("spi: imx: support dynamic burst length for ECSPI DMA mode")
Signed-off-by: John Madieu <john.madieu@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260501135951.2416527-3-john.madieu@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The watermark search in spi_imx_dma_max_wml_find() reads:
if (!dma_data->dma_len % (i * bytes_per_word))
break;
The unary ! binds tighter than %, so this parses as:
if ((!dma_data->dma_len) % (i * bytes_per_word))
break;
!dma_data->dma_len is 0 or 1, and `0 % x == 0` for any x; `1 % x` is
0 unless x == 1. The condition is therefore false in every case
except dma_len != 0 with i * bytes_per_word == 1, i.e. i == 1 and
bytes_per_word == 1.
The loop almost always falls through to its end, leaving i == 0,
which the post-loop fallback rewrites to 1:
if (i == 0)
i = 1;
So spi_imx->wml ends up at 1 for essentially every DMA transfer,
defeating the entire purpose of the function. The DMA engine then
requests service after every single FIFO word instead of using
multi-word bursts, hurting throughput on every DMA-capable variant.
Add the missing parentheses so the modulo is computed first, then
negated:
if (!(dma_data->dma_len % (i * bytes_per_word)))
break;
Fixes: faa8e404ad ("spi: imx: support dynamic burst length for ECSPI DMA mode")
Signed-off-by: John Madieu <john.madieu@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260501135951.2416527-2-john.madieu@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ALSA controls should return 1 from a put callback when the control
value changes. fsl_xcvr_capds_put() and fsl_xcvr_tx_cs_put() both
update cached control data but always return 0, so ALSA suppresses
change notifications for the Capabilities Data Structure and playback
IEC958 channel status controls.
Compare the old and new cached values before copying the new data,
and return whether the control value changed.
Fixes: 2856448686 ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver")
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260428-asoc-fsl-xcvr-event-generation-v1-1-f21cf0812c4f@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch introduces the driver for the SPI controller found in the
SpacemiT K1 SoC. Currently the driver supports master mode only.
The SPI hardware implements RX and TX FIFOs, 32 entries each, and
supports both PIO and DMA mode transfers.
Signed-off-by: Alex Elder <elder@riscstar.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Link: https://patch.msgid.link/20260502-spi-spacemit-k1-v10-2-f412e1ae8a34@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the SPI controller implemented by the SpacemiT K1 SoC.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Alex Elder <elder@riscstar.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
Link: https://patch.msgid.link/20260502-spi-spacemit-k1-v10-1-f412e1ae8a34@riscstar.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The QSPI controller has two interconnect paths:
1. qspi-config: CPU to QSPI controller for register access
2. qspi-memory: QSPI controller to memory for DMA operations
Currently, the driver only manages the qspi-config path. Add support for
the qspi-memory path to ensure proper bandwidth allocation for QSPI data
transfers to/from memory. Enable and disable both paths during runtime PM
transitions.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Link: https://patch.msgid.link/20260429-spi-nor-v5-3-993016c9711e@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The runtime PM functions had incomplete error handling that could leave the
system in an inconsistent state. If any operation failed midway through
suspend or resume, some resources would be left in the wrong state while
others were already changed, leading to potential clock/power imbalances.
Reorder the suspend/resume sequences to avoid brownout risk by ensuring the
performance state is set appropriately before clocks are enabled and clocks
are disabled before dropping the performance state.
Fix by adding proper error checking for all operations and using goto-based
cleanup to ensure all successfully acquired resources are properly released
on any error.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Link: https://patch.msgid.link/20260429-spi-nor-v5-2-993016c9711e@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for the QSPI controller on QCS615 SoC.
Move allOf section after required properties and add if:then constraint
to require minimum 2 interconnects for qcs615 variant.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Link: https://patch.msgid.link/20260429-spi-nor-v5-1-993016c9711e@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Return explicit zero on successful probe to clearly separate the success
and error paths and make the code more readable.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260430120200.249323-4-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Switch to device managed controller allocation to simplify error
handling and to avoid having to take another reference during
deregistration.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260430120200.249323-2-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Switch to device managed controller allocation to simplify error
handling and to avoid having to take another reference during
deregistration.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260429091333.165363-20-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Switch to device managed controller allocation to simplify error
handling and to avoid having to take another reference during
deregistration.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260429091333.165363-18-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Switch to device managed controller allocation to simplify error
handling and to avoid having to take another reference during
deregistration.
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260429091333.165363-17-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
