[PATCH 0/4] iio: proximity: vl53l0x: power sequencing, optional VDDIO, raw I2C ID read

[PATCH 0/4] iio: proximity: vl53l0x: power sequencing, optional VDDIO, raw I2C ID read

[Petr Hodina via B4 Relay]

Hi,

this series improves robustness and hardware compatibility of the
VL53L0X IIO proximity driver.

Patch 1 and 2 adds support for an optional VDDIO (vio) regulator and documents
it in the device tree binding.

Patch 3 fixes the reset and power-up sequencing. The previous logic drove
the reset GPIO in a way that does not match the datasheet timing and
level requirements.

Patch 4 switches the initial device identification from SMBus helpers to
raw I2C transfers and reads the full 16-bit model and revision IDs.

The series has been tested on hardware - Sony Xperia XZ3 (akatsuki).

Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
---
Petr Hodina (4):
      iio: proximity: vl53l0x-i2c: Add optional vddio regulator
      iio: proximity: vl53l0x-i2c: Add optional vddio supply
      iio: proximity: vl53l0x-i2c: Fix reset sequence
      iio: proximity: vl53l0x-i2c: Use raw I2C access and read full device ID

 .../bindings/iio/proximity/st,vl53l0x.yaml         |  2 +
 drivers/iio/proximity/vl53l0x-i2c.c                | 71 +++++++++++++++++++---
 2 files changed, 63 insertions(+), 10 deletions(-)
---
base-commit: 46fe65a2c28ecf5df1a7475aba1f08ccf4c0ac1b
change-id: 20251228-vl53l0x-573541e03f0d

Best regards,
-- 
Petr Hodina <petr.hodina@protonmail.com>

[PATCH 1/4] iio: proximity: vl53l0x-i2c: Add optional vddio regulator

[Petr Hodina via B4 Relay]

From: Petr Hodina <petr.hodina@protonmail.com>

The VL53L0X can be powered using separate core (VDD) and I/O (VDDIO)
supplies. Add support for an optional vio regulator and enable/disable
it during power on/off when present.

Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
---
 Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml b/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml
index 322befc41de6..f7e55d427fe4 100644
--- a/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml
+++ b/Documentation/devicetree/bindings/iio/proximity/st,vl53l0x.yaml
@@ -24,6 +24,8 @@ properties:
 
   vdd-supply: true
 
+  vio-supply: true
+
 required:
   - compatible
   - reg

-- 
2.52.0

Re: [PATCH 1/4] iio: proximity: vl53l0x-i2c: Add optional vddio regulator

[Krzysztof Kozlowski]

On Mon, Jan 19, 2026 at 06:19:55PM +0100, Petr Hodina wrote:
> The VL53L0X can be powered using separate core (VDD) and I/O (VDDIO)

There is no VDDIO pin. I checked on datasheet.

> supplies. Add support for an optional vio regulator and enable/disable
> it during power on/off when present.

Last sentence is incorrect in this context. This patch is not doing that
and anyway, whatever your driver is doing is not here really that
relevant.


Best regards,
Krzysztof

Re: [PATCH 1/4] iio: proximity: vl53l0x-i2c: Add optional vddio regulator

[Krzysztof Kozlowski]

On 19/01/2026 18:19, Petr Hodina via B4 Relay wrote:
> From: Petr Hodina <petr.hodina@protonmail.com>
> 
> The VL53L0X can be powered using separate core (VDD) and I/O (VDDIO)
> supplies. Add support for an optional vio regulator and enable/disable
> it during power on/off when present.
> 
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> ---


Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters


Best regards,
Krzysztof

[PATCH 2/4] iio: proximity: vl53l0x-i2c: Add optional vddio supply

[Petr Hodina via B4 Relay]

From: Petr Hodina <petr.hodina@protonmail.com>

The VL53L0X can be powered using separate core (VDD) and I/O (VDDIO)
supplies.

