Re: DT schemas for multi-transport bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 30, 2019 at 6:18 PM Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> wrote:
>
> On Wed, Oct 30, 2019 at 08:19:36AM -0500, Rob Herring wrote:
> > On Fri, Oct 25, 2019 at 01:43:33PM -0700, Dmitry Torokhov wrote:
> > > Hi Rob,
> > >
> > > I am trying to wrap my mind around converting multi-transport bindings
> > > (let's say TSC2004/5 controller which is pretty much the same part, but
> > > one is I2C while another is SPI interface). There is a set of common
> > > properties, and then we can have transport-specific ones (for example,
> > > spi-max-frequency for SPI case).
> >
> > I'm pretty sure we already have some examples of this.
> >
> > You could have 3 files with common props, i2c props, and spi props, but
> > that's probably an overkill. I'd just list all the possible properties
> > in one file and then they can be made conditional as needed.
> >
> > For bus properties you really only need to list them if required or you
> > have additional constraints.
> >
> > > Is it possible to annotate that some
> > > properties are only needed for certain compatible, similarly to how
> > > patternProperties work (but instead of matching node name we'd match on
> > > compatible)?
> >
> > Yes, with if/then schema. There's numerous examples of this. It's a
> > little more verbose than I'd like, but that's because generally each
> > property schema is independent.
>
> Ah, I see, I think that's what I've been looking for.
>
> >
> >
> > > Also, from syntax POV, how do I reference file ooutside of current
> > > directory? I.e. how do I reference .../spi/spi-controller.yaml from
> > > .../input/touchscreen/tsc2005.yaml?
> >
> > You don't. TSC2005 is not a SPI controller/master.
>
> Right, but spi-controller.yaml contains not only properties for SPI
> controllers, but also for the device (behind patternProperties: on
> "^.*@[0-9a-f]+$").

Right, so there's no need for devices to define those properties again
as they get checked by the parent/bus schema already.

I guess what you are looking for something defining a device is SPI,
I2C, etc. There's nothing for that. I've thought about doing something
like a $bus or $parent property to define what a binding should be a
child of. The problem is how do you match the parent. It's not
consistent. Sometimes we can use the parent node name, but that's not
always followed or for i2c there can be muxes in the middle.

Rob



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux