* Re: [PATCH V3 4/9] iio: imu: inv_icm42607: Add Buffer support functions to icm42607
From: Jonathan Cameron @ 2026-04-13 19:23 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: <20260330195853.392877-5-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:48 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add all FIFO parsing and reading functions to support
> inv_icm42607 hardware.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
A few minor things inline.
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 4 +
> .../imu/inv_icm42607/inv_icm42607_buffer.c | 496 ++++++++++++++++++
> .../imu/inv_icm42607/inv_icm42607_buffer.h | 98 ++++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 25 +
> 4 files changed, 623 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> index 7d13091aa8df..5530fd3bc03f 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> new file mode 100644
> index 000000000000..4f5f199586fc
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> @@ -0,0 +1,496 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/minmax.h>
> +#include <linux/mutex.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/delay.h>
> +
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/common/inv_sensors_timestamp.h>
> +#include <linux/iio/iio.h>
Alphabetical order (+ a block for IIO) for headers.
> +
> +static unsigned int inv_icm42607_wm_truncate(unsigned int watermark,
> + size_t packet_size)
> +{
> + size_t wm_size;
> + unsigned int wm;
> +
> + wm_size = watermark * packet_size;
> + if (wm_size > INV_ICM42607_FIFO_WATERMARK_MAX)
> + wm_size = INV_ICM42607_FIFO_WATERMARK_MAX;
> +
> + wm = wm_size / packet_size;
> +
> + return wm;
Why not
return wm_size / packet_size;
> +}
> +int inv_icm42607_buffer_hwfifo_flush(struct inv_icm42607_state *st,
> + unsigned int count)
> +{
> + s64 gyro_ts, accel_ts;
> + int ret;
> +
> + gyro_ts = iio_get_time_ns(st->indio_gyro);
> + accel_ts = iio_get_time_ns(st->indio_accel);
> +
> + ret = inv_icm42607_buffer_fifo_read(st, count);
> +
> + return ret;
Either
return inv_...
or
ret =
if (ret)
return ret;
return 0;
2nd one only if this is going to get more complex in later patches.
> +}
> +
> +int inv_icm42607_buffer_init(struct inv_icm42607_state *st)
> +{
> + unsigned int val;
> + int ret;
> +
> + st->fifo.watermark.eff_gyro = 1;
> + st->fifo.watermark.eff_accel = 1;
> +
> + /* Configure FIFO_COUNT format in bytes and big endian */
> + val = INV_ICM42607_INTF_CONFIG0_FIFO_COUNT_ENDIAN;
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + val, val);
regmap_set_bits();
> + if (ret)
> + return ret;
> +
> + /* Initialize FIFO in bypass mode */
> + return regmap_write(st->map, INV_ICM42607_REG_FIFO_CONFIG1,
> + INV_ICM42607_FIFO_CONFIG1_BYPASS);
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
> new file mode 100644
> index 000000000000..64a66c00a861
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
...
> +/* FIFO data packet */
> +struct inv_icm42607_fifo_sensor_data {
> + __be16 x;
> + __be16 y;
> + __be16 z;
> +} __packed;
Why packed? It will be anyway unless I'm missing something.
> +#define INV_ICM42607_FIFO_DATA_INVALID -32768
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index da04c820dab2..344071089042 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
...
> @@ -436,6 +449,8 @@ static int inv_icm42607_suspend(struct device *dev)
> static int inv_icm42607_resume(struct device *dev)
> {
> struct inv_icm42607_state *st = dev_get_drvdata(dev);
> + struct inv_icm42607_sensor_state *gyro_st = iio_priv(st->indio_gyro);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(st->indio_accel);
> struct device *accel_dev;
> bool wakeup;
> int ret;
> @@ -462,6 +477,16 @@ static int inv_icm42607_resume(struct device *dev)
> ret = inv_icm42607_set_pwr_mgmt0(st, st->suspended.gyro,
> st->suspended.accel,
> st->suspended.temp, NULL);
> + if (ret)
> + return ret;
> +
> + if (st->fifo.on) {
I've not checked, but if this doesn't get more complex you can do
if (!st->fifo.on)
return 0;
inv_....
return regmap_write();
> + inv_sensors_timestamp_reset(&gyro_st->ts);
> + inv_sensors_timestamp_reset(&accel_st->ts);
> + ret = regmap_write(st->map, INV_ICM42607_REG_FIFO_CONFIG1,
> + INV_ICM42607_FIFO_CONFIG1_MODE);
> + }
> +
> return ret;
> }
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: bcm4709: fix bus range assignment
From: Rosen Penev @ 2026-04-13 19:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, soc,
Arnd Bergmann, Broadcom internal kernel review list,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260413092148.3870746-1-arnd@kernel.org>
On Mon, Apr 13, 2026 at 2:21 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> The netgear r8000 dts file limits the bus range for the first host
> bridge to exclude bus 0, but the two devices on the first bus are
> explicitly assigned to bus 0, causing a build time warning:
>
> /home/arnd/arm-soc/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts:142.3-27: Warning (pci_device_bus_num): /axi@18000000/pcie@13000/pcie@0/pcie@0,0/pcie@1,0:bus-range: PCI bus number 0 out of range, expected (1 - 255)
> /home/arnd/arm-soc/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts:142.3-27: Warning (pci_device_bus_num): /axi@18000000/pcie@13000/pcie@0/pcie@0,0/pcie@2,0:bus-range: PCI bus number 0 out of range, expected (1 - 255)
>
> I could not find any reason why this is done in the first place, but
> this can be easily addressed by reassigning the two devices to
> bus 1, or by dropping the bus-range property in order to allow
> secondary bus 0 to be assigned.
>
> Assuming the bus-range is intentional, fix this by moving the
> devices to the first valid secondary bus number.
No, bus-range is not intentional. It should be removed instead.
>
> Fixes: 893faf67438c ("ARM: dts: BCM5301X: add root pcie bridges")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
> index d170c71cbd76..355be5014943 100644
> --- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
> @@ -147,7 +147,7 @@ pcie@0,0 {
>
> pcie@1,0 {
> device_type = "pci";
> - reg = <0x800 0 0 0 0>;
> + reg = <0x10800 0 0 0 0>;
>
> #address-cells = <3>;
> #size-cells = <2>;
> @@ -162,7 +162,7 @@ wifi@0,0 {
>
> pcie@2,0 {
> device_type = "pci";
> - reg = <0x1000 0 0 0 0>;
> + reg = <0x11000 0 0 0 0>;
>
> #address-cells = <3>;
> #size-cells = <2>;
> --
> 2.39.5
>
^ permalink raw reply
* Re: [PATCH V3 6/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: Jonathan Cameron @ 2026-04-13 19:32 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: <20260330195853.392877-7-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:50 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add icm42607 accelerometer sensor for icm42607.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
A few more things below.
thanks
Jonathan
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> new file mode 100644
> index 000000000000..58754af31100
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> +
> +static const struct iio_enum inv_icm42607_accel_power_mode_enum = {
> + .items = inv_icm42607_accel_power_mode_items,
> + .num_items = ARRAY_SIZE(inv_icm42607_accel_power_mode_items),
> + .set = inv_icm42607_accel_power_mode_set,
> + .get = inv_icm42607_accel_power_mode_get,
> +};
> +
> +static const struct iio_chan_spec_ext_info inv_icm42607_accel_ext_infos[] = {
> + IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, inv_icm42607_get_mount_matrix),
> + IIO_ENUM_AVAILABLE("power_mode", IIO_SHARED_BY_TYPE,
> + &inv_icm42607_accel_power_mode_enum),
> + IIO_ENUM("power_mode", IIO_SHARED_BY_TYPE,
> + &inv_icm42607_accel_power_mode_enum),
> + { },
No comma.
> +};
> +static int inv_icm42607_accel_read_odr(struct inv_icm42607_state *st,
> + int *val, int *val2)
> +{
> + unsigned int odr;
> + unsigned int i;
> +
> + odr = st->conf.accel.odr;
> +
> + for (i = 0; i < ARRAY_SIZE(inv_icm42607_accel_odr_conv); ++i) {
> + if (inv_icm42607_accel_odr_conv[i] == odr)
> + break;
> + }
> + if (i >= ARRAY_SIZE(inv_icm42607_accel_odr_conv))
> + return -EINVAL;
> +
> + *val = inv_icm42607_accel_odr[2 * i];
> + *val2 = inv_icm42607_accel_odr[2 * i + 1];
> +
> + return IIO_VAL_INT_PLUS_MICRO;
> +}
> +
> +static int inv_icm42607_accel_write_odr(struct iio_dev *indio_dev,
> + int val, int val2)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(indio_dev);
> + struct inv_sensors_timestamp *ts = &accel_st->ts;
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int idx;
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + int ret;
> +
> + for (idx = 0; idx < ARRAY_SIZE(inv_icm42607_accel_odr); idx += 2) {
> + if (val == inv_icm42607_accel_odr[idx] &&
> + val2 == inv_icm42607_accel_odr[idx + 1])
> + break;
> + }
> + if (idx >= ARRAY_SIZE(inv_icm42607_accel_odr))
> + return -EINVAL;
> +
> + conf.odr = inv_icm42607_accel_odr_conv[idx / 2];
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> + return -ENXIO;
> +
> + guard(mutex)(&st->lock);
> +
> + ret = inv_sensors_timestamp_update_odr(ts, inv_icm42607_odr_to_period(conf.odr),
> + iio_buffer_enabled(indio_dev));
> + if (ret)
> + return ret;
> +
> + ret = inv_icm42607_set_accel_conf(st, &conf, NULL);
> + if (ret)
> + return ret;
> +
> + inv_icm42607_buffer_update_fifo_period(st);
> + inv_icm42607_buffer_update_watermark(st);
> +
> + return ret;
> +}
> +
> +/*
> + * Calibration bias values, IIO range format int + micro.
> + * Not actually supported in the ICM-42607P registers.
> + */
> +static int inv_icm42607_accel_write_calibbias(struct inv_icm42607_state *st,
> + struct iio_chan_spec const *chan,
> + int val, int val2)
> +{
> + /* Not actually supported in the ICM-42607P registers */
> + return -EOPNOTSUPP;
> +}
> +
> +static int inv_icm42607_accel_read_calibbias(struct inv_icm42607_state *st,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2)
> +{
> + /* Not actually supported in the ICM-42607P registers */
> + return -EOPNOTSUPP;
> +}
> +
> +static int inv_icm42607_accel_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 data;
> + int ret;
> +
> + switch (chan->type) {
> + case IIO_ACCEL:
> + break;
> + case IIO_TEMP:
> + return inv_icm42607_temp_read_raw(indio_dev, chan, val, val2, mask);
> + default:
> + return -EINVAL;
> + }
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> + ret = inv_icm42607_accel_read_sensor(indio_dev, chan, &data);
> + iio_device_release_direct(indio_dev);
> + if (ret)
> + return ret;
> + *val = data;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + return inv_icm42607_accel_read_scale(indio_dev, val, val2);
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return inv_icm42607_accel_read_odr(st, val, val2);
> + case IIO_CHAN_INFO_CALIBBIAS:
> + return inv_icm42607_accel_read_calibbias(st, chan, val, val2);
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +int inv_icm42607_accel_parse_fifo(struct iio_dev *indio_dev)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(indio_dev);
> + struct inv_sensors_timestamp *ts = &accel_st->ts;
> + ssize_t i, size;
> + unsigned int no;
> + const void *accel, *gyro, *timestamp;
> + const int8_t *temp;
> + unsigned int odr;
> + int64_t ts_val;
> + struct inv_icm42607_accel_buffer buffer = { };
> +
> + /* parse all fifo packets */
> + for (i = 0, no = 0; i < st->fifo.count; i += size, ++no) {
> + size = inv_icm42607_fifo_decode_packet(&st->fifo.data[i],
> + &accel, &gyro, &temp, ×tamp, &odr);
> + /* quit if error or FIFO is empty */
> + if (size <= 0)
> + return size;
> +
> + /* skip packet if no accel data or data is invalid */
> + if (accel == NULL || !inv_icm42607_fifo_is_data_valid(accel))
> + continue;
> +
> + /* update odr */
> + if (odr & INV_ICM42607_SENSOR_ACCEL) {
> + inv_sensors_timestamp_apply_odr(ts, st->fifo.period,
> + st->fifo.nb.total, no);
> + }
> +
> + memcpy(&buffer.accel, accel, sizeof(buffer.accel));
> + /* convert 8 bits FIFO temperature in high resolution format */
> + buffer.temp = temp ? (*temp * 64) : 0;
> + ts_val = inv_sensors_timestamp_pop(ts);
> + iio_push_to_buffers_with_timestamp(indio_dev, &buffer, ts_val);
For new code, always use iio_push_to_buffers_with_ts()
This one is going away in near future.
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 735a262dc103..62a1371b0c4a 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +int inv_icm42607_set_accel_conf(struct inv_icm42607_state *st,
> + struct inv_icm42607_sensor_conf *conf,
> + unsigned int *sleep_ms)
> +{
> + struct inv_icm42607_sensor_conf *oldconf = &st->conf.accel;
> + unsigned int val;
> + int ret;
> +
> + if (conf->mode < 0)
> + conf->mode = oldconf->mode;
> + if (conf->fs < 0)
> + conf->fs = oldconf->fs;
> + if (conf->odr < 0)
> + conf->odr = oldconf->odr;
> + if (conf->filter < 0)
> + conf->filter = oldconf->filter;
> +
> + if (conf->fs != oldconf->fs || conf->odr != oldconf->odr) {
> + val = INV_ICM42607_ACCEL_CONFIG0_FS_SEL(conf->fs) |
> + INV_ICM42607_ACCEL_CONFIG0_ODR(conf->odr);
Another indent case that needs fixing.
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
> + if (ret)
> + return ret;
> + oldconf->fs = conf->fs;
> + oldconf->odr = conf->odr;
> + }
> +
> + if (conf->filter != oldconf->filter) {
> + if (conf->mode == INV_ICM42607_SENSOR_MODE_LOW_POWER) {
> + val = INV_ICM42607_ACCEL_CONFIG1_AVG(conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_AVG_MASK, val);
> + } else {
> + val = INV_ICM42607_ACCEL_CONFIG1_FILTER(conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK, val);
> + }
> + if (ret)
> + return ret;
> + oldconf->filter = conf->filter;
> + }
> +
> + return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode, conf->mode,
> + st->conf.temp_en, sleep_ms);
> +}
^ permalink raw reply
* Re: [PATCH RESEND] arm64: dts: apple: fix spelling error
From: Sven Peter @ 2026-04-13 19:36 UTC (permalink / raw)
To: Axel Flordal
Cc: Janne Grunau, asahi, Neal Gompa, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <2338500.vFx2qVVIhK@fedora>
On 08.04.26 09:21, Axel Flordal wrote:
> Change "configiguration" to "configuration".
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Axel Flordal <axel@flordal.net>
> ---
> Original patch: https://lore.kernel.org/asahi/CAEg-Je-KwNNGoi3mpPeNq3Jmtzj_5seuj1Qeh2_1dt994iCJSA@mail.gmail.com/T/#t
> If this is unwanted I of course won't send again.
No, this is perfectly fine. I just totally missed the patch, sorry about
that.
I'm going to pick it up after the merge window since it doesn't fix an
urgent bug!
Sven
^ permalink raw reply
* Re: [PATCH V3 7/9] iio: imu: inv_icm42607: Add Interrupt and Wake on Movement for icm42607
From: Jonathan Cameron @ 2026-04-13 19:37 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: <20260330195853.392877-8-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:51 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for wake on movement for the icm42607 driver.
>
> At this point the driver is usable as an accelerometer/temperature
> driver, so add the necessary Makefile and Kconfig changes as well.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>l
A few comments on this one.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> index 56bb09e2c304..f5f1b5fea183 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
...
>
> struct iio_dev *inv_icm42607_accel_init(struct inv_icm42607_state *st)
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 62a1371b0c4a..4ac3af52c1b8 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +
> +int inv_icm42607_disable_wom(struct inv_icm42607_state *st)
> +{
> + int ret;
> +
> + /* disable WoM interrupt */
> + ret = regmap_clear_bits(st->map, INV_ICM42607_REG_INT_SOURCE1,
> + INV_ICM42607_INT_SOURCE1_WOM_INT1_EN);
> + if (ret)
> + return ret;
> +
> + /* disable WoM hardware */
> + return regmap_clear_bits(st->map, INV_ICM42607_REG_WOM_CONFIG,
> + INV_ICM42607_WOM_CONFIG_EN);
regmap_set_bits()
> +}
> +
> +
As below.
> int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> +
> +/**
> + * inv_icm42607_irq_init() - initialize int pin and interrupt handler
> + * @st: driver internal state
> + * @irq: irq number
> + * @irq_type: irq trigger type
> + * @open_drain: true if irq is open drain, false for push-pull
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + */
> +static int inv_icm42607_irq_init(struct inv_icm42607_state *st, int irq,
> + int irq_type, bool open_drain)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int val = 0;
> + int ret;
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_RISING:
> + case IRQF_TRIGGER_HIGH:
> + val = INV_ICM42607_INT_CONFIG_INT1_ACTIVE_HIGH;
> + break;
> + default:
> + val = INV_ICM42607_INT_CONFIG_INT1_ACTIVE_LOW;
> + break;
> + }
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_LOW:
> + case IRQF_TRIGGER_HIGH:
> + val |= INV_ICM42607_INT_CONFIG_INT1_LATCHED;
> + break;
> + default:
> + break;
> + }
> +
> + if (!open_drain)
> + val |= INV_ICM42607_INT_CONFIG_INT1_PUSH_PULL;
> +
> + ret = regmap_write(st->map, INV_ICM42607_REG_INT_CONFIG, val);
> + if (ret)
> + return ret;
> +
> + irq_type |= IRQF_ONESHOT;
> + return devm_request_threaded_irq(dev, irq, inv_icm42607_irq_timestamp,
> + inv_icm42607_irq_handler, irq_type,
> + st->name, st);
> +}
> +
> +
Trivial but single line is always enough (in IIO anyway)
> static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
^ permalink raw reply
* Re: [PATCH V3 8/9] iio: imu: inv_icm42607: Add Gyroscope to icm42607
From: Jonathan Cameron @ 2026-04-13 19:39 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: <20260330195853.392877-9-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:52 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add gyroscope functions to the icm42607 driver.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
One very minor comment.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> new file mode 100644
> index 000000000000..80473c07c6a4
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> +
> +static const struct iio_chan_spec_ext_info inv_icm42607_gyro_ext_infos[] = {
> + IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, inv_icm42607_get_mount_matrix),
> + {},
{ }
> +};
^ permalink raw reply
* Re: Phandles
From: Kyle Bonnici @ 2026-04-13 20:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herve Codina, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <c0b93231-9337-42f9-83c3-e657e5f017ec@kernel.org>
> The "&foo" used in the property defines that it is phandle, no?
yes &foo is a phandle and must resolve to some node.
>
>>
>>> You asked why phandle has to be the first entry in phandle-value type? I
>>> responded that DT spec makes it.
>>
>> Which section in DTS 0.4 spec?
>
> 2.2.4.2. Property Values
> "That number is used for the value of properties with a phandle value type.
>
> The properties having phandle value must have proper, well, value :)
For a property to have type <phandle> it must either be of that types as
Defined dts spec 0.4 or a binding mandates that type.
>
>>
>>> We discuss DTC here, yes? Whether it has or has not a bug? Please help
>>> me to understand the topic. Why would we care about Zephyr's
>>> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
>>> am not saying that it is not important, just saying that I am not the
>>> audience to discuss it.
>>
>> I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
>> “cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”,
>> “msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”,
>> “clocks”, “sound_dai” and “thermal_sensors”
>> must follow <phandle cell …>.
>>
>> This is only mandated by the dt-schema as far as I understand, that is a used by
>> Linux, but not Zephyr and the DTC Making the assumption that this is true for
>> all systems
>
> No, dtschema is irrelevant here and DTC was validating it since 2017, so
> years before dtschema.
My point it that the DTC is overreaching IMO and validating property using
WARNING_PROPERTY_PHANDLE_CELLS that are not mandated by the
DTS Spec 0.4. This is leaking warnings into Zephyr and can lead a user to
believe, that Zephyr also interprets that property in the same way as the DTC
>
> DT spec indeed does not mandate it as pwms, but replacing that check in
> DTC with something only validating phandles would not solve your
> problem. Your 'pwm' is a phandle-value type, because you use phandle
> there, and still is has wrong value.
Do not take my code in the example too critically, that is just code to show
how to generate the warnings.
My point has been that in zephyr non of these properties should generate
Warnings generated by WARNING_PROPERTY_PHANDLE_CELLS
^ permalink raw reply
* Re: [PATCH v21 2/6] pwm: driver for qualcomm ipq6018 pwm block
From: Uwe Kleine-König @ 2026-04-13 20:27 UTC (permalink / raw)
To: George Moussalem
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pwm, devicetree, linux-kernel,
Devi Priya
In-Reply-To: <DS7PR19MB888389B41E784995F064EE0B9D242@DS7PR19MB8883.namprd19.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
Hello George,
On Mon, Apr 13, 2026 at 11:17:18PM +0400, George Moussalem wrote:
> On 4/13/2026 1:35 PM, Uwe Kleine-König wrote:
> > On Mon, Apr 06, 2026 at 10:24:39PM +0200, George Moussalem via B4 Relay wrote:
> >> From: Devi Priya <quic_devipriy@quicinc.com>
> >>
> >> Driver for the PWM block in Qualcomm IPQ6018 line of SoCs. Based on
> >> driver from downstream Codeaurora kernel tree. Removed support for older
> >> (V1) variants because I have no access to that hardware.
> >>
> >> Tested on IPQ5018 and IPQ6010 based hardware.
> >>
> >> Co-developed-by: Baruch Siach <baruch.siach@siklu.com>
> >> Signed-off-by: Baruch Siach <baruch.siach@siklu.com>
> >> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
> >> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> >> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> >
> > I have a few remaining nitpicks. If you're ok I'll squash the following
> > diff into this patch and apply it:
>
> Just applied it to my own branch, all okay from my side. Thanks for your
> guidance and support!
I did that and added a ; to make the compiler happy. It is now contained
at
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-nexxt
as 7.2-rc1 material. I'll push it into next after the merge window
closes in ~ two weeks.
Best regards and thanks for work
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 01/10] dt-bindings: clock: qcom,rpmcc: add msm8960 compatible
From: Antony Kurniawan Soemardi @ 2026-04-13 18:32 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-01c081e54610@smankusors.com>
Document the qcom,rpmcc-msm8960 compatible.
The MSM8960 platform shares the same RPM clock definitions as
APQ8064, so extend the existing conditional schema to treat
qcom,rpmcc-msm8960 the same as qcom,rpmcc-apq8064.
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index ab97d4b7dba8bc8d38903b399d2bd4bda087db8a..f84d08199e47f45ecb176d350eeb7df8c3ff506b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -36,6 +36,7 @@ properties:
- qcom,rpmcc-msm8937
- qcom,rpmcc-msm8940
- qcom,rpmcc-msm8953
+ - qcom,rpmcc-msm8960
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
- qcom,rpmcc-msm8992
@@ -90,7 +91,9 @@ allOf:
properties:
compatible:
contains:
- const: qcom,rpmcc-apq8064
+ enum:
+ - qcom,rpmcc-apq8064
+ - qcom,rpmcc-msm8960
then:
properties:
clocks:
--
2.34.1
^ permalink raw reply related
* [PATCH] arm64: dts: rockchip: Enable the NPU on rk3588-rock-5-itx
From: Sten-Silver Ots @ 2026-04-13 21:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sten-Silver Ots, FUKAUMI Naoki, Torsten Duwe, Dmitry Baryshkov,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
This commit enables the NPU on Radxa Rock 5 ITX board.
The regulator vdd_npu_s0 was already in place and since the NPUs
power domain supply is now described remove the always-on property
from the regulator.
Signed-off-by: Sten-Silver Ots <stensilver@gmail.com>
---
.../boot/dts/rockchip/rk3588-rock-5-itx.dts | 35 ++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
index de154adb1497..d3ab6c68a60b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
@@ -421,7 +421,6 @@ vdd_npu_s0: regulator@42 {
reg = <0x42>;
fcs,suspend-voltage-selector = <1>;
regulator-name = "vdd_npu_s0";
- regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
@@ -683,6 +682,10 @@ &pd_gpu {
domain-supply = <&vdd_gpu_s0>;
};
+&pd_npu {
+ domain-supply = <&vdd_npu_s0>;
+};
+
&pinctrl {
hym8563 {
rtc_int: rtc-int {
@@ -802,6 +805,36 @@ dp1_hpd: dp1-hpd {
};
};
+&rknn_core_0 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_1 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_2 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_mmu_0 {
+ status = "okay";
+};
+
+&rknn_mmu_1 {
+ status = "okay";
+};
+
+&rknn_mmu_2 {
+ status = "okay";
+};
+
&pwm14 {
pinctrl-names = "default";
pinctrl-0 = <&pwm14m1_pins>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] of/platform: Don't include reserved memory compatibles that aren't needed
From: Rob Herring @ 2026-04-13 22:00 UTC (permalink / raw)
To: Daniel Palmer; +Cc: Krzysztof Kozlowski, saravanak, devicetree, linux-kernel
In-Reply-To: <CAFr9PX=F3Qvyo25HwB139Jk4_+5Rw50GBg=3BJb6bcsk58tL=Q@mail.gmail.com>
On Sat, Apr 04, 2026 at 11:22:32AM +0900, Daniel Palmer wrote:
> Hi Krzysztof,
>
> On Wed, 1 Apr 2026 at 19:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Wed, Apr 01, 2026 at 06:57:35AM +0900, Daniel Palmer wrote:
> > > There are a number of very platform specific compatibles for reserved
> > > memory that the vast majority of people don't need and they waste
> > > 196/200 bytes each.
> >
> > We don't want #ifdefs in the code because they are more difficult to
> > maintain and review. Following your approach we would need to add such
> > ifdefs in multiple other places, so I am not convinced it is worth.
>
> I sort of disagree here. At the moment these compatibles are not
> coupled to the code that uses them at all.
> If that code gets deleted or moved for some reason, the Kconfig symbol
> they belong to will disappear but since these compatibles aren't
> coupled to them and are in a file on the other side of the kernel
> it'll be easy to miss them.
> If they are wrapped in something that links them back to where they
> are used grep or whatever indexer can spot them.
>
> > And this file should not be having different rules than rest of drivers.
>
> There are other places with #ifdefs in match tables. It would be nice
> if there was a nicer way to do it in C but there doesn't seem to be.
> It would be nice if vendor specific stuff wasn't in the core code but
> I don't see a nice way of fixing that either.
> And if you want to see some of the more crazy examples of match tables
> take a look here:
> https://elixir.bootlin.com/linux/v7.0-rc6/source/drivers/cpufreq/cpufreq-dt-platdev.c
>
> Since these matches are not the size of the compatible string but
> actually 200 bytes on 64 bit machines the two megatables in that
> driver will consume about 40K. It doesn't seem like much but DT is
> being used by systems that have megabytes of RAM like a RISC-V
> softcore on an FPGA. I think they might prefer to have a 40K of usable
> memory over 40K of tables that don't contain any values that are
> actually used on their machine ever... and it could be cleaned up
> easily by wrapping each of the vendor specific chunks in the Kconfig
> symbol for their platform.
40K is more convincing, but the case here isn't 40K.
Maybe we would be better off just creating a device for every reserved
memory node with a compatible which is what we do for the rest of the
DT. Then there's never any of these strings. It would only cost memory
if you have nodes with compatibles and you don't want a device created.
Looks like the only ones we have are the 2 NVIDIA ones.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: soc: move,rename google,gs101-pmu-intr-gen and add exynos850
From: Rob Herring (Arm) @ 2026-04-13 22:11 UTC (permalink / raw)
To: Alexey Klimov
Cc: linux-arm-kernel, linux-samsung-soc, Krzysztof Kozlowski,
devicetree, linux-kernel, Sam Protsenko, André Draszik,
Alim Akhtar, Peter Griffin, Tudor Ambarus, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-1-c5a760a3e259@linaro.org>
On Wed, 01 Apr 2026 05:51:54 +0100, Alexey Klimov wrote:
> The PMU interrupt generation block introduced for the Google GS101 is
> actually a standard Samsung Exynos IP block found in older SoCs, such
> as the Exynos850, and is not exclusive to Google SoCs. To accurately
> reflect its origin, move the schema file to under soc/samsung/
> directory and rename it.
> Concurrently, add the new "samsung,exynos850-pmu-intr-gen" compatible
> string to the bindings. Support for this block is required to enable
> power management features like CPU hotplug and idle states on Exynos850
> platforms.
> Also, move this file under Exynos850 SoC in MAINTAINERS entry.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> .../samsung,exynos850-pmu-intr-gen.yaml} | 8 +++++---
> MAINTAINERS | 2 +-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: soc: samsung: exynos-pmu: add samsung,pmu-intr-gen phandle
From: Rob Herring @ 2026-04-13 22:16 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin, André Draszik, Conor Dooley, Alim Akhtar,
Tudor Ambarus, Krzysztof Kozlowski, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-2-c5a760a3e259@linaro.org>
On Wed, Apr 01, 2026 at 05:51:55AM +0100, Alexey Klimov wrote:
> Some Exynos-based SoCs, for instance Exynos850, require access
> to the pmu interrupt generation register region which is exposed
> as a syscon. Update the exynos-pmu bindings documentation to
> reflect this.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> .../devicetree/bindings/soc/samsung/exynos-pmu.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> index 76ce7e98c10f..92acdfd5d44e 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> @@ -110,6 +110,11 @@ properties:
> description:
> Node for reboot method
>
> + samsung,pmu-intr-gen-syscon:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to PMU interrupt generation interface.
> +
> google,pmu-intr-gen-syscon:
Does this mean the driver is just going to have to look at both
properties for the same thing? If so, just use the existing property. We
don't need 2. Yeah, 'google' in Samsung SoCs is a bit weird, but that's
Samsung's fault for not upstreaming support for their h/w first.
Rob
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: soc: samsung: exynos-pmu: deprecate google,pmu-intr-gen-syscon
From: Rob Herring @ 2026-04-13 22:25 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin, André Draszik, Conor Dooley, Alim Akhtar,
Tudor Ambarus, Krzysztof Kozlowski, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-3-c5a760a3e259@linaro.org>
On Wed, Apr 01, 2026 at 05:51:56AM +0100, Alexey Klimov wrote:
> The generic property samsung,pmu-intr-gen-syscon should be used
> by default for Samsung Exynos PMU hardware blocks. Update binding
> document to add deprecated flag for google,pmu-intr-gen-syscon
> property.
> While at this, also add dependency to not allow usage of both
> above mentioned properties in the same time.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> index 92acdfd5d44e..1ff1a8729989 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> @@ -119,6 +119,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> Phandle to PMU interrupt generation interface.
> + deprecated: true
Deprecating doesn't really help. We still have to support both forever.
>
> required:
> - compatible
> @@ -207,6 +208,11 @@ allOf:
> properties:
> samsung,pmu-intr-gen-syscon: false
>
> +dependencies:
> + google,pmu-intr-gen-syscon:
> + not:
> + required: ['samsung,pmu-intr-gen-syscon']
Disallowing both means you couldn't update the DT in a compatible way
where you have both properties for some transistion period.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: qcom,pdc: document the Hawi Power Domain Controller
From: Rob Herring (Arm) @ 2026-04-13 22:25 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-kernel, devicetree,
Thomas Gleixner, Bjorn Andersson, Conor Dooley, Konrad Dybcio
In-Reply-To: <20260401125004.592925-1-mukesh.ojha@oss.qualcomm.com>
On Wed, 01 Apr 2026 18:20:04 +0530, Mukesh Ojha wrote:
> Document the Power Domain Controller on the Qualcomm Hawi SoC.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> .../devicetree/bindings/interrupt-controller/qcom,pdc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v3 09/11] dt-bindings: input: Document hid-over-spi DT schema
From: Rob Herring @ 2026-04-13 22:34 UTC (permalink / raw)
To: Conor Dooley, Dmitry Torokhov, Jingyuan Liang
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Krzysztof Kozlowski, Conor Dooley, linux-input, linux-doc,
linux-kernel, linux-spi, linux-trace-kernel, devicetree, hbarnor,
tfiga, Dmitry Antipov, Jarrett Schultz
In-Reply-To: <20260410-sake-dollop-9f253ddb0749@spud>
On Fri, Apr 10, 2026 at 06:35:00PM +0100, Conor Dooley wrote:
> On Thu, Apr 09, 2026 at 10:16:46AM -0700, Dmitry Torokhov wrote:
> > On Thu, Apr 09, 2026 at 05:02:11PM +0100, Conor Dooley wrote:
> > > On Thu, Apr 02, 2026 at 01:59:46AM +0000, Jingyuan Liang wrote:
> > > > Documentation describes the required and optional properties for
> > > > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > > > supports HID over SPI Protocol 1.0 specification.
> > > >
> > > > The properties are common to HID over SPI.
> > > >
> > > > Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> > > > Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> > > > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > > > ---
> > > > .../devicetree/bindings/input/hid-over-spi.yaml | 126 +++++++++++++++++++++
> > > > 1 file changed, 126 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > > new file mode 100644
> > > > index 000000000000..d1b0a2e26c32
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > > @@ -0,0 +1,126 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: HID over SPI Devices
> > > > +
> > > > +maintainers:
> > > > + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > + - Jiri Kosina <jkosina@suse.cz>
> > >
> > > Why them and not you, the developers of the series?
> > >
> > > > +
> > > > +description: |+
> > > > + HID over SPI provides support for various Human Interface Devices over the
> > > > + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> > > > + or sensors.
> > > > +
> > > > + The specification has been written by Microsoft and is currently available
> > > > + here: https://www.microsoft.com/en-us/download/details.aspx?id=103325
> > > > +
> > > > + If this binding is used, the kernel module spi-hid will handle the
> > > > + communication with the device and the generic hid core layer will handle the
> > > > + protocol.
> > >
> > > This is not relevant to the binding, please remove it.
> > >
> > > > +
> > > > +allOf:
> > > > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + oneOf:
> > > > + - items:
> > > > + - enum:
> > > > + - microsoft,g6-touch-digitizer
> > > > + - const: hid-over-spi
> > > > + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> > > > + const: hid-over-spi
> > >
> > > Why is it allowed but not recommended? Seems to me like we should
> > > require device-specific compatibles.
> >
> > Why would we want to change the driver code to add a new compatible each
> > time a vendor decides to create a chip that is fully hid-spi-protocol
> > compliant? Or is the plan to still allow "hid-over-spi" fallback but
> > require device-specific compatible that will be ignored unless there is
> > device-specific quirk needed?
The plan is the latter case (the 1st entry up above). The comment is
remove the 2nd entry (with 'Just "hid-over-spi" alone is allowed, but
not recommended.').
> This has nothing to do with the driver, just the oddity of having a
> comment saying that not having a device specific compatible was
> permitted by not recommended in a binding. Requiring device-specific
> compatibles is the norm after all and a comment like this makes draws
> more attention to the fact that this is abnormal. Regardless of what the
> driver does, device-specific compatibles should be required.
>
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + interrupts:
> > > > + maxItems: 1
> > > > +
> > > > + reset-gpios:
> > > > + maxItems: 1
> > > > + description:
> > > > + GPIO specifier for the digitizer's reset pin (active low). The line must
> > > > + be flagged with GPIO_ACTIVE_LOW.
> > > > +
> > > > + vdd-supply:
> > > > + description:
> > > > + Regulator for the VDD supply voltage.
> > > > +
> > > > + input-report-header-address:
> > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > + minimum: 0
> > > > + maximum: 0xffffff
> > > > + description:
> > > > + A value to be included in the Read Approval packet, listing an address of
> > > > + the input report header to be put on the SPI bus. This address has 24
> > > > + bits.
> > > > +
> > > > + input-report-body-address:
> > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > + minimum: 0
> > > > + maximum: 0xffffff
> > > > + description:
> > > > + A value to be included in the Read Approval packet, listing an address of
> > > > + the input report body to be put on the SPI bus. This address has 24 bits.
> > > > +
> > > > + output-report-address:
> > > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > > + minimum: 0
> > > > + maximum: 0xffffff
> > > > + description:
> > > > + A value to be included in the Output Report sent by the host, listing an
> > > > + address where the output report on the SPI bus is to be written to. This
> > > > + address has 24 bits.
> > > > +
> > > > + read-opcode:
> > > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > > + description:
> > > > + Value to be used in Read Approval packets. 1 byte.
> > > > +
> > > > + write-opcode:
> > > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > > + description:
> > > > + Value to be used in Write Approval packets. 1 byte.
> > >
> > > Why can none of these things be determined from the device's compatible?
> > > On the surface, they like the kinds of things that could/should be.
> >
> > Why would we want to keep tables of these values in the kernel and again
> > have to update the driver for each new chip?
>
> That's pretty normal though innit? It's what match data does.
> If someone wants to have properties that communicate data that
> can be determined from the compatible, they need to provide
> justification why it is being done.
IIRC, it was explained in prior versions the spec itself says these
values vary by device. If we expect variation, then I think these
properties are fine. But please capture the reasoning for them in this
patch or we will just keep asking the same questions over and over.
Rob
^ permalink raw reply
* Re: [PATCH net-next v3 0/9] net: dsa: add DSA support for the LAN9645x switch chip family
From: Jakub Kicinski @ 2026-04-13 22:47 UTC (permalink / raw)
To: Jens Emil Schulz Østergaard
Cc: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Woojung Huh, Russell King,
Steen Hegelund, Daniel Machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260410-dsa_lan9645x_switch_driver_base-v3-0-aadc8595306d@microchip.com>
On Fri, 10 Apr 2026 13:48:36 +0200 Jens Emil Schulz Østergaard wrote:
> This series provides the Microchip LAN9645X Switch driver.
>
> The LAN9645x is a family of chips with ethernet switch functionality and
> multiple peripheral functions. The switch delivers up to 9 ethernet
> ports and 12 Gbps switching bandwidth.
>
> The switch chip has 5 integrated copper PHYs, support for 2x RGMII
> interfaces, 2x SGMII and one QSGMII interface.
>
> The switch chip is from the same design architecture family as ocelot
> and lan966x, and the driver reflects this similarity. However, LAN9645x
> does not have an internal CPU in any package, and must be driven
> externally. For register IO it supports interfaces such as SPI, I2C and
> MDIO.
We're wrapping up the 7.1 PR and doesn't look like Vladimir (or any
other DSA expert) had a chance to review this yet, so let's defer to
the next cycle.
--
pw-bot: defer
^ permalink raw reply
* Re: [PATCH v2 1/6] ASoC: renesas: fsi: Add shared SPU clock support
From: Kuninori Morimoto @ 2026-04-14 0:02 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-2-phucduc.bui@gmail.com>
Hi
> Add SPU clock pointer, reference counter, and locking in fsi_master for
> shared FSIA/FSIB usage, and initialize them in fsi_probe().
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
(snip)
> diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
> index 1491c2f2cc96..196ec7bac33d 100644
> --- a/sound/soc/renesas/fsi.c
> +++ b/sound/soc/renesas/fsi.c
> @@ -292,8 +292,11 @@ struct fsi_master {
> void __iomem *base;
> struct fsi_priv fsia;
> struct fsi_priv fsib;
> + struct clk *clk_spu;
> const struct fsi_core *core;
> + int spu_count;
> spinlock_t lock;
> + struct mutex clk_lock;
> };
You added clk_spu in this patch, but not touched.
When I checked whole patch-set, you initialize it at [4/6], but [2/6] is
using it. Maybe it works, but is strange.
The total patch orders are opposite, I think.
I think it can be...
As prepare
- Fix trigger stop ordering
- move fsi_clk_init()
- this just moves the function, no change
As adding new feature
- remains
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 2/6] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Kuninori Morimoto @ 2026-04-14 0:27 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-3-phucduc.bui@gmail.com>
Hi
Hi
> Enable/disable the shared SPU clock in hw startup/shutdown. Without this,
> accessing FSI registers may hang the system.
>
> Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
(snip)
> @@ -1492,6 +1492,18 @@ static int fsi_hw_startup(struct fsi_priv *fsi,
> struct device *dev)
> {
> u32 data = 0;
> + int ret = 0;
> + /* enable spu clock */
> + mutex_lock(&fsi->master->clk_lock);
> + if (fsi->master->clk_spu && fsi->master->spu_count++ == 0) {
> + ret = clk_prepare_enable(fsi->master->clk_spu);
> + if (ret < 0) {
> + fsi->master->spu_count--;
> + mutex_unlock(&fsi->master->clk_lock);
> + return ret;
> + }
> + }
> + mutex_unlock(&fsi->master->clk_lock);
1st, please insert white line between "int ret = 0;" and "/* enable spu
clock */".
2nd, besically, FSI already has "lock", and using it for several protecting.
Please re-use it, and don't add random new-lock. It makes code confusable.
Then, please use guard().
3rd, I don't like above count inc/dec, and mutex_unlock() style, because
the code unnecessarily complicated. It can be...
int ret = 0;
if (master->clk_spu) {
guard(spinlock_irqsave)(&master->lock);
if (master->spu_count == 0)
ret = clk_prepare_enable(master->clk_spu);
master->spu_count++;
}
if (ret < 0)
return ret;
I'm not 100% sure, but I guess you need to count up spu_count anyway
regardless of clk_prepare_enable() result ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 3/6] ASoC: renesas: fsi: Fix trigger stop ordering
From: Kuninori Morimoto @ 2026-04-14 0:28 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-4-phucduc.bui@gmail.com>
Hi
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Reorder calls to execute fsi_stream_stop() before fsi_hw_shutdown().
> This ensures that all register accesses are completed before the clock is
> disabled, preventing the system hang observed on r8a7740.
>
> Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
This patch should appearing much earlier.
> sound/soc/renesas/fsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/renesas/fsi.c b/sound/soc/renesas/fsi.c
> index 109e06b5f32d..9df3e91ac79c 100644
> --- a/sound/soc/renesas/fsi.c
> +++ b/sound/soc/renesas/fsi.c
> @@ -1606,9 +1606,9 @@ static int fsi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
> ret = fsi_stream_transfer(io);
> break;
> case SNDRV_PCM_TRIGGER_STOP:
> + fsi_stream_stop(fsi, io);
> if (!ret)
> ret = fsi_hw_shutdown(fsi, dai->dev);
> - fsi_stream_stop(fsi, io);
> fsi_stream_quit(fsi, io);
> break;
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 4/6] ASoC: renesas: fsi: refactor clock initialization
From: Kuninori Morimoto @ 2026-04-14 0:51 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <20260413100700.30995-5-phucduc.bui@gmail.com>
Hi
> Move fsi_clk_init() out of set_fmt() and handle clock master logic
> internally. This simplifies the flow and aligns with probe-time
> initialization.
>
> Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
(snip)
> -/*
> - * clock function
> - */
> -static int fsi_clk_init(struct device *dev,
> - struct fsi_priv *fsi,
> - int xck,
> - int ick,
> - int div,
> - int (*set_rate)(struct device *dev,
> - struct fsi_priv *fsi))
I have mentioned in previous mail to just move fsi_clk_init(), but why do
you need to move it ? It works without any issue without moving function,
I guess ?
This patch 1) moves fsi_clk_init() 2) and update it. So there are too many
diffs. Difficult to review.
Note is that the comment /* clock function */ is not only for fsi_clk_init()
but for all fsi_clk_xxx() functions. Here is that position.
> @@ -1684,15 +1696,6 @@ static int fsi_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
> break;
> }
>
> - if (fsi_is_clk_master(fsi)) {
> - if (fsi->clk_cpg)
> - fsi_clk_init(dai->dev, fsi, 0, 1, 1,
> - fsi_clk_set_rate_cpg);
> - else
> - fsi_clk_init(dai->dev, fsi, 1, 1, 0,
> - fsi_clk_set_rate_external);
> - }
You removes fsi_is_clk_master() check in new fsi_clk_init() ?
> @@ -1992,6 +1995,7 @@ static int fsi_probe(struct platform_device *pdev)
> fsi->master = master;
> fsi_port_info_init(fsi, &info.port_a);
> fsi_handler_init(fsi, &info.port_a);
> + fsi_clk_init(&pdev->dev, fsi, !!(info.port_a.flags & SH_FSI_CLK_CPG));
> ret = fsi_stream_probe(fsi, &pdev->dev);
> if (ret < 0) {
> dev_err(&pdev->dev, "FSIA stream probe failed\n");
> @@ -2005,6 +2009,7 @@ static int fsi_probe(struct platform_device *pdev)
> fsi->master = master;
> fsi_port_info_init(fsi, &info.port_b);
> fsi_handler_init(fsi, &info.port_b);
> + fsi_clk_init(&pdev->dev, fsi, !!(info.port_b.flags & SH_FSI_CLK_CPG));
> ret = fsi_stream_probe(fsi, &pdev->dev);
> if (ret < 0) {
> dev_err(&pdev->dev, "FSIB stream probe failed\n");
Why don't use fsi->clk_cpg ? And why you need to call fsi_clk_init() twice ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: usb: dwc3: add support for StarFive JHB100
From: Thinh Nguyen @ 2026-04-14 1:00 UTC (permalink / raw)
To: Minda Chen
Cc: Conor Dooley, Greg Kroah-Hartman, Thinh Nguyen, Rob Herring,
Krzysztof Kozlowski, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <SHXPR01MB08631832A55ABCB54FE77273E6592@SHXPR01MB0863.CHNPR01.prod.partner.outlook.cn>
On Fri, Apr 10, 2026, Minda Chen wrote:
> Hi Thinh
> Could you review patch2? Just add a compatible to generic platform driver. Thanks
>
Done.
BR,
Thinh
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Shawn Guo @ 2026-04-14 1:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <d671229f-1c9f-470f-b1d1-7d015c0721e8@kernel.org>
On Mon, Apr 13, 2026 at 06:08:49PM +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 16:34, Shawn Guo wrote:
> > In short, there will be Nord DTS using the binding coming, and I do not
>
> Maybe there will, maybe there will not.
>
> > think posting them at the same time should be a requirement.
>
> Well, it is a requirement as I explained previously, said that
> *multiple* times on the mailing list, documented expectations in
> mentioned/linked email threads.
To be honest, I can only read the following from mentioned email
threads.
- Binding and DTS should be organized in separate series per subsystem
- DTS should reference binding series by a lore link
These are what I'm trying to do, and I'm not just posting DTS
simultaneously. I do not really read the requirement of posting
binding and DTS using it simultaneously from the email threads.
Taking a step back, even if the requirement is mentioned in an email
thread like this one, I'm not sure it's the correct or well received
way to define a requirement. And that might be why you had to keep
repeating yourself.
> It's also documented in submitting
> patches in DT (although not with that strong wording).
Either I'm blind or reading the wrong document. I failed to find
the requirement of posting binding and DTS using it simultaneously
in Documentation/devicetree/bindings/submitting-patches.rst. Could you
point it out explicitly?
Shawn
^ permalink raw reply
* [PATCH v2 1/2] ASoC: dt-bindings: ti,tas2781: Add TAS5832 support
From: Baojun Xu @ 2026-04-14 1:54 UTC (permalink / raw)
To: broonie, tiwai
Cc: andriy.shevchenko, 13916275206, shenghao-ding, baojun.xu,
linux-sound, linux-kernel, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, k-yi, henry.lo, robinchen, will-wang, jim.shil,
toastcheng, chinkaiting
TAS5832 is in same family with TAS5827/28/30.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
---
v2:
- No update.
---
Documentation/devicetree/bindings/sound/ti,tas2781.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
index f3a5638f4239..b21466bb0730 100644
--- a/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,tas2781.yaml
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-# Copyright (C) 2022 - 2025 Texas Instruments Incorporated
+# Copyright (C) 2022 - 2026 Texas Instruments Incorporated
%YAML 1.2
---
$id: http://devicetree.org/schemas/sound/ti,tas2781.yaml#
@@ -107,6 +107,9 @@ properties:
ti,tas5830: 65-W Stereo, Digital Input, High Efficiency Closed-Loop
Class-D Amplifier with Class-H Algorithm
+
+ ti,tas5832: 81-W Stereo, Digital Input, High Efficiency Closed-Loop
+ Class-D Amplifier with Class-H Algorithm
oneOf:
- items:
- enum:
@@ -128,6 +131,7 @@ properties:
- ti,tas5827
- ti,tas5828
- ti,tas5830
+ - ti,tas5832
- const: ti,tas2781
- enum:
- ti,tas2781
@@ -264,6 +268,7 @@ allOf:
- ti,tas5827
- ti,tas5828
- ti,tas5830
+ - ti,tas5832
then:
properties:
reg:
--
2.25.1
^ permalink raw reply related
* [PATCH v2 2/2] ASoC: tas2781: Add tas5832 support
From: Baojun Xu @ 2026-04-14 1:54 UTC (permalink / raw)
To: broonie, tiwai
Cc: andriy.shevchenko, 13916275206, shenghao-ding, baojun.xu,
linux-sound, linux-kernel, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, k-yi, henry.lo, robinchen, will-wang, jim.shil,
toastcheng, chinkaiting
In-Reply-To: <20260414015441.2439-1-baojun.xu@ti.com>
TAS5832 is in same family with TAS5827/28/30.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
---
v2:
- Follow the updated association protocol based on device name and id.
---
include/sound/tas2781.h | 1 +
sound/soc/codecs/tas2781-i2c.c | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/include/sound/tas2781.h b/include/sound/tas2781.h
index e847cf51878c..95296bb4a33a 100644
--- a/include/sound/tas2781.h
+++ b/include/sound/tas2781.h
@@ -131,6 +131,7 @@ enum audio_device {
TAS5827,
TAS5828,
TAS5830,
+ TAS5832,
TAS_OTHERS,
};
diff --git a/sound/soc/codecs/tas2781-i2c.c b/sound/soc/codecs/tas2781-i2c.c
index c593f9da0c5b..86b591c489c2 100644
--- a/sound/soc/codecs/tas2781-i2c.c
+++ b/sound/soc/codecs/tas2781-i2c.c
@@ -119,6 +119,7 @@ static const struct i2c_device_id tasdevice_id[] = {
{ "tas5827", TAS5827 },
{ "tas5828", TAS5828 },
{ "tas5830", TAS5830 },
+ { "tas5832", TAS5832 },
{}
};
@@ -143,6 +144,7 @@ static const struct of_device_id tasdevice_of_match[] = {
{ .compatible = "ti,tas5827", .data = &tasdevice_id[TAS5827] },
{ .compatible = "ti,tas5828", .data = &tasdevice_id[TAS5828] },
{ .compatible = "ti,tas5830", .data = &tasdevice_id[TAS5830] },
+ { .compatible = "ti,tas5832", .data = &tasdevice_id[TAS5832] },
{},
};
MODULE_DEVICE_TABLE(of, tasdevice_of_match);
@@ -1746,6 +1748,7 @@ static void tasdevice_fw_ready(const struct firmware *fmw,
case TAS5827:
case TAS5828:
case TAS5830:
+ case TAS5832:
/* If DSP FW fail, DSP kcontrol won't be created. */
tasdevice_dsp_remove(tas_priv);
}
@@ -1917,6 +1920,7 @@ static int tasdevice_codec_probe(struct snd_soc_component *codec)
case TAS5827:
case TAS5828:
case TAS5830:
+ case TAS5832:
p = (struct snd_kcontrol_new *)tas5825_snd_controls;
size = ARRAY_SIZE(tas5825_snd_controls);
break;
@@ -2104,6 +2108,7 @@ static const struct acpi_device_id tasdevice_acpi_match[] = {
{ "TXNW5827", (kernel_ulong_t)&tasdevice_id[TAS5827] },
{ "TXNW5828", (kernel_ulong_t)&tasdevice_id[TAS5828] },
{ "TXNW5830", (kernel_ulong_t)&tasdevice_id[TAS5830] },
+ { "TXNW5832", (kernel_ulong_t)&tasdevice_id[TAS5832] },
{},
};
--
2.25.1
^ 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