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>;
> > > >     
> > >   
> >