On Wed, Apr 3, 2019 at 2:44 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > On Tue, Apr 02, 2019 at 08:25:59PM -0500, Rob Herring wrote: > > On Tue, Apr 2, 2019 at 9:54 AM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > > > > > Switch the DT binding to a YAML schema to enable the DT validation. > > > > > > Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxx> > > > > > > --- > > > > > > Changes from v1 > > > - Added controller constraints to the generic options > > > --- > > > Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml | 96 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > > > Documentation/devicetree/bindings/mtd/sunxi-nand.txt | 48 +------------------------------------ > > > 2 files changed, 96 insertions(+), 48 deletions(-) > > > create mode 100644 Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml > > > delete mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt > > > > Same 'a-f' comment here, but otherwise, > > > > Reviewed-by: Rob Herring <robh@xxxxxxxxxx> > > > > And thanks for being an early adopter. Let me know if you have any > > feedback on the schema or pain points. > > My main feedback is that it's awesome :) Thanks. > We (sunxi) have an awful lot of DT in the tree, and I made schemas for > most of the bindings we have now. It allowed us to find a huge (or at > least way more than what I was expecting) number of issues in our DTs, > like inconsistent node naming, typos, etc., and also that our bindings > were not updated as they should have. > > The following patches are a direct result from that, and I expect to > find more. > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/640978.html > > On the pain point side, I guess the main one is that most of the time > it's not really clear to me how I should express a particular set of > constraints. You've been really helpful to deal with that one, and I > guess it also stems from the fact that there's not a lot of examples > in the tree right now. I expect it to go away the more schemas we > have. Yes, there is a bit of a learning curve to json-schema if you have to do anything out of the ordinary. The meta-schema is supposed to help constrain things, but it's only as good as what we define there. That also mainly works for already known property names and patterns we've thought of. > The other one that might be more problematic is that it also tries to > validate nodes that are not enabled. For in-SoC components that don't > rely on anything external, it's fine, however, for components that > would require something that is connected on the board (like a > regulator, a phy, a GPIO, whatever), then we can't have all the > required resources in the DTSI, and boards that don't use that > component (and keep it disabled) will emit warning that this > particular property is missing. > > I've tried to look into it but couldn't find an easy fix for that in > the tooling, so I've opened a github issue for this. Let me know if > it's not appropriate. Yeah, I need to go look at that. Skipping disabled nodes shouldn't be too hard to do within the tool. This came up before I think and I've resisted because I don't want to skip validating at least what is there. Maybe the better solution would be to drop 'required' from schema when validating disabled nodes. (At least, I think just 'required' is the problem?) The complication would be we'd need 2 sets of schemas and select the right one for each node. Another way to implement it would be just to filter out the warning messages. Rob
