Re: DT schemas for multi-transport bindings

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

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