.../bindings/iio/proximity/st,vl53l0x.yaml | 7 +- MAINTAINERS | 7 + drivers/iio/proximity/Kconfig | 14 + drivers/iio/proximity/Makefile | 1 + drivers/iio/proximity/vl53l1x-i2c.c | 782 ++++++++++++++++++ 5 files changed, 809 insertions(+), 2 deletions(-) create mode 100644 drivers/iio/proximity/vl53l1x-i2c.c
This series adds support for the STMicroelectronics VL53L1X Time-of-Flight ranging sensor. The VL53L1X is a ToF laser-ranging sensor with I2C interface, capable of measuring distances up to 4 meters. The driver supports both interrupt-driven and polled operation. Why a separate driver is needed (instead of extending vl53l0x-i2c.c): The VL53L1X is fundamentally different from the VL53L0X despite the similar naming. Extending the existing driver would require rewriting the majority of it. Key differences include: - A different register map (16-bit addresses vs. 8-bit addresses). - Requires a 91-byte firmware configuration blob to be loaded at boot. - Requires a VHV calibration cycle. - Has distance mode and timing budget configurations. - Uses the regmap API rather than raw i2c_smbus calls. I also reviewed other drivers in drivers/iio/proximity/ and can confirm this IP block does not appear to be shared by any other existing driver. Tested on Raspberry Pi 5 with a VL53L1X breakout board. Note on vdd-supply: In v2, I added vdd-supply as required. Since I'm using the shared st,vl53l0x.yaml binding now, I had to drop that requirement to avoid breaking backward compatibility for existing st,vl53l0x devicetrees. The driver itself still uses non-optional devm_regulator_get() so no change there. --- Changes in v3: - Merge DT binding into existing st,vl53l0x.yaml (per Krzysztof). - Use "reset-gpios" in the binding but xshut_gpio in the driver since that's the actual pin name. - Replace manual polling loops in chip_init and read_proximity with regmap_read_poll_timeout(). - Remove irq_get_trigger_type() and pass IRQF_NO_THREAD directly (per Andy). - Drop struct i2c_client from private data and store irq as int instead. Derive struct device from regmap where needed. - Add dev_err_probe() to first devm_request_irq() error path. - Replace linux/device.h with linux/dev_printk.h, add linux/array_size.h, linux/err.h, linux/types.h (per Andy). - Use USEC_PER_MSEC for poll timeouts. - Remove unnecessary casts. - Divide long config blob to 8 values per line. - Rename goto label to notify_and_clear_irq and drop unused dev_dbg. - Add datasheet section reference for boot delay comment. - vdd-supply no longer required in shared binding to avoid breaking existing st,vl53l0x devicetrees. Changes in v2: - Skip software reset in chip_init when xshut GPIO is available, since the device was already hardware-reset during power-on. - Rename "reset" GPIO to "xshut" to match the datasheet pin name and updated DT binding accordingly. - Make vdd-supply required in DT binding. - Use reg_sequence arrays and regmap_multi_reg_write() for distance mode configuration. - Switch to a hardirq handler with iio_trigger_poll() and IRQF_NO_THREAD instead of a threaded handler. - Drop IRQF_TRIGGER_FALLING fallback. Leave trigger type to firmware/DT. - Use iio_validate_own_trigger() instead of a custom validate_trigger, drop trig pointer from driver data. - Switch usleep_range() to fsleep() throughout and add comments for sleep values. - Don't fail probe on unknown model ID, just log with dev_info(). - Split stop_ranging cleanup into its own devm action, separate from power_off. - Add missing includes: device.h, bitfield.h, completion.h, mod_devicetable.h. - Use FIELD_GET() for range status checks. - Move configure_irq() closer to probe(), use dev_err_probe() for its error paths. - Fix buffer ops symmetry: postdisable -> predisable. - Drop reg_format_endian from regmap config. - Various alignment and formatting fixes. Link to v2: https://lore.kernel.org/linux-iio/20260308113728.40860-1-email@sirat.me Link to v1: https://lore.kernel.org/linux-iio/20260303090253.42076-1-email@sirat.me Siratul Islam (2): dt-bindings: iio: proximity: add ST VL53L1X ToF sensor iio: proximity: add driver for ST VL53L1X ToF sensor .../bindings/iio/proximity/st,vl53l0x.yaml | 7 +- MAINTAINERS | 7 + drivers/iio/proximity/Kconfig | 14 + drivers/iio/proximity/Makefile | 1 + drivers/iio/proximity/vl53l1x-i2c.c | 782 ++++++++++++++++++ 5 files changed, 809 insertions(+), 2 deletions(-) create mode 100644 drivers/iio/proximity/vl53l1x-i2c.c -- 2.53.0
On Thu, Mar 12, 2026 at 04:40:35AM +0600, Siratul Islam wrote: > This series adds support for the STMicroelectronics VL53L1X > Time-of-Flight ranging sensor. > > The VL53L1X is a ToF laser-ranging sensor with I2C interface, > capable of measuring distances up to 4 meters. The driver > supports both interrupt-driven and polled operation. > > Why a separate driver is needed (instead of extending vl53l0x-i2c.c): > The VL53L1X is fundamentally different from the VL53L0X despite the > similar naming. Extending the existing driver would require rewriting > the majority of it. > Key differences include: > - A different register map (16-bit addresses vs. 8-bit addresses). > - Requires a 91-byte firmware configuration blob to be loaded at boot. > - Requires a VHV calibration cycle. > - Has distance mode and timing budget configurations. > - Uses the regmap API rather than raw i2c_smbus calls. > > I also reviewed other drivers in drivers/iio/proximity/ and can > confirm this IP block does not appear to be shared by any other > existing driver. > --- > Changes in v3: > - Merge DT binding into existing st,vl53l0x.yaml (per Krzysztof). > - Use "reset-gpios" in the binding but xshut_gpio in the driver since that's the actual pin name. But why is it "reset" in the bindings? If it's a power rail or enable pin, why not call it as a such in the bindings? The connection on PCB level is different story. > - Replace manual polling loops in chip_init and read_proximity with regmap_read_poll_timeout(). > - Remove irq_get_trigger_type() and pass IRQF_NO_THREAD directly (per Andy). > - Drop struct i2c_client from private data and store irq as int instead. Derive struct device from regmap where needed. > - Add dev_err_probe() to first devm_request_irq() error path. > - Replace linux/device.h with linux/dev_printk.h, add linux/array_size.h, linux/err.h, linux/types.h (per Andy). > - Use USEC_PER_MSEC for poll timeouts. > - Remove unnecessary casts. > - Divide long config blob to 8 values per line. > - Rename goto label to notify_and_clear_irq and drop unused dev_dbg. > - Add datasheet section reference for boot delay comment. > - vdd-supply no longer required in shared binding to avoid breaking existing st,vl53l0x devicetrees. -- With Best Regards, Andy Shevchenko
On Thu, Mar 12, 2026 at 8:28 PM Andy Shevchenko <andriy.shevchenko@intel.com> wrote: > > On Thu, Mar 12, 2026 at 04:40:35AM +0600, Siratul Islam wrote: ... > > --- > > Changes in v3: > > - Merge DT binding into existing st,vl53l0x.yaml (per Krzysztof). > > - Use "reset-gpios" in the binding but xshut_gpio in the driver since that's the actual pin name. > > But why is it "reset" in the bindings? If it's a power rail or enable pin, why > not call it as a such in the bindings? The connection on PCB level is different story. > In v2, I actually used a separate st,vl53l1x.yaml binding with `xshut-gpios` and a required `vdd-supply`. But Krzysztof pointed out that they share the same pins so the existing st,vl53l0x.yaml should suffice, using reset as the xshut pin. I think a choice has to be made here: 1. Either I use the st,vl53l0x.yaml binding with wrong pin name and optional vdd-supply to not break existing code. 2. Or use a separate binding st,vl53l1x.yaml with 1. correct pin name, and 2. require vdd-supply Krzysztof, do you have a preference on how we should handle this? > >
On 3/12/26 10:12 AM, Sirat wrote:
> On Thu, Mar 12, 2026 at 8:28 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
>>
>> On Thu, Mar 12, 2026 at 04:40:35AM +0600, Siratul Islam wrote:
> ...
>>> ---
>>> Changes in v3:
>>> - Merge DT binding into existing st,vl53l0x.yaml (per Krzysztof).
>>> - Use "reset-gpios" in the binding but xshut_gpio in the driver since that's the actual pin name.
>>
>> But why is it "reset" in the bindings? If it's a power rail or enable pin, why
>> not call it as a such in the bindings? The connection on PCB level is different story.
>>
> In v2, I actually used a separate st,vl53l1x.yaml binding with
> `xshut-gpios` and a required `vdd-supply`.
> But Krzysztof pointed out that they share the same pins so the
> existing st,vl53l0x.yaml should suffice,
> using reset as the xshut pin.
>
> I think a choice has to be made here:
> 1. Either I use the st,vl53l0x.yaml binding with wrong pin name and
> optional vdd-supply to not break existing code.
> 2. Or use a separate binding st,vl53l1x.yaml with 1. correct pin name,
> and 2. require vdd-supply
We can modify the existing binding to make the supply required based
on the compatible.
allOf:
# Technically supply is required to power device, but we keep it
# optional for "st,vl53l0x" for backwards compatibility.
- if:
not:
properties:
compatible:
const: "st,vl53l0x"
then:
required:
vdd-supply
And we can add a description to reset-gpios to explain that it is actually the
XSHUT pin.
>
> Krzysztof, do you have a preference on how we should handle this?
>>
>>
On Sat, Mar 14, 2026 at 8:39 PM David Lechner <dlechner@baylibre.com> wrote: > > On 3/12/26 10:12 AM, Sirat wrote: > > On Thu, Mar 12, 2026 at 8:28 PM Andy Shevchenko > > <andriy.shevchenko@intel.com> wrote: > >> > >> On Thu, Mar 12, 2026 at 04:40:35AM +0600, Siratul Islam wrote: > > ... > >>> --- > >>> Changes in v3: > >>> - Merge DT binding into existing st,vl53l0x.yaml (per Krzysztof). > >>> - Use "reset-gpios" in the binding but xshut_gpio in the driver since that's the actual pin name. > >> > > We can modify the existing binding to make the supply required based > on the compatible. > > allOf: > # Technically supply is required to power device, but we keep it > # optional for "st,vl53l0x" for backwards compatibility. > - if: > not: > properties: > compatible: > const: "st,vl53l0x" > then: > required: > vdd-supply > > > And we can add a description to reset-gpios to explain that it is actually the > XSHUT pin. > This will solve the problem, but I'm concerned about someone not following the commit history looking at the code. Logically, it doesn't make sense as both the devices require the supply. In fact it may give the impression that the vl53l0x explicitly doesn't need power. We are having to deal with too much just to save us from writing a new file. That said, I can still implement this if it's still the prefered way to solve our problem. Or leave it optional as it is. >
On Sat, 14 Mar 2026 21:25:44 +0600 Sirat <email@sirat.me> wrote: > On Sat, Mar 14, 2026 at 8:39 PM David Lechner <dlechner@baylibre.com> wrote: > > > > On 3/12/26 10:12 AM, Sirat wrote: > > > On Thu, Mar 12, 2026 at 8:28 PM Andy Shevchenko > > > <andriy.shevchenko@intel.com> wrote: > > >> > > >> On Thu, Mar 12, 2026 at 04:40:35AM +0600, Siratul Islam wrote: > > > ... > > >>> --- > > >>> Changes in v3: > > >>> - Merge DT binding into existing st,vl53l0x.yaml (per Krzysztof). > > >>> - Use "reset-gpios" in the binding but xshut_gpio in the driver since that's the actual pin name. > > >> > > > > We can modify the existing binding to make the supply required based > > on the compatible. > > > > allOf: > > # Technically supply is required to power device, but we keep it > > # optional for "st,vl53l0x" for backwards compatibility. > > - if: > > not: > > properties: > > compatible: > > const: "st,vl53l0x" > > then: > > required: > > vdd-supply > > > > > > And we can add a description to reset-gpios to explain that it is actually the > > XSHUT pin. > > > This will solve the problem, but I'm concerned about someone not > following the commit history looking at the code. > Logically, it doesn't make sense as both the devices require the > supply. In fact it may give the impression that > the vl53l0x explicitly doesn't need power. We are having to deal with > too much just to save us from writing a new file. > > That said, I can still implement this if it's still the prefered way > to solve our problem. Or leave it optional as it is. > > Can make it required in the binding. Just explain clearly why it should be there. The driver should carry on coping without it though (and leave a comment so we don't break that in the future). Jonathan >
On Mon, Mar 16, 2026 at 12:57 AM Jonathan Cameron <jic23@kernel.org> wrote: > > On Sat, 14 Mar 2026 21:25:44 +0600 > Sirat <email@sirat.me> wrote: > > > On Sat, Mar 14, 2026 at 8:39 PM David Lechner <dlechner@baylibre.com> wrote: > > > > > > On 3/12/26 10:12 AM, Sirat wrote: > > > > On Thu, Mar 12, 2026 at 8:28 PM Andy Shevchenko > > > > <andriy.shevchenko@intel.com> wrote: > > > >> > > > >> On Thu, Mar 12, 2026 at 04:40:35AM +0600, Siratul Islam wrote: > > > > ... > > > >>> --- ... > Can make it required in the binding. Just explain clearly why > it should be there. The driver should carry on coping without > it though (and leave a comment so we don't break that in the future). > > Jonathan > > > > Just to make sure that I understand this correctly, I will - make vdd-supply required and add a description of what it is. - add a comment in the driver like "vdd-supply is required in the DT binding but we continue if missing to support older DTs." - also add reset-gpio description and update the example to include the vdd. I'll send v6 after a few days. Thanks, Sirat > >
On Mon, 16 Mar 2026 05:20:29 +0600 Sirat <email@sirat.me> wrote: > On Mon, Mar 16, 2026 at 12:57 AM Jonathan Cameron <jic23@kernel.org> wrote: > > > > On Sat, 14 Mar 2026 21:25:44 +0600 > > Sirat <email@sirat.me> wrote: > > > > > On Sat, Mar 14, 2026 at 8:39 PM David Lechner <dlechner@baylibre.com> wrote: > > > > > > > > On 3/12/26 10:12 AM, Sirat wrote: > > > > > On Thu, Mar 12, 2026 at 8:28 PM Andy Shevchenko > > > > > <andriy.shevchenko@intel.com> wrote: > > > > >> > > > > >> On Thu, Mar 12, 2026 at 04:40:35AM +0600, Siratul Islam wrote: > > > > > ... > > > > >>> --- > ... > > Can make it required in the binding. Just explain clearly why > > it should be there. The driver should carry on coping without > > it though (and leave a comment so we don't break that in the future). > > > > Jonathan > > > > > > > > Just to make sure that I understand this correctly, > > I will > - make vdd-supply required and add a description of what it is. > - add a comment in the driver like "vdd-supply is required in the DT > binding but we continue if missing to support older DTs." > - also add reset-gpio description and update the example to include the vdd. > > I'll send v6 after a few days. > Ah sorry. Took me too long to catch up with emails. Bit late now but for the record, what we were aiming for was: Make it required and add a note to the commit message to say why the requirement should always have been there. Devices tend not to work with no power. The driver fallback stuff to provide a stub powersupply is very standard so no specific need to call that out. Jonathan > Thanks, > Sirat > > > >
On Thu, Mar 12, 2026 at 09:12:30PM +0600, Sirat wrote: > On Thu, Mar 12, 2026 at 8:28 PM Andy Shevchenko > <andriy.shevchenko@intel.com> wrote: > > On Thu, Mar 12, 2026 at 04:40:35AM +0600, Siratul Islam wrote: ... > > > --- > > > Changes in v3: > > > - Merge DT binding into existing st,vl53l0x.yaml (per Krzysztof). > > > - Use "reset-gpios" in the binding but xshut_gpio in the driver since that's the actual pin name. > > > > But why is it "reset" in the bindings? If it's a power rail or enable pin, why > > not call it as a such in the bindings? The connection on PCB level is different story. > > > In v2, I actually used a separate st,vl53l1x.yaml binding with > `xshut-gpios` and a required `vdd-supply`. > But Krzysztof pointed out that they share the same pins so the > existing st,vl53l0x.yaml should suffice, > using reset as the xshut pin. > I think a choice has to be made here: > 1. Either I use the st,vl53l0x.yaml binding with wrong pin name and > optional vdd-supply to not break existing code. > 2. Or use a separate binding st,vl53l1x.yaml with 1. correct pin name, > and 2. require vdd-supply > > Krzysztof, do you have a preference on how we should handle this? I am not a DT guy, I only know (?) that the DT should describe HW. In HW this pin seems like power enable which can roughly be considered as reset. So from SW point of view it probably makes little to no difference. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.