Add support for an optional vio regulator and enable/disable it during
power on/off when present. Update the device tree binding to document the
new optional supply.

Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
---
 drivers/iio/proximity/vl53l0x-i2c.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/iio/proximity/vl53l0x-i2c.c b/drivers/iio/proximity/vl53l0x-i2c.c
index ad3e46d47fa8..7bfab396377a 100644
--- a/drivers/iio/proximity/vl53l0x-i2c.c
+++ b/drivers/iio/proximity/vl53l0x-i2c.c
@@ -55,6 +55,7 @@ struct vl53l0x_data {
 	struct i2c_client *client;
 	struct completion completion;
 	struct regulator *vdd_supply;
+	struct regulator *vio_supply;
 	struct gpio_desc *reset_gpio;
 	struct iio_trigger *trig;
 };
@@ -256,6 +257,8 @@ static void vl53l0x_power_off(void *_data)
 	gpiod_set_value_cansleep(data->reset_gpio, 1);
 
 	regulator_disable(data->vdd_supply);
+	if (data->vio_supply)
+		regulator_disable(data->vio_supply);
 }
 
 static int vl53l0x_power_on(struct vl53l0x_data *data)
@@ -266,6 +269,12 @@ static int vl53l0x_power_on(struct vl53l0x_data *data)
 	if (ret)
 		return ret;
 
+	if (data->vio_supply) {
+		ret = regulator_enable(data->vio_supply);
+		if (ret)
+			return ret;
+	}
+
 	gpiod_set_value_cansleep(data->reset_gpio, 0);
 
 	usleep_range(3200, 5000);
@@ -338,6 +347,13 @@ static int vl53l0x_probe(struct i2c_client *client)
 		return dev_err_probe(&client->dev, PTR_ERR(data->vdd_supply),
 				     "Unable to get VDD regulator\n");
 
+	data->vio_supply = devm_regulator_get_optional(&client->dev, "vio");
+	if (PTR_ERR(data->vio_supply) == -ENODEV)
+		data->vio_supply = NULL;
+	else if (IS_ERR(data->vio_supply))
+		return dev_err_probe(&client->dev, PTR_ERR(data->vio_supply),
+				     "Unable to get VDDIO regulator\n");
+
 	data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
 	if (IS_ERR(data->reset_gpio))
 		return dev_err_probe(&client->dev, PTR_ERR(data->reset_gpio),

-- 
2.52.0

Re: [PATCH 2/4] iio: proximity: vl53l0x-i2c: Add optional vddio supply

[Jonathan Cameron]

On Mon, 19 Jan 2026 18:19:56 +0100
Petr Hodina via B4 Relay <devnull+petr.hodina.protonmail.com@kernel.org> wrote:

> From: Petr Hodina <petr.hodina@protonmail.com>
> 
> The VL53L0X can be powered using separate core (VDD) and I/O (VDDIO)
> supplies.
> 
> Add support for an optional vio regulator and enable/disable it during
> power on/off when present. Update the device tree binding to document the
> new optional supply.

In what sense is it optional?  Some change to device config to say don't
use it, or simply might not be in DT binding but in that case is always on?

If the second just let the regulator framework provide a stub regulator.
That is in the driver don't treat it as optional and all should work fine.


> 
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> ---
>  drivers/iio/proximity/vl53l0x-i2c.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/iio/proximity/vl53l0x-i2c.c b/drivers/iio/proximity/vl53l0x-i2c.c
> index ad3e46d47fa8..7bfab396377a 100644
> --- a/drivers/iio/proximity/vl53l0x-i2c.c
> +++ b/drivers/iio/proximity/vl53l0x-i2c.c
> @@ -55,6 +55,7 @@ struct vl53l0x_data {
>  	struct i2c_client *client;
>  	struct completion completion;
>  	struct regulator *vdd_supply;
> +	struct regulator *vio_supply;
>  	struct gpio_desc *reset_gpio;
>  	struct iio_trigger *trig;
>  };
> @@ -256,6 +257,8 @@ static void vl53l0x_power_off(void *_data)
>  	gpiod_set_value_cansleep(data->reset_gpio, 1);
>  
>  	regulator_disable(data->vdd_supply);
> +	if (data->vio_supply)
> +		regulator_disable(data->vio_supply);
>  }
>  
>  static int vl53l0x_power_on(struct vl53l0x_data *data)
> @@ -266,6 +269,12 @@ static int vl53l0x_power_on(struct vl53l0x_data *data)
>  	if (ret)
>  		return ret;
>  
> +	if (data->vio_supply) {
> +		ret = regulator_enable(data->vio_supply);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	gpiod_set_value_cansleep(data->reset_gpio, 0);
>  
>  	usleep_range(3200, 5000);
> @@ -338,6 +347,13 @@ static int vl53l0x_probe(struct i2c_client *client)
>  		return dev_err_probe(&client->dev, PTR_ERR(data->vdd_supply),
>  				     "Unable to get VDD regulator\n");
>  
> +	data->vio_supply = devm_regulator_get_optional(&client->dev, "vio");
> +	if (PTR_ERR(data->vio_supply) == -ENODEV)
> +		data->vio_supply = NULL;
> +	else if (IS_ERR(data->vio_supply))
> +		return dev_err_probe(&client->dev, PTR_ERR(data->vio_supply),
> +				     "Unable to get VDDIO regulator\n");
> +
>  	data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
>  	if (IS_ERR(data->reset_gpio))
>  		return dev_err_probe(&client->dev, PTR_ERR(data->reset_gpio),
> 

[PATCH 3/4] iio: proximity: vl53l0x-i2c: Fix reset sequence

[Petr Hodina via B4 Relay]

From: Petr Hodina <petr.hodina@protonmail.com>

Fix the reset GPIO handling and power-up timing to better match the
VL53L0X reset requirements.

Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
---
 drivers/iio/proximity/vl53l0x-i2c.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/proximity/vl53l0x-i2c.c b/drivers/iio/proximity/vl53l0x-i2c.c
index 7bfab396377a..6901ce7dd835 100644
--- a/drivers/iio/proximity/vl53l0x-i2c.c
+++ b/drivers/iio/proximity/vl53l0x-i2c.c
@@ -275,9 +275,13 @@ static int vl53l0x_power_on(struct vl53l0x_data *data)
 			return ret;
 	}
 
-	gpiod_set_value_cansleep(data->reset_gpio, 0);
-
-	usleep_range(3200, 5000);
+	usleep_range(5000, 6000);
+	if (data->reset_gpio) {
+		gpiod_set_value_cansleep(data->reset_gpio, 1);
+		usleep_range(5000, 6000);
+		gpiod_set_value_cansleep(data->reset_gpio, 0);
+		usleep_range(5000, 6000);
+	}
 
 	return 0;
 }
@@ -354,7 +358,7 @@ static int vl53l0x_probe(struct i2c_client *client)
 		return dev_err_probe(&client->dev, PTR_ERR(data->vio_supply),
 				     "Unable to get VDDIO regulator\n");
 
-	data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
+	data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_LOW);
 	if (IS_ERR(data->reset_gpio))
 		return dev_err_probe(&client->dev, PTR_ERR(data->reset_gpio),
 				     "Cannot get reset GPIO\n");

-- 
2.52.0

Re: [PATCH 3/4] iio: proximity: vl53l0x-i2c: Fix reset sequence

[Andy Shevchenko]

On Mon, Jan 19, 2026 at 06:19:57PM +0100, Petr Hodina via B4 Relay wrote:

> Fix the reset GPIO handling and power-up timing to better match the
> VL53L0X reset requirements.

...

> -	usleep_range(3200, 5000);
> +	usleep_range(5000, 6000);

> +		usleep_range(5000, 6000);

> +		usleep_range(5000, 6000);

Can you switch to fsleep() while at it?

...

> -	data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
> +	data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_LOW);
>  	if (IS_ERR(data->reset_gpio))
>  		return dev_err_probe(&client->dev, PTR_ERR(data->reset_gpio),
>  				     "Cannot get reset GPIO\n");

