Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201115222425.2885427-1-michael@fossekall.de>
 <20201120155252.kfkavrn4wpqzmbyc@gilmour> <20201120182739.GA3734181@a98shuttle.de>
In-Reply-To: <20201120182739.GA3734181@a98shuttle.de>
From:   Chen-Yu Tsai <wens@csie.org>
Date:   Mon, 23 Nov 2020 12:39:07 +0800
Message-ID: <CAGb2v645Hq_C6fntM8CFnBiHBTFM-6zyZUXLKWPccmb3eOZBKQ@mail.gmail.com>
Subject: Re: [PATCH] ARM: dts: sun8i-h2-plus-bananapi-m2-zero: add gpio-line-names
To:     Michael Klein <michael@fossekall.de>
Cc:     Maxime Ripard <maxime@cerno.tech>,
        devicetree <devicetree@vger.kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Nov 21, 2020 at 2:28 AM Michael Klein <michael@fossekall.de> wrote:
>
> Thank you for having a look at the patch!
>
> On Fri, Nov 20, 2020 at 04:52:52PM +0100, Maxime Ripard wrote:
> >On Sun, Nov 15, 2020 at 11:24:25PM +0100, Michael Klein wrote:
> >> Add gpio-line-names as documented in the Banana Pi wiki [1] and in the
> >> schematics [2].
> >>
> >> [1]: http://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO#GPIO_PIN_define
> >> [2]: https://drive.google.com/file/d/0B4PAo2nW2KfnMW5sVkxWSW9qa28/view
> >>
> >> Signed-off-by: Michael Klein <michael@fossekall.de>
> >> ---
> >>  .../dts/sun8i-h2-plus-bananapi-m2-zero.dts    | 64 +++++++++++++++++++
> >>  1 file changed, 64 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> >> index 4c6704e4c57e..b4ddfaf01b45 100644
> >> --- a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> >> +++ b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
> >> @@ -136,6 +136,70 @@ bluetooth {
> >>
> >>  };
> >>
> >> +&pio {
> >> +    gpio-line-names =
> >> +            /* PA */
> >> +            "UART2-TX", "UART2-RX", "UART2-RTS", "UART2-CTS",
> >> +                    "UART0-TXD", "UART0-RXD", "PWM1", "PA7-EINT7",
> >> +            "PA8-EINT8", "PA9-EINT9", "PA10-EINT10", "TWI0-SCK",
> >> +                    "TWI0-SDA", "UART3-TX", "UART3-RX", "UART3-RTS",
> >> +            "UART3-CTS", "PA17-EINT17", "TWI1-SCK", "TWI1-SDA",
> >> +                    "PA20-EINT20", "PA21-EINT21", "", "",
> >> +            "", "", "", "", "", "", "", "",
> >
> >IIRC, the point is to have the pin names that the vendor publishes.
> >
> >Looking at Documentation/devicetree/bindings/gpio/gpio.txt, it says:
> >
> >"""
> >Optionally, a GPIO controller may have a "gpio-line-names" property. This is
> >an array of strings defining the names of the GPIO lines going out of the
> >GPIO controller. This name should be the most meaningful producer name
> >for the system, such as a rail name indicating the usage. Package names
> >such as pin name are discouraged: such lines have opaque names (since they
> >are by definition generic purpose) and such names are usually not very
> >helpful.
> >"""
> >
> >In this case, from the link you gave above, I think having the CON*-P*
> >names make more sense.
>
> Hm, but these are the pin names (of the connector) and should thus not
> be used, right?
>
> For e.g. the PA0 pin, the wiki link gives three candidates:
>
> - CON2-P13 (GPIO Pin Name -> pin 13 of the 40 pin GPIO header)
> - UART2-TX (Default Function)
> - PA0-EINT0 (Function2 : GPIO)
>
> IMHO, the CON*-P* name is the least helpful of the above, as it tells
> nothing about the usage. I'm not sure about the other two names, though.

I believe the function names are pretty useless in this case, as you
cannot use the GPIO subsystem to mux functions. That is what pinctrl
does. And in our case, the pinctrl drivers already know all the
available functions each pin has.

Using the pin count and connector name provides the user direct mapping
of the software representation of the pin against the actual pin on the
hardware. The user can then proceed to request and use that pin.

Again, you can not request "functions" from userspace, only GPIO usage.

Also using "one" function name creates confusion if the same function
is available on multiple pins.

ChenYu


> Michael
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel