[PATCH v2 01/15] dt-bindings: gpio: convert bindings for NXP PCA953x family to dtschema
krzk at kernel.org
Fri Sep 11 16:54:40 AEST 2020
On Fri, 11 Sep 2020 at 08:42, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> Hi Krzysztof,
> On Thu, Sep 10, 2020 at 8:54 PM Krzysztof Kozlowski <krzk at kernel.org> wrote:
> > On Thu, 10 Sep 2020 at 20:28, Nishanth Menon <nm at ti.com> 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?
> Perhaps you didn't find any other nodes as children of pca953x
There shouldn't be.. unless one makes some i2c-gpio controller under
such GPIO expander. But now it wouldn't be instantiated as expander is
not a bus.
> There are other hog nodes in other types of GPIO controllers. Typically
> they're named after the purpose, e.g. "wifi-disable", "i2c3_mux_oe_n",
> "pcie_sata_switch", "lcd0_mux".
> IMHO it's a hog if it contains a "gpio-hog" property, regardless of node
Yes. The question is then whether to expect the "hog" in name. Just
like we expect for all other device nodes to represent the class.
More information about the Linux-aspeed