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

[PATCH 0/3] 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>
---
Esben Haabendal (3):
      dt-bindings: iio: light: ltr501: Add missing ltr303 compatible
      dt-bindings: iio: light: ltr501: Add ltr329 compatible
      iio: light: ltr501: Add ltr329 driver support

 .../bindings/iio/light/liteon,ltr501.yaml          |  2 ++
 drivers/iio/light/ltr501.c                         | 31 ++++++++++++++++++++++
 2 files changed, 33 insertions(+)
---
base-commit: 8cdeaa50eae8dad34885515f62559ee83e7e8dda
change-id: 20260711-liteon-ltr329-a3eb12414866

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

[PATCH 1/3] 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 c8074f180a79..ab9bb68dd736 100644
--- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
+++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
@@ -18,6 +18,7 @@ properties:
       - liteon,ltr501
       - liteon,ltr559
       - liteon,ltr301
+      - liteon,ltr303
 
   reg:
     maxItems: 1

-- 
2.55.0

[PATCH 2/3] 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 ab9bb68dd736..76e81eba7ea4 100644
--- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
+++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
@@ -19,6 +19,7 @@ properties:
       - liteon,ltr559
       - liteon,ltr301
       - liteon,ltr303
+      - liteon,ltr329
 
   reg:
     maxItems: 1

-- 
2.55.0

[PATCH 3/3] 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.

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

diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index 7d045be78c6d..815b67a10837 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -94,6 +94,7 @@ enum {
 	ltr559,
 	ltr301,
 	ltr303,
+	ltr329,
 };
 
 struct ltr501_gain {
@@ -178,6 +179,11 @@ static const struct ltr501_samp_table ltr501_ps_samp_table[] = {
 			{500000, 2000000}
 };
 
+static bool ltr501_has_irq_support(const struct ltr501_chip_info *chip_info)
+{
+	return chip_info->info != chip_info->info_no_irq;
+}
+
 static int ltr501_match_samp_freq(const struct ltr501_samp_table *tab,
 					   int len, int val, int val2)
 {
@@ -428,6 +434,9 @@ static int ltr501_read_intr_prst(const struct ltr501_data *data,
 {
 	int ret, samp_period, prst;
 
+	if (!ltr501_has_irq_support(data->chip_info))
+		return 0;
+
 	switch (type) {
 	case IIO_INTENSITY:
 		ret = regmap_field_read(data->reg_als_prst, &prst);
@@ -466,6 +475,9 @@ static int ltr501_write_intr_prst(struct ltr501_data *data,
 	int ret, samp_period, new_val;
 	unsigned long period;
 
+	if (!ltr501_has_irq_support(data->chip_info))
+		return 0;
+
 	if (val < 0 || val2 < 0)
 		return -EINVAL;
 
@@ -1257,6 +1269,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,
+		.info = &ltr301_info_no_irq,
+		.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)
@@ -1531,6 +1555,11 @@ 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");
+			return -EINVAL;
+		}
+
 		ret = devm_request_threaded_irq(&client->dev, client->irq,
 						NULL, ltr501_interrupt_handler,
 						IRQF_TRIGGER_FALLING |
@@ -1604,6 +1633,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);
@@ -1613,6 +1643,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 2/3] 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 schema fails to disallow the `interrupts` property for the `liteon,ltr329` compatible string, despite the device explicitly lacking interrupt support.
--

--- Patch [2]: [PATCH 2/3] dt-bindings: iio: light: ltr501: Add ltr329 compatible ---
commit 5d6bf65302b94ef38e976c911c22a66db543f0fe
Author: Esben Haabendal <esben@geanix.com>

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

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

> diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> index ab9bb68dd7363..76e81eba7ea4a 100644
> --- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> +++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml
> @@ -19,6 +19,7 @@ properties:
>        - liteon,ltr559
>        - liteon,ltr301
>        - liteon,ltr303
> +      - liteon,ltr329
>  
>    reg:
>      maxItems: 1

[Severity: Medium]
Since the commit message states this sensor operates without interrupt support,
should the schema disallow the interrupts property for this compatible string?

Adding the compatible string directly to the main enum allows a device tree to
specify an interrupt for liteon,ltr329 without being caught during schema
validation.

Would it make sense to add an if/then conditional block to restrict the
interrupts property when the compatible string is liteon,ltr329 to prevent
this regression?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-liteon-ltr329-v1-0-31f027051594@geanix.com?part=2

Re: [PATCH 3/3] iio: light: ltr501: Add ltr329 driver support

[sashiko-bot]

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

New issues:
- [Medium] Probe error paths skip device power-down, leaving the sensor active and leaking power.

Pre-existing issues:
- [High] Asymmetric teardown of the devm-managed IRQ and manual IIO device unregistration leads to a Use-After-Free on the IIO event interface.
- [High] Enabling the software timestamp channel on sensors without proximity support causes the trigger handler to hang and drop all captured data.
--

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

iio: light: ltr501: Add ltr329 driver support
    
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.

> diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
> index 7d045be78c6df..815b67a10837d 100644
> --- a/drivers/iio/light/ltr501.c
> +++ b/drivers/iio/light/ltr501.c

[ ... ]

> @@ -1257,6 +1269,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,
> +		.info = &ltr301_info_no_irq,
> +		.info_no_irq = &ltr301_info_no_irq,
> +		.channels = ltr301_channels,

[Severity: High]
This is a pre-existing issue, but does using ltr301_channels cause the
trigger handler to hang if the timestamp channel is enabled?

Looking at ltr301_channels, the timestamp channel occupies scan_index 2. If a
user enables the timestamp channel, bit 2 is set in active_scan_mask.

However, ltr501_trigger_handler() assumes bit 2 is always the proximity
sensor:

ltr501_trigger_handler() {
        ...
        if (test_bit(2, indio_dev->active_scan_mask))
                mask |= LTR501_STATUS_PS_RDY;

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

Since sensors using ltr301_channels lack a proximity sensor, the hardware
ready bit is never set. Could this cause ltr501_drdy() to loop and drop
data?

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

[ ... ]

> @@ -1531,6 +1555,11 @@ 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");
> +			return -EINVAL;
> +		}

[Severity: Medium]
Does this early return bypass device power-down on probe failure?

If the device tree specifies an IRQ for a chip that does not support it,
this will return -EINVAL directly instead of jumping to the
powerdown_on_error label, which could leave the device powered on.

[Severity: High]
This isn't a bug introduced by this patch, but is there a use-after-free
risk when the threaded IRQ is requested here?

The driver uses devm_request_threaded_irq() during probe but manually calls
iio_device_unregister() in ltr501_remove().

Because devm-managed resources are freed after ltr501_remove() completes,
the interrupt remains active while iio_device_unregister() destroys the
event interface.

If an interrupt fires during this window, ltr501_interrupt_handler() calls
iio_push_event(), which accesses the freed event interface structure.

> +
>  		ret = devm_request_threaded_irq(&client->dev, client->irq,
>  						NULL, ltr501_interrupt_handler,
>  						IRQF_TRIGGER_FALLING |

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-liteon-ltr329-v1-0-31f027051594@geanix.com?part=3

Re: [PATCH 3/3] iio: light: ltr501: Add ltr329 driver support

[Joshua Crofts]

On Wed, 15 Jul 2026 10:23:50 +0200
Esben Haabendal <esben@geanix.com> wrote:
> @@ -1257,6 +1269,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),

While you're at it, add `#include <linux/array_size.h>`

> +		.als_mode_active = BIT(0),
> +		.als_gain_mask = BIT(2) | BIT(3) | BIT(4),
> +		.als_gain_shift = 2,
> +		.info = &ltr301_info_no_irq,
> +		.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)
> @@ -1531,6 +1555,11 @@ 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");
> +			return -EINVAL;

Shouldn't this jump to the powerdown_on_error label instead of returning?

-- 
Kind regards

CJD

Re: [PATCH 3/3] iio: light: ltr501: Add ltr329 driver support

[Esben Haabendal]

<sashiko-bot@kernel.org> writes:

> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>
> New issues:
> - [Medium] Probe error paths skip device power-down, leaving the sensor active and leaking power.
>
> Pre-existing issues:
> - [High] Asymmetric teardown of the devm-managed IRQ and manual IIO device unregistration leads to a Use-After-Free on the IIO event interface.
> - [High] Enabling the software timestamp channel on sensors without proximity support causes the trigger handler to hang and drop all captured data.
> --
>
> --- Patch [3]: [PATCH 3/3] iio: light: ltr501: Add ltr329 driver support ---
> commit 6c505591ba68d4c8fcdd0eb98eb4532e6610696f
> Author: Esben Haabendal <esben@geanix.com>
>
> iio: light: ltr501: Add ltr329 driver support
>
> 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.
>
>> diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
>> index 7d045be78c6df..815b67a10837d 100644
>> --- a/drivers/iio/light/ltr501.c
>> +++ b/drivers/iio/light/ltr501.c
>
> [ ... ]
>
>> @@ -1257,6 +1269,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,
>> +		.info = &ltr301_info_no_irq,
>> +		.info_no_irq = &ltr301_info_no_irq,
>> +		.channels = ltr301_channels,
>
> [Severity: High]
> This is a pre-existing issue, but does using ltr301_channels cause the
> trigger handler to hang if the timestamp channel is enabled?
>
> Looking at ltr301_channels, the timestamp channel occupies scan_index 2. If a
> user enables the timestamp channel, bit 2 is set in active_scan_mask.
>
> However, ltr501_trigger_handler() assumes bit 2 is always the proximity
> sensor:
>
> ltr501_trigger_handler() {
>         ...
>         if (test_bit(2, indio_dev->active_scan_mask))
>                 mask |= LTR501_STATUS_PS_RDY;
>
>         ret = ltr501_drdy(data, mask);
>         ...
> }
>
> Since sensors using ltr301_channels lack a proximity sensor, the hardware
> ready bit is never set. Could this cause ltr501_drdy() to loop and drop
> data?
>
>> +		.no_channels = ARRAY_SIZE(ltr301_channels),
>> +	},
>>  };
>
> [ ... ]
>
>> @@ -1531,6 +1555,11 @@ 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");
>> +			return -EINVAL;
>> +		}
>
> [Severity: Medium]
> Does this early return bypass device power-down on probe failure?
>
> If the device tree specifies an IRQ for a chip that does not support it,
> this will return -EINVAL directly instead of jumping to the
> powerdown_on_error label, which could leave the device powered on.

Ok. I guess I should fix the same issue for error handling of the
devm_request_threaded_irq() call.

> [Severity: High]
> This isn't a bug introduced by this patch, but is there a use-after-free
> risk when the threaded IRQ is requested here?
>
> The driver uses devm_request_threaded_irq() during probe but manually calls
> iio_device_unregister() in ltr501_remove().
>
> Because devm-managed resources are freed after ltr501_remove() completes,
> the interrupt remains active while iio_device_unregister() destroys the
> event interface.
>
> If an interrupt fires during this window, ltr501_interrupt_handler() calls
> iio_push_event(), which accesses the freed event interface structure.
>
>> +
>>  		ret = devm_request_threaded_irq(&client->dev, client->irq,
>>  						NULL, ltr501_interrupt_handler,
>>  						IRQF_TRIGGER_FALLING |
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260715-liteon-ltr329-v1-0-31f027051594@geanix.com?part=3