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, 15 Jul 2023 11:28:03 +0100
From:   Conor Dooley <conor@kernel.org>
To:     marius.cristea@microchip.com
Cc:     jic23@kernel.org, lars@metafoo.de, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
        linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: iio: adc: adding MCP3564 ADC
Message-ID: <20230715-violate-suburb-ba9ae0a46674@spud>
References: <20230714150051.637952-1-marius.cristea@microchip.com>
 <20230714150051.637952-2-marius.cristea@microchip.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="Oh3cr62XzJVDrboW"
Content-Disposition: inline
In-Reply-To: <20230714150051.637952-2-marius.cristea@microchip.com>
Precedence: bulk


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

Hey,

On Fri, Jul 14, 2023 at 06:00:50PM +0300, marius.cristea@microchip.com wrot=
e:
> From: Marius Cristea <marius.cristea@microchip.com>
>=20
> This is the device tree schema for iio driver for
> Microchip family of 153.6 ksps, Low-Noise 16/24-Bit
> Delta-Sigma ADCs with an SPI interface (Microchip's
> MCP3461, MCP3462, MCP3464, MCP3461R, MCP3462R,
> MCP3464R, MCP3561, MCP3562, MCP3564, MCP3561R,
> MCP3562R and MCP3564R analog to digital converters).
>=20
> Signed-off-by: Marius Cristea <marius.cristea@microchip.com>

This looks good to me, other than the custom property, for which I can't
tell if a consensus was reached on last time around.

> +  microchip,hw-device-address:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    minimum: 0
> +    maximum: 3
> +    description:
> +      The address is set on a per-device basis by fuses in the factory,
> +      configured on request. If not requested, the fuses are set for 0x1.
> +      The device address is part of the device markings to avoid
> +      potential confusion. This address is coded on two bits, so four po=
ssible
> +      addresses are available when multiple devices are present on the s=
ame
> +      SPI bus with only one Chip Select line for all devices.
> +      Each device communication starts by a CS falling edge, followed by=
 the
> +      clocking of the device address (BITS[7:6] - top two bits of COMMAN=
D BYTE
> +      which is first one on the wire).

On the last version, the last comment I could find on lore was
https://lore.kernel.org/all/20230609184149.00002766@Huawei.com/
where Jonathan and Rob were discussing whether or not a spi-mux type of
thing could work, but it does not seem to have ended conclusively.

Rob or Jonathan, would you mind commenting on that?

There was also a comment from Jonathan:
> > +  vref-supply:
> > +    description:
> > +      Some devices have a specific reference voltage supplied on a dif=
ferent
> > +      pin to the other supplies. Needed to be able to establish channe=
l scaling
> > +      unless there is also an internal reference available (e.g. mcp35=
64r)
> > +
>=20
> From a quick glance at a random datasheet, looks like there additional po=
wer supplies
> that should be required.
>=20
> If this is required for some devices, I'd expect to see the binding enfor=
ce
> that with some required entries conditioned on the compatibles rather tha=
n as
> documentation. If there are devices where it isn't even optional then the=
 binding
> should enforce that as well.

The binding does now enforce the vref supply where relevant, but it
sounds like you were looking more supplies to be documented Jonathan?
(AVdd, DVdd etc)

Thanks,
Conor.

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

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

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZLJ0rwAKCRB4tDGHoIJi
0isjAQD8UKTFLjhVVZNOKG3SxHZ2MSbjJTicurz/lGEhX0YZ+AEAyRtXyPVr+4oN
UAukwJ6YwGk8zpf7ck0aQps5Y++sfwc=
=BpcV
-----END PGP SIGNATURE-----

--Oh3cr62XzJVDrboW--