Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux