| Message ID | 20200910175733.11046-2-krzk@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | ARM: dts: / gpio: Add dtschema for NXP PCA953x and correct dts | expand |
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?
On Thu, 10 Sep 2020 at 20:28, Nishanth Menon <nm@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? Best regards, Krzysztof
On 20:53-20200910, Krzysztof Kozlowski wrote: > On Thu, 10 Sep 2020 at 20:28, Nishanth Menon <nm@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? 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..
On Thu, 10 Sep 2020 at 17:57, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > Convert the NXP PCA953x family of GPIO expanders bindings to device tree > schema. > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> > +patternProperties: > + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": > + type: object > + properties: > + gpio-hog: true > + gpios: true > + input: true > + output-high: true > + output-low: true > + line-name: true > + > + required: > + - gpio-hog > + - gpios > + > + usb3-sata-sel-hog { > + gpio-hog; > + gpios = <4 GPIO_ACTIVE_HIGH>; > + output-low; > + line-name = "usb3_sata_sel"; I would prefer we didn't require the addition of hte -hog prefix. It's mostly just a matter of taste, but I can think of a few more concrete reasons: We don't require -high or -low prefixes, so the node name doesn't need to describe the properties that will be found below. Changing around node names for existing boards carries with it the chance of userspace breakage (as sysfs paths change). I would prefer we avoid that if possible. Cheers, Joel
Hi Krzysztof, On Thu, Sep 10, 2020 at 8:54 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > On Thu, 10 Sep 2020 at 20:28, Nishanth Menon <nm@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 controllers? 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 naming. Gr{oetje,eeting}s, Geert
On Fri, 11 Sep 2020 at 08:24, Joel Stanley <joel@jms.id.au> wrote: > > On Thu, 10 Sep 2020 at 17:57, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > Convert the NXP PCA953x family of GPIO expanders bindings to device tree > > schema. > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> > > > +patternProperties: > > + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": > > + type: object > > + properties: > > + gpio-hog: true > > + gpios: true > > + input: true > > + output-high: true > > + output-low: true > > + line-name: true > > + > > + required: > > + - gpio-hog > > + - gpios > > + > > > + usb3-sata-sel-hog { > > + gpio-hog; > > + gpios = <4 GPIO_ACTIVE_HIGH>; > > + output-low; > > + line-name = "usb3_sata_sel"; > > I would prefer we didn't require the addition of hte -hog prefix. It's > mostly just a matter of taste, but I can think of a few more concrete > reasons: > > We don't require -high or -low prefixes, so the node name doesn't need > to describe the properties that will be found below. Thanks for the comments. It is not about properties (high or low) but the role of a device node. The node names should represent a generic class of device (ePAPR and device tree spec) and "hog" is such class. The Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml already uses such naming so the best would be to unify. > > Changing around node names for existing boards carries with it the > chance of userspace breakage (as sysfs paths change). I would prefer > we avoid that if possible. The impact on userspace is indeed important, but are you sure that hogs are visible to user-space via sysfs and configurable? I guess you think of deprecated CONFIG_GPIO_SYSFS? Rob, Any hints from you about hog-naming? Best regards, Krzysztof
On Fri, 11 Sep 2020 at 08:42, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Krzysztof, > > On Thu, Sep 10, 2020 at 8:54 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On Thu, 10 Sep 2020 at 20:28, Nishanth Menon <nm@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 > controllers? 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 > naming. 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. Best regards, Krzysztof
On 11/09/2020 09:52, Krzysztof Kozlowski wrote: > On Fri, 11 Sep 2020 at 08:24, Joel Stanley <joel@jms.id.au> wrote: >> >> On Thu, 10 Sep 2020 at 17:57, Krzysztof Kozlowski <krzk@kernel.org> wrote: >>> >>> Convert the NXP PCA953x family of GPIO expanders bindings to device tree >>> schema. >>> >>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> >> >>> +patternProperties: >>> + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": >>> + type: object >>> + properties: >>> + gpio-hog: true >>> + gpios: true >>> + input: true >>> + output-high: true >>> + output-low: true >>> + line-name: true >>> + >>> + required: >>> + - gpio-hog >>> + - gpios >>> + >> >>> + usb3-sata-sel-hog { >>> + gpio-hog; >>> + gpios = <4 GPIO_ACTIVE_HIGH>; >>> + output-low; >>> + line-name = "usb3_sata_sel"; >> >> I would prefer we didn't require the addition of hte -hog prefix. It's >> mostly just a matter of taste, but I can think of a few more concrete >> reasons: >> >> We don't require -high or -low prefixes, so the node name doesn't need >> to describe the properties that will be found below. > > Thanks for the comments. > > It is not about properties (high or low) but the role of a device > node. The node names should represent a generic class of device (ePAPR > and device tree spec) and "hog" is such class. > > The Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml already > uses such naming so the best would be to unify. In my opinion, It's not right to define this on per gpio-controller and introduce such per gpio-controller restrictions. More over, there is already generic schema for gpio hogs: gpio-hog.yaml Originally, gpio bindings were defined without restricting gpio hog node names and, generic schema follows this. I think, the generic "gpio-hogs" sub-node may be introduced to place gpio hogs child nodes, if gpio hogs node names restriction need to be introduces (*which i'm not sure is reasonable*). gpio@20 { gpio-hogs { yyy-hog { gpio-hog; gpios } } But this require as gpio code as generic gpio schema update (with backward compatibility in mind). > >> >> Changing around node names for existing boards carries with it the >> chance of userspace breakage (as sysfs paths change). I would prefer >> we avoid that if possible. > > The impact on userspace is indeed important, but are you sure that > hogs are visible to user-space via sysfs and configurable? I guess you > think of deprecated CONFIG_GPIO_SYSFS? > > Rob, > Any hints from you about hog-naming? > > Best regards, > Krzysztof >
On Fri, Sep 11, 2020 at 11:54 AM Grygorii Strashko <grygorii.strashko@ti.com> wrote: > More over, there is already generic schema for gpio hogs: gpio-hog.yaml Where is this? I don't have it in my GPIO devel branch for sure, and it is not in linux-next either so not in Bartosz' tree. I did suggest that I want a gpio-common.yaml file which includes the hogs. > Originally, gpio bindings were defined without restricting gpio hog node names and, > generic schema follows this. > > I think, the generic "gpio-hogs" sub-node may be introduced to place gpio hogs child nodes, > if gpio hogs node names restriction need to be introduces (*which i'm not sure is reasonable*). > > gpio@20 { > gpio-hogs { > yyy-hog { > gpio-hog; > gpios > } > } > > But this require as gpio code as generic gpio schema update (with backward compatibility in mind). The whole problem I have with the DT bindings is that defining them is not really a Linux problem and the people maintaining it even want to move it out of the Linux kernel tree. It is supposedly the responsibility of all operating systems using device tree including but not limited to BSD and Zephyr. But there is noone picking up the responsibility outside of the Linux kernel tree except for Rob and Rob cannot do everything. With things like this it breaks apart because noone takes the overall responsibility. And as subsystem maintainer I am fully overloaded with the Linux side of things. This is of course not your or anyone else's fault. But: GPIO DT binding maintainers/writers wanted! Yours, Linus Walleij
On 12/09/2020 13:07, Linus Walleij wrote: > On Fri, Sep 11, 2020 at 11:54 AM Grygorii Strashko > <grygorii.strashko@ti.com> wrote: > >> More over, there is already generic schema for gpio hogs: gpio-hog.yaml > > Where is this? I don't have it in my GPIO devel branch for sure, and > it is not in linux-next either so not in Bartosz' tree. > > I did suggest that I want a gpio-common.yaml file which includes the > hogs. There it is (am I missing smth?): pip3 install git+https://github.com/devicetree-org/dt-schema.git@master as per: https://www.kernel.org/doc/html/latest/devicetree/writing-schema.html
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@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? > > 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
On Sat, Sep 12, 2020 at 12:07:59PM +0200, Linus Walleij wrote: > On Fri, Sep 11, 2020 at 11:54 AM Grygorii Strashko > <grygorii.strashko@ti.com> wrote: > > > More over, there is already generic schema for gpio hogs: gpio-hog.yaml > > Where is this? I don't have it in my GPIO devel branch for sure, and > it is not in linux-next either so not in Bartosz' tree. https://github.com/devicetree-org/dt-schema/tree/master/schemas/gpio > > I did suggest that I want a gpio-common.yaml file which includes the > hogs. Already there, but not wired together ATM. > > Originally, gpio bindings were defined without restricting gpio hog node names and, > > generic schema follows this. Originally, almost all node names were a free-for-all even for classes defined 20 years ago. Now the names are getting enforced. Rob
On Thu, 10 Sep 2020 19:57:19 +0200, Krzysztof Kozlowski wrote: > Convert the NXP PCA953x family of GPIO expanders bindings to device tree > schema. > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> > > --- > > Changes since v1: > 1. Use additionalProperties. > 2. Add wakeup-source. > 3. Add hogs. > 4. Extend example with hogs. > --- > .../devicetree/bindings/gpio/gpio-pca953x.txt | 90 ---------- > .../bindings/gpio/gpio-pca95xx.yaml | 166 ++++++++++++++++++ > .../devicetree/bindings/trivial-devices.yaml | 4 - > 3 files changed, 166 insertions(+), 94 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml > Reviewed-by: Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt deleted file mode 100644 index 3126c3817e2a..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt +++ /dev/null @@ -1,90 +0,0 @@ -* NXP PCA953x I2C GPIO multiplexer - -Required properties: - - compatible: Has to contain one of the following: - nxp,pca6416 - nxp,pca9505 - nxp,pca9534 - nxp,pca9535 - nxp,pca9536 - nxp,pca9537 - nxp,pca9538 - nxp,pca9539 - nxp,pca9554 - nxp,pca9555 - nxp,pca9556 - nxp,pca9557 - nxp,pca9574 - nxp,pca9575 - nxp,pca9698 - nxp,pcal6416 - nxp,pcal6524 - nxp,pcal9535 - nxp,pcal9555a - maxim,max7310 - maxim,max7312 - maxim,max7313 - maxim,max7315 - ti,pca6107 - ti,pca9536 - ti,tca6408 - ti,tca6416 - ti,tca6424 - ti,tca9539 - ti,tca9554 - onnn,cat9554 - onnn,pca9654 - exar,xra1202 - - gpio-controller: if used as gpio expander. - - #gpio-cells: if used as gpio expander. - - interrupt-controller: if to be used as interrupt expander. - - #interrupt-cells: if to be used as interrupt expander. - -Optional properties: - - interrupts: interrupt specifier for the device's interrupt output. - - reset-gpios: GPIO specification for the RESET input. This is an - active low signal to the PCA953x. - - vcc-supply: power supply regulator. - -Example: - - - gpio@20 { - compatible = "nxp,pca9505"; - reg = <0x20>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_pca9505>; - gpio-controller; - #gpio-cells = <2>; - interrupt-parent = <&gpio3>; - interrupts = <23 IRQ_TYPE_LEVEL_LOW>; - }; - - -Example with Interrupts: - - - gpio99: gpio@22 { - compatible = "nxp,pcal6524"; - reg = <0x22>; - interrupt-parent = <&gpio6>; - interrupts = <1 IRQ_TYPE_EDGE_FALLING>; /* gpio6_161 */ - interrupt-controller; - #interrupt-cells = <2>; - vcc-supply = <&vdds_1v8_main>; - gpio-controller; - #gpio-cells = <2>; - gpio-line-names = - "hdmi-ct-hpd", "hdmi.ls-oe", "p02", "p03", "vibra", "fault2", "p06", "p07", - "en-usb", "en-host1", "en-host2", "chg-int", "p14", "p15", "mic-int", "en-modem", - "shdn-hs-amp", "chg-status+red", "green", "blue", "en-esata", "fault1", "p26", "p27"; - }; - - ts3a227@3b { - compatible = "ti,ts3a227e"; - reg = <0x3b>; - interrupt-parent = <&gpio99>; - interrupts = <14 IRQ_TYPE_EDGE_RISING>; - ti,micbias = <0>; /* 2.1V */ - }; - diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml new file mode 100644 index 000000000000..7ff6efadf797 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml @@ -0,0 +1,166 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-pca95xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCA95xx I2C GPIO multiplexer + +maintainers: + - Krzysztof Kozlowski <krzk@kernel.org> + +properties: + compatible: + enum: + - exar,xra1202 + - maxim,max7310 + - maxim,max7312 + - maxim,max7313 + - maxim,max7315 + - nxp,pca6416 + - nxp,pca9505 + - nxp,pca9534 + - nxp,pca9535 + - nxp,pca9536 + - nxp,pca9537 + - nxp,pca9538 + - nxp,pca9539 + - nxp,pca9554 + - nxp,pca9555 + - nxp,pca9556 + - nxp,pca9557 + - nxp,pca9574 + - nxp,pca9575 + - nxp,pca9698 + - nxp,pcal6416 + - nxp,pcal6524 + - nxp,pcal9535 + - nxp,pcal9555a + - onnn,cat9554 + - onnn,pca9654 + - ti,pca6107 + - ti,pca9536 + - ti,tca6408 + - ti,tca6416 + - ti,tca6424 + - ti,tca9539 + - ti,tca9554 + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-line-names: + minItems: 1 + maxItems: 32 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + reset-gpios: + description: + GPIO specification for the RESET input. This is an active low signal to + the PCA953x. + + vcc-supply: + description: + Optional power supply + + wakeup-source: + $ref: /schemas/types.yaml#/definitions/flag + +patternProperties: + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": + type: object + properties: + gpio-hog: true + gpios: true + input: true + output-high: true + output-low: true + line-name: true + + required: + - gpio-hog + - gpios + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + gpio@20 { + compatible = "nxp,pca9505"; + reg = <0x20>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pca9505>; + gpio-controller; + #gpio-cells = <2>; + interrupt-parent = <&gpio3>; + interrupts = <23 IRQ_TYPE_LEVEL_LOW>; + + usb3-sata-sel-hog { + gpio-hog; + gpios = <4 GPIO_ACTIVE_HIGH>; + output-low; + line-name = "usb3_sata_sel"; + }; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c1 { + #address-cells = <1>; + #size-cells = <0>; + + gpio99: gpio@22 { + compatible = "nxp,pcal6524"; + reg = <0x22>; + interrupt-parent = <&gpio6>; + interrupts = <1 IRQ_TYPE_EDGE_FALLING>; /* gpio6_161 */ + interrupt-controller; + #interrupt-cells = <2>; + vcc-supply = <&vdds_1v8_main>; + gpio-controller; + #gpio-cells = <2>; + gpio-line-names = "hdmi-ct-hpd", "hdmi.ls-oe", "p02", "p03", + "vibra", "fault2", "p06", "p07", "en-usb", + "en-host1", "en-host2", "chg-int", "p14", "p15", + "mic-int", "en-modem", "shdn-hs-amp", + "chg-status+red", "green", "blue", "en-esata", + "fault1", "p26", "p27"; + }; + + ts3a227@3b { + compatible = "ti,ts3a227e"; + reg = <0x3b>; + interrupt-parent = <&gpio99>; + interrupts = <14 IRQ_TYPE_EDGE_RISING>; + ti,micbias = <0>; /* 2.1V */ + }; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 25cfcc904240..442a1f537651 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -322,10 +322,6 @@ properties: - nuvoton,npct601 # Nuvoton Temperature Sensor - nuvoton,w83773g - # Octal SMBus and I2C registered interface - - nxp,pca9556 - # 8-bit I2C-bus and SMBus I/O port with reset - - nxp,pca9557 # OKI ML86V7667 video decoder - oki,ml86v7667 # OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus
Convert the NXP PCA953x family of GPIO expanders bindings to device tree schema. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> --- Changes since v1: 1. Use additionalProperties. 2. Add wakeup-source. 3. Add hogs. 4. Extend example with hogs. --- .../devicetree/bindings/gpio/gpio-pca953x.txt | 90 ---------- .../bindings/gpio/gpio-pca95xx.yaml | 166 ++++++++++++++++++ .../devicetree/bindings/trivial-devices.yaml | 4 - 3 files changed, 166 insertions(+), 94 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-pca953x.txt create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml