[PATCH v3 0/6] iio: light: ltr501: Add ltr329 support

[PATCH v3 0/6] iio: light: ltr501: Add ltr329 support

[Esben Haabendal]

The LiteON LTR-329ALS-01 chip is similar to the LTR-303ALS-01, except for
interrupt support and related registers, which LTR-329ALS-01 does not have.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
Changes in v3:
- Removed duplicated error message on devm_request_threaded_irq() failure.
- Added Fixes: and Cc: stable tags to fix for error handling of
  devm_request_threaded_irq() failure.
- Added no_irq_support boolean to simplify checking for chip irq support.
- Moved check for no_irq_support from ltr501_read_intr_prst() and
  ltr501_write_intr_prst() to callers. Note: event functions are not
  registered for no_irq_support devices.
- Moved #include <linux/array_size.h> into its place according to
  alphabetical sorting order (although the rest is not really wel sorted).
- Restored alphanumerical ordering of compatible list in bindings
  documentation.
- Ordered device arrays and enum values according to alphanumerical sorting
  order.
- Link to v2: https://patch.msgid.link/20260715-liteon-ltr329-v2-0-d18af55edab5@geanix.com

Changes in v2:
- Fixed error handling when irq is defined for a chip that does not support
  irq, powering the chip down again.
- Added simlar fix to error handling of devm_request_threaded_irq() error
  handling, powering the chip down again on failure.
- Added explicit #include <linux/array_size.h>.
- Link to v1: https://patch.msgid.link/20260715-liteon-ltr329-v1-0-31f027051594@geanix.com

To: Jonathan Cameron <jic23@kernel.org>
To: David Lechner <dlechner@baylibre.com>
To: Nuno Sá <nuno.sa@analog.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>
To: Nikita Travkin <nikita@trvn.ru>
To: Maslov Dmitry <maslovdmitry@seeed.cc>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: linux-iio@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
Esben Haabendal (6):
      dt-bindings: iio: light: ltr501: Sort compatible enum array
      dt-bindings: iio: light: ltr501: Add missing ltr303 compatible
      dt-bindings: iio: light: ltr501: Add ltr329 compatible
      iio: light: ltr501: Power down chip if request irq fails
      iio: light: ltr501: Add ltr329 driver support
      iio: light: ltr501: Fix sorting order of device arrays

 .../bindings/iio/light/liteon,ltr501.yaml          |   4 +-
 drivers/iio/light/ltr501.c                         | 117 +++++++++++++--------
 2 files changed, 78 insertions(+), 43 deletions(-)
---
base-commit: 075b74841bd0065a3bda3440873c747938e69b68
change-id: 20260711-liteon-ltr329-a3eb12414866

Best regards,
--  
Esben Haabendal <esben@geanix.com>

[PATCH v3 1/6] dt-bindings: iio: light: ltr501: Sort compatible enum array

[Esben Haabendal]

Restore alphabetical sorting of the properties.compatible.enum array.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
index c8074f180a79..480523ca3750 100644
--- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
+++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
@@ -15,9 +15,9 @@ allOf:
 properties:
   compatible:
     enum:
+      - liteon,ltr301
       - liteon,ltr501
       - liteon,ltr559
-      - liteon,ltr301
 
   reg:
     maxItems: 1

-- 
2.55.0

[PATCH v3 2/6] dt-bindings: iio: light: ltr501: Add missing ltr303 compatible

[Esben Haabendal]

When support for ltr303 was back in 2021, the bindings documentation was
not updated accordingly.

Fixes: 7d71d289e1ba ("iio: light: ltr501: Added ltr303 driver support")
Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
index 480523ca3750..6234e2eaec2e 100644
--- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
+++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
@@ -16,6 +16,7 @@ properties:
   compatible:
     enum:
       - liteon,ltr301
+      - liteon,ltr303
       - liteon,ltr501
       - liteon,ltr559
 

-- 
2.55.0

[PATCH v3 3/6] dt-bindings: iio: light: ltr501: Add ltr329 compatible

[Esben Haabendal]

LTR-329ALS-01 is an ambient light sensor similar to LTR-303ALS-01, but
without interrupt support.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
index 6234e2eaec2e..8c9d6cee55b4 100644
--- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
+++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
@@ -17,6 +17,7 @@ properties:
     enum:
       - liteon,ltr301
       - liteon,ltr303