Wondering if in a future change this can be converted to use reset-gpio driver
instead of poking GPIOs directly.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/4] iio: proximity: vl53l0x-i2c: Fix reset sequence

[Krzysztof Kozlowski]

On Mon, Jan 19, 2026 at 06:19:57PM +0100, Petr Hodina wrote:
> Fix the reset GPIO handling and power-up timing to better match the
> VL53L0X reset requirements.
> 
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> ---
>  drivers/iio/proximity/vl53l0x-i2c.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/proximity/vl53l0x-i2c.c b/drivers/iio/proximity/vl53l0x-i2c.c
> index 7bfab396377a..6901ce7dd835 100644
> --- a/drivers/iio/proximity/vl53l0x-i2c.c
> +++ b/drivers/iio/proximity/vl53l0x-i2c.c
> @@ -275,9 +275,13 @@ static int vl53l0x_power_on(struct vl53l0x_data *data)
>  			return ret;
>  	}
>  
> -	gpiod_set_value_cansleep(data->reset_gpio, 0);
> -
> -	usleep_range(3200, 5000);
> +	usleep_range(5000, 6000);
> +	if (data->reset_gpio) {
> +		gpiod_set_value_cansleep(data->reset_gpio, 1);
> +		usleep_range(5000, 6000);
> +		gpiod_set_value_cansleep(data->reset_gpio, 0);
> +		usleep_range(5000, 6000);
> +	}
>  
>  	return 0;
>  }
> @@ -354,7 +358,7 @@ static int vl53l0x_probe(struct i2c_client *client)
>  		return dev_err_probe(&client->dev, PTR_ERR(data->vio_supply),
>  				     "Unable to get VDDIO regulator\n");
>  
> -	data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
> +	data->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_LOW);

This feels wrong - you are now bringing the device out of reset without
observing any of the reset sequence constraints.

Best regards,
Krzysztof

[PATCH 4/4] iio: proximity: vl53l0x-i2c: Use raw I2C access and read full device ID

[Petr Hodina via B4 Relay]

From: Petr Hodina <petr.hodina@protonmail.com>

Replace SMBus byte reads with raw I2C transfers when reading the device
identification registers.

The VL53L0X exposes its model and revision as 16-bit registers, which are
more accurately accessed using standard I2C send/receive operations.
This also avoids depending on SMBus byte data support, which is not
guaranteed on all I2C adapters.

Read and log both model and revision IDs, and validate the model ID
during probe to ensure the expected device is present.

Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
---
 drivers/iio/proximity/vl53l0x-i2c.c | 45 +++++++++++++++++++++++++++++++------
 1 file changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/iio/proximity/vl53l0x-i2c.c b/drivers/iio/proximity/vl53l0x-i2c.c
index 6901ce7dd835..a2de4cc16a43 100644
--- a/drivers/iio/proximity/vl53l0x-i2c.c
+++ b/drivers/iio/proximity/vl53l0x-i2c.c
@@ -320,11 +320,35 @@ static const struct iio_trigger_ops vl53l0x_trigger_ops = {
 	.validate_device = iio_trigger_validate_own_device,
 };
 
+
+static int vl53l0x_read_word(struct i2c_client *client, u8 reg, u16 *val)
+{
+	int ret;
+	u8 buf[2];
+
+	ret = i2c_master_send(client, &reg, 1);
+	if (ret < 0)
+		return ret;
+	if (ret != 1)
+		return -EIO;
+
+	ret = i2c_master_recv(client, buf, 2);
+	if (ret < 0)
+		return ret;
+	if (ret != 2)
+		return -EIO;
+
+	*val = (buf[0] << 8) | buf[1];
+
+	return 0;
+}
+
 static int vl53l0x_probe(struct i2c_client *client)
 {
 	struct vl53l0x_data *data;
 	struct iio_dev *indio_dev;
 	int ret;
+	u16 model, rev;
 
 	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
 	if (!indio_dev)
@@ -339,13 +363,6 @@ static int vl53l0x_probe(struct i2c_client *client)
 				     I2C_FUNC_SMBUS_BYTE_DATA))
 		return -EOPNOTSUPP;
 
