Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: [PATCH 2/2] ARM: dts: aspeed: zaius: Add gpio line names
From:   Andrew Geissler <geissonator@gmail.com>
In-Reply-To: <48c9bd0e-3b5c-4f76-830f-4b0bd962148b@www.fastmail.com>
Date:   Fri, 3 Apr 2020 11:19:02 -0500
Cc:     Joel Stanley <joel@jms.id.au>,
        devicetree <devicetree@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        linux-aspeed <linux-aspeed@lists.ozlabs.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        OpenBMC Maillist <openbmc@lists.ozlabs.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <270714A1-2910-4B84-86B6-46177F439A52@gmail.com>
References: <20200306170218.79698-1-geissonator@yahoo.com>
 <20200306170218.79698-2-geissonator@yahoo.com>
 <294a52cd-2f60-41e5-a58f-a74151a83b08@www.fastmail.com>
 <9360D2B2-8242-4BA1-BF06-8916E87EDE67@gmail.com>
 <48c9bd0e-3b5c-4f76-830f-4b0bd962148b@www.fastmail.com>
To:     Andrew Jeffery <andrew@aj.id.au>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Apr 2, 2020, at 7:51 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
>=20
>=20
>=20
> On Tue, 31 Mar 2020, at 04:46, Andrew Geissler wrote:
>>=20
>>=20
>>> On Mar 26, 2020, at 6:20 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
>>>=20
>>>=20
>>>=20
>>> 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.
>>>>=20
>>>> Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
>>>=20
>>> So we're creating a bit of an ad-hoc ABI here between the DT and =
userspace.
>>>=20
>>> Where are we documenting it?
>>=20
>> Yeah, so far it=E2=80=99s basically design by precedent. If you want =
your OpenBMC
>> function to work then follow the standards we're setting in other =
dts=E2=80=99s.
>>=20
>> Is there a good place to document this? I could create a OpenBMC =
design
>> doc but that would not address non-OpenBMC areas.
>=20
> 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

>=20
> Andrew