* [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
* [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
* 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
* 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 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 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 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 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 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] 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 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 v7 0/6] Enable I2C on SA8255p Qualcomm platforms
From: Andi Shyti @ 2026-06-18 1:36 UTC (permalink / raw)
To: Praveen Talari
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Bjorn Andersson, Mukesh Kumar Savaliya, Viken Dadhaniya,
Mattijs Korpershoek, linux-arm-msm, linux-i2c, devicetree,
linux-kernel, bjorn.andersson, konrad.dybcio, aniket.randive,
chandana.chiluveru, prasad.sodagudi, Krzysztof Kozlowski,
Nikunj Kela
In-Reply-To: <20260617-enable-i2c-on-sa8255p-v7-0-ad736dbeab57@oss.qualcomm.com>
Hi Praveen,
> Praveen Talari (6):
> dt-bindings: i2c: Describe SA8255p
> i2c: qcom-geni: Isolate serial engine setup
> i2c: qcom-geni: Move resource initialization to separate function
> i2c: qcom-geni: Use resources helper APIs in runtime PM functions
> i2c: qcom-geni: Store of_device_id data in driver private struct
> i2c: qcom-geni: Enable I2C on SA8255p Qualcomm platforms
merged to i2c/i2c-for-7.2.
Thanks,
Andi
^ permalink raw reply
* RE: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Joakim Zhang @ 2026-06-18 1:38 UTC (permalink / raw)
To: Conor Dooley, krzk+dt@kernel.org
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Gary Yang, cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260617-chummy-automatic-6c11e9958bbf@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:54 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss
> system control
>
> On Wed, Jun 17, 2026 at 02:04:33PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The Cix Sky1 Audio Subsystem (AUDSS) groups audio-related clock, reset
> > and control registers in a dedicated CRU block. Software reset lines
> > are exposed on the syscon parent via #reset-cells, following the same
> > model as the existing Sky1 FCH and S5 system control bindings.
> >
> > A clock-controller child node is required under the audss syscon. It
> > has no reg property of its own and accesses the parent register block
> > for mux, divider and gate fields.
> >
> > The AUDSS is also controlled by one power domain and reset part.
> >
> > Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> > ---
> > .../soc/cix/cix,sky1-system-control.yaml | 48 +++++++++++++++++++
> > .../reset/cix,sky1-audss-system-control.h | 25 ++++++++++
> > 2 files changed, 73 insertions(+)
> > create mode 100644
> > include/dt-bindings/reset/cix,sky1-audss-system-control.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml index a01a515222c6..5a1cd5c24ade 100644
> > ---
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > +++ b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-contro
> > +++ l.yaml
> > @@ -19,6 +19,7 @@ properties:
> > - enum:
> > - cix,sky1-system-control
> > - cix,sky1-s5-system-control
> > + - cix,sky1-audss-system-control
> > - const: syscon
>
> If the only thing these share are being a reset controller and having a syscon
> fallback, I think it should be in a different file.
>
Thanks for the review. I'll split the AUDSS bindings into a separate YAML file.
One follow-up: should the AUDSS CRU driver be split out as well? I'm inclined to do that, so each binding maps to its own driver, but wanted to check whether you'd prefer a separate audss reset driver or keeping everything in reset-sky1 before I rework the series.
Hello @krzk+dt@kernel.org, what's your opinion?
Thanks,
Joakim
^ permalink raw reply
* RE: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Joakim Zhang @ 2026-06-18 1:43 UTC (permalink / raw)
To: Conor Dooley
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
p.zabel@pengutronix.de, Gary Yang, cix-kernel-upstream,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260617-clinic-blank-61289f8fc1c2@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:56 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> clock controller
>
> On Wed, Jun 17, 2026 at 02:04:35PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The AUDSS CRU contains an internal clock tree of muxes, dividers and
> > gates for DSP, I2S, HDA, DMAC and related blocks. The clock provider
> > is a child node of the cix,sky1-audss-system-control syscon and
> > accesses registers through the parent MMIO region.
>
> Why can this not just be part of the parent syscon node?
The clock and reset blocks are handled by different subsystems and maintainers (clk vs reset). Putting the clock provider on the parent syscon node would mean a single driver has to register both the reset controller and the clock provider on one device, which doesn't fit well.
Thanks,
Joakim
^ permalink raw reply
* Re: [PATCH v16 00/10] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-06-18 1:45 UTC (permalink / raw)
To: Mike Rapoport
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, 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: <ajLr53EK6mJbng-7@kernel.org>
On 6/18/2026 2:48 AM, Mike Rapoport wrote:
> Hi Jinjie,
>
> On Mon, Jun 08, 2026 at 03:34:49PM +0800, Jinjie Ruan wrote:
>> The crash memory allocation, and the exclude of crashk_res, crashk_low_res
>> and crashk_cma memory are almost identical across different architectures,
>> This patch set handle them in crash core in a general way, which eliminate
>> a lot of duplication code.
>>
>> And add support for crashkernel CMA reservation for arm64 and riscv.
>>
>> This patch set is rebased on v7.1-rc1.
>
> Please rebase this set on v7.2-rc1 once that's out.
>
> I'm going to queue it in the liveupdate tree then to expose to the wider
> testing.
>
> Meanwhile it would be great to chase riscv and x86 maintainers for acks :)
Thanks! That sounds great.
I will rebase this patch set on v7.2-rc1 as soon as it is out and send v17.
In the meantime, I will CC and reach out to the RISC-V and x86
maintainers to request their reviews and Acks.
Best regards,
Jinjie
>
^ permalink raw reply
* Re: [PATCH v16 06/10] riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
From: Jinjie Ruan @ 2026-06-18 1:54 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
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-7-ruanjinjie@huawei.com>
On 6/8/2026 3:34 PM, Jinjie Ruan wrote:
> 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 two architecture functions need to be implemented:
> - arch_get_system_nr_ranges(). Call get_nr_ram_ranges_callback()
> to pre-counts the max number of memory ranges.
>
> - arch_crash_populate_cmem(). Use prepare_elf64_ram_headers_callback()
> to collects the memory ranges and fills them into cmem.
Hi Paul, Palmer, Albert, Alexandre and RISC-V maintainers,
Sorry for the interruption.
This patch set aims to clean up and refactor the crash memory allocation
and the exclusion logic of crashk_res, crashk_low_res, and crashk_cma.
Currently, these routines are almost identical across different
architectures, leading to a lot of duplicated code.
This series consolidates the logic into the generic crash core, removing
redundant implementations from architecture-specific directories,
including arch/riscv.
There are no functional changes intended for RISC-V.
The patches will be queued in the liveupdate tree for wider testing.
Could you please take a look at the RISC-V side and consider providing
an Acked-by?
The patch series can be reviewed here:
https://lore.kernel.org/all/20260608073459.3119290-1-ruanjinjie@huawei.com/
Thank you very much for your time and review!
Best regards,
Jinjie
>
> Cc: Paul Walmsley <pjw@kernel.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Albert Ou <aou@eecs.berkeley.edu>
> Cc: Alexandre Ghiti <alex@ghiti.fr>
> Cc: Guo Ren <guoren@kernel.org>
> 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/riscv/kernel/machine_kexec_file.c | 47 +++++++-------------------
> 1 file changed, 12 insertions(+), 35 deletions(-)
>
> diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
> index 3f7766057cac..439cbc50dfa6 100644
> --- a/arch/riscv/kernel/machine_kexec_file.c
> +++ b/arch/riscv/kernel/machine_kexec_file.c
> @@ -44,6 +44,15 @@ static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
> return 0;
> }
>
> +unsigned int arch_get_system_nr_ranges(void)
> +{
> + unsigned int nr_ranges = 2; /* For exclusion of crashkernel region */
> +
> + walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> +
> + return nr_ranges;
> +}
> +
> static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
> {
> struct crash_mem *cmem = arg;
> @@ -55,41 +64,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
> return 0;
> }
>
> -static int prepare_elf_headers(void **addr, unsigned long *sz)
> +int arch_crash_populate_cmem(struct crash_mem *cmem)
> {
> - struct crash_mem *cmem;
> - unsigned int nr_ranges;
> - int ret;
> -
> - nr_ranges = 2; /* For exclusion of crashkernel region */
> - walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
> -
> - cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> - if (!cmem)
> - return -ENOMEM;
> -
> - cmem->max_nr_ranges = nr_ranges;
> - cmem->nr_ranges = 0;
> - ret = walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
> - if (ret)
> - goto out;
> -
> - /* Exclude crashkernel region */
> - ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
> - if (ret)
> - goto out;
> -
> - if (crashk_low_res.end) {
> - ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
> - if (ret)
> - goto out;
> - }
> -
> - ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> -
> -out:
> - kfree(cmem);
> - return ret;
> + return walk_system_ram_res(0, -1, cmem, prepare_elf64_ram_headers_callback);
> }
>
> static char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
> @@ -281,7 +258,7 @@ int load_extra_segments(struct kimage *image, unsigned long kernel_start,
> if (image->type == KEXEC_TYPE_CRASH) {
> void *headers;
> unsigned long headers_sz;
> - ret = prepare_elf_headers(&headers, &headers_sz);
> + ret = crash_prepare_headers(true, &headers, &headers_sz, NULL);
> if (ret) {
> pr_err("Preparing elf core header failed\n");
> goto out;
^ permalink raw reply
* Re: [PATCH v3 2/2] drm/tiny: add support for PIXPAPER 4.26 monochrome e-ink panel
From: LiangCheng Wang @ 2026-06-18 2:33 UTC (permalink / raw)
To: Thomas Zimmermann, Devarsh Thakkar, Maarten Lankhorst,
Maxime Ripard, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wig Cheng
Cc: dri-devel, devicetree, linux-kernel, Tomi Valkeinen,
LiangCheng Wang
In-Reply-To: <9fb7915b-dc46-45af-bba1-a3d3a59b5e49@suse.de>
Hi Thomas,
Thanks for the review, and no worries about the timing.
Before I spin a v4 for these comments, I'd like to confirm the overall
direction, since it affects whether this should remain a standalone driver
at all.
In parallel, Devarsh Thakkar is adding a generic Solomon SSD16xx e-paper
driver (panel-ssd16xx.c, currently v1 in review). The PIXPAPER 4.26 uses an
SSD1677, which is part of that family; Devarsh has said he will add SSD1677
support in the next revision (v2) of his series, after which this panel
could be supported there as a panel entry rather than as a separate driver.
That work isn't posted yet, but I had agreed that consolidating under
panel-ssd16xx.c is the better long-term direction.
I'd appreciate your guidance on how to proceed -- whether it is better to
keep iterating on this standalone driver, or to hold it and add the
PIXPAPER 4.26 panel to panel-ssd16xx.c once that driver supports SSD1677.
I'm happy to go whichever way you prefer.
Regards,
LiangCheng
^ permalink raw reply
* Re: [PATCH v4 7/7] arm64: dts: qcom: mahua: Switch pcie5_phy ref clock to RPMH_CXO_CLK
From: Qiang Yu @ 2026-06-18 2:34 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <a956a733-7bb0-46f3-bf21-142d5cb8fc3e@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 02:11:33PM +0200, Konrad Dybcio wrote:
> On 6/15/26 10:51 AM, Qiang Yu wrote:
> > On Tue, Jun 09, 2026 at 03:06:02PM +0200, Konrad Dybcio wrote:
> >> On 5/28/26 4:29 AM, Qiang Yu wrote:
> >>> PCIe5 PHY on Mahua gets refclk from CXO0 pad directly, so no QREF
> >>> clkref_en voting is required. Override the clock list to use RPMH_CXO_CLK
> >>> directly instead.
> >>
> >> This is the last piece of the puzzle that this series is missing.
> >> There's no QREF clkref_en, but there is a refgen that needs to be
> >> powered. For PCIe5 on Mahua this would be L2F_E0 (0p9) and L4H_E0
> >> (1p2).
> >>
> >> I think the easiest (laziest?) solution would be to add dummy clocks
> >> in the clkref driver and only toggle the required regulators. Another
> >> option is to defer back to individual drivers (such as PCIe QMPPHY).
> >>
> >> I kinda like the "one central node to drive power" approach, but I'm
> >> not sure others agree, since it stretches truth just a tiny bit
> >> (although not as much as one would think since there are *some*
> >> controls for the transparent-to-the-OS hw pieces in these paths still
> >> in TCSR).. Dmitry, Krzysztof, would you object to that?
> >>
> >
> > PCIe5 PHY on Mahua does not use QREF at all, so there is no refgen for
> > QREF either. The refgen supplies you mentioned are for the PCIe5 PHY
> > itself, not for QREF. For other PHYs that do use QREF, there are two
> > refgens: one for QREF (voted here in the TCSR clkref driver) and one for
> > the PHY (which should be voted in the PHY driver).
>
> Okay, so in this case we have the refgen regulator hardwired into the
> PHY block and we just consume it from the PHY node&driver, am I following
> correctly?
>
The refgen regulators are not hardwired into the QREF or PHY blocks
directly. They power the REFGEN block, which provides the reference
voltage to QREF and PHY.
- Qiang Yu
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 2:21 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdU0SJ0q2hcpu+qZCH3eZ5eFDyo8Z964h9DhuSaQ7QdHSg@mail.gmail.com>
On 6/17/26 10:26 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>> +{
>> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
>> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
>> + u32 val;
>> +
>> + /* Make sure MSICAP0 MSIE is configured. */
>> + val = dw_pcie_readl_dbi(dw, MSICAP0);
>> + if (pci_msi_enabled())
>> + val |= MSICAP0_MSIE;
>> + else
>> + val &= ~MSICAP0_MSIE;
>> + dw_pcie_writel_dbi(dw, MSICAP0, val);
>> +
>> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
>> + /* Clear AXIINTC mapping. */
>> + writel(0, rcar->base + AXIINTCADDR);
>> + writel(0, rcar->base + AXIINTCCONT);
>> + } else {
>> + /* Point AXIINTC to GIC ITS and enable. */
>> + writel(AXIINTCADDR_VAL, rcar->base + AXIINTCADDR);
>> + writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
>> + }
>> +
>> + /* Configure MSI interrupt signal */
>> + val = readl(rcar->base + PCIEINTSTS0EN);
>> + if (pci_msi_enabled())
>> + val |= MSI_CTRL_INT;
>> + else
>> + val &= ~MSI_CTRL_INT;
>> + writel(val, rcar->base + PCIEINTSTS0EN);
>> +}
>> +
>> static int rcar_gen4_pcie_enable_device(struct pci_host_bridge *bridge,
>
> FTR, this has a contextual dependency on "[PATCH v2] PCI: rcar-gen4:
> Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes"
> (https://lore.kernel.org/all/20260519195219.189323-1-marek.vasut+renesas@mailbox.org).
It is not an explicit dependency, I only had these patches in my tree
and clearly that was an interaction. I'll rebase this dependency out for V2.
Thanks!
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 2:38 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdX7XuHQDSsX4P7NZ46_OnCX2o25szuALwSs2z+PHq+JNg@mail.gmail.com>
On 6/17/26 9:09 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -4901,6 +4901,18 @@ static bool __maybe_unused its_enable_rk3568002(void *data)
>> return true;
>> }
>>
>> +static bool __maybe_unused its_enable_renesas_gen4(void *data)
>> +{
>> + if (!of_machine_is_compatible("renesas,r8a779f0") &&
>> + !of_machine_is_compatible("renesas,r8a779g0") &&
>> + !of_machine_is_compatible("renesas,r8a779h0"))
>
> of_machine_compatible_match() with an array of strings might generate
> smaller code (I didn't check if 3 entries is enough to trip the balance).
Let me handle that as part of suggestion from Marc.
^ permalink raw reply
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 2:50 UTC (permalink / raw)
To: Marc Zyngier, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <864ij1tyrj.wl-maz@kernel.org>
On 6/17/26 9:24 AM, Marc Zyngier wrote:
Hello Marc,
>> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
>> or APB interface configured to 32 bit, it can therefore access only
>> the first 4 GiB of physical address space. This information comes from
>> R-Car V4H Interface Specification sheet, there is currently no technical
>> update number assigned to this limitation. Further input from hardware
>> engineer indicates that this limitation also applies to R-Car S4 and V4M.
>> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
>> limitation.
My concern is this ^ , I do not have an erratum number, because there
isn't one. I am in touch with the hardware engineer and I did get a
glimpse at internal details of the three SoC, which confirm the
limitations. Is this sufficient ?
>> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
>> common for many ARM GICv3 implementations. Therefore, add an extra
>
> Not quite. It designates GIC600 unambiguously.
What I am trying to communicate is, that the 0x0201743b ID is not ID of
the Renesas GIC implementation, but it is a generic ARM GIC600 ID. That
is why we cannot match the quirk on the ID (it is generic ARM GIC600
ID), and instead we have to match the quirk on the [ ID combined with
of_machine_is_compatible("renesas,...") ].
> It is just that GIC600
> is integrated in zillions of SoCs, most of which don't have this
> problem (the machine I'm typing this from has a GIC600 *and* 96GB of
> RAM).
Right.
Shall I reword this paragraph somehow to make it clearer ?
>> of_machine_is_compatible() check.
>>
>> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
>
> Is this relevant?
I included it for the sake of completeness and to provide all relevant
information, based on previous discussions about similar limitations
that I could find on lore.k.o
[...]
>> +#ifdef CONFIG_RENESAS_ERRATUM_GEN4GICITS1
>> + {
>> + .desc = "ITS: Renesas R-Car Gen4 GIC600 32-bit limit",
>> + .iidr = 0x0201743b,
>> + .mask = 0xffffffff,
>> + .init = its_enable_renesas_gen4,
>> + },
>> #endif
>> {
>> }
>
>
> Honestly, that's a bit too much copy-paste for my taste. Just refactor
> the erratum handling to be more generic, something like this:
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8da..380c4758647d2 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4894,10 +4894,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
> return true;
> }
>
> -static bool __maybe_unused its_enable_rk3568002(void *data)
> +static const char * const dma_impaired_platforms[] = {
> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> + "rockchip,rk3566",
> + "rockchip,rk3568",
> +#endif
> + NULL,
> +};
> +
> +static bool __maybe_unused its_enable_dma32(void *data)
> {
> - if (!of_machine_is_compatible("rockchip,rk3566") &&
> - !of_machine_is_compatible("rockchip,rk3568"))
> + if (!of_machine_compatible_match(dma_impaired_platforms))
> return false;
>
> gfp_flags_quirk |= GFP_DMA32;
> @@ -4972,14 +4979,12 @@ static const struct gic_quirk its_quirks[] = {
> .property = "dma-noncoherent",
> .init = its_set_non_coherent,
> },
> -#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> {
> - .desc = "ITS: Rockchip erratum RK3568002",
> + .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
> .iidr = 0x0201743b,
> .mask = 0xffffffff,
> - .init = its_enable_rk3568002,
> + .init = its_enable_dma32,
> },
> -#endif
> {
> }
> };
>
> Then add the two lines you need in a separate patch.
Will do in V2.
> In the future, please provide a cover letter when you have more than a
> single patch (git will happily generate one for you).
OK
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 3:21 UTC (permalink / raw)
To: Manivannan Sadhasivam, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Marc Zyngier, Rob Herring,
devicetree, linux-arm-kernel, linux-doc, linux-kernel,
linux-renesas-soc
In-Reply-To: <lstafqaogzunb2azyqwvtt3swrk42nu3n5zyct2la5fqxomaqg@wyrz3qolhist>
On 6/17/26 12:33 PM, Manivannan Sadhasivam wrote:
Hello Manivannan,
[...]
>> +/* INTC address */
>> +#define AXIINTCADDR 0x0a00
>> +/* GITS GIC ITS translation register */
>> +#define AXIINTCADDR_VAL 0xf1050000
>
> As Marc pointed out, this address should be fetched from DT, not hardcoded in
> the driver.
I will reply to Marc when I have this ready for V2.
>> +
>> +/* INTC control & mask */
>> +#define AXIINTCCONT 0x0a04
>> +#define INTC_EN BIT(31)
>> +#define INTC_MASK GENMASK(11, 2)
>> +
>> /* PCIe Power Management Control */
>> #define PCIEPWRMNGCTRL 0x0070
>> #define APP_CLK_REQ_N BIT(11)
>> @@ -305,6 +319,39 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
>> return rcar;
>> }
>>
>> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>> +{
>> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
>> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
>> + u32 val;
>> +
>> + /* Make sure MSICAP0 MSIE is configured. */
>> + val = dw_pcie_readl_dbi(dw, MSICAP0);
>> + if (pci_msi_enabled())
>> + val |= MSICAP0_MSIE;
>> + else
>> + val &= ~MSICAP0_MSIE;
>> + dw_pcie_writel_dbi(dw, MSICAP0, val);
>> +
>> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
>
> If MSI is not enabled, then what's the point in clearing these registers (also
> above)? I see it as a redundant code. Is there a necessity to clear them?
AXIINTCCONT INTC_EN should not be set if MSI is disabled, this code
makes sure it is not set, even if it might have been left set e.g. by
prior stage. So no, this is not redundant code, this makes sure the
controller is correctly configured.
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: rng: timeriomem_rng: add reg-io-width and mask properties
From: Krzysztof Kozlowski @ 2026-06-18 4:11 UTC (permalink / raw)
To: Jad Keskes, Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Conor Dooley,
Alexander Clouter, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260617114436.1909659-1-inasj268@gmail.com>
On 17/06/2026 13:44, Jad Keskes wrote:
> Add optional reg-io-width (1, 2, or 4 bytes) and mask properties to the
> binding. reg-io-width selects the bus access size, mask is ANDed with
> the raw register value to allow only the entropy-bearing bits through.
>
> Update the example to show a typical 1-byte configuration.
> Update SPDX to dual license to match kernel convention.
And did you Cc all of the copyright holders?
> Drop the misleading '32-bit aligned' constraint from the reg
> description since alignment now depends on the configured width.
>
> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
> .../bindings/rng/timeriomem_rng.yaml | 48 +++++++++++++++----
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml b/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml
> index 4754174e9849..740bc52bf474 100644
> --- a/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml
> +++ b/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml
> @@ -1,10 +1,16 @@
> -# SPDX-License-Identifier: GPL-2.0-only
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Don't mix multiple changes into one commit.
> %YAML 1.2
> ---
> $id: http://devicetree.org/schemas/rng/timeriomem_rng.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: TimerIO Random Number Generator
> +title: Timer IOMEM Hardware Random Number Generator
> +
> +description: |
> + This binding covers platforms that have a single IO memory address which
Do not describe the binding. Describe the hardware.
> + provides periodic random data. The driver reads from the address at a
Do not describe drivers. Describe the hardware.
> + fixed interval, returning a configurable-width value masked to the desired
> + bits.
>
> maintainers:
> - Krzysztof Kozlowski <krzk@kernel.org>
> @@ -13,9 +19,17 @@ properties:
> compatible:
> const: timeriomem_rng
>
> + reg:
> + maxItems: 1
> + description:
> + Base address to sample from. Must be aligned to the configured access
> + width (1, 2, or 4 bytes) and at least that wide.
> +
> period:
> $ref: /schemas/types.yaml#/definitions/uint32
> - description: wait time in microseconds to use between samples
> + description:
> + Interval in microseconds between reads. New random data is expected to
> + be available at this rate.
>
> quality:
> $ref: /schemas/types.yaml#/definitions/uint32
> @@ -26,16 +40,26 @@ properties:
> instead. Note that the default quality is usually zero which disables
> using this rng to automatically fill the kernel's entropy pool.
>
> - reg:
> - maxItems: 1
> + reg-io-width:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 4
> + enum: [1, 2, 4]
> description:
> - Base address to sample from. Currently 'reg' must be at least four bytes
> - wide and 32-bit aligned.
> + Access width in bytes. Determines whether the read is performed as
> + an 8-bit, 16-bit, or 32-bit bus access.
> +
> + mask:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0xFFFFFFFF
> + description:
> + Mask applied to the value read from the register. Bits set to 0 in
> + the mask are cleared in the output data. Default (no mask) passes
> + all bits through.
>
> required:
> - compatible
> - - period
> - reg
> + - period
>
> additionalProperties: false
>
> @@ -46,3 +70,11 @@ examples:
> reg = <0x44 0x04>;
> period = <1000000>;
> };
> +
> + rng@64 {
> + compatible = "timeriomem_rng";
> + reg = <0x64 0x01>;
> + period = <50000>;
> + reg-io-width = <1>;
> + mask = <0xFF>;
> + };
Grow existing example. Or why can't it grow?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: rng: timeriomem_rng: add reg-io-width and mask properties
From: Krzysztof Kozlowski @ 2026-06-18 4:12 UTC (permalink / raw)
To: Jad Keskes, Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Conor Dooley,
Alexander Clouter, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260617114436.1909659-1-inasj268@gmail.com>
On 17/06/2026 13:44, Jad Keskes wrote:
> Add optional reg-io-width (1, 2, or 4 bytes) and mask properties to the
> binding. reg-io-width selects the bus access size, mask is ANDed with
> the raw register value to allow only the entropy-bearing bits through.
>
> Update the example to show a typical 1-byte configuration.
> Update SPDX to dual license to match kernel convention.
> Drop the misleading '32-bit aligned' constraint from the reg
> description since alignment now depends on the configured width.
>
> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
> .../bindings/rng/timeriomem_rng.yaml | 48 +++++++++++++++----
> 1 file changed, 40 insertions(+), 8 deletions(-)
... And where is any changelog?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/8] media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
From: Frank Li @ 2026-06-18 4:13 UTC (permalink / raw)
To: Sakari Ailus
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: <ajMhZP5YHuQdhc5M@kekkonen.localdomain>
On Thu, Jun 18, 2026 at 01:36:20AM +0300, Sakari Ailus wrote:
> Hi Frank,
>
> Thanks for the patch.
Thanks for you quick reply.
>
> 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.
It can cover many case already, there are many bridge type subdev. after
glace of all code, many CSI2RX is type device. It should one kind important
type/case, like sensors.
And I plan do 1 TO N replicator driver, which duplicate 1 sink pad to N
source pad (with/without register config), plus exist video-mux driver,
It think It can cover more than 80% cases.
> 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.
We can add it later if need, which easy to replace 1to1 API, like I did
for sensor one.
>
> - The new helper should work with the existing types and not add new types
> (struct v4l2_subdev_1to1).
May be save vep data into v4l2_subdev to avoid parse it every time. and
enhence media_entity_pads_init() to avoid refer caller data.
>
> - There should be a way to provide default V4L2 fwnode endpoint
> configuration as well as to validate the obtained configuration.
Do you means remote_bustype_cap_mask information get from a callback?
>
> 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.
I tried it before, media and v4l2's clean up is not revised order of init.
Sorry, I can't find original thread. I remember laurnet pinchart said there
are order problem.
1 v4l2_subdev_init()
2. v4l2_async_subdev_nf_init()
3. v4l2_async_nf_register()
4. media_entity_pads_init()
5 v4l2_async_register_subdev()
v4l2_async_unregister_subdev(sd);
v4l2_subdev_cleanup(sd); // Not sure if it save to move to last step
media_entity_cleanup(&sd->entity);
v4l2_async_nf_unregister(&csi2->notifier);
v4l2_async_nf_cleanup(&csi2->notifier);
Frank
>
> --
> Kind regards,
>
> Sakari Ailus
^ 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