* RE: [PATCH v4 3/5] rtc: pcf85363: add timestamp support with configurable timestamp mode
From: Lakshay Piplani @ 2026-06-15 6:23 UTC (permalink / raw)
To: Lakshay Piplani, alexandre.belloni@bootlin.com,
linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-watchdog@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain
In-Reply-To: <20251121121137.3043764-3-lakshay.piplani@nxp.com>
> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Friday, November 21, 2025 5:42 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org; wim@linux-watchdog.org;
> linux@roeck-us.net; linux-watchdog@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>
> Subject: [PATCH v4 3/5] rtc: pcf85363: add timestamp support with
> configurable timestamp mode
>
> Add support for the timestamp capture registers available on PCF85263 and
> PCF85363. The registers latch the current time when selected events occur,
> such as TS pin activation or battery switch-over.
>
> The capture source can be configured via the nxp,timestamp-mode device tree
> property, and latched values are exported through read-only sysfs attributes.
>
> Additionally:
> - Use rtc_add_group() instead of sysfs_create_group() to register the
> timestamp attributes under the RTC class device (/sys/class/rtc/rtcX).
> - Perform minor cleanups in the probe function for better readability.
>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V3 -> V4:
> - No changes in v4.
> V2 -> V3:
> - Split into separate patches as suggested:
> - Battery switch-over detection.
> - Timestamp recording for TS pin and battery switch-over events.
> - Offset calibration.
> - Watchdog timer (to be reviewed by watchdog maintainers).
> - Dropped Alarm2 support
> - Switched to rtc_add_group() for sysfs attributes
> V1 -> V2:
> - Watchdog related changes due to removal of vendor specific properties
> from device tree
> * remove vendor DT knobs (enable/timeout/stepsize/repeat)
> * use watchdog_init_timeout (with 10s default)
> * derive clock_sel from final timeout
> * default, repeat=true (repeat mode)
> - Fixed uninitalised warning on 'ret' (reported by kernel test robot)
> - Use dev_dbg instead of dev_info for debug related print messages
> - Minor cleanup and comments.
>
> drivers/rtc/rtc-pcf85363.c | 209 +++++++++++++++++++++++++++++++------
> 1 file changed, 175 insertions(+), 34 deletions(-)
Hi,
I hope you're doing well.
This is a gentle follow-up regarding the v4 patch series for the PCF85363 RTC driver that I submitted in November 2025.
I understand things can get busy, but I haven't seen any feedback on the series yet, so I wanted to check if you've had a chance to review it.
I'd be happy to make any updates if needed. Please let me know if there's anything required from my side to move this forward.
Thanks in advance for your time and feedback.
Best regards,
Lakshay Piplani
^ permalink raw reply
* Re: [PATCH v2 2/3] regulator: dt-bindings: qcom,sdm845-refgen-regulator: Document IPQ9650
From: Kathiravan Thirumoorthy @ 2026-06-15 6:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, linux-arm-msm, linux-kernel,
devicetree
In-Reply-To: <20260612-blazing-brainy-firefly-d77a6b@quoll>
On 6/12/2026 2:32 PM, Krzysztof Kozlowski wrote:
> On Thu, Jun 11, 2026 at 02:33:17PM +0530, Kathiravan Thirumoorthy wrote:
>> IPQ9650 has two REFGEN blocks which provide reference current to the PCIe,
>> USB and UNIPHY PHYs. Unlike other supported platforms, IPQ9650 requires the
>> REFGEN clocks to be enabled explicitly.
>>
>> Document the IPQ9650 compatible and the required clocks for it.
>>
>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>
> You just ignored feedback... From me and Sashiko.
Sorry, I missed that. Let me address that in the next spin.
>
> So you got the same comments.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v8 3/7] input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
From: Svyatoslav Ryhel @ 2026-06-15 6:22 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, Svyatoslav Ryhel, devicetree,
linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <20260528053203.9339-4-clamor95@gmail.com>
чт, 28 трав. 2026 р. о 08:32 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Add input driver for ASUS Transformer dock keyboard and touchpad.
>
> Some keys in ASUS Dock report keycodes that don't make sense according to
> their position, this patch modifies the incoming data that is sent to
> serio to send proper scancodes.
>
> Co-developed-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Ion Agorria <ion@agorria.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/input/serio/Kconfig | 15 ++
> drivers/input/serio/Makefile | 1 +
> drivers/input/serio/asus-transformer-ec-kbc.c | 158 ++++++++++++++++++
> 3 files changed, 174 insertions(+)
> create mode 100644 drivers/input/serio/asus-transformer-ec-kbc.c
Hello Dmitry! May you please take a look and Ack it if you are fine
this this driver or tell what I should adjust? That would be very
helpful. Thank you.
^ permalink raw reply
* [PATCH v2 4/4] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Kim Seer Paller @ 2026-06-15 6:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, linux-kernel, linux, devicetree, Kim Seer Paller
In-Reply-To: <20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com>
The AD3532R/AD3532 is a 16-channel, 16-bit voltage output DAC with a
dual-bank register architecture (bank 0 at 0x1000 for channels 0-7,
bank 1 at 0x3000 for channels 8-15). It shares similar functionality
with AD3530R (channel configuration, LDAC triggering, powerdown control),
the main difference being the register address map due to the dual-bank
architecture, handled by table-driven helpers.
Add AD3532R-specific register definitions, channel specs, per-bank
register arrays, a dedicated ad3532r_set_dac_powerdown(), and per-chip
regmap_config to limit debugfs-exposed register space to each variant's
actual address range.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
---
drivers/iio/dac/Kconfig | 4 +-
drivers/iio/dac/ad3530r.c | 208 +++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 197 insertions(+), 15 deletions(-)
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 657c68e75542..f034f7dda703 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -11,8 +11,8 @@ config AD3530R
depends on SPI
select REGMAP_SPI
help
- Say yes here to build support for Analog Devices AD3530R, AD3531R
- Digital to Analog Converter.
+ Say yes here to build support for Analog Devices AD3530/AD3530R,
+ AD3531/AD3531R, and AD3532/AD3532R Digital to Analog Converters.
To compile this driver as a module, choose M here: the
module will be called ad3530r.
diff --git a/drivers/iio/dac/ad3530r.c b/drivers/iio/dac/ad3530r.c
index e4346bc729ba..435d98ce29cb 100644
--- a/drivers/iio/dac/ad3530r.c
+++ b/drivers/iio/dac/ad3530r.c
@@ -2,6 +2,7 @@
/*
* AD3530R/AD3530 8-channel, 16-bit Voltage Output DAC Driver
* AD3531R/AD3531 4-channel, 16-bit Voltage Output DAC Driver
+ * AD3532R/AD3532 16-channel, 16-bit Voltage Output DAC Driver
*
* Copyright 2025 Analog Devices Inc.
*/
@@ -39,6 +40,22 @@
#define AD3531R_SW_LDAC_TRIG_A 0xDD
#define AD3531R_INPUT_CH 0xE3
+#define AD3532R_INTERFACE_CONFIG_A_0 0x1000
+#define AD3532R_INTERFACE_CONFIG_A_1 0x3000
+#define AD3532R_OUTPUT_OPERATING_MODE_0 0x1020
+#define AD3532R_OUTPUT_OPERATING_MODE_1 0x1021
+#define AD3532R_OUTPUT_OPERATING_MODE_2 0x3020
+#define AD3532R_OUTPUT_OPERATING_MODE_3 0x3021
+#define AD3532R_OUTPUT_CONTROL_0 0x102A
+#define AD3532R_OUTPUT_CONTROL_1 0x302A
+#define AD3532R_REFERENCE_CONTROL_0 0x103C
+#define AD3532R_REFERENCE_CONTROL_1 0x303C
+#define AD3532R_SW_LDAC_TRIG_0 0x10E5
+#define AD3532R_SW_LDAC_TRIG_1 0x30E5
+#define AD3532R_INPUT_CH_0 0x10EB
+#define AD3532R_INPUT_CH_1 0x30EB
+#define AD3532R_MAX_REG_ADDR 0x30F9
+
#define AD3530R_SLD_TRIG_A BIT(7)
#define AD3530R_OUTPUT_CONTROL_RANGE BIT(2)
#define AD3530R_REFERENCE_CONTROL_SEL BIT(0)
@@ -50,8 +67,10 @@
#define AD3530R_LDAC_PULSE_US 100
#define AD3530R_DAC_MAX_VAL GENMASK(15, 0)
-#define AD3530R_MAX_CHANNELS 8
+#define AD3530R_CH_PER_REG 4
+#define AD3530R_CH_PER_BANK 8
#define AD3531R_MAX_CHANNELS 4
+#define AD3532R_MAX_CHANNELS 16
enum ad3530r_mode {
AD3530R_NORMAL_OP,
@@ -68,6 +87,7 @@ struct ad3530r_chan {
struct ad3530r_chip_info {
const char *name;
const struct iio_chan_spec *channels;
+ const struct regmap_config *regmap_config;
int (*input_ch_reg)(unsigned int channel);
int (*sw_ldac_trig_reg)(unsigned int channel);
const unsigned int *interface_config_a;
@@ -84,7 +104,7 @@ struct ad3530r_state {
struct regmap *regmap;
/* lock to protect against multiple access to the device and shared data */
struct mutex lock;
- struct ad3530r_chan chan[AD3530R_MAX_CHANNELS];
+ struct ad3530r_chan chan[AD3532R_MAX_CHANNELS];
const struct ad3530r_chip_info *chip_info;
struct gpio_desc *ldac_gpio;
int vref_mV;
@@ -105,6 +125,14 @@ static int ad3531r_input_ch_reg(unsigned int channel)
return 2 * channel + AD3531R_INPUT_CH;
}
+static int ad3532r_input_ch_reg(unsigned int channel)
+{
+ if (channel < 8)
+ return 2 * channel + AD3532R_INPUT_CH_0;
+
+ return 2 * (channel - 8) + AD3532R_INPUT_CH_1;
+}
+
static const char * const ad3530r_powerdown_modes[] = {
"1kohm_to_gnd",
"7.7kohm_to_gnd",
@@ -117,6 +145,12 @@ static const char * const ad3531r_powerdown_modes[] = {
"16kohm_to_gnd",
};
+static const char * const ad3532r_powerdown_modes[] = {
+ "1kohm_to_gnd",
+ "10kohm_to_gnd",
+ "three_state",
+};
+
static int ad3530r_get_powerdown_mode(struct iio_dev *indio_dev,
const struct iio_chan_spec *chan)
{
@@ -152,6 +186,13 @@ static const struct iio_enum ad3531r_powerdown_mode_enum = {
.set = ad3530r_set_powerdown_mode,
};
+static const struct iio_enum ad3532r_powerdown_mode_enum = {
+ .items = ad3532r_powerdown_modes,
+ .num_items = ARRAY_SIZE(ad3532r_powerdown_modes),
+ .get = ad3530r_get_powerdown_mode,
+ .set = ad3530r_set_powerdown_mode,
+};
+
static ssize_t ad3530r_get_dac_powerdown(struct iio_dev *indio_dev,
uintptr_t private,
const struct iio_chan_spec *chan,
@@ -196,6 +237,39 @@ static ssize_t ad3530r_set_dac_powerdown(struct iio_dev *indio_dev,
return len;
}
+static ssize_t ad3532r_set_dac_powerdown(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len)
+{
+ struct ad3530r_state *st = iio_priv(indio_dev);
+ unsigned int reg, pdmode, mask, val, local_ch;
+ bool powerdown;
+ int ret;
+
+ ret = kstrtobool(buf, &powerdown);
+ if (ret)
+ return ret;
+
+ guard(mutex)(&st->lock);
+ local_ch = chan->channel % AD3530R_CH_PER_BANK;
+ reg = (chan->channel < AD3530R_CH_PER_BANK ? AD3532R_OUTPUT_OPERATING_MODE_0 :
+ AD3532R_OUTPUT_OPERATING_MODE_2) +
+ local_ch / AD3530R_CH_PER_REG;
+ mask = AD3530R_OP_MODE_CHAN_MSK(local_ch % AD3530R_CH_PER_REG);
+
+ pdmode = powerdown ? st->chan[chan->channel].powerdown_mode : 0;
+ val = field_prep(mask, pdmode);
+
+ ret = regmap_update_bits(st->regmap, reg, mask, val);
+ if (ret)
+ return ret;
+
+ st->chan[chan->channel].powerdown = powerdown;
+
+ return len;
+}
+
static int ad3530r_trigger_sw_ldac_reg(unsigned int channel)
{
return AD3530R_SW_LDAC_TRIG_A;
@@ -206,6 +280,14 @@ static int ad3531r_trigger_sw_ldac_reg(unsigned int channel)
return AD3531R_SW_LDAC_TRIG_A;
}
+static int ad3532r_trigger_sw_ldac_reg(unsigned int channel)
+{
+ if (channel < 8)
+ return AD3532R_SW_LDAC_TRIG_0;
+
+ return AD3532R_SW_LDAC_TRIG_1;
+}
+
static int ad3530r_trigger_hw_ldac(struct gpio_desc *ldac_gpio)
{
gpiod_set_value_cansleep(ldac_gpio, 1);
@@ -318,6 +400,19 @@ static const struct iio_chan_spec_ext_info ad3531r_ext_info[] = {
{ }
};
+static const struct iio_chan_spec_ext_info ad3532r_ext_info[] = {
+ {
+ .name = "powerdown",
+ .shared = IIO_SEPARATE,
+ .read = ad3530r_get_dac_powerdown,
+ .write = ad3532r_set_dac_powerdown,
+ },
+ IIO_ENUM("powerdown_mode", IIO_SEPARATE, &ad3532r_powerdown_mode_enum),
+ IIO_ENUM_AVAILABLE("powerdown_mode", IIO_SHARED_BY_TYPE,
+ &ad3532r_powerdown_mode_enum),
+ { }
+};
+
#define AD3530R_CHAN(_chan, _ext_info) \
{ \
.type = IIO_VOLTAGE, \
@@ -347,6 +442,25 @@ static const struct iio_chan_spec ad3531r_channels[] = {
AD3530R_CHAN(3, ad3531r_ext_info),
};
+static const struct iio_chan_spec ad3532r_channels[] = {
+ AD3530R_CHAN(0, ad3532r_ext_info),
+ AD3530R_CHAN(1, ad3532r_ext_info),
+ AD3530R_CHAN(2, ad3532r_ext_info),
+ AD3530R_CHAN(3, ad3532r_ext_info),
+ AD3530R_CHAN(4, ad3532r_ext_info),
+ AD3530R_CHAN(5, ad3532r_ext_info),
+ AD3530R_CHAN(6, ad3532r_ext_info),
+ AD3530R_CHAN(7, ad3532r_ext_info),
+ AD3530R_CHAN(8, ad3532r_ext_info),
+ AD3530R_CHAN(9, ad3532r_ext_info),
+ AD3530R_CHAN(10, ad3532r_ext_info),
+ AD3530R_CHAN(11, ad3532r_ext_info),
+ AD3530R_CHAN(12, ad3532r_ext_info),
+ AD3530R_CHAN(13, ad3532r_ext_info),
+ AD3530R_CHAN(14, ad3532r_ext_info),
+ AD3530R_CHAN(15, ad3532r_ext_info),
+};
+
static const unsigned int ad3530r_if_config[] = {
AD3530R_INTERFACE_CONFIG_A,
};
@@ -368,9 +482,44 @@ static const unsigned int ad3531r_op_mode[] = {
AD3530R_OUTPUT_OPERATING_MODE_0,
};
+static const unsigned int ad3532r_if_config[] = {
+ AD3532R_INTERFACE_CONFIG_A_0,
+ AD3532R_INTERFACE_CONFIG_A_1,
+};
+
+static const unsigned int ad3532r_out_ctrl[] = {
+ AD3532R_OUTPUT_CONTROL_0,
+ AD3532R_OUTPUT_CONTROL_1,
+};
+
+static const unsigned int ad3532r_ref_ctrl[] = {
+ AD3532R_REFERENCE_CONTROL_0,
+ AD3532R_REFERENCE_CONTROL_1,
+};
+
+static const unsigned int ad3532r_op_mode[] = {
+ AD3532R_OUTPUT_OPERATING_MODE_0,
+ AD3532R_OUTPUT_OPERATING_MODE_1,
+ AD3532R_OUTPUT_OPERATING_MODE_2,
+ AD3532R_OUTPUT_OPERATING_MODE_3,
+};
+
+static const struct regmap_config ad3530r_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = AD3530R_MAX_REG_ADDR,
+};
+
+static const struct regmap_config ad3532r_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = AD3532R_MAX_REG_ADDR,
+};
+
static const struct ad3530r_chip_info ad3530_chip = {
.name = "ad3530",
.channels = ad3530r_channels,
+ .regmap_config = &ad3530r_regmap_config,
.num_channels = ARRAY_SIZE(ad3530r_channels),
.sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
.input_ch_reg = ad3530r_input_ch_reg,
@@ -386,6 +535,7 @@ static const struct ad3530r_chip_info ad3530_chip = {
static const struct ad3530r_chip_info ad3530r_chip = {
.name = "ad3530r",
.channels = ad3530r_channels,
+ .regmap_config = &ad3530r_regmap_config,
.num_channels = ARRAY_SIZE(ad3530r_channels),
.sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
.input_ch_reg = ad3530r_input_ch_reg,
@@ -402,6 +552,7 @@ static const struct ad3530r_chip_info ad3530r_chip = {
static const struct ad3530r_chip_info ad3531_chip = {
.name = "ad3531",
.channels = ad3531r_channels,
+ .regmap_config = &ad3530r_regmap_config,
.num_channels = ARRAY_SIZE(ad3531r_channels),
.sw_ldac_trig_reg = ad3531r_trigger_sw_ldac_reg,
.input_ch_reg = ad3531r_input_ch_reg,
@@ -417,6 +568,7 @@ static const struct ad3530r_chip_info ad3531_chip = {
static const struct ad3530r_chip_info ad3531r_chip = {
.name = "ad3531r",
.channels = ad3531r_channels,
+ .regmap_config = &ad3530r_regmap_config,
.num_channels = ARRAY_SIZE(ad3531r_channels),
.sw_ldac_trig_reg = ad3531r_trigger_sw_ldac_reg,
.input_ch_reg = ad3531r_input_ch_reg,
@@ -429,6 +581,38 @@ static const struct ad3530r_chip_info ad3531r_chip = {
.internal_ref_support = true,
};
+static const struct ad3530r_chip_info ad3532_chip = {
+ .name = "ad3532",
+ .channels = ad3532r_channels,
+ .regmap_config = &ad3532r_regmap_config,
+ .num_channels = ARRAY_SIZE(ad3532r_channels),
+ .sw_ldac_trig_reg = ad3532r_trigger_sw_ldac_reg,
+ .input_ch_reg = ad3532r_input_ch_reg,
+ .interface_config_a = ad3532r_if_config,
+ .output_control = ad3532r_out_ctrl,
+ .reference_control = ad3532r_ref_ctrl,
+ .op_mode = ad3532r_op_mode,
+ .num_banks = ARRAY_SIZE(ad3532r_if_config),
+ .num_op_mode_regs = ARRAY_SIZE(ad3532r_op_mode),
+ .internal_ref_support = false,
+};
+
+static const struct ad3530r_chip_info ad3532r_chip = {
+ .name = "ad3532r",
+ .channels = ad3532r_channels,
+ .regmap_config = &ad3532r_regmap_config,
+ .num_channels = ARRAY_SIZE(ad3532r_channels),
+ .sw_ldac_trig_reg = ad3532r_trigger_sw_ldac_reg,
+ .input_ch_reg = ad3532r_input_ch_reg,
+ .interface_config_a = ad3532r_if_config,
+ .output_control = ad3532r_out_ctrl,
+ .reference_control = ad3532r_ref_ctrl,
+ .op_mode = ad3532r_op_mode,
+ .num_banks = ARRAY_SIZE(ad3532r_if_config),
+ .num_op_mode_regs = ARRAY_SIZE(ad3532r_op_mode),
+ .internal_ref_support = true,
+};
+
static int ad3530r_set_reg_bank_bits(const struct ad3530r_state *st,
const unsigned int *regs,
unsigned int num_regs,
@@ -534,12 +718,6 @@ static int ad3530r_setup(struct ad3530r_state *st, int external_vref_uV)
return 0;
}
-static const struct regmap_config ad3530r_regmap_config = {
- .reg_bits = 16,
- .val_bits = 8,
- .max_register = AD3530R_MAX_REG_ADDR,
-};
-
static const struct iio_info ad3530r_info = {
.read_raw = ad3530r_read_raw,
.write_raw = ad3530r_write_raw,
@@ -560,7 +738,11 @@ static int ad3530r_probe(struct spi_device *spi)
st = iio_priv(indio_dev);
- st->regmap = devm_regmap_init_spi(spi, &ad3530r_regmap_config);
+ st->chip_info = spi_get_device_match_data(spi);
+ if (!st->chip_info)
+ return -ENODEV;
+
+ st->regmap = devm_regmap_init_spi(spi, st->chip_info->regmap_config);
if (IS_ERR(st->regmap))
return dev_err_probe(dev, PTR_ERR(st->regmap),
"Failed to init regmap");
@@ -569,10 +751,6 @@ static int ad3530r_probe(struct spi_device *spi)
if (ret)
return ret;
- st->chip_info = spi_get_device_match_data(spi);
- if (!st->chip_info)
- return -ENODEV;
-
ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(regulators),
regulators);
if (ret)
@@ -606,6 +784,8 @@ static const struct spi_device_id ad3530r_id[] = {
{ .name = "ad3530r", .driver_data = (kernel_ulong_t)&ad3530r_chip },
{ .name = "ad3531", .driver_data = (kernel_ulong_t)&ad3531_chip },
{ .name = "ad3531r", .driver_data = (kernel_ulong_t)&ad3531r_chip },
+ { .name = "ad3532", .driver_data = (kernel_ulong_t)&ad3532_chip },
+ { .name = "ad3532r", .driver_data = (kernel_ulong_t)&ad3532r_chip },
{ }
};
MODULE_DEVICE_TABLE(spi, ad3530r_id);
@@ -615,6 +795,8 @@ static const struct of_device_id ad3530r_of_match[] = {
{ .compatible = "adi,ad3530r", .data = &ad3530r_chip },
{ .compatible = "adi,ad3531", .data = &ad3531_chip },
{ .compatible = "adi,ad3531r", .data = &ad3531r_chip },
+ { .compatible = "adi,ad3532", .data = &ad3532_chip },
+ { .compatible = "adi,ad3532r", .data = &ad3532r_chip },
{ }
};
MODULE_DEVICE_TABLE(of, ad3530r_of_match);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: iio: dac: add support for AD3532R/AD3532
From: Kim Seer Paller @ 2026-06-15 6:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, linux-kernel, linux, devicetree, Kim Seer Paller,
Conor Dooley
In-Reply-To: <20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com>
The AD3532R/AD3532 is a 16-channel version of the AD3530R/AD3530.
This adds compatible strings for the AD3532R/AD3532.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
---
.../devicetree/bindings/iio/dac/adi,ad3530r.yaml | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml
index a355d52a9d64..2fe098619772 100644
--- a/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad3530r.yaml
@@ -10,15 +10,17 @@ maintainers:
- Kim Seer Paller <kimseer.paller@analog.com>
description: |
- The AD3530/AD3530R (8-channel) and AD3531/AD3531R (4-channel) are low-power,
- 16-bit, buffered voltage output digital-to-analog converters (DACs) with
- software-programmable gain controls, providing full-scale output spans of 2.5V
- or 5V for reference voltages of 2.5V. These devices operate from a single 2.7V
- to 5.5V supply and are guaranteed monotonic by design. The "R" variants
- include a 2.5V, 5ppm/°C internal reference, which is disabled by default.
+ The AD3530/AD3530R (8-channel), AD3531/AD3531R (4-channel), and AD3532/AD3532R
+ (16-channel) are low-power, 16-bit, buffered voltage output digital-to-analog
+ converters (DACs) with software-programmable gain controls, providing
+ full-scale output spans of 2.5V or 5V for reference voltages of 2.5V. These
+ devices operate from a single 2.7V to 5.5V supply and are guaranteed monotonic
+ by design. The "R" variants include a 2.5V, 5ppm/°C internal reference, which
+ is disabled by default.
Datasheet can be found here:
https://www.analog.com/media/en/technical-documentation/data-sheets/ad3530_ad530r.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/ad3531-ad3531r.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ad3532r.pdf
properties:
compatible:
@@ -27,6 +29,8 @@ properties:
- adi,ad3530r
- adi,ad3531
- adi,ad3531r
+ - adi,ad3532
+ - adi,ad3532r
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/4] iio: ABI: add DAC 10kohm_to_gnd powerdown mode
From: Kim Seer Paller @ 2026-06-15 6:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, linux-kernel, linux, devicetree, Kim Seer Paller
In-Reply-To: <20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com>
Add a new powerdown mode for DACs with 10kohm resistor to GND.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
---
Documentation/ABI/testing/sysfs-bus-iio | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index d8d6d85235b0..67446cd37183 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -770,6 +770,7 @@ Description:
3.85kohm_to_gnd: connected to ground via a 3.85kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
7.7kohm_to_gnd: connected to ground via a 7.7kOhm resistor,
+ 10kohm_to_gnd: connected to ground via a 10kOhm resistor,
16kohm_to_gnd: connected to ground via a 16kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
32kohm_to_gnd: connected to ground via a 32kOhm resistor,
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/4] iio: dac: ad3530r: Refactor setup to table-driven register bank approach
From: Kim Seer Paller @ 2026-06-15 6:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, linux-kernel, linux, devicetree, Kim Seer Paller
In-Reply-To: <20260615-iio-ad3532r-support-v2-0-84a0af8b83fa@analog.com>
Replace direct register calls in ad3530r_setup() with per-chip register
address arrays and bank helpers (ad3530r_set_reg_bank_bits,
ad3530r_write_reg_banks). Convert sw_ldac_trig_reg from a static
register address to a function pointer for per-bank LDAC trigger
register selection. Switch spi_device_id to named initializers.
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
---
drivers/iio/dac/ad3530r.c | 144 +++++++++++++++++++++++++++++++++++++---------
1 file changed, 118 insertions(+), 26 deletions(-)
diff --git a/drivers/iio/dac/ad3530r.c b/drivers/iio/dac/ad3530r.c
index d9db3226ecd6..e4346bc729ba 100644
--- a/drivers/iio/dac/ad3530r.c
+++ b/drivers/iio/dac/ad3530r.c
@@ -69,8 +69,14 @@ struct ad3530r_chip_info {
const char *name;
const struct iio_chan_spec *channels;
int (*input_ch_reg)(unsigned int channel);
+ int (*sw_ldac_trig_reg)(unsigned int channel);
+ const unsigned int *interface_config_a;
+ const unsigned int *output_control;
+ const unsigned int *reference_control;
+ const unsigned int *op_mode;
unsigned int num_channels;
- unsigned int sw_ldac_trig_reg;
+ unsigned int num_banks;
+ unsigned int num_op_mode_regs;
bool internal_ref_support;
};
@@ -190,6 +196,16 @@ static ssize_t ad3530r_set_dac_powerdown(struct iio_dev *indio_dev,
return len;
}
+static int ad3530r_trigger_sw_ldac_reg(unsigned int channel)
+{
+ return AD3530R_SW_LDAC_TRIG_A;
+}
+
+static int ad3531r_trigger_sw_ldac_reg(unsigned int channel)
+{
+ return AD3531R_SW_LDAC_TRIG_A;
+}
+
static int ad3530r_trigger_hw_ldac(struct gpio_desc *ldac_gpio)
{
gpiod_set_value_cansleep(ldac_gpio, 1);
@@ -215,7 +231,7 @@ static int ad3530r_dac_write(struct ad3530r_state *st, unsigned int chan,
if (st->ldac_gpio)
return ad3530r_trigger_hw_ldac(st->ldac_gpio);
- return regmap_set_bits(st->regmap, st->chip_info->sw_ldac_trig_reg,
+ return regmap_set_bits(st->regmap, st->chip_info->sw_ldac_trig_reg(chan),
AD3530R_SLD_TRIG_A);
}
@@ -331,12 +347,39 @@ static const struct iio_chan_spec ad3531r_channels[] = {
AD3530R_CHAN(3, ad3531r_ext_info),
};
+static const unsigned int ad3530r_if_config[] = {
+ AD3530R_INTERFACE_CONFIG_A,
+};
+
+static const unsigned int ad3530r_out_ctrl[] = {
+ AD3530R_OUTPUT_CONTROL_0,
+};
+
+static const unsigned int ad3530r_ref_ctrl[] = {
+ AD3530R_REFERENCE_CONTROL_0,
+};
+
+static const unsigned int ad3530r_op_mode[] = {
+ AD3530R_OUTPUT_OPERATING_MODE_0,
+ AD3530R_OUTPUT_OPERATING_MODE_1,
+};
+
+static const unsigned int ad3531r_op_mode[] = {
+ AD3530R_OUTPUT_OPERATING_MODE_0,
+};
+
static const struct ad3530r_chip_info ad3530_chip = {
.name = "ad3530",
.channels = ad3530r_channels,
.num_channels = ARRAY_SIZE(ad3530r_channels),
- .sw_ldac_trig_reg = AD3530R_SW_LDAC_TRIG_A,
+ .sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
.input_ch_reg = ad3530r_input_ch_reg,
+ .interface_config_a = ad3530r_if_config,
+ .output_control = ad3530r_out_ctrl,
+ .reference_control = ad3530r_ref_ctrl,
+ .op_mode = ad3530r_op_mode,
+ .num_banks = ARRAY_SIZE(ad3530r_if_config),
+ .num_op_mode_regs = ARRAY_SIZE(ad3530r_op_mode),
.internal_ref_support = false,
};
@@ -344,7 +387,14 @@ static const struct ad3530r_chip_info ad3530r_chip = {
.name = "ad3530r",
.channels = ad3530r_channels,
.num_channels = ARRAY_SIZE(ad3530r_channels),
- .sw_ldac_trig_reg = AD3530R_SW_LDAC_TRIG_A,
+ .sw_ldac_trig_reg = ad3530r_trigger_sw_ldac_reg,
+ .input_ch_reg = ad3530r_input_ch_reg,
+ .interface_config_a = ad3530r_if_config,
+ .output_control = ad3530r_out_ctrl,
+ .reference_control = ad3530r_ref_ctrl,
+ .op_mode = ad3530r_op_mode,
+ .num_banks = ARRAY_SIZE(ad3530r_if_config),
+ .num_op_mode_regs = ARRAY_SIZE(ad3530r_op_mode),
.input_ch_reg = ad3530r_input_ch_reg,
.internal_ref_support = true,
};
@@ -353,8 +403,14 @@ static const struct ad3530r_chip_info ad3531_chip = {
.name = "ad3531",
.channels = ad3531r_channels,
.num_channels = ARRAY_SIZE(ad3531r_channels),
- .sw_ldac_trig_reg = AD3531R_SW_LDAC_TRIG_A,
+ .sw_ldac_trig_reg = ad3531r_trigger_sw_ldac_reg,
.input_ch_reg = ad3531r_input_ch_reg,
+ .interface_config_a = ad3530r_if_config,
+ .output_control = ad3530r_out_ctrl,
+ .reference_control = ad3530r_ref_ctrl,
+ .op_mode = ad3531r_op_mode,
+ .num_banks = ARRAY_SIZE(ad3530r_if_config),
+ .num_op_mode_regs = ARRAY_SIZE(ad3531r_op_mode),
.internal_ref_support = false,
};
@@ -362,17 +418,56 @@ static const struct ad3530r_chip_info ad3531r_chip = {
.name = "ad3531r",
.channels = ad3531r_channels,
.num_channels = ARRAY_SIZE(ad3531r_channels),
- .sw_ldac_trig_reg = AD3531R_SW_LDAC_TRIG_A,
+ .sw_ldac_trig_reg = ad3531r_trigger_sw_ldac_reg,
.input_ch_reg = ad3531r_input_ch_reg,
+ .interface_config_a = ad3530r_if_config,
+ .output_control = ad3530r_out_ctrl,
+ .reference_control = ad3530r_ref_ctrl,
+ .op_mode = ad3531r_op_mode,
+ .num_banks = ARRAY_SIZE(ad3530r_if_config),
+ .num_op_mode_regs = ARRAY_SIZE(ad3531r_op_mode),
.internal_ref_support = true,
};
+static int ad3530r_set_reg_bank_bits(const struct ad3530r_state *st,
+ const unsigned int *regs,
+ unsigned int num_regs,
+ unsigned int mask)
+{
+ int ret;
+
+ for (unsigned int i = 0; i < num_regs; i++) {
+ ret = regmap_update_bits(st->regmap, regs[i], mask, mask);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ad3530r_write_reg_banks(const struct ad3530r_state *st,
+ const unsigned int *regs,
+ unsigned int num_regs,
+ unsigned int val)
+{
+ int ret;
+
+ for (unsigned int i = 0; i < num_regs; i++) {
+ ret = regmap_write(st->regmap, regs[i], val);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int ad3530r_setup(struct ad3530r_state *st, int external_vref_uV)
{
+ const struct ad3530r_chip_info *chip_info = st->chip_info;
struct device *dev = regmap_get_device(st->regmap);
struct gpio_desc *reset_gpio;
- int i, ret;
u8 range_multiplier, val;
+ int ret;
reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(reset_gpio))
@@ -385,8 +480,9 @@ static int ad3530r_setup(struct ad3530r_state *st, int external_vref_uV)
gpiod_set_value_cansleep(reset_gpio, 0);
} else {
/* Perform software reset */
- ret = regmap_update_bits(st->regmap, AD3530R_INTERFACE_CONFIG_A,
- AD3530R_SW_RESET, AD3530R_SW_RESET);
+ ret = ad3530r_set_reg_bank_bits(st, chip_info->interface_config_a,
+ chip_info->num_banks,
+ AD3530R_SW_RESET);
if (ret)
return ret;
}
@@ -395,8 +491,9 @@ static int ad3530r_setup(struct ad3530r_state *st, int external_vref_uV)
range_multiplier = 1;
if (device_property_read_bool(dev, "adi,range-double")) {
- ret = regmap_set_bits(st->regmap, AD3530R_OUTPUT_CONTROL_0,
- AD3530R_OUTPUT_CONTROL_RANGE);
+ ret = ad3530r_set_reg_bank_bits(st, chip_info->output_control,
+ chip_info->num_banks,
+ AD3530R_OUTPUT_CONTROL_RANGE);
if (ret)
return ret;
@@ -406,8 +503,9 @@ static int ad3530r_setup(struct ad3530r_state *st, int external_vref_uV)
if (external_vref_uV) {
st->vref_mV = range_multiplier * external_vref_uV / MILLI;
} else {
- ret = regmap_set_bits(st->regmap, AD3530R_REFERENCE_CONTROL_0,
- AD3530R_REFERENCE_CONTROL_SEL);
+ ret = ad3530r_set_reg_bank_bits(st, chip_info->reference_control,
+ chip_info->num_banks,
+ AD3530R_REFERENCE_CONTROL_SEL);
if (ret)
return ret;
@@ -420,18 +518,12 @@ static int ad3530r_setup(struct ad3530r_state *st, int external_vref_uV)
FIELD_PREP(AD3530R_OP_MODE_CHAN_MSK(2), AD3530R_NORMAL_OP) |
FIELD_PREP(AD3530R_OP_MODE_CHAN_MSK(3), AD3530R_NORMAL_OP);
- ret = regmap_write(st->regmap, AD3530R_OUTPUT_OPERATING_MODE_0, val);
+ ret = ad3530r_write_reg_banks(st, st->chip_info->op_mode,
+ st->chip_info->num_op_mode_regs, val);
if (ret)
return ret;
- if (st->chip_info->num_channels > 4) {
- ret = regmap_write(st->regmap, AD3530R_OUTPUT_OPERATING_MODE_1,
- val);
- if (ret)
- return ret;
- }
-
- for (i = 0; i < st->chip_info->num_channels; i++)
+ for (unsigned int i = 0; i < st->chip_info->num_channels; i++)
st->chan[i].powerdown_mode = AD3530R_POWERDOWN_32K;
st->ldac_gpio = devm_gpiod_get_optional(dev, "ldac", GPIOD_OUT_LOW);
@@ -510,10 +602,10 @@ static int ad3530r_probe(struct spi_device *spi)
}
static const struct spi_device_id ad3530r_id[] = {
- { "ad3530", (kernel_ulong_t)&ad3530_chip },
- { "ad3530r", (kernel_ulong_t)&ad3530r_chip },
- { "ad3531", (kernel_ulong_t)&ad3531_chip },
- { "ad3531r", (kernel_ulong_t)&ad3531r_chip },
+ { .name = "ad3530", .driver_data = (kernel_ulong_t)&ad3530_chip },
+ { .name = "ad3530r", .driver_data = (kernel_ulong_t)&ad3530r_chip },
+ { .name = "ad3531", .driver_data = (kernel_ulong_t)&ad3531_chip },
+ { .name = "ad3531r", .driver_data = (kernel_ulong_t)&ad3531r_chip },
{ }
};
MODULE_DEVICE_TABLE(spi, ad3530r_id);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/4] Add support for AD3532R/AD3532
From: Kim Seer Paller @ 2026-06-15 6:20 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, linux-kernel, linux, devicetree, Kim Seer Paller,
Conor Dooley
This series adds support for the AD3532R/AD3532, a 16-channel, 16-bit
voltage output DAC, to the existing ad3530r driver.
The AD3532R is part of the AD3530R family and shares similar
functionality (channel configuration, LDAC triggering, powerdown
control). It extends the existing ad3530r driver as the underlying
workflow remains the same. The main difference being the register
address map due to the dual-bank architecture, which is handled
by table-driven helpers introduced in this series.
The AD3532R uses a dual-bank register architecture (bank 0 at 0x1000
for channels 0-7, bank 1 at 0x3000 for channels 8-15). Per-chip
register address arrays in chip_info are iterated by bank helpers,
replacing single-register setup calls for existing variants and scaling
naturally to the AD3532R's dual-bank layout.
The series also adds AD3532R-specific powerdown modes (1kohm_to_gnd,
10kohm_to_gnd, three_state) and a new ABI entry for the 10kohm_to_gnd
powerdown mode.
Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad3532r.pdf
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
---
Changes in v2:
- Split AD3532R patch into refactor only and new device support patches.
- Add ad3530r_set_reg_bank_bits() helper for set-bits call sites.
- Use for (unsigned int i = 0; ...) in bank helpers.
- Add per-chip regmap_config to limit debugfs register space per variant.
- Switch spi_device_id to named initializers.
- Fix line wrapping in ad3532r_set_dac_powerdown().
- Link to v1: https://patch.msgid.link/20260604-iio-ad3532r-support-v1-0-c3552f9031de@analog.com
To: Nuno Sá <nuno.sa@analog.com>
To: Michael Hennerich <Michael.Hennerich@analog.com>
To: Kim Seer Paller <kimseer.paller@analog.com>
To: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
To: Andy Shevchenko <andy@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-iio@vger.kernel.org
Cc: linux@analog.com
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Kim Seer Paller (4):
iio: dac: ad3530r: Refactor setup to table-driven register bank approach
iio: ABI: add DAC 10kohm_to_gnd powerdown mode
dt-bindings: iio: dac: add support for AD3532R/AD3532
iio: dac: ad3530r: Add support for AD3532R/AD3532
Documentation/ABI/testing/sysfs-bus-iio | 1 +
.../devicetree/bindings/iio/dac/adi,ad3530r.yaml | 16 +-
drivers/iio/dac/Kconfig | 4 +-
drivers/iio/dac/ad3530r.c | 352 ++++++++++++++++++---
4 files changed, 326 insertions(+), 47 deletions(-)
---
base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
change-id: 20260604-iio-ad3532r-support-759067e904e1
Best regards,
--
Kim Seer Paller <kimseer.paller@analog.com>
^ permalink raw reply
* Re: [PATCH v5 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Svyatoslav Ryhel @ 2026-06-15 6:19 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, devicetree, linux-kernel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij
In-Reply-To: <CAPVz0n3Dw6Vtqqn8if=MYkBbYittXqsBKbDvrs1ntbD5Zn6iig@mail.gmail.com>
чт, 28 трав. 2026 р. о 08:38 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> вт, 12 трав. 2026 р. о 13:24 Svyatoslav Ryhel <clamor95@gmail.com> пише:
> >
> > From: Linus Walleij <linusw@kernel.org>
> >
> > The ISA1200 is a haptic feedback unit from Imagis Technology using two
> > motors for haptic feedback in mobile phones. Used in many mobile devices
> > c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> > GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> >
> > The exact datasheet for the ISA1200 is not available; all data was modeled
> > based on available downstream kernel sources for various devices and
> > fragments of information scattered across the internet.
> >
> > Tested-by: Linus Walleij <linusw@kernel.org> # GT-I9070 Janice
> > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/input/misc/Kconfig | 12 +
> > drivers/input/misc/Makefile | 1 +
> > drivers/input/misc/isa1200.c | 524 +++++++++++++++++++++++++++++++++++
> > 3 files changed, 537 insertions(+)
> > create mode 100644 drivers/input/misc/isa1200.c
> >
>
> Hello Dmitry! Do I need to make any further adjustments to this driver?
Hello Dmitry! Do I need to make any further adjustments to this
driver? This driver is hanging in LKML for some time already without
responds from input maintainer. It is still relevant and I would like
it to move forward.
^ permalink raw reply
* RE: [PATCH 2/7] ASoC: codecs: ES8389: Fix the issue about mclk_src
From: Zhang Yi @ 2026-06-15 6:06 UTC (permalink / raw)
To: krzk
Cc: alsa-devel, broonie, conor+dt, devicetree, krzk+dt, robh, tiwai,
zhangyi
In-Reply-To: <fbaf1829-723b-4a87-882b-b164bb544912@kernel.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
> >
> >>> struct es8389_private *es8389 = snd_soc_component_get_drvdata(component);
> >>>
> >>> - ret = device_property_read_u8(component->dev, "everest,mclk-src", &es8389->mclk_src);
> >>
> >> Why are you changing implemented ABI?
> >
> > In the old ABI, `mclk_src` was defined as `u8`, which meant that users could set `mclk_src` to any value in the DTS¡ªsuch as `0x02`,
> > but the code wouldn't recognize what that value represented.
> > The actual purpose of `mclk_src` is to indicate whether `sclk` should be used as `mclk`.
> > So I've changed it to bool.
>
> You break ABI implemented by this driver, so you must clearly document
> it with reasons, why breaking is necessary. Honestly, without proper
> reason I would just answer that you must keep it backwards compatible.
OK
^ permalink raw reply
* RE: [PATCH v4 2/5] rtc: pcf85363: support reporting battery switch-over via RTC_VL
From: Lakshay Piplani @ 2026-06-15 6:15 UTC (permalink / raw)
To: 'alexandre.belloni@bootlin.com',
'linux-rtc@vger.kernel.org',
'linux-kernel@vger.kernel.org', 'robh@kernel.org',
'krzk+dt@kernel.org', 'conor+dt@kernel.org',
'devicetree@vger.kernel.org',
'wim@linux-watchdog.org', 'linux@roeck-us.net',
'linux-watchdog@vger.kernel.org'
Cc: Vikash Bansal, Priyanka Jain
In-Reply-To: <AS4PR04MB936215FC06B8ACC0F0259223FB9EA@AS4PR04MB9362.eurprd04.prod.outlook.com>
>
> Hi,
>
> I'm sending a gentle reminder regarding the patches that I submitted in
> November.
> I haven't received any review comments yet, so I'd really appreciate it if you
> could have a look whenever you have some time.
>
> Best Regards
> Lakshay Piplani
Hi,
I hope you're doing well.
This is a gentle follow-up regarding the v4 patch series for the PCF85363 RTC driver that I submitted in November 2025.
I understand things can get busy, but I haven't seen any feedback on the series yet, so I wanted to check if you've had a chance to review it.
I'd be happy to make any updates if needed. Please let me know if there's anything required from my side to move this forward.
Thanks in advance for your time and feedback.
Best regards,
Lakshay Piplani
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: thermal: tsens: add ipq5210 & ipq9650 compatible
From: Varadarajan Narayanan @ 2026-06-15 6:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: amitk, thara.gopinath, rafael, daniel.lezcano, rui.zhang,
lukasz.luba, robh, krzk+dt, conor+dt, linux-pm, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260611-active-strange-porpoise-7dc9db@quoll>
On Thu, Jun 11, 2026 at 10:24:46AM +0200, Krzysztof Kozlowski wrote:
> On Wed, Jun 10, 2026 at 01:42:40PM +0530, Varadarajan Narayanan wrote:
> > Add the compatible for the thermal sensors on the ipq5210 and ipq9650. The
> > ipq5210 uses ipq5332-tsens as a fallback, while ipq9650 is added as a
> > standalone v2 TSENS compatible with combined interrupt.
> >
> > Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> > ---
> > v2: Fix fallback definition
> > Include ipq9650 to all applicable constraints
>
> You already sent v2 and received comments yesterday.
>
> Please respond to feedback and version your patches correctly.
Sorry my mistake.
Have added the additional constraints to ipq9650. Will fix the version no.
and post v4.
Thanks
Varada
^ permalink raw reply
* RE: [PATCH v4 1/5] dt-bindings: rtc: nxp,pcf85363: add timestamp mode config
From: Lakshay Piplani @ 2026-06-15 6:14 UTC (permalink / raw)
To: alexandre.belloni@bootlin.com, linux-rtc@vger.kernel.org,
linux-kernel@vger.kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-watchdog@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain
In-Reply-To: <AS4PR04MB93628F4BEFE9293FC6E457C6FB2B2@AS4PR04MB9362.eurprd04.prod.outlook.com>
>
> Hi,
>
> This is a gentle follow up on the patch series I submitted in November
> (regarding the v4 of PCF85363 RTC driver). I haven't seen any review feedback
> Yet. So, I wanted to check whether you might have had a chance to look at the
> series.
>
> Please let me know if there is anything further is needed from my side.
>
> Thanks,
> Lakshay Piplani
Hi,
I hope you're doing well.
This is a gentle follow-up regarding the v4 patch series for the PCF85363 RTC driver that I submitted in November 2025.
I understand things can get busy, but I haven't seen any feedback on the series yet, so I wanted to check if you've had a chance to review it.
I'd be happy to make any updates if needed. Please let me know if there's anything required from my side to move this forward.
Thanks in advance for your time and feedback.
Best regards,
Lakshay Piplani
^ permalink raw reply
* Re: [PATCH v3 1/2] cpufreq: spacemit: Add K1 cpufreq driver
From: Shuwei Wu @ 2026-06-15 6:12 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Yixun Lan, linux-pm, linux-kernel, linux-riscv, spacemit,
devicetree
In-Reply-To: <bd4s2icqgusnuujvrpoag4cniy3g2e4bumecqxt5yffl77aqpq@kxg4dj4c2wk3>
Hi Viresh,
Thanks for your reply.
On Mon Jun 15, 2026 at 1:24 PM CST, Viresh Kumar wrote:
> On 12-06-26, 17:51, Shuwei Wu wrote:
>> K1 has two CPU cluster clocks but one shared CPU voltage rail. Use one
>> cpufreq policy for all CPUs, let the OPP core handle the shared regulator
>> and the cluster0 clock, and update the cluster1 clock explicitly.
>
> If the clusters can do DVFS individually (as they have separate clocks), this
> should be represented as two separate policies. Isn't it ?
The clusters have separate clocks, but they share the same voltage supply.[1]
So two independent policies would be unsafe: one policy could lower the shared
voltage while the other cluster is still running at a higher frequency.
This means they can't use different policies.
From a hardware perspective, the eight cores of the K1 are homogeneous,
so using the same policy for them is relatively reasonable.
I used a K1-specific driver because cpufreq-dt only manages one CPU clock
through the CPU device used for the OPP transition.
On K1, the policy needs to control two independent cluster clocks and one shared
regulator, so the driver has to update the second cluster clock explicitly and
keep the ordering safe: raise voltage before raising either cluster, and lower
both cluster clocks before lowering the shared voltage.
[1] https://lore.kernel.org/spacemit/aeaXszeaE62rM6BJ@aurel32.net/
--
Best regards,
Shuwei Wu
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: crypto: qcom,inline-crypto-engine: Document Maili ICE
From: Jingyi Wang @ 2026-06-15 6:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, aiqun.yu,
tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260610-mighty-dalmatian-of-piety-2fa184@quoll>
On 6/10/2026 4:55 PM, Krzysztof Kozlowski wrote:
> On Tue, Jun 09, 2026 at 02:08:57AM -0700, Jingyi Wang wrote:
>> The Inline Crypto Engine found on Maili SoC is compatible with the common
>> baseline IP 'qcom,inline-crypto-engine'. Hence, document the compatible as
>> such.
>>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> index db895c50e2d2..c9489f6b8081 100644
>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> @@ -16,6 +16,7 @@ properties:
>> - qcom,eliza-inline-crypto-engine
>> - qcom,hawi-inline-crypto-engine
>> - qcom,kaanapali-inline-crypto-engine
>> + - qcom,maili-inline-crypto-engine
>
> Why clocks are flexible?
I have just noticed that this patch has been merged:
https://lore.kernel.org/all/20260416-qcom_ice_power_and_clk_vote-v5-1-5ccf5d7e2846@oss.qualcomm.com/
Will add qcom,maili-inline-crypto-engine to the eliza/milos list in next version.
( Maybe hawi should also be added together? )
Thanks,
Jingyi
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v4 06/16] media: iris: Add platform data field for watchdog interrupt mask
From: Vikash Garodia @ 2026-06-15 6:11 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260612-iris-ar50lt-v4-6-0abfb74d5b3c@oss.qualcomm.com>
On 6/12/2026 2:55 PM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal<dikshita.agarwal@oss.qualcomm.com>
>
> For AR50LT core, the value of WRAPPER_INTR_STATUS_A2HWD_BMASK differs
> from the currently supported VPUs. In preparation for adding AR50LT
> support in subsequent patches, introduce a platform data field,
> wd_intr_mask, to capture the watchdog interrupt bitmask per platform.
>
> Signed-off-by: Dikshita Agarwal<dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov<dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_platform_common.h | 1 +
> drivers/media/platform/qcom/iris/iris_platform_vpu2.c | 4 ++++
> drivers/media/platform/qcom/iris/iris_platform_vpu3x.c | 6 ++++++
> drivers/media/platform/qcom/iris/iris_vpu_common.c | 8 +++++---
> drivers/media/platform/qcom/iris/iris_vpu_register_defines.h | 1 -
> 5 files changed, 16 insertions(+), 4 deletions(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: syscon: Revert renesas,r9a08g046-lvds-cmn
From: Krzysztof Kozlowski @ 2026-06-15 6:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Tommaso Merciai, Biju Das,
devicetree, linux-kernel, linux-renesas-soc
In-Reply-To: <20260608115507.134969-2-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 01:55:08PM +0200, Krzysztof Kozlowski wrote:
> Revert commit 51284d8b1dbc ("dt-bindings: mfd: syscon: Document the
> LVDS_CMN syscon for the RZ/G3L") because it is completely not matching
> reality and clearly incorrect in respect of renesas,r9a08g046-lvds-cmn.
>
> It wasn't ever build-tested by author on their DTS, either.
>
> The documented renesas,r9a08g046-lvds-cmn compatible clearly disallows
> any children and simple-mfd fallback, however its only use in original
> patchset is with simple-mfd and children, so this could have never
> worked.
>
> Fixes: 51284d8b1dbc ("dt-bindings: mfd: syscon: Document the LVDS_CMN syscon for the RZ/G3L")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mfd/syscon.yaml | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index 9c81010d5a74..e22867088063 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
For the record: this patch is still valid and justified, even with my
other syscon-related work.
The compatible here is not correctly documented and should be reverted.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v7 2/2] rtc: Add NXP PCF85053 driver support
From: Lakshay Piplani @ 2026-06-15 6:10 UTC (permalink / raw)
To: Lakshay Piplani, alexandre.belloni@bootlin.com,
linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain, Daniel Aguirre, Pankit Garg
In-Reply-To: <20251127120456.1849177-2-lakshay.piplani@nxp.com>
> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Thursday, November 27, 2025 5:35 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>; Daniel Aguirre <daniel.aguirre@nxp.com>; Pankit
> Garg <pankit.garg@nxp.com>
> Subject: [PATCH v7 2/2] rtc: Add NXP PCF85053 driver support
>
> PCF85053 is i2c based RTC which supports timer and calendar functionality.
>
> Features supported:
> 1. Read/Write time
> 2. Get/Set Alarm
> 3. Wakeup Source
> 4. Generate up to 32768Hz clock output
> 5. Primary/Secondary i2c bus
>
> Signed-off-by: Daniel Aguirre <daniel.aguirre@nxp.com>
> Signed-off-by: Pankit Garg <pankit.garg@nxp.com>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V6 -> V7: - Addressed minor cleanups from review: use
> dev_get_drvdata()/dev_set_drvdata()
> consistently, fix alarm IRQ dev_id handling, and switch to
> devm_device_init_wakeup().
> - Simplified time/alarm programming by forcing 24h + binary mode in
> hardware,
> dropping complex 12h/BCD handling in setters.
> - Documented the 2000–2099 supported year range, explaining how
> the 00–99 year
> register maps to leap-year behavior in the device.
> V5 -> V6: no changes
> V4 -> V5: no changes
> V3 -> V4: - Handle multi-host ownership explicitly using primary/secondary bus
> hadling.
> - Probe no longer changes any CTRL bits unconditionally and do not clear
> ST/AF/OF
> avoiding lost interrupts or silent mode changes.
> - Read/Set time & alarm now respect HF(12/24h) and DM(BCD/BIN)
> converting
> hour fields correctly for all combinations.
> - Minor changes: drop noisy warnings, tidy error paths/comments.
> V2 -> V3: Add MAINTAINERS file changes to this patch
> V1 -> V2: no changes
Hi,
I wanted to follow up again on the patch series I submitted in November 2025
(v7 of the PCF85053 RTC driver). I haven’t received any feedback on it so far,
so, I wanted to check if you’ve had a chance to review it.
I understand things can get busy, but I would really appreciate any feedback
when you get the time. Please let me know if any additional information is needed from my side.
Thanks for your time.
Best regards,
Lakshay Piplani
^ permalink raw reply
* Re: [PATCH 2/2] usb: typec: ucsi: Add ITE IT885x Type-C PD controller driver
From: sashiko-bot @ 2026-06-15 6:09 UTC (permalink / raw)
To: Amber Kao; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260615-ucsi-itepd-feature-v1-2-a826cfd0df6a@ite.com.tw>
Thank you for your contribution! Sashiko AI review found 12 potential issue(s) to consider:
- [High] DMA safety violation passing stack-allocated variables directly to `i2c_transfer()`.
- [High] Incorrect `devm` unwind ordering causes Use-After-Free of Type-C resources during workqueue flush.
- [High] Race condition during driver removal causing Use-After-Free by destroying the UCSI instance and workqueue before unregistering the interrupt callback.
- [High] Out-of-bounds array access due to unvalidated port index extracted from UCSI commands and hardware responses.
- [High] Race condition during probe where premature interrupt callback registration causes a NULL pointer dereference of the `ucsi` instance.
- [High] Uninitialized variables `ret` and `data` in `ucsi_itepd_connector_change_work` lead to undefined behavior and stack data leaks.
- [High] Missing lock protection when reading `itepd->altmode_cb` leads to data races and potential TOCTOU NULL pointer dereference.
- [High] Use of uninitialized stack memory during UCSI response parsing (`msg_in`).
- [High] Multi-byte native types (u64, u32, u16) are copied directly to/from I2C byte buffers, breaking on Big Endian architectures.
- [High] A pending initial hardware interrupt is explicitly acknowledged during probe but the event is permanently dropped.
- [Medium] `free_irq()` is called unconditionally during cleanup, even if the IRQ was never successfully requested.
- [Medium] Data races on `dp_en` and `con_change_processed` flags due to missing synchronization between workqueues.
--
commit 06a7873d268be15ee101449d82fa1a3ba9e341f7
Author: Amber Kao <amber.kao@ite.com.tw>
usb: typec: ucsi: Add ITE IT885x Type-C PD controller driver
Add core, UCSI, and Alternate Mode support for the ITE IT885x
Type-C Power Delivery controller over I2C. The driver uses the
auxiliary bus to spawn UCSI and Alternate Mode child devices from
the main I2C core driver.
> diff --git a/drivers/usb/typec/ucsi/itepd.c b/drivers/usb/typec/ucsi/itepd.c
> new file mode 100644
> index 0000000000000..39ac1c1361572
> --- /dev/null
> +++ b/drivers/usb/typec/ucsi/itepd.c
[ ... ]
> +static int itepd_read_reg(struct itepd *itepd, u8 reg, void *data, u32 len)
> +{
> + struct i2c_client *client = itepd->client;
> + struct i2c_msg msg[] = {
> + {
> + .addr = client->addr,
> + .flags = 0x0,
> + .len = 1,
> + .buf = ®,
> + },
> + {
> + .addr = client->addr,
> + .flags = I2C_M_RD,
> + .len = len,
> + .buf = (u8 *)data,
> + }
> + };
[Severity: High]
Could this cause DMA mapping errors? The stack-allocated msg array passes
the addresses of the local variables reg and data. The I2C subsystem
requires all buffers passed to i2c_transfer to be DMA-safe. If the I2C
adapter utilizes DMA, mapping stack memory can cause cache coherency issues
or trigger a panic if CONFIG_DMA_API_DEBUG is enabled.
[ ... ]
> +static int itepd_write_reg(struct itepd *itepd, u8 reg, const void *data, u32 len)
> +{
[ ... ]
> + buf[0] = reg;
> + memcpy(buf + sizeof(reg), (u8 *)data, len);
[Severity: High]
Might this break on big-endian architectures? When a multi-byte native
type like u64 or u32 is passed into data and copied directly into the I2C
buffer via memcpy, the most significant bytes are placed first on a big
endian system. Should this use explicit byte-order conversions like
cpu_to_le64 or le32_to_cpu?
[ ... ]
> +int itepd_mode(struct device *dev, u8 port, u8 mux, u32 config, u32 status)
> +{
[ ... ]
> + itepd->altmode_data[port].dp_status = status;
> + if (itepd->altmode_cb)
> + itepd->altmode_cb->notify(itepd->altmode_cb->priv,
> + &itepd->altmode_data[port]);
[Severity: High]
Is there a potential TOCTOU race condition here? The altmode callback pointer
is checked and invoked without holding the cb_lock mutex. If
itepd_altmode_remove unregisters the callback concurrently, altmode_cb
could become NULL right after the check, leading to a dereference panic.
Does itepd_hpd share this same unprotected pattern?
[ ... ]
> +static int itepd_probe(struct i2c_client *client)
> +{
[ ... ]
> + desc = devm_gpiod_get(dev, NULL, GPIOD_IN);
> +
> + if (IS_ERR(desc)) {
> + dev_info(dev, "get gpios from DTS failed\n");
> + } else {
> + if (gpiod_get_value(desc))
> + itepd_irq_process(itepd);
> + }
[Severity: High]
Could this manually trigger an interrupt drop? At this point in the probe
sequence, the auxiliary devices and callbacks are not yet added. Calling
itepd_irq_process clears the pending hardware events by writing to
ITEPD_VENDOR_WC_INT, but since the callbacks are NULL, the event data is
discarded without notifying the UCSI or altmode subsystems.
[ ... ]
> +out_release_altmode_aux:
> + if (itepd->client_mask & BIT(ITEPD_CLIENT_ALTMODE))
> + itepd_del_aux_device(itepd->altmode_aux);
> +out_free_irq:
> + free_irq(itepd->irq, itepd);
> + return ret;
> +}
> +
> +static void itepd_remove(struct i2c_client *client)
> +{
> + struct itepd *itepd = i2c_get_clientdata(client);
> +
> + if (itepd->client_mask & BIT(ITEPD_CLIENT_UCSI))
> + itepd_del_aux_device(itepd->ucsi_aux);
> + if (itepd->client_mask & BIT(ITEPD_CLIENT_ALTMODE))
> + itepd_del_aux_device(itepd->altmode_aux);
> + free_irq(itepd->irq, itepd);
> +}
[Severity: Medium]
Is it safe to unconditionally call free_irq here? The probe function correctly
checks if itepd->irq > 0 before calling request_threaded_irq, but the error
handling and remove paths free the IRQ regardless. If the device was probed
without a valid IRQ, wouldn't this attempt to free an unassigned IRQ line
and trigger a warning?
> diff --git a/drivers/usb/typec/ucsi/itepd_altmode.c b/drivers/usb/typec/ucsi/itepd_altmode.c
> new file mode 100644
> index 0000000000000..a88ae2fb6e798
> --- /dev/null
> +++ b/drivers/usb/typec/ucsi/itepd_altmode.c
[ ... ]
> +static int itepd_altmode_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
[ ... ]
> + alt_port->ordered_wq = alloc_ordered_workqueue("itepd_altmode_%u", 0, port);
> + if (!alt_port->ordered_wq) {
> + fwnode_handle_put(fwnode);
> + return -ENOMEM;
> + }
> +
> + ret = devm_add_action_or_reset(dev, itepd_altmode_destroy_wq,
> + alt_port->ordered_wq);
> + if (ret) {
> + fwnode_handle_put(fwnode);
> + return ret;
> + }
[ ... ]
> + alt_port->typec_mux = fwnode_typec_mux_get(fwnode);
> + if (IS_ERR(alt_port->typec_mux)) {
[Severity: High]
Does this devm initialization order create a use-after-free risk during
device removal? The action to destroy the workqueue is added before the
typec_mux, typec_retimer, and typec_switch are acquired and their put actions
registered. Since devm unwinds in LIFO order, the workqueue flush will
execute after the Type-C resources have been freed. If a worker is pending,
it might dereference the already freed typec resource pointers.
> diff --git a/drivers/usb/typec/ucsi/ucsi_itepd.c b/drivers/usb/typec/ucsi/ucsi_itepd.c
> new file mode 100644
> index 0000000000000..ea55ff7b866ee
> --- /dev/null
> +++ b/drivers/usb/typec/ucsi/ucsi_itepd.c
[ ... ]
> +static void ucsi_itepd_connector_change_work(struct work_struct *work)
> +{
> + struct ucsi_itepd_work *worker = container_of(work, struct ucsi_itepd_work, work);
> + struct ucsi_itepd *ucsi_itepd = worker->ucsi_itepd;
> + u8 data[11];
> + u8 num_vdos;
> + u32 status;
> + u64 cmd;
> + int ret;
> +
> + if (ucsi_itepd->con_change_processed[worker->port])
> + goto out;
> +
> + ucsi_itepd->con_change_processed[worker->port] = true;
[Severity: Medium]
Is there a data race on these array flags? The flags dp_en and
con_change_processed are modified in ucsi_itepd_connector_status, which runs
on the core system_long_wq, but they are read and modified here on the local
ordered_wq. Without mutual exclusion, could this result in skipped
evaluations or out-of-order state transitions?
> + if (ucsi_itepd->dp_en[worker->port]) {
> + /* UCSI_GET_ATTENTION_VDO (0x16) */
> + cmd = UCSI_COMMAND(UCSI_GET_ATTENTION_VDO) |
> + UCSI_CONNECTOR_NUMBER(worker->port + 1);
> + ret = ucsi_send_command(ucsi_itepd->ucsi, cmd, data, 11);
> + }
> + if (ret < 0)
> + goto out;
[Severity: High]
Can this lead to uninitialized stack variable usage? If dp_en is false, the
block that calls ucsi_send_command is skipped, leaving ret and data
uninitialized. Depending on the garbage value of ret, it might skip the
connector change notification or proceed to read random stack values from
data to pass into itepd_hpd.
[ ... ]
> +static void ucsi_itepd_response_hook(struct ucsi_itepd *ucsi_itepd,
> + u32 *cci, u8 *msg_in)
> +{
> + u8 recipient;
> + u8 offset;
> + struct ucsi_itepd_work *worker;
> +
> + if (((*cci & UCSI_CCI_COMMAND_COMPLETE) == 0) &&
> + UCSI_CCI_CONNECTOR(*cci)) {
> + worker = kmalloc_obj(*worker, GFP_KERNEL);
> + if (!worker) {
> + dev_err(ucsi_itepd->dev,
> + "out of memory, skip attention check\n");
> + ucsi_connector_change(ucsi_itepd->ucsi,
> + UCSI_CCI_CONNECTOR(*cci));
> + } else {
> + worker->port = UCSI_CCI_CONNECTOR(*cci) - 1;
> + worker->ucsi_itepd = ucsi_itepd;
> + worker->cci = *cci;
[Severity: High]
Is the worker->port index sufficiently validated? The port index is derived
directly from the hardware CCI register and can be up to 126. It is then
passed to the workqueue where it indexes bounded arrays like
con_change_processed and dp_en which are sized by ITEPD_MAX_PORTS. Would
a faulty or unexpected hardware response cause out-of-bounds memory
corruption here?
[ ... ]
> + switch (UCSI_COMMAND(ucsi_itepd->cmd)) {
> + case UCSI_GET_CONNECTOR_STATUS:
> + ucsi_itepd->connected[ucsi_itepd->cmd_port] =
> + !!(msg_in[2] & BIT(3));
> + ucsi_itepd->orientation[ucsi_itepd->cmd_port] =
> + FIELD_GET(BIT(6), msg_in[10]);
> + break;
[Severity: High]
Could this read past the end of the populated response data? The driver copies
the I2C payload into a local msg_in buffer based on the length provided in
the CCI register. If the hardware responds with a shorter message, reading
msg_in[10] unconditionally evaluates uninitialized stack memory.
[ ... ]
> +static int ucsi_itepd_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
[ ... ]
> + ret = itepd_register_cb(dev, ITEPD_CLIENT_UCSI, ucsi_itepd_cb);
> + if (ret)
> + goto out_destroy_wq;
> +
> + ucsi_itepd->ucsi = ucsi_create(dev, &ucsi_itepd_ops);
[Severity: High]
Does registering the callback early create a race condition? The interrupt on
the parent I2C device is already active. If an interrupt fires immediately
after itepd_register_cb, it will invoke ucsi_itepd_notify which ultimately
dereferences ucsi_itepd->ucsi. Since ucsi_create has not been called yet,
could this result in a NULL pointer dereference?
[ ... ]
> +static void ucsi_itepd_remove(struct auxiliary_device *adev)
> +{
> + struct ucsi_itepd *ucsi_itepd = dev_get_drvdata(&adev->dev);
> +
> + if (ucsi_itepd->ordered_wq) {
> + flush_workqueue(ucsi_itepd->ordered_wq);
> + destroy_workqueue(ucsi_itepd->ordered_wq);
> + }
> +
> + ucsi_unregister(ucsi_itepd->ucsi);
> + ucsi_destroy(ucsi_itepd->ucsi);
> + usleep_range(2000, 2500);
> + itepd_register_cb(&adev->dev, ITEPD_CLIENT_UCSI, NULL);
> +}
[Severity: High]
Might this teardown sequence result in a use-after-free? The workqueue is
destroyed and the ucsi instance is freed before the callback is unregistered.
If an interrupt occurs concurrently, the handler could invoke the callback,
attempting to queue a task on the destroyed workqueue or dereference the
freed ucsi structure. Should the callback be cleared before resources are
freed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-ucsi-itepd-feature-v1-0-a826cfd0df6a@ite.com.tw?part=2
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Krzysztof Kozlowski @ 2026-06-15 6:09 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Potin Lai, conor+dt, linux-hwmon, robh, devicetree
In-Reply-To: <20260615031628.ADC9C1F000E9@smtp.kernel.org>
On Mon, Jun 15, 2026 at 03:16:28AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Device Tree Schema Type Conflict: The new `ti,current-limit` property is defined as a string, which conflicts with its existing global definition as a `uint32`.
> --
Actually HIGH.
Properties can have only one type in general.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v7 1/2] dt-bindings: rtc: Add pcf85053 support
From: Lakshay Piplani @ 2026-06-15 6:08 UTC (permalink / raw)
To: alexandre.belloni@bootlin.com, linux-rtc@vger.kernel.org,
linux-kernel@vger.kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain, Pankit Garg, Conor Dooley
In-Reply-To: <AS4PR04MB93629FC0E5B22263A41914E9FB2B2@AS4PR04MB9362.eurprd04.prod.outlook.com>
> > +
> > + i2c1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + rtc@6f {
> > + compatible = "nxp,pcf85053";
> > + reg = <0x6f>;
> > + nxp,interface = "secondary";
> > + };
> > + };
> > --
> > 2.25.1
>
> Hi,
>
> This is a gentle follow up on the patch series I submitted in November
> (regarding the v7 of PCF85053 RTC driver). I haven't seen any review feedback
> Yet. So, I wanted to check whether you might have had a chance to look at the
> series.
>
> Please let me know if there is anything further needed from my side.
>
> Thanks,
> Lakshay Piplani
Hi,
I wanted to follow up again on the patch series I submitted in November 2025
(v7 of the PCF85053 RTC driver). I haven't received any feedback on it so far,
so, I wanted to check if you've had a chance to review it.
I understand things can get busy, but I would really appreciate any feedback
when you get the time. Please let me know if any additional information is needed from my side.
Thanks for your time.
Best regards,
Lakshay Piplani
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Krzysztof Kozlowski @ 2026-06-15 6:08 UTC (permalink / raw)
To: Potin Lai
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss, linux-hwmon, devicetree, linux-kernel, Cosmo Chou,
Mike Hsieh, Potin Lai
In-Reply-To: <20260615-lm25066-cl-config-v2-1-59be46e67d5a@gmail.com>
On Mon, Jun 15, 2026 at 11:07:13AM +0800, Potin Lai wrote:
> Add a 'ti,current-limit' string property to configure the device's Current
> Limit (CL) behavior to "high" or "low".
>
> LM25056 does not support setting the current limit via software, so
> disallow this property for it.
Then which device supports it? Your commit msg should explain WHY you
are doing this, not WHAT you are doing (unless that is not obvious). The
reason WHY is for some device. You just explainde WHY NOT doing that...
>
> Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> ---
> .../devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> index a20f140dc79a..53ee98e871ff 100644
> --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> @@ -46,12 +46,30 @@ properties:
>
> additionalProperties: false
>
> + ti,current-limit:
> + description: |
> + Configure the current limit setting. When present, this property
> + overrides the hardware setting of the physical CL pin by configuring
> + the register.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum:
> + - low
> + - high
What is the meaning of low and high? Maybe these map to specific values?
Docs are saying 25 or 46 mV, so maybe there is no direct mapping. Anyway
commit msg could also explain that.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 7/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Zhang Yi @ 2026-06-15 6:07 UTC (permalink / raw)
To: krzk
Cc: alsa-devel, broonie, conor+dt, devicetree, krzk+dt, robh, tiwai,
zhangyi
In-Reply-To: <fa710884-e66e-4ef8-bbbd-034eeef8ee62@kernel.org>
> >>> + $ref: /schemas/types.yaml#/definitions/flag
> >>> + description:
> >>> + Indicates that SCLK is used as the internal clock.
> >>
> >> And what happens with mclk in such case? Is it still wired?
> >
> > Yes, setting mclk-from-sclk does not affect the MCLK connection.
>
> I am asking about wiring of the device. If MCLK is used from SCLK, but
> SCLK is used as the internal clock, then how can you still have MCLK
> connected?
If MCLK is derived from SCLK, whether the 'MCLK' pin on the device is
connected or not has no effect on operation.
> >>> +
> >>> + everest,hpfl:
> >>> + $ref: /schemas/types.yaml#/definitions/uint8
> >>> + description:
> >>> + the HPF value of ADCL.
> >>
> >> Is HPF value in dB? If so, use proper unit suffix and proper units.
> >
> > No, the values here correspond to the values in the registers.
> > The value is not in dB
>
> What are the meanings of the register values?
The value of everest,hpfl is equal to the value of the corresponding register,
not the cutoff frequency of the HPF.
The code does not specify which register corresponds to which HPF cutoff frequency.
And we did not set the HPF to kcontrol because we do not want users to be able to control it
while the codec is running.
> >>> + everest,hpfl = [0a];
> >>
> >> <0xa>? What did you want to say here?
> >
> > I just wanted to give an example to show how to set the values of everest,hpfl to 0x0a.
>
> So use syntax I asked.
OK
If you receive this email, please reply to me.
(I'm worried that the issue with not receiving emails might happen again.)
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: clock: ultrarisc: Add DP1000 Clock Controller
From: Jia Wang @ 2026-06-15 6:07 UTC (permalink / raw)
To: Conor Dooley
Cc: wangjia, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-clk,
devicetree, linux-kernel
In-Reply-To: <20260611-reformist-wish-75a73a1d2c49@spud>
On 2026-06-11 18:29 +0100, Conor Dooley wrote:
> On Thu, Jun 11, 2026 at 05:40:53PM +0800, Jia Wang via B4 Relay wrote:
> > From: Jia Wang <wangjia@ultrarisc.com>
> >
> > Add doc for the clock controller on the UltraRISC DP1000 RISC-V SoC.
> >
> > Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> > ---
> > .../bindings/clock/ultrarisc,dp1000-clk.yaml | 72 ++++++++++++++++++++++
> > MAINTAINERS | 7 +++
> > include/dt-bindings/clock/ultrarisc,dp1000-clk.h | 29 +++++++++
> > 3 files changed, 108 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml b/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> > new file mode 100644
> > index 000000000000..d4d3d851a079
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> > @@ -0,0 +1,72 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/ultrarisc,dp1000-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: UltraRISC DP1000 Clock Controller
> > +
> > +maintainers:
> > + - Jia Wang <wangjia@ultrarisc.com>
> > +
> > +description: |
> > + The UltraRISC DP1000 clock controller is driven from a single external
> > + oscillator input. It provides a system PLL with fractional multiplier
> > + and post-divider stages, several fixed-ratio derived clocks for
> > + the on-chip subsystem, Clock Configuration Register (CCR) divider
> > + outputs for GMAC and the UART, I2C, and SPI root clocks, and
> > + per-instance gate clocks for UART0-3, I2C0-3, and SPI0-1.
> > +
> > + All available clocks are defined as preprocessor macros in
> > + include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> > +
> > +properties:
> > + compatible:
> > + const: ultrarisc,dp1000-clk
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > + description:
> > + External oscillator input clock used as the parent of the PLLs.
> > +
> > + clock-names:
> > + items:
> > + - const: osc
>
> Clock names don't really have any value when you have one input clock.
>
Thanks, I’ll drop clock-names in the next version.
> > +
> > + "#clock-cells":
> > + const: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > + - "#clock-cells"
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/ultrarisc,dp1000-clk.h>
> > +
> > + osc: oscillator {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <24000000>;
> > + };
>
> Drop this whole node please.
>
I'll drop this node in the next version.
> > +
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + clock-controller@11080000 {
> > + compatible = "ultrarisc,dp1000-clk";
> > + reg = <0x0 0x11080000 0x0 0x1000>;
> > + clocks = <&osc>;
> > + clock-names = "osc";
> > + #clock-cells = <1>;
> > + };
> > + };
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e035a3be797c..3331f1edf002 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -27357,6 +27357,13 @@ S: Maintained
> > F: drivers/usb/common/ulpi.c
> > F: include/linux/ulpi/
> >
> > +ULTRARISC DP1000 CLOCK DRIVER
> > +M: Jia Wang <wangjia@ultrarisc.com>
> > +L: linux-clk@vger.kernel.org
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> > +F: include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> > +
> > ULTRATRONIK BOARD SUPPORT
> > M: Goran Rađenović <goran.radni@gmail.com>
> > M: Börge Strümpfel <boerge.struempfel@gmail.com>
> > diff --git a/include/dt-bindings/clock/ultrarisc,dp1000-clk.h b/include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> > new file mode 100644
> > index 000000000000..5e484f652b08
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> > @@ -0,0 +1,29 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +#ifndef _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H
> > +#define _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H
> > +
> > +#define DP1000_CLK_SYSPLL 0
> > +#define DP1000_CLK_SYSPLL_DIV2 1
> > +#define DP1000_CLK_SUBSYS 2
> > +#define DP1000_CLK_GMAC 3
> > +#define DP1000_CLK_UART_ROOT 4
> > +#define DP1000_CLK_I2C_ROOT 5
> > +#define DP1000_CLK_SPI_ROOT 6
> > +#define DP1000_CLK_PCIE_DBI 7
> > +#define DP1000_CLK_PCIEX4_CORE 8
> > +#define DP1000_CLK_PCIEX16_CORE 9
> > +#define DP1000_CLK_PCIE_AUX 10
> > +#define DP1000_CLK_UART0 11
> > +#define DP1000_CLK_UART1 12
> > +#define DP1000_CLK_UART2 13
> > +#define DP1000_CLK_UART3 14
> > +#define DP1000_CLK_I2C0 15
> > +#define DP1000_CLK_I2C1 16
> > +#define DP1000_CLK_I2C2 17
> > +#define DP1000_CLK_I2C3 18
> > +#define DP1000_CLK_SPI0 19
> > +#define DP1000_CLK_SPI1 20
> > +
>
> > +#define DP1000_CLK_NUM 21
>
> This is not suitable to have in a binding, move it to the driver if it
> is required.
> pw-bot: changes-requested
>
I'll move DP1000_CLK_NUM to the driver.
> Cheers,
> Conor.
>
> > +
> > +#endif /* _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H */
> >
> > --
> > 2.34.1
> >
> >
Best regards,
Jia Wang
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: usb: Add ITE IT885x support
From: sashiko-bot @ 2026-06-15 6:03 UTC (permalink / raw)
To: Amber Kao; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260615-ucsi-itepd-feature-v1-1-a826cfd0df6a@ite.com.tw>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The device tree binding defines a generic `gpios` property and redundantly maps it to the exact same hardware pin as the `interrupts` property, which is a structural anti-pattern.
- [Low] The device tree binding example uses a vendor-specific node name instead of a generic functional name.
--
commit db50e109009ce6583e099c466366e81f9dc8a5ee
Author: Amber Kao <amber.kao@ite.com.tw>
dt-bindings: usb: Add ITE IT885x support
Add device tree binding documentation for the ITE IT885x. The ITE IT885x is
an I2C-based USB Type-C Power Delivery (PD) controller.
> diff --git a/Documentation/devicetree/bindings/usb/ite,itepd-it885x.yaml b/Documentation/devicetree/bindings/usb/ite,itepd-it885x.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ite,itepd-it885x.yaml
[ ... ]
> +properties:
> + compatible:
> + const: ite,itepd-it885x
> +
> + reg:
> + maxItems: 1
> +
> + gpios:
> + maxItems: 1
[Severity: Low]
Does this property need a functional prefix? Device tree schemas generally
require GPIO consumers to have a prefix, such as irq-gpios, rather than
using the bare gpios property.
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + itepd@40 {
[Severity: Low]
Should this node name use a generic functional name instead of a vendor
specific one? A generic name like typec@40 or usb-typec@40 would align
better with the devicetree specification recommendations.
> + compatible = "ite,itepd-it885x";
> + reg = <0x40>;
> + gpios = <&tlmm 129 GPIO_ACTIVE_LOW>;
> + interrupts-extended = <&tlmm 129 IRQ_TYPE_EDGE_FALLING>;
[Severity: Low]
Is it necessary to map the exact same physical pin to both gpios and
interrupts-extended here? If this is used merely to poll the interrupt line
state during probe, the hardware description shouldn't encode software
workarounds.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-ucsi-itepd-feature-v1-0-a826cfd0df6a@ite.com.tw?part=1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox