On Thu, Sep 10, 2020 at 02:13:05PM -0500, Nishanth Menon wrote: > On 20:53-20200910, Krzysztof Kozlowski wrote: > > On Thu, 10 Sep 2020 at 20:28, Nishanth Menon <nm@xxxxxx> wrote: > > > > > > On 19:57-20200910, Krzysztof Kozlowski wrote: > > > [...] > > > > + wakeup-source: > > > > + $ref: /schemas/types.yaml#/definitions/flag > > > > + > > > > +patternProperties: > > > > + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": > > > > > > I wonder if "hog" is too generic and might clash with "something-hog" in > > > the future? > > > > This pattern is already used in > > Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml. It will > > match only children and so far it did not find any other nodes in ARM > > and ARM64 dts. I don't expect clashes. Also the question is then - if > > one adds a child of GPIO expander named "foobar-hog" and it is not a > > GPIO hog, then what is it? > > Probably a nitpick.. but then,.. I have'nt seen us depend on hierarchy > for uniqueness of naming.. we choose for example "bus" no matter where > in the hierarchy it falls in, as long it is a bus.. etc.. same argument > holds good for properties as well.. "gpio-hog;" is kinda redundant if > you think of it for a compatible that is already gpio ;).. > > I did'nt mean to de-rail the discussion, but was curious what the DT > maintainers think.. Not really a fan of gpio-hog binding to have another type of hog nor can I imagine what that would be. Rob