Re: [PATCH v2 3/4] dt-bindings: mfd: Add Delta TN48M CPLD drivers bindings

From: Rob Herring
Date: Tue May 25 2021 - 17:44:14 EST

On Tue, May 25, 2021 at 4:47 AM Robert Marko <robert.marko@xxxxxxxxxx> wrote:
>
> On Tue, May 25, 2021 at 1:09 AM Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > On Mon, May 24, 2021 at 02:05:38PM +0200, Robert Marko wrote:
> > > Add binding documents for the Delta TN48M CPLD drivers.
> > >
> > > Signed-off-by: Robert Marko <robert.marko@xxxxxxxxxx>
> > > ---
> > > Changes in v2:
> > > * Implement MFD as a simple I2C MFD
> > > * Add GPIO bindings as separate
> >
> > I don't understand why this changed. This doesn't look like an MFD to
> > me. Make your binding complete if there are missing functions.
> > Otherwise, stick with what I already ok'ed.
>
> It changed because the custom driver was dropped at Lee Jones-es request,
> and simple-mfd-i2c is now used.

To a certain extent, I don't care about the driver. A binding can't
know what an OS wants in terms of structure and driver structure could
evolve.

> > > .../bindings/gpio/delta,tn48m-gpio.yaml | 42 ++++++++++
> > > .../bindings/mfd/delta,tn48m-cpld.yaml | 81 +++++++++++++++++++
> > > 2 files changed, 123 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml
> > > create mode 100644 Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml b/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml
> > > new file mode 100644
> > > index 000000000000..aca646aecb12
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml
> > > @@ -0,0 +1,42 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/gpio/delta,tn48m-gpio.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Delta Networks TN48M CPLD GPIO controller
> > > +
> > > +maintainers:
> > > + - Robert Marko <robert.marko@xxxxxxxxxx>
> > > +
> > > +description: |
> > > + This module is part of the Delta TN48M multi-function device. For more
> > > + details see ../mfd/delta,tn48m-cpld.yaml.
> > > +
> > > + GPIO controller module provides GPIO-s for the SFP slots.
> > > + It is split into 3 controllers, one output only for the SFP TX disable
> > > + pins, one input only for the SFP present pins and one input only for
> > > + the SFP LOS pins.
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - delta,tn48m-gpio-sfp-tx-disable
> > > + - delta,tn48m-gpio-sfp-present
> > > + - delta,tn48m-gpio-sfp-los
> >
> > The function of the 'general purpose' IO should not be encoded into the
> > compatible name. Is each instance.
>
> They are not general-purpose, they are hard-wired pins.
> This is how the driver knows whether its output or input only,

Why does the driver need to know that? The user of the pins (the SFP
cage) knows the direction and should configure them the right way.

> and it's been reviewed by Andy Shevchenko.
> It was weird for me as well, but that is how GPIO regmap works.
>
> It was modeled by the sl28cpld GPIO driver as well as the rest of the docs
> as that CPLD has similar features supported to what this initial support does.

That one is at least just encoding the programming model, not the
connection. Maybe the driver didn't need to know there either, but I
can't study everyone's h/w in depth.

That one is also 8 GPIOs per instance, not 1.

> > > + reg:
> > > + maxItems: 1
> > > +
> > > + "#gpio-cells":
> > > + const: 2
> > > +
> > > + gpio-controller: true
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - "#gpio-cells"
> > > + - gpio-controller
> > > +
> > > +additionalProperties: false
> > > diff --git a/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml b/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml
> > > new file mode 100644
> > > index 000000000000..055e09129f86
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml
> > > @@ -0,0 +1,81 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/mfd/delta,tn48m-cpld.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Delta Networks TN48M CPLD controller
> > > +
> > > +maintainers:
> > > + - Robert Marko <robert.marko@xxxxxxxxxx>
> > > +
> > > +description: |
> > > + Lattice CPLD onboard the TN48M switches is used for system
> > > + management.
> > > +
> > > + It provides information about the hardware model, revision,
> > > + PSU status etc.
> > > +
> > > + It is also being used as a GPIO expander for the SFP slots.
> > > +
> > > +properties:
> > > + compatible:
> > > + const: delta,tn48m-cpld
> > > +
> > > + reg:
> > > + description:
> > > + I2C device address.
> > > + maxItems: 1
> > > +
> > > + "#address-cells":
> > > + const: 1
> > > +
> > > + "#size-cells":
> > > + const: 0
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - "#address-cells"
> > > + - "#size-cells"
> > > +
> > > +patternProperties:
> > > + "^gpio(@[0-9a-f]+)?$":
> > > + $ref: ../gpio/delta,tn48m-gpio.yaml
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + i2c {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + cpld@41 {
> > > + compatible = "delta,tn48m-cpld";
> > > + reg = <0x41>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + gpio@31 {
> > > + compatible = "delta,tn48m-gpio-sfp-tx-disable";
> > > + reg = <0x31>;
> >
> > Encode the register address into the gpio cells.
> Do you have an example of that?

The 'gpio number' in the first cell is totally up to the GPIO provider
(really all the cells are and are opaque to the consumer, but GPIO is
fairly standardized). So most of the time it's just the bit offset or
bit and register offsets when multiple 32-bit registers.

Rob