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;
User-Agent: Cyrus-JMAP/3.1.7-1080-gca5de7b-fmstable-20200402v5
Mime-Version: 1.0
Message-Id: <48c9bd0e-3b5c-4f76-830f-4b0bd962148b@www.fastmail.com>
In-Reply-To: <9360D2B2-8242-4BA1-BF06-8916E87EDE67@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>
Date:   Fri, 03 Apr 2020 11:21:41 +1030
From:   "Andrew Jeffery" <andrew@aj.id.au>
To:     "Andrew Geissler" <geissonator@gmail.com>
Cc:     "Joel Stanley" <joel@jms.id.au>,
        devicetree <devicetree@vger.kernel.org>,
        linux-arm-kernel@lists.infradead.org,
        linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
        linux-gpio@vger.kernel.org, openbmc@lists.ozlabs.org
Subject: Re: [PATCH 2/2] ARM: dts: aspeed: zaius: Add gpio line names
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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 mak=
es it
> >> easier to share userspace code across different systems and makes t=
he
> >> 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 use=
rspace.
> >=20
> > Where are we documenting it?
>=20
> Yeah, so far it=E2=80=99s basically design by precedent. If you want y=
our 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 desig=
n
> doc but that would not address non-OpenBMC areas.

Don't let perfect be the enemy of good enough :) Lets document it in Ope=
nBMC
and then look at alternatives if we find it's necessary. I don't think w=
e will given
that the contract is between the kernel and OpenBMC userspace.

Andrew