linux-kernel - Re: [PATCH v2 2/2] iio: magnetometer: si7210: add driver for Si7210

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <22cec5f4-5945-405a-b586-dcc9b1cef3aa@wanadoo.fr>
Date: Fri, 10 Jan 2025 17:12:33 +0100
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: apokusinski01@...il.com
Cc: andrej.skvortzov@...il.com, andy@...nel.org, conor+dt@...nel.org,
 danila@...xyga.com, devicetree@...r.kernel.org, icenowy@...c.io,
 javier.carrasco.cruz@...il.com, jic23@...nel.org,
 krzysztof.kozlowski@...aro.org, lars@...afoo.de, linux-iio@...r.kernel.org,
 linux-kernel@...r.kernel.org, megi@....cz, neil.armstrong@...aro.org,
 robh@...nel.org
Subject: Re: [PATCH v2 2/2] iio: magnetometer: si7210: add driver for Si7210

Le 09/01/2025 à 00:44, Antoni Pokusinski a écrit :
> Silicon Labs Si7210 is an I2C Hall effect magnetic position and
> temperature sensor. The driver supports the following functionalities:
> * reading the temperature measurements
> * reading the magnetic field measurements in a single-shot mode
> * choosing the magnetic field measurement scale (20 or 200 mT)

...

> diff --git a/drivers/iio/magnetometer/Makefile b/drivers/iio/magnetometer/Makefile
> index 3e4c2ecd9adf..58f32a855494 100644
> --- a/drivers/iio/magnetometer/Makefile
> +++ b/drivers/iio/magnetometer/Makefile
> @@ -31,6 +31,8 @@ obj-$(CONFIG_SENSORS_RM3100)		+= rm3100-core.o
>   obj-$(CONFIG_SENSORS_RM3100_I2C)	+= rm3100-i2c.o
>   obj-$(CONFIG_SENSORS_RM3100_SPI)	+= rm3100-spi.o
>   
> +obj-$(CONFIG_SI7210) += si7210.o

Maybe add some tabs, to align?

> +
>   obj-$(CONFIG_TI_TMAG5273)		+= tmag5273.o
>   
>   obj-$(CONFIG_YAMAHA_YAS530)		+= yamaha-yas530.o

...

> +static int si7210_read_raw(struct iio_dev *indio_dev,
> +			   struct iio_chan_spec const *chan,
> +			   int *val, int *val2, long mask)
> +{
> +	struct si7210_data *data = iio_priv(indio_dev);
> +	long long tmp;

I think that temp is better than tmp
(temperature vs temporary?)

> +	__be16 dspsig;
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		ret = si7210_fetch_measurement(data, chan, &dspsig);
> +		if (ret < 0)
> +			return ret;
> +
> +		*val = dspsig & GENMASK(14, 0);
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		*val = 0;
> +		if (data->curr_scale == 20)
> +			*val2 = 1250;
> +		else /* data->curr_scale == 200 */
> +			*val2 = 12500;
> +		return IIO_VAL_INT_PLUS_MICRO;
> +	case IIO_CHAN_INFO_OFFSET:
> +		*val = -16384;
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_PROCESSED:
> +		ret = si7210_fetch_measurement(data, chan, &dspsig);
> +		if (ret < 0)
> +			return ret;
> +
> +		tmp = FIELD_GET(GENMASK(14, 3), dspsig);
> +		tmp = (div_s64(-383 * tmp * tmp, 100) + (160940 * tmp - 279800000));

I would keep 279800000 outside of the (), or even write it to better 
match the spec:
	tmp = div_s64(-383 * tmp * tmp, 100) + 160940 * tmp - 279800000;

Here, tmp seems to be Temperature_raw from the sepc * 10^6


> +		tmp = (1 + (data->temp_gain >> 11)) * tmp + 62500 * data->temp_offset;

/ 2048 instead of >> 11 to match the formula in the sepc?

Would it be clearer to have 62500 written as (1000000 / 32)

> +
> +		ret = regulator_get_voltage(data->vdd);
> +		if (ret < 0)
> +			return ret;
> +
> +		tmp -= 222 * div_s64(ret, 1000);
> +
> +		*val = div_s64(tmp, 1000);
> +
> +		return IIO_VAL_INT;
> +	default:
> +		return -EINVAL;
> +	}
> +}
> +
> +static int si7210_set_scale(struct si7210_data *data, unsigned int scale)
> +{
> +	s8 *a_otp_values;
> +	int ret;
> +
> +	if (scale == 20)
> +		a_otp_values = data->scale_20_a;
> +	else if (scale == 200)
> +		a_otp_values = data->scale_200_a;
> +	else
> +		return -EINVAL;
> +
> +	guard(mutex)(&data->fetch_lock);
> +
> +	/* Write the registers 0xCA - 0xCC*/

Missing space before */

> +	ret = regmap_bulk_write(data->regmap, SI7210_REG_A0, a_otp_values, 3);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Write the registers 0xCE - 0xD0*/

Missing space before */

> +	ret = regmap_bulk_write(data->regmap, SI7210_REG_A3, &a_otp_values[3], 3);
> +	if (ret < 0)
> +		return ret;
> +
> +	data->curr_scale = scale;
> +
> +	return 0;
> +}

...

> +static int si7210_device_wake(struct si7210_data *data)
> +{
> +	/*
> +	 * According to the datasheet, the primary method to wake up a
> +	 * device is to send an empty write. However this is not feasible
> +	 * using current API so we use the other method i.e. read a single
> +	 * byte. The device should respond with 0xFF

Nitpick: Missing ending .

> +	 */
> +
> +	int ret = 0;

No need to init.

> +
> +	ret = i2c_smbus_read_byte(data->client);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (ret != 0xFF)
> +		return -EIO;
> +
> +	return 0;
> +}

...

> +MODULE_DESCRIPTION("Silicon Labs Si7210 Hall Effect sensor I2C driver");
> +MODULE_LICENSE("Dual BSD/GPL");

This is not consistent with the SPDX tag.

CJ