On Wed, Apr 03, 2019 at 03:33:42AM -0500, Rob Herring wrote: > > 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?) I thought about something along those lines too, since indeed the only thing that causes troube is required. > The complication would be we'd need 2 sets of schemas and select the > right one for each node. You mean two instances of the schema in the tool, right? Not two schema files? Do you expect any drawback to that (like performance-wise maybe, if we have more schemas with more complicated select patterns)? > Another way to implement it would be just to filter out the warning > messages. That would work too I guess :) Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
