* Re: [PATCH v2 20/21] dt-bindings: gpio: describe Waveshare GPIO controller
From: Dmitry Baryshkov @ 2026-04-13 0:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, dri-devel, devicetree,
linux-kernel, linux-gpio, Riccardo Mereu
In-Reply-To: <20260412-diligent-ginger-flamingo-f5059d@quoll>
On Sun, Apr 12, 2026 at 11:48:46AM +0200, Krzysztof Kozlowski wrote:
> On Sat, Apr 11, 2026 at 03:10:40PM +0300, Dmitry Baryshkov wrote:
> > The Waveshare DSI TOUCH family of panels has separate on-board GPIO
> > controller, which controls power supplies to the panel and the touch
> > screen and provides reset pins for both the panel and the touchscreen.
> > Also it provides a simple PWM controller for panel backlight.
> >
> > Add bindings for these GPIO controllers. As overall integration might be
> > not very obvious (and it differs significantly from the bindings used by
> > the original drivers), provide complete example with the on-board
> > regulators and the DSI panel.
> >
> > Tested-by: Riccardo Mereu <r.mereu@arduino.cc>
>
> You cannot test a binding, it is not possible. Otherwise explain me how
> did you copy it to the device and what sort of device runs YAML.
I'll drop it from the next iteration.
>
> The tag was given here explicitly, so I really do not understand this. I
> could imagine tags coming from a reply to the cover letter, but adding
> tag here? That's just fake test.
>
> Best regards,
> Krzysztof
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] dt-bindings: iio: light: Add PixArt PAJ7620 gesture sensor
From: Harpreet Saini @ 2026-04-13 0:02 UTC (permalink / raw)
To: jic23
Cc: Harpreet Saini, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Bjorn Andersson, Marek Vasut, Kael D'Alcamo, Lad Prabhakar,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260413000308.7618-1-sainiharpreet29.ref@yahoo.com>
Signed-off-by: Harpreet Saini <sainiharpreet29@yahoo.com>
---
This is part 1 of a 2-patch series proposing a driver for the PixArt
PAJ7620 gesture sensor. This patch adds the Device Tree bindings and
registers the "pixart" vendor prefix. The driver patch will follow in
a succeeding branch.
.../bindings/iio/light/pixart,paj7620.yaml | 48 +++++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
2 files changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/pixart,paj7620.yaml
diff --git a/Documentation/devicetree/bindings/iio/light/pixart,paj7620.yaml b/Documentation/devicetree/bindings/iio/light/pixart,paj7620.yaml
new file mode 100644
index 000000000000..301816485fcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/pixart,paj7620.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/pixart,paj7620.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PixArt PAJ7620 Gesture Sensor
+
+maintainers:
+ - Harpreet Saini <sainiharpreet29@yahoo.com>
+
+description: |
+ The PixArt PAJ7620 is a gesture recognition sensor with an integrated
+ infrared LED and CMOS array. It communicates over an I2C interface and
+ provides gesture data via a dedicated interrupt pin.
+
+properties:
+ compatible:
+ const: pixart,paj7620
+
+ reg:
+ maxItems: 1
+ description: The I2C address of the sensor.
+
+ interrupts:
+ maxItems: 1
+ description: Interrupt mapping for the sensor's physical INT pin.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ paj7620@73 {
+ compatible = "pixart,paj7620";
+ reg = <0x73>;
+ interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index ee7fd3cfe203..d73a0bf62b62 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1273,6 +1273,8 @@ patternProperties:
description: Pine64
"^pineriver,.*":
description: Shenzhen PineRiver Designs Co., Ltd.
+ "^pixart,.*":
+ description: PixArt Imaging Inc.
"^pixcir,.*":
description: PIXCIR MICROELECTRONICS Co., Ltd
"^plantower,.*":
--
2.43.0
^ permalink raw reply related
* RE: [PATCH v3 2/2] dt-bindings: leds: Document LTC3208 Multidisplay LED Driver
From: Roleda, Jan carlo @ 2026-04-12 23:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260407-outstanding-sceptical-giraffe-3fd6bb@quoll>
Hello Krzysztof,
Thank you again for the review.
For clarification,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Tuesday, April 7, 2026 2:58 PM
> To: Roleda, Jan carlo <Jancarlo.Roleda@analog.com>
> Cc: Lee Jones <lee@kernel.org>; Pavel Machek <pavel@kernel.org>; Rob
> Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor
> Dooley <conor+dt@kernel.org>; linux-kernel@vger.kernel.org; linux-
> leds@vger.kernel.org; devicetree@vger.kernel.org
> Subject: Re: [PATCH v3 2/2] dt-bindings: leds: Document LTC3208 Multidisplay
> LED Driver
>
> [External]
>
> On Mon, Apr 06, 2026 at 03:17:06PM +0800, Jan Carlo Roleda wrote:
> > Add Documentation for LTC3208 Multidisplay LED Driver.
> >
> > Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
> > ---
>
> Still incorrect order.
>
> ...
>
> > +
> > + led-controller@1b {
> > + compatible = "adi,ltc3208";
> > + reg = <0x1b>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + adi,disable-camhl-pin;
> > + adi,cfg-enrgbs-pin;
> > + adi,disable-rgb-aux4-dropout;
> > +
> > + led@0 {
> > + reg = <0>;
>
> I still expect this to be complete, so at least function and color.
>
> Best regards,
> Krzysztof
Are you referring here to keep the led@0-6,
but instead of only the reg I should include other LED properties (i.e. function and color)?
If so, I will add them as such in the next patch.
Do let me know if this is correct.
Regards,
Carlo
^ permalink raw reply
* RE: [PATCH v3 1/2] leds: ltc3208: add driver
From: Roleda, Jan carlo @ 2026-04-12 23:32 UTC (permalink / raw)
To: Lee Jones
Cc: Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <20260409165902.GB3439476@google.com>
Hello Jones,
Thank you again for the extensive reviews.
> -----Original Message-----
> From: Lee Jones <lee@kernel.org>
> Sent: Friday, April 10, 2026 12:59 AM
> To: Roleda, Jan carlo <Jancarlo.Roleda@analog.com>
> Cc: Pavel Machek <pavel@kernel.org>; Rob Herring <robh@kernel.org>;
> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley
> <conor+dt@kernel.org>; linux-kernel@vger.kernel.org; linux-
> leds@vger.kernel.org; devicetree@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] leds: ltc3208: add driver
>
> [External]
>
> "Add driver" is not a good subject line.
>
> > Kernel driver implementation for LTC3208 Multidisplay LED Driver
>
> A one line commit messages is not suitable fore a 300 line driver!
>
> What is the LTC3208 Multidisplay LED?
> What does it do?
> How does it operate?
> What's special about it?
> Any quirks?
I'll provide a more detailed commit description for next patch.
> > Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
> > ---
> > MAINTAINERS | 7 ++
> > drivers/leds/Kconfig | 11 ++
> > drivers/leds/Makefile | 1 +
> > drivers/leds/leds-ltc3208.c | 298
> > ++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 317 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 55af015174a5..48bae02057d5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15126,6 +15126,13 @@ W: https://ez.analog.com/linux-software-
> drivers
> > F: Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> > F: drivers/iio/temperature/ltc2983.c
> >
> > +LTC3208 LED DRIVER
> > +M: Jan Carlo Roleda <jancarlo.roleda@analog.com>
> > +L: linux-leds@vger.kernel.org
> > +S: Maintained
> > +W: https://ez.analog.com/linux-software-drivers
> > +F: drivers/leds/leds-ltc3208.c
> > +
> > LTC4282 HARDWARE MONITOR DRIVER
> > M: Nuno Sa <nuno.sa@analog.com>
> > L: linux-hwmon@vger.kernel.org
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index
> > 597d7a79c988..867b120ea8ba 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -1029,6 +1029,17 @@ config LEDS_ACER_A500
> > This option enables support for the Power Button LED of
> > Acer Iconia Tab A500.
> >
> > +config LEDS_LTC3208
> > + tristate "LED Driver for Analog Devices LTC3208"
> > + depends on LEDS_CLASS && I2C
> > + select REGMAP_I2C
> > + help
> > + Say Y to enable the LTC3208 LED driver.
> > + This supports the LED device LTC3208.
>
> You can do better!
>
> > + To compile this driver as a module, choose M here: the module will
> > + be called ltc3208.
> > +
> > source "drivers/leds/blink/Kconfig"
> >
> > comment "Flash and Torch LED drivers"
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index
> > 8fdb45d5b439..b08b539112b6 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -61,6 +61,7 @@ obj-$(CONFIG_LEDS_LP8788) += leds-
> lp8788.o
> > obj-$(CONFIG_LEDS_LP8860) += leds-lp8860.o
> > obj-$(CONFIG_LEDS_LP8864) += leds-lp8864.o
> > obj-$(CONFIG_LEDS_LT3593) += leds-lt3593.o
> > +obj-$(CONFIG_LEDS_LTC3208) += leds-ltc3208.o
> > obj-$(CONFIG_LEDS_MAX5970) += leds-max5970.o
> > obj-$(CONFIG_LEDS_MAX77650) += leds-max77650.o
> > obj-$(CONFIG_LEDS_MAX77705) += leds-max77705.o
> > diff --git a/drivers/leds/leds-ltc3208.c b/drivers/leds/leds-ltc3208.c
> > new file mode 100644 index 000000000000..65e65cd73d73
> > --- /dev/null
> > +++ b/drivers/leds/leds-ltc3208.c
> > @@ -0,0 +1,298 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * LED driver for Analog Devices LTC3208 Multi-Display Driver
> > + *
> > + * Copyright 2026 Analog Devices Inc.
> > + *
> > + * Author: Jan Carlo Roleda <jancarlo.roleda@analog.com> */ #include
> > +<linux/bitfield.h> #include <linux/errno.h> #include
> > +<linux/gpio/consumer.h> #include <linux/i2c.h> #include
> > +<linux/init.h> #include <linux/leds.h> #include
> > +<linux/mod_devicetable.h> #include <linux/module.h> #include
> > +<linux/platform_device.h> #include <linux/property.h> #include
> > +<linux/regmap.h> #include <linux/types.h> #include
> > +<linux/workqueue.h>
>
> Are all of these headers strictly necessary? For instance, it doesn't appear we
> are using GPIOs, platform devices, or workqueues in this driver.
>
> > +#define LTC3208_SET_HIGH_BYTE_DATA(x) FIELD_PREP(GENMASK(7, 4),
> (x))
Noted, I'll review the headers and remove unnecessary ones.
> > +
> > +/* Registers */
> > +#define LTC3208_REG_A_GRNRED 0x1 /* Green (High half-byte) and Red
> (Low half-byte) current DAC*/
> > +#define LTC3208_REG_B_AUXBLU 0x2 /* AUX (High half-byte) and Blue
> (Low half-byte) current DAC*/
> > +#define LTC3208_REG_C_MAIN 0x3 /* Main current DAC */
> > +#define LTC3208_REG_D_SUB 0x4 /* Sub current DAC */
> > +#define LTC3208_REG_E_AUX 0x5 /* AUX DAC Select */
> > +#define LTC3208_REG_F_CAM 0x6 /* CAM (High half-byte and Low
> half-byte) current DAC*/
> > +#define LTC3208_REG_G_OPT 0x7 /* Device Options */
> > +
> > +/* Device Options register */
> > +#define LTC3208_OPT_CPO_MASK GENMASK(7, 6)
> > +#define LTC3208_OPT_DIS_RGBDROP BIT(3)
> > +#define LTC3208_OPT_DIS_CAMHILO BIT(2)
> > +#define LTC3208_OPT_EN_RGBS BIT(1)
>
> Nit: This can look nicer nested:
>
> #define LTC3208_REG_A_GRNRED 0x1 /* Green (High half-byte)
> and Red (Low half-byte) current DAC*/
> #define LTC3208_REG_B_AUXBLU 0x2 /* AUX (High half-byte)
> and Blue (Low half-byte) current DAC*/
> #define LTC3208_REG_C_MAIN 0x3 /* Main current DAC */
> #define LTC3208_REG_D_SUB 0x4 /* Sub current DAC */
> #define LTC3208_REG_E_AUX 0x5 /* AUX DAC Select */
> #define LTC3208_AUX1_MASK GENMASK(1, 0)
> #define LTC3208_AUX2_MASK GENMASK(3, 2)
> #define LTC3208_AUX3_MASK GENMASK(5, 4)
> #define LTC3208_AUX4_MASK GENMASK(7, 6)
> #define LTC3208_REG_F_CAM 0x6 /* CAM (High half-byte and Low
> half-byte) current DAC*/
> #define LTC3208_REG_G_OPT 0x7 /* Device Options */
> #define LTC3208_OPT_CPO_MASK GENMASK(7, 6)
> #define LTC3208_OPT_DIS_RGBDROP BIT(3)
> #define LTC3208_OPT_DIS_CAMHILO BIT(2)
> #define LTC3208_OPT_EN_RGBS BIT(1)
>
Will follow this suggestion, thanks!
> > +#define LTC3208_MAX_BRIGHTNESS_4BIT 0xF #define
> > +LTC3208_MAX_BRIGHTNESS_8BIT 0xFF
> > +
> > +#define LTC3208_NUM_LED_GRPS 8
> > +#define LTC3208_NUM_AUX_LEDS 4
> > +
> > +#define LTC3208_NUM_AUX_OPT 4
> > +#define LTC3208_MAX_CPO_OPT 3
>
> Nit: Can we have _all_ of the values line up nicely?
>
> #define LTC3208_NUM_AUX_OPT 4
> #define LTC3208_MAX_CPO_OPT 3
>
Noted, will format this.
> > +enum ltc3208_aux_channel {
> > + LTC3208_AUX_CHAN_AUX = 0,
> > + LTC3208_AUX_CHAN_MAIN,
> > + LTC3208_AUX_CHAN_SUB,
> > + LTC3208_AUX_CHAN_CAM
> > +};
> > +
> > +enum ltc3208_channel {
> > + LTC3208_CHAN_MAIN = 0,
> > + LTC3208_CHAN_SUB,
> > + LTC3208_CHAN_AUX,
> > + LTC3208_CHAN_CAML,
> > + LTC3208_CHAN_CAMH,
> > + LTC3208_CHAN_RED,
> > + LTC3208_CHAN_BLUE,
> > + LTC3208_CHAN_GREEN
> > +};
> > +
> > +static const char * const ltc3208_dt_aux_channels[] = {
> > + "adi,aux1-channel", "adi,aux2-channel",
> > + "adi,aux3-channel", "adi,aux4-channel"
> > +};
> > +
> > +static const char * const ltc3208_aux_opt[] = {
> > + "aux", "main", "sub", "cam"
> > +};
> > +
> > +
>
> ?
>
> > +struct ltc3208_led {
> > + struct led_classdev cdev;
> > + struct i2c_client *client;
> > + enum ltc3208_channel channel;
> > +};
> > +
> > +struct ltc3208_dev {
> > + struct i2c_client *client;
> > + struct regmap *map;
> > + struct ltc3208_led *leds;
> > +};
> > +
> > +static const struct regmap_config ltc3208_regmap_cfg = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > +};
> > +
> > +static int ltc3208_led_set_brightness(struct led_classdev *led_cdev,
> > + enum led_brightness brightness) {
> > + struct ltc3208_led *led = container_of(led_cdev,
> > + struct ltc3208_led, cdev);
>
> You can use 100-chars to avoid this awkwardness.
>
Noted on this formatting.
> > + struct i2c_client *client = led->client;
> > + struct ltc3208_dev *dev = i2c_get_clientdata(client);
> > + struct regmap *map = dev->map;
> > + u8 current_level = brightness;
> > +
> > + /*
> > + * For registers with 4-bit splits (CAM, AUX/BLUE, GREEN/RED), the
> other
> > + * half of the byte will be retrieved from the stored DAC value before
> > + * updating the register.
> > + */
> > + switch (led->channel) {
> > + case LTC3208_CHAN_MAIN:
> > + return regmap_write(map, LTC3208_REG_C_MAIN,
> current_level);
> > + case LTC3208_CHAN_SUB:
> > + return regmap_write(map, LTC3208_REG_D_SUB,
> current_level);
> > + case LTC3208_CHAN_AUX:
> > + /* combine both low and high halves of byte */
> > + current_level =
> LTC3208_SET_HIGH_BYTE_DATA(current_level);
> > + current_level |= dev-
> >leds[LTC3208_CHAN_BLUE].cdev.brightness;
> > + return regmap_write(map, LTC3208_REG_B_AUXBLU,
> current_level);
>
> Should we be using 'regmap_update_bits()' or 'regmap_field' here instead?
> Constructing the register value by reading the software state of another LED
> instance could lead to races.
>
> > + case LTC3208_CHAN_BLUE:
> > + /* apply high bits stored in other led */
> > + current_level |= LTC3208_SET_HIGH_BYTE_DATA(dev-
> >leds[LTC3208_CHAN_AUX].cdev.brightness);
> > + return regmap_write(map, LTC3208_REG_B_AUXBLU,
> current_level);
> > + case LTC3208_CHAN_CAMH:
> > + current_level =
> LTC3208_SET_HIGH_BYTE_DATA(current_level);
> > + current_level |= dev-
> >leds[LTC3208_CHAN_CAML].cdev.brightness;
> > + return regmap_write(map, LTC3208_REG_F_CAM,
> current_level);
> > + case LTC3208_CHAN_CAML:
> > + current_level |= LTC3208_SET_HIGH_BYTE_DATA(dev-
> >leds[LTC3208_CHAN_CAMH].cdev.brightness);
> > + return regmap_write(map, LTC3208_REG_F_CAM,
> current_level);
> > + case LTC3208_CHAN_GREEN:
> > + current_level =
> LTC3208_SET_HIGH_BYTE_DATA(current_level);
> > + current_level |= dev-
> >leds[LTC3208_CHAN_RED].cdev.brightness;
> > + return regmap_write(map, LTC3208_REG_A_GRNRED,
> current_level);
> > + case LTC3208_CHAN_RED:
> > + current_level |= LTC3208_SET_HIGH_BYTE_DATA(dev-
> >leds[LTC3208_CHAN_GREEN].cdev.brightness);
> > + return regmap_write(map, LTC3208_REG_A_GRNRED,
> current_level);
>
> This lot is begging for a sub function:
>
> static int ltc3208_led_set_current_level(struct regmap *regmap, u8 reg, u8
> low, u8 high) { {
> return regmap_write(regmap, reg, SET_HIGH_BYTE(high) | low); }
>
Noted on this. Thank you for the suggestion!
> > + default:
> > + dev_err(&client->dev, "Invalid LED Channel\n");
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static int ltc3208_update_options(struct ltc3208_dev *dev,
> > + bool is_sub, bool is_cam_hi, bool
> is_rgb_drop) {
> > + struct regmap *map = dev->map;
> > + u8 val = FIELD_PREP(LTC3208_OPT_EN_RGBS, is_sub) |
> > + FIELD_PREP(LTC3208_OPT_DIS_CAMHILO, is_cam_hi)
> |
> > + FIELD_PREP(LTC3208_OPT_DIS_RGBDROP,
> is_rgb_drop);
> > +
>
> That tabbing is awkward. In these cases it's better to do the allocation after
> the declaration.
>
Noted on this.
> > + return regmap_write(map, LTC3208_REG_G_OPT, val); }
> > +
> > +static int ltc3208_update_aux_dac(struct ltc3208_dev *dev,
> > + enum ltc3208_aux_channel aux_1, enum ltc3208_aux_channel
> aux_2,
> > + enum ltc3208_aux_channel aux_3, enum ltc3208_aux_channel
> aux_4)
>
> These should sit under the '('.
>
> > +{
> > + struct regmap *map = dev->map;
> > + u8 val = FIELD_PREP(LTC3208_AUX1_MASK, aux_1) |
> > + FIELD_PREP(LTC3208_AUX2_MASK, aux_2) |
> > + FIELD_PREP(LTC3208_AUX3_MASK, aux_3) |
> > + FIELD_PREP(LTC3208_AUX4_MASK, aux_4);
>
> As above.
>
> > + return regmap_write(map, LTC3208_REG_E_AUX, val); }
> > +
> > +static int ltc3208_probe(struct i2c_client *client) {
> > + enum ltc3208_aux_channel
> aux_channels[LTC3208_NUM_AUX_LEDS];
> > + struct ltc3208_dev *data;
>
> 'data' is a terrible variable name.
>
> > + struct ltc3208_led *leds;
> > + struct regmap *map;
>
> 'regmap'
>
Will replace these variable names accordingly.
> > + int ret, i;
> > + u32 val;
> > + bool dropdis_rgb_aux4;
> > + bool dis_camhl;
> > + bool en_rgbs;
> > +
> > + map = devm_regmap_init_i2c(client, <c3208_regmap_cfg);
> > + if (IS_ERR(map))
> > + return dev_err_probe(&client->dev, PTR_ERR(map),
> > + "Failed to initialize regmap\n");
> > +
> > + data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + leds = devm_kcalloc(&client->dev, LTC3208_NUM_LED_GRPS,
> > + sizeof(struct ltc3208_led), GFP_KERNEL);
> > + if (!leds)
> > + return -ENOMEM;
> > +
> > + data->client = client;
> > + data->map = map;
> > +
> > + /* initialize options from devicetree */
>
> Capitalise comments and it's "Device Tree", although honestly, I think the
> whole comment is superfluous.
>
I'll omit this comment in that case.
> > + dis_camhl = device_property_read_bool(&client->dev,
> > + "adi,disable-camhl-pin");
> > + en_rgbs = device_property_read_bool(&client->dev,
> > + "adi,cfg-enrgbs-pin");
> > + dropdis_rgb_aux4 = device_property_read_bool(&client->dev,
> > + "adi,disable-rgb-aux4-
> dropout");
>
> Use 100-chars.
>
> > + ret = ltc3208_update_options(data, en_rgbs, dis_camhl,
> > + dropdis_rgb_aux4);
> > + if (ret)
> > + return dev_err_probe(&client->dev, ret,
> > + "error writing to options register\n");
>
> Capitalise.
>
> > + /* initialize aux channel configurations from devicetree */
>
> As above and throughout.
>
Noted.
> > + for (i = 0; i < LTC3208_NUM_AUX_LEDS; i++) {
>
> for (int i = 0; ...
>
Will update to this.
> > + ret = device_property_match_property_string(&client->dev,
> > +
> ltc3208_dt_aux_channels[i],
> > + ltc3208_aux_opt,
> > +
> LTC3208_NUM_AUX_OPT);
> > + /* use default value if absent in devicetree */
> > + if (ret == -EINVAL)
> > + aux_channels[i] = LTC3208_AUX_CHAN_AUX;
> > + else if (ret >= 0)
> > + aux_channels[i] = ret;
> > + else
> > + return dev_err_probe(&client->dev, ret,
> > + "Failed getting aux-channel.\n");
> > + }
> > +
> > + ret = ltc3208_update_aux_dac(data, aux_channels[0],
> aux_channels[1],
> > + aux_channels[2], aux_channels[3]);
>
> Why not just aux_channels and pull the values out in the function.
>
Noted. I'll update the function to use an array pointer instead.
> > + if (ret)
> > + return dev_err_probe(&client->dev, ret,
> > + "error writing to aux %u channel
> register.\n", i);
>
> When is 'i' not 'LTC3208_NUM_AUX_LEDS'?
>
My apologies for this, it seems like I misplaced this error message from a previous iteration.
I'll remove the reference to `i` as all 4 channels are written at the same time. In the above function.
> > + i2c_set_clientdata(client, data);
> > +
> > + device_for_each_child_node_scoped(&client->dev, child) {
> > + struct ltc3208_led *led;
> > + struct led_init_data init_data = {};
> > +
> > + ret = fwnode_property_read_u32(child, "reg", &val);
> > + if (ret || val >= LTC3208_NUM_LED_GRPS)
> > + return dev_err_probe(&client->dev, -EINVAL,
> > + "Invalid reg property for LED\n");
>
> Why aren't we propagating the real error?
>
I'll add the error code into the error strings.
> > +
> > + led = &leds[val];
> > + led->client = client;
> > + led->channel = val;
> > + led->cdev.brightness_set_blocking =
> ltc3208_led_set_brightness;
> > + led->cdev.max_brightness =
> LTC3208_MAX_BRIGHTNESS_4BIT;
> > + if (val == LTC3208_CHAN_MAIN || val ==
> LTC3208_CHAN_SUB)
> > + led->cdev.max_brightness =
> LTC3208_MAX_BRIGHTNESS_8BIT;
> > +
> > + init_data.fwnode = child;
> > +
> > + ret = devm_led_classdev_register_ext(&client->dev, &led-
> >cdev,
> > + &init_data);
> > + if (ret)
> > + return dev_err_probe(&client->dev, ret,
> > + "Failed to register LED %u\n", val);
> > + }
> > +
> > + data->leds = leds;
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id ltc3208_match_table[] = {
> > + {.compatible = "adi,ltc3208"},
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, ltc3208_match_table);
> > +
> > +static const struct i2c_device_id ltc3208_idtable[] = {
> > + { "ltc3208" },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, ltc3208_idtable);
> > +
> > +static struct i2c_driver ltc3208_driver = {
> > + .driver = {
> > + .name = "ltc3208",
> > + .of_match_table = ltc3208_match_table,
> > + },
> > + .id_table = ltc3208_idtable,
> > + .probe = ltc3208_probe,
> > +};
> > +module_i2c_driver(ltc3208_driver);
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Jan Carlo Roleda <jancarlo.roleda@analog.com>");
> > +MODULE_DESCRIPTION("LTC3208 LED Driver");
> >
> > --
> > 2.43.0
> >
>
> --
> Lee Jones [李琼斯]
I will submit another patch with your suggestions soon.
Regards,
Carlo
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] IPA v5.2 support
From: patchwork-bot+netdevbpf @ 2026-04-12 22:40 UTC (permalink / raw)
To: Luca Weiss
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, elder, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, netdev, devicetree, linux-kernel,
krzysztof.kozlowski, horms
In-Reply-To: <20260410-ipa-v5-2-v2-0-778422a05060@fairphone.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 09:40:06 +0200 you wrote:
> Add support for IPA v5.2 which can be found in the Milos SoC.
>
> Note: This series has been split up into two, one for net(-next), one
> for the qcom dts bits.
>
> Changes in v2:
> - Split the series, drop applied IPA fixes, mark as net-next
> - Pick up tags
> - Link to v1: https://patch.msgid.link/20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com
>
> [...]
Here is the summary with links:
- [net-next,v2,1/2] dt-bindings: net: qcom,ipa: add Milos compatible
https://git.kernel.org/netdev/net-next/c/d471d70cc964
- [net-next,v2,2/2] net: ipa: add IPA v5.2 configuration data
https://git.kernel.org/netdev/net-next/c/4bf38bac1b2e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v5 0/3] Add support for PIC64-HPSC/HX MDIO controller
From: patchwork-bot+netdevbpf @ 2026-04-12 21:50 UTC (permalink / raw)
To: Charles Perry
Cc: netdev, MameMaria.Mbaye, andrew+netdev, davem, edumazet, kuba,
pabeni, robh, krzk+dt, conor+dt, hkallweit1, linux, devicetree
In-Reply-To: <20260408131821.1145334-1-charles.perry@microchip.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 06:18:13 -0700 you wrote:
> Hello,
>
> This series adds a driver for the two MDIO controllers of PIC64-HPSC/HX.
> The hardware supports C22 and C45 but only C22 is implemented for now.
>
> This MDIO hardware is based on a Microsemi design supported in Linux by
> mdio-mscc-miim.c. However, The register interface is completely different
> with pic64hpsc, hence the need for a separate driver.
>
> [...]
Here is the summary with links:
- [net-next,v5,1/3] dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
https://git.kernel.org/netdev/net-next/c/268bb35d1a34
- [net-next,v5,2/3] net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
https://git.kernel.org/netdev/net-next/c/f76aef980206
- [net-next,v5,3/3] net: phy: add a PHY write barrier when disabling interrupts
https://git.kernel.org/netdev/net-next/c/96aefe3afe0e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 12/13] hwmon: spd5118: Add I3C support
From: Guenter Roeck @ 2026-04-12 21:26 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Akhil R, Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Philipp Zabel,
Eric Biggers, Sakari Ailus, Wolfram Sang, Miquel Raynal,
linux-i3c, devicetree, linux-kernel, linux-acpi, acpica-devel,
linux-hwmon
In-Reply-To: <20260412201629345ffec6@mail.local>
Hi Alexandre,
On 4/12/26 13:16, Alexandre Belloni wrote:
> On 09/04/2026 07:19:25-0700, Guenter Roeck wrote:
>> On 4/9/26 03:57, Akhil R wrote:
>>> Add a regmap config and a probe function to support for I3C based
>>> communication to SPD5118 devices.
>>>
>>> On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
>>> ACPI or device tree entry. The device matching is hence through the OF
>>> match tables only and do not need an I3C class match table. The device
>>> identity is verified in the type registers before proceeding to the
>>> common probe function.
>>>
>>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>>
>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>
>
> Guenter, I guess you can actually take 11/13 and 12/13 for 7.1 if you
> prefer as they don't seem to actually have any dependency on the
> previous patches. The worst that can happen is that the driver won't be
> probed because the I3C subsystem will not enumerate the device.
>
Thanks, but Linus released 7.0 today, and the 7.1 commit window is open,
so it is a bit late for adding content to it.
I can queue the patches for 7.2 after the commit window closes.
Guenter
^ permalink raw reply
* Re: [PATCH v3 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: David Heidelberg @ 2026-04-12 21:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel
In-Reply-To: <20260412-pixel3-camera-v3-1-e26b090a6110@ixit.cz>
On 12/04/2026 18:35, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> The Pixel 3 features two front-facing Sony IMX355 sensors with
> different focal lengths (standard and wide-angle).
>
> Both sensors are connected via CSIPHY1 and controlled over CCI I2C1,
> using MCLK2 as the clock source. Describe the camera nodes and
> associated resources in the device tree.
>
> This enables support for the dual front camera configuration.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 193 ++++++++++++++++++++-
> 1 file changed, 192 insertions(+), 1 deletion(-)
>
...
> - /* front camera, imx355 @1a */
> + front_cam: camera@10 {
> + compatible = "sony,imx355";
> + reg = <0x10>;
> +
> + clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
> + assigned-clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
> + /*
> + * The sensor can accept a 24 MHz clock, but 19.2 MHz has
> + * better driver compatibility.
> + */
> + assigned-clock-rates = <19200000>;
Currently I working on a patch which add 24 MHz to imx355, so this may not be
necessary.
Please wait with merging, after the patch gets tested also on Pixel 3a, I'll
send it :)
David
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: patchwork-bot+netdevbpf @ 2026-04-12 21:00 UTC (permalink / raw)
To: Josua Mayer
Cc: robh, krzk+dt, conor+dt, shawnguo, Frank.Li, s.hauer, kernel,
festevam, andrew, olteanv, davem, edumazet, kuba, pabeni,
yazan.shhady, mikhail.anikin, ada, devicetree, linux-kernel, imx,
linux-arm-kernel, vladimir.oltean, conor.dooley, krzk, netdev,
krzysztof.kozlowski
In-Reply-To: <20260409-imx8dxl-sr-som-v2-0-83ff20629ba0@solid-run.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 09 Apr 2026 14:34:32 +0200 you wrote:
> Add bindings and description for SolidRUn i.MX8DXL based SoM and
> HummingBoard Telematics.
>
> Modify SJA1110 Ethernet Switch bindings to allow SPI Mode 0.
>
> This patch-set is based on v7.0-rc2, because rc1 was experiencing
> deadlocks with imx8qxp clock driver.
>
> [...]
Here is the summary with links:
- [v2,1/3] dt-bindings: net: dsa: nxp,sja1105: make spi-cpol optional for sja1110
https://git.kernel.org/netdev/net-next/c/600f01dc4bd0
- [v2,2/3] dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
(no matching commit)
- [v2,3/3] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 04/13] i3c: master: Support ACPI enumeration of child devices
From: Alexandre Belloni @ 2026-04-12 20:18 UTC (permalink / raw)
To: Akhil R
Cc: frank.li, acpica-devel, conor+dt, devicetree, ebiggers, krzk+dt,
lenb, linux-acpi, linux-hwmon, linux-i3c, linux-kernel, linux,
miquel.raynal, p.zabel, rafael, robh, sakari.ailus, wsa+renesas
In-Reply-To: <20260410053147.27344-1-akhilrajeev@nvidia.com>
On 10/04/2026 11:01:47+0530, Akhil R wrote:
> On Thu, 9 Apr 2026 22:17:22 -0400, Frank Li wrote:
> > On Thu, Apr 09, 2026 at 04:27:34PM +0530, Akhil R wrote:
> >> Although the existing subsystem allows host controllers to register
> >> through the ACPI table, it was not possible to describe I3C or I2C
> >> devices when using ACPI. This is because the driver relied on reg
> >> property to retrieve the PID, static address etc whereas ACPI uses
> >> _ADR or serial resources to describe such devices.
> >>
> >> Read _ADR and LVR from the ACPI resources and extract the data as per the
> >> ACPI specification for an I3C bus. Also read mipi-i3c-static-address as
> >> per the MIPI DISCO specifications [1] to get the static address to be
> >> used. Hence enable describing the I3C or I2C devices in the ACPI
> >> table, which is required if the device is using a static address or if it
> >> needs some specific properties to be attached to it.
> >
> > Please wrap your commit message at 75 char.
>
> Ack. Will do.
>
> >
> >>
> >> [1] https://www.mipi.org/mipi-disco-for-i3c-download
> >>
> >> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> >> ---
> >> drivers/i3c/master.c | 140 ++++++++++++++++++++++++++++++++++++++++---
> >> 1 file changed, 132 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> >> index 5e0e926f61f3..08d0fcabd6f1 100644
> >> --- a/drivers/i3c/master.c
> >> +++ b/drivers/i3c/master.c
> >> @@ -5,6 +5,7 @@
> >> * Author: Boris Brezillon <boris.brezillon@bootlin.com>
> >> */
> >>
> >> +#include <linux/acpi.h>
> >> #include <linux/atomic.h>
> >> #include <linux/bug.h>
> >> #include <linux/device.h>
> >> @@ -2403,6 +2404,53 @@ EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
> >>
> >> #define OF_I3C_REG1_IS_I2C_DEV BIT(31)
> >>
> >> +#ifdef CONFIG_ACPI
> > ...
> >
> >> +#ifdef CONFIG_ACPI
> >> +static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
> >> + struct fwnode_handle *fwnode)
> >
> >
> > Can you move this and below function to previous #ifdef CONFIG_ACPI block.
>
> Ack. I will update, but there are some cross-dependencies. We may have to
> add a few function prototypes with the headers if we have to move these
> under the same block. Hope that is fine.
>
If you have cross-dependencies, then I guess they can sty separate
blocks.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 12/13] hwmon: spd5118: Add I3C support
From: Alexandre Belloni @ 2026-04-12 20:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: Akhil R, Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J . Wysocki, Robert Moore, Len Brown, Philipp Zabel,
Eric Biggers, Sakari Ailus, Wolfram Sang, Miquel Raynal,
linux-i3c, devicetree, linux-kernel, linux-acpi, acpica-devel,
linux-hwmon
In-Reply-To: <19218853-499c-46a2-8843-0bafa17c81d5@roeck-us.net>
On 09/04/2026 07:19:25-0700, Guenter Roeck wrote:
> On 4/9/26 03:57, Akhil R wrote:
> > Add a regmap config and a probe function to support for I3C based
> > communication to SPD5118 devices.
> >
> > On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
> > ACPI or device tree entry. The device matching is hence through the OF
> > match tables only and do not need an I3C class match table. The device
> > identity is verified in the type registers before proceeding to the
> > common probe function.
> >
> > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>
> Acked-by: Guenter Roeck <linux@roeck-us.net>
>
Guenter, I guess you can actually take 11/13 and 12/13 for 7.1 if you
prefer as they don't seem to actually have any dependency on the
previous patches. The worst that can happen is that the driver won't be
probed because the I3C subsystem will not enumerate the device.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 3/4] staging: iio: magnetometer: Add QST QMC5883P driver
From: David Lechner @ 2026-04-12 18:52 UTC (permalink / raw)
To: Hardik Phalet, Greg Kroah-Hartman
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Brigham Campbell, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-staging
In-Reply-To: <DHR32TA81G99.14OO5FKEDU8CB@pm.me>
On 4/12/26 4:54 AM, Hardik Phalet wrote:
> On Sat Apr 11, 2026 at 1:32 AM IST, David Lechner wrote:
>> On 4/9/26 4:07 PM, Hardik Phalet wrote:
>>
>> This is a little bit much to review all in one patch. Could be nice
>> to split out power management to a separate patch.
>>
...
>>> +static IIO_DEVICE_ATTR(downsampling_ratio, 0644, downsampling_ratio_show,
>>> + downsampling_ratio_store, 0);
>>> +static IIO_CONST_ATTR(downsampling_ratio_available, "1 2 4 8");
>>
>> As mentioned in the cover letter, we'd like to know more about what
>> this actually does. If there is a good reason it doesn't fit with
>> any existing filter attribute, then we'll need a patch to document
>> the sysfs ABI as well.
>>
> In the device datasheet, OSR2("Down sampling ratio") is mentioned like this:
> "Another filter is added for better noise performance; the depth can be
> adjusted through OSR2". OSR2's defintion is called "down sampling ratio"
> in a table. Nowhere else. I didn't know what attribute to map it to in
> this case.
>
I wonder if there is an application note or something that explains it
in more detail if the datasheet does not.
We could always omit the feature if no one knows what it actually does.
^ permalink raw reply
* Re: [PATCH RFC v2 8/9] Documentation: ABI: testing: add docs for ad9910 sysfs entries
From: David Lechner @ 2026-04-12 18:45 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar
Cc: Rodrigo Alencar via B4 Relay, rodrigo.alencar, linux-iio,
devicetree, linux-kernel, linux-doc, Lars-Peter Clausen,
Michael Hennerich, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan
In-Reply-To: <20260412155115.2f7a83bf@jic23-huawei>
On 4/12/26 9:51 AM, Jonathan Cameron wrote:
> On Mon, 23 Mar 2026 11:36:08 +0000
> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
>
>> On 26/03/22 05:22PM, Jonathan Cameron wrote:
>>> On Wed, 18 Mar 2026 17:56:08 +0000
>>> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
>>>
>>>> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>>>>
>>>> Add ABI documentation file for the DDS AD9910 with sysfs entries to
>>>> control Parallel Port, Digital Ramp Generator, RAM and OSK parameters.
>>>>
>>>> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
>>>> ---
>>
...
>>>
>>>> + - "ramp_down": No-dwell low; the ramp resets to upper
>>>> + limit upon reaching the lower limit.
>>>> + - "ramp_up": No-dwell high; the ramp resets to lower
>>>> + limit upon reaching the upper limit.
>>>> + - "bidirectional_continuous": Both no-dwell high and low;
>>>> + the ramp continuously sweeps without dwelling.
>>>
>>> Triangle wave? bidirectional continuous is a rather confusing term so maybe
>>> we should rethink this one.
>>
>> Mostly yes, but not only that. Sawtooth can be achieved as well by changing
>> the step sizes, also other weird patterns can be achieved by toggling DRCTL pin.
>
> Sawtooth is kind of a special triangle wave with one very steep side.
> Wikipedia even has: "It can also be considered the extreme case of an asymmetric triangle wave"
> https://en.wikipedia.org/wiki/Sawtooth_wave
>
>> This mode is the most useful when one does not have an FPGA and want to save
>> resources on controlling the DRCTL pin. That mode name comes from the datasheet,
>> so I suppose it was fine.
>
> Let us see if we can get more opinions on this. Whilst I can see the logic of
> the datasheet naming, it's a bit obscure.
>
It is the same as ramp_up and ramp_down other than what happens when it hits
the limit? If so, I would call it ramp_up_down.
^ permalink raw reply
* Re: [PATCH 2/2] soc: qcom: socinfo: Add SoC ID for SM7750
From: Krzysztof Kozlowski @ 2026-04-12 18:39 UTC (permalink / raw)
To: Alexander Koskovich, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260412-sm7550-id-v1-2-958a673ff791@pm.me>
On 12/04/2026 17:42, Alexander Koskovich wrote:
> Recognize the SM7750 SoC which is an Eliza SoC variant.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> drivers/soc/qcom/socinfo.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom,ids: Add SoC ID for SM7750
From: Krzysztof Kozlowski @ 2026-04-12 18:39 UTC (permalink / raw)
To: Alexander Koskovich, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260412-sm7550-id-v1-1-958a673ff791@pm.me>
On 12/04/2026 17:42, Alexander Koskovich wrote:
> Document the ID for SM7750, an Eliza SoC variant that can be found on
> the Nothing Phone (4a) Pro.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Mark Brown @ 2026-04-12 16:24 UTC (permalink / raw)
To: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Anushka Badhe
Cc: linux-sound, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260410055532.60868-1-anushkabadhe@gmail.com>
On Fri, 10 Apr 2026 11:25:32 +0530, Anushka Badhe wrote:
> ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1
Thanks!
[1/1] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
https://git.kernel.org/broonie/sound/c/115e7d764dad
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-channel ADC
From: Jonathan Cameron @ 2026-04-12 18:33 UTC (permalink / raw)
To: Antoniu Miclaus
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Olivier Moysan, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260328114050.46848-1-antoniu.miclaus@analog.com>
On Sat, 28 Mar 2026 13:40:47 +0200
Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:
> Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC with
> integrated fully differential amplifiers (FDA).
>
> Architecture notes:
>
> The AD4880 is modeled as a single IIO device rather than two independent
> devices because the channels share power supplies, a voltage reference,
> the CNV conversion clock, and a single interleaved data output stream.
> Splitting them into separate IIO devices would make synchronized
> dual-channel capture impossible from userspace.
>
> An MFD approach does not apply here either - the channels are not
> functionally distinct sub-devices but identical ADC paths sharing a
> common data interface.
>
> Each channel has fully independent configuration registers accessible
> through separate SPI chip selects, so per-channel regmaps are used with
> no locking between them. The data path has no software involvement at
> runtime: the CNV clock triggers simultaneous conversions and the device
> outputs an interleaved bitstream captured directly by the IIO backend
> (FPGA). spi_new_ancillary_device() handles the configuration path;
> the IIO backend handles the data path.
>
> The debugfs_reg_access callback is not exposed for the dual-channel
> variant since the IIO framework provides a single (reg, val) interface
> with no channel parameter, and exposing only one channel would be
> misleading.
>
> The AD4880 is a fairly unique part - having separate SPI config
> interfaces per channel with a shared interleaved data output is not
> a common pattern.
I tried applying this and it's not going in cleanly (I didn't check
exactly why). Please could you send a rebased version. The togreg
branch should be fine I think, but maybe sanity check it against
my current testing branch as well.
Whilst this driver is making a few more assumptions about the backend
than I'd ideally like, I think it is reasonable to postpone any handling
for truely separate backends until (maybe) someone needs it.
Thanks,
Jonathan
>
> Changes in v8:
> - Drop fwnode_handle cleanup patch (now in jic23/testing)
> - Clarify backend buffer comment to describe FPGA architecture
> (two axi_ad408x IP instances with a packer block)
> - Make filter_type a per-channel array instead of a single variable
> - Restore debugfs_reg_access for AD4880 (uses channel 0 regmap),
> based on sashiko's review
>
> Antoniu Miclaus (3):
> iio: backend: add devm_iio_backend_get_by_index()
> dt-bindings: iio: adc: ad4080: add AD4880 support
> iio: adc: ad4080: add support for AD4880 dual-channel ADC
>
> .../bindings/iio/adc/adi,ad4080.yaml | 53 +++-
> drivers/iio/adc/ad4080.c | 251 ++++++++++++++----
> drivers/iio/industrialio-backend.c | 53 ++--
> include/linux/iio/backend.h | 1 +
> 4 files changed, 282 insertions(+), 76 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v7 5/6] iio: adc: ad4691: add oversampling support
From: Jonathan Cameron @ 2026-04-12 17:58 UTC (permalink / raw)
To: David Lechner
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-pwm, linux-gpio,
linux-doc
In-Reply-To: <742b1821-9103-414e-a860-c2e8d5406e35@baylibre.com>
On Fri, 10 Apr 2026 16:15:20 -0500
David Lechner <dlechner@baylibre.com> wrote:
> On 4/9/26 10:28 AM, Radu Sabau via B4 Relay wrote:
> > From: Radu Sabau <radu.sabau@analog.com>
> >
> > Add per-channel oversampling ratio (OSR) support for CNV burst mode.
> > The accumulator depth register (ACC_DEPTH_IN) is programmed with the
> > selected OSR at buffer enable time and before each single-shot read.
> >
> > Supported OSR values: 1, 2, 4, 8, 16, 32.
> >
> > Introduce AD4691_MANUAL_CHANNEL() for manual mode channels, which do
> > not expose the oversampling ratio attribute since OSR is not applicable
> > in that mode. A separate manual_channels array is added to
> > struct ad4691_channel_info and selected at probe time; offload paths
> > reuse the same arrays with num_channels capping access before the soft
> > timestamp entry.
> >
> > The reported sampling frequency accounts for the active OSR:
> > effective_freq = oscillator_freq / osr
>
> Technically, the way this is implemented is fine according to IIO ABI
> rules. Writing any attribute can cause others to change. It does
> introduce a potential pitfall though. Currently, changing the OSR will
> change the sampling frequency, so you have to always write oversampling_ratio
> first, then write sampling_frequency to get what you asked for. If you want
> to change the OSR and keep the same sample rate, you still have to write both
> attributes again.
>
> In other drivers, I've implemented it so that the requested sampling frequency
> is stored any you always get the closest sampling frequency available based on
> the oversampling ratio. This way, it doesn't matter which order you write
> the attributes. In that case, the actual periodic trigger source isn't set up
> until we actually start sampling.
>
Agreed. This is more intuitive. Now generally the userspace should
be sanity checking the value anyway as limitations may mean the new
sampling frequency is not particularly close to the original one but
at least it increases the chances of getting the expected value somewhat!
So to me this is a nice useability improvement given the code to implement
it tends not to be too complex.
Thanks,
J
^ permalink raw reply
* Re: [PATCH 14/19] drm/panel: jadard-jd9365da-h3: support Waveshare DSI panels
From: Dmitry Baryshkov @ 2026-04-12 17:56 UTC (permalink / raw)
To: Linus Walleij
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Bartosz Golaszewski, dri-devel, devicetree, linux-kernel,
linux-gpio
In-Reply-To: <CAD++jLnXJKKv5ghRnCcMTU9g984seJAMHyL6VWWV0Bv+dv01wg@mail.gmail.com>
On Thu, 9 Apr 2026 at 11:50, Linus Walleij <linusw@kernel.org> wrote:
>
> On Thu, Apr 9, 2026 at 2:49 AM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> > > But there is also one more thing, this looks like a big "jam table"
> > > with just register+value tuples, so construct something like:
> > >
> > > struct jadard_jam_tbl_entry {
> > > u8 reg;
> > > u8 val;
> > > };
> > >
> > > static const struct jadard_jam_tbl_entry jd_3_4_c_init_jam[] = {
> > > {0x00, 0x00}, {0x01, 0x41}, ...};
> > >
> > > (Ideas taken from drivers/net/dsa/realtek/rtl8366rb.c, take a look
> > > for code and all, you get the picture.)
> >
> > Few months ago the code was moved exactly in the opposite direction. We
> > added all _multi() functions and made shure that the code is as
> > efficient as the register tables. On the other hand, having it as a code
> > allows better control. E.g. handling 2/4 lane case would require extra
> > hacks to the register tables, while the code handles that without extra
> > hacks and without loosing effectiveness.
>
> OK then sorry for the fuzz!
No worries, it's fine to explain it (and also sorry for me not being
able to answer your other questions).
> Reviewed-by: Linus Walleij <linusw@kernel.org>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 4/6] iio: adc: ad4691: add SPI offload support
From: Jonathan Cameron @ 2026-04-12 17:56 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260409-ad4692-multichannel-sar-adc-driver-v7-4-be375d4df2c5@analog.com>
On Thu, 09 Apr 2026 18:28:25 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add SPI offload support to enable DMA-based, CPU-independent data
> acquisition using the SPI Engine offload framework.
>
> When an SPI offload is available (devm_spi_offload_get() succeeds),
> the driver registers a DMA engine IIO buffer and uses dedicated buffer
> setup operations. If no offload is available the existing software
> triggered buffer path is used unchanged.
>
> Both CNV Burst Mode and Manual Mode support offload, but use different
> trigger mechanisms:
>
> CNV Burst Mode: the SPI Engine is triggered by the ADC's DATA_READY
> signal on the GP pin specified by the trigger-source consumer reference
> in the device tree (one cell = GP pin number 0-3). For this mode the
> driver acts as both an SPI offload consumer (DMA RX stream, message
> optimization) and a trigger source provider: it registers the
> GP/DATA_READY output via devm_spi_offload_trigger_register() so the
> offload framework can match the '#trigger-source-cells' phandle and
> automatically fire the SPI Engine DMA transfer at end-of-conversion.
>
> Manual Mode: the SPI Engine is triggered by a periodic trigger at
> the configured sampling frequency. The pre-built SPI message uses
> the pipelined CNV-on-CS protocol: N+1 16-bit transfers are issued
> for N active channels (the first result is discarded as garbage from
> the pipeline flush) and the remaining N results are captured by DMA.
>
> All offload transfers use 16-bit frames (bits_per_word=16, len=2).
> The channel scan_type (storagebits=16, shift=0, IIO_BE) is shared
> between the software triggered-buffer and offload paths; no separate
> scan_type or channel array is needed for the offload case. The
> ad4691_manual_channels[] array introduced in the triggered-buffer
> commit is reused here: it hides the IIO_CHAN_INFO_OVERSAMPLING_RATIO
> attribute, which is not applicable in Manual Mode.
>
> Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
A few comments inline.
> diff --git a/drivers/iio/adc/ad4691.c b/drivers/iio/adc/ad4691.c
> index 3e5caa0972eb..839ea7f44c78 100644
> --- a/drivers/iio/adc/ad4691.c
> +++ b/drivers/iio/adc/ad4691.c
> +
> +static int ad4691_cnv_burst_offload_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + struct ad4691_offload_state *offload = st->offload;
> + struct device *dev = regmap_get_device(st->regmap);
> + struct spi_device *spi = to_spi_device(dev);
> + struct spi_offload_trigger_config config = {
> + .type = SPI_OFFLOAD_TRIGGER_DATA_READY,
> + };
> + unsigned int n_active;
> + unsigned int bit, k;
> + int ret;
> +
> + n_active = bitmap_weight(indio_dev->active_scan_mask, iio_get_masklength(indio_dev));
> +
> + ret = regmap_write(st->regmap, AD4691_STD_SEQ_CONFIG,
> + bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)));
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG,
> + ~bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)) & GENMASK(15, 0));
This indent is hard to read. I would either use a local variable, or do it as
ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG,
~bitmap_read(indio_dev->active_scan_mask, 0,
iio_get_masklength(indio_dev)) &
GENMASK(15, 0));
> + if (ret)
> + return ret;
> +
> + ret = ad4691_enter_conversion_mode(st);
> + if (ret)
> + return ret;
> +
> + memset(st->scan_xfers, 0, sizeof(st->scan_xfers));
> +
> + /*
> + * Each AVG_IN register read uses two 16-bit transfers:
> + * TX: [reg_hi | 0x80, reg_lo] (address, CS stays asserted)
> + * RX: [data_hi, data_lo] (data, storagebits=16, shift=0)
> + * The state reset is also split into two 16-bit transfers
> + * (address then value) to keep bits_per_word uniform throughout.
> + */
> + k = 0;
> + iio_for_each_active_channel(indio_dev, bit) {
> + put_unaligned_be16(0x8000 | AD4691_AVG_IN(bit), offload->tx_cmd[k]);
> +
> + /* TX: address phase, CS stays asserted into data phase */
> + st->scan_xfers[2 * k].tx_buf = offload->tx_cmd[k];
> + st->scan_xfers[2 * k].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k].bits_per_word = AD4691_OFFLOAD_BITS_PER_WORD;
> +
> + /* RX: data phase, CS toggles after to delimit the next register op */
> + st->scan_xfers[2 * k + 1].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k + 1].bits_per_word = AD4691_OFFLOAD_BITS_PER_WORD;
> + st->scan_xfers[2 * k + 1].offload_flags = SPI_OFFLOAD_XFER_RX_STREAM;
> + st->scan_xfers[2 * k + 1].cs_change = 1;
> + k++;
> + }
> +
> + /* State reset to re-arm DATA_READY for the next scan. */
> + put_unaligned_be16(AD4691_STATE_RESET_REG, offload->tx_reset);
> + offload->tx_reset[2] = AD4691_STATE_RESET_ALL;
> +
> + st->scan_xfers[2 * k].tx_buf = offload->tx_reset;
> + st->scan_xfers[2 * k].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k].bits_per_word = AD4691_OFFLOAD_BITS_PER_WORD;
> +
> + st->scan_xfers[2 * k + 1].tx_buf = &offload->tx_reset[2];
> + st->scan_xfers[2 * k + 1].len = sizeof(offload->tx_cmd[k]);
> + st->scan_xfers[2 * k + 1].bits_per_word = AD4691_OFFLOAD_BITS_PER_WORD;
> + st->scan_xfers[2 * k + 1].cs_change = 1;
> +
> + spi_message_init_with_transfers(&st->scan_msg, st->scan_xfers, 2 * k + 2);
> + st->scan_msg.offload = offload->spi;
> +
> + ret = spi_optimize_message(spi, &st->scan_msg);
> + if (ret)
> + goto err_exit_conversion;
> +
> + ret = ad4691_sampling_enable(st, true);
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = spi_offload_trigger_enable(offload->spi, offload->trigger, &config);
> + if (ret)
> + goto err_sampling_disable;
> +
> + return 0;
> +
> +err_sampling_disable:
> + ad4691_sampling_enable(st, false);
> +err_unoptimize:
> + spi_unoptimize_message(&st->scan_msg);
> +err_exit_conversion:
> + ad4691_exit_conversion_mode(st);
> + return ret;
> +}
>
> static ssize_t sampling_frequency_store(struct device *dev,
> @@ -833,6 +1123,23 @@ static ssize_t sampling_frequency_store(struct device *dev,
> if (ret)
> return ret;
>
> + if (st->manual_mode && st->offload) {
> + struct spi_offload_trigger_config config = {
> + .type = SPI_OFFLOAD_TRIGGER_PERIODIC,
> + .periodic = { .frequency_hz = freq },
> + };
> +
> + ret = spi_offload_trigger_validate(st->offload->trigger, &config);
> + if (ret) {
> + iio_device_release_direct(indio_dev);
> + return ret;
> + }
> +
> + st->offload->trigger_hz = config.periodic.frequency_hz;
> + iio_device_release_direct(indio_dev);
This release in a different scope is a bit ugly.
Look at whether the auto cleanup approach works well here.
https://elixir.bootlin.com/linux/v7.0-rc7/source/include/linux/iio/iio.h#L767
> + return len;
> + }
> +
^ permalink raw reply
* Re: [PATCH v7 3/6] iio: adc: ad4691: add triggered buffer support
From: Jonathan Cameron @ 2026-04-12 17:47 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260409-ad4692-multichannel-sar-adc-driver-v7-3-be375d4df2c5@analog.com>
On Thu, 09 Apr 2026 18:28:24 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add buffered capture support using the IIO triggered buffer framework.
>
> CNV Burst Mode: the GP pin identified by interrupt-names in the device
> tree is configured as DATA_READY output. The IRQ handler stops
> conversions and fires the IIO trigger; the trigger handler executes a
> pre-built SPI message that reads all active channels from the AVG_IN
> accumulator registers and then resets accumulator state and restarts
> conversions for the next cycle.
>
> Manual Mode: CNV is tied to SPI CS so each transfer simultaneously
> reads the previous result and starts the next conversion (pipelined
> N+1 scheme). At preenable time a pre-built, optimised SPI message of
> N+1 transfers is constructed (N channel reads plus one NOOP to drain
> the pipeline). The trigger handler executes the message in a single
> spi_sync() call and collects the results. An external trigger (e.g.
> iio-trig-hrtimer) is required to drive the trigger at the desired
> sample rate.
>
> Both modes share the same trigger handler and push a complete scan —
> one u16 slot per channel at its scan_index position, followed by a
> timestamp — to the IIO buffer via iio_push_to_buffers_with_ts().
>
> The CNV Burst Mode sampling frequency (PWM period) is exposed as a
> buffer-level attribute via IIO_DEVICE_ATTR.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
A couple of minor things inline.
Thanks,
Jonathan
> diff --git a/drivers/iio/adc/ad4691.c b/drivers/iio/adc/ad4691.c
> index 43bd408c3d11..3e5caa0972eb 100644
> --- a/drivers/iio/adc/ad4691.c
> +++ b/drivers/iio/adc/ad4691.c
> @@ -5,15 +5,19 @@
> */
> #include <linux/array_size.h>
> #include <linux/bitfield.h>
> -#include <linux/bitops.h>
> +#include <linux/bitmap.h>
> #include <linux/cleanup.h>
> #include <linux/delay.h>
> #include <linux/dev_printk.h>
> #include <linux/device/devres.h>
> +#include <linux/dmaengine.h>
> #include <linux/err.h>
> +#include <linux/interrupt.h>
> #include <linux/math.h>
> #include <linux/module.h>
> #include <linux/mod_devicetable.h>
> +#include <linux/property.h>
> +#include <linux/pwm.h>
> #include <linux/regmap.h>
> #include <linux/regulator/consumer.h>
> #include <linux/reset.h>
> @@ -21,7 +25,14 @@
> #include <linux/units.h>
> #include <linux/unaligned.h>
>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/buffer-dma.h>
> +#include <linux/iio/buffer-dmaengine.h>
Not yet... Only bring these headers in when you need them.
So far this is just doing normal SPI stuff.
> #include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/triggered_buffer.h>
> +#include <linux/iio/trigger_consumer.h>
> @@ -201,8 +245,45 @@ struct ad4691_state {
> * atomicity of consecutive SPI operations.
> */
> struct mutex lock;
> + /*
> + * Per-buffer-enable lifetime resources:
> + * Manual Mode - a pre-built SPI message that clocks out N+1
> + * transfers in one go.
> + * CNV Burst Mode - a pre-built SPI message that clocks out 2*N
> + * transfers in one go.
> + */
> + struct spi_message scan_msg;
> + /* max 16 + 1 NOOP (manual) or 2*16 + 2 (CNV burst). */
> + struct spi_transfer scan_xfers[34];
> + /*
> + * CNV burst: 16 AVG_IN addresses + state-reset address + state-reset
> + * value = 18. Manual: 16 channel cmds + 1 NOOP = 17.
> + */
> + __be16 scan_tx[18];
David raised this. As these aren't going through the regmap and are using
spi_transfers directly they need to be using DMA safe buffers.
> + /* Scan buffer: one BE16 slot per channel (rx'd directly), plus timestamp */
> + struct {
> + __be16 vals[16];
> + aligned_s64 ts;
> + } scan;
> };
> +static int ad4691_manual_buffer_preenable(struct iio_dev *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + unsigned int n_active;
> + unsigned int n_xfers;
> + unsigned int prev_i, k, i;
> + bool first;
> + int ret;
> +
> + n_active = bitmap_weight(indio_dev->active_scan_mask, iio_get_masklength(indio_dev));
> + n_xfers = n_active + 1;
> +
> + memset(st->scan_xfers, 0, n_xfers * sizeof(st->scan_xfers[0]));
> + memset(st->scan_tx, 0, n_xfers * sizeof(st->scan_tx[0]));
> +
> + spi_message_init(&st->scan_msg);
> +
> + first = true;
> + prev_i = 0;
> + k = 0;
> + iio_for_each_active_channel(indio_dev, i) {
> + st->scan_tx[k] = cpu_to_be16(AD4691_ADC_CHAN(i));
> + st->scan_xfers[k].tx_buf = &st->scan_tx[k];
> + /*
> + * The pipeline means xfer[0] receives the residual from the
> + * previous sequence, not a valid sample for channel i. Point
> + * it at vals[i] anyway; xfer[1] (or the NOOP when only one
> + * channel is active) will overwrite that slot with the real
> + * result, so no separate dummy buffer is needed.
> + */
> + if (first) {
> + st->scan_xfers[k].rx_buf = &st->scan.vals[i];
> + first = false;
> + } else {
> + st->scan_xfers[k].rx_buf = &st->scan.vals[prev_i];
> + }
> + st->scan_xfers[k].len = sizeof(__be16);
> + st->scan_xfers[k].cs_change = 1;
> + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
> + prev_i = i;
> + k++;
> + }
> +
> + /* Final NOOP transfer retrieves the last channel's result. */
> + st->scan_xfers[k].tx_buf = &st->scan_tx[k]; /* scan_tx[k] == 0 == NOOP */
> + st->scan_xfers[k].rx_buf = &st->scan.vals[prev_i];
> + st->scan_xfers[k].len = sizeof(__be16);
> + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
> +
> + ret = spi_optimize_message(st->spi, &st->scan_msg);
> + if (ret)
See below. This matches my expectations for what to do if spi_optimize_message()
fails.
> + return ret;
> +
> + ret = ad4691_enter_conversion_mode(st);
> + if (ret) {
> + spi_unoptimize_message(&st->scan_msg);
> + return ret;
> + }
> +
> + return 0;
> +}
> +static int ad4691_cnv_burst_buffer_preenable(struct iio_dev *indio_dev)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> + unsigned int n_active;
> + unsigned int k, i;
> + int ret;
> +
> + n_active = bitmap_weight(indio_dev->active_scan_mask, iio_get_masklength(indio_dev));
> +
> + memset(st->scan_xfers, 0, (2 * n_active + 2) * sizeof(st->scan_xfers[0]));
> + memset(st->scan_tx, 0, (n_active + 2) * sizeof(st->scan_tx[0]));
> +
> + spi_message_init(&st->scan_msg);
> +
> + /*
> + * Each AVG_IN read needs two transfers: a 2-byte address write phase
> + * followed by a 2-byte data read phase. CS toggles between channels
> + * (cs_change=1 on the read phase of all but the last channel).
> + */
> + k = 0;
> + iio_for_each_active_channel(indio_dev, i) {
> + st->scan_tx[k] = cpu_to_be16(0x8000 | AD4691_AVG_IN(i));
> + st->scan_xfers[2 * k].tx_buf = &st->scan_tx[k];
> + st->scan_xfers[2 * k].len = sizeof(__be16);
> + spi_message_add_tail(&st->scan_xfers[2 * k], &st->scan_msg);
> + st->scan_xfers[2 * k + 1].rx_buf = &st->scan.vals[i];
> + st->scan_xfers[2 * k + 1].len = sizeof(__be16);
> + st->scan_xfers[2 * k + 1].cs_change = 1;
> + spi_message_add_tail(&st->scan_xfers[2 * k + 1], &st->scan_msg);
> + k++;
> + }
> +
> + st->scan_tx[k] = cpu_to_be16(AD4691_STATE_RESET_REG);
> + st->scan_xfers[2 * k].tx_buf = &st->scan_tx[k];
> + st->scan_xfers[2 * k].len = sizeof(__be16);
> + spi_message_add_tail(&st->scan_xfers[2 * k], &st->scan_msg);
> + st->scan_tx[k + 1] = cpu_to_be16(AD4691_STATE_RESET_ALL << 8);
> + st->scan_xfers[2 * k + 1].tx_buf = &st->scan_tx[k + 1];
> + st->scan_xfers[2 * k + 1].len = sizeof(__be16);
> + st->scan_xfers[2 * k + 1].cs_change = 1;
> + spi_message_add_tail(&st->scan_xfers[2 * k + 1], &st->scan_msg);
> +
> + ret = spi_optimize_message(st->spi, &st->scan_msg);
> + if (ret)
> + goto err_unoptimize;
I'd expect spi_optimize_message() to be side effect free if it fails.
I took a quick look at the implementation and it looks like it is..
So probably just return ret; here
That matches with the other similar flow above.
> +
> + ret = regmap_write(st->regmap, AD4691_STD_SEQ_CONFIG,
> + bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)));
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = regmap_write(st->regmap, AD4691_ACC_MASK_REG,
> + ~bitmap_read(indio_dev->active_scan_mask, 0,
> + iio_get_masklength(indio_dev)) & GENMASK(15, 0));
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = ad4691_enter_conversion_mode(st);
> + if (ret)
> + goto err_unoptimize;
> +
> + ret = ad4691_sampling_enable(st, true);
> + if (ret)
> + goto err_exit_conv;
> +
> + enable_irq(st->irq);
> + return 0;
> +
> +err_exit_conv:
> + ad4691_exit_conversion_mode(st);
> +err_unoptimize:
> + spi_unoptimize_message(&st->scan_msg);
> + return ret;
> +}
> +static int ad4691_setup_triggered_buffer(struct iio_dev *indio_dev,
> + struct ad4691_state *st)
> +{
> + struct device *dev = regmap_get_device(st->regmap);
> + struct iio_trigger *trig;
> + unsigned int i;
> + int irq, ret;
> +
> + trig = devm_iio_trigger_alloc(dev, "%s-dev%d",
> + indio_dev->name,
> + iio_device_id(indio_dev));
Might as well wrap this less.
> + if (!trig)
> + return -ENOMEM;
> +
^ permalink raw reply
* Re: [PATCH v7 3/6] iio: adc: ad4691: add triggered buffer support
From: Jonathan Cameron @ 2026-04-12 17:44 UTC (permalink / raw)
To: David Lechner
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-pwm, linux-gpio,
linux-doc
In-Reply-To: <20260412184301.05544396@jic23-huawei>
On Sun, 12 Apr 2026 18:43:01 +0100
Jonathan Cameron <jic23@kernel.org> wrote:
> On Fri, 10 Apr 2026 15:46:36 -0500
> David Lechner <dlechner@baylibre.com> wrote:
>
> > On 4/9/26 10:28 AM, Radu Sabau via B4 Relay wrote:
> > > From: Radu Sabau <radu.sabau@analog.com>
> > >
> > > Add buffered capture support using the IIO triggered buffer framework.
> > >
> >
> > ...
> >
> > > @@ -201,8 +245,45 @@ struct ad4691_state {
> > > * atomicity of consecutive SPI operations.
> > > */
> > > struct mutex lock;
> > > + /*
> > > + * Per-buffer-enable lifetime resources:
> > > + * Manual Mode - a pre-built SPI message that clocks out N+1
> > > + * transfers in one go.
> > > + * CNV Burst Mode - a pre-built SPI message that clocks out 2*N
> > > + * transfers in one go.
> > > + */
> > > + struct spi_message scan_msg;
> > > + /* max 16 + 1 NOOP (manual) or 2*16 + 2 (CNV burst). */
> > > + struct spi_transfer scan_xfers[34];
> > > + /*
> > > + * CNV burst: 16 AVG_IN addresses + state-reset address + state-reset
> > > + * value = 18. Manual: 16 channel cmds + 1 NOOP = 17.
> > > + */
> > > + __be16 scan_tx[18];
> >
> > Needs __aligned(IIO_DMA_MINALIGN) since it is used with SPI.
> As below.
> >
> > > + /* Scan buffer: one BE16 slot per channel (rx'd directly), plus timestamp */
> > > + struct {
> > > + __be16 vals[16];
> > > + aligned_s64 ts;
> > > + } scan;
> >
> > Unless it is required that all channels are always enabled:
> >
> > IIO_DECLARE_BUFFER_WITH_TS(__be16, scan_rx, 16);
> >
> > In any case, needs to be DMA-safe for SPI.
> Custom regmap that uses spi_write_then_read() for all cases so it
> should be bounced anyway.
>
> Perhaps a comment to that affect would be useful.
>
Ignore that. It's an optimized spi message. oops.
> J
>
^ permalink raw reply
* Re: [PATCH v7 3/6] iio: adc: ad4691: add triggered buffer support
From: Jonathan Cameron @ 2026-04-12 17:43 UTC (permalink / raw)
To: David Lechner
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-pwm, linux-gpio,
linux-doc
In-Reply-To: <0f05add7-96c0-4eee-b396-d6e1be904c09@baylibre.com>
On Fri, 10 Apr 2026 15:46:36 -0500
David Lechner <dlechner@baylibre.com> wrote:
> On 4/9/26 10:28 AM, Radu Sabau via B4 Relay wrote:
> > From: Radu Sabau <radu.sabau@analog.com>
> >
> > Add buffered capture support using the IIO triggered buffer framework.
> >
>
> ...
>
> > @@ -201,8 +245,45 @@ struct ad4691_state {
> > * atomicity of consecutive SPI operations.
> > */
> > struct mutex lock;
> > + /*
> > + * Per-buffer-enable lifetime resources:
> > + * Manual Mode - a pre-built SPI message that clocks out N+1
> > + * transfers in one go.
> > + * CNV Burst Mode - a pre-built SPI message that clocks out 2*N
> > + * transfers in one go.
> > + */
> > + struct spi_message scan_msg;
> > + /* max 16 + 1 NOOP (manual) or 2*16 + 2 (CNV burst). */
> > + struct spi_transfer scan_xfers[34];
> > + /*
> > + * CNV burst: 16 AVG_IN addresses + state-reset address + state-reset
> > + * value = 18. Manual: 16 channel cmds + 1 NOOP = 17.
> > + */
> > + __be16 scan_tx[18];
>
> Needs __aligned(IIO_DMA_MINALIGN) since it is used with SPI.
As below.
>
> > + /* Scan buffer: one BE16 slot per channel (rx'd directly), plus timestamp */
> > + struct {
> > + __be16 vals[16];
> > + aligned_s64 ts;
> > + } scan;
>
> Unless it is required that all channels are always enabled:
>
> IIO_DECLARE_BUFFER_WITH_TS(__be16, scan_rx, 16);
>
> In any case, needs to be DMA-safe for SPI.
Custom regmap that uses spi_write_then_read() for all cases so it
should be bounced anyway.
Perhaps a comment to that affect would be useful.
J
^ permalink raw reply
* [PATCH] arm: dts: allwinner: t113s mangopi: enable watchdog for reboot
From: Michal Piekos @ 2026-04-12 17:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
Michal Piekos
Reboot hangs on MangoPi MQ-R T113s because no restart handler is
available.
Enable the SoC watchdog whose driver registers a restart handler.
Tested on MangoPi MQ-R T113s.
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts b/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts
index 8b3a75383816..f0232a5e903b 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts
+++ b/arch/arm/boot/dts/allwinner/sun8i-t113s-mangopi-mq-r-t113.dts
@@ -33,3 +33,7 @@ rtl8189ftv: wifi@1 {
interrupt-names = "host-wake";
};
};
+
+&wdt {
+ status = "okay";
+};
---
base-commit: f5459048c38a00fc583658d6dcd0f894aff6df8f
change-id: 20260412-t113-mangopi-reboot-hang-c9a9def82e2b
Best regards,
--
Michal Piekos <michal.piekos@mmpsystems.pl>
^ permalink raw reply related
* [PATCH v3 2/2] drm/bridge: waveshare-dsi: support DSI LCD kits with LVDS panels
From: Dmitry Baryshkov @ 2026-04-12 17:32 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260412-ws-lcd-v3-0-db22c2631828@oss.qualcomm.com>
Several Waveshare DSI LCD kits use LVDS panels and the ICN6202 DSI2LVDS
bridge. Support that setup by handling waveshare,dsi2lvds compatible.
The only difference with the existing waveshare,dsi2dpi is the bridge's
output type (LVDS vs DPI).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/waveshare-dsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/waveshare-dsi.c b/drivers/gpu/drm/bridge/waveshare-dsi.c
index 32d40414adb9..ded57f298d64 100644
--- a/drivers/gpu/drm/bridge/waveshare-dsi.c
+++ b/drivers/gpu/drm/bridge/waveshare-dsi.c
@@ -177,7 +177,7 @@ static int ws_bridge_probe(struct i2c_client *i2c)
regmap_write(ws->reg_map, 0xc2, 0x01);
regmap_write(ws->reg_map, 0xac, 0x01);
- ws->bridge.type = DRM_MODE_CONNECTOR_DPI;
+ ws->bridge.type = (uintptr_t)i2c_get_match_data(i2c);
ws->bridge.of_node = dev->of_node;
devm_drm_bridge_add(dev, &ws->bridge);
@@ -185,7 +185,8 @@ static int ws_bridge_probe(struct i2c_client *i2c)
}
static const struct of_device_id ws_bridge_of_ids[] = {
- {.compatible = "waveshare,dsi2dpi",},
+ {.compatible = "waveshare,dsi2dpi", .data = (void *)DRM_MODE_CONNECTOR_DPI, },
+ {.compatible = "waveshare,dsi2lvds", .data = (void *)DRM_MODE_CONNECTOR_LVDS, },
{ }
};
--
2.47.3
^ 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