* Re: [PATCH v4 1/3] iio: adc: Fix incorrect reading when datarate changed in single mode
From: sashiko-bot @ 2026-06-22 22:33 UTC (permalink / raw)
To: Jakub Szczudlo; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260622221550.374235-2-jakubszczudlo40@gmail.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
New issues:
- [High] I2C read failures inside the polling loop are improperly mapped to 'device busy', causing a 7.5-second hang and massive dmesg log flooding.
- [High] The data ready polling logic fails to synchronize because the ST/BSY bit is likely static in continuous conversion mode.
- [Medium] The `ads1100_poll_data_ready` function performs a completely redundant I2C read that wastes bus bandwidth.
Pre-existing issues:
- [High] The return value of `ads1100_set_config_bits` is ignored in `ads1100_set_scale`, leading to silent configuration failures.
- [High] Reading the ADC result immediately after runtime resume returns an invalid or stale conversion.
- [High] I2C read functions allocate transfer buffers on the stack, which is unsafe for DMA operations.
--
commit 06506d1fcb678ffc0137dbc1df3913f95ce47327
Author: Jakub Szczudlo <jakubszczudlo40@gmail.com>
Subject: iio: adc: Fix incorrect reading when datarate changed in single mode
This commit attempts to fix incorrect ADC readings after changing
datarate or gain while suspended in single mode. It introduces a
polling loop to wait for new data before returning from the configuration
functions.
> diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
> index 9fe8d54cce83c..e3c801381434d 100644
> --- a/drivers/iio/adc/ti-ads1100.c
> +++ b/drivers/iio/adc/ti-ads1100.c
[ ... ]
> @@ -123,10 +127,49 @@ static int ads1100_get_adc_result(struct ads1100_data *data, int chan, int *val)
> return 0;
> }
[Severity: High]
This is a pre-existing issue, but doesn't reading the ADC result immediately
after runtime resume return an invalid or stale conversion?
Looking at ads1100_get_adc_result():
ret = pm_runtime_resume_and_get(&data->client->dev);
if (ret < 0)
return ret;
ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
When the device auto-suspends, a subsequent sysfs read of in_voltage0_raw
calls pm_runtime_resume_and_get(), which transitions the ADC to continuous
mode and starts a new conversion. However, ads1100_get_adc_result()
immediately reads the I2C output register without waiting for the conversion
to complete, which can take up to 125ms at 8 SPS.
> +static bool ads1100_new_data_not_ready(struct ads1100_data *data)
> +{
> + int ret;
> + u8 buffer[3];
> +
> + ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
[Severity: High]
This isn't a bug introduced by this patch, but is it safe to use
stack-allocated buffers for I2C transfers?
Using stack-allocated buffers for I2C transfers violates subsystem rules and
can lead to memory corruption or kernel panics on architectures where
CONFIG_VMAP_STACK is enabled and the underlying I2C controller utilizes DMA.
> + if (ret < 0) {
> + dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
> + return true;
[Severity: High]
Does returning true on hard I2C errors trap the driver in an infinite polling
loop?
Returning true signals to the read_poll_timeout() macro that the device is
merely not ready, causing it to endlessly retry for up to 7.5 seconds instead
of aborting. This masks the actual I2C error code with -ETIMEDOUT and
generates massive dmesg log flooding.
> + } else if (ret < 3) {
> + dev_err(&data->client->dev, "Short I2C read\n");
> + return true;
> + }
> +
> + return FIELD_GET(ADS1100_CFG_ST_BSY, buffer[2]);
[Severity: High]
Will this polling logic synchronize properly in continuous conversion mode?
When changing scale or datarate, PM_RUNTIME_ACQUIRE_AUTOSUSPEND() is called,
transitioning the ADC to continuous conversion mode. In continuous conversion
mode on these TI ADCs, the ST_BSY bit does not pulse to indicate new data;
it is typically static.
If ST_BSY reads as 0, ads1100_new_data_not_ready() returns false, breaking the
loop instantly. If it reads as 1, the driver would hang for 7.5 seconds.
> +}
> +
> +static int ads1100_poll_data_ready(struct ads1100_data *data)
> +{
> + int ret;
> + u8 buffer[3];
> + bool data_ready;
> + int datarate = ads1100_data_rate[FIELD_GET(ADS1100_DR_MASK, data->config)];
> + /* To be sure we wait 5 times more than datarate */
> + unsigned long wait_time = DIV_ROUND_CLOSEST(MICRO, 5 * datarate);
> +
> + /* To be sure that polled value will have value after config change */
> + ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
[Severity: Medium]
Is this initial I2C read redundant?
Executing ads1100_poll_data_ready() triggers this initial i2c_master_recv(),
discards the populated local buffer, and immediately enters
read_poll_timeout() with sleep_before_read = false. This instantly performs
another identical i2c_master_recv() inside ads1100_new_data_not_ready(),
needlessly occupying the I2C bus.
[ ... ]
> @@ -149,19 +198,36 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
>
> ads1100_set_config_bits(data, ADS1100_PGA_MASK, ffs(gain) - 1);
>
> - return 0;
> + ret = ads1100_poll_data_ready(data);
> +
> + return ret;
> }
[Severity: High]
This is a pre-existing issue, but does ads1100_set_scale() ignore the return
value of ads1100_set_config_bits()?
If the I2C write to update the hardware PGA scale fails, the error is
discarded. The function proceeds to poll for new data and may eventually
return success to userspace.
This leads to silently corrupted or miscalculated voltage measurements because
the sysfs attribute appears to have updated while the ADC is physically
operating with the old scale.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622221550.374235-1-jakubszczudlo40@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v4 3/3] iio: adc: Add ti-ads1110 support to ti-ads1100 driver
From: sashiko-bot @ 2026-06-22 22:31 UTC (permalink / raw)
To: Jakub Szczudlo; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260622221550.374235-4-jakubszczudlo40@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Medium] Hardcoded IIO device name ignores the newly added device configuration name.
- [Medium] Hardcoded ads1100_data_rate array used instead of config-specific data_rate in ads1100_poll_data_ready.
Pre-existing issues:
- [High] Missing PM runtime resume on device removal causes an unbalanced regulator_disable() call.
--
commit d015d54867f4b919a8e4d7c10d3727993b652f65
Author: Jakub Szczudlo <jakubszczudlo40@gmail.com>
iio: adc: Add ti-ads1110 support to ti-ads1100 driver
Add ADS1110 support that have faster datarate than ADS1100, it also uses
internal voltage reference of 2.048V for measurement.
> diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
> index e3c801381434d..ec79a89464fb6 100644
> --- a/drivers/iio/adc/ti-ads1100.c
> +++ b/drivers/iio/adc/ti-ads1100.c
> @@ -40,20 +40,44 @@
> #define ADS1100_SINGLESHOT ADS1100_CFG_SC
>
> #define ADS1100_SLEEP_DELAY_MS 2000
> +#define ADS1110_INTERNAL_REF_mV 2048
>
> static const int ads1100_data_rate[] = { 128, 32, 16, 8 };
> +static const int ads1110_data_rate[] = { 240, 60, 30, 15 };
[Severity: Medium]
Will this result in using the slower ads1100_data_rate array for the ADS1110
when polling for data readiness?
Looking at ads1100_poll_data_ready(), it still accesses the hardcoded
ads1100_data_rate array directly:
static int ads1100_poll_data_ready(struct ads1100_data *data)
{
...
int datarate = ads1100_data_rate[FIELD_GET(ADS1100_DR_MASK, data->config)];
/* To be sure we wait 5 times more than datarate */
unsigned long wait_time = DIV_ROUND_CLOSEST(MICRO, 5 * datarate);
...
}
Should this be updated to use data->ads_config->data_rate instead?
[ ... ]
> @@ -404,6 +436,13 @@ static int ads1100_probe(struct i2c_client *client)
> if (ret)
> return ret;
>
> + model = i2c_get_match_data(client);
> + if (!model)
> + return dev_err_probe(dev, -EINVAL,
> + "Can't get device data from firmware\n");
> +
> + data->ads_config = (struct ads1100_config *)model;
> +
[Severity: Medium]
Does this ignore the newly added device configuration name for the IIO device?
In ads1100_probe(), indio_dev->name is hardcoded earlier in the function:
indio_dev->name = "ads1100";
Should this be updated to use data->ads_config->name so the user-space
sysfs name correctly identifies the ADS1110?
[Severity: High]
This is a pre-existing issue, but does the lack of a PM runtime resume on
device removal cause an unbalanced regulator disable?
If the device auto-suspends during runtime idle, the vdd regulator is disabled
via ads1100_runtime_suspend():
static int ads1100_runtime_suspend(struct device *dev)
{
...
regulator_disable(data->reg_vdd);
...
}
When the driver is unbound, devres calls pm_runtime_disable() (which does not
resume the device), followed by ads1100_reg_disable() which attempts to call
regulator_disable() again on the already-disabled regulator, triggering a
kernel WARNING.
Could we ensure the device is resumed during driver unbind to prevent this?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622221550.374235-1-jakubszczudlo40@gmail.com?part=3
^ permalink raw reply
* [PATCH v4 3/3] iio: adc: Add ti-ads1110 support to ti-ads1100 driver
From: Jakub Szczudlo @ 2026-06-22 22:15 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt,
linusw, jakubszczudlo40, linux-kernel, marcelo.schmitt,
mazziesaccount, mike.looijmans, nuno.sa, robh, sakari.ailus, wens
In-Reply-To: <20260622221550.374235-1-jakubszczudlo40@gmail.com>
Add ADS1110 support that have faster datarate than ADS1100, it also uses
internal voltage reference of 2.048V for measurement.
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
drivers/iio/adc/Kconfig | 6 +--
drivers/iio/adc/ti-ads1100.c | 81 +++++++++++++++++++++++++++---------
2 files changed, 64 insertions(+), 23 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 1c663c98c6c9..30198335c63b 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -1765,11 +1765,11 @@ config TI_ADS1018
called ti-ads1018.
config TI_ADS1100
- tristate "Texas Instruments ADS1100 and ADS1000 ADC"
+ tristate "Texas Instruments ADS1100 and similar single channel I2C ADC"
depends on I2C
help
- If you say yes here you get support for Texas Instruments ADS1100 and
- ADS1000 ADC chips.
+ If you say yes here you get support TI ADS1100 and similar single
+ channel I2C Analog to Digital Converters.
This driver can also be built as a module. If so, the module will be
called ti-ads1100.
diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
index e3c801381434..ec79a89464fb 100644
--- a/drivers/iio/adc/ti-ads1100.c
+++ b/drivers/iio/adc/ti-ads1100.c
@@ -5,7 +5,7 @@
* Copyright (c) 2023, Topic Embedded Products
*
* Datasheet: https://www.ti.com/lit/gpn/ads1100
- * IIO driver for ADS1100 and ADS1000 ADC 16-bit I2C
+ * IIO driver for ADS1100 and similar single channel ADC 16-bit I2C
*/
#include <linux/bitfield.h>
@@ -40,20 +40,44 @@
#define ADS1100_SINGLESHOT ADS1100_CFG_SC
#define ADS1100_SLEEP_DELAY_MS 2000
+#define ADS1110_INTERNAL_REF_mV 2048
static const int ads1100_data_rate[] = { 128, 32, 16, 8 };
+static const int ads1110_data_rate[] = { 240, 60, 30, 15 };
static const int ads1100_data_rate_bits[] = { 12, 14, 15, 16 };
/* Timeout based on the minimum sample rate of 8 SPS (7.5s) */
#define ADS1100_MAX_DRDY_TIMEOUT_US 7500000
+struct ads1100_config {
+ const char *name;
+ const int *data_rate;
+ const int data_rate_count;
+ bool has_internal_vref_only;
+};
+
+static const struct ads1100_config ads1100_config = {
+ .name = "ads1100",
+ .data_rate = ads1100_data_rate,
+ .data_rate_count = ARRAY_SIZE(ads1100_data_rate),
+ .has_internal_vref_only = false,
+};
+
+static const struct ads1100_config ads1110_config = {
+ .name = "ads1110",
+ .data_rate = ads1110_data_rate,
+ .data_rate_count = ARRAY_SIZE(ads1110_data_rate),
+ .has_internal_vref_only = true,
+};
+
struct ads1100_data {
struct i2c_client *client;
struct regulator *reg_vdd;
struct mutex lock;
int scale_avail[2 * 4]; /* 4 gain settings */
+ const struct ads1100_config *ads_config;
u8 config;
- bool supports_data_rate; /* Only the ADS1100 can select the rate */
+ bool supports_data_rate;
};
static const struct iio_chan_spec ads1100_channel = {
@@ -89,6 +113,14 @@ static int ads1100_set_config_bits(struct ads1100_data *data, u8 mask, u8 value)
return 0;
};
+static int ads1100_get_vref_milivolts(struct ads1100_data *data)
+{
+ if (data->ads_config->has_internal_vref_only)
+ return ADS1110_INTERNAL_REF_mV;
+
+ return regulator_get_voltage(data->reg_vdd) / MILLI;
+}
+
static int ads1100_data_bits(struct ads1100_data *data)
{
return ads1100_data_rate_bits[FIELD_GET(ADS1100_DR_MASK, data->config)];
@@ -114,6 +146,9 @@ static int ads1100_get_adc_result(struct ads1100_data *data, int chan, int *val)
if (ret < 0) {
dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
return ret;
+ } else if (ret < 2) {
+ dev_err(&data->client->dev, "Short I2C read\n");
+ return -EIO;
}
/* Value is always 16-bit 2's complement */
@@ -184,7 +219,7 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
if (ret)
return ret;
- microvolts = regulator_get_voltage(data->reg_vdd);
+ microvolts = ads1100_get_vref_milivolts(data) * (MICRO / MILLI);
/*
* val2 is in 'micro' units, n = val2 / 1000000
* result must be millivolts, d = microvolts / 1000
@@ -209,9 +244,9 @@ static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
unsigned int size;
int ret;
- size = data->supports_data_rate ? ARRAY_SIZE(ads1100_data_rate) : 1;
+ size = data->supports_data_rate ? data->ads_config->data_rate_count : 1;
for (i = 0; i < size; i++) {
- if (ads1100_data_rate[i] != rate)
+ if (data->ads_config->data_rate[i] != rate)
continue;
PM_RUNTIME_ACQUIRE_AUTOSUSPEND(&data->client->dev, pm);
@@ -233,14 +268,9 @@ static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
return -EINVAL;
}
-static int ads1100_get_vdd_millivolts(struct ads1100_data *data)
-{
- return regulator_get_voltage(data->reg_vdd) / (MICRO / MILLI);
-}
-
static void ads1100_calc_scale_avail(struct ads1100_data *data)
{
- int millivolts = ads1100_get_vdd_millivolts(data);
+ int millivolts = ads1100_get_vref_milivolts(data);
unsigned int i;
for (i = 0; i < ARRAY_SIZE(data->scale_avail) / 2; i++) {
@@ -262,9 +292,9 @@ static int ads1100_read_avail(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_SAMP_FREQ:
*type = IIO_VAL_INT;
- *vals = ads1100_data_rate;
+ *vals = data->ads_config->data_rate;
if (data->supports_data_rate)
- *length = ARRAY_SIZE(ads1100_data_rate);
+ *length = data->ads_config->data_rate_count;
else
*length = 1;
return IIO_AVAIL_LIST;
@@ -283,6 +313,7 @@ static int ads1100_read_raw(struct iio_dev *indio_dev,
int *val2, long mask)
{
int ret;
+ int data_rate_index;
struct ads1100_data *data = iio_priv(indio_dev);
guard(mutex)(&data->lock);
@@ -299,12 +330,12 @@ static int ads1100_read_raw(struct iio_dev *indio_dev,
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
/* full-scale is the supply voltage in millivolts */
- *val = ads1100_get_vdd_millivolts(data);
+ *val = ads1100_get_vref_milivolts(data);
*val2 = 15 + FIELD_GET(ADS1100_PGA_MASK, data->config);
return IIO_VAL_FRACTIONAL_LOG2;
case IIO_CHAN_INFO_SAMP_FREQ:
- *val = ads1100_data_rate[FIELD_GET(ADS1100_DR_MASK,
- data->config)];
+ data_rate_index = FIELD_GET(ADS1100_DR_MASK, data->config);
+ *val = data->ads_config->data_rate[data_rate_index];
return IIO_VAL_INT;
default:
return -EINVAL;
@@ -373,6 +404,7 @@ static int ads1100_probe(struct i2c_client *client)
struct iio_dev *indio_dev;
struct ads1100_data *data;
struct device *dev = &client->dev;
+ const struct ads1100_config *model;
int ret;
indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
@@ -404,6 +436,13 @@ static int ads1100_probe(struct i2c_client *client)
if (ret)
return ret;
+ model = i2c_get_match_data(client);
+ if (!model)
+ return dev_err_probe(dev, -EINVAL,
+ "Can't get device data from firmware\n");
+
+ data->ads_config = (struct ads1100_config *)model;
+
ret = ads1100_setup(data);
if (ret)
return dev_err_probe(dev, ret,
@@ -466,16 +505,18 @@ static DEFINE_RUNTIME_DEV_PM_OPS(ads1100_pm_ops,
NULL);
static const struct i2c_device_id ads1100_id[] = {
- { .name = "ads1100" },
- { .name = "ads1000" },
+ { .name = "ads1000", .driver_data = (kernel_ulong_t)&ads1100_config },
+ { .name = "ads1100", .driver_data = (kernel_ulong_t)&ads1100_config },
+ { .name = "ads1110", .driver_data = (kernel_ulong_t)&ads1110_config },
{ }
};
MODULE_DEVICE_TABLE(i2c, ads1100_id);
static const struct of_device_id ads1100_of_match[] = {
- {.compatible = "ti,ads1100" },
- {.compatible = "ti,ads1000" },
+ { .compatible = "ti,ads1000", .data = &ads1100_config },
+ { .compatible = "ti,ads1100", .data = &ads1100_config },
+ { .compatible = "ti,ads1110", .data = &ads1110_config },
{ }
};
--
2.47.3
^ permalink raw reply related
* [PATCH v4 2/3] dt-bindings: iio: adc: ti,ads1100: add support for ADS1110
From: Jakub Szczudlo @ 2026-06-22 22:15 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt,
linusw, jakubszczudlo40, linux-kernel, marcelo.schmitt,
mazziesaccount, mike.looijmans, nuno.sa, robh, sakari.ailus, wens,
Krzysztof Kozlowski
In-Reply-To: <20260622221550.374235-1-jakubszczudlo40@gmail.com>
Register layouts are the same as for ADS1100 but ADS1110 have different
data rates and have internal voltage reference that is always 2.048V.
Also correct order of ads so they will be sorted alphabetically.
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/iio/adc/ti,ads1100.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
index 970ccab15e1e..28c5e2dd0ad6 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
@@ -4,19 +4,23 @@
$id: http://devicetree.org/schemas/iio/adc/ti,ads1100.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI ADS1100/ADS1000 single channel I2C analog to digital converter
+title: TI ADS1100 and similar single channel I2C Analog to Digital Converters
maintainers:
- Mike Looijmans <mike.looijmans@topic.nl>
description: |
- Datasheet at: https://www.ti.com/lit/gpn/ads1100
+ Datasheets:
+ - https://www.ti.com/lit/gpn/ads1000
+ - https://www.ti.com/lit/gpn/ads1100
+ - https://www.ti.com/lit/gpn/ads1110
properties:
compatible:
enum:
- - ti,ads1100
- ti,ads1000
+ - ti,ads1100
+ - ti,ads1110
reg:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH v4 1/3] iio: adc: Fix incorrect reading when datarate changed in single mode
From: Jakub Szczudlo @ 2026-06-22 22:15 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt,
linusw, jakubszczudlo40, linux-kernel, marcelo.schmitt,
mazziesaccount, mike.looijmans, nuno.sa, robh, sakari.ailus, wens
In-Reply-To: <20260622221550.374235-1-jakubszczudlo40@gmail.com>
When device is suspended and it is in single mode then changing
datarate doesn't make it actual wait for new measurement, so to
be sure that read after change is correct functions that changes
datarate and gain will wait for new data.
Fixes: 541880542f2b ("iio: adc: Add TI ADS1100 and ADS1000")
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
drivers/iio/adc/ti-ads1100.c | 74 ++++++++++++++++++++++++++++++++++--
1 file changed, 70 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
index 9fe8d54cce83..e3c801381434 100644
--- a/drivers/iio/adc/ti-ads1100.c
+++ b/drivers/iio/adc/ti-ads1100.c
@@ -15,6 +15,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/i2c.h>
+#include <linux/iopoll.h>
#include <linux/mutex.h>
#include <linux/property.h>
#include <linux/pm_runtime.h>
@@ -43,6 +44,9 @@
static const int ads1100_data_rate[] = { 128, 32, 16, 8 };
static const int ads1100_data_rate_bits[] = { 12, 14, 15, 16 };
+/* Timeout based on the minimum sample rate of 8 SPS (7.5s) */
+#define ADS1100_MAX_DRDY_TIMEOUT_US 7500000
+
struct ads1100_data {
struct i2c_client *client;
struct regulator *reg_vdd;
@@ -123,10 +127,49 @@ static int ads1100_get_adc_result(struct ads1100_data *data, int chan, int *val)
return 0;
}
+static bool ads1100_new_data_not_ready(struct ads1100_data *data)
+{
+ int ret;
+ u8 buffer[3];
+
+ ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
+ if (ret < 0) {
+ dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
+ return true;
+ } else if (ret < 3) {
+ dev_err(&data->client->dev, "Short I2C read\n");
+ return true;
+ }
+
+ return FIELD_GET(ADS1100_CFG_ST_BSY, buffer[2]);
+}
+
+static int ads1100_poll_data_ready(struct ads1100_data *data)
+{
+ int ret;
+ u8 buffer[3];
+ bool data_ready;
+ int datarate = ads1100_data_rate[FIELD_GET(ADS1100_DR_MASK, data->config)];
+ /* To be sure we wait 5 times more than datarate */
+ unsigned long wait_time = DIV_ROUND_CLOSEST(MICRO, 5 * datarate);
+
+ /* To be sure that polled value will have value after config change */
+ ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
+ if (ret < 0) {
+ dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
+ return ret;
+ }
+
+ return read_poll_timeout(ads1100_new_data_not_ready, data_ready,
+ !data_ready, wait_time,
+ ADS1100_MAX_DRDY_TIMEOUT_US, false, data);
+}
+
static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
{
int microvolts;
int gain;
+ int ret;
/* With Vdd between 2.7 and 5V, the scale is always below 1 */
if (val)
@@ -135,6 +178,12 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
if (!val2)
return -EINVAL;
+ PM_RUNTIME_ACQUIRE_AUTOSUSPEND(&data->client->dev, pm);
+
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
+ return ret;
+
microvolts = regulator_get_voltage(data->reg_vdd);
/*
* val2 is in 'micro' units, n = val2 / 1000000
@@ -149,19 +198,36 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
ads1100_set_config_bits(data, ADS1100_PGA_MASK, ffs(gain) - 1);
- return 0;
+ ret = ads1100_poll_data_ready(data);
+
+ return ret;
}
static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
{
unsigned int i;
unsigned int size;
+ int ret;
size = data->supports_data_rate ? ARRAY_SIZE(ads1100_data_rate) : 1;
for (i = 0; i < size; i++) {
- if (ads1100_data_rate[i] == rate)
- return ads1100_set_config_bits(data, ADS1100_DR_MASK,
- FIELD_PREP(ADS1100_DR_MASK, i));
+ if (ads1100_data_rate[i] != rate)
+ continue;
+
+ PM_RUNTIME_ACQUIRE_AUTOSUSPEND(&data->client->dev, pm);
+
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
+ return ret;
+
+ ret = ads1100_set_config_bits(data, ADS1100_DR_MASK,
+ FIELD_PREP(ADS1100_DR_MASK, i));
+ if (ret)
+ return ret;
+
+ ret = ads1100_poll_data_ready(data);
+
+ return ret;
}
return -EINVAL;
--
2.47.3
^ permalink raw reply related
* [PATCH v4 0/3] iio: adc: Add support for TI ADS1110 to ti-ads1100 driver
From: Jakub Szczudlo @ 2026-06-22 22:15 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt,
linusw, jakubszczudlo40, linux-kernel, marcelo.schmitt,
mazziesaccount, mike.looijmans, nuno.sa, robh, sakari.ailus, wens
Add support for the TI ADS1110 to the existing ADS1100 ADC IIO driver.
The ADS1110 is pin-to-pin compatible with the ADS1100 while providing
higher resolution and an internal voltage reference. This patch series
extends driver support for ADS1110, updates device tree bindings and
Kconfig text, and improves the overall hardware description for the
TI ADS1100 family.
Tested on: Raspberry pi 3b+ with 7.0 stable kernel
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
V3 -> V4:
- make fixes patch the first change in the series
- correct error handling when short read
- use ACQUIRE macros from pm_runtime.h in new functions
- Link to v3: https://lore.kernel.org/linux-iio/20260613190957.654798-1-jakubszczudlo40@gmail.com/
V2 -> V3:
- clean patch from unreleated changes
- divide adding support for ads1110 into separate patch
- add missing changelog
- Link to v2: https://lore.kernel.org/linux-iio/20260607183542.368184-1-jakubszczudlo40@gmail.com/
V1 -> V2:
- go from creating new driver to extending ADS1100 driver to support ADS1110
- Link to v1: https://lore.kernel.org/linux-iio/20260527164312.355729-1-jakubszczudlo40@gmail.com/
Jakub Szczudlo (3):
iio: adc: Fix incorrect reading when datarate changed in single mode
dt-bindings: iio: adc: ti,ads1100: add support for ADS1110
iio: adc: Add ti-ads1110 support to ti-ads1100 driver
.../bindings/iio/adc/ti,ads1100.yaml | 10 +-
drivers/iio/adc/Kconfig | 6 +-
drivers/iio/adc/ti-ads1100.c | 153 +++++++++++++++---
3 files changed, 140 insertions(+), 29 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH 2/2] arm64: tegra: Fix CMDQV interrupt type on Tegra264
From: Nicolin Chen @ 2026-06-22 20:58 UTC (permalink / raw)
To: Ashish Mhetre
Cc: joro, will, robin.murphy, robh, krzk+dt, conor+dt, jonathanh,
thierry.reding, iommu, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260622065410.2780215-2-amhetre@nvidia.com>
On Mon, Jun 22, 2026 at 06:54:10AM +0000, Ashish Mhetre wrote:
> The CMDQV interrupts on Tegra264 are described as level-triggered, but
> per the hardware interrupt documentation these interrupts are actually
> edge-triggered.
>
> Correct the interrupt type for all CMDQV nodes from IRQ_TYPE_LEVEL_HIGH
> to IRQ_TYPE_EDGE_RISING.
>
> Fixes: fe57d0ac4835 ("arm64: tegra: Add nodes for CMDQV")
> Reported-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Acked-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iommu: Fix interrupt type in example
From: Nicolin Chen @ 2026-06-22 20:52 UTC (permalink / raw)
To: Ashish Mhetre
Cc: joro, will, robin.murphy, robh, krzk+dt, conor+dt, jonathanh,
thierry.reding, iommu, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260622065410.2780215-1-amhetre@nvidia.com>
On Mon, Jun 22, 2026 at 06:54:09AM +0000, Ashish Mhetre wrote:
> The CMDQV interrupt on Tegra264 is edge-triggered per the hardware
> interrupt documentation, but the binding example describes it as
> level-triggered. Correct the example to use IRQ_TYPE_EDGE_RISING so
> that it does not propagate the wrong trigger type.
>
> Fixes: 8a59954192eb ("dt-bindings: iommu: Add NVIDIA Tegra CMDQV support")
> Reported-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Acked-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH v5 2/3] counter: add GPIO-based counter driver
From: Wadim Mueller @ 2026-06-22 20:51 UTC (permalink / raw)
To: William Breathitt Gray
Cc: Oleksij Rempel, kernel, conor+dt, krzk+dt, robh, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260617074929.333876-1-wbg@kernel.org>
On Wed, 17 Jun 2026 16:49:25 +0900
William Breathitt Gray <wbg@kernel.org> wrote:
Hi William,
thanks for the review. Three things before I spin v6.
> One change I consider is whether to make Signal B optional. [...]
> I wonder whether this is substantially different enough from
> simply using the interrupt-cnt module on the respective IRQ?
> I'm CCing Oleksij and the Pengutronix team in case they wish to
> comment.
I want to keep signal-b mandatory in v6 (if no concerns from Oleksij). The single-line case is
already covered by interrupt-cnt.
> In such a configuration, we would have two Counts: Count 1 [...]
> Count 2 supports only increase/decrease modes with a Synapse for
> Signal B.
Just to confirm, plan for v6 is:
Count 0 "AB Count": A + B + optional index0, all 8 functions
Count 1 "B Count": B + optional index1, increase/decrease only
One counter_ops, dispatch on count->id. Per-count state in
struct gpio_counter_count_priv (value, ceiling, preset, preset_enabled,
enabled, function, direction), held in priv->count_priv[2] as you
suggested. prev_a/prev_b stay on priv (they describe the wire, not
the count).
For the second Index in DT I would just let index-gpios take 1..2
entries (first = count0, second = count1), no new property. Ok for
you and Conor?
> Hmm, is it a problem that priv->enabled is changed to a false state
> before the IRQs are actually disabled? Do any issues arise if an IRQ
> is handled during that brief period of time?
I guess it is a race. In v6 I will reorder:
enable=1: enable_irq(); lock; enabled = true; unlock;
enable=0: lock; enabled = false; unlock; disable_irq();
Plus a mutex around enable_write so two writers can not interleave
(disable_irq() can not run under the spinlock).
All other points from your review (kill *_delta, STATE_CHANGED for
all quadrature modes, INC/DEC both edges, drop prev_a check in
pulse-direction, ...) go into v6 too.
action_write and floor in a follow-up, as you suggested.
Thanks,
Wadim
^ permalink raw reply
* Re: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
From: Markus Mayer @ 2026-06-22 20:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Florian Fainelli, Rob Herring, Conor Dooley,
Linux ARM Kernel List, Device Tree Mailing List,
Linux Kernel Mailing List
In-Reply-To: <CAGt4E5tGHJFXswic6vTx-ThN2K9xBtO8oA4ybrXg+q5cA6GYCA@mail.gmail.com>
On Thu, 28 May 2026 at 14:45, Markus Mayer <mmayer@broadcom.com> wrote:
> > > Thanks for providing justification, quite reasonable. A pity that none
> > > of the commit msgs answered this way.
> >
> > The real pity is how this API was designed, making all of this
> > necessary in the first place.
> >
> > We can definitely spell out more clearly in the commit messages what
> > is going on and why all of this is needed. I'll pull all the pieces
> > together from the various responses. As long as there's a way we can
> > reasonably implement what we need, we'll be happy.
>
> It has been a minute, but we'd like to resume this effort[1] to
> upstream these changes or some variation thereof.
>
> What are the best steps to resume this undertaking? There are still a
> few topics where I am not entirely clear on how to better explain
> things or how to address the feedback provided. My apologies for that.
> I will do my best to address whatever concerns there are.
>
> Should I put together a new pull request that contains improved commit
> messages and addresses some of the feedback and we hash out whatever
> questions remain on the new thread? Or would it be better for me to
> reply to the old thread with some of the questions that remain before
> sending a revised series?
Any advice on how to best proceed from here?
Thanks,
-Markus
> [1] https://lore.kernel.org/all/20231205184741.3092376-1-mmayer@broadcom.com/
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Sebastian Reichel @ 2026-06-22 20:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Javier Martinez Canillas, Liam Girdwood, Mark Brown,
Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
Hi,
On Mon, Jun 22, 2026 at 12:16:08PM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
> ---
[...]
> .../bindings/power/reset/restart-handler.yaml | 8 ++++----
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
[...]
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-22 20:05 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <f7aae511-0e23-41cf-a5b0-27782caac30b@baylibre.com>
On Mon Jun 22, 2026 at 3:01 PM -05, David Lechner wrote:
> On 6/22/26 2:58 PM, Kurt Borja wrote:
>> On Mon Jun 22, 2026 at 2:38 PM -05, David Lechner wrote:
>>> On 6/22/26 2:30 PM, Kurt Borja wrote:
>>>> Hi all,
>>>>
>>>> After submitting a patch series adding support for TI ADS126X ADCs [1],
>>>> I was made aware by David [2] that at least two more chip families,
>>>> ads1220 [3] and ads1x2c14, share very similar features (though these
>>>> chips are not really compatible between them). After that, I found one
>>>> more chip with the same features which is already upstream, the
>>>> AD4170-4.
>>>>
>>>> As David explained in [2], these chips are intended to be used with
>>>> RTDs, thermocouples or other resistive sensors so they share the
>>>> following per-channel features:
>>>>
>>>> - Configurable reference selection
>>>> - Burn-out Current Sources (BOCS) for diagnostic purpuses
>>>> - Excitation current sources (usually called IDACs TI) for sensor
>>>> current biasing
>>>>
>>>> Given that these three features are present in all four devices and
>>>> three of these drivers are still under review, my proposal is to have
>>>> these features be described in adc.yaml and have this series merged
>>>> before the three others [1] [2] [3].
>>>>
>>>> This series is sent as RFC because I still don't have much experience
>>>> with dt-bindings and I don't know if this approach or the properties are
>>>> general enough to be described like this.
>>>
>>> It will probably be easier if I just include these patches when I do
>>> v2 of my series (if you don't mind me tweaking them a bit).
>>
>> Sure, that's fine by me. I'll add a dependency to your series with b4.
>>
>> Want me to send one more version addressing your comments before you
>> take it in?
>>
>
> No need. I don't mind fixing it up.
Thanks :)
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: David Lechner @ 2026-06-22 20:01 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <DJFUE81GZEEG.35TP4FFBVE63B@gmail.com>
On 6/22/26 2:58 PM, Kurt Borja wrote:
> On Mon Jun 22, 2026 at 2:38 PM -05, David Lechner wrote:
>> On 6/22/26 2:30 PM, Kurt Borja wrote:
>>> Hi all,
>>>
>>> After submitting a patch series adding support for TI ADS126X ADCs [1],
>>> I was made aware by David [2] that at least two more chip families,
>>> ads1220 [3] and ads1x2c14, share very similar features (though these
>>> chips are not really compatible between them). After that, I found one
>>> more chip with the same features which is already upstream, the
>>> AD4170-4.
>>>
>>> As David explained in [2], these chips are intended to be used with
>>> RTDs, thermocouples or other resistive sensors so they share the
>>> following per-channel features:
>>>
>>> - Configurable reference selection
>>> - Burn-out Current Sources (BOCS) for diagnostic purpuses
>>> - Excitation current sources (usually called IDACs TI) for sensor
>>> current biasing
>>>
>>> Given that these three features are present in all four devices and
>>> three of these drivers are still under review, my proposal is to have
>>> these features be described in adc.yaml and have this series merged
>>> before the three others [1] [2] [3].
>>>
>>> This series is sent as RFC because I still don't have much experience
>>> with dt-bindings and I don't know if this approach or the properties are
>>> general enough to be described like this.
>>
>> It will probably be easier if I just include these patches when I do
>> v2 of my series (if you don't mind me tweaking them a bit).
>
> Sure, that's fine by me. I'll add a dependency to your series with b4.
>
> Want me to send one more version addressing your comments before you
> take it in?
>
No need. I don't mind fixing it up.
^ permalink raw reply
* Re: [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-22 19:58 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <42e544b8-f2da-450b-92bb-99c41f1c72fe@baylibre.com>
On Mon Jun 22, 2026 at 2:38 PM -05, David Lechner wrote:
> On 6/22/26 2:30 PM, Kurt Borja wrote:
>> Hi all,
>>
>> After submitting a patch series adding support for TI ADS126X ADCs [1],
>> I was made aware by David [2] that at least two more chip families,
>> ads1220 [3] and ads1x2c14, share very similar features (though these
>> chips are not really compatible between them). After that, I found one
>> more chip with the same features which is already upstream, the
>> AD4170-4.
>>
>> As David explained in [2], these chips are intended to be used with
>> RTDs, thermocouples or other resistive sensors so they share the
>> following per-channel features:
>>
>> - Configurable reference selection
>> - Burn-out Current Sources (BOCS) for diagnostic purpuses
>> - Excitation current sources (usually called IDACs TI) for sensor
>> current biasing
>>
>> Given that these three features are present in all four devices and
>> three of these drivers are still under review, my proposal is to have
>> these features be described in adc.yaml and have this series merged
>> before the three others [1] [2] [3].
>>
>> This series is sent as RFC because I still don't have much experience
>> with dt-bindings and I don't know if this approach or the properties are
>> general enough to be described like this.
>
> It will probably be easier if I just include these patches when I do
> v2 of my series (if you don't mind me tweaking them a bit).
Sure, that's fine by me. I'll add a dependency to your series with b4.
Want me to send one more version addressing your comments before you
take it in?
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH v4 01/16] spi: dt-bindings: add spi-max-post-config-frequency property
From: Conor Dooley @ 2026-06-22 19:46 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Santhosh Kumar K, broonie, robh, krzk+dt, conor+dt, miquel.raynal,
richard, vigneshr, pratyush, mwalle, takahiro.kuwano, linux-spi,
devicetree, linux-kernel, linux-mtd, praneeth, u-kumar1, a-dutta
In-Reply-To: <20260622-private-curly-fennec-7e1ad0@quoll>
[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]
On Mon, Jun 22, 2026 at 11:14:32AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Jun 18, 2026 at 01:07:10PM +0530, Santhosh Kumar K wrote:
> > Add spi-max-post-config-frequency, a generic uint32 property for SPI
> > peripherals that support two distinct clock rates: a conservative rate
> > always reachable without controller configuration, and a higher rate
> > reachable only after controller-side configuration such as PHY tuning.
> >
> > When both properties are present, spi-max-frequency gives the
> > conservative pre-configuration rate and spi-max-post-config-frequency
> > gives the higher post-configuration target.
> >
> > Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
> > ---
> > .../devicetree/bindings/spi/spi-peripheral-props.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > index 880a9f624566..ece86f65930f 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > @@ -45,6 +45,12 @@ properties:
> > description:
> > Maximum SPI clocking speed of the device in Hz.
> >
> > + spi-max-post-config-frequency:
>
> -hz
Ah d'oh. I was hung up on matching the existing property that I didn't
include -hz in my original suggestion, sorry!
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml
>
> and you need maxItems: 1.
>
> Now, please take time and think if this should not be an array instead
> (maxItems: ...) to cover other possible cases, e.g. different tuning
> levels? IOW, having single spi-max-frequency turned out to be
> insufficient. You address that insufficiency with one more frequency,
> but what if this is going to be insufficient next month as well?
>
> I don't know, answer is rather for domain experts.
>
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Maximum SPI clock frequency in Hz achievable post controller-side
> > + configuration.
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v2 3/3] dt-bindings: iio: adc: Add burn-out current properties
From: David Lechner @ 2026-06-22 19:44 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622-new-channel-props-v2-3-aafd5369f253@gmail.com>
On 6/22/26 2:30 PM, Kurt Borja wrote:
> Some ADCs incorporate burn-out current sources that provide current to
> the channel's input pins for open-circuit or short-circuit detection.
>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> Documentation/devicetree/bindings/iio/adc/adc.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> index 160a8cfa9842a86..9240f569d4ab7af 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> @@ -105,6 +105,12 @@ properties:
> This array describes the current configuration of the excitation current
> sources or the single matched current for all sources.
>
> + burn-out-current-microamp:
This also needs to be nanoamp.
> + maxItems: 1
> + description:
> + Burn-out current sources provide current to the channel's input pins for
> + open-circuit or short-circuit detection.
> +
> anyOf:
> - oneOf:
> - required:
>
^ permalink raw reply
* Re: [PATCH RFC v2 2/3] dt-bindings: iio: adc: Add excitation current sources properties
From: David Lechner @ 2026-06-22 19:42 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622-new-channel-props-v2-2-aafd5369f253@gmail.com>
On 6/22/26 2:30 PM, Kurt Borja wrote:
> Some ADCs incorporate current sources that provide excitation current to
> resistive temperature devices (RTDs), thermistors, diodes and other
> resistive sensors that require constant current biasing.
>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> Documentation/devicetree/bindings/iio/adc/adc.yaml | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> index fdad6b8276c934c..160a8cfa9842a86 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> @@ -86,6 +86,25 @@ properties:
> source. If two values are provided, the first one corresponds to the
> positive source and the second to the negative source.
>
> + excitation-channels:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Excitation current sources provide current to resistive temperature
> + devices (RTDs), thermistors, diodes and other resistive sensors that
> + require constant current biasing.
> +
> + This array describes the mux configuration of the excitation current
> + sources.
> +
> + excitation-current-microamp:
As seen in adi,ltc2983.yaml, this actually needs to be nanoamp to be able
to be flexible for all parts.
> + description:
> + Excitation current sources provide current to resistive temperature
> + devices (RTDs), thermistors, diodes and other resistive sensors that
> + require constant current biasing.
> +
> + This array describes the current configuration of the excitation current
> + sources or the single matched current for all sources.
> +
> anyOf:
> - oneOf:
> - required:
>
^ permalink raw reply
* Re: [PATCH RFC v2 1/3] dt-bindings: iio: adc: Add reference-source property
From: David Lechner @ 2026-06-22 19:40 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622-new-channel-props-v2-1-aafd5369f253@gmail.com>
On 6/22/26 2:30 PM, Kurt Borja wrote:
> Some ADCs have configurable voltage reference sources for each channel.
>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> Documentation/devicetree/bindings/iio/adc/adc.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> index b9bc02b5b07a4c7..fdad6b8276c934c 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> @@ -73,6 +73,19 @@ properties:
> device design and can interact with other characteristics such as
> settling time.
>
> + reference-source:
Since this is an array, the name should be `reference-sources`.
> + $ref: /schemas/types.yaml#/definitions/string-array
> + maxItems: 2
> + minItems: 1
Maybe minItems here is OK, but I don't think we should put maxItems here.
This way, it stays more flexible for other use cases.
> + description:
> + Indicates the voltage reference source or sources for this channel. Some
> + ADCs usually allow choosing between internal reference sources or a pair
> + of external pins.
> +
> + If a single value is provided, it represents a single voltage reference
> + source. If two values are provided, the first one corresponds to the
> + positive source and the second to the negative source.
> +
> anyOf:
> - oneOf:
> - required:
>
^ permalink raw reply
* Re: [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: David Lechner @ 2026-06-22 19:38 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622-new-channel-props-v2-0-aafd5369f253@gmail.com>
On 6/22/26 2:30 PM, Kurt Borja wrote:
> Hi all,
>
> After submitting a patch series adding support for TI ADS126X ADCs [1],
> I was made aware by David [2] that at least two more chip families,
> ads1220 [3] and ads1x2c14, share very similar features (though these
> chips are not really compatible between them). After that, I found one
> more chip with the same features which is already upstream, the
> AD4170-4.
>
> As David explained in [2], these chips are intended to be used with
> RTDs, thermocouples or other resistive sensors so they share the
> following per-channel features:
>
> - Configurable reference selection
> - Burn-out Current Sources (BOCS) for diagnostic purpuses
> - Excitation current sources (usually called IDACs TI) for sensor
> current biasing
>
> Given that these three features are present in all four devices and
> three of these drivers are still under review, my proposal is to have
> these features be described in adc.yaml and have this series merged
> before the three others [1] [2] [3].
>
> This series is sent as RFC because I still don't have much experience
> with dt-bindings and I don't know if this approach or the properties are
> general enough to be described like this.
It will probably be easier if I just include these patches when I do
v2 of my series (if you don't mind me tweaking them a bit).
>
> No dependencies between properties were provided because not all devices
> may be able to configure each one of them.
>
> [1] https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
> [2] https://lore.kernel.org/linux-iio/20260615-iio-adc-ti-ads122c14-v1-0-e6bdadf7cb2b@baylibre.com/
> [3] https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> v2:
> - reference-source is now a string-array and now presents a couple of
> quick examples
> - excitation-* properties now do not enforce arbitrary limits
> - Dropped burn-out-current-polarity because it was not general enough
> - I kept burn-out-current-microamp because the discussion around it is
> still ongoing
>
> v1: https://patch.msgid.link/20260618-new-channel-props-v1-0-963c1b5cf40a@gmail.com
>
> ---
> Kurt Borja (3):
> dt-bindings: iio: adc: Add reference-source property
> dt-bindings: iio: adc: Add excitation current sources properties
> dt-bindings: iio: adc: Add burn-out current properties
>
> Documentation/devicetree/bindings/iio/adc/adc.yaml | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> ---
> base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
> change-id: 20260618-new-channel-props-4fbd52020da2
>
^ permalink raw reply
* [PATCH RFC v2 3/3] dt-bindings: iio: adc: Add burn-out current properties
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
In-Reply-To: <20260622-new-channel-props-v2-0-aafd5369f253@gmail.com>
Some ADCs incorporate burn-out current sources that provide current to
the channel's input pins for open-circuit or short-circuit detection.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
index 160a8cfa9842a86..9240f569d4ab7af 100644
--- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
@@ -105,6 +105,12 @@ properties:
This array describes the current configuration of the excitation current
sources or the single matched current for all sources.
+ burn-out-current-microamp:
+ maxItems: 1
+ description:
+ Burn-out current sources provide current to the channel's input pins for
+ open-circuit or short-circuit detection.
+
anyOf:
- oneOf:
- required:
--
2.54.0
^ permalink raw reply related
* [PATCH RFC v2 2/3] dt-bindings: iio: adc: Add excitation current sources properties
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
In-Reply-To: <20260622-new-channel-props-v2-0-aafd5369f253@gmail.com>
Some ADCs incorporate current sources that provide excitation current to
resistive temperature devices (RTDs), thermistors, diodes and other
resistive sensors that require constant current biasing.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
index fdad6b8276c934c..160a8cfa9842a86 100644
--- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
@@ -86,6 +86,25 @@ properties:
source. If two values are provided, the first one corresponds to the
positive source and the second to the negative source.
+ excitation-channels:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Excitation current sources provide current to resistive temperature
+ devices (RTDs), thermistors, diodes and other resistive sensors that
+ require constant current biasing.
+
+ This array describes the mux configuration of the excitation current
+ sources.
+
+ excitation-current-microamp:
+ description:
+ Excitation current sources provide current to resistive temperature
+ devices (RTDs), thermistors, diodes and other resistive sensors that
+ require constant current biasing.
+
+ This array describes the current configuration of the excitation current
+ sources or the single matched current for all sources.
+
anyOf:
- oneOf:
- required:
--
2.54.0
^ permalink raw reply related
* [PATCH RFC v2 1/3] dt-bindings: iio: adc: Add reference-source property
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
In-Reply-To: <20260622-new-channel-props-v2-0-aafd5369f253@gmail.com>
Some ADCs have configurable voltage reference sources for each channel.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
index b9bc02b5b07a4c7..fdad6b8276c934c 100644
--- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
@@ -73,6 +73,19 @@ properties:
device design and can interact with other characteristics such as
settling time.
+ reference-source:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ maxItems: 2
+ minItems: 1
+ description:
+ Indicates the voltage reference source or sources for this channel. Some
+ ADCs usually allow choosing between internal reference sources or a pair
+ of external pins.
+
+ If a single value is provided, it represents a single voltage reference
+ source. If two values are provided, the first one corresponds to the
+ positive source and the second to the negative source.
+
anyOf:
- oneOf:
- required:
--
2.54.0
^ permalink raw reply related
* [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
Hi all,
After submitting a patch series adding support for TI ADS126X ADCs [1],
I was made aware by David [2] that at least two more chip families,
ads1220 [3] and ads1x2c14, share very similar features (though these
chips are not really compatible between them). After that, I found one
more chip with the same features which is already upstream, the
AD4170-4.
As David explained in [2], these chips are intended to be used with
RTDs, thermocouples or other resistive sensors so they share the
following per-channel features:
- Configurable reference selection
- Burn-out Current Sources (BOCS) for diagnostic purpuses
- Excitation current sources (usually called IDACs TI) for sensor
current biasing
Given that these three features are present in all four devices and
three of these drivers are still under review, my proposal is to have
these features be described in adc.yaml and have this series merged
before the three others [1] [2] [3].
This series is sent as RFC because I still don't have much experience
with dt-bindings and I don't know if this approach or the properties are
general enough to be described like this.
No dependencies between properties were provided because not all devices
may be able to configure each one of them.
[1] https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
[2] https://lore.kernel.org/linux-iio/20260615-iio-adc-ti-ads122c14-v1-0-e6bdadf7cb2b@baylibre.com/
[3] https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
v2:
- reference-source is now a string-array and now presents a couple of
quick examples
- excitation-* properties now do not enforce arbitrary limits
- Dropped burn-out-current-polarity because it was not general enough
- I kept burn-out-current-microamp because the discussion around it is
still ongoing
v1: https://patch.msgid.link/20260618-new-channel-props-v1-0-963c1b5cf40a@gmail.com
---
Kurt Borja (3):
dt-bindings: iio: adc: Add reference-source property
dt-bindings: iio: adc: Add excitation current sources properties
dt-bindings: iio: adc: Add burn-out current properties
Documentation/devicetree/bindings/iio/adc/adc.yaml | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
---
base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
change-id: 20260618-new-channel-props-4fbd52020da2
--
Thanks,
~ Kurt
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: qcom: sm8250-xiaomi-elish: add ov8856 front camera
From: Xin Xu @ 2026-06-22 18:52 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
In-Reply-To: <tencent_A65CB41DCB0CA96634CF8883E1CF89059706@qq.com>
Add the ov8856 front camera, connected on CCI1 to CSIPHY4 and
powered by pm8008 LDOs and other supplies.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
Changes in v2:
- Fix coding style (property order)
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index c514478cba4f..262cb9f29ebc 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/phy/phy.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include <dt-bindings/usb/pd.h>
@@ -531,6 +532,61 @@ vreg_l7f_1p8: ldo7 {
};
};
+&camss {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l5a_0p88>;
+ vdda-pll-supply = <&vreg_l9a_1p2>;
+
+ ports {
+ port@4 {
+ csiphy4_ep: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ remote-endpoint = <&ov8856_front_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c1 {
+ camera_front: camera@10 {
+ compatible = "ovti,ov8856";
+ reg = <0x10>;
+
+ avdd-supply = <&vreg_l5p>;
+ dovdd-supply = <&vreg_l1c_1p8>;
+ dvdd-supply = <&vreg_l1p>;
+
+ clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ clock-names = "xvclk";
+ assigned-clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ reset-gpios = <&tlmm 109 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&mclk3_active &camera_front_active>;
+ pinctrl-names = "default";
+
+ orientation = <0>; /* Front facing */
+ rotation = <270>;
+
+ port {
+ ov8856_front_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64
+ <720000000 360000000>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+};
+
&cdsp {
firmware-name = "qcom/sm8250/xiaomi/elish/cdsp.mbn";
status = "okay";
@@ -877,6 +933,20 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ camera_front_active: camera-front-active-state {
+ pins = "gpio109";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ mclk3_active: mclk3-active-state {
+ pins = "gpio97";
+ function = "cam_mclk";
+ bias-disable;
+ drive-strength = <4>;
+ };
+
pm8008_default: pm8008-default-state {
int-pins {
pins = "gpio84";
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-22 18:46 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
Add the pm8008 PMIC node on i2c15 with seven LDOs,
using GPIO84 as interrupt and GPIO76 as reset.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
Changes in v2:
- Fix coding style (blank line, interrupts-extended, property order,
drop output-high)
- Correct voltage constraints for ldo1 and ldo2
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 93 +++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 51b57c697a75..c514478cba4f 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -571,6 +571,82 @@ fuel-gauge@55 {
};
};
+&i2c15 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ pm8008: pmic@8 {
+ compatible = "qcom,pm8008";
+ reg = <0x8>;
+
+ interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&tlmm 76 GPIO_ACTIVE_LOW>;
+
+ vdd-l1-l2-supply = <&vreg_s8c_1p35>;
+ vdd-l3-l4-supply = <&vreg_bob>;
+ vdd-l5-supply = <&vreg_bob>;
+ vdd-l6-supply = <&vreg_bob>;
+ vdd-l7-supply = <&vreg_bob>;
+
+ pinctrl-0 = <&pm8008_default>;
+ pinctrl-names = "default";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pm8008 0 0 2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ #thermal-sensor-cells = <0>;
+
+ regulators {
+ vreg_l1p: ldo1 {
+ regulator-name = "vreg_l1p";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vreg_l2p: ldo2 {
+ regulator-name = "vreg_l2p";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vreg_l3p: ldo3 {
+ regulator-name = "vreg_l3p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l4p: ldo4 {
+ regulator-name = "vreg_l4p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l5p: ldo5 {
+ regulator-name = "vreg_l5p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l6p: ldo6 {
+ regulator-name = "vreg_l6p";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vreg_l7p: ldo7 {
+ regulator-name = "vreg_l7p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2900000>;
+ };
+ };
+ };
+};
+
&i2c11 {
clock-frequency = <400000>;
status = "okay";
@@ -801,6 +877,23 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ pm8008_default: pm8008-default-state {
+ int-pins {
+ pins = "gpio84";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ input-enable;
+ };
+
+ reset-pins {
+ pins = "gpio76";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+ };
+
wlan_en_state: wlan-default-state {
pins = "gpio20";
function = "gpio";
--
2.53.0
^ 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