| Age | Commit message (Collapse) | Author |
|---|
|
Both probe paths register their notification handler before assigning
driver_data, which the handler dereferences.
In the devicetree path, the notification IRQ can fire as soon as
devm_request_irq() registers the handler: the interrupt may already be
pending at probe time, for example when a VMM injects the
generation-changed notification while restoring a guest from a snapshot
that was taken before the driver had probed (Firecracker does exactly
this on snapshot restore). The IRQ is also requested with IRQF_SHARED,
so another device sharing the line can trigger the handler just as
early. The handler then calls vmgenid_notify(), which dereferences the
still-NULL driver_data and panics:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.38+ #1 PREEMPT(none)
Hardware name: linux,dummy-virt (DT)
pc : vmgenid_notify.isra.0+0x24/0x8c
lr : vmgenid_of_irq_handler+0x14/0x34
Call trace:
vmgenid_notify.isra.0+0x24/0x8c (P)
vmgenid_of_irq_handler+0x14/0x34
__handle_irq_event_percpu+0x44/0x1bc
handle_irq_event+0x4c/0xb4
handle_fasteoi_irq+0xf8/0x1f8
The ACPI path has the same ordering problem: the handler is installed
with acpi_install_notify_handler() before driver_data is assigned.
ACPI notifications are dispatched asynchronously from a workqueue, so
the window is narrow, but a notification arriving between the two calls
hits the same NULL dereference.
Assign driver_data before registering the handlers. The state is fully
initialized at that point, so the handlers are safe to run. Should
registration fail, the probe error path leaves no dangling pointer
behind: the driver core clears driver_data in device_unbind_cleanup().
Fixes: 7b1bcd6b50a6 ("virt: vmgenid: add support for devicetree bindings")
Fixes: e07606713a90 ("virt: vmgenid: change implementation to use a platform driver")
Cc: stable@vger.kernel.org
Signed-off-by: Zhichen Wang <wangzhichen@manus.ai>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
It was found that AWS SEV-SNP enabled instances are not able to boot with
commit 81256a50aa0f ("x86/mm: Make memremap(MEMREMAP_WB) map memory as
encrypted by default") applied and the reason seems to be the vmgenid
device which requires unencrypted writeable memory.
A similar problem was previously fixed in DRM with commit
7dfede7d7edd ("drm/vmwgfx: Fix guests running with TDX/SEV").
Note, trusting vmgenid device in a Confidential VM is questionable: the
malicious host may intentionally avoid notifying the guest when a copy is
created.
Fixes: 81256a50aa0f ("x86/mm: Make memremap(MEMREMAP_WB) map memory as encrypted by default")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: stable@vger.kernel.org # 6.15+
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
|
|
Optimize data reading for high frequencies by not reading FIFO
count in case of watermark interrupt.
We cannot already read more than watermark samples because of the
timestamping mechanism. It is required to not perturb the timing
between the watermark interrupts. Since we also know there is at
least watermark samples in the FIFO, let's just read these watermark
FIFO samples directly without reading FIFO count in this case.
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The watermark computation was in fact resulting in computing the GCD
of the latencies when both sensors are on. GCD is required because
of the IIO buffer watermark.
Move to use gcd() and update documentation accordingly.
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Sometimes dynamic switch between 1 sensor frame to 2 sensors frame is
not working when there are too much frames already in the FIFO. By
moving accel/gyro on sleep before turning FIFO on, we are storing many
FIFO frames before updating the frame format hitting the bug everytime.
Fix that by always using the 2 sensors frame of 16 bytes. Also update
the hwfifo max watermark reported.
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
When turning accel or gyro on, a sleep is required for letting the
mechanical part stabilize before reporting correct data. Move the
sleep before enabling FIFO data to prevent push of incorrect data.
We need to unlock the driver mutex while sleeping to not block data
of the other sensor if it is running. There is no possible race here
because we are already under IIO mode mutex locked since it is a
IIO buffer callback.
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The dual-channel parts (AD4880/AD4883/AD4884) are built from two
independent ADC dies, each with its own SPI chip select and register
map. They are presented as a single IIO device because the FPGA
interleaves both dies into one DMA stream, so only one direct_reg_access
debugfs file is created and it can only reach channel A's regmap. Channel
B's registers are therefore inaccessible, which blocks bring-up and
debugging of the second die.
Select the target die through the debugfs register address: the low 8
bits are the register offset and the upper bits are the channel index
(0x0nn selects channel A, 0x1nn channel B). A read returns the real
register value of the selected die and each die is addressed
independently; single-channel parts only accept channel 0.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
As documented in Documentation/process/deprecated.rst, the
use of BUG() and BUG_ON() should be avoided as they could
cause a complete system crash, preventing further debugging.
In iio_get_time_ns() and current_timestamp_clock_show(), the
clock type is already validated against supported clock
types prior to these calls, making the default switch
branches expected to be unreachable. Replace these with
WARN_ON_ONCE(1) followed by an error return to avoid a
crash and to log the highly unexpected condition.
Signed-off-by: Rishab Madhugiri <rishab.madhugiri@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Convert deprecated SIMPLE_DEV_PM_OPS() to DEFINE_SIMPLE_DEV_PM_OPS()
and pm_sleep_ptr(). Also replace SIMPLE_DEV_PM_OPS() + EXPORT_SYMBOL_GPL()
with EXPORT_GPL_SIMPLE_DEV_PM_OPS().
This allows us to drop the __maybe_unused annotations from the resume callback.
This is a straightforward cleanup with no functional change intended.
Signed-off-by: Triet Hoang <triet.hoang.dev@gmail.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
Remove stale TODOs from ltr390.c. All features have already been
implemented by Abhash Jha<abhashkumarjha123@gmail.com>'s patches:
[1] Configurable gain and resolution
[2] Suspend/resume support
[3] Support for reading the ALS
[4] Interrupt support
Link: https://git.kernel.org/torvalds/c/13fad2607dad [1]
Link: https://git.kernel.org/torvalds/c/288ce72fb5fc [2]
Link: https://git.kernel.org/torvalds/c/14e0d914a855 [3]
Link: https://git.kernel.org/torvalds/c/7ca4b8957066 [4]
Signed-off-by: Chang Yu <marcus.yu.56@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
iio_dmaengine_buffer_submit_block() computes max_size unconditionally at
the top of the function, but only the fileio branch consumes it - and
that branch already computes it again right where it is used. Drop the
unconditional copy.
No functional change intended.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The BM1390 tries to initialize the AVE_NUM to 110b at the start-up. The
field location is not taken into account, and value is written unsifted.
This causes the AVE_NUM to be initialized to zero.
Use FIELD_PREP() to shift the intended AVE_NUM value to correct field.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: 81ca5979b6ed ("iio: pressure: Support ROHM BU1390")
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
apds9999_init() called devm_add_action_or_reset() at the start
of the function, before register configuration and before enabling the
device via APDS9999_MAIN_CTRL_LS_EN.
If register initialization failed during apds9999_init() (e.g. SMBus
write failures on LS_MEAS_RATE or LS_GAIN), devm_add_action_or_reset()
immediately triggered apds9999_standby(), writing to the control
register on a device that failed initialization and was never enabled.
Fix this by registering devm_add_action_or_reset() only after
APDS9999_MAIN_CTRL_LS_EN is successfully written to the control
register.
Signed-off-by: Surendra Singh Chouhan <kr494167@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The ADE9078 is a polyphase energy metering device that is register
compatible with the ADE9000. The main differences relevant to the driver
are the absence of the on-chip dip/swell detection and slightly different
full-scale ADC codes.
Add a dedicated channel table that omits the swell/dip voltage events and
a matching chip_info describing the ADE9078 full-scale codes. A separate
RMS voltage channel macro variant is added that drops the swell/dip event
spec so the ADE9078 channel table can omit those events.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The driver currently hardcodes the device name and the full-scale ADC
codes used to derive the IIO scale attributes. In preparation for
supporting additional parts of the ADE9000 family, move these
part-specific values into a new struct ade9000_chip_info and retrieve it
via spi_get_device_match_data() at probe time.
The channel table and its size are also referenced through the chip_info
so that parts with a different channel layout can be added without
touching the probe path.
No functional change intended for the ADE9000.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
When an unrecognized proximity status is encountered in aw96103_irq(),
the default case executes a return IRQ_HANDLED. Because this happens
inside the loop over the device's channels, any remaining channels are
left unhandled, causing missed events and stale IRQ status.
Replace the return IRQ_HANDLED statement in the default case with
continue to ensure all channels are processed even if one has an
unexpected status value.
This issue was found via code inspection.
Signed-off-by: Salah Triki <salah.triki@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The calibbias cache (data->calibbias) was updated before the I2C
write to TMP117_REG_TEMP_OFFSET was known to succeed. If the write
failed, the function correctly returned an error, but the driver's
internal cache had already been updated to the new value.
This causes the cache and the actual hardware register to go out of
sync: a subsequent write of the same value would be silently
skipped by the early "if (off == data->calibbias) return 0;" check,
since the cache matches even though the register was never
successfully updated.
Update data->calibbias only after confirming the I2C write
succeeded, so the cache always reflects the actual state of the
device.
Found by code inspection.
Fixes: df041e737a38 ("iio: temperature: add driver support for ti tmp117")
Signed-off-by: Salah Triki <salah.triki@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
A WHOAMI value differing from the one the compatible implies aborts
probe with -ENODEV, which prevents a register-compatible part described
with a fallback compatible from probing at all.
The devicetree compatible is authoritative for which part is fitted:
log the mismatch at info level and continue. The message keeps a
breadcrumb for anyone seeing an unexpected part change on their device
versus the devicetree; tmp117 takes the same trade at the same level
for its fallback matches.
A whoami of 0x00 or 0xff still fails probe: SPI has no transfer-level
ack, so those values mean nothing answered. Otherwise the probe outcome
on mismatch changes for all parts the driver supports. The check sits
before the mismatch comparison; it does not depend on hw->whoami, since
no supported part uses either value (the WHOAMI values the driver
defines span 0x40-0x5C). inv_icm45600 carries the same guard nested in
its mismatch branch.
Tested via a backport to a Fairphone 6 running a 7.1-based kernel: its
ICM-42630 (WHOAMI 0x0C), described with an icm42631 fallback compatible
and matched as icm42631, probes with the one informational line, and
accelerometer, gyroscope and temperature reads work.
Suggested-by: Conor Dooley <conor@kernel.org>
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
When interrupt timestamp interval is not valid, we use an estimated value
that can in rare case be bigger than the interrupt timestamp. This is
obviously wrong, so better use interrupt timestamp in this case.
Fixes: 8f4b627656fa ("iio: inv_sensors: better timestamp alignment when using watermark")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
We've had bugs in the cache code with handling of register numbers with the
top bit set before, add some test cases for this. It's not really worth
fixing up all the individual tests to support a base address, instead
write a specific test that reproduces a bunch of the coverge. Run this on
the rbtree and maple caches which are the only ones that can reasonably
support this case.
Link: https://patch.msgid.link/20260818-regmap-kunit-cache-high-bit-v1-2-7e790676dea3@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
To allow testing of register maps with very large register values add
support for specifying base address to the RAM regmap. Since the config
struct is shared with the raw RAM regmap also update that, though we
will not use it.
Link: https://patch.msgid.link/20260818-regmap-kunit-cache-high-bit-v1-1-7e790676dea3@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
phy_led_triggers_register() frees phy_led_triggers when a speed trigger
registration fails, but leaves the pointer set to the freed allocation
before clearing phy_num_led_triggers.
phy_probe() ignores the registration error. If a later probe step fails,
its error path calls phy_led_triggers_unregister(); normal teardown during
an unbind or MDIO bus removal calls the same helper from phy_remove().
In either case, the trigger count is zero, so the per-trigger unregister
loop is skipped, but the dangling pointer is still freed unconditionally.
Clear the pointer when partial registration cleanup frees the array, and
make phy_led_triggers_unregister() free the array only when its pointer is
non-NULL.
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-7-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
phy_default_setup_single_port() ignores errors from phy_add_port() and
always reports success. If a PHY driver attach_mdi_port() callback fails,
the phy_port is leaked and PHY probing continues without the expected
default port.
Destroy the port and return the error.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-6-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
phy_probe() may fail while querying features or completing other core
initialization after the PHY driver probe callback has succeeded. The
driver core does not run the remove path after a probe error, so
resources that the PHY driver releases in its remove callback are
leaked.
Call the PHY driver remove callback on these failures.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-5-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
phy_probe() sets PHY_READY before calling of_phy_leds(). If LED setup
fails, the error path releases the initialized resources while the PHY
state remains READY even though probing failed.
Set PHY_READY only after LED setup succeeds.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-4-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit 4497f5028675 ("net: phy: Clean the phy_ports after unregistering
the downstream SFP bus") established that an SFP upstream must be
unregistered before its phy_ports are destroyed because SFP callbacks
may access these ports.
phy_setup_ports() does not follow this order when a later port setup
step fails after phy_sfp_probe() succeeds. It destroys the SFP phy_port
and leaves phy_probe() to unregister the upstream later, creating a race
between port destruction and SFP upstream callbacks.
The error unwind is also split across three functions. If
phy_setup_sfp_port() fails, phy_sfp_probe() leaves the upstream
registered and relies on phy_probe() to remove it after
phy_setup_ports() returns.
Make each layer unwind the resources it successfully set up. Unregister
only the upstream in phy_sfp_probe() when SFP port setup fails, since
the failed port has already been destroyed. Add phy_sfp_release() for a
successful SFP probe, and make phy_setup_ports() use it before cleaning
up the remaining ports. Once phy_setup_ports() has rolled back all port
setup, make phy_probe() skip this cleanup.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-3-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
phy_probe() uses one cleanup path for failures at every initialization
stage. This runs cleanup for resources that have not been initialized.
After a successful probe and remove, phy_led_triggers_unregister() can
leave phy_num_led_triggers non-zero after freeing the trigger array. If a
subsequent probe fails before LED trigger registration, the common error
path calls phy_led_triggers_unregister() with a NULL array and stale count,
causing a NULL dereference.
Split the cleanup by initialization stage so each failure path unwinds only
the resources that may have been initialized. Unregister LED triggers
before releasing the SFP upstream and ports, because the LED triggers are
initialized after those resources and must be unwound first.
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Link: https://patch.msgid.link/20260823035600.188864-2-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
aspeed_adc_probe() continues to register ADC resources after deasserting
the shared reset, even if the reset controller reports a failure.
A failed deassertion leaves the hardware unavailable, so stop probing
before installing the cleanup action and enabling the ADC.
Fixes: edf7550a1f93 ("iio: adc: aspeed: Deassert reset in probe")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
iio_dmaengine_buffer_submit_block() counts scatterlist entries with
sg_nents_for_len(), which walks the CPU-side lengths (sg->length), but
then consumes the DMA-side fields (sg_dma_address()/sg_dma_len()).
After dma_map_sgtable() the two views may differ: an IOMMU can coalesce
the mapping so that only the first sgt->nents entries carry valid DMA
addresses, with nents < orig_nents.
On x86 with an IOMMU enabled, a DMABUF block backed by two 1 MiB
system-heap chunks maps to a single 2 MiB IOVA range. The CPU-side
count is 2, so the loop reads one entry past the mapped set and emits a
garbage vec ({addr = ~0, len = 0}). The DMA engine driver rejects the
vec array (prep returns NULL), the fence is signalled with -ENOMEM,
which a userspace poller cannot observe, and the block is left in
ACTIVE state so every further enqueue of it fails with -EBUSY. The
visible symptom is a stream of zero-filled blocks followed by a wedged
buffer.
Platforms without an IOMMU never hit this because nents == orig_nents.
Size the vec array with sgt->nents, i.e. the DMA-mapped view, and stop
the fill loop once bytes_used is covered - which is allowed to be
smaller than the block size - passing the number of vecs actually
filled to dmaengine_prep_peripheral_dma_vec().
One vec per mapped entry is enough since coalescing can only ever
reduce the number of entries. A single mapped entry longer than the
device's maximum segment size would need more than one, but the DMA API
already assumes no single segment exceeds it [1], and splitting a vec
down to the hardware descriptor size is the DMA engine driver's job -
which both current .device_prep_peripheral_dma_vec() implementations
do.
[1]: commit ab2cbeb0ed30 ("iommu/dma: Handle SG length overflow better")
Assisted-by: Claude:claude-fable-5
Fixes: 7a86d469983a ("iio: buffer-dmaengine: Support new DMABUF based userspace API")
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
pm_runtime_set_active() failing in probe() jumps to error_unreg_buffer,
which only calls iio_triggered_buffer_cleanup() -- it does not undo the
iio_device_register() that already succeeded a few lines above. probe()
then returns the error, the devm-managed indio_dev is freed, but the
iio core still has it registered: the sysfs/chardev nodes stay live and
point at freed memory.
Add an error_unreg_dev label that unregisters the iio device before
falling through to the existing buffer cleanup, mirroring the teardown
order already used in lidar_remove().
Fixes: 4ac4e086fd8c ("iio: pulsedlight-lidar-lite: add runtime PM")
Assisted-by: Claude:claude-opus-4
Signed-off-by: Cong Nguyen <congnt264@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
iio_trigger_notify_done_atomic() defers ->reenable() into
trig->reenable_work on the system workqueue, and the worker dereferences
the owning trigger through container_of(). Nothing cancels this work
before iio_trig_release() frees the trigger, so a worker armed by the
last in-flight IRQ can outlive the free and touch freed memory.
Cancel it at the top of iio_trig_release(), which every free path
reaches through the device core's final put_device().
Found by an in-house static analysis tool.
Fixes: 9020ef659885 ("iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
admv1013_read_raw() switches on chan->channel instead of
chan->channel2 when handling IIO_CHAN_INFO_CALIBBIAS. The channel
field only ever holds 0 or 1 (see ADMV1013_CHAN_CALIB()), while the
IIO_MOD_I / IIO_MOD_Q modifiers are stored in channel2. As a result,
the switch always falls through to the default case and calibbias
reads always fail with -EINVAL, even though the corresponding
admv1013_write_raw() path correctly uses channel2 and works as
expected.
Fix the read path to switch on chan->channel2, matching the write
path and the actual channel_spec definition.
Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013")
Signed-off-by: Salah Triki <salah.triki@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
When setting the sampling frequency, the check for `base_freq / 2` is
followed by an independent `if` statement for `base_freq / 4`. If `val`
equals `base_freq / 2`, the second check fails and falls through to the
`else if (val != base_freq)` branch, returning `-EINVAL` erroneously.
Fix this by chaining the checks with `else if`.
Fixes: e0f3fc9b47e6 ("iio: accel: sca3000_core: implemented IIO_CHAN_INFO_SAMP_FREQ")
Signed-off-by: Salah Triki <salah.triki@gmail.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
admv1013_probe() registers a clock notifier whose callback takes st->lock
on POST_RATE_CHANGE. Initialize the mutex before
devm_clk_notifier_register() so the callback cannot observe an
uninitialized lock during probe.
Use devm_mutex_init() so the lock lifetime is tied to the device and
cleanup stays paired with the rest of the managed probe resources.
Fixes: da35a7b526d9 ("iio: frequency: admv1013: add support for ADMV1013")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The serial_number file operations are open coded and never call
debugfs_file_get(), which debugfs_create_file_unsafe() requires.
debugfs_remove_recursive() therefore does not wait for a read in
progress, and unbind frees the iio_dev underneath it.
Use debugfs_create_file() instead.
Fixes: 9aaea09b4cbd ("gyro:adis16136: fix debugfs_simple_attr.cocci warnings")
Signed-off-by: Arka Mondal <arkamondalofficial@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
adis16400_serial_number_fops is open coded and never calls
debugfs_file_get(), so debugfs_remove_recursive() does not wait for a
read in progress and unbind frees the iio_dev underneath it.
Commit ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE
instead of DEFINE_SIMPLE_ATTRIBUTE") converted product_id and
flash_count to DEFINE_DEBUGFS_ATTRIBUTE, which protects itself, but
moved all three files to debugfs_create_file_unsafe().
serial_number prints three registers as "%.4x-%.4x-%.4x" and
DEFINE_DEBUGFS_ATTRIBUTE() formats a single u64, so it cannot be
converted without changing what the file returns. adis16475 and
adis16550 already use debugfs_create_file() for their open coded
files. Use it here too.
Fixes: ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE")
Signed-off-by: Arka Mondal <arkamondalofficial@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The firmware_revision and firmware_date file operations are open coded
and never call debugfs_file_get(), which debugfs_create_file_unsafe()
requires. debugfs_remove_recursive() therefore does not wait for a read
in progress, and unbind frees the iio_dev underneath it.
Use debugfs_create_file() instead.
Fixes: 9bf94f836e32 ("imu:adis16480: fix debugfs_simple_attr.cocci warnings")
Signed-off-by: Arka Mondal <arkamondalofficial@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The ZYNQ XADC alarm IRQ handler queues zynq_unmask_work via
schedule_delayed_work(); that work is cleared by a devm callback.
Register the devm callback before devm_request_irq() so the devres LIFO
teardown frees the IRQ first, ensuring the handler can no longer queue
work by the time the workqueue is cleared. Otherwise the handler could
re-arm the work and run it after the xadc structure has been freed.
This issue was found by an in-house static analysis tool.
Fixes: 2a9685d1a3b7 ("iio: adc: xilinx: use more devres helpers and remove remove()")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Reviewed-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
iio_push_to_buffers_with_ts_unaligned() leaks uninitialized heap memory
to userspace if the data passed in is not a multiple of 8 bytes and the
timestamp is enabled. Specify __GFP_ZERO for the devm_krealloc()
to ensure any extra space is cleared.
Fixes: 95ec3fdf2b79 ("iio: core: Introduce iio_push_to_buffers_with_ts_unaligned()")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260529121005.1470-1-kimjinseob88%40gmail.com
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The firmware parser reads a length from the binary header and then uses
it to walk six-byte register/value entries. A truncated firmware image
can make the parser read beyond the copied firmware buffer. A value
smaller than the four-byte count field also underflows, producing a very
large length.
Read the little-endian field with get_unaligned_le32(), as previously
proposed by David Lechner. Validate the header size, reject an
underflowed length, ensure the resulting payload is contained in the
firmware image, and require it to contain whole register/value entries.
Fixes: 07b241262dca ("iio: proximity: aw96103: Add support for aw96103/aw96105 proximity sensor")
Link: https://lore.kernel.org/r/20260314-iio-proximity-aw96103-fix-firmware-read-v1-1-c74fe9ccd82b@baylibre.com
Cc: stable@vger.kernel.org
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
adf4377_clk_register() fills in init.parent_data, and assumes that
init.parent_names is NULL. However, the latter is uninitialized, and
thus may cause a crash.
Similarly, adf4377_clk_register() fills in only parent_data.fw_name,
leaving other members of the clk_parent_data structure uninitialized.
Make sure all members are fully initialized, to fix such bugs, and to
avoid future breakage when converting drivers to a different method for
specifying the parents.
Fixes: 60e5448ddbec2dc2 ("iio: frequency: adf4377: add clk provider support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Joshua Crofts <joshua.crofts1@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The proximity channels were previously defined with 12 realbits.
However, PROXDIFF is read from RegDiffMsb (0x65) and RegDiffLsb
(0x66). The SX9324 datasheet assigns bits 7:0 of each register to
PROXDIFF and documents it as a signed two's-complement value
(Revision 3, Section 8, Table 8, page 43). In contrast, RegOffsetMsb
explicitly marks bits 7:6 as reserved. Thus, PROXDIFF is a 16-bit
signed value.
With realbits = 12, sx_common_read_proximity() uses bit 11 as the
sign bit in sign_extend32(), causing samples outside the 12-bit
signed range to wrap into the [-2048, 2047] range.
Correct the realbits value to 16 to accurately reflect the hardware.
Tested on an SX9324-based device: a phase 0 DIFF readback of 0x7fff
was reported as -1 before this change and as 32767 afterward.
Fixes: 4c18a890dff8 ("iio:proximity:sx9324: Add SX9324 support")
Cc: stable@vger.kernel.org
Signed-off-by: Zhang Jie <zhangjie14@huaqin.corp-partner.google.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The driver performs a sanity check for an array size, when converting a
register value to an array index. The check incorrectly accepts the
sizeof(array) as a last index, when last valid index should be
sizeof(array) - 1.
Fix the check by bailing out when index >= sizeof(array).
Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
When BU27034 fails to read gain value at integration-time setting, it
returns 0. This leaves caller unaware of the fact that setting the
integration time failed.
Fix this by returning the relevant error instead of zero.
Fixes: 439c2cef8157 ("iio: bu27034: simplify using guard(mutex)")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The data reading function ignores the cached error value, and
unconditionally returns 0. Return cached 'ret' -value after stopping
the measurement so user knows if read failed and data is garbage.
Fixes: 534674463a59 ("iio: bm1390: simplify using guard(mutex)")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The BD79703 has adds IIO_CHAN_INFO_SCALE in the info_mask_shared_by_type
so users can read the scale, which depends on the used reference
voltage. This, however, enables users to try writing the scale as well.
This isn't really supported but the bd79703_write_raw() does not check
the mask, and if written scale values pass the validation, the driver
will proceed writing the DAC value when users writes the scale.
Prevent the unsupported scale setting and return an error.
Fixes: af6aca656a85 ("iio: dac: Support ROHM BD79703 DAC")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The bd79124_start_measurement() and bd79124_stop_measurement() ignore
errors from the regmap reads, causing potential use of uninitialized
stack variable when deciding whether the measurement is already
started/stopped. The bd79124_stop_measurement() may also ignore failure
to clear the sequencer state bits, which may make the hardware to ignore
the setting and leave hardware and driver states out of sync.
Check the return value and bail-out if error is detected.
Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The ROHM BD79124 has pins which can be configured as GPOs or as ADC
inputs. The bd79124gpo_set_multiple() is intended to ensure that a pin
which is requested to be toggled, is indeed configured as a GPO.
The check uses XOR, causing it to fail if mask is not exactly same as
GPO configuration. Eg, if not all GPOs are asked to be toggled at once.
Fix this by checking that mask does not contain pins that are not
configured as GPO, allowing some of the pins which are configured as
GPO to be untouched.
Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
|
The alarm limit register on BD79124 span to two consecutive registers.
The first register for high-limit containing also hysteresis
configuration. The initialization in driver writes only one 8-bit
register, overwriting the hysteresis and leaving the other limit
register uninitialized.
Fix the limit initialization by using the bd79124_write_int_to_reg(),
which correctly initializes the limit on both of the registers.
Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
