From: Rob Herring <robh+dt@kernel.org> To: "Álvaro Fernández Rojas" <noltari@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org>, Michael Walle <michael@walle.cc>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Florian Fainelli <f.fainelli@gmail.com>, "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" <bcm-kernel-feedback-list@broadcom.com>, Jonas Gorski <jonas.gorski@gmail.com>, Necip Fazil Yildiran <fazilyildiran@gmail.com>, Andy Shevchenko <andy.shevchenko@gmail.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v6 04/15] dt-bindings: add BCM6328 pincontroller binding documentation Date: Wed, 10 Mar 2021 13:52:12 -0700 [thread overview] Message-ID: <CAL_JsqJzDj6bKwEfWzoa_m8HjP2VbZH21wYXXEUUEmLwHjrY_A@mail.gmail.com> (raw) In-Reply-To: <693A763C-14D1-47A2-A87E-2358E69DC993@gmail.com> On Wed, Mar 10, 2021 at 12:10 PM Álvaro Fernández Rojas <noltari@gmail.com> wrote: > > Hi Rob, > > > El 10 mar 2021, a las 19:45, Rob Herring <robh+dt@kernel.org> escribió: > > > > On Wed, Mar 10, 2021 at 11:03 AM Álvaro Fernández Rojas > > <noltari@gmail.com> wrote: > >> > >> Hi Rob, > >> > >>> El 10 mar 2021, a las 18:45, Rob Herring <robh+dt@kernel.org> escribió: > >>> > >>> On Wed, Mar 10, 2021 at 5:55 AM Álvaro Fernández Rojas > >>> <noltari@gmail.com> wrote: > >>>> > >>>> Add binding documentation for the pincontrol core found in BCM6328 SoCs. > >>>> > >>>> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> > >>>> Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com> > >>>> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > >>>> --- > >>>> v6: add changes suggested by Rob Herring > >>>> v5: change Documentation to dt-bindings in commit title > >>>> v4: no changes > >>>> v3: add new gpio node > >>>> v2: remove interrupts > >>>> > >>>> .../pinctrl/brcm,bcm6328-pinctrl.yaml | 174 ++++++++++++++++++ > >>>> 1 file changed, 174 insertions(+) > >>>> create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml > >>>> new file mode 100644 > >>>> index 000000000000..471f6efa1754 > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml > >>>> @@ -0,0 +1,174 @@ > >>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > >>>> +%YAML 1.2 > >>>> +--- > >>>> +$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6328-pinctrl.yaml# > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>> + > >>>> +title: Broadcom BCM6328 pin controller > >>>> + > >>>> +maintainers: > >>>> + - Álvaro Fernández Rojas <noltari@gmail.com> > >>>> + - Jonas Gorski <jonas.gorski@gmail.com> > >>>> + > >>>> +description: |+ > >>>> + The pin controller node should be the child of a syscon node. > >>>> + > >>>> + Refer to the the bindings described in > >>>> + Documentation/devicetree/bindings/mfd/syscon.yaml > >>>> + > >>>> +properties: > >>>> + compatible: > >>>> + const: brcm,bcm6328-pinctrl > >>>> + > >>>> + gpio: > >>>> + type: object > >>>> + properties: > >>>> + compatible: > >>>> + const: brcm,bcm6328-gpio > >>>> + > >>>> + data: > >>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>> + description: | > >>>> + Offset in the register map for the data register (in bytes). > >>>> + > >>>> + dirout: > >>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>> + description: | > >>>> + Offset in the register map for the dirout register (in bytes). > >>>> + > >>>> + gpio-controller: true > >>>> + > >>>> + "#gpio-cells": > >>>> + const: 2 > >>>> + > >>>> + gpio-ranges: > >>>> + maxItems: 1 > >>>> + > >>>> + required: > >>>> + - gpio-controller > >>>> + - gpio-ranges > >>>> + - '#gpio-cells' > >>>> + > >>>> + additionalProperties: false > >>>> + > >>>> +patternProperties: > >>>> + '^.*-pins$': > >>>> + if: > >>>> + type: object > >>>> + then: > >>>> + properties: > >>>> + function: > >>>> + $ref: "pinmux-node.yaml#/properties/function" > >>>> + enum: [ serial_led_data, serial_led_clk, inet_act_led, pcie_clkreq, > >>>> + led, ephy0_act_led, ephy1_act_led, ephy2_act_led, > >>>> + ephy3_act_led, hsspi_cs1, usb_device_port, usb_host_port ] > >>>> + > >>>> + pins: > >>>> + $ref: "pinmux-node.yaml#/properties/pins" > >>>> + enum: [ gpio6, gpio7, gpio11, gpio16, gpio17, gpio18, gpio19, > >>>> + gpio20, gpio25, gpio26, gpio27, gpio28, hsspi_cs1, > >>>> + usb_port1 ] > >>>> + > >>>> +required: > >>>> + - compatible > >>>> + - gpio > >>>> + > >>>> +additionalProperties: false > >>>> + > >>>> +examples: > >>>> + - | > >>>> + gpio_cntl@10000080 { > >>>> + compatible = "brcm,bcm6328-gpio-controller", "syscon", "simple-mfd"; > >>> > >>> You just added "brcm,bcm6328-gpio-controller", it would need to be documented. > >> > >> I just added that because you requested me to do it ¯\_(ツ)_/¯ > > > > I said 'syscon' by itself was not allowed, then asked about the multiple levels. > > Why not? Because 'syscon' alone doesn't mean anything and doesn't describe what registers it contains. You need something that says this is the XYZ block in the ABC SoC. > What if you have several controllers inside a syscon? You either just add properties (e.g. just add #clock-cells and it's a clock provider) or you have child nodes. Which one you do generally depends on if the providers have DT resources themselves. > The root should also have “something" in it? > > > > >> What should I do to document it? > >> I still don’t get most of this .yaml stuff... > >> > >>> > >>>> + reg = <0x10000080 0x80>; > >>>> + > >>>> + pinctrl: pinctrl { > >>>> + compatible = "brcm,bcm6328-pinctrl"; > >>>> + > >>>> + gpio { > >>>> + compatible = "brcm,bcm6328-gpio"; > >>> > >>> I'm still trying to understand why you need 3 levels of nodes here? > >>> The gpio controller contains a pin controller plus other undefined > >>> functions (because of 'syscon') and the pin controller contains a gpio > >>> controller? > >> > >> In previous versions the gpio controller was registered along with the pin controller, but @Linus requested me to register the gpio pin controller ranges through device tree by using gpio-ranges and I decided to use this approach, which was already used by other pin controllers. > >> However, there aren’t any pinctrl drivers using gpio-regmap, so this is kind of new… > >> > >>> > >>> I think "brcm,bcm6328-gpio-controller" and "brcm,bcm6328-pinctrl" > >>> should be a single node. > >> > >> I agree, but does it make sense to add gpio-ranges to a pinctrl node referencing itself? > > > > It wouldn't be. I wasn't saying the pinctrl and gpio controller are > > the same node. My suggestion was combining syscon and pinctrl. > > But that wouldn’t be correct if there were more “things” inside the syscon, right? Right. > >> Something like: > >> syscon { > > > > Again with the syscon. If pinctrl and GPIO are the only functions > > within this h/w block, then this is not a syscon. You are just abusing > > that having 'syscon' compatible means you get a regmap created > > automagically for you. Nothing here looks like a 'system controller' > > to me. A 'system controller' is a random collection of register bits > > with functions that don't fit anywhere else. > > pinctrl and GPIO aren’t the only functions within this HW block. > Maybe I didn’t document/code it properly, but I’m sure I’m not abusing what a system controller is. Okay, that's the detail missing from this patch. > Please, take a look at http://www.datashed.science/misc/bcm/gpl/broadcom-sdk-416L05/shared/opensource/include/bcm963xx/6328_map_part.h: > typedef struct GpioControl { > uint32 GPIODirHi; /* 0 */ > uint32 GPIODir; /* 4 */ > uint32 GPIOioHi; /* 8 */ > uint32 GPIOio; /* C */ > uint32 unused0; /* 10 */ > uint32 SpiSlaveCfg; /* 14 */ > uint32 GPIOMode; /* 18 */ > uint64 PinMuxSel; /* 1C */ > uint32 PinMuxSelOther; /* 24 */ > uint32 TestControl; /* 28 */ > uint32 unused2; /* 2C */ > uint32 RoboSWLEDControl; /* 30 */ > uint32 RoboSWLEDLSR; /* 34 */ > uint32 unused3; /* 38 */ > uint32 RoboswEphyCtrl; /* 3C */ > uint32 RoboswSwitchCtrl; /* 40 */ > uint32 RegFileTmCtl; /* 44 */ > uint32 RingOscCtrl0; /* 48 */ > uint32 RingOscCtrl1; /* 4C */ > uint32 unused4[6]; /* 50 - 64 */ > uint32 DieRevID; /* 68 */ > uint32 unused5; /* 6c */ > uint32 DiagSelControl; /* 70 */ > uint32 DiagReadBack; /* 74 */ > uint32 DiagReadBackHi; /* 78 */ > uint32 DiagMiscControl; /* 7c */ > } GpioControl; > > So we’re using GPIODirHi, GPIODir, GPIOioHi and GPIOio registers for GPIO regmap driver. > And we’re using GPIOMode, PinMuxSel (u64 -> x2 u32), PinMuxSelOther for pinctrl driver. > And this is for BCM6328, but some of the other SoCs are even more scattered. So based on this I'd do something like this: syscon { reg = <base 0x80>; ranges = <0 base 0x80>; pinctrl@18 { reg = <0x18 0x10>; foo-pins {}; gpio@0 { reg = <0x0 0x10>; }; }; If things are more scattered within gpio or pinctrl, then maybe you need multiple reg entries. Whether the OS uses 'reg' and mmio or a regmap from the syscon is up to you. That's independent of the binding. > >> pinctrl: pinctrl { > >> compatible … > >> > >> gpio-controller; > >> gpio-ranges = <&pinctrl 0 0 32>; > >> #gpio-cells = <2>; > > > > I was assuming you have multiple GPIO controllers within 1 pinctlr? > > The pinctrl and gpio could be a single node like above if there's only > > 1 GPIO controller. But I'm still somewhat guessing what the h/w looks > > like because I have to go searching thru the driver to decipher. > > Please describe the h/w in the binding. > > GPIO dirout and data rely on 2x u32 registers or a single u64 register. > This is can be either be implemented as a single GPIO controller, or as 2 separate GPIO controllers. > However, since I’m overriding reg_mask_xlate with bcm63xx_reg_mask_xlate I can register it as a single GPIO controller, which makes more sense to me. I think 1 makes more sense. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh+dt@kernel.org> To: "Álvaro Fernández Rojas" <noltari@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org>, Michael Walle <michael@walle.cc>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Florian Fainelli <f.fainelli@gmail.com>, "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" <bcm-kernel-feedback-list@broadcom.com>, Jonas Gorski <jonas.gorski@gmail.com>, Necip Fazil Yildiran <fazilyildiran@gmail.com>, Andy Shevchenko <andy.shevchenko@gmail.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v6 04/15] dt-bindings: add BCM6328 pincontroller binding documentation Date: Wed, 10 Mar 2021 13:52:12 -0700 [thread overview] Message-ID: <CAL_JsqJzDj6bKwEfWzoa_m8HjP2VbZH21wYXXEUUEmLwHjrY_A@mail.gmail.com> (raw) In-Reply-To: <693A763C-14D1-47A2-A87E-2358E69DC993@gmail.com> On Wed, Mar 10, 2021 at 12:10 PM Álvaro Fernández Rojas <noltari@gmail.com> wrote: > > Hi Rob, > > > El 10 mar 2021, a las 19:45, Rob Herring <robh+dt@kernel.org> escribió: > > > > On Wed, Mar 10, 2021 at 11:03 AM Álvaro Fernández Rojas > > <noltari@gmail.com> wrote: > >> > >> Hi Rob, > >> > >>> El 10 mar 2021, a las 18:45, Rob Herring <robh+dt@kernel.org> escribió: > >>> > >>> On Wed, Mar 10, 2021 at 5:55 AM Álvaro Fernández Rojas > >>> <noltari@gmail.com> wrote: > >>>> > >>>> Add binding documentation for the pincontrol core found in BCM6328 SoCs. > >>>> > >>>> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> > >>>> Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com> > >>>> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> > >>>> --- > >>>> v6: add changes suggested by Rob Herring > >>>> v5: change Documentation to dt-bindings in commit title > >>>> v4: no changes > >>>> v3: add new gpio node > >>>> v2: remove interrupts > >>>> > >>>> .../pinctrl/brcm,bcm6328-pinctrl.yaml | 174 ++++++++++++++++++ > >>>> 1 file changed, 174 insertions(+) > >>>> create mode 100644 Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml > >>>> new file mode 100644 > >>>> index 000000000000..471f6efa1754 > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml > >>>> @@ -0,0 +1,174 @@ > >>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > >>>> +%YAML 1.2 > >>>> +--- > >>>> +$id: http://devicetree.org/schemas/pinctrl/brcm,bcm6328-pinctrl.yaml# > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>> + > >>>> +title: Broadcom BCM6328 pin controller > >>>> + > >>>> +maintainers: > >>>> + - Álvaro Fernández Rojas <noltari@gmail.com> > >>>> + - Jonas Gorski <jonas.gorski@gmail.com> > >>>> + > >>>> +description: |+ > >>>> + The pin controller node should be the child of a syscon node. > >>>> + > >>>> + Refer to the the bindings described in > >>>> + Documentation/devicetree/bindings/mfd/syscon.yaml > >>>> + > >>>> +properties: > >>>> + compatible: > >>>> + const: brcm,bcm6328-pinctrl > >>>> + > >>>> + gpio: > >>>> + type: object > >>>> + properties: > >>>> + compatible: > >>>> + const: brcm,bcm6328-gpio > >>>> + > >>>> + data: > >>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>> + description: | > >>>> + Offset in the register map for the data register (in bytes). > >>>> + > >>>> + dirout: > >>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>> + description: | > >>>> + Offset in the register map for the dirout register (in bytes). > >>>> + > >>>> + gpio-controller: true > >>>> + > >>>> + "#gpio-cells": > >>>> + const: 2 > >>>> + > >>>> + gpio-ranges: > >>>> + maxItems: 1 > >>>> + > >>>> + required: > >>>> + - gpio-controller > >>>> + - gpio-ranges > >>>> + - '#gpio-cells' > >>>> + > >>>> + additionalProperties: false > >>>> + > >>>> +patternProperties: > >>>> + '^.*-pins$': > >>>> + if: > >>>> + type: object > >>>> + then: > >>>> + properties: > >>>> + function: > >>>> + $ref: "pinmux-node.yaml#/properties/function" > >>>> + enum: [ serial_led_data, serial_led_clk, inet_act_led, pcie_clkreq, > >>>> + led, ephy0_act_led, ephy1_act_led, ephy2_act_led, > >>>> + ephy3_act_led, hsspi_cs1, usb_device_port, usb_host_port ] > >>>> + > >>>> + pins: > >>>> + $ref: "pinmux-node.yaml#/properties/pins" > >>>> + enum: [ gpio6, gpio7, gpio11, gpio16, gpio17, gpio18, gpio19, > >>>> + gpio20, gpio25, gpio26, gpio27, gpio28, hsspi_cs1, > >>>> + usb_port1 ] > >>>> + > >>>> +required: > >>>> + - compatible > >>>> + - gpio > >>>> + > >>>> +additionalProperties: false > >>>> + > >>>> +examples: > >>>> + - | > >>>> + gpio_cntl@10000080 { > >>>> + compatible = "brcm,bcm6328-gpio-controller", "syscon", "simple-mfd"; > >>> > >>> You just added "brcm,bcm6328-gpio-controller", it would need to be documented. > >> > >> I just added that because you requested me to do it ¯\_(ツ)_/¯ > > > > I said 'syscon' by itself was not allowed, then asked about the multiple levels. > > Why not? Because 'syscon' alone doesn't mean anything and doesn't describe what registers it contains. You need something that says this is the XYZ block in the ABC SoC. > What if you have several controllers inside a syscon? You either just add properties (e.g. just add #clock-cells and it's a clock provider) or you have child nodes. Which one you do generally depends on if the providers have DT resources themselves. > The root should also have “something" in it? > > > > >> What should I do to document it? > >> I still don’t get most of this .yaml stuff... > >> > >>> > >>>> + reg = <0x10000080 0x80>; > >>>> + > >>>> + pinctrl: pinctrl { > >>>> + compatible = "brcm,bcm6328-pinctrl"; > >>>> + > >>>> + gpio { > >>>> + compatible = "brcm,bcm6328-gpio"; > >>> > >>> I'm still trying to understand why you need 3 levels of nodes here? > >>> The gpio controller contains a pin controller plus other undefined > >>> functions (because of 'syscon') and the pin controller contains a gpio > >>> controller? > >> > >> In previous versions the gpio controller was registered along with the pin controller, but @Linus requested me to register the gpio pin controller ranges through device tree by using gpio-ranges and I decided to use this approach, which was already used by other pin controllers. > >> However, there aren’t any pinctrl drivers using gpio-regmap, so this is kind of new… > >> > >>> > >>> I think "brcm,bcm6328-gpio-controller" and "brcm,bcm6328-pinctrl" > >>> should be a single node. > >> > >> I agree, but does it make sense to add gpio-ranges to a pinctrl node referencing itself? > > > > It wouldn't be. I wasn't saying the pinctrl and gpio controller are > > the same node. My suggestion was combining syscon and pinctrl. > > But that wouldn’t be correct if there were more “things” inside the syscon, right? Right. > >> Something like: > >> syscon { > > > > Again with the syscon. If pinctrl and GPIO are the only functions > > within this h/w block, then this is not a syscon. You are just abusing > > that having 'syscon' compatible means you get a regmap created > > automagically for you. Nothing here looks like a 'system controller' > > to me. A 'system controller' is a random collection of register bits > > with functions that don't fit anywhere else. > > pinctrl and GPIO aren’t the only functions within this HW block. > Maybe I didn’t document/code it properly, but I’m sure I’m not abusing what a system controller is. Okay, that's the detail missing from this patch. > Please, take a look at http://www.datashed.science/misc/bcm/gpl/broadcom-sdk-416L05/shared/opensource/include/bcm963xx/6328_map_part.h: > typedef struct GpioControl { > uint32 GPIODirHi; /* 0 */ > uint32 GPIODir; /* 4 */ > uint32 GPIOioHi; /* 8 */ > uint32 GPIOio; /* C */ > uint32 unused0; /* 10 */ > uint32 SpiSlaveCfg; /* 14 */ > uint32 GPIOMode; /* 18 */ > uint64 PinMuxSel; /* 1C */ > uint32 PinMuxSelOther; /* 24 */ > uint32 TestControl; /* 28 */ > uint32 unused2; /* 2C */ > uint32 RoboSWLEDControl; /* 30 */ > uint32 RoboSWLEDLSR; /* 34 */ > uint32 unused3; /* 38 */ > uint32 RoboswEphyCtrl; /* 3C */ > uint32 RoboswSwitchCtrl; /* 40 */ > uint32 RegFileTmCtl; /* 44 */ > uint32 RingOscCtrl0; /* 48 */ > uint32 RingOscCtrl1; /* 4C */ > uint32 unused4[6]; /* 50 - 64 */ > uint32 DieRevID; /* 68 */ > uint32 unused5; /* 6c */ > uint32 DiagSelControl; /* 70 */ > uint32 DiagReadBack; /* 74 */ > uint32 DiagReadBackHi; /* 78 */ > uint32 DiagMiscControl; /* 7c */ > } GpioControl; > > So we’re using GPIODirHi, GPIODir, GPIOioHi and GPIOio registers for GPIO regmap driver. > And we’re using GPIOMode, PinMuxSel (u64 -> x2 u32), PinMuxSelOther for pinctrl driver. > And this is for BCM6328, but some of the other SoCs are even more scattered. So based on this I'd do something like this: syscon { reg = <base 0x80>; ranges = <0 base 0x80>; pinctrl@18 { reg = <0x18 0x10>; foo-pins {}; gpio@0 { reg = <0x0 0x10>; }; }; If things are more scattered within gpio or pinctrl, then maybe you need multiple reg entries. Whether the OS uses 'reg' and mmio or a regmap from the syscon is up to you. That's independent of the binding. > >> pinctrl: pinctrl { > >> compatible … > >> > >> gpio-controller; > >> gpio-ranges = <&pinctrl 0 0 32>; > >> #gpio-cells = <2>; > > > > I was assuming you have multiple GPIO controllers within 1 pinctlr? > > The pinctrl and gpio could be a single node like above if there's only > > 1 GPIO controller. But I'm still somewhat guessing what the h/w looks > > like because I have to go searching thru the driver to decipher. > > Please describe the h/w in the binding. > > GPIO dirout and data rely on 2x u32 registers or a single u64 register. > This is can be either be implemented as a single GPIO controller, or as 2 separate GPIO controllers. > However, since I’m overriding reg_mask_xlate with bcm63xx_reg_mask_xlate I can register it as a single GPIO controller, which makes more sense to me. I think 1 makes more sense. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-10 20:53 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-10 12:54 [PATCH v6 00/15] pinctrl: add BCM63XX pincontrol support Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 01/15] gpio: guard gpiochip_irqchip_add_domain() with GPIOLIB_IRQCHIP Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 02/15] gpio: regmap: set gpio_chip of_node Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 14:01 ` Andy Shevchenko 2021-03-10 14:01 ` Andy Shevchenko 2021-03-10 18:27 ` Michael Walle 2021-03-10 18:27 ` Michael Walle 2021-03-10 19:12 ` Álvaro Fernández Rojas 2021-03-10 19:12 ` Álvaro Fernández Rojas 2021-03-11 1:16 ` Linus Walleij 2021-03-11 1:16 ` Linus Walleij 2021-03-10 12:54 ` [PATCH v6 03/15] pinctrl: bcm: add bcm63xx base code Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 14:07 ` Andy Shevchenko 2021-03-10 14:07 ` Andy Shevchenko 2021-03-10 17:50 ` Rob Herring 2021-03-10 17:50 ` Rob Herring 2021-03-11 1:09 ` Linus Walleij 2021-03-11 1:09 ` Linus Walleij 2021-03-11 14:57 ` Rob Herring 2021-03-11 14:57 ` Rob Herring 2021-03-11 16:13 ` Linus Walleij 2021-03-11 16:13 ` Linus Walleij 2021-03-11 17:00 ` Álvaro Fernández Rojas 2021-03-11 17:00 ` Álvaro Fernández Rojas 2021-03-11 18:24 ` Rob Herring 2021-03-11 18:24 ` Rob Herring 2021-03-11 18:32 ` Álvaro Fernández Rojas 2021-03-11 18:32 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 04/15] dt-bindings: add BCM6328 pincontroller binding documentation Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 17:45 ` Rob Herring 2021-03-10 17:45 ` Rob Herring 2021-03-10 18:03 ` Álvaro Fernández Rojas 2021-03-10 18:03 ` Álvaro Fernández Rojas 2021-03-10 18:45 ` Rob Herring 2021-03-10 18:45 ` Rob Herring 2021-03-10 19:10 ` Álvaro Fernández Rojas 2021-03-10 19:10 ` Álvaro Fernández Rojas 2021-03-10 20:52 ` Rob Herring [this message] 2021-03-10 20:52 ` Rob Herring 2021-03-11 17:09 ` Álvaro Fernández Rojas 2021-03-11 17:09 ` Álvaro Fernández Rojas 2021-03-11 18:14 ` Rob Herring 2021-03-11 18:14 ` Rob Herring 2021-03-11 18:34 ` Álvaro Fernández Rojas 2021-03-11 18:34 ` Álvaro Fernández Rojas 2021-03-15 15:57 ` Linus Walleij 2021-03-15 15:57 ` Linus Walleij 2021-03-11 1:22 ` Linus Walleij 2021-03-11 1:22 ` Linus Walleij 2021-03-10 12:54 ` [PATCH v6 05/15] pinctrl: add a pincontrol driver for BCM6328 Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 06/15] dt-bindings: add BCM6358 pincontroller binding documentation Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 07/15] pinctrl: add a pincontrol driver for BCM6358 Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 08/15] dt-bindings: add BCM6362 pincontroller binding documentation Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 09/15] pinctrl: add a pincontrol driver for BCM6362 Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 10/15] dt-bindings: add BCM6368 pincontroller binding documentation Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:54 ` [PATCH v6 11/15] pinctrl: add a pincontrol driver for BCM6368 Álvaro Fernández Rojas 2021-03-10 12:54 ` Álvaro Fernández Rojas 2021-03-10 12:55 ` [PATCH v6 12/15] dt-bindings: add BCM63268 pincontroller binding documentation Álvaro Fernández Rojas 2021-03-10 12:55 ` Álvaro Fernández Rojas 2021-03-10 12:55 ` [PATCH v6 13/15] pinctrl: add a pincontrol driver for BCM63268 Álvaro Fernández Rojas 2021-03-10 12:55 ` Álvaro Fernández Rojas 2021-03-10 12:55 ` [PATCH v6 14/15] dt-bindings: add BCM6318 pincontroller binding documentation Álvaro Fernández Rojas 2021-03-10 12:55 ` Álvaro Fernández Rojas 2021-03-10 12:55 ` [PATCH v6 15/15] pinctrl: add a pincontrol driver for BCM6318 Álvaro Fernández Rojas 2021-03-10 12:55 ` Álvaro Fernández Rojas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAL_JsqJzDj6bKwEfWzoa_m8HjP2VbZH21wYXXEUUEmLwHjrY_A@mail.gmail.com \ --to=robh+dt@kernel.org \ --cc=andy.shevchenko@gmail.com \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=bgolaszewski@baylibre.com \ --cc=devicetree@vger.kernel.org \ --cc=f.fainelli@gmail.com \ --cc=fazilyildiran@gmail.com \ --cc=jonas.gorski@gmail.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=michael@walle.cc \ --cc=noltari@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.