linux-kernel - Re: [PATCH v2 2/3] iio: adc: Add driver for Marvell 88PM886 PMIC ADC

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: <3031049.e9J7NaK4W3@radijator>
Date: Mon, 01 Sep 2025 18:51:19 +0200
From: Duje Mihanović <duje@...emihanovic.xyz>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
 David Lechner <dlechner@...libre.com>,
 Nuno Sá <nuno.sa@...log.com>,
 Andy Shevchenko <andy@...nel.org>, Karel Balej <balejk@...fyz.cz>,
 Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 David Wronek <david@...nlining.org>, phone-devel@...r.kernel.org,
 ~postmarketos/upstreaming@...ts.sr.ht, linux-kernel@...r.kernel.org,
 linux-iio@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 2/3] iio: adc: Add driver for Marvell 88PM886 PMIC ADC

On Monday, 1 September 2025 17:35:23 Central European Summer Time Andy Shevchenko wrote:
> On Sun, Aug 31, 2025 at 12:33:05PM +0200, Duje Mihanović wrote:
> > +static const struct regmap_config pm886_gpadc_regmap_config = {
> > +	.reg_bits = 8,
> > +	.val_bits = 8,
> > +	.max_register = PM886_REG_GPADC_VBAT_SLP + 1,
> 
> What is this + 1 register? Why is it not defined / documented?

It is the second field of the vbat_slp channel.

> > +static int
> > +gpadc_get_resistance_ohm(struct iio_dev *iio, struct iio_chan_spec const
> > *chan) +{
> > +	struct pm886_gpadc *gpadc = iio_priv(iio);
> > +	unsigned int raw_uv, raw_ua;
> > +	int ret;
> > +
> > +	ret = gpadc_set_bias(gpadc, chan->channel, true);
> > +	if (ret)
> > +		goto err;
> > +
> > +	ret = gpadc_find_bias_current(iio, chan, &raw_uv, &raw_ua);
> > +	if (ret)
> > +		goto err;
> > +
> > +	ret = gpadc_set_bias(gpadc, chan->channel, false);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return DIV_ROUND_CLOSEST(raw_uv, raw_ua);
> > +err:
> > +	gpadc_set_bias(gpadc, chan->channel, false);
> 
> You do the same in the other branch and checking there for an error. Why this
> one is so special?

My rationale here was to not override the error from either the first
gpadc_set_bias() call or the subsequent gpadc_find_bias_current() call.

> > +		dev_dbg(&iio->dev, "chan: %d, raw: %d\n", chan->channel, *val);
> 
> How is this useful? The userspace gets the same value. Do you expect problems
> on its way to the user space?

That's a leftover from debugging v1, will drop.

> > +	iio->dev.of_node = dev->parent->of_node;
> 
> No, use device_set_node() with the respective parameters.
> 
> But rather debug why firmware node (or OF in your case) is not propagated from
> the parent device.

I guess it is because the IIO device is registered as a child of the
GPADC platform device, which does not have a node unlike the PMIC
device (GPADC pdev's parent). It seems that the regulator cell
registers its regulators directly under the PMIC dev, so maybe I should
do the same here with the IIO dev?

Regards,
--
Duje