+      - liteon,ltr329
       - liteon,ltr501
       - liteon,ltr559
 

-- 
2.55.0

[PATCH v3 4/6] iio: light: ltr501: Power down chip if request irq fails

[Esben Haabendal]

In case devm_request_threaded_irq() failed, we were leaving the chip
powered instead of powering it down again. Power down the chip switching
ALS and PS modes to standby.

The dev_err() message was causing duplicated error messages, as
devm_request_threaded_irq() calls dev_err_probe() on failure.

Fixes: 7ac702b3144b ("iio: ltr501: Add interrupt support")
Cc: stable@vger.kernel.org
Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/iio/light/ltr501.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index 7d045be78c6d..b36bd10a0262 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -1537,11 +1537,8 @@ static int ltr501_probe(struct i2c_client *client)
 						IRQF_ONESHOT,
 						"ltr501_thresh_event",
 						indio_dev);
-		if (ret) {
-			dev_err(&client->dev, "request irq (%d) failed\n",
-				client->irq);
-			return ret;
-		}
+		if (ret)
+			goto powerdown_on_error;
 	} else {
 		indio_dev->info = data->chip_info->info_no_irq;
 	}

-- 
2.55.0

[PATCH v3 5/6] iio: light: ltr501: Add ltr329 driver support

[Esben Haabendal]

This adds support for the LTR-329ALS-01 chip, which is similar to
LTR-303ALS-01, except for interrupt, which LTR-329ALS-01 chip does not
have.

Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/iio/light/ltr501.c | 48 ++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index b36bd10a0262..9d37872ceec5 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -9,6 +9,7 @@
  * TODO: IR LED characteristics
  */
 
+#include <linux/array_size.h>
 #include <linux/module.h>
 #include <linux/i2c.h>
 #include <linux/err.h>
