17.06.2020 17:17, Thierry Reding пишет: > On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote: >> 12.06.2020 17:18, Thierry Reding пишет: >> ... >>> +patternProperties: >>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match >>> + "^gpios(-[a-zA-Z0-9-]+)?$": >>> + type: object >>> + required: >>> + - gpio-hog >> >> There are two problems here: >> >> 1. This naming limitation didn't exist before this patch, so it's not a >> part of the conversion. >> >> 2. GPIO core uses the node's name for the hog's name. Hence by imposing >> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx, >> which doesn't make much sense to me. >> >> Please explain the rationale of this change. > > We could probably do without this if we didn't enforce additional or > unevaluated properties. Because if we don't match on a pattern here then > all of those GPIO hog nodes would show up as "extra" properties and they > are currently not allowed. If we do allow them, then we can drop this, > but we then have no way to fail validation for whatever else somebody > might want to put into these device tree nodes. > > That said, I think additionalProperties can be a schema in itself, so > maybe there's a way to only allow additional properties if they are of > type object and have a gpio-hog property. I'll look into that. Isn't it possible to validate the additional properties by checking what properties they have? For example, if sub-node has a gpio-hog property then this sub-node is okay, otherwise fail.
