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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 03 Apr 2020 11:21:41 +1030
From:   "Andrew Jeffery" <andrew@...id.au>
To:     "Andrew Geissler" <geissonator@...il.com>
Cc:     "Joel Stanley" <joel@....id.au>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-aspeed@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        linux-gpio@...r.kernel.org, openbmc@...ts.ozlabs.org
Subject: Re: [PATCH 2/2] ARM: dts: aspeed: zaius: Add gpio line names



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.

Andrew