@@ -94,6 +95,7 @@ enum {
 	ltr559,
 	ltr301,
 	ltr303,
+	ltr329,
 };
 
 struct ltr501_gain {
@@ -140,6 +142,7 @@ struct ltr501_chip_info {
 	u8 als_mode_active;
 	u8 als_gain_mask;
 	u8 als_gain_shift;
+	bool no_irq_support;
 	struct iio_chan_spec const *channels;
 	const int no_channels;
 	const struct iio_info *info;
@@ -178,6 +181,11 @@ static const struct ltr501_samp_table ltr501_ps_samp_table[] = {
 			{500000, 2000000}
 };
 
+static bool ltr501_has_irq_support(const struct ltr501_chip_info *info)
+{
+	return !info->no_irq_support;
+}
+
 static int ltr501_match_samp_freq(const struct ltr501_samp_table *tab,
 					   int len, int val, int val2)
 {
@@ -821,6 +829,9 @@ static int __ltr501_write_raw(struct iio_dev *indio_dev,
 			if (ret < 0)
 				return ret;
 
+			if (!ltr501_has_irq_support(info))
+				return ret;
+
 			/* update persistence count when changing frequency */
 			ret = ltr501_write_intr_prst(data, chan->type,
 						     0, data->als_period);
@@ -840,6 +851,9 @@ static int __ltr501_write_raw(struct iio_dev *indio_dev,
 			if (ret < 0)
 				return ret;
 
+			if (!ltr501_has_irq_support(info))
+				return ret;
+
 			/* update persistence count when changing frequency */
 			ret = ltr501_write_intr_prst(data, chan->type,
 						     0, data->ps_period);
@@ -1257,6 +1271,18 @@ static const struct ltr501_chip_info ltr501_chip_info_tbl[] = {
 		.channels = ltr301_channels,
 		.no_channels = ARRAY_SIZE(ltr301_channels),
 	},
+	[ltr329] = {
+		.partid = 0x0A,
+		.als_gain = ltr559_als_gain_tbl,
+		.als_gain_tbl_size = ARRAY_SIZE(ltr559_als_gain_tbl),
+		.als_mode_active = BIT(0),
+		.als_gain_mask = BIT(2) | BIT(3) | BIT(4),
+		.als_gain_shift = 2,
+		.no_irq_support = true,
+		.info_no_irq = &ltr301_info_no_irq,
+		.channels = ltr301_channels,
+		.no_channels = ARRAY_SIZE(ltr301_channels),
+	},
 };
 
 static int ltr501_write_contr(struct ltr501_data *data, u8 als_val, u8 ps_val)
@@ -1369,13 +1395,15 @@ static int ltr501_init(struct ltr501_data *data)
 
 	data->ps_contr = status | LTR501_CONTR_ACTIVE;
 
-	ret = ltr501_read_intr_prst(data, IIO_INTENSITY, &data->als_period);
-	if (ret < 0)
-		return ret;
+	if (ltr501_has_irq_support(data->chip_info)) {
+		ret = ltr501_read_intr_prst(data, IIO_INTENSITY, &data->als_period);
+		if (ret < 0)
+			return ret;
 
-	ret = ltr501_read_intr_prst(data, IIO_PROXIMITY, &data->ps_period);
-	if (ret < 0)
-		return ret;
+		ret = ltr501_read_intr_prst(data, IIO_PROXIMITY, &data->ps_period);
+		if (ret < 0)
+			return ret;
+	}
 
 	return ltr501_write_contr(data, data->als_contr, data->ps_contr);
 }
@@ -1531,6 +1559,12 @@ static int ltr501_probe(struct i2c_client *client)
 		return ret;
 
 	if (client->irq > 0) {
+		if (!ltr501_has_irq_support(data->chip_info)) {
+			dev_err(&client->dev, "chip does not support irq\n");
+			ret = -EINVAL;
+			goto powerdown_on_error;
+		}
+
 		ret = devm_request_threaded_irq(&client->dev, client->irq,
 						NULL, ltr501_interrupt_handler,
 						IRQF_TRIGGER_FALLING |
@@ -1601,6 +1635,7 @@ static const struct i2c_device_id ltr501_id[] = {
 	{ .name = "ltr559", .driver_data = ltr559 },
 	{ .name = "ltr301", .driver_data = ltr301 },
 	{ .name = "ltr303", .driver_data = ltr303 },
+	{ .name = "ltr329", .driver_data = ltr329 },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, ltr501_id);
@@ -1610,6 +1645,7 @@ static const struct of_device_id ltr501_of_match[] = {
 	{ .compatible = "liteon,ltr559", },
 	{ .compatible = "liteon,ltr301", },
 	{ .compatible = "liteon,ltr303", },
+	{ .compatible = "liteon,ltr329", },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, ltr501_of_match);

-- 
2.55.0

[PATCH v3 6/6] iio: light: ltr501: Fix sorting order of device arrays

[Esben Haabendal]

Using alphanumerical sort order for these should help reduce merge
conflicts.

Signed-off-by: Esben Haabendal <esben@geanix.com>
---
 drivers/iio/light/ltr501.c | 70 +++++++++++++++++++++++-----------------------
 1 file changed, 35 insertions(+), 35 deletions(-)

diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index 9d37872ceec5..dbdd69a90ee6 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -91,11 +91,11 @@ struct ltr501_samp_table {
 #define LTR501_RESERVED_GAIN -1
 
 enum {
-	ltr501 = 0,
-	ltr559,
-	ltr301,
+	ltr301 = 0,
 	ltr303,
 	ltr329,
+	ltr501,
+	ltr559,
 };
 
 struct ltr501_gain {
@@ -1219,34 +1219,6 @@ static const struct iio_info ltr301_info = {
 };
 
 static const struct ltr501_chip_info ltr501_chip_info_tbl[] = {
-	[ltr501] = {
-		.partid = 0x08,
-		.als_gain = ltr501_als_gain_tbl,
-		.als_gain_tbl_size = ARRAY_SIZE(ltr501_als_gain_tbl),
-		.ps_gain = ltr501_ps_gain_tbl,
-		.ps_gain_tbl_size = ARRAY_SIZE(ltr501_ps_gain_tbl),
-		.als_mode_active = BIT(0) | BIT(1),
-		.als_gain_mask = BIT(3),
-		.als_gain_shift = 3,
-		.info = &ltr501_info,
-		.info_no_irq = &ltr501_info_no_irq,
-		.channels = ltr501_channels,
-		.no_channels = ARRAY_SIZE(ltr501_channels),
-	},
-	[ltr559] = {
-		.partid = 0x09,
-		.als_gain = ltr559_als_gain_tbl,
-		.als_gain_tbl_size = ARRAY_SIZE(ltr559_als_gain_tbl),
-		.ps_gain = ltr559_ps_gain_tbl,
-		.ps_gain_tbl_size = ARRAY_SIZE(ltr559_ps_gain_tbl),
-		.als_mode_active = BIT(0),
-		.als_gain_mask = BIT(2) | BIT(3) | BIT(4),
-		.als_gain_shift = 2,
-		.info = &ltr501_info,
-		.info_no_irq = &ltr501_info_no_irq,
-		.channels = ltr501_channels,
-		.no_channels = ARRAY_SIZE(ltr501_channels),
-	},
 	[ltr301] = {
 		.partid = 0x08,
 		.als_gain = ltr501_als_gain_tbl,
@@ -1283,6 +1255,34 @@ static const struct ltr501_chip_info ltr501_chip_info_tbl[] = {
 		.channels = ltr301_channels,
 		.no_channels = ARRAY_SIZE(ltr301_channels),
 	},
+	[ltr501] = {
+		.partid = 0x08,
+		.als_gain = ltr501_als_gain_tbl,
+		.als_gain_tbl_size = ARRAY_SIZE(ltr501_als_gain_tbl),
+		.ps_gain = ltr501_ps_gain_tbl,
+		.ps_gain_tbl_size = ARRAY_SIZE(ltr501_ps_gain_tbl),
+		.als_mode_active = BIT(0) | BIT(1),
+		.als_gain_mask = BIT(3),
+		.als_gain_shift = 3,
+		.info = &ltr501_info,
+		.info_no_irq = &ltr501_info_no_irq,
+		.channels = ltr501_channels,
+		.no_channels = ARRAY_SIZE(ltr501_channels),
+	},
+	[ltr559] = {
+		.partid = 0x09,
+		.als_gain = ltr559_als_gain_tbl,
+		.als_gain_tbl_size = ARRAY_SIZE(ltr559_als_gain_tbl),
+		.ps_gain = ltr559_ps_gain_tbl,
+		.ps_gain_tbl_size = ARRAY_SIZE(ltr559_ps_gain_tbl),
+		.als_mode_active = BIT(0),
+		.als_gain_mask = BIT(2) | BIT(3) | BIT(4),
+		.als_gain_shift = 2,
+		.info = &ltr501_info,
+		.info_no_irq = &ltr501_info_no_irq,
+		.channels = ltr501_channels,
+		.no_channels = ARRAY_SIZE(ltr501_channels),
+	},
 };
 
 static int ltr501_write_contr(struct ltr501_data *data, u8 als_val, u8 ps_val)
@@ -1631,21 +1631,21 @@ static const struct acpi_device_id ltr_acpi_match[] = {
 MODULE_DEVICE_TABLE(acpi, ltr_acpi_match);
 
 static const struct i2c_device_id ltr501_id[] = {
-	{ .name = "ltr501", .driver_data = ltr501 },
-	{ .name = "ltr559", .driver_data = ltr559 },
 	{ .name = "ltr301", .driver_data = ltr301 },
 	{ .name = "ltr303", .driver_data = ltr303 },
 	{ .name = "ltr329", .driver_data = ltr329 },
+	{ .name = "ltr501", .driver_data = ltr501 },
+	{ .name = "ltr559", .driver_data = ltr559 },
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, ltr501_id);
 
 static const struct of_device_id ltr501_of_match[] = {
-	{ .compatible = "liteon,ltr501", },
-	{ .compatible = "liteon,ltr559", },
 	{ .compatible = "liteon,ltr301", },
 	{ .compatible = "liteon,ltr303", },
 	{ .compatible = "liteon,ltr329", },
+	{ .compatible = "liteon,ltr501", },
+	{ .compatible = "liteon,ltr559", },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, ltr501_of_match);

-- 
2.55.0

Re: [PATCH v3 3/6] dt-bindings: iio: light: ltr501: Add ltr329 compatible

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The DT binding schema does not restrict the `interrupts` property for the `liteon,ltr329` compatible, allowing invalid configurations to pass validation.
--

--- Patch [3]: [PATCH v3 3/6] dt-bindings: iio: light: ltr501: Add ltr329 compatible ---
commit 11927e9d8e871ae421d027fafa731bcca8f1e3c4
Author: Esben Haabendal <esben@geanix.com>

dt-bindings: iio: light: ltr501: Add ltr329 compatible

This commit adds the liteon,ltr329 compatible string for the LTR-329ALS-01
ambient light sensor. It notes that the device is similar to LTR-303ALS-01
but lacks interrupt support.

> diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> index 6234e2eaec2e4..8c9d6cee55b49 100644
> --- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> +++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> @@ -17,6 +17,7 @@ properties:
>      enum:
>        - liteon,ltr301
>        - liteon,ltr303
> +      - liteon,ltr329

[Severity: Medium]
Since the commit message notes this device is without interrupt support,
should an allOf/if-then block be added to explicitly set interrupts: false
for the liteon,ltr329 compatible?

Because the interrupts property is globally defined with maxItems: 1 in this
schema, any device tree that incorrectly specifies an interrupt for this
specific device will silently pass schema validation.

>        - liteon,ltr501
>        - liteon,ltr559
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-liteon-ltr329-v3-0-c6b768c7c745@geanix.com?part=3

Re: [PATCH v3 4/6] iio: light: ltr501: Power down chip if request irq fails

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Uninitialized kernel stack memory is leaked to userspace and functional behavior is broken on Big Endian architectures due to `regmap_bulk_read()` reading into a 4-byte `int`.
- [Medium] Data race (TOCTOU) on `data->als_contr` and `data->ps_contr` between raw sysfs reads and writes.
- [Medium] Data race on `data->als_period` and `data->ps_period` between sysfs event writes and sysfs raw writes.
--

--- Patch [4]: [PATCH v3 4/6] iio: light: ltr501: Power down chip if request irq fails ---
commit 9f4c589a7c5ec63bde9127853783856ae3e751dd
Author: Esben Haabendal <esben@geanix.com>

iio: light: ltr501: Power down chip if request irq fails

This patch updates the error handling in ltr501_probe() when
devm_request_threaded_irq() fails. It ensures the chip is powered down by
jumping to the powerdown_on_error label and removes a duplicate error message.

> diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
> index 7d045be78c6df..b36bd10a02624 100644
> --- a/drivers/iio/light/ltr501.c
> +++ b/drivers/iio/light/ltr501.c
> @@ -1537,11 +1537,8 @@ static int ltr501_probe(struct i2c_client *client)
>  						IRQF_ONESHOT,
>  						"ltr501_thresh_event",
>  						indio_dev);
> -		if (ret) {
> -			dev_err(&client->dev, "request irq (%d) failed\n",
> -				client->irq);
> -			return ret;
> -		}
> +		if (ret)
> +			goto powerdown_on_error;
>  	} else {
>  		indio_dev->info = data->chip_info->info_no_irq;
>  	}

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem with
uninitialized memory when reading data on Big Endian architectures. 

In ltr501_read_thresh():

        int ret, thresh_data;
        ...
        ret = regmap_bulk_read(data->regmap, LTR501_ALS_THRESH_UP,
                               &thresh_data, 2);
        if (ret < 0)
                return ret;
        *val = thresh_data & LTR501_ALS_THRESH_MASK;

And in ltr501_trigger_handler():

        int ret, psdata;
        ...
        ret = regmap_bulk_read(data->regmap, LTR501_PS_DATA,
                               &psdata, 2);
        if (ret < 0)
                goto done;
        scan.channels[j++] = psdata & LTR501_PS_DATA_MASK;

Could this leak up to 2 bytes of uninitialized kernel stack memory to userspace
and result in data loss on Big Endian systems? The regmap_bulk_read() call
reads 2 bytes into the MSB of the 32-bit int variables and then the code masks
the uninitialized LSBs.

Similarly, in ltr501_write_thresh():

        ret = regmap_bulk_write(data->regmap, LTR501_ALS_THRESH_UP,
                                &val, 2);

Would this write the upper 2 bytes of the 32-bit integer on Big Endian systems,
silently passing incorrect zeroes to the hardware?

[Severity: Medium]
This is a pre-existing issue, but is there a data race on data->als_contr
between raw sysfs reads and writes?

In ltr501_read_raw(), data->als_contr is read locklessly:

        i = (data->als_contr & data->chip_info->als_gain_mask)
             >> data->chip_info->als_gain_shift;

While in __ltr501_write_raw(), it performs a non-atomic read-modify-write:

        data->als_contr &= ~info->als_gain_mask;
        data->als_contr |= i << info->als_gain_shift;

Can a concurrent read (via sysfs) during a write observe an intermediate
configuration state, leading to the driver temporarily reporting an incorrect
scale factor to userspace?

[Severity: Medium]
This isn't a bug introduced by this patch, but is there a data race on
data->als_period between sysfs event writes and sysfs raw writes?

In ltr501_write_intr_prst():

        mutex_unlock(&data->lock_als);
        if (ret >= 0)
                data->als_period = period;

And in __ltr501_write_raw():

        ret = ltr501_write_intr_prst(data, chan->type,
                                     0, data->als_period);

Does updating data->als_period outside of the mutex lock in
ltr501_write_intr_prst() leave it unprotected against concurrent event writers
or lockless readers like __ltr501_write_raw()?

Could this lead to stale or inconsistent values being used to configure the
hardware, potentially setting incorrect sampling frequencies or interrupt
persistence counts?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-liteon-ltr329-v3-0-c6b768c7c745@geanix.com?part=4

Re: [PATCH v3 5/6] iio: light: ltr501: Add ltr329 driver support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The software trigger handler incorrectly maps the TIMESTAMP channel to the Proximity Sensor for ALS-only chips, causing an I2C polling timeout and trigger failure.
--

--- Patch [5]: [PATCH v3 5/6] iio: light: ltr501: Add ltr329 driver support ---
commit 62d63375d5ea8d7644dcba28928c83f753f6e2cf
Author: Esben Haabendal <esben@geanix.com>

iio: light: ltr501: Add ltr329 driver support
    
This patch adds support for the LTR-329ALS-01 chip, which is similar to
the LTR-303ALS-01 but lacks interrupt support.

> diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
> index b36bd10a02624..9d37872ceec58 100644
> --- a/drivers/iio/light/ltr501.c
> +++ b/drivers/iio/light/ltr501.c
[ ... ]
> @@ -1257,6 +1271,18 @@ static const struct ltr501_chip_info ltr501_chip_info_tbl[] = {
>  		.channels = ltr301_channels,
>  		.no_channels = ARRAY_SIZE(ltr301_channels),
>  	},
> +	[ltr329] = {
> +		.partid = 0x0A,
> +		.als_gain = ltr559_als_gain_tbl,
> +		.als_gain_tbl_size = ARRAY_SIZE(ltr559_als_gain_tbl),
> +		.als_mode_active = BIT(0),
> +		.als_gain_mask = BIT(2) | BIT(3) | BIT(4),
> +		.als_gain_shift = 2,
> +		.no_irq_support = true,
> +		.info_no_irq = &ltr301_info_no_irq,
> +		.channels = ltr301_channels,

[Severity: High]
This isn't a bug introduced by this patch, but will the trigger handler fail
for the LTR-329 when using ltr301_channels?

Looking at ltr301_channels, scan_index 2 is defined as the software
timestamp:

drivers/iio/light/ltr501.c:ltr301_channels[] = {
	...
	IIO_CHAN_SOFT_TIMESTAMP(2),
};

However, in ltr501_trigger_handler(), test_bit(2, ...) hardcodes the
assumption that scan_index 2 is the proximity sensor:

drivers/iio/light/ltr501.c:ltr501_trigger_handler() {
	...
	if (test_bit(2, indio_dev->active_scan_mask))
		mask |= LTR501_STATUS_PS_RDY;

	ret = ltr501_drdy(data, mask);
	...
}

If a user enables the IIO timestamp channel (scan_index 2) on an ALS-only
chip like the LTR-329, will ltr501_drdy() timeout waiting for the proximity
sensor ready bit, effectively breaking triggered buffers?

> +		.no_channels = ARRAY_SIZE(ltr301_channels),
> +	},
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-liteon-ltr329-v3-0-c6b768c7c745@geanix.com?part=5

Re: [PATCH v3 1/6] dt-bindings: iio: light: ltr501: Sort compatible enum array

[Krzysztof Kozlowski]

On Tue, Aug 04, 2026 at 07:02:12PM +0200, Esben Haabendal wrote:
> Restore alphabetical sorting of the properties.compatible.enum array.
> 
> Signed-off-by: Esben Haabendal <esben@geanix.com>
> ---
>  Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v3 2/6] dt-bindings: iio: light: ltr501: Add missing ltr303 compatible

[Krzysztof Kozlowski]

On Tue, Aug 04, 2026 at 07:02:13PM +0200, Esben Haabendal wrote:
> When support for ltr303 was back in 2021, the bindings documentation was
> not updated accordingly.
> 
> Fixes: 7d71d289e1ba ("iio: light: ltr501: Added ltr303 driver support")
> Signed-off-by: Esben Haabendal <esben@geanix.com>
> ---
>  Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v3 3/6] dt-bindings: iio: light: ltr501: Add ltr329 compatible

[Krzysztof Kozlowski]

On Tue, Aug 04, 2026 at 07:02:14PM +0200, Esben Haabendal wrote:
> LTR-329ALS-01 is an ambient light sensor similar to LTR-303ALS-01, but
> without interrupt support.
> 
> Signed-off-by: Esben Haabendal <esben@geanix.com>
> ---
>  Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v3 0/6] iio: light: ltr501: Add ltr329 support

[Kuppuswamy Sathyanarayanan]

Hi,

On 8/4/2026 10:02 AM, Esben Haabendal wrote:
> The LiteON LTR-329ALS-01 chip is similar to the LTR-303ALS-01, except for
> interrupt support and related registers, which LTR-329ALS-01 does not have.
> 
> Signed-off-by: Esben Haabendal <esben@geanix.com>
> ---

Acked-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>


> Changes in v3:
> - Removed duplicated error message on devm_request_threaded_irq() failure.
> - Added Fixes: and Cc: stable tags to fix for error handling of
>   devm_request_threaded_irq() failure.
> - Added no_irq_support boolean to simplify checking for chip irq support.
> - Moved check for no_irq_support from ltr501_read_intr_prst() and
>   ltr501_write_intr_prst() to callers. Note: event functions are not
>   registered for no_irq_support devices.
> - Moved #include <linux/array_size.h> into its place according to
>   alphabetical sorting order (although the rest is not really wel sorted).
> - Restored alphanumerical ordering of compatible list in bindings
>   documentation.
> - Ordered device arrays and enum values according to alphanumerical sorting
>   order.
> - Link to v2: https://patch.msgid.link/20260715-liteon-ltr329-v2-0-d18af55edab5@geanix.com
> 
> Changes in v2:
> - Fixed error handling when irq is defined for a chip that does not support
>   irq, powering the chip down again.
> - Added simlar fix to error handling of devm_request_threaded_irq() error
>   handling, powering the chip down again on failure.
> - Added explicit #include <linux/array_size.h>.
> - Link to v1: https://patch.msgid.link/20260715-liteon-ltr329-v1-0-31f027051594@geanix.com
> 
> To: Jonathan Cameron <jic23@kernel.org>
> To: David Lechner <dlechner@baylibre.com>
> To: Nuno Sá <nuno.sa@analog.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>
> To: Nikita Travkin <nikita@trvn.ru>
> To: Maslov Dmitry <maslovdmitry@seeed.cc>
> To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Cc: linux-iio@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> 
> ---
> Esben Haabendal (6):
>       dt-bindings: iio: light: ltr501: Sort compatible enum array
>       dt-bindings: iio: light: ltr501: Add missing ltr303 compatible
>       dt-bindings: iio: light: ltr501: Add ltr329 compatible
>       iio: light: ltr501: Power down chip if request irq fails
>       iio: light: ltr501: Add ltr329 driver support
>       iio: light: ltr501: Fix sorting order of device arrays
> 
>  .../bindings/iio/light/liteon,ltr501.yaml          |   4 +-
>  drivers/iio/light/ltr501.c                         | 117 +++++++++++++--------
>  2 files changed, 78 insertions(+), 43 deletions(-)
> ---
> base-commit: 075b74841bd0065a3bda3440873c747938e69b68
> change-id: 20260711-liteon-ltr329-a3eb12414866
> 
> Best regards,
> --  
> Esben Haabendal <esben@geanix.com>
> 

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer