Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 1 Apr 2023 10:06:38 -0400
From:   William Breathitt Gray <william.gray@linaro.org>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Jonathan Cameron <jic23@kernel.org>
Cc:     Lars-Peter Clausen <lars@metafoo.de>, linux-iio@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] iio: addac: stx104: Migrate to the regmap API
Message-ID: <ZCg6bhkxGKmkMloM@fedora>
References: <cover.1679867815.git.william.gray@linaro.org>
 <4ebc1b6b609a086846420954b893e914fd395384.1679867815.git.william.gray@linaro.org>
 <ZCGBIAvr7OQLwNXv@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="/yW4sqb6LeVhtg6s"
Content-Disposition: inline
In-Reply-To: <ZCGBIAvr7OQLwNXv@smile.fi.intel.com>
Precedence: bulk


--/yW4sqb6LeVhtg6s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 27, 2023 at 02:42:24PM +0300, Andy Shevchenko wrote:
> On Sun, Mar 26, 2023 at 06:05:57PM -0400, William Breathitt Gray wrote:
> > The regmap API supports IO port accessors so we can take advantage of
> > regmap abstractions rather than handling access to the device registers
> > directly in the driver.
>=20
> ...
>=20
> > +static const struct regmap_config aio_ctl_regmap_config =3D {
> > +	.name =3D "aio_ctl",
> > +	.reg_bits =3D 8,
> > +	.reg_stride =3D 1,
> > +	.reg_base =3D STX104_AIO_BASE,
> > +	.val_bits =3D 8,
> > +	.io_port =3D true,
> > +	.max_register =3D 0x11,
>=20
> Not sure if define would be better for this, so it will be grouped with
> register offset definitions. (Same for the other configs)

Actually, I'll remove this max_register line because it's superfluous
when we define both rd_table and wr_table.

However, I explain my reasoning for hardcoding the max_register value in
a response to the ebc-c384_wdt watchdog driver conversion [0]. To
summarize, it's not immediately obvious whether a FOO_REGISTER comes
before or after a BAR_REGISTER so someone reading the code would need to
verify the define; there are cases as well, such as GPIO drivers, where
the only the base register is defined but the max register would be an
extent from there; and finally, a reviewer would ultimately need to
check against the datasheet to verify that the max_register is actually
at the named defined register location, whereas it is far easier to
lookup the address range in the datasheet rather than named registers.
These things make hardcoding max_register to be not only clearer code to
read and verify but also less likely to be set to the wrong address.

[0] https://lore.kernel.org/all/ZAyY3VGlo4N4SLZQ@fedora/

> > +	.wr_table =3D &aio_ctl_wr_table,
> > +	.rd_table =3D &aio_ctl_rd_table,
> > +	.volatile_table =3D &aio_ctl_volatile_table,
> > +	.cache_type =3D REGCACHE_FLAT,
> > +};
>=20
> Do we need regmap lock?

I think the regmap lock is opt-out, so I don't think we need to set an
custom lock callback for the regmaps in this driver.

Jonathan, do read_raw() and write_raw() require explicit locking?

> > +		err =3D regmap_read(priv->aio_ctl_map, STX104_ADC_CONFIGURATION, &ad=
c_config);
> > +		if (err)
> > +			return err;
> > =20
> > -		*val =3D 1 << gain;
> > +		*val =3D 1 << u8_get_bits(adc_config, STX104_GAIN);
>=20
> Maybe not for this change, but why not BIT()?

This probably should have been BIT(gain) when it was originally
introduced. I'm avoiding it here just to keep this migration patch more
straight-forward to review; but perhaps I'll make this change afterall
in a v4 submission.

> >  	case IIO_CHAN_INFO_RAW:
> >  		if (chan->output) {
>=20
> You can decrease indentation by
>=20
> 		if (!chan->output)
> 			return -EINVAL;
>=20
> here.

Sure I can make this change as well in a v4.

William Breathitt Gray

--/yW4sqb6LeVhtg6s
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSNN83d4NIlKPjon7a1SFbKvhIjKwUCZCg6bgAKCRC1SFbKvhIj
K9ZyAQDUzIF5/JKTWriFyF4UIAK/m3LufltaEhYoY2e9UMm7HAEAjjbhh8T6QNrn
xZDGS5LJrKuhlUrkheaVBPHtp8N1sAs=
=814R
-----END PGP SIGNATURE-----

--/yW4sqb6LeVhtg6s--