linux-kernel - Re: [PATCH 2/2] ARM: dts: aspeed: zaius: Add gpio line names

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 3 Apr 2020 11:19:02 -0500
From:   Andrew Geissler <geissonator@...il.com>
To:     Andrew Jeffery <andrew@...id.au>
Cc:     Joel Stanley <joel@....id.au>,
        devicetree <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-aspeed <linux-aspeed@...ts.ozlabs.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        OpenBMC Maillist <openbmc@...ts.ozlabs.org>
Subject: Re: [PATCH 2/2] ARM: dts: aspeed: zaius: Add gpio line names



> On Apr 2, 2020, at 7:51 PM, Andrew Jeffery <andrew@...id.au> wrote:
> 
> 
> 
> On Tue, 31 Mar 2020, at 04:46, Andrew Geissler wrote:
>> 
>> 
>>> On Mar 26, 2020, at 6:20 PM, Andrew Jeffery <andrew@...id.au> wrote:
>>> 
>>> 
>>> 
>>> On Sat, 7 Mar 2020, at 03:32, Andrew Geissler wrote:
>>>> Name the GPIOs to help userspace work with them. The names describe the
>>>> functionality the lines provide, not the net or ball name. This makes it
>>>> easier to share userspace code across different systems and makes the
>>>> use of the lines more obvious.
>>>> 
>>>> Signed-off-by: Andrew Geissler <geissonator@...oo.com>
>>> 
>>> So we're creating a bit of an ad-hoc ABI here between the DT and userspace.
>>> 
>>> Where are we documenting it?
>> 
>> Yeah, so far it’s basically design by precedent. If you want your OpenBMC
>> function to work then follow the standards we're setting in other dts’s.
>> 
>> Is there a good place to document this? I could create a OpenBMC design
>> doc but that would not address non-OpenBMC areas.
> 
> Don't let perfect be the enemy of good enough :) Lets document it in OpenBMC
> and then look at alternatives if we find it's necessary. I don't think we will given
> that the contract is between the kernel and OpenBMC userspace.

Ok, I put a doc up for review here:
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/30988

> 
> Andrew