-	ret = i2c_smbus_read_byte_data(data->client, VL_REG_IDENTIFICATION_MODEL_ID);
-	if (ret < 0)
-		return -EINVAL;
-
-	if (ret != VL53L0X_MODEL_ID_VAL)
-		dev_info(&client->dev, "Unknown model id: 0x%x", ret);
-
 	data->vdd_supply = devm_regulator_get(&client->dev, "vdd");
 	if (IS_ERR(data->vdd_supply))
 		return dev_err_probe(&client->dev, PTR_ERR(data->vdd_supply),
@@ -372,6 +389,20 @@ static int vl53l0x_probe(struct i2c_client *client)
 	if (ret)
 		return ret;
 
+	ret = vl53l0x_read_word(client, 0xC0, &model);
+	if (ret)
+		return dev_err_probe(&client->dev, ret, "Failed to read model ID\n");
+
+	ret = vl53l0x_read_word(client, 0xC2, &rev);
+	if (ret)
+		return dev_err_probe(&client->dev, ret, "Failed to read revision ID\n");
+
+	dev_info(&client->dev, "VL53L0X model=0x%04x rev=0x%04x\n", model, rev);
+
+	if ((model >> 8) != VL53L0X_MODEL_ID_VAL)
+		return dev_err_probe(&client->dev, -ENODEV,
+			"Unexpected model ID: 0x%04x\n", model);
+
 	indio_dev->name = "vl53l0x";
 	indio_dev->info = &vl53l0x_info;
 	indio_dev->channels = vl53l0x_channels;

-- 
2.52.0

Re: [PATCH 4/4] iio: proximity: vl53l0x-i2c: Use raw I2C access and read full device ID

[Andy Shevchenko]

On Mon, Jan 19, 2026 at 06:19:58PM +0100, Petr Hodina via B4 Relay wrote:

> Replace SMBus byte reads with raw I2C transfers when reading the device
> identification registers.
> 
> The VL53L0X exposes its model and revision as 16-bit registers, which are
> more accurately accessed using standard I2C send/receive operations.
> This also avoids depending on SMBus byte data support, which is not
> guaranteed on all I2C adapters.
> 
> Read and log both model and revision IDs, and validate the model ID
> during probe to ensure the expected device is present.

...

>  };
>  
> +

Stray blank line addition.

> +static int vl53l0x_read_word(struct i2c_client *client, u8 reg, u16 *val)
> +{
> +	int ret;
> +	u8 buf[2];

Here and everywhere else, please, keep the reversed xmas tree ordering.

> +	ret = i2c_master_send(client, &reg, 1);
> +	if (ret < 0)
> +		return ret;
> +	if (ret != 1)
> +		return -EIO;
> +
> +	ret = i2c_master_recv(client, buf, 2);

sizeof(buf)

> +	if (ret < 0)
> +		return ret;
> +	if (ret != 2)

Ditto.

> +		return -EIO;
> +
> +	*val = (buf[0] << 8) | buf[1];

Actually define

	__be16 buf;

and use

	*val = be16_to_cpu(buf);

> +	return 0;
> +}

...

>  static int vl53l0x_probe(struct i2c_client *client)
>  {
>  	struct vl53l0x_data *data;
>  	struct iio_dev *indio_dev;
>  	int ret;
> +	u16 model, rev;
>  

Use reversed xmas tree ordering.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 4/4] iio: proximity: vl53l0x-i2c: Use raw I2C access and read full device ID

[Krzysztof Kozlowski]

