This series converts spin lock handling in UniPhier AIO drivers
to use guard() helpers.
The changes are purely code cleanups with no functional impact.
Miquel Raynal [Thu, 26 Mar 2026 16:47:15 +0000 (17:47 +0100)]
spi: spi-mem: Add a no_cs_assertion capability
Some controllers are 'smart', and that's a problem.
For instance, the Cadence quadspi controller is capable of deasserting
the CS automatically whenever a too long period of time without any data
to transfer elapses.
This 'feature' combined with a loaded interconnect with arbitration, a
"long" transfer may be split into smaller DMA transfers. In this case
the controller may allow itself to deassert the CS between chunks.
Deasserting the CS stops any ongoing continuous read. Reasserting it
later to continue the reading will only result in the host getting
garbage.
In this case, the host controller driver has no control over the CS
state, so we cannot reliably enable continuous reads. Flag this
limitation through a spi-mem controller capability.
The inversion in the flag name (starting with 'no_') is voluntary, in
order to avoid the need to set this flag in all controller drivers. Only
the broken controllers shall set this bit, the default being that the
controller masters its CS fully.
Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
ASoC: cs35l56: Fix out-of-bounds in dev_err() in cs35l56_read_onchip_spkid()
Remove the incorrect use of onchip_spkid_gpios[i] in the dev_err() after
regmap_read() of CS35L56_GPIO_STATUS1 returns an error.
This dev_err() was incorrectly copy-pasted from one inside the for-loop,
where i was valid. The read of CS35L56_GPIO_STATUS1 isn't for a specific
GPIO register, so the use of onchip_spkid_gpios[i] in the error message is
both irrelevant and out-of-bounds here.
Johan Hovold [Wed, 29 Apr 2026 09:20:05 +0000 (11:20 +0200)]
spi: at91-usart: drop dead runtime pm support
Drop the dead runtime PM support which has never been enabled.
Fixes: 96ed3ecde2c0 ("spi: at91-usart: add power management support") Cc: Radu Pirea <radu_nicolae.pirea@upb.ro> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260429092005.166128-1-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: cs35l56: Fix hibernate write in runtime resume error path
The error path of cs35l56_runtime_resume_common() should only write
the hibernation sequence if can_hibernate is true.
Something has already gone badly wrong if we ever reach the error
path. But triggering hibernate on hardware that does not support it
is likely to make the situation unrecoverable without a full reboot
because there might not be any hardware signal to exit hibernate.
ASoC: spacemit: fix RX DMA params not set when TX is running
When TX is already running (SSCR_SSE is set), the hw_params callback
returns early before setting up DMA parameters for the RX stream. This
prevents the capture path from configuring its DMA data properly.
Move the SSCR_SSE check after DMA parameter setup and format
constraints, so both TX and RX streams get their DMA configuration
regardless of whether the hardware is already enabled. The early return
now only skips the register writes that would disrupt an active stream.
Bruce Johnston [Tue, 28 Apr 2026 18:39:31 +0000 (14:39 -0400)]
dm vdo: use GFP_NOIO for blkdev_issue_zeroout on format path
GFP_NOWAIT is inappropriate when blkdev_issue_zeroout may sleep and
bio_alloc can fail under pressure; use GFP_NOIO for clear_partition and
vdo_clear_layout zeroout calls.
Signed-off-by: Bruce Johnston <bjohnsto@redhat.com> Signed-off-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: fc1d43826702 ("dm vdo: save the formatted metadata to disk")
In some situations, direct mappings may need to use different
operation templates.
For instance, when enabling continuous reads, Winbond SPI NANDs no
longer expect address cycles because they would be ignoring them
otherwise. Hence, right after the command opcode, they start counting
dummy cycles, followed by the data cycles as usual.
This breaks the assumptions of "reads from cache" always being done
identically once the best variant has been picked up, across the
lifetime of the system.
In order to support this feature, we must give direct mapping more than
a single operation template to use, in order to switch to using
secondary operations upon request by the upper layer.
Create the concept of optional secondary operation template, which may
or may not be fulfilled by the SPI NAND and SPI NOR cores. If the
underlying SPI controller does not leverage any kind of direct mapping
acceleration, the feature has no impact and can be freely
used. Otherwise, the controller driver needs to opt-in for using this
feature, if supported.
The condition checked to know whether a secondary operation has been
provided or not is to look for a non zero opcode to limit the creation
of extra variables. In practice, the opcode 0x00 exist, but is not
related to any cache related operation.
Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
spi: spi-mem: Transform the read operation template
As of now, we only use a single operation template when creating SPI
memory direct mappings. With the idea to extend this possibility to 2,
rename the template to reflect that we are currently setting the
"primary" operation, and create a pointer in the same structure to point
to it.
From a user point of view, the op_tmpl name remains but becomes a
pointer, leading to minor changes in both the SPI NAND and SPI NOR
cores.
There is no functional change.
Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Direct mappings are very static concepts, which allow us to reuse a
template to perform reads or writes in a very efficient manner after a
single initialization. With the introduction of pipelined ECC engines
for SPI controllers, the need to differentiate between an operation with
and without correction has arised. The chosen solution at that time has
been to create new direct mappings for these operations, jumping from 2
to 4 dirmaps per target. Enabling ECC was done by choosing the correct
dirmap.
Today, we need to further parametrize dirmaps. With the goal to enable
continuous reads on a wider range of devices, we will need more
flexibility regarding the read from cache operation template to pick at
run time, for instance to use shorter "continuous read from cache"
variants.
We could create other direct mappings, but it would increase the matrix
by a power of two, bringing the theoretical number of dirmaps to
8 (read/write, ecc, shorter read variants) per target. This grow is not
sustainable, so let's change how dirmaps work - a little bit.
Operations already carry an ECC parameter, use it to indicate whether
error correction is required or not. In practice this change happens
only at the core level, SPI controller drivers do not care about the
direct mapping structure in this case, they just pick whatever is in the
template as a base. As a result, we allow the core to dynamically change
the content of the templates.
He who can do more can do less, so during the checking steps, make sure
to enable the ECC requirement just for the time of the checks.
Since continuous reads may sometimes not be able to go past an erase
block boundary, it has been decided not to attempt longer reads and if
the user request is bigger, it will be split across eraseblocks.
As these request will anyway be handled correctly, there is no reason to
filter out cases where we would go over a target or a die, so drop this
limitation which had a side effect: any request to read more than the
content of an eraseblock would simply not benefit from the continuous
read feature.
Rosen Penev [Sun, 3 May 2026 00:30:37 +0000 (17:30 -0700)]
ASoC: tegra: ADMAIF: allocate with a single kzalloc
Consolidate the allocations for capture_dma_data and playback_dma_data
into a single kzalloc by using a flexible array member at the end of
the tegra_admaif struct. This reduces the number of allocations from
three to one, simplifies error handling, and improves memory locality.
Francesco Lavra [Tue, 10 Feb 2026 17:35:45 +0000 (18:35 +0100)]
drm/fb-helper: Fix clipping when damage area spans a single scanline
When the damage area resulting from a dirty memory range spans a single
scanline, the width of the rectangle is calculated dynamically because it
may not coincide with the framebuffer width.
If the dirty range ends exactly at the end of the scanline, the `bit_end`
variable is incorrectly assigned a 0 value, which results in a bogus clip
rectangle where the x2 coordinate is 0. This prevents the dirty scanline
from being flushed to the hardware.
Change the calculation of the `bit_end` value to fix the x2 coordinate
value in the above edge case.
Fixes: ded74cafeea9 ("drm/fb-helper: Clip damage area horizontally") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260210173545.733937-1-flavra@baylibre.com
Myeonghun Pak [Fri, 24 Apr 2026 11:25:18 +0000 (20:25 +0900)]
drm/qxl: Fix missing KMS poll cleanup
drm_kms_helper_poll_init() initializes the output polling work and
enables polling for the DRM device. qxl enables polling before calling
drm_dev_register(), but the drm_dev_register() failure path tears down
the modeset and device state without disabling the polling helper.
The remove path also unregisters and shuts down the DRM device without
first disabling the polling helper. Add matching drm_kms_helper_poll_fini()
calls in both paths so the delayed polling work is cancelled before qxl
tears down the associated modeset/device state.
Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5ff91e442652 ("qxl: use drm helper hotplug support") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260424112543.57819-1-mhun512@gmail.com
It is possible that the dm_ima_measure_on_* functions run at the same
time as a table is getting swapped, but before the md->ima.active_table
is updated by dm_ima_measure_on_device_resume(). Instead of using the
current device size, use the size of the active table that is being
measured (assuming there is one), so the information is consistent.
Also, don't allocate a separate string to hold the capactiy. Just
print it directly to the measurement buffer.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
dm-ima: Fail more gracefully in dm_ima_measure_on_*
In all the dm_ima_measure_on_* functions besides
dm_ima_measure_on_table_load(), even if measuring the event fails, it's
still possible to update dm->ima, so that it continues to correctly
track the device state. This means that one measurement failure won't
cause future measurements to record the wrong data.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
a device rename could happen after do_resume() removed the inactive
table that it was swapping to out of the hash cell, but before it was
made the active table. In this case, the table metadata would still
have the old name. Update the swapped table's metadata to avoid this.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
dm-ima: Fix issues with dm_ima_measure_on_device_rename
dm_ima_measure_on_device_rename() can be called on a device before it
ever loads a table, so it needs to handle the case where there is no
table metadata. Also, it was only updating the table_metadata on the
active table. If there was an inactive table when the device was renamed
and that table was later swapped in as the active table, it would
still have the old name. dm_ima_measure_on_device_rename() was also
needlessly allocating new memory for the updated table metadata, instead
of just reusing the existing memory.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
dm-ima: remove new_map from dm_ima_measure_on_device_clear
Now that two processes can't modify md->ima in
dm_ima_measure_on_device_clear() at the same time, there's no need to
track if an inactive table was actually removed. We might as well
clean it up unconditionally, on the off chance that a previous
ima measurement failed and left md->ima.inactive_table behind.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
anc_configure() passed values from drvdata->anc_fir_values[],
drvdata->anc_iir_values[] and drvdata->sid_fir_values[] as register
offset to snd_soc_component_read(). The content of these arrays are user
controllable via the component controls "ANC FIR Coefficients", "ANC
IIR Coefficients" and "Sidetone FIR Coefficients" which I assume are
supposed to hold register values, not register offsets.
Without a datasheet for that component and given that before commit a201aef1a88b ("ASoC: codecs: ab8500: Fix casting of private data") the
arrays overlapped with driver control structures and thus didn't work
properly since 2012, drop that functionality and let someone repair it
who has an actual need for it.
With the core functionally removed several code parts become essentially
unused and are removed, too.
dm-ima: Fix UAF errors and measuring incorrect context
the dm-ima code did not keep the dm_ima_measure_on_* functions from
running at the same time. This could lead to various errors. If two
processes were updating the device state, one could update the state
first, but the other could measure the state first, causing the the
current device state to appear incorrect. If a table load happened while
a device was resuming, the IMA measurement could report the wrong table
being active. And if two dm_ima_measure_on_* functions ran at the same
time, one of them could free data that the other was accessing, causing
a crash.
All the core dm functions that call a dm_ima_measure_on_* function
update the device state they want to measure under the _hash_lock,
except for do_resume(). But holding the _hash_lock is not a good way to
synchronize these functions. It's a global mutex, that is needed in many
dm operations, and the dm_ima_measure_* functions can sleep, blocking
any dm operation on any device that needs the _hash_lock.
To serialize and order the IMA measurement functions, the
dm_ima_measurements now has two counters, update_idx and measure_idx.
update_idx is incremented while holding the _hash_lock and saved, along
with the device name and uuid, in a dm_ima_context struct. Once the
_hash_lock is dropped, the dm_ima_measure_* function is called. It waits
until measure_idx matches the saved value of update_idx, ensuring that
the updates and measurements happen in the same order if there are
multiple processes changing the device at the same time. Then it
measures the device, updates measure_idx, and wakes up any other
process waiting to do a measurement. This makes sure that the
measurements are serialized and done in the order that the _hash_lock
was acquired in. But they only block other measurements for the same
device, which are unlikely to happen at the same time.
do_resume() is trickier, because it removes the inactive table while
holding the _hash_lock, but doesn't hold it while updating md->map. To
make sure it is also ordered, the IMA code grabs the _hash_lock after
md->map is updated. Then it makes sure that the device isn't being
removed and that another do_resume() hasn't already changed the active
table again, and serializes like the other functions do.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
dm-ima: don't copy the active table to the inactive table
If an inactive table was cleared, dm_ima_measure_on_table_clear() was
copying the ima.active_table to ima.inactive_table. This is not what
device-mapper does, and it makes the IMA measurements show an inactive
table when there isn't one. Also, once this is removed, the code no
longer needs to keep checking if the active and the inactive table point
to the same memory.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
When it ran out of space for adding more targets to the ima_buf,
dm_ima_measure_on_table_load() would measure the dm device early, and
then add the rest of the targets and measure it again.
last_target_measured was intended to flag the last target measured so
that the device wouldn't get remeasured, if no new targets were added
after the early measurement. But the way to code works, the dm device
will never be measured early unless there is another target to add to
the ima_buf. Instead, if there is only one more target to add, that
target was getting added to the ima_buf, but it wasn't getting
remeasured, because last_target_measured was set. Since
dm_ima_measure_on_table_load() only measures a device early when there
are more targets to add, the final measurement must always happen, and
last_target_measured is unneeded.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
There's no point in saving the string length of DM_IMA_VERSION_STR. It's
a constant, so the compiler will precompute it. dm_create() will already
zero out the rest of dm->ima.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
returning DM_MAPIO_REQUEUE from the target map() function only requeues
the bio during noflush suspends. During regular operations or during
flushing suspends, it fails the bio. Failing the bio during flushing
suspends is the correct behavior here. We cannot handle the bio, and we
cannot suspends while it is outstanding. But during normal operations,
we should not push the bio back to dm. Instead, wait for the reshape
to be resumed.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
David Carlier [Sun, 5 Apr 2026 15:47:13 +0000 (16:47 +0100)]
dm vdo: use get_random_u32() where appropriate
Use the typed random integer helpers instead of
get_random_bytes() when filling a single integer variable.
The helpers return the value directly, require no pointer
or size argument, and better express intent.
Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Set PM ops for the vesadrm driver. Suspend and resume the DRM state
on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Set PM ops for the simpledrm driver. Suspend and resume the DRM
state on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Set PM ops for the ofdrm driver. Suspend and resume the DRM state
on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Set PM ops for the efidrm driver. Suspend and resume the DRM state
on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Set PM ops for the corebootdrm driver. Suspend and resume the DRM
state on systems that support it.
Many systems lose the hardware's framebuffer settings on suspend,
hence resuming doesn't work there. Yet some systems, most notably
emulators, keep the hardware state across suspend/resume cycles.
There, DRM's suspend and resume helpers bring back the display on
resume.
Fold the '+' check in the single-underscore-prefixed version
_kstrtoull() and remove the function. The arch/x86/boot/ namespace
prefixes everything copied from kernel proper with "boot_" so that
namespace clashes can be avoided.
x86/boot/compressed: Use boot_kstrtoul() for hugepages= parsing
Replace simple_strtoull() with boot_kstrtoul() for parsing the hugepages= boot
parameter.
Unlike simple_strtoull(), boot_kstrtoul() performs strict validation and
returns an error on invalid inputs instead of silently accepting partial
input. Use boot_kstrtoul() to reject and warn about invalid hugepages= values.
boot_kstrtoul() also converts the input directly to an unsigned long and
avoids implicit casting as max_gb_huge_pages *is* an unsigned long.
Add support for the PLLDSI{0,1} clocks in the r9a09g047 CPG driver.
Introduce CLK_PLLDSI{0,1} also, introduce the
rzg3e_cpg_pll_dsi{0,1}_limits structures to describe the frequency
constraints specific to the RZ/G3E SoC.
On Renesas RZ/G3E:
- PLLDSI0 maximum output frequency: 1218 MHz
- PLLDSI1 maximum output frequency: 609 MHz
These limits are enforced through the newly added
RZG3E_CPG_PLL_DSI{0,1}_LIMITS().
Add PLLDSI clk mux support to select PLLDSI clock from different clock
sources.
Introduce the DEF_PLLDSI_SMUX() macro to define these muxes and register
them in the clock driver.
Extend the determine_rate callback to calculate and propagate PLL
parameters via rzv2h_get_pll_dtable_pars() when LVDS output is selected,
using a new helper function rzv2h_cpg_plldsi_smux_lvds_determine_rate().
The CLK_SMUX2_DSI{0,1}_CLK clock multiplexers select between two paths
with different duty cycles:
Implement rzv2h_cpg_plldsi_smux_{get,set}_duty_cycle clock operations to
allow the DRM driver to query and configure the appropriate clock path
based on the required output duty cycle.
Replace vmwgfx's vblank timer with DRM's common implementation. The
timer handling is almost identical with a few additional bug fixes in
the common code.
Replace most of vmwgfx's vmw_vkms_get_vblank_timestamp() with the
shared helper drm_crtc_vblank_get_vblank_timeout(). The common helper
also works in the presence of delayed vblank timeouts that modify the
vblank counter concurrently.
Set the timeout handler to vmw_vkms_handle_vblank_timeout(). In addition
to handling vblank events, this function also controls CRC generation.
Remove all the hrtimer-related code from vmwgfx. DRM vblank timers
provides this.
v2:
- only cancel vblank timer in CRTC cleanup if vkms_enabled (Zack)
drm/vmwgfx: Move vblank handling into separate helper
Decouple vblank handling from the underlying hrtimer. This will be
helpful for replacing vmwgfx's vblank timer with DRM's common
implementation.
The new helper vmw_vkms_handle_vblank_timeout() can later be used as
callback for DRM's handle_vblank call as-is. The helper also keeps the
current semantics for restarting the timer. It returns true to restart
the next vblank timeout even if it could not acquire vmwgfx's vblank
lock.
The remaining code in vmw_vkms_vblank_simulate() will be replaced by
the DRM implementation in a later patch.
v2:
- clarify return-value semantics in commit message (Zack)
drm/vmwgfx: Determine lock-waiting timeout from vblank state
Use the calculated duration of a frame as stored in the vblank state
for the lock-waiting timeout. Decouples the waiting from the details
of the vblank implementation. Both values should be equal.
This will be helpful for replacing vmwgfx's vblank timer with DRM's
common implementation.
Ian Dannapel [Thu, 16 Apr 2026 14:42:36 +0000 (16:42 +0200)]
fpga-mgr: Add Efinix SPI programming driver
Add a new driver for loading binary firmware to configuration
RAM using "SPI passive mode" on Efinix FPGAs.
Efinix passive SPI configuration requires chip select to remain asserted
from reset until the complete bitstream and trailing idle clocks have
been transferred, so the driver keeps CS active with cs_change and locks
the SPI bus for the duration of configuration.
Thorsten Blum [Sun, 3 May 2026 10:11:02 +0000 (12:11 +0200)]
ALSA: jack: use scnprintf to improve parse_mask_bits
Use the return value of scnprintf() to keep track of the current string
length and also replace strlcat() with scnprintf(). Return the string
length directly instead of calling strlen(buf).
Phil Pemberton [Thu, 9 Apr 2026 12:20:16 +0000 (13:20 +0100)]
fpga: ts73xx-fpga: add OF match table for device tree probing
The ts73xx-fpga driver currently only matches by platform device name,
which prevents it from being probed when the device is described in a
device tree. Add an of_device_id table so the driver can match against
the "technologic,ts7300-fpga" compatible string.
The TS-7350 and TS-7390 use different FPGAs with a different programming
interface, so while the driver is named "ts73xx-fpga", it doesn't apply
to them.
Phil Pemberton [Thu, 9 Apr 2026 12:20:15 +0000 (13:20 +0100)]
dt-bindings: fpga: Add Technologic Systems TS-7300 FPGA Manager
Add device tree binding documentation for the Altera Cyclone II FPGA
found on Technologic Systems (now EmbeddedTS) TS-7300 boards, programmed
via the memory-mapped interface in the CPLD.
Signed-off-by: Phil Pemberton <philpem@philpem.me.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260409122016.3940462-2-philpem@philpem.me.uk Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
Cássio Gabriel [Fri, 1 May 2026 17:45:14 +0000 (14:45 -0300)]
ALSA: pcmtest: Return -EFAULT on pattern read copy failure
pattern_write() reports -EFAULT when copy_from_user() fails, but
pattern_read() converts copy_to_user() failures into a zero-length read.
That makes a userspace buffer fault look like EOF instead of reporting the
actual error.
Return -EFAULT from pattern_read() when copying the pattern data to
userspace fails, and update the file offset only after a successful copy.
Weiming Shi [Tue, 14 Apr 2026 17:23:39 +0000 (01:23 +0800)]
i2c: stub: Reject I2C block transfers with invalid length
The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]
as the transfer length. The existing check only clamps it to avoid
overrunning the chip->words[256] register array, but does not validate
it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union
i2c_smbus_data.block buffer (34 bytes total). The driver is a
development/test tool (CONFIG_I2C_STUB=m, not built by default)
that must be loaded with a chip_addr= parameter.
A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl
with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing
stub_xfer() to read or write past the end of the union
i2c_smbus_data.block buffer:
BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)
Read of size 1 at addr ffff88800abcfd92 by task exploit/81
Call Trace:
<TASK>
stub_xfer (drivers/i2c/i2c-stub.c:223)
__i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)
i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)
i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)
i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)
__x64_sys_ioctl (fs/ioctl.c:583)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
The bug exists because i2c-stub implements .smbus_xfer directly,
bypassing the I2C_SMBUS_BLOCK_MAX validation in
i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same
function correctly validates against I2C_SMBUS_BLOCK_MAX, but the
I2C_SMBUS_I2C_BLOCK_DATA case does not.
Fix by rejecting transfers with data->block[0] == 0 or
data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with
both the I2C_SMBUS_BLOCK_DATA case in the same function and the
I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().
Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
ALSA: Consistently define pci_device_ids using named initializers
... and PCI device helpers.
The various struct pci_device_id arrays were initialized mostly by list
expressions, some of them using the PCI_DEVICE macros. This isn't easily
readable if you're not into PCI. Using named initializers is more
explicit and thus easier to parse. Also use PCI_DEVICE* helper macros to
assign .vendor, .device, .subvendor and .subdevice where appropriate and
skip explicit assignments of 0 (which the compiler takes care of).
The secret plan is to make struct pci_device_id::driver_data an
anonymous union (similar to
https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
and that requires named initializers. But it's also a nice cleanup on
its own.
This change doesn't introduce changes to the compiled pci_device_id
array. Tested on x86 and arm64.
Ivan Hu [Thu, 30 Apr 2026 07:41:07 +0000 (15:41 +0800)]
x86/efi: Fix graceful fault handling after FPU softirq changes
Since commit d02198550423 ("x86/fpu: Improve crypto performance by
making kernel-mode FPU reliably usable in softirqs"), kernel_fpu_begin()
calls fpregs_lock() which uses local_bh_disable() instead of the
previous preempt_disable(). This sets SOFTIRQ_OFFSET in preempt_count
during the entire EFI runtime service call, causing in_interrupt() to
return true in normal task context.
The graceful page fault handler efi_crash_gracefully_on_page_fault()
uses in_interrupt() to bail out for faults in real interrupt context.
With SOFTIRQ_OFFSET now set, the handler always bails out, leaving EFI
firmware page faults unhandled. This escalates to die() which also sees
in_interrupt() as true and calls panic("Fatal exception in interrupt"),
resulting in a hard system freeze. On systems with buggy firmware that
triggers page faults during EFI runtime calls (e.g., accessing unmapped
memory in GetTime()), this causes an unrecoverable hang instead of the
expected graceful EFI_ABORTED recovery.
Fix by replacing in_interrupt() with !in_task(). This preserves the
original intent of bailing for interrupts or NMI faults, while no longer
falsely triggering from the FPU code path's local_bh_disable().
Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs") Cc: <stable@vger.kernel.org> Signed-off-by: Ivan Hu <ivan.hu@canonical.com>
[ardb: Sashiko spotted that using 'in_hardirq() || in_nmi()' leaves a
window where a softirq may be taken before fpregs_lock() is
called, but after efi_rts_work.efi_rts_id has been assigned,
and any page faults occurring in that window will then be
misidentified as having been caused by the firmware. Instead,
use !in_task(), which incorporates in_serving_softirq(). ] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
drm/bridge: ti-sn65dsi83: add test pattern generation support
Generation of a test pattern output is a useful tool for panel bringup and
debugging, and very simple to support with this chip.
The value of REG_VID_CHA_ACTIVE_LINE_LENGTH_LOW needs to be divided by two
for the test pattern to work in dual LVDS mode. While not clearly stated in
the datasheet, this is needed according to the DSI Tuner [0] output. And
some dual-LVDS panels refuse to show any picture without this division by
two.
Wolfram Sang [Thu, 2 Apr 2026 11:27:06 +0000 (13:27 +0200)]
soc: renesas: Add Renesas R-Car MFIS driver
Renesas R-Car MFIS offers multiple features but most importantly
mailboxes and hwspinlocks. Because they share a common register space
and a common register unprotection mechanism, a single driver was chosen
to handle all dependencies. (MFD and auxiliary bus have been tried as
well, but they failed because of circular dependencies.)
In this first step, the driver implements common register access and a
mailbox controller. hwspinlock support will be added incrementally, once
the subsystem allows out-of-directory drivers.
projects / thirdparty / linux.git / log
