* Re: [PATCH v8 1/8] iio: dac: ad5696: properly check i2c_transfer() return value
From: Jonathan Cameron @ 2026-07-18 23:40 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, sashiko-bot
In-Reply-To: <20260716-ad5686-new-features-v8-1-ebb0051af5e5@analog.com>
On Thu, 16 Jul 2026 13:14:17 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Verify that the expected number of i2c messages were transferred when
> ad5686_i2c_read() is called. This issue exists since the support for I2C
> devices was first introduced.
>
> Fixes: 4177381b4401 ("iio:dac:ad5686: Add AD5671R/75R/94/94R/95R/96/96R support")
> Reported-by: sashiko-bot@kernel.org
> Closes: https://lore.kernel.org/all/20260705114746.1485F1F000E9@smtp.kernel.org/
> Reviewed-by: David Lechner <dlechner@baylibre.com>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Let's hold off on this for now. Whilst it is technically correct today I'm
looking into ensuring that we never need this. The only error case
today is actually returning 0 which in practice is an error.
> ---
> drivers/iio/dac/ad5696-i2c.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/dac/ad5696-i2c.c b/drivers/iio/dac/ad5696-i2c.c
> index 279309329b64..551b200bfe14 100644
> --- a/drivers/iio/dac/ad5696-i2c.c
> +++ b/drivers/iio/dac/ad5696-i2c.c
> @@ -7,6 +7,7 @@
> * Copyright 2018 Analog Devices Inc.
> */
>
> +#include <linux/array_size.h>
> #include <linux/errno.h>
> #include <linux/i2c.h>
> #include <linux/mod_devicetable.h>
> @@ -39,9 +40,11 @@ static int ad5686_i2c_read(struct ad5686_state *st, u8 addr)
> AD5686_ADDR(addr) |
> 0x00);
>
> - ret = i2c_transfer(i2c->adapter, msg, 2);
> + ret = i2c_transfer(i2c->adapter, msg, ARRAY_SIZE(msg));
> if (ret < 0)
> return ret;
> + if (ret != ARRAY_SIZE(msg))
> + return -EIO;
>
> return be16_to_cpu(st->data[0].d16);
> }
>
^ permalink raw reply
* Re: [PATCH v8 3/8] iio: dac: ad5686: refactor command/data macros
From: Jonathan Cameron @ 2026-07-18 23:46 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, sashiko-bot
In-Reply-To: <20260716-ad5686-new-features-v8-3-ebb0051af5e5@analog.com>
On Thu, 16 Jul 2026 13:14:19 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Replace usage of bit shifting macros for FIELD_PREP(), which would not
> ignore bit masking when preparing SPI/I2C commands. This change is a code
> hardening measure to be paired with the upcoming triggered buffer support.
> For the AD5310 regmap case, 16-bit data coming from the buffer may overlap
> with command bits if the data field is unmasked.
>
> *_REF_BIT_MSK and *_PD_MSK bit position macros are renamed (with a DATA
> prefix) so to indicate that they are relative to the DATA field.
This is a bit of an 'and' statement in here. I guess I'll let it
go but ideal would be to have done the renames as a precursor keeping
the focus in the main patch on the FIELD_PREP() introductions.
Jonathan
^ permalink raw reply
* Re: [PATCH v8 2/8] iio: dac: ad5686: missing NULL check on match data
From: Jonathan Cameron @ 2026-07-18 23:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rodrigo Alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, sashiko-bot
In-Reply-To: <aloD5HdbntKu--xC@ashevche-desk.local>
On Fri, 17 Jul 2026 13:28:52 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Fri, Jul 17, 2026 at 10:31:26AM +0100, Rodrigo Alencar wrote:
> > On 17/07/26 11:15, Andy Shevchenko wrote:
> > > On Fri, Jul 17, 2026 at 07:51:35AM +0100, Rodrigo Alencar wrote:
> > > > On 16/07/26 21:42, Andy Shevchenko wrote:
> > > > > On Thu, Jul 16, 2026 at 01:14:18PM +0100, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > > > > struct iio_dev *indio_dev;
> > > > > > int ret, i;
> > > > >
> > > > > Move an assignment here as well.
> > > > >
> > > > > chip_info = ...
> > > >
> > > > assignment? this is an input param validation
> > >
> > > Can we make sure we always get a correct one to begin with?
> > > With that an assignment and check can be coupled together.
> > > Also consider use -ENODATA as it's most likely comes from
> > > driver_data.
> >
> > I suppose you are suggesting to move the check to the bus code with:
> >
> > info = i2c_get_match_data(i2c);
> > if (!info)
> > return -ENODATA;
> >
> > rather than here in the core/common code.
>
> Yes! This avoids layering violation and makes the API contract cleaner.
I applied the following rather than going for a v9 for just this:
Shout if I messed it up.
diff --git a/drivers/iio/dac/ad5686-spi.c b/drivers/iio/dac/ad5686-spi.c
index 8abfaf8f0c46..591596a68004 100644
--- a/drivers/iio/dac/ad5686-spi.c
+++ b/drivers/iio/dac/ad5686-spi.c
@@ -98,8 +98,13 @@ static const struct ad5686_bus_ops ad5686_spi_ops = {
static int ad5686_spi_probe(struct spi_device *spi)
{
- return ad5686_probe(&spi->dev, spi_get_device_match_data(spi),
- spi->modalias, &ad5686_spi_ops);
+ const struct ad5686_chip_info *chip_info;
+
+ chip_info = spi_get_device_match_data(spi);
+ if (!chip_info)
+ return -ENODEV;
+
+ return ad5686_probe(&spi->dev, chip_info, spi->modalias, &ad5686_spi_ops);
}
static const struct spi_device_id ad5686_spi_id[] = {
diff --git a/drivers/iio/dac/ad5696-i2c.c b/drivers/iio/dac/ad5696-i2c.c
index d49946adbde3..a6c85d0c33c9 100644
--- a/drivers/iio/dac/ad5696-i2c.c
+++ b/drivers/iio/dac/ad5696-i2c.c
@@ -68,8 +68,13 @@ static const struct ad5686_bus_ops ad5686_i2c_ops = {
static int ad5686_i2c_probe(struct i2c_client *i2c)
{
- return ad5686_probe(&i2c->dev, i2c_get_match_data(i2c),
- i2c->name, &ad5686_i2c_ops);
+ const struct ad5686_chip_info *chip_info;
+
+ chip_info = i2c_get_match_data(i2c);
+ if (!chip_info)
+ return -ENODEV;
+
+ return ad5686_probe(&i2c->dev, chip_info, i2c->name, &ad5686_i2c_ops);
}
>
> > > > > > + if (!chip_info)
> > > > > > + return -ENODEV;
>
^ permalink raw reply related
* Re: [PATCH v8 3/8] iio: dac: ad5686: refactor command/data macros
From: Jonathan Cameron @ 2026-07-18 23:59 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, sashiko-bot
In-Reply-To: <20260716-ad5686-new-features-v8-3-ebb0051af5e5@analog.com>
On Thu, 16 Jul 2026 13:14:19 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Replace usage of bit shifting macros for FIELD_PREP(), which would not
> ignore bit masking when preparing SPI/I2C commands. This change is a code
> hardening measure to be paired with the upcoming triggered buffer support.
> For the AD5310 regmap case, 16-bit data coming from the buffer may overlap
> with command bits if the data field is unmasked.
>
> *_REF_BIT_MSK and *_PD_MSK bit position macros are renamed (with a DATA
> prefix) so to indicate that they are relative to the DATA field.
>
> Reported-by: sashiko-bot@kernel.org
> Closes: https://lore.kernel.org/all/20260628143026.EC6CA1F000E9@smtp.kernel.org/
> Reviewed-by: David Lechner <dlechner@baylibre.com>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Some fuzz when applying this due at least partly to crossing with various
header cleanup related series. Please check I didn't mess it up!
Thanks,
Jonathan
> ---
> drivers/iio/dac/ad5686-spi.c | 21 +++++++++++----------
> drivers/iio/dac/ad5686.c | 10 +++++-----
> drivers/iio/dac/ad5686.h | 22 ++++++++++++----------
> drivers/iio/dac/ad5696-i2c.c | 11 ++++++-----
> 4 files changed, 34 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/iio/dac/ad5686-spi.c b/drivers/iio/dac/ad5686-spi.c
> index 6b6ef1d7071f..d3b64b4361d5 100644
> --- a/drivers/iio/dac/ad5686-spi.c
> +++ b/drivers/iio/dac/ad5686-spi.c
> @@ -9,6 +9,7 @@
> */
>
> #include <linux/array_size.h>
> +#include <linux/bitfield.h>
> #include <linux/errno.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> @@ -26,21 +27,21 @@ static int ad5686_spi_write(struct ad5686_state *st,
>
> switch (st->chip_info->regmap_type) {
> case AD5310_REGMAP:
> - st->data[0].d16 = cpu_to_be16(AD5310_CMD(cmd) |
> - val);
> + st->data[0].d16 = cpu_to_be16(FIELD_PREP(AD5310_CMD_MSK, cmd) |
> + FIELD_PREP(AD5310_DATA_MSK, val));
> buf = &st->data[0].d8[0];
> tx_len = 2;
> break;
> case AD5683_REGMAP:
> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) |
> - AD5683_DATA(val));
> + st->data[0].d32 = cpu_to_be32(FIELD_PREP(AD5686_CMD_MSK, cmd) |
> + FIELD_PREP(AD5683_DATA_MSK, val));
> buf = &st->data[0].d8[1];
> tx_len = 3;
> break;
> case AD5686_REGMAP:
> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) |
> - AD5686_ADDR(addr) |
> - val);
> + st->data[0].d32 = cpu_to_be32(FIELD_PREP(AD5686_CMD_MSK, cmd) |
> + FIELD_PREP(AD5686_ADDR_MSK, addr) |
> + FIELD_PREP(AD5686_DATA_MSK, val));
> buf = &st->data[0].d8[1];
> tx_len = 3;
> break;
> @@ -81,9 +82,9 @@ static int ad5686_spi_read(struct ad5686_state *st, u8 addr)
> return -EINVAL;
> }
>
> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) |
> - AD5686_ADDR(addr));
> - st->data[1].d32 = cpu_to_be32(AD5686_CMD(AD5686_CMD_NOOP));
> + st->data[0].d32 = cpu_to_be32(FIELD_PREP(AD5686_CMD_MSK, cmd) |
> + FIELD_PREP(AD5686_ADDR_MSK, addr));
> + st->data[1].d32 = cpu_to_be32(FIELD_PREP(AD5686_CMD_MSK, AD5686_CMD_NOOP));
>
> ret = spi_sync_transfer(spi, t, ARRAY_SIZE(t));
> if (ret < 0)
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> index d34250647aa4..c285aeed44d1 100644
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
> @@ -35,8 +35,8 @@ static int ad5310_control_sync(struct ad5686_state *st)
> unsigned int pd_val = st->pwr_down_mask & st->pwr_down_mode;
>
> return ad5686_write(st, AD5686_CMD_CONTROL_REG, 0,
> - FIELD_PREP(AD5310_PD_MSK, pd_val & AD5686_PD_MSK) |
> - FIELD_PREP(AD5310_REF_BIT_MSK, st->use_internal_vref ? 0 : 1));
> + FIELD_PREP(AD5310_DATA_PD_MSK, pd_val & AD5686_PD_MSK) |
> + FIELD_PREP(AD5310_DATA_REF_MSK, st->use_internal_vref ? 0 : 1));
> }
>
> static int ad5683_control_sync(struct ad5686_state *st)
> @@ -44,8 +44,8 @@ static int ad5683_control_sync(struct ad5686_state *st)
> unsigned int pd_val = st->pwr_down_mask & st->pwr_down_mode;
>
> return ad5686_write(st, AD5686_CMD_CONTROL_REG, 0,
> - FIELD_PREP(AD5683_PD_MSK, pd_val & AD5686_PD_MSK) |
> - FIELD_PREP(AD5683_REF_BIT_MSK, st->use_internal_vref ? 0 : 1));
> + FIELD_PREP(AD5683_DATA_PD_MSK, pd_val & AD5686_PD_MSK) |
> + FIELD_PREP(AD5683_DATA_REF_MSK, st->use_internal_vref ? 0 : 1));
> }
>
> static inline unsigned int ad5686_pd_mask_shift(const struct iio_chan_spec *chan)
> @@ -565,7 +565,7 @@ int ad5686_probe(struct device *dev,
> break;
> case AD5686_REGMAP:
> ret = ad5686_write(st, AD5686_CMD_INTERNAL_REFER_SETUP, 0,
> - st->use_internal_vref ? 0 : AD5686_REF_BIT_MSK);
> + st->use_internal_vref ? 0 : AD5686_DATA_REF_MSK);
> if (ret)
> return ret;
> break;
> diff --git a/drivers/iio/dac/ad5686.h b/drivers/iio/dac/ad5686.h
> index c424720f8f72..32cb3931413c 100644
> --- a/drivers/iio/dac/ad5686.h
> +++ b/drivers/iio/dac/ad5686.h
> @@ -14,12 +14,14 @@
>
> #include <linux/iio/iio.h>
>
> -#define AD5310_CMD(x) ((x) << 12)
> +#define AD5310_CMD_MSK GENMASK(15, 12)
> +#define AD5310_DATA_MSK GENMASK(11, 0)
>
> -#define AD5683_DATA(x) ((x) << 4)
> +#define AD5683_DATA_MSK GENMASK(19, 4)
>
> -#define AD5686_ADDR(x) ((x) << 16)
> -#define AD5686_CMD(x) ((x) << 20)
> +#define AD5686_CMD_MSK GENMASK(23, 20)
> +#define AD5686_ADDR_MSK GENMASK(19, 16)
> +#define AD5686_DATA_MSK GENMASK(15, 0)
>
> #define AD5686_ADDR_DAC(chan) (0x1 << (chan))
> #define AD5686_ADDR_ALL_DAC 0xF
> @@ -38,15 +40,15 @@
> #define AD5686_CMD_CONTROL_REG 0x4
> #define AD5686_CMD_READBACK_ENABLE_V2 0x5
>
> -#define AD5310_REF_BIT_MSK BIT(8)
> -#define AD5310_PD_MSK GENMASK(10, 9)
> +#define AD5310_DATA_REF_MSK BIT(8)
> +#define AD5310_DATA_PD_MSK GENMASK(10, 9)
>
> -#define AD5683_REF_BIT_MSK BIT(12)
> -#define AD5683_PD_MSK GENMASK(14, 13)
> +#define AD5683_DATA_REF_MSK BIT(12) /* DB16 */
> +#define AD5683_DATA_PD_MSK GENMASK(14, 13) /* DB18:DB17 */
> +
> +#define AD5686_DATA_REF_MSK BIT(0)
>
> -#define AD5686_REF_BIT_MSK BIT(0)
> #define AD5686_PD_MSK GENMASK(1, 0)
> -
> #define AD5686_PD_MODE_1K_TO_GND 0x1
> #define AD5686_PD_MODE_100K_TO_GND 0x2
> #define AD5686_PD_MODE_THREE_STATE 0x3
> diff --git a/drivers/iio/dac/ad5696-i2c.c b/drivers/iio/dac/ad5696-i2c.c
> index 551b200bfe14..2c95d394a1c0 100644
> --- a/drivers/iio/dac/ad5696-i2c.c
> +++ b/drivers/iio/dac/ad5696-i2c.c
> @@ -8,6 +8,7 @@
> */
>
> #include <linux/array_size.h>
> +#include <linux/bitfield.h>
> #include <linux/errno.h>
> #include <linux/i2c.h>
> #include <linux/mod_devicetable.h>
> @@ -36,9 +37,8 @@ static int ad5686_i2c_read(struct ad5686_state *st, u8 addr)
> };
> int ret;
>
> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(AD5686_CMD_NOOP) |
> - AD5686_ADDR(addr) |
> - 0x00);
> + st->data[0].d32 = cpu_to_be32(FIELD_PREP(AD5686_CMD_MSK, AD5686_CMD_NOOP) |
> + FIELD_PREP(AD5686_ADDR_MSK, addr));
>
> ret = i2c_transfer(i2c->adapter, msg, ARRAY_SIZE(msg));
> if (ret < 0)
> @@ -55,8 +55,9 @@ static int ad5686_i2c_write(struct ad5686_state *st,
> struct i2c_client *i2c = to_i2c_client(st->dev);
> int ret;
>
> - st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) | AD5686_ADDR(addr)
> - | val);
> + st->data[0].d32 = cpu_to_be32(FIELD_PREP(AD5686_CMD_MSK, cmd) |
> + FIELD_PREP(AD5686_ADDR_MSK, addr) |
> + FIELD_PREP(AD5686_DATA_MSK, val));
>
> ret = i2c_master_send(i2c, &st->data[0].d8[1], 3);
> if (ret < 0)
>
^ permalink raw reply
* Re: [PATCH v8 2/8] iio: dac: ad5686: missing NULL check on match data
From: Jonathan Cameron @ 2026-07-19 0:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rodrigo Alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, sashiko-bot
In-Reply-To: <20260719005533.41520a27@jic23-huawei>
On Sun, 19 Jul 2026 00:55:44 +0100
Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> wrote:
> On Fri, 17 Jul 2026 13:28:52 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Fri, Jul 17, 2026 at 10:31:26AM +0100, Rodrigo Alencar wrote:
> > > On 17/07/26 11:15, Andy Shevchenko wrote:
> > > > On Fri, Jul 17, 2026 at 07:51:35AM +0100, Rodrigo Alencar wrote:
> > > > > On 16/07/26 21:42, Andy Shevchenko wrote:
> > > > > > On Thu, Jul 16, 2026 at 01:14:18PM +0100, Rodrigo Alencar via B4 Relay wrote:
> >
> > ...
> >
> > > > > > > struct iio_dev *indio_dev;
> > > > > > > int ret, i;
> > > > > >
> > > > > > Move an assignment here as well.
> > > > > >
> > > > > > chip_info = ...
> > > > >
> > > > > assignment? this is an input param validation
> > > >
> > > > Can we make sure we always get a correct one to begin with?
> > > > With that an assignment and check can be coupled together.
> > > > Also consider use -ENODATA as it's most likely comes from
> > > > driver_data.
> > >
> > > I suppose you are suggesting to move the check to the bus code with:
> > >
> > > info = i2c_get_match_data(i2c);
> > > if (!info)
> > > return -ENODATA;
> > >
> > > rather than here in the core/common code.
> >
> > Yes! This avoids layering violation and makes the API contract cleaner.
>
> I applied the following rather than going for a v9 for just this:
> Shout if I messed it up.
>
> diff --git a/drivers/iio/dac/ad5686-spi.c b/drivers/iio/dac/ad5686-spi.c
> index 8abfaf8f0c46..591596a68004 100644
> --- a/drivers/iio/dac/ad5686-spi.c
> +++ b/drivers/iio/dac/ad5686-spi.c
> @@ -98,8 +98,13 @@ static const struct ad5686_bus_ops ad5686_spi_ops = {
>
> static int ad5686_spi_probe(struct spi_device *spi)
> {
> - return ad5686_probe(&spi->dev, spi_get_device_match_data(spi),
> - spi->modalias, &ad5686_spi_ops);
> + const struct ad5686_chip_info *chip_info;
Renamed these to info to match the later patch that has this code anyway.
> +
> + chip_info = spi_get_device_match_data(spi);
> + if (!chip_info)
> + return -ENODEV;
> +
> + return ad5686_probe(&spi->dev, chip_info, spi->modalias, &ad5686_spi_ops);
> }
>
> static const struct spi_device_id ad5686_spi_id[] = {
> diff --git a/drivers/iio/dac/ad5696-i2c.c b/drivers/iio/dac/ad5696-i2c.c
> index d49946adbde3..a6c85d0c33c9 100644
> --- a/drivers/iio/dac/ad5696-i2c.c
> +++ b/drivers/iio/dac/ad5696-i2c.c
> @@ -68,8 +68,13 @@ static const struct ad5686_bus_ops ad5686_i2c_ops = {
>
> static int ad5686_i2c_probe(struct i2c_client *i2c)
> {
> - return ad5686_probe(&i2c->dev, i2c_get_match_data(i2c),
> - i2c->name, &ad5686_i2c_ops);
> + const struct ad5686_chip_info *chip_info;
> +
> + chip_info = i2c_get_match_data(i2c);
> + if (!chip_info)
> + return -ENODEV;
> +
> + return ad5686_probe(&i2c->dev, chip_info, i2c->name, &ad5686_i2c_ops);
> }
>
>
> >
> > > > > > > + if (!chip_info)
> > > > > > > + return -ENODEV;
> >
>
>
^ permalink raw reply
* Re: [PATCH v8 0/8] New features for the AD5686 IIO driver
From: Jonathan Cameron @ 2026-07-19 0:15 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, sashiko-bot,
Maxwell Doose, Joshua Crofts, Andy Shevchenko
In-Reply-To: <20260716-ad5686-new-features-v8-0-ebb0051af5e5@analog.com>
On Thu, 16 Jul 2026 13:14:16 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> This is the second series of three on updating the AD5686 driver.
>
> Initially, a big patch series was sent:
> https://lore.kernel.org/r/20260422-ad5313r-iio-support-v1-0-ed7dca001d1b@analog.com
>
> Then, the first patch series added fixes and cleanups:
> https://lore.kernel.org/linux-iio/20260524-ad5686-fixes-v7-0-b6bf395d08bd@analog.com/
>
> This one is introducing new features:
> - Consume optional reset and correct power supplies;
> - LDAC GPIO handling (active-low, held low when unused);
> - SPI bus sync() implementation for batching multiple transfers;
> - Triggered buffer support, leveraging LDAC and sync() to flush
> all channel writes atomically;
> - Gain control support through the scale property.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Applied 2-8 but with tweaks as called out. Pushed out as testing, please
check I didn't mess it up.
For 1, hopefully I'll get some time this week to put out a set adding
the defensive check in the i2c layer. That API is just too weird
today for my liking.
Jonathan
> ---
> Changes in v8:
> - Add nul-check for chip_info match data.
> - Update comments/commit text and other minor changes.
> - Link to v7: https://lore.kernel.org/r/20260710-ad5686-new-features-v7-0-1bcc8c280e4d@analog.com
>
> Changes in v7:
> - Fix return value check of i2c_transfer().
> - Amend refactoring of command/data macros.
> - Link to v6: https://lore.kernel.org/r/20260705-ad5686-new-features-v6-0-269594c7aae5@analog.com
>
> Changes in v6:
> - Refactor command/data macros in favor of FIELD_PREP()
> - Link to v5: https://lore.kernel.org/r/20260628-ad5686-new-features-v5-0-577caadbf7c0@analog.com
>
> Changes in v5:
> - Create auxiliary handler for the triggered buffer.
> - Do not allow modification of double_scale in case gain_gpio is not set.
> - Link to v4: https://lore.kernel.org/r/20260623-ad5686-new-features-v4-0-28962a57db0f@analog.com
>
> Changes in v4:
> - Replace anyof+const for enum in dt-bindings.
> - Address some sashiko's comments.
> - Use guard(mutex)() in trigger handler and other misc changes.
> - Link to v3: https://lore.kernel.org/r/20260616-ad5686-new-features-v3-0-f829fb7e9262@analog.com
>
> Changes in v3:
> - Add range-double property.
> - Acquire reset control after power-up delay.
> - Include cleanup.h and use guard(mutex)() in read_raw().
> - Link to v2: https://lore.kernel.org/r/20260609-ad5686-new-features-v2-0-70b423f5c76d@analog.com
>
> Changes in v2:
> - Get reset control deasserted.
> - Update entire spi_transfer struct rather than individual fields.
> - Replace udelay() for fsleep() in probe().
> - Minor changes addressing further feedback.
> - Link to v1: https://lore.kernel.org/r/20260602-ad5686-new-features-v1-0-691e01883d27@analog.com
>
> ---
> Rodrigo Alencar (8):
> iio: dac: ad5696: properly check i2c_transfer() return value
> iio: dac: ad5686: missing NULL check on match data
> iio: dac: ad5686: refactor command/data macros
> iio: dac: ad5686: introduce sync operation
> iio: dac: ad5686: implement new sync() op for the spi bus
> iio: dac: ad5686: read_raw/write_raw: use guard(mutex)()
> iio: dac: ad5686: add triggered buffer support
> iio: dac: ad5686: add gain control support
>
> drivers/iio/dac/Kconfig | 2 +
> drivers/iio/dac/ad5686-spi.c | 142 +++++++++++++++++++++-------
> drivers/iio/dac/ad5686.c | 217 +++++++++++++++++++++++++++++++++++++++----
> drivers/iio/dac/ad5686.h | 52 ++++++++---
> drivers/iio/dac/ad5696-i2c.c | 18 ++--
> 5 files changed, 355 insertions(+), 76 deletions(-)
> ---
> base-commit: 4c0ecdbdc0d87570f74e656e21d56bae1ab6a8f1
> change-id: 20260602-ad5686-new-features-e116c04bddb9
>
> Best regards,
^ permalink raw reply
* Re: [PATCH 2/2] iio: accel: mma8452: Allow open drain interrupt pin configuration
From: Jonathan Cameron @ 2026-07-19 1:11 UTC (permalink / raw)
To: Joshua Crofts
Cc: Esben Haabendal, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Martin Kepplinger,
Sean Nyekjaer, David Lechner, Nuno Sá, Andy Shevchenko,
Martin Kepplinger, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260715150148.000045ad@gmail.com>
On Wed, 15 Jul 2026 15:01:48 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> On Wed, 15 Jul 2026 14:21:56 +0200
> Esben Haabendal <esben@geanix.com> wrote:
>
> > > I'm not sure if this was intentional or not in the original implementation.
> >
> > Ah okay. I assumed it was intentional, hinting at the hierarchy of the
> > defines.
> > Should I flatten that, or is it okay to leave it as it is?
> > For what it is worth, I like the current format :)
>
> Up to you of course, nobody can force you to do anything :P
>
FWIW I often ask for this style as it makes it visually much
easier to see what each set are.
No extra spaces == register addresses
2 extra spaces == fields in registers.
4 extra spaces == values for those fields.
Naming does this to some degree but doesn't span multiple registers
or fields in the same way that a bit of indenting does.
Jonathan
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: qcom: x1: disable ps883x USB4 capability
From: Dr. David Alan Gilbert @ 2026-07-19 1:15 UTC (permalink / raw)
To: jens.glathe
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa, Heikki Krogerus, Bjorn Andersson,
Konrad Dybcio, linux-usb, devicetree, linux-kernel, linux-arm-msm,
stable
In-Reply-To: <20260718-ps883x-disable-usb4-v1-5-cec86d0b909e@oldschoolsolutions.biz>
* Jens Glathe via B4 Relay (devnull+jens.glathe.oldschoolsolutions.biz@kernel.org) wrote:
> From: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
>
> Add the "parade,disable-usb4" property to the PS883x node so that the
> retimer driver treats USB4 as USB3. This allows the combo PHY to remain
> in a DP-capable mode, restoring working DisplayPort output over the
> dock while keeping USB functional.
>
> This is a temporary platform workaround until proper USB4 DP tunneling
> support is available.
>
> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Tested-by: Dr. David Alan Gilbert <dave@treblig.org>
on zenbook a14 with tb cable
> ---
> arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 4 ++++
> arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts | 2 ++
> arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 6 ++++++
> arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi | 4 ++++
> arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi | 4 ++++
> arch/arm64/boot/dts/qcom/x1-crd.dtsi | 6 ++++++
> arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi | 4 ++++
> arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi | 2 ++
> arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi | 4 ++++
> arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 6 ++++++
> arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 4 ++++
> arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts | 4 ++++
> arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 6 ++++++
> arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts | 2 ++
> arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi | 4 ++++
> 15 files changed, 62 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> index 9fa86bb6438ec..5ec77c5912f8e 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
> @@ -762,6 +762,8 @@ typec-mux@8 {
> orientation-switch;
> retimer-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -877,6 +879,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts b/arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts
> index bfb7cea56df96..328a360843f4c 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts
> +++ b/arch/arm64/boot/dts/qcom/hamoa-lenovo-ideacentre-mini-01q8x10.dts
> @@ -601,6 +601,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> index ad503beec1d3d..9ce080b9ae896 100644
> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> @@ -703,6 +703,8 @@ typec-mux@8 {
> orientation-switch;
> retimer-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -760,6 +762,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -865,6 +869,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi b/arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi
> index 48c4ad648354e..d67ded1da5875 100644
> --- a/arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-asus-vivobook-s15.dtsi
> @@ -678,6 +678,8 @@ typec-mux@8 {
> orientation-switch;
> retimer-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -798,6 +800,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> index 66d566808f583..e1033d3bef359 100644
> --- a/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-asus-zenbook-a14.dtsi
> @@ -845,6 +845,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -945,6 +947,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> index 9602d65c8b3db..002a974c88751 100644
> --- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
> @@ -967,6 +967,8 @@ typec-mux@8 {
> orientation-switch;
> retimer-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1024,6 +1026,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1112,6 +1116,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> index d6de4da02dcd3..fa17cdafc07b4 100644
> --- a/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-dell-thena.dtsi
> @@ -852,6 +852,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -947,6 +949,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> index 02708f23a8657..4dd62092b8809 100644
> --- a/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-hp-omnibook-x14.dtsi
> @@ -917,6 +917,8 @@ typec-mux@8 {
> orientation-switch;
> retimer-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> index 7559557610ed4..1aa075d6eeda5 100644
> --- a/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1-microsoft-denali.dtsi
> @@ -759,6 +759,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -822,6 +824,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> index 2e38402e2c140..ada5da526634a 100644
> --- a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
> @@ -795,6 +795,8 @@ typec-mux@8 {
> orientation-switch;
> retimer-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -852,6 +854,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -943,6 +947,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi
> index 5d49df41be02a..c8bfb38c64ad5 100644
> --- a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi
> @@ -895,6 +895,8 @@ typec-mux@8 {
> orientation-switch;
> retimer-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -1018,6 +1020,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts b/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
> index ce7b10ea89b6d..11412099eaec1 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
> @@ -726,6 +726,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -789,6 +791,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> index beb1475d7fa0c..d16d3627796b8 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
> @@ -863,6 +863,8 @@ typec-mux@8 {
> orientation-switch;
> retimer-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -920,6 +922,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -977,6 +981,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> index f95b1f9f439d3..55f9df8e5f403 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-medion-sprchrgd-14-s1.dts
> @@ -857,6 +857,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> index 28342cb84ded7..4ccfbe7e14eb8 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> @@ -902,6 +902,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -984,6 +986,8 @@ typec-mux@8 {
> retimer-switch;
> orientation-switch;
>
> + parade,disable-usb4;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> --
> 2.53.0
>
>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* Re: [PATCH 2/5] usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set
From: Dr. David Alan Gilbert @ 2026-07-19 1:14 UTC (permalink / raw)
To: jens.glathe
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa, Heikki Krogerus, Bjorn Andersson,
Konrad Dybcio, linux-usb, devicetree, linux-kernel, linux-arm-msm,
stable
In-Reply-To: <20260718-ps883x-disable-usb4-v1-2-cec86d0b909e@oldschoolsolutions.biz>
* Jens Glathe via B4 Relay (devnull+jens.glathe.oldschoolsolutions.biz@kernel.org) wrote:
> From: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
>
> On Qualcomm X1E80100 platforms using the Parade PS883x retimer (like
> Lenovo ThinkPad T14s Gen6), hotplugging USB4-capable docks such as the
> Lenovo 40B0 results in working USB but no DisplayPort output on the
> dock's HDMI/DP ports.
>
> When the dock negotiates USB4, the retimer receives TYPEC_MODE_USB4
> and forwards it via typec_mux_set(). The qmp_combo PHY then selects
> QMPPHY_MODE_USB3_ONLY because no classic DP altmode SVID is present in
> the state, leaving the DP transmitter and AUX channel disabled.
>
> Add a DT property "parade,disable-usb4" that, when present, makes the
> PS883x driver reject USB4 modes as not supported. DP altmode
> configuration is still applied if negotiated, so both USB and
> DisplayPort continue to work.
>
> This is a temporary workaround until proper USB4 DP tunneling support
> is available in the X1E USB4 controller and qmp_combo PHY stack.
>
> Link: https://patch.msgid.link/20260312101431.2375709-1-krishna.kurapati@oss.qualcomm.com
> Assisted-by: Grok(xAI):4.3
> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Tested-by: Dr. David Alan Gilbert <dave@treblig.org>
On zenbook a14 with the following patches and a TB cable
> ---
> drivers/usb/typec/mux/ps883x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/usb/typec/mux/ps883x.c b/drivers/usb/typec/mux/ps883x.c
> index 64e0a61b776a1..3fa26ce01a9c9 100644
> --- a/drivers/usb/typec/mux/ps883x.c
> +++ b/drivers/usb/typec/mux/ps883x.c
> @@ -62,6 +62,7 @@ struct ps883x_retimer {
>
> enum typec_orientation orientation;
> bool in_reset;
> + bool disable_usb4;
> };
>
> static int ps883x_enable_vregs(struct ps883x_retimer *retimer)
> @@ -249,6 +250,13 @@ static int ps883x_set(struct ps883x_retimer *retimer, struct typec_retimer_state
> cfg0 |= CONN_STATUS_0_USB_3_1_CONNECTED;
> break;
> case TYPEC_MODE_USB4:
> + if (retimer->disable_usb4) {
> + dev_info(&retimer->client->dev,
> + "USB4 disabled via DT property, rejecting USB4 mode\n");
> + return -EOPNOTSUPP;
> + }
> +
> + /* Normal USB4 handling */
> eudo_data = state->data;
>
> cfg2 |= CONN_STATUS_2_USB4_CONNECTED;
> @@ -378,6 +386,8 @@ static int ps883x_retimer_probe(struct i2c_client *client)
>
> retimer->client = client;
>
> + retimer->disable_usb4 = device_property_read_bool(dev, "parade,disable-usb4");
> +
> mutex_init(&retimer->lock);
>
> retimer->regmap = devm_regmap_init_i2c(client, &ps883x_retimer_regmap);
>
> --
> 2.53.0
>
>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* Re: [PATCH 2/2] iio: accel: mma8452: Allow open drain interrupt pin configuration
From: Jonathan Cameron @ 2026-07-19 1:30 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Esben Haabendal, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Martin Kepplinger,
Sean Nyekjaer, David Lechner, Nuno Sá, Andy Shevchenko,
Martin Kepplinger, linux-iio, devicetree, linux-kernel
In-Reply-To: <alpqq3zhSS_iYGJq@ashevche-desk.local>
On Fri, 17 Jul 2026 20:47:23 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Fri, Jul 17, 2026 at 02:02:50PM +0200, Esben Haabendal wrote:
> > "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> > > On Thu, Jul 16, 2026 at 04:51:34PM +0000, Esben Haabendal wrote:
> > >> On Wednesday, 15 July 2026 at 16:56, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > >> > On Wed, Jul 15, 2026 at 04:25:20PM +0200, Esben Haabendal wrote:
> > >> > > "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> > >> > > > On Wed, Jul 15, 2026 at 01:35:41PM +0200, Esben Haabendal wrote:
> > >> > > >> "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> > >> > > >> > On Wed, Jul 15, 2026 at 10:07:39AM +0200, Esben Haabendal wrote:
>
> ...
>
> > >> > > >> >> if (client->irq) {
> > >> > > >> >> ret = request_threaded_irq(client->irq, NULL, mma8452_interrupt,
> > >> > > >> >> - IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> > >> > > >> >> + IRQF_TRIGGER_LOW | IRQF_ONESHOT |
> > >> > > >> >> + data->open_drain ? IRQF_SHARED : 0,
> > >> > > >> >> client->name, indio_dev);
> > >> > > >> >
> > >> > > >> > Why do we care?
> > >> > > >>
> > >> > > >> Care about what exactly?
> > >> > > >
> > >> > > > About exclusivity of the interrupt.
> > >> > >
> > >> > > Ok.
> > >> > >
> > >> > > >> We need to add IRQF_SHARED flag in order to allow shared interrupt, and
> > >> > > >> we should not add it when using (the default) push-pull mode.
> > >> > > >
> > >> > > > Why not? How would it make any difference from SW perspective?
> > >> > >
> > >> > > Not adding the IRQF_SHARED flag prevents use with shared interrupts. I
> > >> > > think we are on the same page on that.
> > >> > >
> > >> > > Unconditional adding IRQF_SHARED flag would allow configurations where
> > >> > > other devices share interrupt line with mma8452 compatible chip
> > >> > > configured with push-pull, resulting in broken or unpredictable results.
> > >> > > I don't see why we should not care about that.
> > >> >
> > >> > But it's not their problem! If it's this device that prevents this
> > >> > configuration, it should have a check. With this code it just hides
> > >> > and changing a DT property will lead to kernel warning.
> > >>
> > >> The chip such does not prevent the configuration, and does not prevent
> > >> sharing the interrupt. The irq pin in the device can be configured in either
> > >> push-pull mode or open-drain mode.
> > >> In order to allow sharing interrupt line with other chips, the chip
> > >> must be configured with irq pin in open-drain mode, which is what the
> > >> drive-open-drain device-tree property I am adding in this series enables
> > >> developers to do.
> > >> If/when you add this property to the device-tree, the irq pin will be
> > >> in open-drain mode, and the IRQF_SHARED flag can (and should IMHO) be set
> > >> as the interrupt line can be shared.
> > >> If/when the drive-open-drain property is not set (existing device-trees
> > >> and current only supported behavior), the chip cannot support sharing the
> > >> interrupt line, and adding the IRQF_SHARED flag would be a bug, as the
> > >> chip irq pin requires an exclusive interrupt input.
> > >>
> > >> Maybe the confusion is caused by the fact that the drive-open-drain
> > >> does not describe how the irq pin IS behaving, but rather how it SHOULD
> > >> behave, and possibly required because of the HW designed having tied the
> > >> irq pin to an irq input together with other irq sources.
> > >
> > > Why do we care of push-pull then? Can't we always make it open-drain?
> >
> > No. Open-drain requires an external pull-up resistor. If there are no
> > external pull-up resistor, open-drain will not work, and interrupt
> > sharing is not possible.
>
> Right. My question was basically to understand if we have the HW (platforms to
> which this sensor is attached) that relies on this pin to be PP (in current
> configuration)?
I'd met plenty of boards where the resistor wasn't there for other sensors
(including one that 'shared' the interrupt - worked much better once we'd
patched a resistor on) so I'd say it is very likely those exist.
Anyhow it is also trivial to put an interrupt multiplexer in the path for
the push pull case (I've seen this on a real design). In this case an
AND gate will do the job Sure you'd not bother if both sensors were
capable of open-drain, but maybe only one of them is? We could of course
make that an explicit component and give it a driver, but meh, why
bother - just allow the combination argued against here of push-pull
and IRQF_SHARED.
So I'd just set IRQF_SHARED unconditionally.
>
> > >> > > > Yes, I understand the HW case.
> > >> > > >
> > >> > > >> > The (hidden) problem this will have in the future is that the IRQ core
> > >> > > >> > will splat a warning in case that other shared IRQs might be
> > >> > > >> > configured with different flags. Putting that flag conditionally makes
> > >> > > >> > it a mine field for the users. Instead just unconditionally add that
> > >> > > >> > flag and we will get reports as soon as there will be a user that
> > >> > > >> > shares the same interrupt pin with some other devices which drivers do
> > >> > > >> > not use the same settings.
> > >> > > >>
> > >> > > >> If we add the IRQF_SHARED flag unconditionally, it will be set also when
> > >> > > >> push-pull mode is enabled. I don't see how the kernel will be able to
> > >> > > >> notice that that is not going to work. If you have another device that
> > >> > > >> uses IRQF_TRIGGER_LOW|IRF_ONESHOT|IRQF_SHARED, it will not work with the
> > >> > > >> MMA8452 device when configured as push-pull.
> > >> > > >
> > >> > > > Right, and why do we care (again)?
> > >> > >
> > >> > > Why we care that the system as a whole (SW on top of HW) will not work?
> > >> > >
> > >> > > If we don't care about that, why do we even have this IRQF_SHARED flag?
> > >> > > The only purpose of that is to tell the kernel that this particular
> > >> > > device / interrupt will work with shared interrupt or not.
> > >> > >
> > >> > > Isn't that exactly what I do with this change? Nothing more, nothing less.
> > >> > >
> > >> > > > It's pure DT/FW/HW issue, not an SW issue.
> > >> > > > Otherwise it will become a carefully placed mine for the poor user who will
> > >> > > > use these flags and try to share an interrupt with the mma8452 device which
> > >> > > > has no set property and uses push-pull mode.
> > >> > >
> > >> > > I don't get how you see it like that. Adding IRQF_SHARED unconditionally
> > >> > > would create exactly the mine field you are talking about. Poor users
> > >> > > can specify a system configuration (DT) that tries to use a shared
> > >> > > interrupt line, but configures the mma8452 compatible chip in push-pull.
> > >> > > The poor user will not only be poor, but also unhappy.
> > >> >
> > >> > > By applying the IRQF_SHARED dynamically, the kernel will be able to fail
> > >> > > in a controlled manner instead, making it much less painful to create a
> > >> > > working system configuration (DT)
> > >> >
> > >> > And my point that we need to make less painful runtime experience.
> > >>
> > >> Yes. We agree on that.
> > >>
> > >> But I do believe that my patch is that painful runtime experience.
> > >>
> > >> Adding IRQF_SHARED flag when irq pin is configured in push-pull mode
> > >> will be painful. I know, that was my initial approach. Does really not
> > >> work, and can lead to wasting time on debugging the HW.
> > >>
> > >> > > Going back to your poor user story above, if the poor user tries to
> > >> > > share the interrupt pin with the mma8452 device, it will get an error
> > >> > > (just as it is with the kernel today). The device does not support
> > >> > > shared interrupts. Reading the DT bindings documentation, the user
> > >> > > should be able to find the drive-open-drain property, and add that to
> > >> > > the device-tree to make things work. Maybe even consider if that is
> > >> > > compatible with the hardware being used.
> > >> > >
> > >> > > If IRQF_SHARED was set unconditionally, the user would not get an error,
> > >> > > but most likely would get a system where no irq's were raised for the
> > >> > > other chips. I sincerely believe that debugging this is much more
> > >> > > painful than reading device-tree bindings.
> > >> > >
> > >> > > > Did I miss anything?
> > >> > >
> > >> > > I don't know. Maybe I am missing the obvious here.
> > >> >
> > >> > I consider the case when shared interrupt is enabled on both devices, but
> > >> > second one (driver) missed the same IRQ flags. This becomes a warning in
> > >> > IRQ core.
> > >>
> > >> Missed which IRQ flags?
> > >
> > > _LOW, for instance.
> >
> > All devices sharing an interrupt really do need to agree on these
> > flags. Do you known any drivers that does not specify the trigger type
> > when requesting an irq?.
>
> Huh?! Majority of the device drivers! And that's how it should have been from
> day 1, that's why I call this a pre-existing bug in this driver which we may
> not address :-(. But we may address it when use SHARED interrupts.
>
> > You cannot share an interrupt line if not all devices have the
> > same trigger mode. So if one device on a shared interrupt has _LOW, all
> > the other devices need to have that. Not just the flags, but the actual
> > triggering mode of the device. Some chips might support more than one
> > mode, others only one specific mode.
>
> Yes.
>
> > >> > Shared interrupts it's also a contract with all stakeholders on keeping
> > >> > the same flags for all devices.
> > >>
> > >> Of-course.
> > >>
> > >> And adding IRQF_SHARED is a contract that says that the interrupt can be
> > >> shared. I can only see that it would be a bug to add that flag in cases
> > >> where we know that the interrupt really cannot be shared.
> > >>
> > >> As for the IRQF_TRIGGER_LOW flag being set, I think that looks correct
> > >> as long as we do not support switching to active high irq polarity.
> > >
> > > No, it's not. It overrides whatever platform wants to have.
> >
> > The trigger type is not just a platform thing. It describes how the
> > device behaves.
>
> No, it describes how this certain device is connected to the certain platform.
> It's a combination of what device is capable of and how platform design makes
> use of it.
>
> > Device that only support one triggering mode must set
> > the flag that describes that. Devices that can be configured for
> > different triggering modes can implement that, and should then configure
> > the device for the chosen mode and set the flags accordingly.
>
> Yes, but not in the device drivers!
Absolutely agree on this point. Setting interrupt sense / type in a driver
was something I used to miss in reviews and is effectively impossible to
fix without regressions. This should be coming from firmware. The mention
elsewhere of a not gate in the path is annoyingly common as it is a really
cheap way to solve voltage level mismatches.
So I think Andy made a good point that, given until now shared interrupts
weren't possible, we can't regress any board if we remove the _LOW bit
for at least those. With the above thing (the AND gate interrupt combiner)
arguing for IRQF_SHARED always this gets a bit less obvious though.
We have had some 'novel' solutions in the past where we needed to enable
the opposite sense from firmware in which we check if firmware made a choice
to be _HIGH. If it did we override the _LOW in the driver.
Could that work here to avoid that _LOW forcing in all but a fallback
case to avoid regressions?
>
> > > It prevents PCB level designs from anything else.
> >
> > Yes. In this case, the current driver does not support designs that
> > requires the mma8452 compatible chip to be configured for active high
> > irq trigger. We could and probably should address that.
>
> Exactly!
>
> > But that is a different issue than what I am doing here. And I don't
> > have hardware readily available where this can be tested, so I would
> > prefer to let somebody else do that.
>
> No objection on the specific issue, but...
>
> > I am adding support for designs that require the mma8452 compatible chip
> > to be configured for open-drain, while staying backwards compatible and
> > allowing support for designs without external pull-up.
>
> ...the shared case *is* different. And I do not want the disaster (a bug)
> to spread.
>
> > In all cases, the driver should register the interrupt handle with the
> > IRQF_TRIGGER_* flag that matches what the chip is configured for.
> > I believe leaving it out is invalid.
>
> Again, this chip is not a single party in the equation. Nobody prevents
> to put a NOT gate on PCB to support this device and say other that wants
> inverted polarity while sharing the same interrupt line.
>
> > >> But on that topic, the chip actually supports selecting between active
> > >> low and high irq polarity. Should we implement something along the lines
> > >> of what is done in smi330_setup_irq() in iio/imu/smi330/smi330_core.c?
> > >> And thereby allow using the device with active high irq?
>
I've always been really nervous about that approach because we might get
one of those with a not gate. If we do then we do have to an explicit
device to do the interrupt inversion.
I did let myself get talked into that handling a long time back but
in conflates the interrupt description at the two ends of a path with
possible logic on it.
> ...
>
> > >> > After looking into genirq code I don't see other way how to handle this.
> > >> > It looks like we need to address the TRIGGER_LOW first, in other words
> > >> > we need drop that flag when IRQF_SHARED is set, and leave it to users
> > >> > to setup IRQ trigger properly on all sides.
> > >>
> > >> Why do we need to drop the IRQF_TRIGGER_LOW flag because IRQF_SHARED is
> > >> set?
> > >>
> > >> Users as in those specifying the system device-tree?
> > >
> > > No, because like I said, the SHARED is a *contract*, it's not just a setting.
> >
> > Absolutely. That is the key here.
> >
> > IQRF_SHARED is a contract, where the driver promises to return IRQ_NONE
> > if the interrupt is not for that device. This is already implemented
> > by mma8452_interrupt().
> >
> > > And that contract includes the similarities on the IRQ flags. One may not
> > > have two devices with different trigger level, it's a common sense,
> > > right?
> >
> > Right.
> >
> > And that is exactly why we have to specify the IRQF_TRIGGER_* flag that
> > the irq output is configured for.
>
> No, definitely the opposite. We may *not* specify this flag in the driver,
> we have to rely on the _platform_ configuration. PCB level.
>
> > The driver will not switch to the
> > desired trigger level based on what other devices on the same interrupt
> > uses. You have to configure/specify the trigger mode and leve and set
> > the IRQF_TRIGGER_* flag accordingly.
>
> Yes, but not in the driver!
>
> > > So, SHARED must exclude anything that comes from the platform description or
> > > IRQ chip controller (limitations).
> >
> > Now you got me confused again. The IRQF_TRIGGER_LOW flag given to
> > request_threaded_irq() is not coming from platform description or IRQ
> > chip controller. It describes the trigger mode that the chip is
> > excercising in the current implementation.
>
> And this is wrong. It's not device driver business to define this. More
> accurate it's not only of the device in question and how it works.
>
> > The kernel would not know how to configure the IRQ chip controller, and
> > in case of shared interrupts, would not be able to check that the
> > devices sharing the interrupt is configured correctly.
>
> Huh?! The kernel is responsible to program IRQ chip and the respective
> device drivers in accordance with the platform design (and protocol to
> supply it to the OS is called DT or ACPI or ...).
>
> There are several limitations for this:
> - IRQ chip that might not support certain trigger configurations
> - device that can only take subset of trigger configurations
> - in shared line case all of the devices need to agree on that
> on a _platform_ level
>
> > > So, without addressing that, it makes a little sense to add SHARED.
> >
> > Not true.
>
> True. Obviously we have a disagreement here and I tried hard to explain
> my point above.
>
> > Let me take my system here. I have multiple chips / irq sources
> > connected to the same interrupt input on the CPU. They are all using
> > level low triggering (which hardware and system engineers have ofcourse
> > been observant enough to ensure).
>
> And if not? Isn't it possible to make them share an interrupt line?
> Of course it's very much possible, but in the platform description
> the both devices will need to have the same one, so for the second
> one it will be a bit of a lie (due to an external NOT gate or a latch
> or any other PCB level tricks).
>
> > Without my change, the mma8452 driver does not support configuring the
> > chip to use open-drain, so it will be pulling the interrupt line high,
> > interrupting irq for all interrupt sources.
>
> I even don't consider this, this is obvious. And you are correct here.
>
> > With my change, I can now configure the device to use open-drain,
> > register the interrupt, and everything works nicely.
>
> Nope, it depends on the other stakeholders.
>
> > And the change is backwards compatible, as you have to specify
> > drive-open-drain to switch from PP to OD.
> >
> > How does that not make sense?
>
> Please, read again what I wrote.
>
> > > I would accept this patch without adding SHARED, perhaps.
> >
> > Without IRQF_SHARED, I cannot use it with the hardware I have which are
> > sharing the interrupt.
>
> True, but with _LOW it makes a little sense to use SHARED.
>
> > > But still question why we can't use the OD instead of PP for the pin
> > > to begin with?
> >
> > Because HW needs to be designed for OD. It is perfectly valid to design
> > hardware that relies on the default mode of mma8452 and compatible chips
> > to use PP. Switching to OD will not work for such systems without
> > external pull-up.
> >
> > > Do we have real HW that uses IRQ input without a pull-up?
> >
> > I certainly have had such designs many times in the past.
>
> Okay.
>
> > Why should we implement the driver so that we cannot support such valid
> > HW designs?
>
> This is exactly my question as your patch limits this to _LOW.
> And this is a big issue with it.
>
> ...
>
> P.S.
> I'm on vacation, but I disagree on the approach taken in this patch.
> I leave it to you and Jonathan and others to settle down.
>
> Here is my formal NAK (to this form of the patch, as I said, w/o shared
> support it might be okay to go).
>
^ permalink raw reply
* Re: [PATCH v2 0/3] io: accel: mma8452: Allow open drain interrupt pin configuration
From: Jonathan Cameron @ 2026-07-19 1:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Esben Haabendal, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Martin Kepplinger,
Sean Nyekjaer, David Lechner, Nuno Sá, Andy Shevchenko,
Martin Kepplinger, linux-iio, devicetree, linux-kernel
In-Reply-To: <aleRUWg9MZWgXMVs@ashevche-desk.local>
On Wed, 15 Jul 2026 16:55:29 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Wed, Jul 15, 2026 at 02:33:26PM +0200, Esben Haabendal wrote:
> > Extend the mma8452 driver with support for configuration of the
> > interrupt line in open-drain mode, which is needed for hardware designs
> > where the interrupt line is shared with other chips.
> >
> > Adding drive-open-drain property to mma8452 device-tree node for such
> > designs to enable switching pin configuration to open-drain mode.
>
> NAK.
>
> Please, do not send a new version until everything is settled down in the
> previous round. Let's continue discussion in v1.
>
Even if the conversation there hadn't been ongoing, please slow down
with new versions. At least 24 hours, preferably a week between versions
of anything non trivial (and this turned out not to be!)
Jonathan
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: iio: light: ltr501: Add ltr329 compatible
From: Jonathan Cameron @ 2026-07-19 1:38 UTC (permalink / raw)
To: Esben Haabendal
Cc: Krzysztof Kozlowski, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nikita Travkin,
Maslov Dmitry, linux-iio, devicetree, linux-kernel
In-Reply-To: <pnxaJvFlsLehHV30SMlmWECZnbQ6Rqb2cvWWlVbjYKsg9v0i_Wyu28e7U_OYfV1XooewL13ZLUMBjODBTYnBuiI0t9m-bxt8AdKsz9oizok=@geanix.com>
On Thu, 16 Jul 2026 16:14:55 +0000
Esben Haabendal <esben@geanix.com> wrote:
> On Thursday, 16 July 2026 at 10:07, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> > On Wed, Jul 15, 2026 at 02:27:24PM +0200, Esben Haabendal wrote:
> > > LTR-329ALS-01 is an ambient light sensor similar to LTR-303ALS-01, but
> > > without interrupt support.
> > >
> > > Signed-off-by: Esben Haabendal <esben@geanix.com>
> > > ---
> > > Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> > > index ab9bb68dd736..76e81eba7ea4 100644
> > > --- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> > > +++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> > > @@ -19,6 +19,7 @@ properties:
> > > - liteon,ltr559
> > > - liteon,ltr301
> > > - liteon,ltr303
> > > + - liteon,ltr329
> >
> > Do not grow lists at the end, they are ordered alphanumerically to avoid
> > conflicts.
>
> Placing the new entry at the top would produce a rather strangely order list:
>
> ltr329
> ltr501
> ltr559
> ltr301
> ltr329
>
> Should I add a patch sorting the entire list to avoid this kind of
> confusion in the future?
>
Please do a precursor patch for that Also do it for the id tables in the driver.
Thanks,
Jonathan
> /Esben
^ permalink raw reply
* Re: [PATCH v2 3/4] iio: light: ltr501: Add ltr329 driver support
From: Jonathan Cameron @ 2026-07-19 1:47 UTC (permalink / raw)
To: Esben Haabendal
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nikita Travkin, Maslov Dmitry,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260715-liteon-ltr329-v2-3-d18af55edab5@geanix.com>
On Wed, 15 Jul 2026 14:27:25 +0200
Esben Haabendal <esben@geanix.com> wrote:
> This adds support for the LTR-329ALS-01 chip, which is similar to
> LTR-303ALS-01, except for interrupt, which LTR-329ALS-01 chip does not
> have.
>
> Signed-off-by: Esben Haabendal <esben@geanix.com>
Hi Esben
A few comments inline.
Thanks,
Jonathan
> ---
> drivers/iio/light/ltr501.c | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
> index 7d045be78c6d..379e57ac5f5b 100644
> --- a/drivers/iio/light/ltr501.c
> +++ b/drivers/iio/light/ltr501.c
> @@ -15,6 +15,7 @@
> #include <linux/delay.h>
> #include <linux/regmap.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/array_size.h> // for ARRAY_SIZE
>
> #include <linux/iio/iio.h>
> #include <linux/iio/events.h>
> @@ -94,6 +95,7 @@ enum {
> ltr559,
> ltr301,
> ltr303,
> + ltr329,
> };
>
> struct ltr501_gain {
> @@ -178,6 +180,11 @@ static const struct ltr501_samp_table ltr501_ps_samp_table[] = {
> {500000, 2000000}
> };
>
> +static bool ltr501_has_irq_support(const struct ltr501_chip_info *chip_info)
> +{
> + return chip_info->info != chip_info->info_no_irq;
> +}
> +
> static int ltr501_match_samp_freq(const struct ltr501_samp_table *tab,
> int len, int val, int val2)
> {
> @@ -428,6 +435,9 @@ static int ltr501_read_intr_prst(const struct ltr501_data *data,
> {
> int ret, samp_period, prst;
>
> + if (!ltr501_has_irq_support(data->chip_info))
> + return 0;
This is only called in two places. One of those is events infrastructure
that I would assume is not registered. For the other in _init I'd
push the check to the caller. Would avoid oddity that we seem to read
this and get an 'all good' return when there is no such thing to read.
> +
> switch (type) {
> case IIO_INTENSITY:
> ret = regmap_field_read(data->reg_als_prst, &prst);
> @@ -466,6 +476,9 @@ static int ltr501_write_intr_prst(struct ltr501_data *data,
> int ret, samp_period, new_val;
> unsigned long period;
>
> + if (!ltr501_has_irq_support(data->chip_info))
This one is called when setting sampling frequency. I'd gate whether
it is called in __ltr501_write_raw() rather than down here for same reason
as the read side.
> + return 0;
> +
> if (val < 0 || val2 < 0)
> return -EINVAL;
>
> @@ -1257,6 +1270,18 @@ static const struct ltr501_chip_info ltr501_chip_info_tbl[] = {
> .channels = ltr301_channels,
> .no_channels = ARRAY_SIZE(ltr301_channels),
> },
> + [ltr329] = {
> + .partid = 0x0A,
> + .als_gain = ltr559_als_gain_tbl,
> + .als_gain_tbl_size = ARRAY_SIZE(ltr559_als_gain_tbl),
> + .als_mode_active = BIT(0),
> + .als_gain_mask = BIT(2) | BIT(3) | BIT(4),
> + .als_gain_shift = 2,
> + .info = <r301_info_no_irq,
> + .info_no_irq = <r301_info_no_irq,
The suggestion about a flag in your discussion with Nuno makes sense to me.
> + .channels = ltr301_channels,
> + .no_channels = ARRAY_SIZE(ltr301_channels),
> + },
> };
>
> static int ltr501_write_contr(struct ltr501_data *data, u8 als_val, u8 ps_val)
> @@ -1531,6 +1556,12 @@ static int ltr501_probe(struct i2c_client *client)
> return ret;
>
> if (client->irq > 0) {
> + if (!ltr501_has_irq_support(data->chip_info)) {
> + dev_err(&client->dev, "chip does not support irq\n");
> + ret = -EINVAL;
> + goto powerdown_on_error;
> + }
> +
> ret = devm_request_threaded_irq(&client->dev, client->irq,
> NULL, ltr501_interrupt_handler,
> IRQF_TRIGGER_FALLING |
> @@ -1604,6 +1635,7 @@ static const struct i2c_device_id ltr501_id[] = {
> { .name = "ltr559", .driver_data = ltr559 },
> { .name = "ltr301", .driver_data = ltr301 },
> { .name = "ltr303", .driver_data = ltr303 },
> + { .name = "ltr329", .driver_data = ltr329 },
Please put these in numeric order in a precursor patch.
> { }
> };
> MODULE_DEVICE_TABLE(i2c, ltr501_id);
> @@ -1613,6 +1645,7 @@ static const struct of_device_id ltr501_of_match[] = {
> { .compatible = "liteon,ltr559", },
> { .compatible = "liteon,ltr301", },
> { .compatible = "liteon,ltr303", },
> + { .compatible = "liteon,ltr329", },
> { }
> };
> MODULE_DEVICE_TABLE(of, ltr501_of_match);
>
^ permalink raw reply
* Re: [PATCH v2 4/4] iio: light: ltr501: Power down chip if request irq fails
From: Jonathan Cameron @ 2026-07-19 1:51 UTC (permalink / raw)
To: Esben Haabendal
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nikita Travkin, Maslov Dmitry,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260715-liteon-ltr329-v2-4-d18af55edab5@geanix.com>
On Wed, 15 Jul 2026 14:27:26 +0200
Esben Haabendal <esben@geanix.com> wrote:
> In case request irq failed, we were leaving the chip powered instead of
> powering it down again.
>
> Signed-off-by: Esben Haabendal <esben@geanix.com>
> ---
> drivers/iio/light/ltr501.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
> index 379e57ac5f5b..9d4de798e5ab 100644
> --- a/drivers/iio/light/ltr501.c
> +++ b/drivers/iio/light/ltr501.c
> @@ -1571,7 +1571,7 @@ static int ltr501_probe(struct i2c_client *client)
> if (ret) {
> dev_err(&client->dev, "request irq (%d) failed\n",
> client->irq);
> - return ret;
> + goto powerdown_on_error;
A goto after a devm call rings ordering alarm bells. The two calls will
be reverse of expected order (error handling generally reverse order of
setup).
Instead of doing this, register an extra callback with devm_add_action_or_reset()
for the power down. That will do for the fix, then if you have time
convert remaining two calls to devm as well in a follow up patch.
Jonathan
> }
> } else {
> indio_dev->info = data->chip_info->info_no_irq;
>
^ permalink raw reply
* Re: [PATCH v6 2/5] dt-bindings: iio: adc: microchip,mcp3564: Add spi-device-addr
From: Jonathan Cameron @ 2026-07-19 2:07 UTC (permalink / raw)
To: Janani Sunil
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Mark Brown, Marius Cristea, Marcus Folkesson, Kent Gustavsson,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson
In-Reply-To: <20260715-ad5529r-driver-v6-2-cfdf8b9f5ee3@analog.com>
On Wed, 15 Jul 2026 13:41:05 +0200
Janani Sunil <janani.sunil@analog.com> wrote:
> Add the generic spi-device-addr property to the binding and deprecate
> the existing vendor specific microchip,hw-device-address property.
>
> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
Maybe I'm reading the situation wrong but I was expecting to see
driver patches as well. Or is the now deprecated binding element
not actually used?
One other thing below.
Jonathan
> ---
> Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
> index 675319276197..02bb198e9fa7 100644
> --- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
> @@ -80,6 +80,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/uint32
> minimum: 0
> maximum: 3
> + deprecated: true
> description:
> The address is set on a per-device basis by fuses in the factory,
> configured on request. If not requested, the fuses are set for 0x1.
> @@ -91,6 +92,11 @@ properties:
> clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> which is first one on the wire).
>
> + spi-device-addr:
> + maxItems: 1
> + items:
> + enum: [0, 1, 2, 3]
No default here, yet not required, so how do we know what the value is
if this property isn't there?
> +
> "#io-channel-cells":
> const: 1
>
> @@ -123,7 +129,6 @@ dependencies:
> required:
> - compatible
> - reg
> - - microchip,hw-device-address
> - spi-max-frequency
>
> allOf:
> @@ -159,7 +164,7 @@ examples:
> spi-cpha;
> spi-cpol;
> spi-max-frequency = <10000000>;
> - microchip,hw-device-address = <1>;
> + spi-device-addr = <1>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
^ permalink raw reply
* Re: [PATCH v6 3/5] dt-bindings: iio: adc: microchip,mcp3911: Add spi-device-addr
From: Jonathan Cameron @ 2026-07-19 2:08 UTC (permalink / raw)
To: Janani Sunil
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Mark Brown, Marius Cristea, Marcus Folkesson, Kent Gustavsson,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson
In-Reply-To: <20260715-ad5529r-driver-v6-3-cfdf8b9f5ee3@analog.com>
On Wed, 15 Jul 2026 13:41:06 +0200
Janani Sunil <janani.sunil@analog.com> wrote:
> Add the generic spi-device-addr property to the binding and deprecate
> the existing vendor specific microchip,device-addr property
>
> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> ---
> Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
> index 3a69ec60edb9..4a60df06bd35 100644
> --- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
> @@ -57,6 +57,12 @@ properties:
> $ref: /schemas/types.yaml#/definitions/uint32
> enum: [0, 1, 2, 3]
> default: 0
> + deprecated: true
> +
> + spi-device-addr:
> + maxItems: 1
> + items:
> + enum: [0, 1, 2, 3]
Needs to carry the default as the old binding did.
>
> vref-supply:
> description: |
> @@ -86,7 +92,7 @@ examples:
> interrupts = <15 2>;
> reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> spi-max-frequency = <20000000>;
> - microchip,device-addr = <0>;
> + spi-device-addr = <0>;
> vref-supply = <&vref_reg>;
> clocks = <&xtal>;
> };
>
^ permalink raw reply
* Re: [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
From: Jonathan Cameron @ 2026-07-19 2:10 UTC (permalink / raw)
To: Janani Sunil
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Mark Brown, Marius Cristea, Marcus Folkesson, Kent Gustavsson,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson
In-Reply-To: <20260715-ad5529r-driver-v6-1-cfdf8b9f5ee3@analog.com>
On Wed, 15 Jul 2026 13:41:04 +0200
Janani Sunil <janani.sunil@analog.com> wrote:
> Some SPI devices support sharing a single chip select across multiple
> physical chips by encoding a device address in the SPI frame itself.
> Add the generic spi-device-addr property for describing these hardware
> addresses. The property is placed on the SPI peripheral node and may
> contain multiple addresses.
>
> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> ---
> Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> index 880a9f624566..135657582131 100644
> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> @@ -142,6 +142,11 @@ properties:
> minItems: 2
> maxItems: 4
>
> + spi-device-addr:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Device address used when multiple peripherals share a single chip select.
This needs to also explain why it is an array.
> +
> st,spi-midi-ns:
> deprecated: true
> description: |
>
^ permalink raw reply
* Re: [PATCH v6 5/5] iio: dac: Add AD5529R DAC driver support
From: Jonathan Cameron @ 2026-07-19 2:19 UTC (permalink / raw)
To: Janani Sunil
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Mark Brown, Marius Cristea, Marcus Folkesson, Kent Gustavsson,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
linux-spi, Kent Gustavsson
In-Reply-To: <20260715-ad5529r-driver-v6-5-cfdf8b9f5ee3@analog.com>
On Wed, 15 Jul 2026 13:41:08 +0200
Janani Sunil <janani.sunil@analog.com> wrote:
> Add support for AD5529R 16-channel, 12/16 bit Digital to Analog Converter
> from Analog Devices.
>
> The device communicates over SPI and supports per-channel output range
> configuration. An optional external 4.096V reference can be used in
> place of the internal reference.
>
> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
Hi Janini
Fairly quick review as it is end of day here now.
A few things inline.
Thanks,
Jonathan
> diff --git a/drivers/iio/dac/ad5529r.c b/drivers/iio/dac/ad5529r.c
> new file mode 100644
> index 000000000000..c279dc530d68
> --- /dev/null
> +++ b/drivers/iio/dac/ad5529r.c
> +static int ad5529r_reset(struct ad5529r_state *st)
> +{
> + struct reset_control *rst;
> + int ret;
> +
> + rst = devm_reset_control_get_optional_exclusive(&st->spi->dev, NULL);
> + if (IS_ERR(rst))
> + return PTR_ERR(rst);
> +
> + if (rst) {
> + ret = reset_control_assert(rst);
> + if (ret)
> + return ret;
> +
Nothing on the datasheet to say how long it needs to be asserted?
If it is very small maybe add a comment to say that here.
> + ret = reset_control_deassert(rst);
> + if (ret)
> + return ret;
> +
> +static int ad5529r_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct iio_dev *indio_dev;
> + struct ad5529r_state *st;
> + struct regmap_config regmap_8bit_cfg = ad5529r_regmap_8bit_config;
> + struct regmap_config regmap_16bit_cfg = ad5529r_regmap_16bit_config;
I would fill both of these in using a designated initializer and do
it once we know the remaining fields.
regmap_8bit_cfg = (struct regmap_config) {
.name = "ad5529r-8bit",
.reg_bits = 16,
.val_bits = 8,
.max_register = AD5529R_8BIT_REG_MAX,
.read_flag_mask = AD5529R_SPI_READ_FLAG,
.rd_table = &ad5529r_8bit_readable_table,
.wr_table = &ad5529r_8bit_writeable_table,
.reg_base = ...
};
That keeps everything in once place and removes the indirection of a template
that we then override parts of.
> + bool external_vref;
> + u32 dev_addr = 0;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + st = iio_priv(indio_dev);
> +
> + st->spi = spi;
> +
> + st->model_data = spi_get_device_match_data(spi);
> + if (!st->model_data)
> + return dev_err_probe(dev, -EINVAL,
> + "Failed to identify device variant\n");
> +
> + device_property_read_u32(dev, "spi-device-addr", &dev_addr);
> + if (dev_addr > 3)
> + return dev_err_probe(dev, -EINVAL,
> + "spi-device-addr %u out of range [0, 3]\n",
> + dev_addr);
> + regmap_8bit_cfg.reg_base = dev_addr << AD5529R_ADDR_SHIFT;
> + regmap_16bit_cfg.reg_base = dev_addr << AD5529R_ADDR_SHIFT;
> +
> + ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(ad5529r_supply_names),
> + ad5529r_supply_names);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to get and enable regulators\n");
> +
> + ret = devm_regulator_get_enable_optional(dev, "hvss");
> + if (ret && ret != -ENODEV)
> + return dev_err_probe(dev, ret,
> + "Failed to get and enable hvss regulator\n");
> +
> + ret = devm_regulator_get_enable_optional(dev, "vref");
> + if (ret == -ENODEV)
> + external_vref = false;
> + else if (!ret)
> + external_vref = true;
> + else
> + return dev_err_probe(dev, ret,
> + "Failed to get and enable vref regulator\n");
Slightly prefer these last two flipped so get the error of the way
a bit earlier.
> +
^ permalink raw reply
* [PATCH RFC] arm64: dts: allwinner: a523: Add SPDIF to x96qproplus device
From: Per Larsson @ 2026-07-19 3:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support, open list
Cc: Per Larsson
When spdif support was added for the Allwinner A523 family of SoCs, only
two of the three possible pins were added to the dtsi, since the third
would clash with the first ethernet port (emac0)
However, some devices don't use emac0 and instead use emac1 for the only
available ethernet port, leaving the pin free to use for spdif.
Add it to the dtsi, and to such a device where this pin is used for spdif
Signed-off-by: Per Larsson <per@palvencia.se>
---
Marking this as RFC for a few reasons
1. This is my first submission, hoping everything is properly organized.
2. My testing setup is not the best: I get sound with this patch, but
the pulseaudio daemon needs to be restarted far too often.
Hopefully it's just something on this minirootfs. Testing welcome.
3. Not sure where to get the hash for a fixes tag or if that's even OK
---
.../arm64/boot/dts/allwinner/sun55i-a523.dtsi | 7 ++++++
.../dts/allwinner/sun55i-h728-x96qpro+.dts | 24 +++++++++++++++++++
2 files changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
index ca6a16807049..7370e8ed24ec 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
@@ -216,6 +216,13 @@ spdif_out_pb_pin: spdif-pb-pin {
allwinner,pinmux = <2>;
};
+ /omit-if-no-ref/
+ spdif_out_ph_pin: spdif-ph-pin {
+ pins = "PH7";
+ function = "spdif";
+ allwinner,pinmux = <4>;
+ };
+
/omit-if-no-ref/
spdif_out_pi_pin: spdif-pi-pin {
pins = "PI10";
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
index a96927fbdadd..b172985583f8 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
+++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
@@ -44,6 +44,24 @@ reg_vcc3v3: vcc3v3 {
vin-supply = <®_vcc5v>;
regulator-always-on;
};
+
+ sound-spdif {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "spdif-out";
+
+ simple-audio-card,cpu {
+ sound-dai = <&spdif>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&spdif_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ #sound-dai-cells = <0>;
+ compatible = "linux,spdif-dit";
+ };
};
&ehci0 {
@@ -275,6 +293,12 @@ &r_pio {
vcc-pm-supply = <®_aldo3>;
};
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spdif_out_ph_pin>;
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.48.1
^ permalink raw reply related
* [PATCH v5 0/2] arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO
From: Jiaxing Hu @ 2026-07-19 3:46 UTC (permalink / raw)
To: heiko, robh, krzk+dt, conor+dt
Cc: devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Jiaxing Hu
Add mainline support for the ArmSoM CM5, an RK3576 compute module, and
its CM5-IO carrier board.
Patch 1 adds the binding, patch 2 the module dtsi and the carrier dts.
The on-module YT8531 PHY has no crystal and takes its 25 MHz reference
from the SoC. Following review of v4, the reference is now handled the
way Andrew Lunn and Maxime Chevallier asked for: the PHY is the consumer
and enables the clock itself. That needs a small motorcomm change sent
to netdev [1]; the clock is optional so this DTS still applies without
it. The earlier dwmac-rk MAC-side patch is dropped.
Tested on a CM5-IO with [1] applied: the YT8531 links at 1000 Mbit/s;
RK806, HYM8563, eMMC, microSD, the USB3 hub and PCIe all probe.
dtbs_check is clean.
Changes in v5:
- The 25 MHz reference is now consumed by the PHY, not the MAC. The PHY
node gets its clock back (clocks = <&cru REFCLKO25M_GMAC0_OUT>) and is
named explicitly (ethernet-phy-id4f51.e91b) so it is instantiated from
the DT without an MDIO ID probe, which it cannot answer before the
clock runs. &gmac0 drops clk_mac_refout and inherits the SoC clocks.
This reverses the v4 removal of the PHY-node clock, which was the wrong
direction.
- Enable &sai6, the I2S CPU DAI the HDMI sound card needs (already in v4;
re-tested here, HDMI audio card registers).
Changes in v4:
- phy-mode = "rgmii-id", drop the MAC tx_delay/rx_delay; the PHY adds
both delays (Andrew Lunn). Re-tested at 1000 Mbit/s.
- Pick up Krzysztof's Acked-by on patch 1.
Changes in v3:
- Remove the ES8388 codec from the header and the i2c0 comment; use gpios
in the vcc_3v3_pcie regulator.
Changes in v2:
- Fix the Type-C DP alt-mode node, move the FUSB302 role-switch endpoint
into the connector, drop the ES8388 node and dead pinctrls, rename the
wifi pinctrl node, and describe the PHY reset at the MDIO bus level.
[1] net: phy: motorcomm: enable the reference clock for YT8531
Jiaxing Hu (2):
dt-bindings: arm: rockchip: Add ArmSoM CM5 and CM5-IO
arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO
.../devicetree/bindings/arm/rockchip.yaml | 7 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3576-armsom-cm5-io.dts | 402 +++++++++++++
.../boot/dts/rockchip/rk3576-armsom-cm5.dtsi | 558 ++++++++++++++++++
4 files changed, 968 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
--
2.43.0
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: arm: rockchip: Add ArmSoM CM5 and CM5-IO
From: Jiaxing Hu @ 2026-07-19 3:46 UTC (permalink / raw)
To: heiko, robh, krzk+dt, conor+dt
Cc: devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Jiaxing Hu, Krzysztof Kozlowski
In-Reply-To: <20260719034611.3623066-1-gahing@gahingwoo.com>
Add compatibles for the ArmSoM CM5, an RK3576 compute module, and its
CM5-IO carrier board.
Signed-off-by: Jiaxing Hu <gahing@gahingwoo.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde186..5c7697f4d 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -71,6 +71,13 @@ properties:
- const: ariaboard,photonicat
- const: rockchip,rk3568
+ - description: ArmSoM CM5 Module based boards
+ items:
+ - enum:
+ - armsom,cm5-io
+ - const: armsom,cm5
+ - const: rockchip,rk3576
+
- description: ArmSoM Sige1 board
items:
- const: armsom,sige1
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/2] arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO
From: Jiaxing Hu @ 2026-07-19 3:46 UTC (permalink / raw)
To: heiko, robh, krzk+dt, conor+dt
Cc: devicetree, linux-rockchip, linux-arm-kernel, linux-kernel,
Jiaxing Hu
In-Reply-To: <20260719034611.3623066-1-gahing@gahingwoo.com>
Add the ArmSoM CM5, an RK3576 compute module (rk3576-armsom-cm5.dtsi),
and its CM5-IO carrier (rk3576-armsom-cm5-io.dts). The module has the
RK806 PMIC, HYM8563 RTC, eMMC, GMAC0 with an on-module MotorComm YT8531
PHY, and the SDIO bus for the on-module WiFi. The carrier adds HDMI, a
GbE RJ45, two USB-A ports behind a USB3 hub, USB-C with FUSB302 and DP
alt-mode, a PCIe 2.0 x1 M.2 slot, microSD, status LEDs and a 40-pin
header.
The YT8531 has no crystal and takes the SoC 25 MHz reference
(REFCLKO25M_GMAC0_OUT), described as a clock on the PHY node and enabled
by the PHY driver. The PHY is named explicitly so it is instantiated
from the device tree without an MDIO ID probe, which the PHY cannot
answer until that clock is running. Its reset is described at the MDIO
bus level so mdiobus releases it before the scan.
Signed-off-by: Jiaxing Hu <gahing@gahingwoo.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3576-armsom-cm5-io.dts | 402 +++++++++++++
.../boot/dts/rockchip/rk3576-armsom-cm5.dtsi | 558 ++++++++++++++++++
3 files changed, 961 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index cb55c6b70..3ec0b6e20 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-display-vz.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-100ask-dshanpi-a1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-cm5-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
new file mode 100644
index 000000000..40d9be0c6
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5-io.dts
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * ArmSoM CM5-IO - official carrier board for the ArmSoM CM5 (RK3576) module.
+ *
+ * Carrier provides:
+ * - Full-size HDMI 2.1 (HDMI TX via HDPTX PHY)
+ * - Gigabit Ethernet RJ45 (GMAC0 + on-module YT8531)
+ * - 2x USB-A behind a USB3 hub (combphy1 + u2phy1)
+ * - USB-C with PD/altmode (FUSB302 on i2c0, combphy0 + USBDP PHY)
+ * - M.2 PCIe 2.0 x1 slot (combphy0 as PCIe lane)
+ * - microSD card slot
+ * - Green/red status LEDs, 40-pin RPi-compatible header
+ * - 12 V DC barrel jack
+ *
+ * Copyright (c) 2024 ArmSoM
+ * Copyright (c) 2026 Jiaxing Hu <gahing@gahingwoo.com>
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include <dt-bindings/usb/pd.h>
+#include "rk3576-armsom-cm5.dtsi"
+
+/ {
+ model = "ArmSoM CM5-IO";
+ compatible = "armsom,cm5-io", "armsom,cm5", "rockchip,rk3576";
+
+ aliases {
+ ethernet0 = &gmac0;
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ };
+
+ chosen {
+ stdout-path = "serial0:1500000n8";
+ };
+
+ /* Full-size HDMI Type-A connector, driven by the SoC HDMI TX. */
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ /*
+ * Carrier status LEDs (schematic ARMSOM-CM5-IO-1V1_20240829):
+ * green - GPIO2 PD0 (net LED_GREEN_EN)
+ * red - GPIO2 PD1 (net LED_RED_EN)
+ */
+ leds: leds {
+ compatible = "gpio-leds";
+
+ led_green: led-green {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio2 RK_PD0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_green_en>;
+ default-state = "on";
+ };
+
+ led_red: led-red {
+ color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_FAULT;
+ gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_red_en>;
+ default-state = "off";
+ };
+ };
+
+ /* Carrier power tree: 12 V barrel jack -> 5 V -> peripheral rails. */
+ vcc_12v0_dcin: regulator-vcc-12v0-dcin {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_12v0_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ vcc_5v0_sys: regulator-vcc-5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_12v0_dcin>;
+ };
+
+ vcc_5v0_device: regulator-vcc-5v0-device {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v0_device";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_12v0_dcin>;
+ };
+
+ /* PCIe 3.3 V for the M.2 slot, gated by GPIO0 PC3. */
+ vcc_3v3_pcie: regulator-vcc-3v3-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_pwr_en>;
+ regulator-name = "vcc_3v3_pcie";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpios = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <5000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ /* USB-C / OTG 5 V, gated by GPIO2 PB6. */
+ vcc_5v0_typec0: regulator-vcc-5v0-typec0 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio2 RK_PB6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_otg0_pwren>;
+ regulator-name = "vcc_5v0_typec0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v0_device>;
+ };
+
+ /* USB-A host 5 V (through the hub), gated by GPIO4 PB0. */
+ vcc_5v0_usbhost: regulator-vcc-5v0-usbhost {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio4 RK_PB0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_host_pwren>;
+ regulator-name = "vcc_5v0_usbhost";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc_5v0_device>;
+ };
+};
+
+/*
+ * ComboPHY0 -> PCIe lane (M.2 slot); ComboPHY1 -> USB3 lane (USB-A hub).
+ */
+&combphy0_ps {
+ status = "okay";
+};
+
+&combphy1_psu {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_vp0: endpoint {
+ remote-endpoint = <&vp0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&hdptxphy {
+ status = "okay";
+};
+
+/* SAI6 is the I2S CPU DAI feeding the HDMI audio path. */
+&sai6 {
+ status = "okay";
+};
+
+/* I2C0: FUSB302 USB-C PD controller @ 0x22, pinctrl i2c0m1 (PC4/PC5). */
+&i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0m1_xfer>;
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PB4 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vcc_5v0_typec0>;
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ power-role = "dual";
+ try-power-role = "sink";
+ op-sink-microwatt = <1000000>;
+ sink-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_FIXED(9000, 3000, PDO_FIXED_USB_COMM)
+ PDO_FIXED(12000, 3000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+
+ altmodes {
+ displayport {
+ svid = /bits/ 16 <0xff01>;
+ vdo = <0xffffffff>;
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_orien_sw: endpoint {
+ remote-endpoint = <&usbdp_phy_orientation_switch>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_role_sw: endpoint {
+ remote-endpoint = <&usb_drd0_role_switch>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ dp_altmode_mux: endpoint {
+ remote-endpoint = <&usbdp_phy_dp_altmode_mux>;
+ };
+ };
+ };
+ };
+ };
+};
+
+/*
+ * PCIe 2.0 x1 M.2 slot. Reset GPIO2 PB1, power vcc_3v3_pcie (GPIO0 PC3).
+ */
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_reset>;
+ reset-gpios = <&gpio2 RK_PB1 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc_3v3_pcie>;
+ status = "okay";
+};
+
+/* microSD card slot. */
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ disable-wp;
+ max-frequency = <200000000>;
+ no-sdio;
+ no-mmc;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vccio_sd_s0>;
+ status = "okay";
+};
+
+&u2phy0 {
+ status = "okay";
+};
+
+&u2phy0_otg {
+ phy-supply = <&vcc_5v0_typec0>;
+ status = "okay";
+};
+
+&u2phy1 {
+ status = "okay";
+};
+
+&u2phy1_otg {
+ phy-supply = <&vcc_5v0_usbhost>;
+ status = "okay";
+};
+
+/* Debug UART0 on the 40-pin header. */
+&uart0 {
+ pinctrl-0 = <&uart0m0_xfer>;
+ status = "okay";
+};
+
+/* USB DRD0: USB-C (USBDP SuperSpeed + USB2 HS), OTG with FUSB302 role-switch. */
+&usb_drd0_dwc3 {
+ dr_mode = "otg";
+ usb-role-switch;
+ status = "okay";
+
+ port {
+ usb_drd0_role_switch: endpoint {
+ remote-endpoint = <&usbc0_role_sw>;
+ };
+ };
+};
+
+/* USB DRD1: USB-A ports behind the hub (combphy1 SuperSpeed + USB2 HS). */
+&usb_drd1_dwc3 {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbdp_phy {
+ status = "okay";
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PC4 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PC5 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy_orientation_switch: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_orien_sw>;
+ };
+
+ usbdp_phy_dp_altmode_mux: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dp_altmode_mux>;
+ };
+ };
+};
+
+&vop {
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
+
+&vp0 {
+ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+ reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+ remote-endpoint = <&hdmi_in_vp0>;
+ };
+};
+
+&pinctrl {
+ leds {
+ /* GPIO2 PD0 - green carrier LED */
+ led_green_en: led-green-en {
+ rockchip,pins = <2 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ /* GPIO2 PD1 - red carrier LED */
+ led_red_en: led-red-en {
+ rockchip,pins = <2 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ /* GPIO0 PC3 - PCIe power enable */
+ pcie_pwr_en: pcie-pwr-en {
+ rockchip,pins = <0 RK_PC3 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ /* GPIO2 PB1 - PCIe PERST# */
+ pcie_reset: pcie-reset {
+ rockchip,pins = <2 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ usb {
+ /* GPIO4 PB0 - USB host 5V enable */
+ usb_host_pwren: usb-host-pwren {
+ rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ /* GPIO2 PB6 - USB OTG / Type-C 5V enable */
+ usb_otg0_pwren: usb-otg0-pwren {
+ rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ /* GPIO0 PB4 - FUSB302 INT# (active-low) */
+ usbc0_int: usbc0-int {
+ rockchip,pins = <0 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
new file mode 100644
index 000000000..b6977b973
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
@@ -0,0 +1,558 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * ArmSoM CM5 - Rockchip RK3576 compute module (Raspberry Pi CM4 form factor).
+ *
+ * Common to all CM5 carriers. The carrier .dts includes this file, sets the
+ * board model/compatible, and adds carrier-specific peripherals.
+ *
+ * On-module devices:
+ * - RK806 PMIC on I2C1
+ * - HYM8563 RTC on I2C2
+ * - eMMC (SDHCI)
+ * - GMAC0 + MotorComm YT8531 Gigabit Ethernet PHY (RGMII)
+ * - SYN43752 WiFi 6 + BT 5.x (SDIO + UART4)
+ *
+ * Copyright (c) 2024 ArmSoM
+ * Copyright (c) 2026 Jiaxing Hu <gahing@gahingwoo.com>
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include "rk3576.dtsi"
+
+/ {
+ compatible = "armsom,cm5", "rockchip,rk3576";
+
+ vcc_1v1_nldo_s3: regulator-vcc-1v1-nldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ vcc_1v2_ufs_vccq_s0: regulator-vcc-1v2-ufs-vccq-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v2_ufs_vccq_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ vcc_1v8_s0: regulator-vcc-1v8-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v8_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_1v8_s3>;
+ };
+
+ vcc_1v8_ufs_vccq2_s0: regulator-vcc-1v8-ufs-vccq2-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v8_ufs_vccq2_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_1v8_s3>;
+ };
+
+ vcc_2v0_pldo_s3: regulator-vcc-2v0-pldo-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_2v0_pldo_s3";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <2000000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ vcc_3v3_s0: regulator-vcc-3v3-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3_ufs_s0";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_5v0_sys>;
+ };
+
+ /*
+ * WiFi power sequencer for SYN43752. Reset GPIO1 PC6 active-low,
+ * clock from the HYM8563 RTC oscillator.
+ */
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&hym8563>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_reg_on>;
+ reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b2 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b3 {
+ cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+/*
+ * GMAC0 drives an on-module MotorComm YT8531. The PHY has no local crystal and
+ * takes the SoC 25 MHz reference (REFCLKO25M_GMAC0_OUT); ethm0_clk0_25m_out
+ * routes that clock to the pad, and the PHY node consumes and enables it.
+ */
+&gmac0 {
+ phy-mode = "rgmii-id";
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy0>;
+ phy-supply = <&vcc_3v3_s3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ð0m0_miim
+ ð0m0_tx_bus2
+ ð0m0_rx_bus2
+ ð0m0_rgmii_clk
+ ð0m0_rgmii_bus
+ ðm0_clk0_25m_out>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ status = "okay";
+};
+
+/* I2C1: RK806 PMIC @ 0x23 (interrupt on GPIO0 PA6). */
+&i2c1 {
+ status = "okay";
+
+ pmic@23 {
+ compatible = "rockchip,rk806";
+ reg = <0x23>;
+
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA6 IRQ_TYPE_LEVEL_LOW>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
+ <&rk806_dvs2_null>, <&rk806_dvs3_null>;
+
+ system-power-controller;
+
+ vcc1-supply = <&vcc_5v0_sys>;
+ vcc2-supply = <&vcc_5v0_sys>;
+ vcc3-supply = <&vcc_5v0_sys>;
+ vcc4-supply = <&vcc_5v0_sys>;
+ vcc5-supply = <&vcc_5v0_sys>;
+ vcc6-supply = <&vcc_5v0_sys>;
+ vcc7-supply = <&vcc_5v0_sys>;
+ vcc8-supply = <&vcc_5v0_sys>;
+ vcc9-supply = <&vcc_5v0_sys>;
+ vcc10-supply = <&vcc_5v0_sys>;
+ vcc11-supply = <&vcc_2v0_pldo_s3>;
+ vcc12-supply = <&vcc_5v0_sys>;
+ vcc13-supply = <&vcc_1v1_nldo_s3>;
+ vcc14-supply = <&vcc_1v1_nldo_s3>;
+ vcca-supply = <&vcc_5v0_sys>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ rk806_dvs1_null: dvs1-null-pins {
+ pins = "gpio_pwrctrl1";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs2_null: dvs2-null-pins {
+ pins = "gpio_pwrctrl2";
+ function = "pin_fun0";
+ };
+
+ rk806_dvs3_null: dvs3-null-pins {
+ pins = "gpio_pwrctrl3";
+ function = "pin_fun0";
+ };
+
+ regulators {
+ vdd_cpu_big_s0: dcdc-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_big_s0";
+ regulator-enable-ramp-delay = <400>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_npu_s0: dcdc-reg2 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_npu_s0";
+ regulator-enable-ramp-delay = <400>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_lit_s0: dcdc-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <950000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_cpu_lit_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vcc_3v3_s3: dcdc-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_3v3_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd_gpu_s0: dcdc-reg5 {
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <900000>;
+ regulator-ramp-delay = <12500>;
+ regulator-name = "vdd_gpu_s0";
+ regulator-enable-ramp-delay = <400>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <850000>;
+ };
+ };
+
+ vddq_ddr_s0: dcdc-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vddq_ddr_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_logic_s0: dcdc-reg7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <800000>;
+ regulator-name = "vdd_logic_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8_s3: dcdc-reg8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd2_ddr_s3: dcdc-reg9 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vdd2_ddr_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_ddr_s0: dcdc-reg10 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <550000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdd_ddr_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8_s0: pldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca_1v8_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pldo2_s0: pldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_pldo2_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_1v2_s0: pldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vdda_1v2_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_3v3_s0: pldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcca_3v3_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd_s0: pldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pldo6_s3: pldo-reg6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_pldo6_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vdd_0v75_s3: nldo-reg1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdd_0v75_s3";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <750000>;
+ };
+ };
+
+ vdda_ddr_pll_s0: nldo-reg2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdda_ddr_pll_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v75_hdmi_s0: nldo-reg3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <837500>;
+ regulator-max-microvolt = <837500>;
+ regulator-name = "vdda0v75_hdmi_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v85_s0: nldo-reg4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <850000>;
+ regulator-name = "vdda_0v85_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v75_s0: nldo-reg5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <750000>;
+ regulator-name = "vdda_0v75_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+/* I2C2: HYM8563 RTC @ 0x51 (interrupt on GPIO0 PA0). */
+&i2c2 {
+ status = "okay";
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ clock-output-names = "hym8563";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA0 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hym8563_int>;
+ wakeup-source;
+ #clock-cells = <0>;
+ };
+};
+
+/*
+ * The PHY reset has to be described at the MDIO bus level: mdiobus releases a
+ * bus level reset before it scans for PHY IDs, whereas the per-PHY reset-gpios
+ * is only applied by phylib once the PHY has already been found, which never
+ * happens while the YT8531 is still held in reset.
+ *
+ * The compatible names the YT8531 explicitly so phylib instantiates the PHY
+ * from the device tree without an MDIO ID probe; the crystal-less PHY does not
+ * answer on MDIO until its driver has enabled the reference clock below.
+ */
+&mdio0 {
+ reset-gpios = <&gpio2 RK_PB3 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <20000>;
+ reset-post-delay-us = <100000>;
+
+ rgmii_phy0: phy@1 {
+ compatible = "ethernet-phy-id4f51.e91b",
+ "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ clocks = <&cru REFCLKO25M_GMAC0_OUT>;
+ };
+};
+
+&saradc {
+ vref-supply = <&vcca_1v8_s0>;
+ status = "okay";
+};
+
+/* eMMC: on-module, HS400 200 MHz with enhanced strobe. */
+&sdhci {
+ bus-width = <8>;
+ full-pwr-cycle-in-suspend;
+ max-frequency = <200000000>;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ no-sdio;
+ no-sd;
+ non-removable;
+ /delete-property/ supports-cqe;
+ status = "okay";
+};
+
+/* SDIO: SYN43752 WiFi, power-sequenced by sdio_pwrseq, clock from HYM8563. */
+&sdio {
+ bus-width = <4>;
+ cap-sdio-irq;
+ disable-wp;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ no-sd;
+ no-mmc;
+ non-removable;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vcc_1v8_s3>;
+ wakeup-source;
+ status = "okay";
+};
+
+/* UART4: Bluetooth (SYN43752). */
+&uart4 {
+ pinctrl-0 = <&uart4m1_xfer &uart4m1_ctsn &uart4m1_rtsn>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&pinctrl {
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ wireless-wlan {
+ /* GPIO1 PC6 - WiFi power enable / reset (sdio_pwrseq) */
+ wifi_reg_on: wifi-reg-on {
+ rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 2/2] arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO
From: sashiko-bot @ 2026-07-19 4:04 UTC (permalink / raw)
To: Jiaxing Hu; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260719034611.3623066-3-gahing@gahingwoo.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Uninitialized hardware state (missing clock enablement & reset sequence violation) due to motorcomm PHY driver not handling clocks.
--
--- Patch [2]: [PATCH v5 2/2] arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO ---
commit c0855ea5f59329ce1c87ee05212dc9c8bf0d2728
Author: Jiaxing Hu <gahing@gahingwoo.com>
arm64: dts: rockchip: Add ArmSoM CM5 and CM5-IO
This patch adds device tree support for the Rockchip RK3576 based
ArmSoM CM5 compute module and its CM5-IO carrier board. It configures
the GMAC0 Ethernet with an on-module MotorComm YT8531 PHY.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
> new file mode 100644
> index 0000000000000..b6977b973b340
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-cm5.dtsi
[ ... ]
> +&mdio0 {
> + reset-gpios = <&gpio2 RK_PB3 GPIO_ACTIVE_LOW>;
> + reset-delay-us = <20000>;
> + reset-post-delay-us = <100000>;
> +
> + rgmii_phy0: phy@1 {
> + compatible = "ethernet-phy-id4f51.e91b",
> + "ethernet-phy-ieee802.3-c22";
> + reg = <0x1>;
> + clocks = <&cru REFCLKO25M_GMAC0_OUT>;
> + };
> +};
[Severity: High]
The commit message states that the REFCLKO25M_GMAC0_OUT clock is enabled by
the PHY driver. Does the motorcomm PHY driver actually handle clocks?
Looking at drivers/net/phy/motorcomm.c, there don't appear to be any calls to
clk_get() or devm_clk_get() to fetch and enable the clocks specified in the
device tree.
Additionally, dwmac-rk.c only fetches a PHY clock if the phy-is-integrated
property is present, which is missing here.
Because the MDIO bus deasserts the reset-gpios before the PHY device is
probed, will the PHY be brought out of reset with a dead clock?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719034611.3623066-1-gahing@gahingwoo.com?part=2
^ permalink raw reply
* [PATCH 0/3] powerpc: 512x: Convert ADS7845 touchscreen on PDM360NG to device tree
From: Dmitry Torokhov @ 2026-07-19 5:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Anatolij Gustschin
Cc: devicetree, linuxppc-dev, linux-kernel
The reason for this series is to remove support for platform data in the
ads7846 touchscreen driver, as pdm360ng is the last user of legacy
platform data in the kernel for this driver.
This series converts the ADS7845 touchscreen on the PDM360NG board to
use Device Tree bindings instead of legacy platform data callbacks:
- Move GPIO controller capabilities into mpc5121.dtsi so all MPC5121
boards inherit proper controller definitions, and remove redundant
local declarations from ac14xx.dts
- Update pdm360ng.dts to use "ti,ads7845" with pendown-gpio and
interrupt-parent referencing gpio_pic
- Add "ifm,pdm360ng" to mpc512x_generic.c and delete obsolete
pdm360ng.c.
This change has been discussed in '24i but I just got around to
implementing this:
https://lore.kernel.org/r/ZoNHLjmSvCN12vU5@google.com/
Note that this should compile but I have not tried this on real
hardware.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Dmitry Torokhov (3):
powerpc/dts: mpc5121: Move GPIO controller properties to SoC dtsi
powerpc/dts: pdm360ng: Convert ADS7845 touchscreen to DT bindings
powerpc/512x: Remove pdm360ng platform setup in favor of mpc512x_generic
arch/powerpc/boot/dts/ac14xx.dts | 13 ---
arch/powerpc/boot/dts/mpc5121.dtsi | 6 +-
arch/powerpc/boot/dts/pdm360ng.dts | 7 +-
arch/powerpc/platforms/512x/Kconfig | 3 +-
arch/powerpc/platforms/512x/Makefile | 1 -
arch/powerpc/platforms/512x/mpc512x_generic.c | 1 +
arch/powerpc/platforms/512x/pdm360ng.c | 126 --------------------------
7 files changed, 12 insertions(+), 145 deletions(-)
---
base-commit: 8e9685d3c41c35dd1b37df70d854137abcb2fbac
change-id: 20260717-ads7846-pdm360ng-ec7ed9f72f82
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 1/3] powerpc/dts: mpc5121: Move GPIO controller properties to SoC dtsi
From: Dmitry Torokhov @ 2026-07-19 5:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Anatolij Gustschin
Cc: devicetree, linuxppc-dev, linux-kernel
In-Reply-To: <20260718-ads7846-pdm360ng-v1-0-f318f85cda57@gmail.com>
Define gpio@1100 with label gpio_pic as a GPIO controller and
interrupt controller directly in mpc5121.dtsi so all MPC5121 boards
inherit the correct controller capabilities.
Remove the redundant local controller property declaration block from
ac14xx.dts.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
arch/powerpc/boot/dts/ac14xx.dts | 13 -------------
arch/powerpc/boot/dts/mpc5121.dtsi | 6 +++++-
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/boot/dts/ac14xx.dts b/arch/powerpc/boot/dts/ac14xx.dts
index 5d8877e1f4ad..05fcf08df1ca 100644
--- a/arch/powerpc/boot/dts/ac14xx.dts
+++ b/arch/powerpc/boot/dts/ac14xx.dts
@@ -148,19 +148,6 @@ clock@f00 {
compatible = "fsl,mpc5121rev2-clock", "fsl,mpc5121-clock";
};
- /*
- * GPIO PIC:
- * interrupts cell = <pin nr, sense>
- * sense == 8: Level, low assertion
- * sense == 2: Edge, high-to-low change
- */
- gpio_pic: gpio@1100 {
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
sdhc@1500 {
cd-gpios = <&gpio_pic 23 0>; /* card detect */
wp-gpios = <&gpio_pic 24 0>; /* write protect */
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index a278fb7b9e71..9c5dacb94b92 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -146,10 +146,14 @@ pmc@1000 {
interrupts = <83 0x8>;
};
- gpio@1100 {
+ gpio_pic: gpio@1100 {
compatible = "fsl,mpc5121-gpio";
reg = <0x1100 0x100>;
interrupts = <78 0x8>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
};
can@1300 {
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply related
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