linux-kernel - Re: [PATCH v2 07/14] iio: accel: bma220: reset registers during init stage

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: <20250910190154.0c5ab461@jic23-huawei>
Date: Wed, 10 Sep 2025 19:01:54 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Petre Rodan <petre.rodan@...dimension.ro>
Cc: David Lechner <dlechner@...libre.com>, Nuno Sá
 <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 07/14] iio: accel: bma220: reset registers during
 init stage

On Wed, 10 Sep 2025 10:57:12 +0300
Petre Rodan <petre.rodan@...dimension.ro> wrote:

> Bring all configuration registers to default values during device probe().
> 
> Signed-off-by: Petre Rodan <petre.rodan@...dimension.ro>

Hi Petre

One comment on code you happened to be moving.  The patch itself looks good
to me so this is a 'whilst we are here' type comment, though should be addressed
in a separate patch.

thanks,

Jonathan

> +static int bma220_init(struct spi_device *spi)
> +{
> +	int ret;
> +	static const char * const regulator_names[] = { "vddd", "vddio", "vdda" };
> +
> +	ret = devm_regulator_bulk_get_enable(&spi->dev,
> +					     ARRAY_SIZE(regulator_names),
> +					     regulator_names);
> +	if (ret)
> +		return dev_err_probe(&spi->dev, ret, "Failed to get regulators\n");
> +
> +	ret = bma220_read_reg(spi, BMA220_REG_ID);
> +	if (ret != BMA220_CHIP_ID)
> +		return -ENODEV;

Not relevant to this patch as such, but we should relax this constraint so that
fallback compatibles work in device tree.  Convention is to just print a
dev_info() message if we get a wrong ID and carry on.

> +
> +	/* Make sure the chip is powered on and config registers are reset */
> +	ret = bma220_power(spi, true);
> +	if (ret)
> +		return dev_err_probe(&spi->dev, ret, "Failed to power-on chip\n");
> +
> +	ret = bma220_reset(spi, true);
> +	if (ret)
> +		return dev_err_probe(&spi->dev, ret, "Failed to soft reset chip\n");
> +
> +	return 0;
> +}