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
