[PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Christoph Niedermaier]

From: Marek Vasut [mailto:marex at denx.de]
Sent: Friday, March 12, 2021 5:17 PM
> To: Christoph Niedermaier <cniedermaier at dh-electronics.com>; linux-arm-
> kernel at lists.infradead.org; linus.walleij at linaro.org
> Cc: Alexandre Torgue <alexandre.torgue at st.com>; Patrice Chotard
> <patrice.chotard at st.com>; Patrick Delaunay <patrick.delaunay at st.com>;
> Maxime Coquelin <mcoquelin.stm32 at gmail.com>; linux-stm32 at st-md-
> mailman.stormreply.com
> Subject: Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96
> 
> ACHTUNG: Diese E-Mail kommt aus dem Internet und nicht aus unserem
> Firmennetzwerk!
> 
> 
> 
> On 3/12/21 4:17 PM, Christoph Niedermaier wrote:
>> From: Marek Vasut [mailto:marex at denx.de]
>> Sent: Thursday, August 6, 2020 9:30 AM
>>
>>> On 8/6/20 9:09 AM, Christoph Niedermaier wrote:
>>>> From: Marek Vasut <marex at denx.de>
>>>> Sent: Friday, July 24, 2020 12:16 PM
>>>>>
>>>>> Fill in the custom GPIO line names used by DH.
>>>>>
>>>> [...]
>>>>> +&gpioa {
>>>>> +       gpio-line-names = "", "", "", "",
>>>>> +                         "", "", "", "",
>>>>> +                         "", "", "", "DH-GPIO-K",
>>>>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>>>>> +};
>>>>> +
>>>> [...]
>>>>
>>>> We have been using the GPIO names at DH electronics for some time and also
>>>> on other SOMs, but have not yet streamed them. We started with the naming
>>>> only with a capital letter "A-W" since then without problems. To avoid a
>>>> hard cut or patching for us and our customers it would be good if we could
>>>> use the same naming in the mainline kernel as well. Marek, we would be
>>>> happy if you would adopt our valued GPIO naming in your patch.
>>>
>>> My counter-argument to this is that the naming should be unique and
>>> provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
>>> should rather be DHCOM-n . I can't say I'm particularly fond of the
>>> plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
>>> listing in libgpiod tools) does not give any hint what the GPIO is or
>>> where it comes from. Also, I worry a plain 'n' naming might clash with
>>> other GPIO IPs easily, while a more unique name can not.
>>
>> Hello Marek,
>>
>> after an internal discussion, we decided the following:
>>
>> Could you update the patch for the Avenger96 to the GPIO naming "AV96-n".
>>
>> Moreover for the SOM layer (stm32mp15xx-dhcom-som.dtsi) we would prefer
>> "DHCOM-n". It would be nice if you could create a patch for it.
> 
> I don't think we should have any SoM-side gpio-line-names, because once
> you plug the SoM into new carrier board, the gpio-lane-names will no
> longer make sense. So, I think all the gpio-line-names should be
> implemented in the carrier board DTS.

The idea is to define the GPIO names on the SOM layer and then
overwrite them on the carrier board DTS if needed. If there is no
naming on the carrier board, at least you have access via the DHCOM
GPIO names. The DHCOM GPIO names are standardized, so that you can
be sure that the assignment to a pin always fits.

> 
> As for the naming scheme, I was also hoping Linus might jump in and
> provide some suggestion on best practice here.
> 
> I think naming carrier board GPIOs "A", "B", "C",... is too opaque and
> can easily collide e.g. with GPIO expanders which might be on I2C or so.
> 
> A naming scheme which encodes the carrier board name is clearer and less
> likely to cause collision, so "AV96-A", "AV96-B", etc. looks good to me.
> It is obvious where the GPIO is located and unlikely to collide with any
> other GPIO name.

Regards,
Christoph