DT schemas for multi-transport bindings

DT schemas for multi-transport bindings

[Dmitry Torokhov]

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). 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)?

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?

Thanks.

-- 
Dmitry

Re: DT schemas for multi-transport bindings

[Rob Herring]

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.


> 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. Every SPI controller 
should reference spi-controller.yaml and that defines the bus structure 
and allowed SPI bus properties in child nodes.

If you did though, it would be '../spi/spi-controller.yaml'

Rob

Re: DT schemas for multi-transport bindings

[Dmitry Torokhov]

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]+$").

> Every SPI controller 
> should reference spi-controller.yaml and that defines the bus structure 
> and allowed SPI bus properties in child nodes.
> 
> If you did though, it would be '../spi/spi-controller.yaml'

OK, I'll try this out.

Thanks.

-- 
Dmitry

Re: DT schemas for multi-transport bindings

[Rob Herring]

On Wed, Oct 30, 2019 at 6:18 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> 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