[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdZGE3RGWarj6_kZN7e6AT+1C9FMrs=bGUFJLD00F9gOEQ@mail.gmail.com>
Date: Tue, 16 Oct 2018 09:10:56 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Mark Brown <broonie@...nel.org>, jacopo <jacopo@...ndi.org>,
Liam Girdwood <lgirdwood@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Jon Hunter <jonathanh@...dia.com>,
Cheng-Yi Chiang <cychiang@...omium.org>
Subject: Re: [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access
On Tue, Oct 16, 2018 at 1:08 AM Laurent Pinchart
<laurent.pinchart@...asonboard.com> wrote:
> I've seen other boards where two components sharing a reset signal have an
> active low reset for one, and an active high reset for the other one. Only one
> of the two can be out of reset at a time. That's probably considered as
> "clever" by the hardware engineers, but is awful to support for us.
Haha what a feat. If/when we run into that we simply invent a new
flag like GPIOD_ACTIVE_AMBIGUOUS.
> The core issue in my opinion is that we need code to handle this, and since
> the removal of board files there is no place anymore for such code. Board
> drivers exist in drivers/staging/board/, but that's hardly a solution moving
> forward (the TODO file explicitly states that removal of that code is the end
> goal).
Yeah I kind of already concluded that I need to pull the multiple user
reference counting out of the regulator core and take it over to the
GPIO subsystem so I'm going to attempt that for the next kernel
cycle. It's a neat feature anyways.
Yours,
Linus Walleij
Powered by blists - more mailing lists