[PATCH v1 02/36] dt-bindings: spi: support non-spi bindings as SPI slaves

[Sam Ravnborg]

Hi Mark.

On Mon, Mar 16, 2020 at 04:35:38PM +0000, Mark Brown wrote:
> On Mon, Mar 16, 2020 at 02:28:44PM +0100, Sam Ravnborg wrote:
> > On Mon, Mar 16, 2020 at 12:02:41PM +0000, Mark Brown wrote:
> > > On Sun, Mar 15, 2020 at 02:43:42PM +0100, Sam Ravnborg wrote:
> 
> > > > Independent bindings can be SPI slaves which for example is
> > > > the case for several panel bindings.
> 
> > > What is an "independent binding"?
> 
> > For several panels we have device trees that looks like this:
> 
> So what you're trying to do is define a generic class for SPI slaves
> which are just normal children of SPI nodes?  I really can't get to
> there from your changelog so we need some work there - in particular
> "non-spi bindings" is *very* confusing as as far as I can see these are
> bindings for SPI devices.
> 
> > The bindings are child of the spi controller node, but not specified
> > in the same binding file as the spi controller node.
> 
> Of course not, this how all buses work isn't it?
> 
> > So SPI slaves can now reference spi-slave.yaml to get access to
> > the SPI slave properties - and the copies can be avoided.
> > Likewise spi-controller.yml now references spi-slave.yaml.
> 
> > This was the best way I saw it could be done.
> 
> Rob didn't do the binding conversion but he did review it - I'm a bit
> surprised that there's issues here?

For panels we have panel-common.yaml that list all the
typical properties used by a panel - so the individual
panel bindings shall not repeat them.
This is also aligned with the principle of re-using properties rather
than inventing new properties all over.

And with a number of bindings describing HW that is SPI slaves
the idea is to do something like we do for panels.

I look forward for Rob's feedback - but as he is on vacation this week
we may have to wait a week for that.

The simple way forward had been to do like we do in many other places
and include a few SPI properties and be done with it.
This is an attempt to do something better.
If there is push-back or a nack, then we can always do like we do in
other places and just duplicate the properties.

> Also shouldn't there be some constraint that these devices have to be
> the child of a SPI controller or something?  Just including a file
> doesn't look right for something like class definition.

It was the best I could come up with - and this patch was called out
for review in the hope there is a better way than this patch.

We have similar examples like:
  - pincfg-node.yaml
  - regulatro.yaml
  - dma-common.yaml

They are not exactly 1:1 to what we do with spi-slave.yaml, but they
served as inspiration.

	Sam