* 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 v3 4/4] arm64: dts: rockchip: enable HDMI RX audio capture on Orange Pi 5 Plus
From: Sebastian Reichel @ 2026-07-18 23:31 UTC (permalink / raw)
To: Igor Paunovic
Cc: Dmitry Osipenko, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <20260718085728.6797-5-royalnet026@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]
Hi,
On Sat, Jul 18, 2026 at 10:57:28AM +0200, Igor Paunovic wrote:
> Route the HDMI receiver audio to i2s7_8ch, the receive-only I2S
> interface dedicated to HDMI RX, through a simple-audio-card with the
> receiver as bitclock and frame master. Together with the audio
> capture support in the snps_hdmirx driver this exposes a capture-only
> ALSA card fed by the HDMI input.
>
> Tested on the Orange Pi 5 Plus with multiple HDMI sources: capture
> follows the source sample rate and stays in sync via the FIFO-level
> clock tracking in the driver.
>
> Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
> ---
> New in v3.
>
> .../dts/rockchip/rk3588-orangepi-5-plus.dts | 20 +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> index 9950d11..d5840e1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> @@ -37,6 +37,22 @@
> };
> };
>
> + hdmiin-sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "rockchip,hdmiin";
The name is exposed to userspace and visible to the user (e.g.
in alsamixer), but also used by Alsa UCM2. I suggest to use
"RK3588 HDMI-IN".
> + simple-audio-card,format = "i2s";
> + simple-audio-card,bitclock-master = <&hdmiin_codec>;
> + simple-audio-card,frame-master = <&hdmiin_codec>;
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s7_8ch>;
> + };
> +
> + hdmiin_codec: simple-audio-card,codec {
> + sound-dai = <&hdmi_receiver 0>;
> + };
> + };
> +
Move the whole card definition to rk3588-extra.dtsi with a new label
(e.g. hdmi_receiver_sound) and add status = "disabled"; Then just do
&hdmi_receiver_sound {
status = "okay";
};
in the Orange Pi 5+ DT, i.e. just like the soundcards for HDMI
output. This reduces a lot of duplication as the soundcard is the
same on all boards considering there is a dedicated I2S channel for
it. It's disabled by default as some boards do not route the HDMI
receiver at all.
Greetings,
-- Sebastian
> ir-receiver {
> compatible = "gpio-ir-receiver";
> gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
> @@ -247,6 +263,10 @@
> status = "okay";
> };
>
> +&i2s7_8ch {
> + status = "okay";
> +};
> +
> &led_blue_gpio {
> gpios = <&gpio3 RK_PA6 GPIO_ACTIVE_HIGH>;
> status = "okay";
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v16 02/10] dt-bindings: iio: imu: icm42600: Remove interrupts from required
From: Jonathan Cameron @ 2026-07-18 23:19 UTC (permalink / raw)
To: Chris Morgan
Cc: Krzysztof Kozlowski, Chris Morgan, linux-iio, andy, nuno.sa,
dlechner, jean-baptiste.maneyrol, linux-rockchip, devicetree,
heiko, conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <PH0PR19MB99733836951FBC9755A5361641A5F82@PH0PR19MB997338.namprd19.prod.outlook.com>
On Wed, 15 Jul 2026 15:34:53 -0500
Chris Morgan <macromorgan@hotmail.com> wrote:
> On Wed, Jul 15, 2026 at 08:29:44PM +0200, Krzysztof Kozlowski wrote:
> > On 15/07/2026 16:52, Chris Morgan wrote:
> > > On Wed, Jul 15, 2026 at 07:52:52AM +0200, Krzysztof Kozlowski wrote:
> > >> On Mon, Jul 13, 2026 at 04:58:32PM -0500, Chris Morgan wrote:
> > >>> From: Chris Morgan <macromorgan@hotmail.com>
> > >>>
> > >>> Interrupts are almost never required for IIO devices per upstream
> > >>> maintainers. Remove interrupt as a required parameter for the
> > >>> devicetree binding.
> > >>
> > >> That's an odd statement. We do require interrupts when the hardware
> > >> requires them. We do not require interrupts, not because we have such
> > >> policy, but because hardware does not require them.
> > >>
> > >> Plus, we do require interrupts when software implementing ABI requires
> > >> them.
> > >>
> > >> Above commit msg is simply inaccurate and misleading. Instead, please
> > >> use actual hardware arguments or how ABI is actually used. You must not
> > >> introduce changes to ABI just "because" while for example making that
> > >> ABI conflicting with existing implementation.
> > >
> > > I will defer then to Jonathan on the specifics of this, but from what I
> > > can tell:
> > >
> > > 1) The icm42600 devices don't need an interrupt for operation other
> > > than for buffered mode or wake on movement. One-shot should work
> > > without it.
> > >
> > > 2) The existing icm42600 driver does require an interrupt however, and
> > > refuses to bind without it. The driver could in theory be modified to
> > > not require an interrupt though and skip using buffered mode and WoM
> > > when no interrupt is present; however I don't plan on making these
> > > changes at this time.
> > >
> > > 3) The new icm42607 driver I'm trying to upstream does not use an
> > > interrupt, because on my current test device it's not even wired up.
> > > On future devices that I have with this chip I may pursue using an
> > > interrupt, but it will never be required.
> > >
> > > So should I go back to requiring the interrupt for all devices except
> > > for the new driver then?
> >
> > You mentioned two drivers, I don't know how does this relate to them. In
> > any case your commit msg is inaccurate and not a correct reason to make
> > a change.
> >
> > Best regards,
> > Krzysztof
>
> I'm confused, so again should I just go back to the way things were?
>
> This binding is to describe the hardware for devices using two distinct
> drivers, the inv_icm42600 and the new (that I am trying to finish)
> inv_icm42607 driver. The hardware requires an interrupt if you want to
> use features such as wake-on-motion or hardware buffers. The existing
> driver inv_icm42600 always assumes an interrupt is present and thus
> fails to probe if one is not (making it a "requirement"). The new
> driver I'm writing does not use the interrupt, because I don't have
> one.
For dt-bindings, look at it from the question of 'is the hardware useful
without this interrupt?' Answer is yes for vast majority of sensors as we
can either reduce features but still have some useful ones, or use another
approach such as polling a ready flag to replace doing it with an interrupt.
It is very common for boards to come out where none of the interrupts are
wired.
The only time I've seen that they are actually required for IIO stuff is
for very simple devices where the interrupt is the data - e.g. stand alone
threshold detectors with no ADC like functionality.
All this is independent of the driver working without the interrupt.
It is fully allowed to refuse to probe because it relies on something
optional in the DT-binding.
Jonathan
>
> I'm thinking I'll just go back to the way it was previously, unless
> Jonathan disagrees. The interrupt will be listed as required for all
> devices using the inv_icm42600 driver, and not required for devices
> using the inv_icm42607 driver.
>
> Thank you.
>
^ permalink raw reply
* Re: [PATCH V17 0/9] Add Invensense ICM42607
From: Jonathan Cameron @ 2026-07-18 23:13 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260716182637.24310-1-macroalpha82@gmail.com>
On Thu, 16 Jul 2026 13:26:27 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for the ICM42607 IMU. This sensor shares the same
> functionality but a different register layout with the existing
> ICM42600.
>
> This driver should work with the ICM42607 and ICM42607P over both I2C
> and SPI, however only the ICM42607P over I2C could be tested.
Looking pretty good to me. Just that sashiko review and that one
minor think I noted + drop the header Uwe requested.
Thanks for persevering! Jonathan
^ permalink raw reply
* Re: [PATCH V17 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Jonathan Cameron @ 2026-07-18 23:05 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260716182637.24310-4-macroalpha82@gmail.com>
On Thu, 16 Jul 2026 13:26:30 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add the core component of a new inv_icm42607 driver. This includes
> a few setup functions and the full register definition in the
> header file, as well as the bits necessary to compile and probe the
> device when used on an i2c bus.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Hi Chris,
Just one small thing below given you are probably going to do
a v18. If it had just been this I might have tweaked it whilst
applying
Thanks,
Jonathan
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> new file mode 100644
> index 000000000000..8f74bf38aad1
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
...
> +static int inv_icm42607_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + const struct inv_icm42607_hw *hw;
> + struct regmap *regmap;
> +
> + hw = i2c_get_match_data(client);
> + if (!hw)
> + return dev_err_probe(dev, -ENODEV, "Failed to get i2c data\n");
> +
> + regmap = devm_regmap_init_i2c(client, &inv_icm42607_regmap_config);
> + if (IS_ERR(regmap))
> + return dev_err_probe(dev, PTR_ERR(regmap),
> + "Failed to register i2c regmap\n");
> +
> + return inv_icm42607_core_probe(regmap, hw, inv_icm42607_i2c_bus_setup);
> +}
> +
> +static const struct i2c_device_id inv_icm42607_id[] = {
> + {
> + .name = "icm42607",
> + .driver_data = (kernel_ulong_t)&inv_icm42607_hw_data,
> + }, {
> + .name = "icm42607p",
> + .driver_data = (kernel_ulong_t)&inv_icm42607p_hw_data,
> + },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, inv_icm42607_id);
> +
> +static const struct of_device_id inv_icm42607_of_matches[] = {
> + {
> + .compatible = "invensense,icm42607",
I'd expect to see the data here as well. Look at implementation of i2c_get_match_data()
and consider what would happen if there was a slightly mismatch between which devices
were listed in each table. To avoid that fragility we normally just put
the data pointers in both places.
> + }, {
> + .compatible = "invensense,icm42607p",
> + },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, inv_icm42607_of_matches);
^ permalink raw reply
* Re: [PATCH V17 8/9] iio: imu: inv_icm42607: Add Temp Support in icm42607
From: Jonathan Cameron @ 2026-07-18 22:59 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260716182637.24310-9-macroalpha82@gmail.com>
On Thu, 16 Jul 2026 13:26:35 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add functions for reading temperature sensor data.
Hi Chris
Before I take a look myself. Sashiko did have a comment on this
one that looks valid to me
https://sashiko.dev/#/patchset/20260716182637.24310-1-macroalpha82%40gmail.com
See comments on the the IIO_TEMP vs IIO_CHAN_INFO_RAW below.
The suspend one is interesting but definitely not something I'd insist
on fixing. Might need some thought if you actually want suspend to work
in all cases.
Jonathan
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
> drivers/iio/imu/inv_icm42607/Makefile | 1 +
> .../iio/imu/inv_icm42607/inv_icm42607_accel.c | 6 ++
> .../iio/imu/inv_icm42607/inv_icm42607_gyro.c | 6 ++
> .../iio/imu/inv_icm42607/inv_icm42607_temp.c | 98 +++++++++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_temp.h | 38 +++++++
> 5 files changed, 149 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
>
> diff --git a/drivers/iio/imu/inv_icm42607/Makefile b/drivers/iio/imu/inv_icm42607/Makefile
> index 8e73385c8f4b..7b907e019601 100644
> --- a/drivers/iio/imu/inv_icm42607/Makefile
> +++ b/drivers/iio/imu/inv_icm42607/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_INV_ICM42607) += inv-icm42607.o
> inv-icm42607-y += inv_icm42607_core.o
> inv-icm42607-y += inv_icm42607_gyro.o
> inv-icm42607-y += inv_icm42607_accel.o
> +inv-icm42607-y += inv_icm42607_temp.o
>
> obj-$(CONFIG_INV_ICM42607_I2C) += inv-icm42607-i2c.o
> inv-icm42607-i2c-y += inv_icm42607_i2c.o
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> index 7bb67f232d19..9a44a180e5cc 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> @@ -15,6 +15,7 @@
> #include <linux/types.h>
>
> #include "inv_icm42607.h"
> +#include "inv_icm42607_temp.h"
>
> #define INV_ICM42607_ACCEL_CHAN(_modifier, _index, _ext_info) \
> { \
> @@ -40,6 +41,7 @@ enum inv_icm42607_accel_scan {
> INV_ICM42607_ACCEL_SCAN_X,
> INV_ICM42607_ACCEL_SCAN_Y,
> INV_ICM42607_ACCEL_SCAN_Z,
> + INV_ICM42607_ACCEL_SCAN_TEMP,
> };
>
> static const struct iio_chan_spec_ext_info inv_icm42607_accel_ext_infos[] = {
> @@ -54,6 +56,7 @@ static const struct iio_chan_spec inv_icm42607_accel_channels[] = {
> inv_icm42607_accel_ext_infos),
> INV_ICM42607_ACCEL_CHAN(IIO_MOD_Z, INV_ICM42607_ACCEL_SCAN_Z,
> inv_icm42607_accel_ext_infos),
> + INV_ICM42607_TEMP_CHAN(INV_ICM42607_ACCEL_SCAN_TEMP),
> };
>
> static const int inv_icm42607_accel_scale_nano[][2] = {
> @@ -186,6 +189,9 @@ static int inv_icm42607_accel_read_raw(struct iio_dev *indio_dev,
>
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> + if (chan->type == IIO_TEMP)
> + return inv_icm42607_temp_read_raw(indio_dev, chan,
So this only gets called if mask is IIO_CHAN_INFO_RAW but look at what is implemented...
Sashiko suggeted this should be outside the switch and that looks correct
to me as well.
> + val, val2, mask);
> ret = inv_icm42607_read_sensor(indio_dev, chan, &data);
> if (ret)
> return ret;
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> index 923d47d096bd..fa6e65c7ab6b 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> @@ -15,6 +15,7 @@
> #include <linux/types.h>
>
> #include "inv_icm42607.h"
> +#include "inv_icm42607_temp.h"
>
> #define INV_ICM42607_GYRO_CHAN(_modifier, _index, _ext_info) \
> { \
> @@ -40,6 +41,7 @@ enum inv_icm42607_gyro_scan {
> INV_ICM42607_GYRO_SCAN_X,
> INV_ICM42607_GYRO_SCAN_Y,
> INV_ICM42607_GYRO_SCAN_Z,
> + INV_ICM42607_GYRO_SCAN_TEMP,
> };
>
> static const struct iio_chan_spec_ext_info inv_icm42607_gyro_ext_infos[] = {
> @@ -54,6 +56,7 @@ static const struct iio_chan_spec inv_icm42607_gyro_channels[] = {
> inv_icm42607_gyro_ext_infos),
> INV_ICM42607_GYRO_CHAN(IIO_MOD_Z, INV_ICM42607_GYRO_SCAN_Z,
> inv_icm42607_gyro_ext_infos),
> + INV_ICM42607_TEMP_CHAN(INV_ICM42607_GYRO_SCAN_TEMP),
> };
>
> static const int inv_icm42607_gyro_scale_nano[][2] = {
> @@ -183,6 +186,9 @@ static int inv_icm42607_gyro_read_raw(struct iio_dev *indio_dev,
>
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> + if (chan->type == IIO_TEMP)
> + return inv_icm42607_temp_read_raw(indio_dev, chan,
> + val, val2, mask);
> ret = inv_icm42607_read_sensor(indio_dev, chan, &data);
> if (ret)
> return ret;
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> new file mode 100644
> index 000000000000..8681ef2b49e2
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/cleanup.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/iio/iio.h>
> +#include <linux/mutex.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
> +
> +#include "inv_icm42607.h"
> +#include "inv_icm42607_temp.h"
> +
> +static int inv_icm42607_temp_read(struct inv_icm42607_state *st, s16 *temp)
> +{
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + struct device *dev = regmap_get_device(st->map);
> + int ret, gyro_mode, accel_mode;
> + unsigned int val;
> + u8 raw[2];
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> + return ret;
> +
> + guard(mutex)(&st->lock);
> +
> + /*
> + * Check if both the gyro and accel are off and if so, enable one
> + * of them. The temp sensor cannot be read if both the gyro and
> + * accel sensor are off. Prefer to enable the accel over the gyro
> + * as the datasheet says the gyro uses 5x more power and it has
> + * a minimum run time of 45ms.
> + */
> + ret = regmap_read(st->map, INV_ICM42607_REG_PWR_MGMT0, &val);
> + if (ret)
> + return ret;
> +
> + accel_mode = FIELD_GET(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, val);
> + gyro_mode = FIELD_GET(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, val);
> + if (!gyro_mode && !accel_mode) {
> + /* enable accel sensor */
> + conf.mode = INV_ICM42607_SENSOR_MODE_LOW_NOISE;
> + ret = inv_icm42607_set_sensor_conf(st, &conf, IIO_ACCEL);
> + if (ret)
> + return ret;
> + }
> +
> + ret = regmap_bulk_read(st->map, INV_ICM42607_REG_TEMP_DATA1,
> + raw, sizeof(raw));
> + if (ret)
> + return ret;
> +
> + *temp = get_unaligned_be16(raw);
> + if (*temp == INV_ICM42607_DATA_INVALID)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + s16 temp;
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
Only this case is ever called. (Sashiko pointed this out).
> + ret = inv_icm42607_temp_read(st, &temp);
> + if (ret)
> + return ret;
> + *val = temp;
> + return IIO_VAL_INT;
> + /*
> + * T°C = (temp / 128) + 25
> + * Tm°C = 1000 * ((temp * 100 / 12800) + 25)
> + * scale: 100000 / 12800 ~= 7.8125
> + * offset: 3200
> + */
> + case IIO_CHAN_INFO_SCALE:
> + *val = 7;
> + *val2 = 812500000;
> + return IIO_VAL_INT_PLUS_NANO;
> + case IIO_CHAN_INFO_OFFSET:
> + *val = 3200;
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
> new file mode 100644
> index 000000000000..18499b4d0b94
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
> @@ -0,0 +1,38 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#ifndef INV_ICM42607_TEMP_H_
> +#define INV_ICM42607_TEMP_H_
> +
> +#include <linux/bitops.h>
> +
> +struct iio_dev;
> +struct iio_chan_spec;
> +
> +#define INV_ICM42607_TEMP_CHAN(_index) \
> +{ \
> + .type = IIO_TEMP, \
> + .info_mask_separate = \
> + BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_OFFSET) | \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_shared_by_all = \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .info_mask_shared_by_all_available = \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .scan_index = _index, \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = 16, \
> + .storagebits = 16, \
> + .endianness = IIO_BE, \
> + }, \
> +}
> +
> +int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask);
> +
> +#endif
^ permalink raw reply
* Re: [RFC PATCH 3/3] iio: proximity: srf04: Add Cytron HC-SR04 support
From: Jonathan Cameron @ 2026-07-18 22:47 UTC (permalink / raw)
To: Paweł Wiśniewski
Cc: dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, ak, linux-iio,
devicetree, linux-kernel
In-Reply-To: <3fedc827a2581d61bef9ea639ed77cf90e80047a.1784221074.git.pawel.wis.me@gmail.com>
On Thu, 16 Jul 2026 19:35:56 +0200
Paweł Wiśniewski <pawel.wis.me@gmail.com> wrote:
> Tested on a Raspberry Pi 3 Model B+ running
> 6.18.34+rpt-rpi-v8. The sensor was instantiated using only the
> cytron,hc-sr04 compatible, with trigger connected to GPIO17 and echo
> connected to GPIO27 through a 5 V to 3.3 V resistor divider. The
> driver bound to the device, registered an IIO device, and returned
> changing distance readings through in_distance_raw.
>
> Assisted-by: ChatGPT:GPT-5.6 Thinking
> Signed-off-by: Paweł Wiśniewski <pawel.wis.me@gmail.com>
This suggests that it is very much suited to a fallback compatible to the
Devantech SRF04 (see comment I made on the binding).
With that in place, we probably don't need a driver change.
Thanks,
Jonathan
> ---
> drivers/iio/proximity/Kconfig | 1 +
> drivers/iio/proximity/srf04.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
> index bb77fad2a1b3..89e9d57ceba6 100644
> --- a/drivers/iio/proximity/Kconfig
> +++ b/drivers/iio/proximity/Kconfig
> @@ -139,6 +139,7 @@ config SRF04
> ranger sensor. This driver can be used to measure the distance
> of objects. It is using two GPIOs.
> Actually Supported types are:
> + - Cytron HC-SR04
> - Devantech SRF04
> - Maxbotix mb1000
> - Maxbotix mb1010
> diff --git a/drivers/iio/proximity/srf04.c b/drivers/iio/proximity/srf04.c
> index 7be50bdebfcb..f5ee7d6572b5 100644
> --- a/drivers/iio/proximity/srf04.c
> +++ b/drivers/iio/proximity/srf04.c
> @@ -231,6 +231,7 @@ static const struct iio_chan_spec srf04_chan_spec[] = {
> };
>
> static const struct of_device_id of_srf04_match[] = {
> + { .compatible = "cytron,hc-sr04", .data = &srf04_cfg },
> { .compatible = "devantech,srf04", .data = &srf04_cfg },
> { .compatible = "maxbotix,mb1000", .data = &mb_lv_cfg },
> { .compatible = "maxbotix,mb1010", .data = &mb_lv_cfg },
^ permalink raw reply
* Re: [RFC PATCH 2/3] dt-bindings: iio: proximity: Add Cytron HC-SR04
From: Jonathan Cameron @ 2026-07-18 22:45 UTC (permalink / raw)
To: Paweł Wiśniewski
Cc: dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt, ak, linux-iio,
devicetree, linux-kernel
In-Reply-To: <bb79ea1b842e062dd47bd1fb31fdd15a9ef76c29.1784221074.git.pawel.wis.me@gmail.com>
On Thu, 16 Jul 2026 19:35:55 +0200
Paweł Wiśniewski <pawel.wis.me@gmail.com> wrote:
> The Cytron HC-SR04 starts a ranging cycle with an active-high trigger
> pulse of at least 10 us and reports the acoustic round-trip time as
> the width of an active-high echo pulse.
>
> Add the cytron,hc-sr04 compatible and a reference to the product
> manual. Update the trigger GPIO description to account for the pulse
> durations used by the supported devices.
>
> The interface matches the two-GPIO protocol implemented by the
> existing SRF04 driver.
Is it suited to using a fallback compatible to one of those already
supported parts? This should say where things are different.
>
> Assisted-by: ChatGPT:GPT-5.6 Thinking
> Signed-off-by: Paweł Wiśniewski <pawel.wis.me@gmail.com>
> ---
> .../devicetree/bindings/iio/proximity/devantech-srf04.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
> index ce795279839e..f4237ae612ab 100644
> --- a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
> +++ b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/iio/proximity/devantech-srf04.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Devantech SRF04 and Maxbotix mb1000 ultrasonic range finder
> +title: Devantech SRF04 and Maxbotix mb1000 and Cytron HC-SR04 ultrasonic range finder
If we were going to keep the list going it would need to be:
title: Devantech SRF04, Maxbotix mb1000 and Cytron HC-SR04 ultrasonic range finder
However, previous experience suggests that sooner or later it is better to just
jump to Devantech SRF04 and similar.
>
> maintainers:
> - Andreas Klinger <ak@it-klinger.de>
> @@ -21,9 +21,12 @@ description: |
>
> https://www.maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf
>
> + https://botland.com.pl/index.php?controller=attachment&id_attachment=476
> +
> properties:
> compatible:
> enum:
> + - cytron,hc-sr04
> - devantech,srf04
> - maxbotix,mb1000
> - maxbotix,mb1010
^ permalink raw reply
* Re: [PATCH v10 2/2] iio: health: add MAX86150 ECG and PPG biosensor driver
From: Jonathan Cameron @ 2026-07-18 22:40 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, devicetree, robh, krzk+dt, conor+dt, andriy.shevchenko,
u.kleine-koenig, joshua.crofts1, nuno.sa, Michael.Hennerich,
dlechner, linux, linux-kernel
In-Reply-To: <20260717201138.1078019-3-shofiqtest@gmail.com>
On Fri, 17 Jul 2026 23:11:37 +0300
Md Shofiqul Islam <shofiqtest@gmail.com> wrote:
> Add a new IIO driver for the Analog Devices MAX86150 integrated
> biosensor, which combines two PPG optical channels (Red/IR LED) and
> one ECG biopotential channel in a single I2C device.
>
> The device has a 32-entry hardware FIFO with a configurable almost-full
> interrupt. The driver uses the standard IIO hardware-trigger and
> triggered-buffer framework: a hard-irq handler reads and clears
> INT_STATUS1 to de-assert the line before calling iio_trigger_poll(),
> and the threaded trigger handler drains the FIFO and pushes samples,
> with timestamps back-calculated from the interrupt arrival time by one
> sample_period_ns per step. Relying on the trigger core's own
> attach/detach synchronization avoids the need for an explicit
> iio_buffer_enabled() guard or synchronize_irq() in the interrupt path.
Why is it using a triggered buffer + trigger? We normally don't do
that when a hardware fifo is involved. That stuff is all about when
a trigger indicate a scan of channels (one set of samples of all channels).
Look at the drivers that register a kfifo directly. Sorry I didn't
raise this earlier. I think I got too focused on the narrow details
rather than the big picture.
>
> Key implementation details:
> - Part ID register (0xFF) verified against 0x1E on probe; mismatched
> devices are rejected with -ENODEV so the driver cannot bind to the
> wrong hardware
> - Stale A_FULL and PPG_RDY status bits are cleared before arming the
> interrupt or polling for a sample, so a previously-latched flag
> cannot fire the handler against garbage state
> - 24-bit FIFO words decoded directly from the raw byte buffer
> - regmap_set_bits() / regmap_clear_bits() for single-direction writes
> - Device remains in shutdown between captures to suppress LED current
> - vdd, avdd, vref and leds regulators required per the datasheet power
> tree
> - iio_get_time_ns() used for timestamps so they respect the IIO
> device's configured clock source
> - A_FULL status bit used to detect FIFO exactly full (wr_ptr == rd_ptr
> with OVF_COUNTER == 0) so valid samples are not silently dropped
> - No IRQ trigger-type override: the device has no register to
> reconfigure interrupt polarity or type, so IRQF_ONESHOT with
> whatever type firmware provides is sufficient
>
> Suggested-by: Jonathan Cameron <jic23@kernel.org>
> Suggested-by: Joshua Crofts <joshua.crofts1@gmail.com>
> Assisted-by: Claude:claude-sonnet-5
> Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> diff --git a/drivers/iio/health/max86150.c b/drivers/iio/health/max86150.c
> new file mode 100644
> index 0000000000000..47d96570a95fc
> --- /dev/null
> +++ b/drivers/iio/health/max86150.c
> +static int max86150_chip_init(struct max86150_data *data)
> +{
...
> + if (ret)
> + return ret;
> +
> + data->sample_period_ns = 10000000; /* matches MAX86150_PPG_SR_SP_100HZ above */
Probably express as NANO / 100;
> +
> +static int max86150_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct iio_dev *indio_dev;
> + struct max86150_data *data;
> + unsigned int part_id;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + data = iio_priv(indio_dev);
> +
> + ret = devm_regulator_get_enable(dev, "vdd");
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to enable vdd supply\n");
> +
> + ret = devm_regulator_get_enable(dev, "avdd");
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to enable avdd supply\n");
> +
> + ret = devm_regulator_get_enable(dev, "vref");
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to enable vref supply\n");
> +
> + ret = devm_regulator_get_enable(dev, "leds");
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to enable leds supply\n");
Given there are 4 of these devm_regulator_bulk_get_enable() probably makes sense.
> +
> + data->regmap = devm_regmap_init_i2c(client, &max86150_regmap_config);
> + if (IS_ERR(data->regmap))
> + return dev_err_probe(dev, PTR_ERR(data->regmap),
> + "Failed to init regmap\n");
> +
> + ret = regmap_read(data->regmap, MAX86150_REG_PART_ID, &part_id);
> + if (ret)
> + return dev_err_probe(dev, ret, "Cannot read part ID\n");
> +
> + if (part_id != MAX86150_PART_ID_VAL)
> + return dev_err_probe(dev, -ENODEV,
> + "Unexpected part ID 0x%02x (expected 0x%02x)\n",
> + part_id, MAX86150_PART_ID_VAL);
This breaks fallback dt compatibles. Normally if we get a missmatch we just print
a message and carry on anyway. If we need to not do that for some reason here
add a comment to that affect.
> +
> + ret = max86150_chip_init(data);
> + if (ret)
> + return dev_err_probe(dev, ret, "Chip initialisation failed\n");
> +
> + ret = devm_add_action_or_reset(dev, max86150_powerdown, data);
> + if (ret)
> + return ret;
> +
> + indio_dev->name = "max86150";
> + indio_dev->channels = max86150_channels;
> + indio_dev->num_channels = ARRAY_SIZE(max86150_channels);
> + indio_dev->info = &max86150_iio_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + if (client->irq > 0) {
> + data->trig = devm_iio_trigger_alloc(dev, "%s-dev%d",
> + indio_dev->name,
> + iio_device_id(indio_dev));
> + if (!data->trig)
> + return -ENOMEM;
> +
> + data->trig->ops = &max86150_trigger_ops;
> + iio_trigger_set_drvdata(data->trig, indio_dev);
> +
> + /*
> + * The device only ever drives an active-low interrupt line;
> + * there is no register to reconfigure its polarity or type,
> + * so the trigger type from firmware needs no help here.
Not need to say this. It is most common situation.
> + */
> + ret = devm_request_threaded_irq(dev, client->irq,
> + NULL,
> + max86150_irq_handler,
> + IRQF_ONESHOT,
> + "max86150", data->trig);
Using a trigger for a fifo full interrupt is always a little bit overly
complex. In this case you have both validation function set so
you can't use the buffer without this trigger being available.
If it is meaningful to trigger this from another source then
maybe you use a triggered_buffer. In some cases where both types
of operation are things people want (maybe from a sysfs trigger) we don't
necessarily register a trigger for the fifo interrupt. The lack of having
set a trigger can mean that path should be used.
Normal thing to do in this case is no trigger + directly register
a kfifo to fill from the hardware fifo. Simply turning that buffer
on is the signal to begin capture.
> + if (ret)
> + return ret;
> +
> + ret = devm_iio_trigger_register(dev, data->trig);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to register trigger\n");
> + }
> +
> + ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
> + iio_pollfunc_store_time,
> + max86150_trigger_handler,
> + NULL);
> + if (ret)
> + return ret;
> +
> + /*
> + * Set the default trigger AFTER buffer setup succeeds. Setting it
> + * before would leak the iio_trigger_get() reference if buffer setup
> + * failed: INDIO_BUFFER_TRIGGERED is not set on that path so
> + * iio_device_release() skips iio_trigger_put().
I don't believe there is anything stopping you just registering
the triggered_buffer before the trigger. That would get rid of
this complexity.
> + */
> + if (data->trig)
> + indio_dev->trig = iio_trigger_get(data->trig);
> +
> + return devm_iio_device_register(dev, indio_dev);
> +}
^ permalink raw reply
* Re: [PATCH v10 1/2] dt-bindings: iio: health: add adi,max86150
From: Jonathan Cameron @ 2026-07-18 22:19 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, devicetree, robh, krzk+dt, conor+dt, andriy.shevchenko,
u.kleine-koenig, joshua.crofts1, nuno.sa, Michael.Hennerich,
dlechner, linux, linux-kernel
In-Reply-To: <20260717201138.1078019-2-shofiqtest@gmail.com>
On Fri, 17 Jul 2026 23:11:36 +0300
Md Shofiqul Islam <shofiqtest@gmail.com> wrote:
> Add the Device Tree binding schema for the Analog Devices MAX86150
> integrated biosensor, which combines two photoplethysmography (PPG)
> channels (Red LED and IR LED) and one electrocardiogram (ECG) channel
> in a single I2C device. Samples are buffered in a 32-entry hardware
> FIFO with a configurable almost-full interrupt.
>
> The device requires four independent supply rails per the datasheet
> power tree: digital core (vdd), analog core (avdd), ECG reference
> (vref), and LED anode (leds).
>
> Assisted-by: Claude:claude-sonnet-5
> Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
A few small things inline from a fresh look.
Thanks,
Jonathan
> ---
> .../bindings/iio/health/adi,max86150.yaml | 78 +++++++++++++++++++
> MAINTAINERS | 6 ++
> 2 files changed, 84 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/health/adi,max86150.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/health/adi,max86150.yaml b/Documentation/devicetree/bindings/iio/health/adi,max86150.yaml
> new file mode 100644
> index 0000000000000..da2ff9b0ada2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/health/adi,max86150.yaml
> @@ -0,0 +1,78 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/health/adi,max86150.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices MAX86150 ECG and PPG Biosensor
> +
> +maintainers:
> + - Md Shofiqul Islam <shofiqtest@gmail.com>
> +
> +description: |
> + The MAX86150 is an integrated biosensor SoC that combines:
> + - Two PPG (photoplethysmography) channels: Red LED and IR LED,
> + for heart rate and blood-oxygen saturation (SpO2) measurement.
> + - One ECG (electrocardiogram) channel for biopotential recording.
> +
> + The device communicates over I2C at up to 400 kHz and raises an
> + active-low interrupt when the 32-entry hardware FIFO reaches its
> + configurable almost-full threshold.
For this the 32-entry fifo bit is good but maybe move ti to the interrupt
description. The rest of this paragraph is a repeat of detail below where
it is more useful. Hence I would drop it.
> +
> + Datasheet:
> + https://www.analog.com/media/en/technical-documentation/data-sheets/MAX86150.pdf
> +
> +properties:
> + compatible:
> + const: adi,max86150
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> + description: |
Formatting not needed so drop the |
> + Active-low interrupt line. Asserted when the FIFO almost-full
> + threshold is reached or when a new PPG sample is ready.
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: dac: fix spelling of 'reference' in adi,ad5791
From: Jonathan Cameron @ 2026-07-18 22:05 UTC (permalink / raw)
To: Yahya Toubali
Cc: Nuno Sá, Michael Hennerich, David Lechner, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:ANALOG DEVICES INC IIO DRIVERS,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20260718165615.1923592-1-yahya@yahyatoubali.me>
On Sat, 18 Jul 2026 17:56:14 +0100
Yahya Toubali <yahya@yahyatoubali.me> wrote:
> Fix misspelling of 'reference' (was 'referance') in the
> vrefp-supply and vrefn-supply descriptions.
>
> Signed-off-by: Yahya Toubali <yahya@yahyatoubali.me>
Hi Yahya, I'm not 100% sure why, but none of your postings made it
to my local inbox. However, they were in patchwork and lore so it
might be a temporary problem my end.
Applied,
Thanks,
Jonathan
> ---
> Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml
> index 2bd89e0aa46b..80fb98035c6f 100644
> --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5791.yaml
> @@ -36,11 +36,11 @@ properties:
>
> vrefp-supply:
> description:
> - Positive referance input voltage range. From 5v to (vdd - 2.5)
> + Positive reference input voltage range. From 5v to (vdd - 2.5)
>
> vrefn-supply:
> description:
> - Negative referance input voltage range. From (vss + 2.5) to 0.
> + Negative reference input voltage range. From (vss + 2.5) to 0.
>
> adi,rbuf-gain2-en:
> description: Specify to allow an external amplifier to be connected in a
>
> base-commit: 1229e2e57a5c2980ccd457b9b53ea0eed5a22ab3
> prerequisite-patch-id: c8aee5eb39e3cd6f2b2f28c82163565665288d2a
> prerequisite-patch-id: 60ad32e9f0e74902635d7886b97c4225ac8dc5ce
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: leds: backlight: Convert TPS65217 to DT schema
From: sashiko-bot @ 2026-07-18 22:04 UTC (permalink / raw)
To: Eduard Bostina
Cc: devicetree, dri-devel, lee, linux-leds, robh, linux-input,
dmitry.torokhov, conor+dt
In-Reply-To: <20260718215632.3295049-4-egbostina@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Stale and conflicting regulator text binding not deleted during schema conversion.
- [Low] Missing `required` constraint for `reg` property in regulator child nodes.
--
--- Patch [3]: [PATCH v2 3/3] dt-bindings: leds: backlight: Convert TPS65217 to DT schema ---
commit 0671f0f93114029deaa2c3fee6b27ad8abd2cb2d
Author: Eduard Bostina <egbostina@gmail.com>
dt-bindings: leds: backlight: Convert TPS65217 to DT schema
This commit converts the Texas Instruments TPS65217 backlight binding to YAML
schema. It also documents missing child nodes, interrupt properties, and
updates regulator names to match what the boards use.
> diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
> new file mode 100644
> index 0000000000000..9586e08f1b1fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
> @@ -0,0 +1,123 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/ti,tps65217.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TPS65217 family of regulators
[Severity: Medium]
Should Documentation/devicetree/bindings/regulator/tps65217.txt also be
deleted in this patch?
The new YAML schema defines the full MFD device, but conflicts with the
undeleted regulator text binding. The old regulator text binding expects
regulator nodes to be named dcdc[1-3] and ldo[1-4], while the new schema
expects regulator@[0-6], which could cause validation inconsistencies.
[ ... ]
> + patternProperties:
> + "^regulator@[0-6]$":
> + type: object
> + $ref: /schemas/regulator/regulator.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + regulator-compatible:
> + $ref: /schemas/types.yaml#/definitions/string
[Severity: Low]
Does this schema need to specify the reg property as required?
Since these regulator child nodes have a unit address in the pattern
(^regulator@[0-6]$), DT validation could incorrectly pass nodes that contain a
unit address but lack the mandatory reg property without a required block.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718215632.3295049-1-egbostina@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: input: Convert TI TPS65217 power button to DT schema
From: sashiko-bot @ 2026-07-18 22:02 UTC (permalink / raw)
To: Eduard Bostina
Cc: dmitry.torokhov, robh, devicetree, lee, dri-devel, conor+dt,
linux-input, linux-leds
In-Reply-To: <20260718215632.3295049-3-egbostina@gmail.com>
> Convert the Texas Instruments TPS65217 and TPS65218 Power Button
> bindings to DT schema.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718215632.3295049-1-egbostina@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: dts: ti: am335x-guardian: Drop unused isink-en property
From: sashiko-bot @ 2026-07-18 21:59 UTC (permalink / raw)
To: Eduard Bostina
Cc: linux-leds, lee, dmitry.torokhov, devicetree, dri-devel,
linux-input, conor+dt, robh
In-Reply-To: <20260718215632.3295049-2-egbostina@gmail.com>
> The 'isink-en' property is not read by any driver, so remove it from the
> TPS65217 backlight node.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718215632.3295049-1-egbostina@gmail.com?part=1
^ permalink raw reply
* [PATCH v2 3/3] dt-bindings: leds: backlight: Convert TPS65217 to DT schema
From: Eduard Bostina @ 2026-07-18 21:56 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Pavel Machek,
Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry
In-Reply-To: <20260718215632.3295049-1-egbostina@gmail.com>
Convert the Texas Instruments TPS65217 bindings to DT schema.
During the conversion, the following updates were made:
- Documented the 'regulators', 'charger' and 'pwrbutton' child nodes,
which are used by the boards but were missing from the old txt
binding.
- Documented the 'interrupts', 'interrupt-controller', '#interrupt-cells'
and 'ti,pmic-shutdown-controller' properties, which are used by the
am335x boards and read by the driver.
- Named the regulators 'regulator@[0-6]' to match what the boards use
instead of the dcdc/ldo node names from the txt binding.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
---
.../bindings/leds/backlight/ti,tps65217.yaml | 123 ++++++++++++++++++
.../leds/backlight/tps65217-backlight.txt | 27 ----
2 files changed, 123 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
new file mode 100644
index 000000000000..9586e08f1b1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/ti,tps65217.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TPS65217 family of regulators
+
+maintainers:
+ - Eduard Bostina <egbostina@gmail.com>
+
+description:
+ The TPS65217 chip contains a boost converter and current sinks which can be
+ used to drive LEDs for use as backlights.
+
+properties:
+ compatible:
+ const: ti,tps65217
+
+ reg:
+ maxItems: 1
+ description: I2C slave address
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 1
+
+ ti,pmic-shutdown-controller:
+ type: boolean
+ description:
+ Set the PMIC to shutdown on PWR_EN toggle.
+
+ backlight:
+ type: object
+ additionalProperties: false
+ description:
+ Node for specifying WLED1 and WLED2 lines in TPS65217.
+
+ properties:
+ isel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2]
+ description: |
+ Selection bit. Valid values:
+ 1 - ISEL1 (low-level)
+ 2 - ISEL2 (high-level)
+
+ fdim:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [100, 200, 500, 1000]
+ description:
+ PWM dimming frequency in Hz.
+
+ default-brightness:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 100
+
+ required:
+ - isel
+ - fdim
+ - default-brightness
+
+ regulators:
+ type: object
+ additionalProperties: false
+ description:
+ List of child nodes that specify the regulator initialization data.
+ Not all regulators for the given device need to be present.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^regulator@[0-6]$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ maxItems: 1
+
+ regulator-compatible:
+ $ref: /schemas/types.yaml#/definitions/string
+
+ charger:
+ $ref: /schemas/power/supply/tps65217-charger.yaml#
+
+ pwrbutton:
+ $ref: /schemas/input/ti,tps65217-pwrbutton.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tps@24 {
+ reg = <0x24>;
+ compatible = "ti,tps65217";
+
+ backlight {
+ isel = <1>; /* 1 - ISET1, 2 ISET2 */
+ fdim = <100>; /* TPS65217_BL_FDIM_100HZ */
+ default-brightness = <50>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
deleted file mode 100644
index 5fb9279ac287..000000000000
--- a/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-TPS65217 family of regulators
-
-The TPS65217 chip contains a boost converter and current sinks which can be
-used to drive LEDs for use as backlights.
-
-Required properties:
-- compatible: "ti,tps65217"
-- reg: I2C slave address
-- backlight: node for specifying WLED1 and WLED2 lines in TPS65217
-- isel: selection bit, valid values: 1 for ISEL1 (low-level) and 2 for ISEL2 (high-level)
-- fdim: PWM dimming frequency, valid values: 100, 200, 500, 1000
-- default-brightness: valid values: 0-100
-
-Each regulator is defined using the standard binding for regulators.
-
-Example:
-
- tps: tps@24 {
- reg = <0x24>;
- compatible = "ti,tps65217";
- backlight {
- isel = <1>; /* 1 - ISET1, 2 ISET2 */
- fdim = <100>; /* TPS65217_BL_FDIM_100HZ */
- default-brightness = <50>;
- };
- };
-
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: input: Convert TI TPS65217 power button to DT schema
From: Eduard Bostina @ 2026-07-18 21:56 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Pavel Machek,
Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry
In-Reply-To: <20260718215632.3295049-1-egbostina@gmail.com>
Convert the Texas Instruments TPS65217 and TPS65218 Power Button
bindings to DT schema.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
---
.../bindings/input/ti,tps65217-pwrbutton.yaml | 42 +++++++++++++++++++
.../bindings/input/tps65218-pwrbutton.txt | 30 -------------
2 files changed, 42 insertions(+), 30 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
delete mode 100644 Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
diff --git a/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml b/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
new file mode 100644
index 000000000000..3526d8b045fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ti,tps65217-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TPS65217 and TPS65218 Power Button
+
+maintainers:
+ - Eduard Bostina <egbostina@gmail.com>
+
+description:
+ This module is part of the TPS65217/TPS65218 PMIC. It provides a simple
+ power button event via an interrupt.
+
+properties:
+ compatible:
+ enum:
+ - ti,tps65217-pwrbutton
+ - ti,tps65218-pwrbutton
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ pmic {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-button {
+ compatible = "ti,tps65218-pwrbutton";
+ interrupts = <3 IRQ_TYPE_EDGE_BOTH>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
deleted file mode 100644
index 8682ab6d4a50..000000000000
--- a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Texas Instruments TPS65217 and TPS65218 power button
-
-This module is part of the TPS65217/TPS65218. For more details about the whole
-TPS65217 chip see Documentation/devicetree/bindings/regulator/tps65217.txt.
-
-This driver provides a simple power button event via an Interrupt.
-
-Required properties:
-- compatible: should be "ti,tps65217-pwrbutton" or "ti,tps65218-pwrbutton"
-
-Required properties:
-- interrupts: should be one of the following
- - <2>: For controllers compatible with tps65217
- - <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218
-
-Examples:
-
-&tps {
- tps65217-pwrbutton {
- compatible = "ti,tps65217-pwrbutton";
- interrupts = <2>;
- };
-};
-
-&tps {
- power-button {
- compatible = "ti,tps65218-pwrbutton";
- interrupts = <3 IRQ_TYPE_EDGE_BOTH>;
- };
-};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: ti: am335x-guardian: Drop unused isink-en property
From: Eduard Bostina @ 2026-07-18 21:56 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Pavel Machek,
Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry
In-Reply-To: <20260718215632.3295049-1-egbostina@gmail.com>
The 'isink-en' property is not read by any driver, so remove it from the
TPS65217 backlight node.
Signed-off-by: Eduard Bostina <egbostina@gmail.com>
---
arch/arm/boot/dts/ti/omap/am335x-guardian.dts | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
index 6ce3a2d029ee..d595e79d6b05 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
@@ -320,9 +320,6 @@ backlight {
isel = <1>; /* 1 - ISET1, 2 ISET2 */
fdim = <500>; /* TPS65217_BL_FDIM_500HZ */
default-brightness = <50>;
- /* 1(on) - enable current sink, while initialization */
- /* 0(off) - disable current sink, while initialization */
- isink-en = <1>;
};
regulators {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] dt-bindings: Convert TI TPS65217 to DT schema
From: Eduard Bostina @ 2026-07-18 21:56 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Conor Dooley, Daniel Thompson,
devicetree, Dmitry Torokhov, dri-devel, Eduard Bostina,
Jingoo Han, Kevin Hilman, Krzysztof Kozlowski, Lee Jones,
linux-input, linux-kernel, linux-leds, linux-omap, Pavel Machek,
Rob Herring, Roger Quadros, Tony Lindgren
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry
This series converts the Texas Instruments TPS65217 PMIC bindings to DT
schema.
Changes in v2:
- Set 'additionalProperties' to false and documented all child nodes
('regulators', 'charger', 'pwrbutton').
- Documented the 'interrupts', 'interrupt-controller', '#interrupt-cells'
and 'ti,pmic-shutdown-controller' properties.
- Dropped 'isink-en' from the schema. It is not read by any driver, so it
is now removed from am335x-guardian.dts instead.
- Added the power button conversion and referenced it from
the leds schema.
Eduard Bostina (3):
ARM: dts: ti: am335x-guardian: Drop unused isink-en property
dt-bindings: input: Convert TI TPS65217 power button to DT schema
dt-bindings: leds: backlight: Convert TPS65217 to DT schema
.../bindings/input/ti,tps65217-pwrbutton.yaml | 42 ++++++
.../bindings/input/tps65218-pwrbutton.txt | 30 -----
.../bindings/leds/backlight/ti,tps65217.yaml | 123 ++++++++++++++++++
.../leds/backlight/tps65217-backlight.txt | 27 ----
arch/arm/boot/dts/ti/omap/am335x-guardian.dts | 3 -
5 files changed, 165 insertions(+), 60 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/ti,tps65217-pwrbutton.yaml
delete mode 100644 Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
create mode 100644 Documentation/devicetree/bindings/leds/backlight/ti,tps65217.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
--
2.43.0
^ permalink raw reply
* Re: [PATCH v9 0/7] clk: qcom: Add common clkref support and migrate Glymur and Mahua
From: Bjorn Andersson @ 2026-07-18 21:52 UTC (permalink / raw)
To: Qiang Yu
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Kees Cook,
Gustavo A. R. Silva, Konrad Dybcio, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-hardening, Krzysztof Kozlowski,
Konrad Dybcio
In-Reply-To: <20260713-tcsr_qref_0714-v9-0-373670ab15f9@oss.qualcomm.com>
On Mon, Jul 13, 2026 at 09:59:35PM -0700, Qiang Yu wrote:
> This series adds a common clkref_en implementation and converts glymur
> and mahua to use it, along with the related binding and DTS updates.
>
> The PCIe clkref clocks on Glymur and Mahua gate the QREF block which
> provides reference clocks to the PCIe PHYs. QREF requires LDO supplies
> and a reference voltage from the refgen block to operate. The refgen
> block itself requires vdda-refgen_0p9 and vdda-refgen_1p2 LDOs to
> function.
>
> Previously, these QREF votes were done in PHY drivers. In earlier
> discussion [1], the feedback was that this is the wrong ownership point:
> those supplies are for the QREF controlled by clkref registers, not for
> the PHY directly. Based on that feedback, this series keeps the
> regulator handling with the clkref control path.
>
> Another reason for this series is reuse. clkref_en registers may live in
> different blocks across platforms (for example TCSR on Glymur, TLMM on
> SM8750 [2]), while the behavior is the same. The common helper lets each
> driver provide simple descriptors (name, offset, optional supplies) and
> reuse shared registration and runtime logic.
>
> Glymur and Mahua share the same QREF TX/RPT/RX component naming but
> have different PCIe QREF topologies. Both are handled in tcsrcc-glymur.c
> via match_data to select the correct descriptor table per compatible.
>
> [1] https://lore.kernel.org/lkml/aEBfV2M-ZqDF7aRz@hovoldconsulting.com/
> [2] https://lore.kernel.org/linux-arm-msm/20260202-topic-8750_tcsr-v1-0-cd7e6648c64f@oss.qualcomm.com/
>
> Changes in v9:
> - Add reviewed-by tags, no code change.
> - Link to v8: https://lore.kernel.org/all/20260708-tcsr_qref_0708-v8-0-62c42b5fa269@oss.qualcomm.com/
>
> Changes in v8:
> - Define refs with __counted_by(num_refs) and make provider a single allocation
> - Use mahua_tcsr_tx1_rpt012_rx2_regulators for PCIe6.
> - Link to v7: https://lore.kernel.org/all/20260702-tcsr_qref_0702-v7-0-776f2811b7af@oss.qualcomm.com/
>
> Changes in v7:
> - Define compatible as an enum and add the per-compatible allOf/if/then block upfront for glymur. Reword commit msg for patch1
> - Drop Krzysztof's Reviewed-by since the patch changed substantially from what he reviewed.
> - Added a comment noting that on Mahua the REFGEN4 block is supplied by the vdda-refgen3-* regulators, and mentioned this in the commit message for patch2.
> - Change the descriptor array to an array of pointers (const struct qcom_clk_ref_desc * const *). Skip unpopulated indices with if (!desc)
> - Convert tcsr_cc_glymur_clk_descs[] and tcsr_cc_mahua_clk_descs[] to a pointer array.
> - Add regulator lists for clkref_en on Mahua.
> - Null-check device_get_match_data() result in probe.
> - Add rx0 regulator in mahua tcsr node
> - Squashed the former patch 8 (switch pcie5_phy ref clock to RPMH_CXO_CLK) into patch7, so Mahua PCIe probes at every commit.
> - Link to v6: https://lore.kernel.org/all/20260621-tcsr_qref_0622-v6-0-c939c22ded0c@oss.qualcomm.com/
>
> Changes in v6:
> - Split dt-bindings patch into two: one to move glymur-tcsr to its own
> binding file, and one to add mahua support
> - Use regmap_set_bits()/regmap_clear_bits() instead of regmap_update_bits()
> in clk-ref.c
> - Move clk_init_data from struct qcom_clk_ref to a stack variable in
> qcom_clk_ref_register()
> - Add Co-developed-by/Reviewed-by tags from Konrad Dybcio
> - Add missing regulator supplies for EDP and USB clkref_en on glymur
> - Link to v5: https://patch.msgid.link/20260602-tcsr_qref_0527-v5-0-8ea174a59d7e@oss.qualcomm.com
>
> Changes in v5:
> - Return 0 if regmap_read fail
> - Add a separate file for glymur-tcsr and mahua-tcsr
> - Link to v4: https://patch.msgid.link/20260527-tcsr_qref_0527-v4-0-ded83866c9d9@oss.qualcomm.com
>
> Changes in v4:
> - Add mahua QREF support (binding, driver, DTS) to avoid dtb check error
> - Override pcie5_phy ref clock to RPMH_CXO_CLK on mahua since
> TCSR_PCIE_1_CLKREF_EN is not available
> - Rename regulator arrays to topology-based names and merge duplicates
> - Remove else: false blocks from binding
> - Sort supply properties alphabetically in binding and DTS
> - Link to v3: https://lore.kernel.org/all/20260506-qref_vote_0506-v3-0-5ab71d2e6f16@oss.qualcomm.com/
>
> Changes in v3:
> - Fix dtb check error: allOf:0: 'then' is a dependency of 'if'.
> - Link to v2: https://lore.kernel.org/all/20260420-vote_qref_in_tcsrcc-v2-0-589a23ae640a@oss.qualcomm.com/
>
> Changes in v2:
> - RFC tag dropped
> - Changed back to additionalProperties: false
> - Moved all Glymur supply properties into top-level properties so they are explicitly defined.
> - Link to v1: https://lore.kernel.org/all/20260331-qref_vote-v1-0-3fd7fbf87864@oss.qualcomm.com/
>
> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> ---
> Qiang Yu (7):
> dt-bindings: clock: qcom: Move glymur TCSR to own binding
> dt-bindings: clock: qcom,glymur-tcsr: Add mahua support
> clk: qcom: Add generic clkref_en support
> clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper
> clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
> arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
> arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
>
> .../bindings/clock/qcom,glymur-tcsr.yaml | 146 +++++++
> .../bindings/clock/qcom,sm8550-tcsr.yaml | 2 -
> arch/arm64/boot/dts/qcom/glymur-crd.dts | 20 +
> arch/arm64/boot/dts/qcom/mahua-crd.dts | 16 +
> arch/arm64/boot/dts/qcom/mahua.dtsi | 13 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/clk-ref.c | 205 +++++++++
> drivers/clk/qcom/tcsrcc-glymur.c | 471 +++++++++++----------
> include/linux/clk/qcom.h | 67 +++
> 9 files changed, 704 insertions(+), 237 deletions(-)
> ---
> base-commit: 3da905eb243cad56200f09bb7eaa060537aed0cc
I was hoping to apply this series, but I don't have this commit and
patch 4 ("migrate to clk_ref helper") doesn't apply to my tree.
What did you base this on? Why don't you test your changes on latest
mainline or linux-next?
Please rebase and test on a relevant branch.
Regards,
Bjorn
> change-id: 20260713-tcsr_qref_0714-0ee27bc42a07
>
> Best regards,
> --
> Qiang Yu <qiang.yu@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH v7 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs
From: Jonathan Cameron @ 2026-07-18 21:39 UTC (permalink / raw)
To: Marcelo Schmitt
Cc: sashiko-reviews, Marcelo Schmitt, conor+dt, devicetree, robh,
linux-iio
In-Reply-To: <alvKfTS8Kj1MF3db@debian-BULLSEYE-live-builder-AMD64>
On Sat, 18 Jul 2026 15:48:29 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
> TL;DR: Will switch to voltageY-voltageZ ABI.
>
> On 07/18, Jonathan Cameron wrote:
> > On Fri, 17 Jul 2026 13:38:07 -0300
> > Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
> >
> > > On 07/16, sashiko-bot@kernel.org wrote:
> > > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > > - [Medium] The `LTC2378_DIFF_CHANNEL` macro defines an IIO channel that is intended to be differential but lacks the `.differential = 1`, `.indexed = 1`, `.channel = 0`, and `.channel2 = 1` attributes.
> > > > --
> > > >
> > > > --- Patch [2]: [PATCH v7 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs ---
> > > > commit 5710d5f25b45906977e2522567c1964b1d3219f8
> > > > Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > >
> > > > iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs
> > > >
> > > > This commit adds a new driver for the Analog Devices LTC2378-20 and
> > > > similar analog-to-digital converters.
> > > >
> > > > > diff --git a/drivers/iio/adc/ltc2378.c b/drivers/iio/adc/ltc2378.c
> > > > > new file mode 100644
> > > > > index 0000000000000..5600c820c7f45
> > > > > --- /dev/null
> > > > > +++ b/drivers/iio/adc/ltc2378.c
> > > > > @@ -0,0 +1,416 @@
> > > > [ ... ]
> > > > > +#define LTC2378_DIFF_CHANNEL(_sign, _real_bits, _storage_bits) \
> > > > > +{ \
> > > > > + .type = IIO_VOLTAGE, \
> > > > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> > > > > + BIT(IIO_CHAN_INFO_SCALE), \
> > > > > + .scan_index = 0, \
> > > >
> > > > [Severity: Medium]
> > > > Does this macro need to set .differential = 1, .indexed = 1, .channel = 0,
> > > > and .channel2 = 1? The name suggests these are differential channels, but
> > > > without these attributes, the IIO ABI will expose them as single-ended
> > > > (e.g., in_voltage_raw instead of in_voltage0-voltage1_raw).
> > >
> > > For parts with multiple inputs and configurable differential channels (e.g.
> > > AD4130-8, MCP3561/2/4R, NAFE13388 [1, 2, 3]), the voltageY-voltageZ ABI helps
> > > clarifying what physical inputs make up a channel. For differential only parts,
> > > the ABI seems to be flexible by only requiring a 'consistent labeling' (either
> > > voltageY or voltageY-voltageZ IIUC). Will set the channel with the differential
> > > ABI if maintainers believe that's the best way to have it. Might slightly tweak
> > > the channel macros to keep .differential = 0 for pseudo-differential chips
> > > (e.g.LTC2369-18).
> >
> > Whilst I get your point on differential only cases not really requiring the
> > specification of two inputs, I think that does provide a simple indication
> > to users that they are differential channel.
> Agree. The first ADCs I've worked with were single-ended so having to provide
> the negative input when working with differential ones was something noticeable
> to me. Though, one applications engineer once called me out for the
> voltageY-voltageZ naming arguing that a differential channel provided only one
> input to his application and thus it should be labeled only 'voltageY' or even
> just 'voltage'. Despite understanding that argument, I share the opinion
> that an indication of differential channel is helpful. Anyways, besides the
> possibility for application to display channel names differently in user space,
> I see we now have .read_label so the whole discussion seems pointless.
>
> >
> > I would prefer that we make them 'look' like differential channels so make up
> > a suitable number for the negative side.
>
> Would it make sense to adjust the ABI doc to encourage the dual numbering for
> differential channels? So I don't fall the temptation of single index in the
> future :)
Yes. That would be good!
Thanks,
Jonathan
>
> Thanks,
> Marcelo
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: rockchip: Add Vicharak Vaaman board
From: Andrew Lunn @ 2026-07-18 20:58 UTC (permalink / raw)
To: Hrushiraj Gandhi
Cc: heiko, devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
robh, krzk+dt, conor+dt
In-Reply-To: <20260718065900.755631-3-hrushirajg23@gmail.com>
> +&gmac {
> + assigned-clocks = <&cru SCLK_RMII_SRC>;
> + assigned-clock-parents = <&clkin_gmac>;
> + clock_in_out = "input";
> + phy-supply = <&vcc3v3_lan>;
> + /* TX/RX delays tuned for the Vaaman board PCB trace lengths */
> + phy-mode = "rgmii";
Please could you read:
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
and then expand the comment to explain in detail what is going on
here.
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_pins>;
> + snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> + snps,reset-active-low;
> + snps,reset-delays-us = <0 10000 50000>;
> + tx_delay = <0x28>;
> + rx_delay = <0x11>;
> + status = "okay";
> +};
I don't see a phy-handle here?
Andrew
^ permalink raw reply
* Re: [PATCH v7 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs
From: Marcelo Schmitt @ 2026-07-18 18:48 UTC (permalink / raw)
To: Jonathan Cameron
Cc: sashiko-reviews, Marcelo Schmitt, conor+dt, devicetree, robh,
linux-iio
In-Reply-To: <20260718024628.3e2872ca@jic23-huawei>
TL;DR: Will switch to voltageY-voltageZ ABI.
On 07/18, Jonathan Cameron wrote:
> On Fri, 17 Jul 2026 13:38:07 -0300
> Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
>
> > On 07/16, sashiko-bot@kernel.org wrote:
> > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > - [Medium] The `LTC2378_DIFF_CHANNEL` macro defines an IIO channel that is intended to be differential but lacks the `.differential = 1`, `.indexed = 1`, `.channel = 0`, and `.channel2 = 1` attributes.
> > > --
> > >
> > > --- Patch [2]: [PATCH v7 2/4] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs ---
> > > commit 5710d5f25b45906977e2522567c1964b1d3219f8
> > > Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > >
> > > iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs
> > >
> > > This commit adds a new driver for the Analog Devices LTC2378-20 and
> > > similar analog-to-digital converters.
> > >
> > > > diff --git a/drivers/iio/adc/ltc2378.c b/drivers/iio/adc/ltc2378.c
> > > > new file mode 100644
> > > > index 0000000000000..5600c820c7f45
> > > > --- /dev/null
> > > > +++ b/drivers/iio/adc/ltc2378.c
> > > > @@ -0,0 +1,416 @@
> > > [ ... ]
> > > > +#define LTC2378_DIFF_CHANNEL(_sign, _real_bits, _storage_bits) \
> > > > +{ \
> > > > + .type = IIO_VOLTAGE, \
> > > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> > > > + BIT(IIO_CHAN_INFO_SCALE), \
> > > > + .scan_index = 0, \
> > >
> > > [Severity: Medium]
> > > Does this macro need to set .differential = 1, .indexed = 1, .channel = 0,
> > > and .channel2 = 1? The name suggests these are differential channels, but
> > > without these attributes, the IIO ABI will expose them as single-ended
> > > (e.g., in_voltage_raw instead of in_voltage0-voltage1_raw).
> >
> > For parts with multiple inputs and configurable differential channels (e.g.
> > AD4130-8, MCP3561/2/4R, NAFE13388 [1, 2, 3]), the voltageY-voltageZ ABI helps
> > clarifying what physical inputs make up a channel. For differential only parts,
> > the ABI seems to be flexible by only requiring a 'consistent labeling' (either
> > voltageY or voltageY-voltageZ IIUC). Will set the channel with the differential
> > ABI if maintainers believe that's the best way to have it. Might slightly tweak
> > the channel macros to keep .differential = 0 for pseudo-differential chips
> > (e.g.LTC2369-18).
>
> Whilst I get your point on differential only cases not really requiring the
> specification of two inputs, I think that does provide a simple indication
> to users that they are differential channel.
Agree. The first ADCs I've worked with were single-ended so having to provide
the negative input when working with differential ones was something noticeable
to me. Though, one applications engineer once called me out for the
voltageY-voltageZ naming arguing that a differential channel provided only one
input to his application and thus it should be labeled only 'voltageY' or even
just 'voltage'. Despite understanding that argument, I share the opinion
that an indication of differential channel is helpful. Anyways, besides the
possibility for application to display channel names differently in user space,
I see we now have .read_label so the whole discussion seems pointless.
>
> I would prefer that we make them 'look' like differential channels so make up
> a suitable number for the negative side.
Would it make sense to adjust the ABI doc to encourage the dual numbering for
differential channels? So I don't fall the temptation of single index in the
future :)
Thanks,
Marcelo
^ permalink raw reply
* Re: [PATCH 3/5] usb: typec: mux: ps883x: refactor DP altmode handling and support TYPEC_DP_STATE_F
From: sashiko-bot @ 2026-07-18 17:29 UTC (permalink / raw)
To: Jens Glathe; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260718-ps883x-disable-usb4-v1-3-cec86d0b909e@oldschoolsolutions.biz>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Dereferencing NULL pointer during Thunderbolt Alt Mode teardown.
- [High] Failure to tear down DisplayPort Alt Mode correctly during SAFE state transition.
--
--- Patch [3]: [PATCH 3/5] usb: typec: mux: ps883x: refactor DP altmode handling and support TYPEC_DP_STATE_F ---
commit 1182bfe184aec8b5b6e514d7c1a3d153c73073da
Author: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
usb: typec: mux: ps883x: refactor DP altmode handling and support TYPEC_DP_STATE_F
This commit refactors DisplayPort altmode handling into a helper function.
It also adds support for the legacy TYPEC_DP_STATE_F mode to ensure DP
altmode works correctly on certain docks during Type-C fallback mode.
> diff --git a/drivers/usb/typec/mux/ps883x.c b/drivers/usb/typec/mux/ps883x.c
> index 3fa26ce01a9c9..3533d4f363286 100644
> --- a/drivers/usb/typec/mux/ps883x.c
> +++ b/drivers/usb/typec/mux/ps883x.c
[ ... ]
> @@ -188,6 +188,25 @@ static int ps883x_configure(struct ps883x_retimer *retimer, int cfg0,
> return 0;
> }
>
> +static void ps883x_apply_dp_altmode(int *cfg0, int *cfg1, int dp_state)
> +{
> + *cfg1 |= CONN_STATUS_1_DP_CONNECTED | CONN_STATUS_1_DP_HPD_LEVEL;
> +
> + switch (dp_state) {
[Severity: High]
This is a pre-existing issue, but does this correctly handle tearing down
the DisplayPort Alt Mode?
When the system requests TYPEC_STATE_SAFE (mode 0) to tear down the alt
mode, dp_state will be 0. It seems the CONN_STATUS_1_DP_CONNECTED and
CONN_STATUS_1_DP_HPD_LEVEL bits are unconditionally applied here, and the
switch statement hits the default empty case. Because state->alt is still
present, the retimer remains inappropriately configured for DisplayPort
instead of resetting.
> + case TYPEC_DP_STATE_D:
> + case TYPEC_DP_STATE_F:
> + *cfg0 |= CONN_STATUS_0_USB_3_1_CONNECTED;
> + fallthrough;
> + case TYPEC_DP_STATE_C:
> + case TYPEC_DP_STATE_E:
> + *cfg1 |= CONN_STATUS_1_DP_SINK_REQUESTED |
> + CONN_STATUS_1_DP_PIN_ASSIGNMENT_C_D;
> + break;
> + default:
> + break;
> + }
> +}
> +
> static int ps883x_set(struct ps883x_retimer *retimer, struct typec_retimer_state *state)
> {
> struct typec_thunderbolt_data *tb_data;
[ ... ]
> case USB_TYPEC_TBT_SID:
> tb_data = state->data;
> -
> /* Unconditional */
> cfg2 |= CONN_STATUS_2_TBT_CONNECTED;
>
[Severity: High]
This isn't a bug introduced by this patch, but will this cause a NULL
pointer dereference when a Thunderbolt device is unplugged?
During an active Thunderbolt device unplug, the Type-C bus core calls
typec_altmode_remove() which sets the state to TYPEC_STATE_SAFE and passes
NULL for state->data. Here in ps883x_set(), tb_data is assigned to
state->data and then unconditionally dereferenced just below this block for
tb_data->cable_mode, which seems like it would cause a kernel panic during
teardown.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-ps883x-disable-usb4-v1-0-cec86d0b909e@oldschoolsolutions.biz?part=3
^ permalink raw reply
* Re: [PATCH 5/5] arm64: dts: qcom: x1: disable ps883x USB4 capability
From: sashiko-bot @ 2026-07-18 17:22 UTC (permalink / raw)
To: Jens Glathe; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260718-ps883x-disable-usb4-v1-5-cec86d0b909e@oldschoolsolutions.biz>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The `parade,disable-usb4` property encodes a transient software workaround into the Device Tree and breaks non-fallback docks by intentionally failing retimer configuration.
--
--- Patch [5]: [PATCH 5/5] arm64: dts: qcom: x1: disable ps883x USB4 capability ---
commit c967f56ff3b6574dc86834616a0288179a8a0cd3
Author: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
arm64: dts: qcom: x1: disable ps883x USB4 capability
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.
[ ... ]
> 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;
[Severity: High]
The commit message mentions this is a temporary platform workaround for missing
software support. Does this encode a transient OS driver limitation into the
device tree?
Device trees typically describe fixed hardware capabilities. Will adding this
property permanently mask the hardware's actual capabilities and cause issues
for future OS updates once proper USB4 DP tunneling is available?
Also, looking at how the retimer driver handles this property:
drivers/usb/typec/mux/ps883x.c:ps883x_set() {
...
case TYPEC_MODE_USB4:
if (retimer->disable_usb4) {
dev_info(&retimer->client->dev,
"USB4 disabled via DT property, rejecting USB4 mode\n");
return -EOPNOTSUPP;
}
...
}
By returning -EOPNOTSUPP, this intentionally skips retimer configuration and
leaves the physical link broken. While some docks might detect the broken
link, time out, and fall back to DP Alt Mode + USB3, what happens with docks
that don't implement this fallback behavior?
Could this approach result in completely broken USB and DisplayPort
functionality on non-fallback docks when the PMIC autonomously negotiates
USB4?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-ps883x-disable-usb4-v1-0-cec86d0b909e@oldschoolsolutions.biz?part=5
^ permalink raw reply
* Re: [PATCH 2/5] usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set
From: sashiko-bot @ 2026-07-18 17:14 UTC (permalink / raw)
To: Jens Glathe; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260718-ps883x-disable-usb4-v1-2-cec86d0b909e@oldschoolsolutions.biz>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Encoding a temporary software workaround into the Device Tree using a custom property (`parade,disable-usb4`).
--
--- Patch [2]: [PATCH 2/5] usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set ---
commit e075e4adfa41dd9a2eea759527c1bbbc8a97f7a9
Author: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Subject: usb: typec: ps883x: Return -EOPNOTSUPP for USB4 when parade,disable-usb4 is set
This commit adds a temporary workaround to disable USB4 support on the
PS883x retimer using a new device tree property. It addresses an issue on
X1E80100 platforms where negotiating USB4 results in no DisplayPort output
due to missing software support in the qmp_combo PHY stack.
Link: https://patch.msgid.link/20260312101431.2375709-1-krishna.kurapati@oss.qualcomm.com
> 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
[ ... ]
> @@ -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;
> + }
[Severity: High]
Since the commit message notes this is a temporary workaround for missing OS
support in the X1E USB4 controller and PHY stack, does this approach conflict
with the principle that the device tree is a stable hardware description ABI?
If this workaround is deployed in user device trees or firmware, wouldn't
those boards permanently have USB4 disabled on this retimer even after the
kernel drivers are eventually updated to fully support it?
Could this be implemented as a software quirk instead, perhaps by matching
the platform's compatible string or inferring the limitation dynamically
from the dependent drivers, rather than altering the hardware description?
> +
> + /* 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);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-ps883x-disable-usb4-v1-0-cec86d0b909e@oldschoolsolutions.biz?part=2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox