Re: [PATCH v7 2/7] dt-bindings: iio: adc: microchip,mcp3564: Add spi-device-addr
Jonathan Cameron <[email protected]> Tue, 28 Jul 2026 22:17:19 +0100
| Newsgroups | org.kernel.vger.linux-spi,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-doc,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260728221719.7f668a73@jic23-huawei> |
On Tue, 28 Jul 2026 17:00:55 +0100 Conor Dooley <[email protected]> wrote: > On Sat, Jul 25, 2026 at 11:07:39PM +0100, Jonathan Cameron wrote: > > On Sat, 25 Jul 2026 15:57:07 -0500 > > David Lechner <[email protected]> wrote: > > > > > On 7/22/26 2:54 AM, Janani Sunil wrote: > > > > Add the generic spi-device-addr property to the binding and deprecate > > > > the existing vendor specific microchip,hw-device-address property. > > > > > > > > Signed-off-by: Janani Sunil <[email protected]> > > > > --- > > > > .../devicetree/bindings/iio/adc/microchip,mcp3564.yaml | 10 ++++++++-- > > > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml > > > > index 675319276197..de1ea289e7f5 100644 > > > > --- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml > > > > +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml > > > > @@ -80,6 +80,7 @@ properties: > > > > $ref: /schemas/types.yaml#/definitions/uint32 > > > > minimum: 0 > > > > maximum: 3 > > > > + deprecated: true > > > > 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. > > > > @@ -91,6 +92,12 @@ properties: > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE > > > > which is first one on the wire). > > > > > > > > + spi-device-addr: > > > > + maxItems: 1 > > > > > > Does it not make sense to all for more than once device connected > > > to the same CS here? I would expect maxItems to be 4 to match the > > > number of possible addresses. > > > > > > > I think for this part their isn't a reason to aggregate. > > No magic accesses that touch them all at once. So this hits > > exactly the point you raised about how we set the address for > > more than one of them. > > No David is actually right here, and maxitems should be 4. > Setting the address for multiple was already discussed I thought, with > the property being an array and each compatible being used to determine > the "stride" between entries based on the number of supported channels? I don't think that applies for this device or at least to do so is a major driver rewrite, not a simple binding change. Probably we'd just add a bus and hang the 4 instances off it. They are running on own timing etc so we can't grab data across all of them in any sort of synchronous way - the clocks will probably drift over time etc. They are independent devices (think of them using spi-device-address like an i2c address) - so why have one DT node for up to 4 of them? Note this is different from the AD5529R where the design is intended for them to operate as one single larger device. Jonathan > > > > > Jonathan > > > > > > + items: > > > > + enum: [0, 1, 2, 3] > > > > + default: [1] > > > > + > > > > "#io-channel-cells": > > > > const: 1 > > > > > > > > @@ -123,7 +130,6 @@ dependencies: > > > > required: > > > > - compatible > > > > - reg > > > > - - microchip,hw-device-address > > > > - spi-max-frequency > > > > > > > > allOf: > > > > @@ -159,7 +165,7 @@ examples: > > > > spi-cpha; > > > > spi-cpol; > > > > spi-max-frequency = <10000000>; > > > > - microchip,hw-device-address = <1>; > > > > + spi-device-addr = <1>; > > > > > > > > #address-cells = <1>; > > > > #size-cells = <0>; > > > > > > > > >