From: Rob Herring <robh@kernel.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Conor Dooley <conor@kernel.org>,
marius.cristea@microchip.com, lars@metafoo.de,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: iio: adc: adding MCP3564 ADC
Date: Thu, 8 Jun 2023 13:34:43 -0600 [thread overview]
Message-ID: <20230608193443.GA3261675-robh@kernel.org> (raw)
In-Reply-To: <20230520161753.28a8c128@jic23-huawei>
On Sat, May 20, 2023 at 04:17:53PM +0100, Jonathan Cameron wrote:
> On Fri, 19 May 2023 19:29:15 +0100
> Conor Dooley <conor@kernel.org> wrote:
>
> > Hey Marius,
> >
> > On Fri, May 19, 2023 at 07:01:44PM +0300, marius.cristea@microchip.com wrote:
> > > From: Marius Cristea <marius.cristea@microchip.com>
> > >
> > > 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.
> >
> > Just one quick process bit, please try to CC all of the maintainers
> > listed by get_maintainer.pl - you unfortunately managed to miss 2 of the
> > 3 dt-binding maintainers :/ Perhaps you ran get_maintainer.pl using our
> > vendor tree?
> >
> > > Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
> > > ---
> >
> > > + vref-supply:
> > > + description:
> > > + Some devices have a specific reference voltage supplied on a different
> > > + pin to the other supplies. Needed to be able to establish channel scaling
> > > + unless there is also an internal reference available (e.g. mcp3564r)
> >
> > Should this be marked as a required property for the non-r devices that
> > do not have an internal reference?
> >
> > > + microchip,hw-device-address:
> >
> > Hopefully Rob or Jonathan etc can chime in as to whether a common
> > property exists for this type of thing...
> >
> Nope. This is a new one for me - there are devices that work on a daisy chain
> principle but I think this one works by encoding stuff in the actual message
> which is unusual for SPI.
Not something I've seen either.
>
> > > + $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 possible
> > > + addresses are available when multiple devices are present on the same
> > > + SPI bus with only one Chip Select line for all devices.
What's this going to look like with more than one device? It would need
to be incorporated into 'reg' and the unit-address to work. Something
like this is
spi {
device0@0 {
reg = <0>;
microchip,hw-device-address = <0>;
};
device1@0 {
reg = <0>;
microchip,hw-device-address = <1>;
};
};
That should throw warnings because you have 2 nodes at the same address
which is not good practice.
I think you need a spi mux in here with the mux addresses being the
microchip,hw-device-address values.
Rob
next prev parent reply other threads:[~2023-06-08 19:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-19 16:01 [PATCH 0/2] Adding support for Microchip MCP3564 ADC family marius.cristea
2023-05-19 16:01 ` [PATCH 1/2] dt-bindings: iio: adc: adding MCP3564 ADC marius.cristea
2023-05-19 18:29 ` Conor Dooley
2023-05-20 15:17 ` Jonathan Cameron
2023-06-08 19:34 ` Rob Herring [this message]
2023-06-09 17:41 ` Jonathan Cameron
2023-05-20 13:20 ` Jonathan Cameron
2023-05-24 10:37 ` Mike Looijmans
2023-05-28 19:16 ` Jonathan Cameron
2023-05-19 16:01 ` [PATCH 2/2] iio: adc: adding support for " marius.cristea
2023-05-20 15:15 ` Jonathan Cameron
2023-06-22 11:32 ` Marius.Cristea
2023-07-02 10:28 ` Jonathan Cameron
2023-05-24 11:05 ` Mike Looijmans
2023-05-28 19:20 ` Jonathan Cameron
2023-06-20 14:34 ` Mike Looijmans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230608193443.GA3261675-robh@kernel.org \
--to=robh@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marius.cristea@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).