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 :) 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. 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. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
