Re: Requesting as a GPIO a pin already used through pinctrl

From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Alexandre Courbot <gnurou@gmail.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Chen-Yu Tsai <wens@csie.org>
Subject: Re: Requesting as a GPIO a pin already used through pinctrl
Date: Wed, 2 Nov 2016 22:31:42 +0100	[thread overview]
Message-ID: <20161102213142.ajano4g4oizusv74@lukather> (raw)
In-Reply-To: <CACRpkda=_TD5S7N52CSYrmKvkY5WLU4Qi47_a=K+8Ud+kmphqg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

Hi Linus,

On Thu, Oct 27, 2016 at 02:12:45PM +0200, Linus Walleij wrote:
> On Wed, Oct 26, 2016 at 5:49 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> 
> > In order not to break the DT, we looked at the code of pin_request
> > (which is the one using the strict flag), and went to the conclusion
> > that it needs to be amended to check the owner based on the device
> > structure pointer.
> (...)
> > Which means that in order to avoid removing one property from a DT to
> > fix an actual bug that can cause real stability issues to Linux, we
> > end up reworking the gpiolib API and fixing all the users.
> 
> DT backward compatibility is for one case: when devices are shipped
> with a DT burnt into ROM/flash. Is that happening?
>
> If Allwinner or their subvendors are not shipping devcie trees - i.e. if
> this a community-only effort and you're just building and booting the
> DT+kernel on all these devices, by all means break the ABI if it
> makes sense. Noone is going to complain.
> 
> Then we can discuss backward compatibility the day Allwinner start
> shipping device trees, not now.

As far as I know, no one is shipping DTs in a read-only
storage. Allwinner ships a different binary format (FEX), or a widely
incompatible DT in their newer SoCs in their BSPs, so it doesn't
really matter anyway.

The only product that I know of that is running only a mainline-ish
kernel is the CHIP, which I happen to work on, and we just have an
upgradable debian package holding the DT.

And we'll *have* to update it anyway, since between the time where we
ship a feature, and the time it gets upstreamed, the DT binding is
very likely to have changed anyway because of the reviews.

Some other products have a mainline-ish options too, but are in a
similar situation, since their DT have bindings of an earlier version
of patches.

So no, I really don't think the DT ABI matters here, or at least
compared to the bug we face and the changes that we would need to make
in order to fix it. But Mark will probably disagree.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]