Re: [PATCH v7 2/7] dt-bindings: iio: adc: microchip,mcp3564: Add spi-device-addr

Jonathan Cameron <[email protected]>
Newsgroups org.kernel.vger.linux-iio,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-spi
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>;
> > > >     
> > >   
> >
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.