All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: vidhu.linux@gmail.com
Cc: "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-iio@vger.kernel.org,
	"Shuah Khan" <skhan@linuxfoundation.org>
Subject: Re: [PATCH 3/3] iio: proximity: Add Benewake TF-Luna LiDAR driver
Date: Tue, 20 Oct 2026 11:10:32 +0300	[thread overview]
Message-ID: <atch-NQ78VUdfgxW@ashevche-desk.local> (raw)
In-Reply-To: <20261020-tf-luna-v1-3-53a88f93db24@gmail.com>

On Tue, Oct 20, 2026 at 12:03:43AM +0530, Vidhu Sarwal via B4 Relay wrote:
> 
> Add a driver for the Benewake TF-Luna, a single-point time-of-flight
> LiDAR distance sensor with a range of 0.2 m to 8 m, connected over I2C.
> 
> The sensor is run in trigger mode. Each read starts one measurement and
> waits for the timestamp register to change before reading the result.
> In continuous mode a read can catch the sensor in the middle of updating
> its result registers unless it is synchronised to the data ready output,
> which this driver does not use yet.
> 
> When the signal strength is too low the sensor reports a dummy distance
> of 0, so such readings, as well as overexposed ones, return -ENODATA
> instead of a distance.

On top of my previous reply.

...

> +static int tf_luna_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	struct tf_luna_data *data;
> +	struct iio_dev *indio_dev;
> +	unsigned int mode;
> +	u8 signature[4];
> +	u8 version[3];
> +	int ret;

It also makes sense to have local variable here

	struct regmap *map;


> +	indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	data = iio_priv(indio_dev);
> +
> +	ret = devm_mutex_init(dev, &data->lock);
> +	if (ret)
> +		return ret;

> +	data->regmap = devm_regmap_init_i2c(client, &tf_luna_regmap_config);
> +	if (IS_ERR(data->regmap))
> +		return dev_err_probe(dev, PTR_ERR(data->regmap),
> +				     "Failed to initialize regmap\n");

	map = devm_regmap_init_i2c(client, &tf_luna_regmap_config);
	if (IS_ERR(map))
		return dev_err_probe(dev, PTR_ERR(map), "Failed to initialize regmap\n");
	data->regmap = map;

> +	ret = devm_regulator_get_enable(dev, "vcc");
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to enable vcc regulator\n");
> +
> +	/* Boot time is not documented, about 350 ms was measured */
> +	fsleep(500 * USEC_PER_MSEC);
> +
> +	ret = regmap_bulk_read(data->regmap, TF_LUNA_REG_SIGNATURE, signature,
> +			       sizeof(signature));

Make it split logically and taking into account the above either

	ret = regmap_bulk_read(map, TF_LUNA_REG_SIGNATURE,
			       signature, sizeof(signature));

OR

	ret = regmap_bulk_read(map, TF_LUNA_REG_SIGNATURE, signature, sizeof(signature));

(perhaps you can shorten the 'signature' to 'sign' to fit).

> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to read signature\n");
> +
> +	if (memcmp(signature, "LUNA", sizeof(signature)))

Hmm... No. Please, make signature to be __?e32 and use a definition for this
FourCC [1] in the hexadecimal with the comment, and compare as regular integers...

> +		dev_info(dev, "Unknown signature %*ph, continuing\n",
> +			 (int)sizeof(signature), signature);

...and here use %*p4c?.

#define	TF_LUNA_SIGN	0x... /* "LUNA" in ASCII */

	__?e32 signature;
	u32 fourcc;
	...
	ret = regmap_bulk_read(map, TF_LUNA_REG_SIGNATURE, signature, sizeof(signature));
	...
	fourcc = ?e32_to_cpu(signature);
	if (fourcc != TF_LUNA_SIGN)
		dev_info(dev, "Unknown signature %p4c?, continuing\n", &fourcc);

where '?' represents either 'b' or 'l' depending on what you have and what you
want to see printed.

> +	ret = regmap_bulk_read(data->regmap, TF_LUNA_REG_VERSION, version,
> +			       sizeof(version));

	ret = regmap_bulk_read(map, TF_LUNA_REG_VERSION, version, sizeof(version));

(or 'version' --> 'ver', for example).

> +	if (ret)
> +		return ret;
>
> +	dev_dbg(dev, "Firmware version %u.%u.%u\n",
> +		version[2], version[1], version[0]);

Yeah, I need to post my series to also make this to be a pointer extension.

> +	/*
> +	 * In continuous mode a read can catch the sensor updating its result
> +	 * registers unless it is synchronised to the data ready output. Use
> +	 * trigger mode and start each measurement on demand instead.
> +	 */
> +	ret = regmap_write(data->regmap, TF_LUNA_REG_MODE, TF_LUNA_MODE_TRIGGER);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * The sensor silently drops writes it is not ready for, so check that
> +	 * the mode was set. A write takes up to 100 ms to read back.
> +	 */
> +	fsleep(100 * USEC_PER_MSEC);

msleep() as it's known to be big enough.

> +	ret = regmap_read(data->regmap, TF_LUNA_REG_MODE, &mode);
> +	if (ret)
> +		return ret;
> +
> +	if (mode != TF_LUNA_MODE_TRIGGER)
> +		return dev_err_probe(dev, -EIO, "Failed to set trigger mode\n");
> +
> +	indio_dev->name = "tf-luna";
> +	indio_dev->info = &tf_luna_info;
> +	indio_dev->channels = tf_luna_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(tf_luna_channels);
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +
> +	return devm_iio_device_register(dev, indio_dev);
> +}

[1]: https://en.wikipedia.org/wiki/FourCC

-- 
With Best Regards,
Andy Shevchenko



      parent reply	other threads:[~2026-10-20  8:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 18:33 [PATCH 0/3] iio: proximity: Add Benewake TF-Luna LiDAR driver Vidhu Sarwal via B4 Relay
2026-10-19 18:33 ` Vidhu Sarwal
2026-10-19 18:33 ` [PATCH 1/3] dt-bindings: vendor-prefixes: Add Benewake Vidhu Sarwal via B4 Relay
2026-10-19 18:33   ` Vidhu Sarwal
2026-10-20  8:35   ` Krzysztof Kozlowski
2026-10-19 18:33 ` [PATCH 2/3] dt-bindings: iio: proximity: Add Benewake TF-Luna Vidhu Sarwal via B4 Relay
2026-10-19 18:33   ` Vidhu Sarwal
2026-10-20  8:38   ` Krzysztof Kozlowski
2026-10-19 18:33 ` [PATCH 3/3] iio: proximity: Add Benewake TF-Luna LiDAR driver Vidhu Sarwal via B4 Relay
2026-10-19 18:33   ` Vidhu Sarwal
2026-10-20  7:23   ` Joshua Crofts
2026-10-20  7:42     ` Andy Shevchenko
2026-10-20  8:10   ` Andy Shevchenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=atch-NQ78VUdfgxW@ashevche-desk.local \
    --to=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=vidhu.linux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.