On 19/01/2026 18:19, Petr Hodina via B4 Relay wrote:
> diff --git a/drivers/iio/proximity/vl53l0x-i2c.c b/drivers/iio/proximity/vl53l0x-i2c.c
> index 6901ce7dd835..a2de4cc16a43 100644
> --- a/drivers/iio/proximity/vl53l0x-i2c.c
> +++ b/drivers/iio/proximity/vl53l0x-i2c.c
> @@ -320,11 +320,35 @@ static const struct iio_trigger_ops vl53l0x_trigger_ops = {
>  	.validate_device = iio_trigger_validate_own_device,
>  };
>  
> +

Do not introduce stray blank lines.

> +static int vl53l0x_read_word(struct i2c_client *client, u8 reg, u16 *val)
> +{
> +	int ret;
> +	u8 buf[2];
> +
> +	ret = i2c_master_send(client, &reg, 1);
> +	if (ret < 0)
> +		return ret;
> +	if (ret != 1)
> +		return -EIO;
> +
> +	ret = i2c_master_recv(client, buf, 2);
> +	if (ret < 0)
> +		return ret;
> +	if (ret != 2)
> +		return -EIO;
> +
> +	*val = (buf[0] << 8) | buf[1];
> +
> +	return 0;
> +}
> +
>  static int vl53l0x_probe(struct i2c_client *client)
>  {
>  	struct vl53l0x_data *data;
>  	struct iio_dev *indio_dev;
>  	int ret;
> +	u16 model, rev;
>  
>  	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
>  	if (!indio_dev)
> @@ -339,13 +363,6 @@ static int vl53l0x_probe(struct i2c_client *client)
>  				     I2C_FUNC_SMBUS_BYTE_DATA))
>  		return -EOPNOTSUPP;
>  
> -	ret = i2c_smbus_read_byte_data(data->client, VL_REG_IDENTIFICATION_MODEL_ID);
> -	if (ret < 0)
> -		return -EINVAL;
> -
> -	if (ret != VL53L0X_MODEL_ID_VAL)
> -		dev_info(&client->dev, "Unknown model id: 0x%x", ret);
> -
>  	data->vdd_supply = devm_regulator_get(&client->dev, "vdd");
>  	if (IS_ERR(data->vdd_supply))
>  		return dev_err_probe(&client->dev, PTR_ERR(data->vdd_supply),
> @@ -372,6 +389,20 @@ static int vl53l0x_probe(struct i2c_client *client)
>  	if (ret)
>  		return ret;
>  
> +	ret = vl53l0x_read_word(client, 0xC0, &model);
> +	if (ret)
> +		return dev_err_probe(&client->dev, ret, "Failed to read model ID\n");
> +
> +	ret = vl53l0x_read_word(client, 0xC2, &rev);
> +	if (ret)
> +		return dev_err_probe(&client->dev, ret, "Failed to read revision ID\n");
> +
> +	dev_info(&client->dev, "VL53L0X model=0x%04x rev=0x%04x\n", model, rev);

dev_dbg

This does not look like useful printk message. Drivers should be silent
on success:
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/coding-style.rst#L913
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/debugging/driver_development_debugging_guide.rst#L79

Best regards,
Krzysztof

Re: [PATCH 4/4] iio: proximity: vl53l0x-i2c: Use raw I2C access and read full device ID

[Jonathan Cameron]

On Mon, 19 Jan 2026 18:19:58 +0100
Petr Hodina via B4 Relay <devnull+petr.hodina.protonmail.com@kernel.org> wrote:

> From: Petr Hodina <petr.hodina@protonmail.com>
> 
> Replace SMBus byte reads with raw I2C transfers when reading the device
> identification registers.
> 
> The VL53L0X exposes its model and revision as 16-bit registers, which are
> more accurately accessed using standard I2C send/receive operations.
> This also avoids depending on SMBus byte data support, which is not
> guaranteed on all I2C adapters.

Hmm. I thought it was emulated wherever possible.  See below for
request for a specific comment on what the subtle difference is.
I'm also wondering from this description if it actually works with
smbus but  isn't documented as doing so?
> 
> Read and log both model and revision IDs, and validate the model ID
> during probe to ensure the expected device is present.
> 
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> ---
>  drivers/iio/proximity/vl53l0x-i2c.c | 45 +++++++++++++++++++++++++++++++------
>  1 file changed, 38 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/proximity/vl53l0x-i2c.c b/drivers/iio/proximity/vl53l0x-i2c.c
> index 6901ce7dd835..a2de4cc16a43 100644
> --- a/drivers/iio/proximity/vl53l0x-i2c.c
> +++ b/drivers/iio/proximity/vl53l0x-i2c.c
> @@ -320,11 +320,35 @@ static const struct iio_trigger_ops vl53l0x_trigger_ops = {
>  	.validate_device = iio_trigger_validate_own_device,
>  };
>  
> +
> +static int vl53l0x_read_word(struct i2c_client *client, u8 reg, u16 *val)
> +{
> +	int ret;
> +	u8 buf[2];
> +
> +	ret = i2c_master_send(client, &reg, 1);

Add a comment that a stop is needed. Otherwise this would
be i2c_smbus_read_word_swapped()

Sigh, seems ST liked to make everyone's life a little harder ;)


> +	if (ret < 0)
> +		return ret;
> +	if (ret != 1)
> +		return -EIO;
> +
> +	ret = i2c_master_recv(client, buf, 2);
> +	if (ret < 0)
> +		return ret;
> +	if (ret != 2)
> +		return -EIO;
> +
> +	*val = (buf[0] << 8) | buf[1];
> +
> +	return 0;
> +}
> +
>  static int vl53l0x_probe(struct i2c_client *client)
>  {
>  	struct vl53l0x_data *data;
>  	struct iio_dev *indio_dev;
>  	int ret;
> +	u16 model, rev;
>  
>  	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
>  	if (!indio_dev)
> @@ -339,13 +363,6 @@ static int vl53l0x_probe(struct i2c_client *client)
>  				     I2C_FUNC_SMBUS_BYTE_DATA))
>  		return -EOPNOTSUPP;
>  
> -	ret = i2c_smbus_read_byte_data(data->client, VL_REG_IDENTIFICATION_MODEL_ID);
> -	if (ret < 0)
> -		return -EINVAL;
> -
> -	if (ret != VL53L0X_MODEL_ID_VAL)
> -		dev_info(&client->dev, "Unknown model id: 0x%x", ret);
> -
>  	data->vdd_supply = devm_regulator_get(&client->dev, "vdd");
>  	if (IS_ERR(data->vdd_supply))
>  		return dev_err_probe(&client->dev, PTR_ERR(data->vdd_supply),
> @@ -372,6 +389,20 @@ static int vl53l0x_probe(struct i2c_client *client)
>  	if (ret)
>  		return ret;
>  
> +	ret = vl53l0x_read_word(client, 0xC0, &model);
defines for the register addresses.
I'm curious why they got bigger in a patch that doesn't mention it in the
patch description.

> +	if (ret)
> +		return dev_err_probe(&client->dev, ret, "Failed to read model ID\n");
Given these long lines, it would be good to have a precursor patch
struct device *dev = &client->dev;
and use that throughout probe()

> +
> +	ret = vl53l0x_read_word(client, 0xC2, &rev);
> +	if (ret)
> +		return dev_err_probe(&client->dev, ret, "Failed to read revision ID\n");
> +
> +	dev_info(&client->dev, "VL53L0X model=0x%04x rev=0x%04x\n", model, rev);
> +
> +	if ((model >> 8) != VL53L0X_MODEL_ID_VAL)
> +		return dev_err_probe(&client->dev, -ENODEV,
> +			"Unexpected model ID: 0x%04x\n", model);
See comment on other patch. This breaks DT fallback compatibles and
the benefit they bring for new compatible parts being able to be run with 
old kernels.  Just warn and carry on with whatever the firmware told you this
was.

> +
>  	indio_dev->name = "vl53l0x";
>  	indio_dev->info = &vl53l0x_info;
>  	indio_dev->channels = vl53l0x_channels;
>