* Re: [PATCH v16 05/10] x86: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Borislav Petkov @ 2026-06-18 0:41 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo,
dave.hansen, hpa, robh, saravanak, akpm, bhe, rppt,
pasha.tatashin, pratyush, ruirui.yang, rdunlap, peterz, feng.tang,
dapeng1.mi, kees, elver, kuba, lirongqing, ebiggers, paulmck,
leitao, coxu, Liam.Howlett, ryan.roberts, osandov, jbohac,
cfsworks, tangyouling, sourabhjain, ritesh.list, adityag,
liaoyuanhong, seanjc, fuqiang.wang, ardb, chenjiahao16, guoren,
x86, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, devicetree, kexec
In-Reply-To: <20260608073459.3119290-6-ruanjinjie@huawei.com>
On Mon, Jun 08, 2026 at 03:34:54PM +0800, Jinjie Ruan wrote:
> Subject: Re: [PATCH v16 05/10] x86: kexec_file: Use crash_prepare_headers() helper to simplify code
Use proper subject prefix: "x86/crash: ..."
> Use the newly introduced crash_prepare_headers() function to replace
> the existing prepare_elf_headers(), allocate cmem and exclude crash kernel
> memory in the crash core, which reduce code duplication.
>
> Only the following three architecture functions need to be implemented:
> - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
> to pre-count the max number of memory ranges.
>
> - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
> to collect the memory ranges and fills them into cmem.
>
> - arch_crash_exclude_ranges(). Exclude the low 1M for x86.
>
> By the way, remove the unused "nr_mem_ranges" in
s/By the way/While at it/
> arch_crash_handle_hotplug_event().
>
> Cc: Thomas Gleixner <tglx@kernel.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Vivek Goyal <vgoyal@redhat.com>
> Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Acked-by: Baoquan He <bhe@redhat.com>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/x86/kernel/crash.c | 89 +++++------------------------------------
> 1 file changed, 11 insertions(+), 78 deletions(-)
With those nitpicks above addressed:
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: convert altera i2c to dt-schema
From: Andi Shyti @ 2026-06-18 0:11 UTC (permalink / raw)
To: Chaitanya Sabnis
Cc: wsa, thor.thayer, robh, krzk+dt, conor+dt, linux-i2c, devicetree,
linux-kernel
In-Reply-To: <20260505053201.5795-1-chaitanya.msabnis@gmail.com>
Hi Chaitanya,
On Tue, May 05, 2026 at 11:02:01AM +0530, Chaitanya Sabnis wrote:
> Convert the Altera SoftIP I2C Controller bindings from legacy text
> format to modern dt-schema (YAML).
>
> The hardware constraints and properties remain identical. The example
> node was updated to use a standard 32-bit address space to clear
> compilation warnings.
>
> Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
merged to i2c/i2c-for-7.2
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v5 7/8] arm64: dts: imx8: add camera parallel interface (CPI) node
From: sashiko-bot @ 2026-06-17 23:45 UTC (permalink / raw)
To: Frank.Li; +Cc: devicetree, Frank.Li, imx, robh, conor+dt
In-Reply-To: <20260617-imx8qxp_pcam-v5-7-7fa6c8e7fba7@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The devicetree routes the parallel CPI to `port@4`, contradicting the `fsl,imx8qxp-isi` binding which explicitly documents `port@6`.
- [Low] Devicetree validation failure (dtbs_check) due to missing `ports` property in `parallel_cpi` base node for imx8qm.
--
commit 0f41e0622cccbe3c369609c51df0eb689a3de5d4
Author: Frank Li <Frank.Li@nxp.com>
arm64: dts: imx8: add camera parallel interface (CPI) node
Add the camera parallel interface (CPI) base node to imx8-ss-img.dtsi and
extend it with routing in imx8qxp-ss-img.dtsi.
> diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> index a72b2f1c4a1b2..b504f99f6acdb 100644
> --- a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
[ ... ]
> @@ -222,6 +222,19 @@ irqsteer_parallel: irqsteer@58260000 {
> status = "disabled";
> };
>
> + parallel_cpi: cpi@58261000 {
> + compatible = "fsl,imx8qxp-pcif";
> + reg = <0x58261000 0x1000>;
> + clocks = <&pi0_pxl_lpcg IMX_LPCG_CLK_0>,
> + <&pi0_ipg_lpcg IMX_LPCG_CLK_4>;
> + clock-names = "pixel", "ipg";
> + assigned-clocks = <&clk IMX_SC_R_PI_0 IMX_SC_PM_CLK_PER>;
> + assigned-clock-parents = <&clk IMX_SC_R_PI_0_PLL IMX_SC_PM_CLK_PLL>;
> + assigned-clock-rates = <160000000>;
> + power-domains = <&pd IMX_SC_R_PI_0>;
> + status = "disabled";
> + };
[Severity: Low]
Will this cause dtbs_check failures for other platforms that include this
file?
Since this base node definition lacks a ports property, validating platforms
like imx8qm that include this file without appending ports might trigger a
dt-schema warning. The dt-schema tool unconditionally validates disabled
nodes, and fsl,imx93-pcif.yaml requires the ports property.
[ ... ]
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-ss-img.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-ss-img.dtsi
> index 232cf25dadfcd..5aae15540d6cb 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp-ss-img.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp-ss-img.dtsi
[ ... ]
> @@ -62,6 +62,14 @@ isi_in_2: endpoint {
> remote-endpoint = <&mipi_csi0_out>;
> };
> };
> +
> + port@4 {
> + reg = <4>;
> +
> + isi_in_4: endpoint {
> + remote-endpoint = <¶llel_cpi_out>;
> + };
> + };
[Severity: Medium]
Does connecting this to port 4 conflict with the documented binding?
Documentation/devicetree/bindings/media/fsl,imx8qxp-isi.yaml explicitly
documents port 6 as the CSI-2 Parallel RX. While port 4 is technically
correct for the imx8-isi crossbar driver (which only supports 5 ports),
this setup directly contradicts the documented schema.
Should the binding be updated or the devicetree corrected to maintain
consistency?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-imx8qxp_pcam-v5-0-7fa6c8e7fba7@nxp.com?part=7
^ permalink raw reply
* Re: [PATCH v3 0/5] iio: adc: Add support for LTC2378 and similar ADCs
From: David Lechner @ 2026-06-17 22:46 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, andy, robh, krzk+dt, conor+dt,
pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <cover.1781661028.git.marcelo.schmitt@analog.com>
On 6/16/26 9:02 PM, Marcelo Schmitt wrote:
> This patch series adds support for LTC2378 and similar low noise, low power,
> high speed, successive approximation register (SAR) ADCs. These ADCs are similar
> among each other, varying mainly on the amount of precision bits, maximum sample
> rate, and input configuration (either fully differential or pseudo-differential).
>
> The first patch adds device tree documentation for LTC2378.
>
> The second patch enables single-shot sample read with a GPIO connected
> to the LTC2378 CNV pin.
>
> The third patch extends IIO DMAengine buffer interface to make
> sampling_frequency and sampling_frequency_available buffer attributes.
>
> The fourth patch enables high-speed data captures with SPI offloading.
> The setup is similar to AD4030, with a specialized PWM generator being used both
> for SPI offload triggering and conversion start signaling.
>
> The last support patch enables running buffered data captures without SPI offloading.
>
> Even though these parts are somewhat similar to AD4000, the wiring configuration
> for LTC parts is different as well as the available HDL for high speed sample
> rate mode. Because of that, I propose creating a new device driver for
> supporting LTC2378-like devices.
>
> Specifications can be found at:
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/233818fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236416fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236418f.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236716fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236718f.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236816f.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236818f.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/236918fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237016fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237616fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237618fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237620fb.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237716fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237718fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237720fb.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237816fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237818fa.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237820fb.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/237918fb.pdf
> Link: https://www.analog.com/media/en/technical-documentation/data-sheets/238016fb.pdf
Putting `Link:` tags like this in the cover letter will cause b4 to apply all of these
to all patches in the series, so we don't want to do that. I think it is enough that
they are already in the code, we don't need to list them again here.
^ permalink raw reply
* Re: [PATCH v3 5/5] iio: adc: ltc2378: Enable triggered buffer data capture
From: David Lechner @ 2026-06-17 22:39 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, andy, robh, krzk+dt, conor+dt,
pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <22248e8ba646fbe8edfc87e2b9be527632d5b48c.1781661028.git.marcelo.schmitt@analog.com>
On 6/16/26 9:04 PM, Marcelo Schmitt wrote:
> Enable users to run triggered data captures with LTC2378 and similar ADCs.
>
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---
> Change log v2 -> v3:
> - Extracted from main driver file into a separate buffer-specific containment.
>
> drivers/iio/adc/ltc2378-lib-core.c | 17 +++++++-
> drivers/iio/adc/ltc2378-triggered-buffer.c | 49 ++++++++++++++++++++++
> drivers/iio/adc/ltc2378.h | 15 +++++++
> 3 files changed, 80 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iio/adc/ltc2378-triggered-buffer.c
>
> diff --git a/drivers/iio/adc/ltc2378-lib-core.c b/drivers/iio/adc/ltc2378-lib-core.c
> index 1160f4324d01..ec83e9f2ae81 100644
> --- a/drivers/iio/adc/ltc2378-lib-core.c
> +++ b/drivers/iio/adc/ltc2378-lib-core.c
> @@ -18,7 +18,7 @@ int ltc2378_lib_buffer_setup(struct iio_dev *indio_dev, struct ltc2378_state *st
>
> ret = __ltc2378_set_offload_ops(st);
> if (ret == -EOPNOTSUPP)
> - return 0; /* Let device setup complete without buffer support */
> + goto trigger_buf_setup;
>
> if (!ret)
> ret = st->ops->buffer_setup(indio_dev, st);
> @@ -27,6 +27,21 @@ int ltc2378_lib_buffer_setup(struct iio_dev *indio_dev, struct ltc2378_state *st
> return dev_err_probe(dev, ret, "error on SPI offload setup\n");
>
> return 0;
> +
> +trigger_buf_setup:
> + ret = __ltc2378_set_triggered_buf_ops(st);
> + if (ret == -EOPNOTSUPP)
> + return 0; /* Let device setup complete without buffer support */
> +
> + if (!ret)
> + ret = st->ops->buffer_setup(indio_dev, st);
> +
> + if (ret)
> + return dev_err_probe(dev, ret, "error on buffer setup\n");
This is repeating the code above. Seems like it would be better without
the goto.
> +
> + st->chans[st->num_iio_chans++] = IIO_CHAN_SOFT_TIMESTAMP(1);
Adding a channel here seems messy. I still think static const channel
data would be better. But at least would be better if this was moved
to the same function as the other channel setup.
> +
> + return 0;
> }
> EXPORT_SYMBOL_NS_GPL(ltc2378_lib_buffer_setup, "IIO_LTC2378");
>
> diff --git a/drivers/iio/adc/ltc2378-triggered-buffer.c b/drivers/iio/adc/ltc2378-triggered-buffer.c
> new file mode 100644
> index 000000000000..d1d788fb5cb4
> --- /dev/null
> +++ b/drivers/iio/adc/ltc2378-triggered-buffer.c
> @@ -0,0 +1,49 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2026 Analog Devices, Inc.
> + * Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
> + */
> +
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/triggered_buffer.h>
> +#include <linux/iio/trigger_consumer.h>
> +
> +#include <ltc2378.h>
> +
> +static irqreturn_t ltc2378_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct ltc2378_state *st = iio_priv(indio_dev);
> + int ret;
> +
> + ret = ltc2378_convert_and_acquire(st);
> + if (ret < 0)
> + goto err_out;
As mentioned elsewhere, SPI xfer size may be 2 or 4 bytes, but
we are always pushing 4 bytes, so this only works on little-endian
architecture.
I think best would be to have storagesize = 16 when appropriate to
avoid having to manually handle this.
> +
> + iio_push_to_buffers_with_ts(indio_dev, &st->scan, sizeof(st->scan),
> + pf->timestamp);
> +
> +err_out:
> + iio_trigger_notify_done(indio_dev->trig);
> + return IRQ_HANDLED;
> +}
> +
^ permalink raw reply
* Re: [PATCH v5 2/8] media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
From: Sakari Ailus @ 2026-06-17 22:36 UTC (permalink / raw)
To: Frank.Li
Cc: Mauro Carvalho Chehab, Michael Riesch, Laurent Pinchart, Frank Li,
Martin Kepplinger-Novakovic, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-media, linux-kernel,
imx, devicetree, linux-arm-kernel
In-Reply-To: <20260617-imx8qxp_pcam-v5-2-7fa6c8e7fba7@nxp.com>
Hi Frank,
Thanks for the patch.
On Wed, Jun 17, 2026 at 03:50:12PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Many V4L2 subdev drivers implement the same registration and media pad
> setup logic for simple pipelines consisting of a single sink pad and a
> single source pad. As a result, the same boilerplate code is duplicated
> across multiple drivers.
>
> Introduce a common helper library for 1-to-1 subdevs to encapsulate the
> registration, media entity initialization, and cleanup paths. Drivers
> can embed a struct v4l2_subdev_1to1 instance and use the provided helper
> APIs instead of open-coding the setup sequence.
I appreciate your efforts in trying to reduce the amount of code drivers
need simply to get things done but I think there are a few issues with the
approach taken in this patch:
- The new helpers aren't generic enough, but require two pads; one sink,
one source. You could provide special helpers for just this case, but
right now it looks like that if there's something you need that the
helper assumes you don't, you can't use the helper at all. In other
words, more modularity would be nice.
- The new helper should work with the existing types and not add new types
(struct v4l2_subdev_1to1).
- There should be a way to provide default V4L2 fwnode endpoint
configuration as well as to validate the obtained configuration.
I don't have a good proposal to address the above but at least one way I
can think of making error handling easier would be to use devm_() for
teardown in more places we to today. That certainly does have its own
issues though.
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v3 4/5] iio: adc: ltc2378: Enable high-speed data capture
From: David Lechner @ 2026-06-17 22:33 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, andy, robh, krzk+dt, conor+dt,
pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <9f173c47928446aa3e900cf0becb6130dd76846b.1781661028.git.marcelo.schmitt@analog.com>
On 6/16/26 9:04 PM, Marcelo Schmitt wrote:
> Make use of SPI transfer offloading to speed up data capture, enabling data
> acquisition at faster sample rates (up to 2 MSPS).
>
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---
> Change log v2 -> v3:
> - Fixed the evaluation loop conditions for CNV PWM and SPI Engine trigger PWM,
> avoiding potential infinite loop if and CPU stall.
> - Added comment to about initial PWM disable.
> - Adjusted SPI offload setup initialization to not print error on a valid condition.
> - Fully initialize IIO channel scan_type.
> - Reworked to make offload support not imply all dependencies to be built in.
> - Made sampling_frequency a buffer attribute.
> - Made offload support not require DMA and other features to be built in.
> - Now using same scan_type configuration for all use cases.
>
> drivers/iio/adc/Kconfig | 19 ++
> drivers/iio/adc/Makefile | 6 +
> drivers/iio/adc/ltc2378-lib-core.c | 35 +++
> drivers/iio/adc/ltc2378-offload-buffer.c | 305 +++++++++++++++++++++++
> drivers/iio/adc/ltc2378.c | 46 ++++
> drivers/iio/adc/ltc2378.h | 42 ++++
> 6 files changed, 453 insertions(+)
> create mode 100644 drivers/iio/adc/ltc2378-lib-core.c
> create mode 100644 drivers/iio/adc/ltc2378-offload-buffer.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 2b8203451367..f96d9262b891 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -944,6 +944,9 @@ config LTC2378
> tristate "Analog Devices LTC2378 ADC driver"
> depends on SPI
> depends on GPIOLIB
> + select LTC2378_LIB
> + select LTC2378_LIB_OFFLOAD_BUFFER if SPI_OFFLOAD && PWM && SPI_OFFLOAD_TRIGGER_PWM && IIO_BUFFER && IIO_BUFFER_DMAENGINE
> + select LTC2378_LIB_TRIGGERED_BUFFER if IIO_BUFFER
> help
> Say yes here to build support for Analog Devices LTC2378-20 and
> similar analog to digital converters.
> @@ -2027,3 +2030,19 @@ config XILINX_AMS
> xilinx-ams.
>
> endmenu
> +
> +config LTC2378_LIB
> + tristate
> + help
> + Say yes here to build support for buffered data capture with LTC2378
> +
> +config LTC2378_LIB_OFFLOAD_BUFFER
> + bool
> + help
> + Say yes here to build support for high speed data capture with LTC2378
> +
> +config LTC2378_LIB_TRIGGERED_BUFFER
> + bool
> + select IIO_TRIGGERED_BUFFER
> + help
Why do these need to be compile-time options to only select one or the other?
In all other SPI offload ADCs we've done so far, they always support both and
gets selected at runtime based on devicetree config.
> + Say yes here to build support for buffered data capture with LTC2378
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 1814fb78dde3..109cd39237c9 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -82,6 +82,12 @@ obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
> obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
> obj-$(CONFIG_LTC2309) += ltc2309.o
> obj-$(CONFIG_LTC2378) += ltc2378.o
> +
> +ltc2378_lib-y += ltc2378-lib-core.o
> +ltc2378_lib-$(CONFIG_LTC2378_LIB_OFFLOAD_BUFFER) += ltc2378-offload-buffer.o
> +ltc2378_lib-$(CONFIG_LTC2378_LIB_TRIGGERED_BUFFER) += ltc2378-triggered-buffer.o
> +obj-$(CONFIG_LTC2378_LIB) += ltc2378_lib.o
Why do these need to be split into separate files? The driver isn't that
long, so seems better to just do it all in one file to make it easier to
read.
> +
> obj-$(CONFIG_LTC2471) += ltc2471.o
> obj-$(CONFIG_LTC2485) += ltc2485.o
> obj-$(CONFIG_LTC2496) += ltc2496.o ltc2497-core.o
> diff --git a/drivers/iio/adc/ltc2378-lib-core.c b/drivers/iio/adc/ltc2378-lib-core.c
> new file mode 100644
> index 000000000000..1160f4324d01
> --- /dev/null
> +++ b/drivers/iio/adc/ltc2378-lib-core.c
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Analog Devices LTC2378 ADC series driver
> + *
> + * Copyright (C) 2026 Analog Devices Inc.
> + * Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/iio/iio.h>
> +
> +#include "ltc2378.h"
> +
> +int ltc2378_lib_buffer_setup(struct iio_dev *indio_dev, struct ltc2378_state *st)
> +{
> + struct device *dev = &st->spi->dev;
> + int ret;
> +
> + ret = __ltc2378_set_offload_ops(st);
> + if (ret == -EOPNOTSUPP)
> + return 0; /* Let device setup complete without buffer support */
> +
> + if (!ret)
> + ret = st->ops->buffer_setup(indio_dev, st);
> +
> + if (ret)
> + return dev_err_probe(dev, ret, "error on SPI offload setup\n");
Would be better to just return early instead of doing the !ret check.
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_NS_GPL(ltc2378_lib_buffer_setup, "IIO_LTC2378");
> +
...
> diff --git a/drivers/iio/adc/ltc2378.c b/drivers/iio/adc/ltc2378.c
> index 88582bdcd6a6..bf17b202230b 100644
> --- a/drivers/iio/adc/ltc2378.c
> +++ b/drivers/iio/adc/ltc2378.c
> @@ -17,6 +17,7 @@
> #include <linux/regulator/consumer.h>
> #include <linux/spi/spi.h>
> #include <linux/types.h>
> +#include <linux/units.h>
>
> #include <linux/iio/iio.h>
> #include <linux/iio/types.h>
> @@ -26,120 +27,160 @@
> static const struct ltc2378_chip_info ltc2338_18_chip_info = {
> .name = "ltc2338-18",
> .resolution = 18,
> + .max_sample_rate_hz = HZ_PER_MHZ,
1 * HZ_PER_MHZ would make a bit more sense
> + .tconv_ns = 527,
> .bipolar = true,
> };
>
^ permalink raw reply
* Re: [PATCH v3 2/5] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs
From: David Lechner @ 2026-06-17 22:18 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, andy, robh, krzk+dt, conor+dt,
pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <5c18e7a370119ddfd5faefe147b294b39f78894a.1781661028.git.marcelo.schmitt@analog.com>
On 6/16/26 9:03 PM, Marcelo Schmitt wrote:
> Support for LTC2378-20 and similar analog-to-digital converters.
>
...
> +static int ltc2378_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct iio_dev *indio_dev;
> + struct ltc2378_state *st;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + st = iio_priv(indio_dev);
> + st->spi = spi;
> +
> + ret = devm_regulator_get_enable_read_voltage(dev, "ref");
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to read ref regulator\n");
> +
> + st->ref_uV = ret;
add blank line here
> + st->info = spi_get_device_match_data(spi);
> + if (!st->info)
> + return -EINVAL;
> +
> + indio_dev->name = st->info->name;
> + indio_dev->info = <c2378_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + st->cnv_gpio = devm_gpiod_get(dev, "cnv", GPIOD_OUT_LOW);
> + if (IS_ERR(st->cnv_gpio))
> + return dev_err_probe(dev, PTR_ERR(st->cnv_gpio),
> + "failed to get CNV GPIO");
> +
> + st->num_iio_chans = 0;
> + st->chans[st->num_iio_chans++] = (struct iio_chan_spec) {
Why can't we make this static const (part of chip info) like we do in most
drivers?
> + .type = IIO_VOLTAGE,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE),
> + .scan_index = 0,
> + .scan_type = {
> + .format = st->info->bipolar ? IIO_SCAN_FORMAT_SIGNED_INT :
> + IIO_SCAN_FORMAT_UNSIGNED_INT,
> + .realbits = st->info->resolution,
> + /*
> + * Buffer elements could be 16-bit for low precision
> + * parts. Though, using more storage bits allows keeping
> + * the same scan_type configuration for both types of
> + * buffer support.
> + */
Won't this make non-SPI offload buffered reads more complicated later?
I.e. have to shift the value or not before pushing to buffers depending
on CPU endianness.
> + .storagebits = 32,
> + },
> + };
> +
> + st->xfer.rx_buf = &st->scan.data;
> + st->xfer.len = st->info->resolution > 16 ? 4 : 2;
Can use spi_bpw_to_bytes() here.
> + st->xfer.bits_per_word = st->info->resolution;
> +
> + indio_dev->channels = st->chans;
> + indio_dev->num_channels = st->num_iio_chans;
> +
> + return devm_iio_device_register(&spi->dev, indio_dev);
> +}
> +
...
> diff --git a/drivers/iio/adc/ltc2378.h b/drivers/iio/adc/ltc2378.h
> new file mode 100644
> index 000000000000..a3a69351de6c
> --- /dev/null
> +++ b/drivers/iio/adc/ltc2378.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Analog Devices LTC2378 and similar ADCs common definitions and properties
> + * Copyright (C) 2026 Analog Devices, Inc.
> + * Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
> + */
> +
> +#ifndef __DRIVERS_IIO_ADC_LTC2378_H__
> +#define __DRIVERS_IIO_ADC_LTC2378_H__
> +
> +#include <linux/iio/iio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/delay.h>
> +#include <linux/spi/spi.h>
> +#include <linux/types.h>
> +#include <linux/units.h>
> +
> +#define LTC2378_TDSDOBUSYL_NS 5
> +#define LTC2378_TBUSYLH_NS 13
> +#define LTC2378_TCNV_HIGH_NS 20
> +
> +struct ltc2378_chip_info {
> + const char *name;
> + int resolution;
> + bool bipolar;
> +};
> +
> +struct ltc2378_state {
> + const struct ltc2378_chip_info *info;
> + struct gpio_desc *cnv_gpio;
> + struct spi_device *spi;
> + struct spi_transfer xfer;
> + unsigned int num_iio_chans;
> + struct iio_chan_spec chans[2]; /* 1 physical chan + 1 timestamp chan */
> + int ref_uV;
> +
> + /*
> + * DMA (thus cache coherency maintenance) requires the
> + * transfer buffers to live in their own cache lines.
> + */
> + struct {
> + union {
> + u16 sample_buf16;
> + u32 sample_buf32;
> + } data;
> + aligned_s64 timestamp;
> + } scan __aligned(IIO_DMA_MINALIGN);
> +};
> +
> +static inline int ltc2378_convert_and_acquire(struct ltc2378_state *st)
> +{
> + int ret;
> +
> + /* Cause a rising edge of CNV to initiate a new ADC conversion */
> + gpiod_set_value_cansleep(st->cnv_gpio, 1);
> + fsleep(4);
> + ret = spi_sync_transfer(st->spi, &st->xfer, 1);
> + gpiod_set_value_cansleep(st->cnv_gpio, 0);
> +
> + return ret;
> +}
> +
> +#endif /* __DRIVERS_IIO_ADC_LTC2378_H__ */
Why do we need a header for this stuff? If there is a good reason
the commit message should explain it. Otherwise, it makes the driver
harder to read.
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: iio: adc: Add ltc2378
From: David Lechner @ 2026-06-17 22:04 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, andy, robh, krzk+dt, conor+dt,
pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <f9e88abdbd23df8039282497a81d3c8698a10665.1781661028.git.marcelo.schmitt@analog.com>
On 6/16/26 9:03 PM, Marcelo Schmitt wrote:
> Document how to describe LTC2378-20 and similar ADCs in device tree.
>
...
> + vdd-supply:
> + description: A 2.5V supply that powers the chip (VDD).
> +
> + ovdd-supply:
> + description:
> + A 1.71V to 5.25V supply that sets the logic level for digital interface.
> +
> + ref-supply:
> + description:
> + A 2.5V to 5.1V supply for the reference input (REF).
> +
> + cnv-gpios:
> + description:
> + When provided, this property indicates the GPIO that is connected to the
> + CNV pin.
> + maxItems: 1
Missing pwms property for when CNV pin is connected to PWM.
> +
> + interrupts:
> + description:
> + Interrupt for signaling the completion of conversion results. The active
> + low signal provided on the BUSY pin asserts when ADC conversions finish.
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - vdd-supply
> + - ovdd-supply
> + - ref-supply
I only looked at LTC2338-18, but it has a REFIN, which is optional.
Nothing named REF that is required.
^ permalink raw reply
* [PATCH 3/3] dt-bindings: spi: nxp,imx94-xspi: add DMA properties
From: han.xu @ 2026-06-17 21:55 UTC (permalink / raw)
To: Han Xu, Haibo Chen, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-spi, imx, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260617215520.3327836-1-han.xu@oss.nxp.com>
From: Han Xu <han.xu@nxp.com>
Add dmas and dma-names to describe TX and RX DMA channels for the i.MX94
XSPI controller.
Signed-off-by: Han Xu <han.xu@nxp.com>
---
.../devicetree/bindings/spi/nxp,imx94-xspi.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/nxp,imx94-xspi.yaml b/Documentation/devicetree/bindings/spi/nxp,imx94-xspi.yaml
index 16a0598c6d033..ccf841f194c06 100644
--- a/Documentation/devicetree/bindings/spi/nxp,imx94-xspi.yaml
+++ b/Documentation/devicetree/bindings/spi/nxp,imx94-xspi.yaml
@@ -30,6 +30,16 @@ properties:
- const: base
- const: mmap
+ dmas:
+ items:
+ - description: Transmit DMA
+ - description: Receive DMA
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
interrupts:
items:
- description: interrupt for EENV0
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: imx94-xspi: add the DMA channels
From: han.xu @ 2026-06-17 21:55 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Han Xu, devicetree, imx, linux-arm-kernel, linux-kernel
From: Han Xu <han.xu@nxp.com>
Add the DMA channels for iMX94 XSPI controller.
Signed-off-by: Han Xu <han.xu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx94.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index c460ece6070f8..9de1b9754450e 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -820,6 +820,8 @@ xspi1: spi@42b90000 {
#size-cells = <0>;
clocks = <&scmi_clk IMX94_CLK_XSPI1>;
clock-names = "per";
+ dmas = <&edma2 27 0 0>, <&edma2 28 0 FSL_EDMA_RX>;
+ dma-names = "tx", "rx";
status = "disabled";
};
@@ -836,6 +838,8 @@ xspi2: spi@42be0000 {
#size-cells = <0>;
clocks = <&scmi_clk IMX94_CLK_XSPI2>;
clock-names = "per";
+ dmas = <&edma4 42 0 0>, <&edma4 43 0 FSL_EDMA_RX>;
+ dma-names = "tx", "rx";
status = "disabled";
};
};
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH v3 3/5] iio: buffer: Extend DMAengine buffer interfaces to take extra sysfs attributes
From: David Lechner @ 2026-06-17 21:43 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, andy, robh, krzk+dt, conor+dt,
pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <a09f2cac2d26fe385f1f7790b0db64b7d9953ac6.1781661028.git.marcelo.schmitt@analog.com>
On 6/16/26 9:03 PM, Marcelo Schmitt wrote:
> Some devices using DMAengine buffers are connected to extra hardware that
> allows setting how fast data is transferred to/from the buffer. However,
> those extra pieces of harwdware are external to the sensor chip such that
> supporting the transfer speed as a sensor property is a bit of an
> inaccuracy. Expand IIO DMAengine buffer interfaces to take arguments for
> extra sysfs attributes, enabling the transfer speed to be configured
> through the buffer interface.
This message is a bit confusing. It sounds like it is attempting to
control something about the DMA controller itself. But based on the
later patches, it looks like this is just so we can add arbitrary
sysfs attributes to the bufferX directory. And in this specific case,
a sampling_frequency attribute.
>
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---
> New patch.
>
> Now that I've come to this buffer "solution", I have pretty much convinced
> myself it would be better to instead have some sort of IIO trigger to control
> the signal source connected to SPI offloading trigger module.
>
In the other chips with SPI offload we've done already, we just used
IIO_CHAN_INFO_SAMP_FREQ to control the SPI offload trigger rate.
Any reason why we can't do that here? In the original SPI offload
discussions, IIRC the general consensus was that adding a trigger
just to control that was overkill when I suggested the same.
^ permalink raw reply
* Re: [PATCH v4 1/3] regulator: qcom-refgen: correct the regulator type to CURRENT
From: Dmitry Baryshkov @ 2026-06-17 21:42 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, linux-arm-msm, linux-kernel,
devicetree, stable, Konrad Dybcio
In-Reply-To: <20260617-ipq9650_refgen-v4-1-c505ea6c6661@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 11:08:43PM +0530, Kathiravan Thirumoorthy wrote:
> As per the REFGEN IP team, this block supplies the reference current to
> the PHYs in the SoC. So, correct the regulator type to REGULATOR_CURRENT
> to match with the HW behavior.
>
> Fixes: 7cbfbe237960 ("regulator: Introduce Qualcomm REFGEN regulator driver")
> Cc: stable@vger.kernel.org
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> drivers/regulator/qcom-refgen-regulator.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Conor Dooley @ 2026-06-17 21:41 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617-deed-snap-4649ffae0e27@spud>
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
On Wed, Jun 17, 2026 at 10:23:56PM +0100, Conor Dooley wrote:
> On Wed, Jun 17, 2026 at 08:47:53PM +0300, Stefan Dösinger wrote:
> > Am Mittwoch, 17. Juni 2026, 19:08:02 Ostafrikanische Zeit schrieb Conor
> > Dooley:
> > > On Tue, Jun 16, 2026 at 11:26:21PM +0300, Stefan Dösinger wrote:
> >
> > > > +F: Documentation/devicetree/zte,zx297520v3-*
> > >
> > > Sashiko complaint here looks valid.
> >
> > Yes, it is valid.
> >
> > It also brought up another concern in patch 12 that has an impact on this
> > binding:
> >
> > Am Dienstag, 16. Juni 2026, 23:42:19 Ostafrikanische Zeit schrieb sashiko-
> > bot@kernel.org:
> > > issue(s) to consider: - [Low] The `syscon-reboot` node is incorrectly
> > > defined at the root level using the explicitly deprecated `regmap`
> > > property. --
> >
> > And indeed "regmap" is deprecated and I missed it somehow. As far as I
> > understand, to put syscon-reboot as a child of the clock, I need to add the
> > simple-mfd .compatible:
> >
> > Either
> >
> > topclk: clock-controller@13b000 {
> > compatible = "zte,zx297520v3-topclk", "syscon", "simple-mfd";
> > reg = <0x0013b000 0x400>;
> > ...
> > syscon-reboot {
> > compatible = "syscon-reboot";
> > regmap = <&topclk>;
> > offset = <0x0>;
> > mask = <0x1>;
> > };
> > };
> >
> > --- or ---
> >
> > something@13b000 {
> > compatible = "zte,zx297520v3-topcrm", "syscon", "simple-mfd";
> > reg = <0x0013b000 0x400>;
> > ranges;
> >
> > topclk: clock-controller@0 {
> > compatible = "zte,zx297520v3-topclk";
> > ...
> > }
> >
> > syscon-reboot {
> > compatible = "syscon-reboot";
> > offset = <0x0>;
> > mask = <0x1>;
> > };
> > };
> >
> > I see both ways in existing DTS files (e.g. imx6sl.dtsi for the fomer,
> > uniphier-pro4.dtsi for the latter). Is there a preferred way? I have a mild
> > preference for the first, as it would keep all 3 clocks in the same way. If I
> > go for the second, the clock driver would have to query its own node and the
> > parent node for the regmap.
>
> The first one is more natural...
>
> > AFAIU unrelated to syscon-reboot option 2 would give me the opportunity to
> > have separate clock and reset nodes and bindings and skip the aux bus, but
> > this would not be a correct representation of how the hardware works.
>
> ...for this reason!
> Do you actually need an aux bus here though? Since you have to add
> simple-mfd for your the syscon-reboot and simple-mfd is a real bus, can you
> set the reset controller up with an mfd_cell + devm_mfd_add_devices()
> instead?
Although, the /naming/ is more natural in the second case. "topcrm"
sounds like the actual name of this register region. And syscon@ for the
node name.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 6/8] media: nxp: add V4L2 subdev driver for camera parallel interface (CPI)
From: sashiko-bot @ 2026-06-17 21:34 UTC (permalink / raw)
To: Frank.Li; +Cc: imx, Frank.Li, robh, conor+dt, devicetree
In-Reply-To: <20260617-imx8qxp_pcam-v5-6-7fa6c8e7fba7@nxp.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] NULL pointer dereference when enabling or disabling streams on an unconnected sink pad.
- [High] Missing format bounds clamping causes integer underflow and massive hardware width configuration.
- [Medium] Missing `V4L2_SUBDEV_FL_STREAMS` flag breaks V4L2 format and routing state initialization.
- [Medium] Reversed pad direction arguments in `v4l2_subdev_state_xlate_streams` leads to improper stream mask mapping.
- [Low] Unconditional overwrite of hardware configuration variable `val` renders `switch` statement dead code.
--
commit 6eecb6f34887a526e9a659dcd6d0a03e320f98ab
Author: Alice Yuan <alice.yuan@nxp.com>
media: nxp: add V4L2 subdev driver for camera parallel interface (CPI)
Add a V4L2 sub-device driver for the CPI controller found on i.MX8QXP,
i.MX8QM, and i.MX93 SoCs. This controller supports parallel camera sensors
and enables image data capture through a parallel interface.
> diff --git a/drivers/media/platform/nxp/imx-parallel-cpi.c b/drivers/media/platform/nxp/imx-parallel-cpi.c
> new file mode 100644
> index 0000000000000..00f5d5f47644b
> --- /dev/null
> +++ b/drivers/media/platform/nxp/imx-parallel-cpi.c
> @@ -0,0 +1,614 @@
[ ... ]
> +static void imx_cpi_config_ctrl_reg1(struct imx_cpi_device *pcpidev,
> + const struct v4l2_mbus_framefmt *format)
> +{
> + const struct imx_cpi_plat_data *pdata = pcpidev->pdata;
> + u32 pixel_width;
> + u32 vsync_pulse;
> + u32 val;
> +
> + pixel_width = format->width - 1;
> + vsync_pulse = format->width << 1;
> +
> + switch (pcpidev->pdata->version) {
> + case PI_V1:
> + val = CPI_CTRL_REG1_PIXEL_WIDTH(pixel_width) |
> + CPI_CTRL_REG1_VSYNC_PULSE(vsync_pulse);
> + break;
> + default:
> + val = 0; /* Never happen */
> + }
> +
> + val = CPI_CTRL_REG1_PIXEL_WIDTH(pixel_width) |
> + CPI_CTRL_REG1_VSYNC_PULSE(vsync_pulse);
[Severity: Low]
Is the unconditional assignment to val here intentional? It immediately
overwrites the val computed inside the switch statement above, effectively
rendering the switch block as dead code and dropping any future hardware
version configurations.
> + writel(val, pcpidev->regs + pdata->interface_ctrl_reg1);
> +}
[ ... ]
> +static int imx_cpi_set_fmt(struct v4l2_subdev *sd,
> + struct v4l2_subdev_state *sd_state,
> + struct v4l2_subdev_format *sdformat)
> +{
> + struct imx_cpi_pix_format const *pcpidev_fmt;
> + struct v4l2_mbus_framefmt *fmt;
> +
> + /*
> + * The Parallel cpi can't transcode in any way, the source format
> + * can't be modified.
> + */
> + if (sdformat->pad == V4L2_SUBDEV_1TO1_PADS_SOURCE)
> + return v4l2_subdev_get_fmt(sd, sd_state, sdformat);
> +
> + pcpidev_fmt = find_imx_cpi_format(sdformat->format.code);
> + if (!pcpidev_fmt)
> + pcpidev_fmt = &imx_cpi_formats[0];
> +
> + fmt = v4l2_subdev_state_get_format(sd_state, sdformat->pad);
> +
> + fmt->code = pcpidev_fmt->code;
> + fmt->width = sdformat->format.width;
> + fmt->height = sdformat->format.height;
[Severity: High]
Does this code need bounds checking for width and height? If a malicious
application provides a width of 0, it is copied directly to the format
structure here.
Later in imx_cpi_config_ctrl_reg1(), the width is used like this:
pixel_width = format->width - 1;
which would underflow to 0xffffffff, causing an extremely large dimension to
be written to the hardware configuration.
> + fmt->field = V4L2_FIELD_NONE;
> + fmt->colorspace = sdformat->format.colorspace;
[ ... ]
> +static int imx_cpi_disable_streams(struct v4l2_subdev *sd,
> + struct v4l2_subdev_state *state, u32 pad,
> + u64 streams_mask)
> +{
> + struct imx_cpi_device *pcpidev = sd_to_imx_cpi_device(sd);
> + struct media_pad *sink_pad, *remote_pad;
> + struct device *dev = pcpidev->dev;
> + struct v4l2_subdev *remote_sd;
> + u64 mask;
> + int ret;
> +
> + sink_pad = &sd->entity.pads[V4L2_SUBDEV_1TO1_PADS_SINK];
> + remote_pad = media_pad_remote_pad_first(sink_pad);
> + remote_sd = media_entity_to_v4l2_subdev(remote_pad->entity);
[Severity: High]
Could this cause a NULL pointer dereference if the subdevice is not connected?
media_pad_remote_pad_first() returns NULL if no link is enabled on the sink
pad. If userspace sends VIDIOC_SUBDEV_S_STREAM directly to the unconnected
device node, remote_pad->entity would trigger a panic.
> +
> + mask = v4l2_subdev_state_xlate_streams(state, V4L2_SUBDEV_1TO1_PADS_SINK,
> + V4L2_SUBDEV_1TO1_PADS_SOURCE,
> + &streams_mask);
[Severity: Medium]
Are the pad arguments reversed here?
When disable_streams is called, streams_mask originates from the pad passed
to the operation (the SOURCE pad). To find the remote mask, it should
translate from SOURCE to SINK.
Should this be passing V4L2_SUBDEV_1TO1_PADS_SOURCE as the second argument
and V4L2_SUBDEV_1TO1_PADS_SINK as the third?
> +
> + ret = v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
> + if (ret)
[ ... ]
> +static int imx_cpi_enable_streams(struct v4l2_subdev *sd,
> + struct v4l2_subdev_state *state, u32 pad,
> + u64 streams_mask)
> +{
> + struct imx_cpi_device *pcpidev = sd_to_imx_cpi_device(sd);
> + const struct imx_cpi_pix_format *pcpidev_fmt;
> + const struct v4l2_mbus_framefmt *format;
> + struct media_pad *sink_pad, *remote_pad;
> + struct device *dev = pcpidev->dev;
> + struct v4l2_subdev *remote_sd;
> + u64 mask;
> + int ret;
> +
> + sink_pad = &sd->entity.pads[V4L2_SUBDEV_1TO1_PADS_SINK];
> + remote_pad = media_pad_remote_pad_first(sink_pad);
> + remote_sd = media_entity_to_v4l2_subdev(remote_pad->entity);
[Severity: High]
Does this have the same NULL pointer dereference issue on unconnected links as
imx_cpi_disable_streams()?
> +
> + mask = v4l2_subdev_state_xlate_streams(state, V4L2_SUBDEV_1TO1_PADS_SINK,
> + V4L2_SUBDEV_1TO1_PADS_SOURCE,
> + &streams_mask);
[Severity: Medium]
Similarly, do the pad arguments need to be swapped here to correctly
translate from SOURCE to SINK?
> +
> + format = v4l2_subdev_state_get_format(state, V4L2_SUBDEV_1TO1_PADS_SINK);
[ ... ]
> +static int imx_cpi_probe(struct platform_device *pdev)
> +{
> + struct imx_cpi_device *pcpidev;
> + struct device *dev = &pdev->dev;
> + struct v4l2_subdev *sd;
> + int ret;
[ ... ]
> + sd->internal_ops = &imx_cpi_internal_ops;
> + snprintf(sd->name, sizeof(sd->name), "parallel-%s",
> + dev_name(pcpidev->dev));
> +
> + sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
[Severity: Medium]
Should V4L2_SUBDEV_FL_STREAMS also be set here?
Without this flag, the V4L2 core falls back to allocating the legacy
state->pads array. This causes the routing and stream configuration
set up by v4l2_subdev_set_routing_with_fmt() in imx_cpi_init_state()
to be ignored, which leaves the initial format reporting uninitialized.
> +
> + sd->entity.function = MEDIA_ENT_F_VID_IF_BRIDGE;
> + sd->entity.ops = &imx_cpi_entity_ops;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-imx8qxp_pcam-v5-0-7fa6c8e7fba7@nxp.com?part=6
^ permalink raw reply
* Re: [PATCH v4 10/10] Input: cap11xx - add support for CAP1114
From: sashiko-bot @ 2026-06-17 21:25 UTC (permalink / raw)
To: Jun Yan; +Cc: dmitry.torokhov, devicetree, linux-input, conor+dt, robh
In-Reply-To: <20260617150318.753148-11-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Out-of-bounds write in `cap11xx_i2c_probe` due to unvalidated Device Tree keycodes.
--
commit 42cef688f767435c4da8af0dd519be20d4164735
Author: Jun Yan <jerrysteve1101@gmail.com>
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support.
This commit adds support for the CAP1114 touch sensor, updating the driver
to handle up to 14 channels and 11 LED outputs. It introduces logic to
read from a secondary status register to support the expanded channel count
and configures grouped sensors as independent inputs.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 275eb79a7193..865c58533eb9 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -292,6 +307,17 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
> of_property_read_u32_array(node, "linux,keycodes",
> priv->keycodes, priv->model->num_channels);
[Severity: High]
This is a pre-existing issue, but I noticed that these keycodes are read
directly from the Device Tree into the priv->keycodes array without any
bounds validation.
Later during initialization in cap11xx_i2c_probe(), the driver loops over
these keycodes and sets bits using an unchecked macro:
__set_bit(priv->keycodes[i], priv->idev->keybit);
If an exceptionally large keycode (greater than KEY_MAX) is provided via a
Device Tree overlay, could this cause an out-of-bounds write on the
priv->idev->keybit array and corrupt adjacent heap memory? Should we verify
that each keycode read from the Device Tree is less than or equal to KEY_MAX?
> +
> + /*
> + * CAP1114 needs dedicated configuration to split
> + * grouped sensors into independent inputs.
> + */
> + if (priv->model->has_grouped_sensors) {
> + error = regmap_set_bits(priv->regmap, CAP1114_REG_CONFIG2,
> + CAP1114_REG_CONFIG2_VOL_UP_DOWN);
> + if (error)
> + return error;
> + }
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617150318.753148-1-jerrysteve1101@gmail.com?part=10
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Conor Dooley @ 2026-06-17 21:23 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <-l2OM6P0RNSYRQfOSObOyw@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]
On Wed, Jun 17, 2026 at 08:47:53PM +0300, Stefan Dösinger wrote:
> Am Mittwoch, 17. Juni 2026, 19:08:02 Ostafrikanische Zeit schrieb Conor
> Dooley:
> > On Tue, Jun 16, 2026 at 11:26:21PM +0300, Stefan Dösinger wrote:
>
> > > +F: Documentation/devicetree/zte,zx297520v3-*
> >
> > Sashiko complaint here looks valid.
>
> Yes, it is valid.
>
> It also brought up another concern in patch 12 that has an impact on this
> binding:
>
> Am Dienstag, 16. Juni 2026, 23:42:19 Ostafrikanische Zeit schrieb sashiko-
> bot@kernel.org:
> > issue(s) to consider: - [Low] The `syscon-reboot` node is incorrectly
> > defined at the root level using the explicitly deprecated `regmap`
> > property. --
>
> And indeed "regmap" is deprecated and I missed it somehow. As far as I
> understand, to put syscon-reboot as a child of the clock, I need to add the
> simple-mfd .compatible:
>
> Either
>
> topclk: clock-controller@13b000 {
> compatible = "zte,zx297520v3-topclk", "syscon", "simple-mfd";
> reg = <0x0013b000 0x400>;
> ...
> syscon-reboot {
> compatible = "syscon-reboot";
> regmap = <&topclk>;
> offset = <0x0>;
> mask = <0x1>;
> };
> };
>
> --- or ---
>
> something@13b000 {
> compatible = "zte,zx297520v3-topcrm", "syscon", "simple-mfd";
> reg = <0x0013b000 0x400>;
> ranges;
>
> topclk: clock-controller@0 {
> compatible = "zte,zx297520v3-topclk";
> ...
> }
>
> syscon-reboot {
> compatible = "syscon-reboot";
> offset = <0x0>;
> mask = <0x1>;
> };
> };
>
> I see both ways in existing DTS files (e.g. imx6sl.dtsi for the fomer,
> uniphier-pro4.dtsi for the latter). Is there a preferred way? I have a mild
> preference for the first, as it would keep all 3 clocks in the same way. If I
> go for the second, the clock driver would have to query its own node and the
> parent node for the regmap.
The first one is more natural...
> AFAIU unrelated to syscon-reboot option 2 would give me the opportunity to
> have separate clock and reset nodes and bindings and skip the aux bus, but
> this would not be a correct representation of how the hardware works.
...for this reason!
Do you actually need an aux bus here though? Since you have to add
simple-mfd for your the syscon-reboot and simple-mfd is a real bus, can you
set the reset controller up with an mfd_cell + devm_mfd_add_devices()
instead?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Conor Dooley @ 2026-06-17 21:17 UTC (permalink / raw)
To: Gerald Loacker
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <c34d4167-1a33-4e20-820c-735811b6a966@wolfvision.net>
[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]
On Wed, Jun 17, 2026 at 06:20:19PM +0200, Gerald Loacker wrote:
> Hi Conor,
>
> Am 17.06.2026 um 17:51 schrieb Conor Dooley:
> > On Wed, Jun 17, 2026 at 02:23:14PM +0200, Gerald Loacker wrote:
> >> Add support for the optional rockchip,clk-lane-phase device tree property
> >> to allow board-specific tuning of the clock lane sampling phase for
> >> improved signal integrity across supported data rates.
> >>
> >> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
> >> ---
> >> Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> >> index 03950b3cad08c..0d824d1511bc0 100644
> >> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> >> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
> >> @@ -56,6 +56,13 @@ properties:
> >> description:
> >> Some additional phy settings are access through GRF regs.
> >>
> >> + rockchip,clk-lane-phase:
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> + minimum: 0
> >> + maximum: 7
> >> + description:
> >> + Clock lane sampling phase in 40 ps steps. The hardware default is 3.
> >
> > Can this instead become rockchip,clk-lane-phase-ps and be listed in the
> > actual unit?
> > With the -ps suffix, you can then drop the $ref.
> > The default should be listed as "default: 3" (or default: 120)
> >
> > pw-bot: changes-requested
> >
>
> Thanks for the suggestion.
>
> The phase setting is a hardware tap index (0–7) selecting a delay line
> position. The datasheet mentions “about 40 ps” per step, but this is not
> a calibrated or guaranteed value and may vary with PVT.
>
> Because of that, I’d prefer to keep the property as an index and
> document the approximate delay in the description:
>
> Clock lane sampling phase selection (hardware tap index 0–7). Each step
> corresponds to an approximately 40 ps delay as described in the hardware
> specification.
>
> This matches the hardware model more closely. Happy to adjust if needed.
>
Sure, I think that's fair.
> >> +
> >> required:
> >> - compatible
> >> - reg
> >>
> >> --
> >> 2.34.1
> >>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: iio: adc: Add ltc2378
From: Conor Dooley @ 2026-06-17 21:16 UTC (permalink / raw)
To: Marcelo Schmitt
Cc: Marcelo Schmitt, linux-iio, devicetree, linux-kernel, jic23,
nuno.sa, Michael.Hennerich, dlechner, andy, robh, krzk+dt,
conor+dt, pop.ioan-daniel
In-Reply-To: <ajLV-O60lCdlIbXR@debian-BULLSEYE-live-builder-AMD64>
[-- Attachment #1: Type: text/plain, Size: 8059 bytes --]
On Wed, Jun 17, 2026 at 02:14:32PM -0300, Marcelo Schmitt wrote:
> On 06/17, Conor Dooley wrote:
> > On Tue, Jun 16, 2026 at 11:03:11PM -0300, Marcelo Schmitt wrote:
> > > Document how to describe LTC2378-20 and similar ADCs in device tree.
> > >
> > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > ---
> > > Change log v2 -> v3:
> > > - Re-added device tree fallback compatibles for LTC2378 chips, now with options
> > > to provide a single compatible string or a pair of single compatible string
> > > plus a fallback string to a slower sample rate spec in case a driver for the
> > > specific part is not found.
> > >
> > > .../bindings/iio/adc/adi,ltc2378.yaml | 160 ++++++++++++++++++
> > > MAINTAINERS | 7 +
> > > 2 files changed, 167 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> > > new file mode 100644
> > > index 000000000000..7d30a2cade8f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> > > @@ -0,0 +1,160 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/iio/adc/adi,ltc2378.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Analog Devices LTC2378 and similar Analog to Digital Converters
> > > +
> > > +maintainers:
> > > + - Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > +
> > > +description: |
> > > + Analog Devices LTC2378 series of ADCs.
> > > + Specifications can be found at:
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/233818fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/236416fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/236418f.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/236716fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/236718f.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/236816f.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/236818f.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/236918fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237016fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237616fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237618fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237620fb.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237716fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237718fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237720fb.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237816fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237818fa.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237820fb.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/237918fb.pdf
> > > + https://www.analog.com/media/en/technical-documentation/data-sheets/238016fb.pdf
> > > +
> > > +$ref: /schemas/spi/spi-peripheral-props.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + # Single compatible string match.
> > > + - enum:
> > > + - adi,ltc2338-18
> > > + - adi,ltc2364-16
> > > + - adi,ltc2364-18
> > > + - adi,ltc2367-16
> > > + - adi,ltc2367-18
> > > + - adi,ltc2368-16
> > > + - adi,ltc2368-18
> > > + - adi,ltc2369-18
> > > + - adi,ltc2370-16
> > > + - adi,ltc2376-16
> > > + - adi,ltc2376-18
> > > + - adi,ltc2376-20
> > > + - adi,ltc2377-16
> > > + - adi,ltc2377-18
> > > + - adi,ltc2377-20
> > > + - adi,ltc2378-16
> > > + - adi,ltc2378-18
> > > + - adi,ltc2378-20
> > > + - adi,ltc2379-18
> > > + - adi,ltc2380-16
> > > +
> > > + # Low sample rate fallback for 16-bit unipolar sensors.
> > > + - items:
> > > + - enum:
> > > + - adi,ltc2370-16 # 2 MSPS
> > > + - adi,ltc2368-16 # 1 MSPS
> > > + - adi,ltc2367-16 # 500 kSPS
> > > + - const: adi,ltc2364-16 # fallback (250 kSPS)
> >
> > Your driver still matches on ltc2370-16, which makes me question the
> > value of these fallbacks. That said, the chip info struct contains no
> > information about sampling rate.
> The info about sample rate is added in patch 4.
Ah, I missed that.
> > What actually is the impact of the sample rate on the programming model?
> If the user tries to set a sample rate beyond the maximum supported, software
> can throw an error to indicate that.
I think you have misunderstood this. I was asking how the driver
interacts with the hardware. Do all devices come out of reset with the
minimum sampling rate? Or a per-device default rate? Do the faster
devices support all slower rates? If they do, do the registers have the
same meaning and the same value sets 2370-16 device to 1 MSPS as
2368-16.
> > Is there actually a benefit to matching on ltc2370-16, or can you just
> > match on the fallback?
> The benefit is telling software that it is safe to go up to 2 MSPS. It is also
> okay to match on the fallback, but software may restrain operation to a slower
> sample rate.
My whole review here is shit cos I didn't see patch 4, so the use of
fallbacks seems appropriate (provided your answers to my programming
model questions are sane!).
>
> With the code being proposed in this patch set, there is no benefit in matching
> the ltc2364-16 fallback if there is a faster ltc2370-16 device connected because
> device driver supports that. Though, other operating systems and/or platforms
> might not support all device variants and so the fallback might be useful.
>
> > +static const struct ltc2378_chip_info ltc2370_16_chip_info = {
> > + .name = "ltc2370-16",
> > + .resolution = 16,
> In a later patch ...
> + .max_sample_rate_hz = 2 * HZ_PER_MHZ,
> + .tconv_ns = 322,
> > + .bipolar = false,
> > +};
> >
> > +static const struct ltc2378_chip_info ltc2368_16_chip_info = {
> > + .name = "ltc2368-16",
> > + .resolution = 16,
> + .max_sample_rate_hz = HZ_PER_MHZ,
> + .tconv_ns = 527
> > + .bipolar = false,
> > +};
> >
> > +static const struct ltc2378_chip_info ltc2367_16_chip_info = {
> > + .name = "ltc2367-16",
> > + .resolution = 16,
> + .max_sample_rate_hz = 500 * HZ_PER_KHZ,
> + .tconv_ns = 1500,
> > + .bipolar = false,
> > +};
> >
> > +static const struct ltc2378_chip_info ltc2364_16_chip_info = {
> > + .name = "ltc2364-16",
> > + .resolution = 16,
> + .max_sample_rate_hz = 250 * HZ_PER_KHZ,
> + .tconv_ns = 3000,
> > + .bipolar = false,
> > +};
> >
> ...
> > > + # Low sample rate fallback for 20-bit bipolar sensors.
> > > + - items:
> > > + - enum:
> > > + - adi,ltc2378-20 # 1 MSPS
> > > + - adi,ltc2377-20 # 500 kSPS
> > > + - const: adi,ltc2376-20 # fallback (250 kSPS)
> >
> > I didn't check these, but I assume they are the same.
>
> Yes, except for small variations on input (unipolar/bipolar) and precision bits,
> these devices are pretty much equal.
What I meant here was that 2378-20, 2377-20 and 2376-20 would follow the
same pattern of having identical match data (pre patch 4).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 09/10] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: sashiko-bot @ 2026-06-17 21:15 UTC (permalink / raw)
To: Jun Yan; +Cc: conor+dt, devicetree, robh, linux-input, dmitry.torokhov
In-Reply-To: <20260617150318.753148-10-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Schema Validation Regression (Incomplete Constraints Update)
--
commit 74e08f50d786114a66be01956a59aeb6b7083fbc
Author: Jun Yan <jerrysteve1101@gmail.com>
dt-bindings: input: cap11xx: Add CAP1114 support
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support. Add the compatible string for CAP1114, add
its datasheet URL, update the maximum of LED channel reg, and add
constraint for linux,keycodes.
> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index b97e5b2735f1..2a37ac252c37 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
[ ... ]
> @@ -140,7 +144,7 @@ properties:
> The number of entries must correspond to the number of channels.
>
> patternProperties:
> - "^led@[0-7]$":
> + "^led@[0-9a]$":
[Severity: Medium]
Does this global regex update also require an update to the disablement block
for hardware variants without LEDs?
The allOf block that disables LEDs for specific variants (like CAP1106,
CAP1203, etc.) still uses "^led@[0-7]$": false.
Because of this new global regex, wouldn't nodes like led@8, led@9,
and led@a now bypass the false constraint and be silently permitted on
devices that are supposed to have zero LEDs?
> type: object
> description: CAP11xx LEDs
> $ref: /schemas/leds/common.yaml#
> @@ -149,7 +153,7 @@ patternProperties:
> reg:
> description: LED channel number
> minimum: 0
> - maximum: 7
> + maximum: 10
>
> label: true
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617150318.753148-1-jerrysteve1101@gmail.com?part=9
^ permalink raw reply
* Re: [PATCH V13 8/9] iio: imu: inv_icm42607: Add Gyroscope to icm42607
From: Chris Morgan @ 2026-06-17 21:10 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner, jic23,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh
In-Reply-To: <ajEhr0JIQwzRgoZa@ashevche-desk.local>
On Tue, Jun 16, 2026 at 01:13:03PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 15, 2026 at 12:25:51PM -0500, Chris Morgan wrote:
>
> > Add gyroscope functions to the icm42607 driver.
>
> ...
>
> > +int inv_icm42607_set_gyro_conf(struct inv_icm42607_state *st,
> > + struct inv_icm42607_sensor_conf *conf,
> > + unsigned int *sleep_ms)
> > +{
> > + struct inv_icm42607_sensor_conf *oldconf = &st->conf.gyro;
> > + unsigned int val;
> > + int ret;
> > +
> > + if (conf->mode < 0)
> > + conf->mode = oldconf->mode;
> > + if (conf->fs < 0)
> > + conf->fs = oldconf->fs;
> > + if (conf->odr < 0)
> > + conf->odr = oldconf->odr;
> > + if (conf->filter < 0)
> > + conf->filter = oldconf->filter;
>
> Same comment as per previous patch. But looking at this, can you rather have
> a helper that answers the below two questions? Something like
>
> void _assign_conf(..., bool *write_odr, bool *write_filter)
> {
> ...
> }
> EXPORT_...
>
> in the core driver? But wight both approaches and choose either existing one
> (as in this patch series) or what I suggested.
In the core driver, I was going to do something like this:
static void inv_icm42607_update_config(struct inv_icm42607_sensor_conf *conf,
struct inv_icm42607_sensor_conf *oldconf,
bool *config0, bool *config1)
{
if (conf->mode < 0)
conf->mode = oldconf->mode;
if (conf->fs < 0)
conf->fs = oldconf->fs;
if (conf->odr < 0)
conf->odr = oldconf->odr;
if (conf->filter < 0)
conf->filter = oldconf->filter;
if (conf->fs != oldconf->fs || conf->odr != oldconf->odr)
*config0 = true;
if (conf->filter != oldconf->filter)
*config1 = true;
}
So the step of copying stuff for sanity checking as well as checking
if I need to update config0 or config1 registers is handled here, and
I can simply check the values of config0 and config1 with an if to
determine if I need to call to write to the registers.
>
> > + if (conf->fs != oldconf->fs || conf->odr != oldconf->odr) {
> > + val = FIELD_PREP(INV_ICM42607_GYRO_CONFIG0_FS_SEL_MASK,
> > + conf->fs);
> > + val |= FIELD_PREP(INV_ICM42607_GYRO_CONFIG0_ODR_MASK,
> > + conf->odr);
> > + ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG0, val);
> > + if (ret)
> > + return ret;
> > + oldconf->fs = conf->fs;
> > + oldconf->odr = conf->odr;
> > + }
> > +
> > + if (conf->filter != oldconf->filter) {
> > + val = FIELD_PREP(INV_ICM42607_GYRO_CONFIG1_FILTER_MASK,
> > + conf->filter);
> > + ret = regmap_update_bits(st->map, INV_ICM42607_REG_GYRO_CONFIG1,
> > + INV_ICM42607_GYRO_CONFIG1_FILTER_MASK, val);
> > + if (ret)
> > + return ret;
> > + oldconf->filter = conf->filter;
> > + }
> > +
> > + return inv_icm42607_set_pwr_mgmt0(st, conf->mode, st->conf.accel.mode,
> > + st->conf.temp_en, sleep_ms);
> > +}
>
> ...
>
> > +{
> > + unsigned int odr;
> > + unsigned int i;
> > +
> > + guard(mutex)(&st->lock);
> > +
> > + odr = st->conf.gyro.odr;
> > +
> > + for (i = 5; i < ARRAY_SIZE(inv_icm42607_gyro_odr); ++i) {
>
> Same comment, why pre-increment?
I could not brain on this day, I had the dumb.
I'll fix it. :-)
>
> > + if (i == odr)
> > + break;
> > + }
> > + if (i >= ARRAY_SIZE(inv_icm42607_gyro_odr))
> > + return -EINVAL;
> > +
> > + *val = inv_icm42607_gyro_odr[i][0];
> > + *val2 = inv_icm42607_gyro_odr[i][1];
> > +
> > + return IIO_VAL_INT_PLUS_MICRO;
> > +}
> > +
> > +static int inv_icm42607_gyro_write_odr(struct iio_dev *indio_dev,
> > + int val, int val2)
> > +{
> > + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> > + struct device *dev = regmap_get_device(st->map);
> > + unsigned int idx;
> > + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> > + int ret;
> > +
> > + for (idx = 5; idx < ARRAY_SIZE(inv_icm42607_gyro_odr); ++idx) {
>
> Ditto.
>
> > + if (val == inv_icm42607_gyro_odr[idx][0] &&
> > + val2 == inv_icm42607_gyro_odr[idx][1])
> > + break;
> > + }
> > + if (idx >= ARRAY_SIZE(inv_icm42607_gyro_odr))
> > + return -EINVAL;
> > +
> > + conf.odr = idx;
> > +
> > + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> > + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> > + if (ret)
> > + return ret;
> > +
> > + guard(mutex)(&st->lock);
> > +
> > + return inv_icm42607_set_gyro_conf(st, &conf, NULL);
> > +}
>
> Can be some of the code deduplicated between gyro and accel?
Probably a fair amount, but the deduplication will likely need to be
undone somewhat if we get buffer, WoM or apex support added back
(I don't have any devices with such functionality, so if anyone will
do it then it won't be me). I can refactor more if you want, or we
can keep it split like this to make it easy if someone else wants to
tackle the buffers/IRQs stuff later? Your call.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH v9 5/5] iio: adc: versal-sysmon: add oversampling support
From: sashiko-bot @ 2026-06-17 21:07 UTC (permalink / raw)
To: Salih Erim; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260617180147.3370346-6-salih.erim@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Software cache for oversampling ratios is unconditionally initialized to 1, potentially causing desynchronization with the actual hardware configuration.
--
commit 81ca0dc5aa386dec0337a8e068370935d45ea78e
Author: Salih Erim <salih.erim@amd.com>
iio: adc: versal-sysmon: add oversampling support
This commit adds support for reading and writing the oversampling ratio
through the IIO oversampling_ratio attribute. The hardware supports averaging
2, 4, 8, or 16 samples, plus a ratio of 1 for no averaging.
> diff --git a/drivers/iio/adc/versal-sysmon-core.c b/drivers/iio/adc/versal-sysmon-core.c
> index 19a8edd89198c..16f474c1bffae 100644
> --- a/drivers/iio/adc/versal-sysmon-core.c
> +++ b/drivers/iio/adc/versal-sysmon-core.c
[ ... ]
> @@ -832,6 +981,8 @@ int devm_versal_sysmon_core_probe(struct device *dev, struct regmap *regmap)
>
> sysmon = iio_priv(indio_dev);
> sysmon->regmap = regmap;
> + sysmon->temp_oversampling = 1;
> + sysmon->supply_oversampling = 1;
[Severity: Medium]
Could this software cache initialization become desynchronized with the actual
hardware configuration?
The oversampling variables are initialized to 1 unconditionally, without
reading the SYSMON_CONFIG hardware register or actively writing this default
value down to the hardware.
If the bootloader or a previous kernel instance (such as through kexec)
configured an oversampling ratio other than 1, will the hardware continue
averaging samples while userspace incorrectly reads '1' from the IIO
oversampling ratio attribute?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617180147.3370346-1-salih.erim@amd.com?part=5
^ permalink raw reply
* Re: [PATCH v5 2/8] media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
From: sashiko-bot @ 2026-06-17 21:06 UTC (permalink / raw)
To: Frank.Li; +Cc: conor+dt, imx, Frank.Li, robh, devicetree
In-Reply-To: <20260617-imx8qxp_pcam-v5-2-7fa6c8e7fba7@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Redundant cleanup and misguided teardown of `sd->subdev_notifier`.
--
commit ebb79cbbc440da4b8d1a35f25ce9168deff7467d
Author: Frank Li <Frank.Li@nxp.com>
media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
This commit introduces a common helper library to encapsulate registration,
media entity initialization, and cleanup for 1-to-1 V4L2 subdevices,
reducing boilerplate in simple bridge and converter drivers.
> diff --git a/drivers/media/v4l2-core/v4l2-1to1.c b/drivers/media/v4l2-core/v4l2-1to1.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/media/v4l2-core/v4l2-1to1.c
[ ... ]
> +void media_async_subdev_1to1_cleanup(struct v4l2_subdev_1to1 *sd_1to1)
> +{
> + struct v4l2_subdev *sd = &sd_1to1->sd;
> +
> + v4l2_async_unregister_subdev(sd);
> + v4l2_subdev_cleanup(sd);
> + media_entity_cleanup(&sd->entity);
> + v4l2_async_nf_unregister(sd->subdev_notifier);
> + v4l2_async_nf_cleanup(sd->subdev_notifier);
> +
> + kfree(sd->subdev_notifier);
[Severity: Low]
Does this code perform redundant cleanups?
Looking at v4l2_async_unregister_subdev(), it already handles unregistering,
cleaning up, freeing, and setting sd->subdev_notifier to NULL:
v4l2_async_unregister_subdev(struct v4l2_subdev *sd) {
...
__v4l2_async_nf_unregister(sd->subdev_notifier);
__v4l2_async_nf_cleanup(sd->subdev_notifier);
kfree(sd->subdev_notifier);
sd->subdev_notifier = NULL;
...
}
Since sd->subdev_notifier is NULL after v4l2_async_unregister_subdev()
returns, are the subsequent calls to v4l2_async_nf_unregister(),
v4l2_async_nf_cleanup(), and kfree() necessary here in
media_async_subdev_1to1_cleanup()?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-imx8qxp_pcam-v5-0-7fa6c8e7fba7@nxp.com?part=2
^ permalink raw reply
* Re: [PATCH v9 4/5] iio: adc: versal-sysmon: add threshold event support
From: sashiko-bot @ 2026-06-17 21:01 UTC (permalink / raw)
To: Salih Erim; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260617180147.3370346-5-salih.erim@amd.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Integer Overflow and Missing Bit Masking in Threshold Calculations
- [High] Supply Voltage Threshold Events Permanently Disabled on Trigger
- [High] Kernel Panic from Sleeping in Atomic Context on I2C Devices
- [High] Race Condition Desynchronizes Hardware Interrupt State
--
commit 0d7222f55024a692e00cced200dc17d0764c1060
Author: Salih Erim <salih.erim@amd.com>
iio: adc: versal-sysmon: add threshold event support
Adds threshold event support for temperature and supply voltage channels.
It uses hysteresis mode for temperature and provides per-channel alarm
enable for supply voltages. The interrupt handler masks active threshold
interrupts and schedules a delayed worker to poll.
> diff --git a/drivers/iio/adc/versal-sysmon-core.c b/drivers/iio/adc/versal-sysmon-core.c
> index e0b9b3d2b6d13..19a8edd89198c 100644
> --- a/drivers/iio/adc/versal-sysmon-core.c
> +++ b/drivers/iio/adc/versal-sysmon-core.c
[ ... ]
> @@ -52,6 +101,16 @@ static const struct iio_chan_spec temp_channels[] = {
> SYSMON_CHAN_TEMP(3, SYSMON_TEMP_MIN_MIN, "min_min"),
> };
>
> +static void sysmon_q8p7_to_millicelsius(s16 raw_data, int *val)
> +{
> + *val = (raw_data * MILLIDEGREE_PER_DEGREE) >> SYSMON_FRACTIONAL_SHIFT;
> +}
> +
> +static void sysmon_millicelsius_to_q8p7(u32 *raw_data, int val)
> +{
> + *raw_data = (val << SYSMON_FRACTIONAL_SHIFT) / MILLIDEGREE_PER_DEGREE;
> +}
[Severity: High]
Can this left shift overflow on negative or large sysfs values? Unlike the
voltage path, this function also seems to lack value clamping and a (u16)
bitmask. Since sysmon_write_event_value() writes this raw 32-bit value
directly to SYSMON_TEMP_TH_UP, could it overwrite reserved hardware bits
with sign-extended negative values like 0xFFFFEC00?
> +
> static void sysmon_supply_rawtoprocessed(int raw_data, int *val)
> {
> int mantissa, format, exponent;
> @@ -69,6 +128,33 @@ static void sysmon_supply_rawtoprocessed(int raw_data, int *val)
> *val = (mantissa * (int)MILLI) >> exponent;
> }
>
> +static void sysmon_supply_processedtoraw(int val, u32 reg_val, u32 *raw_data)
> +{
> + int exponent = FIELD_GET(SYSMON_MODE_MASK, reg_val);
> + int format = FIELD_GET(SYSMON_FMT_MASK, reg_val);
> + int scale, tmp;
> +
> + scale = BIT(SYSMON_SUPPLY_MANTISSA_BITS - exponent);
> + tmp = (val * scale) / (int)MILLI;
[Severity: High]
Can this 32-bit multiplication overflow on large sysfs inputs? If scale is up
to 65536, a large val could cause an integer overflow before the division.
> +
> + if (format)
> + tmp = clamp(tmp, S16_MIN, S16_MAX);
> + else
> + tmp = clamp(tmp, 0, U16_MAX);
> +
> + *raw_data = (u16)tmp;
> +}
[ ... ]
> +static int sysmon_write_event_config(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + enum iio_event_type type,
> + enum iio_event_direction dir,
> + bool state)
> +{
[ ... ]
> + case IIO_TEMP:
> + if (state) {
> + ret = regmap_write(sysmon->regmap, SYSMON_IER, mask);
> + if (ret)
> + return ret;
> +
> + scoped_guard(spinlock_irq, &sysmon->irq_lock)
> + sysmon->temp_mask &= ~mask;
> + } else {
> + ret = regmap_write(sysmon->regmap, SYSMON_IDR, mask);
> + if (ret)
> + return ret;
> +
> + scoped_guard(spinlock_irq, &sysmon->irq_lock)
> + sysmon->temp_mask |= mask;
> + }
> + return 0;
[Severity: High]
Is there a race condition here if sysmon_unmask_worker() runs concurrently?
By writing to SYSMON_IDR before acquiring sysmon->irq_lock to update
sysmon->temp_mask, the concurrent worker might read the old temp_mask (where
the bit is still 0/enabled). Could the worker then write to SYSMON_IER in
sysmon_unmask_temp(), effectively re-enabling the interrupt in hardware
immediately after userspace administratively disabled it?
[ ... ]
> +static int sysmon_handle_event(struct iio_dev *indio_dev, u32 event)
> +{
> + u32 alarm_flag_offset = SYSMON_ALARM_FLAG + event * SYSMON_REG_STRIDE;
> + u32 alarm_reg_offset = SYSMON_ALARM_REG + event * SYSMON_REG_STRIDE;
> + struct sysmon *sysmon = iio_priv(indio_dev);
> + unsigned long alarm_flag_reg;
> + unsigned int reg_val;
> + u32 address, bit;
> + int ret;
> +
> + switch (event) {
[ ... ]
> + case SYSMON_BIT_ALARM0:
> + case SYSMON_BIT_ALARM1:
> + case SYSMON_BIT_ALARM2:
> + case SYSMON_BIT_ALARM3:
> + case SYSMON_BIT_ALARM4:
> + ret = regmap_read(sysmon->regmap, alarm_flag_offset, ®_val);
> + if (ret)
> + return ret;
> +
> + alarm_flag_reg = reg_val;
> +
> + for_each_set_bit(bit, &alarm_flag_reg, SYSMON_ALARM_BITS_PER_REG) {
> + address = bit + SYSMON_ALARM_BITS_PER_REG * event;
> + sysmon_push_event(indio_dev, address);
> + ret = regmap_clear_bits(sysmon->regmap, alarm_reg_offset, BIT(bit));
[Severity: High]
Does clearing this bit permanently disable the supply voltage hardware alarm?
The alarm_reg_offset here points to SYSMON_ALARM_REG, which
sysmon_write_alarm_config() uses as the alarm configuration/enable register.
Since there is no mechanism to re-enable voltage alarms later, does this turn
continuous threshold events into one-shot events?
> + if (ret)
> + return ret;
> + }
> +
> + return regmap_write(sysmon->regmap, alarm_flag_offset, alarm_flag_reg);
> +
> + default:
> + return -EINVAL;
> + }
> +}
[ ... ]
> +static void sysmon_unmask_worker(struct work_struct *work)
> +{
> + struct sysmon *sysmon =
> + container_of(work, struct sysmon, sysmon_unmask_work.work);
> + unsigned int isr;
> +
> + /*
> + * If the ISR read fails, skip processing to avoid acting
> + * on undefined data.
> + */
> + scoped_guard(spinlock_irq, &sysmon->irq_lock) {
> + if (regmap_read(sysmon->regmap, SYSMON_ISR, &isr))
> + break;
[Severity: High]
Can this cause a "scheduling while atomic" panic on I2C devices?
The driver takes a spinlock with interrupts disabled via spinlock_irq,
but then calls regmap_read() which uses a sleeping mutex on I2C buses.
A similar sequence occurs in the hardirq handler sysmon_iio_irq().
> + regmap_write(sysmon->regmap, SYSMON_ISR, isr);
> + sysmon_unmask_temp(sysmon, isr);
> + }
[ ... ]
> +static int sysmon_init_interrupt(struct sysmon *sysmon,
> + struct device *dev,
> + struct iio_dev *indio_dev,
> + int irq)
> +{
> + unsigned int imr;
> + int ret;
> +
> + /* Events not supported without IRQ (e.g. I2C path) */
> + if (!irq)
> + return 0;
> +
> + INIT_DELAYED_WORK(&sysmon->sysmon_unmask_work, sysmon_unmask_worker);
> +
> + ret = regmap_read(sysmon->regmap, SYSMON_IMR, &imr);
> + if (ret)
> + return ret;
> + sysmon->temp_mask = imr & SYSMON_TEMP_INTR_MASK;
> +
> + ret = devm_request_irq(dev, irq, sysmon_iio_irq, 0, "sysmon-irq", indio_dev);
[Severity: High]
Should we verify that the regmap doesn't sleep before requesting the IRQ?
If a user provides an interrupts property for an I2C-connected device in
the Device Tree, it looks like this will register sysmon_iio_irq() as a
hardirq handler and trigger the atomic sleep violations mentioned above.
> + if (ret)
> + return ret;
> +
> + return devm_add_action_or_reset(dev, sysmon_disable_interrupts, sysmon);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617180147.3370346-1-salih.erim@amd.com?part=4
^ permalink raw reply
* Re: [PATCH v4 07/10] Input: cap11xx - refactor code for better CAP1114 support.
From: sashiko-bot @ 2026-06-17 20:57 UTC (permalink / raw)
To: Jun Yan; +Cc: conor+dt, devicetree, dmitry.torokhov, linux-input, robh
In-Reply-To: <20260617150318.753148-8-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Bitmask truncation in `cap11xx_led_set` causing silent failure for LEDs >= 8.
- [High] Regmap cache staleness due to missing volatile register definition for the dynamic `sensor_input_reg_base`.
Pre-existing issues:
- [High] Buffer overflow and Fortify Source panic when reading `calib_sensitivities` for devices with more than 8 channels.
--
commit 837f207153012dfc0860b6d46ad5d3ae4f7b3004
Author: Jun Yan <jerrysteve1101@gmail.com>
Extend cap11xx_hw_model structure to support CAP1114
This patch extends the cap11xx_hw_model structure to support CAP1114
with different register offsets and hardware characteristics.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 1db4a9090705..0f19ee036e78 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -211,8 +215,8 @@ static int cap11xx_init_keys(struct cap11xx_priv *priv)
> }
>
> if (!of_property_read_u32_array(node, "microchip,input-threshold",
> - priv->thresholds, priv->model->num_channels)) {
> + priv->thresholds, priv->model->num_sensor_thresholds)) {
> - for (i = 0; i < priv->model->num_channels; i++) {
> + for (i = 0; i < priv->model->num_sensor_thresholds; i++) {
> if (priv->thresholds[i] > 127) {
> dev_err(dev, "Invalid input-threshold value %u\n",
> priv->thresholds[i]);
[Severity: High]
This is a pre-existing issue, but looking at cap11xx_init_keys(), could
reading "microchip,calib-sensitivity" overflow the calib_sensitivities array
for devices with more than 8 channels?
In cap11xx_init_keys():
} else if (!of_property_read_u32_array(node, "microchip,calib-sensitivity",
priv->calib_sensitivities,
priv->model->num_channels)) {
The calib_sensitivities array is statically allocated to 8 elements in
struct cap11xx_priv. For models with more than 8 channels (like the CAP1114
which has 14), could this cause a buffer overflow into the keycodes array
and trigger a kernel panic if FORTIFY_SOURCE is enabled?
[ ... ]
> @@ -308,7 +314,7 @@ static irqreturn_t cap11xx_thread_func(int irq_num, void *data)
> if (ret < 0)
> goto out;
>
> - ret = regmap_read(priv->regmap, CAP11XX_REG_SENSOR_INPUT, &status);
> + ret = regmap_read(priv->regmap, priv->model->sensor_input_reg_base, &status);
> if (ret < 0)
> goto out;
[Severity: High]
Will this result in reading stale cached values instead of the actual
hardware state?
The interrupt handler now dynamically reads from sensor_input_reg_base.
However, cap11xx_volatile_reg() still hardcodes CAP11XX_REG_SENSOR_INPUT as
a volatile register.
Since the new dynamic base register (and the subsequent register for devices
with more than 8 channels) is no longer marked volatile, will the regmap
cache return stale data and break input events for these models?
[ ... ]
> @@ -362,7 +368,7 @@ static int cap11xx_led_set(struct led_classdev *cdev,
> * 0 (OFF) and 1 (ON).
> */
> return regmap_update_bits(priv->regmap,
> - CAP11XX_REG_LED_OUTPUT_CONTROL,
> + priv->model->led_output_control_reg_base,
> BIT(led->reg),
> value ? BIT(led->reg) : 0);
> }
[Severity: High]
Will this bitmask be truncated for LEDs with an index of 8 or higher?
The bitmask passed to regmap_update_bits() is BIT(led->reg). Since models
like CAP1114 support more than 8 LEDs, and the register operations are 8-bit,
BIT(led->reg) will exceed 8 bits for higher-index LEDs.
The initialization code in cap11xx_init_leds() caps the LED clearance mask to
8 bits:
GENMASK(min(num_leds, 8) - 1, 0)
Does cap11xx_led_set() also need an update to handle devices with more than
8 LEDs to avoid silently failing?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617150318.753148-1-jerrysteve1101@gmail.com?part=7
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox