17.06.2020 17:24, Dmitry Osipenko пишет: > 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. > Ah, I haven't finished reading yours last sentence before started to type :) Yes, it will be nice if we could avoid the naming limitation, or at least change it to something like xxx-hog.
