[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

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

[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

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

[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

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 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

[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

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 4/6] iio: light: ltr501: Power down chip if request irq fails

[Andy Shevchenko]

On Tue, Aug 04, 2026 at 07:02:15PM +0200, Esben Haabendal wrote:
> 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")

Be careful with this. The removing of the error message should either go
separately, or you should be assured that the IRQ core prints it for you
in all stable kernels where this goes to be backported.

> Signed-off-by: Esben Haabendal <esben@geanix.com>

-- 
With Best Regards,
Andy Shevchenko

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

[Esben Haabendal]

"Andy Shevchenko" <andriy.shevchenko@intel.com> writes:

> On Tue, Aug 04, 2026 at 07:02:15PM +0200, Esben Haabendal wrote:
>> 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")
>
> Be careful with this. The removing of the error message should either go
> separately, or you should be assured that the IRQ core prints it for you
> in all stable kernels where this goes to be backported.

Ah yes. The duplicate error message removal is only valid as of
6.18.
I will split into a separate patch, and mark it with Fixes against the
change in devres.c that prints the error messsage.

/Esben

[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

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 5/6] iio: light: ltr501: Add ltr329 driver support

[Andy Shevchenko]

On Tue, Aug 04, 2026 at 07:02:16PM +0200, Esben Haabendal wrote:
> 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.

...

>  	if (client->irq > 0) {
> +		if (!ltr501_has_irq_support(data->chip_info)) {
> +			dev_err(&client->dev, "chip does not support irq\n");
> +			ret = -EINVAL;

Can this be

			ret = dev_err_probe(-EINVAL);

?

> +			goto powerdown_on_error;
> +		}

-- 
With Best Regards,
Andy Shevchenko

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

[Esben Haabendal]

"Andy Shevchenko" <andriy.shevchenko@intel.com> writes:

> On Tue, Aug 04, 2026 at 07:02:16PM +0200, Esben Haabendal wrote:
>> 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.
>
> ...
>
>>  	if (client->irq > 0) {
>> +		if (!ltr501_has_irq_support(data->chip_info)) {
>> +			dev_err(&client->dev, "chip does not support irq\n");
>> +			ret = -EINVAL;
>
> Can this be
>
> 			ret = dev_err_probe(-EINVAL);

Sure can, if that is the preferred style. But it will probably still be
two lines due to line width considerations.

And personally, as it would not take advantage of the -EPROBE_DEFER
logic of dev_err_probe(), I find the dev_err() style more clear.

>> +			goto powerdown_on_error;
>> +		}

/Esben

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

[Andy Shevchenko]

On Fri, Aug 07, 2026 at 09:53:11AM +0200, Esben Haabendal wrote:
> "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> > On Tue, Aug 04, 2026 at 07:02:16PM +0200, Esben Haabendal wrote:

...

> >>  	if (client->irq > 0) {
> >> +		if (!ltr501_has_irq_support(data->chip_info)) {
> >> +			dev_err(&client->dev, "chip does not support irq\n");
> >> +			ret = -EINVAL;
> >
> > Can this be
> >
> > 			ret = dev_err_probe(-EINVAL);
> 
> Sure can, if that is the preferred style. But it will probably still be
> two lines due to line width considerations.

Even older kernels' checkpatch won't complain on that long line (as ending by
a sting literal). But it's up to you.

> And personally, as it would not take advantage of the -EPROBE_DEFER
> logic of dev_err_probe(), I find the dev_err() style more clear.

The point is to use the unified template for the probe error messages (that's
why you may find a patch against dev_err_probe() documentation that allows this
kind of use).

> >> +			goto powerdown_on_error;
> >> +		}

-- 
With Best Regards,
Andy Shevchenko

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

[Esben Haabendal]

"Andy Shevchenko" <andriy.shevchenko@intel.com> writes:

> On Fri, Aug 07, 2026 at 09:53:11AM +0200, Esben Haabendal wrote:
>> "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
>> > On Tue, Aug 04, 2026 at 07:02:16PM +0200, Esben Haabendal wrote:
>
> ...
>
>> >>  	if (client->irq > 0) {
>> >> +		if (!ltr501_has_irq_support(data->chip_info)) {
>> >> +			dev_err(&client->dev, "chip does not support irq\n");
>> >> +			ret = -EINVAL;
>> >
>> > Can this be
>> >
>> > 			ret = dev_err_probe(-EINVAL);
>>
>> Sure can, if that is the preferred style. But it will probably still be
>> two lines due to line width considerations.
>
> Even older kernels' checkpatch won't complain on that long line (as ending by
> a sting literal). But it's up to you.
>
>> And personally, as it would not take advantage of the -EPROBE_DEFER
>> logic of dev_err_probe(), I find the dev_err() style more clear.
>
> The point is to use the unified template for the probe error messages (that's
> why you may find a patch against dev_err_probe() documentation that allows this
> kind of use).

Ah, I missed that comment. Thanks.

I will update the patch.

>> >> +			goto powerdown_on_error;
>> >> +		}

/Esben

[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 6/6] iio: light: ltr501: Fix sorting order of device arrays

[Andy Shevchenko]

On Tue, Aug 04, 2026 at 07:02:17PM +0200, Esben Haabendal wrote:
> Using alphanumerical sort order for these should help reduce merge
> conflicts.

...

>  enum {
> -	ltr501 = 0,
> -	ltr559,
> -	ltr301,

> +	ltr301 = 0,

Is the 0 required? Why?

>  	ltr303,
>  	ltr329,
> +	ltr501,
> +	ltr559,
>  };

-- 
With Best Regards,
Andy Shevchenko

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

[Esben Haabendal]

"Andy Shevchenko" <andriy.shevchenko@intel.com> writes:

> On Tue, Aug 04, 2026 at 07:02:17PM +0200, Esben Haabendal wrote:
>> Using alphanumerical sort order for these should help reduce merge
>> conflicts.
>
> ...
>
>>  enum {
>> -	ltr501 = 0,
>> -	ltr559,
>> -	ltr301,
>
>> +	ltr301 = 0,
>
> Is the 0 required? Why?

As for the code produced, it should not make any difference.

I assume it was put here for improved code readability, and I did not
see any reason to change that.

I don't care about it myself, so will be happy to remove it if that is
the preferred style now.

>>  	ltr303,
>>  	ltr329,
>> +	ltr501,
>> +	ltr559,
>>  };

/Esben

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

[Andy Shevchenko]

On Fri, Aug 07, 2026 at 09:57:17AM +0200, Esben Haabendal wrote:
> "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> > On Tue, Aug 04, 2026 at 07:02:17PM +0200, Esben Haabendal wrote:

...

> >>  enum {
> >> -	ltr501 = 0,
> >> -	ltr559,
> >> -	ltr301,
> >
> >> +	ltr301 = 0,
> >
> > Is the 0 required? Why?
> 
> As for the code produced, it should not make any difference.
> 
> I assume it was put here for improved code readability, and I did not
> see any reason to change that.
> 
> I don't care about it myself, so will be happy to remove it if that is
> the preferred style now.

It's not about the style, it's about understanding the C language.
As per style, we have only one requirement in IIO, if the value is used
in communication with HW (part of protocol or a bitfield) *all* enum
values must be explicitly assigned, otherwise (Linux only case) none
(with, of course some exceptions, which are not the case here).

> >>  	ltr303,
> >>  	ltr329,
> >> +	ltr501,
> >> +	ltr559,
> >>  };

-- 
With Best Regards,
Andy Shevchenko

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

[Esben Haabendal]

"Andy Shevchenko" <andriy.shevchenko@intel.com> writes:

> On Fri, Aug 07, 2026 at 09:57:17AM +0200, Esben Haabendal wrote:
>> "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
>> > On Tue, Aug 04, 2026 at 07:02:17PM +0200, Esben Haabendal wrote:
>
> ...
>
>> >>  enum {
>> >> -	ltr501 = 0,
>> >> -	ltr559,
>> >> -	ltr301,
>> >
>> >> +	ltr301 = 0,
>> >
>> > Is the 0 required? Why?
>>
>> As for the code produced, it should not make any difference.
>>
>> I assume it was put here for improved code readability, and I did not
>> see any reason to change that.
>>
>> I don't care about it myself, so will be happy to remove it if that is
>> the preferred style now.
>
> It's not about the style, it's about understanding the C language.
> As per style, we have only one requirement in IIO, if the value is used
> in communication with HW (part of protocol or a bitfield) *all* enum
> values must be explicitly assigned, otherwise (Linux only case) none
> (with, of course some exceptions, which are not the case here).

Ok. I will amend the patch with this change, so that we get rid of this
unneeded and unwanted assignment.

>> >>  	ltr303,
>> >>  	ltr329,
>> >> +	ltr501,
>> >> +	ltr559,
>> >>  };

/Esben

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