linux-kernel - Re: [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdZ3O+=BiXqasVA-f_0qJCcY2UzWjR3=ri=SxY1et=PzVQ@mail.gmail.com>
Date:   Sat, 13 Oct 2018 16:59:12 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     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>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        cychiang@...omium.org
Subject: Re: [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access

On Fri, Oct 12, 2018 at 6:44 PM Mark Brown <broonie@...nel.org> wrote:
> On Fri, Oct 12, 2018 at 04:26:12PM +0200, jacopo mondi wrote:

> > Do you think extending gpiod_lookup_flags with this newly introduced
> > NONEXCLUSIVE one is an acceptable solution to avoid handling this in
> > the sensor driver like we're doing today?
>
> One problem you've got there is that you need the two devices to know
> about each other so they coordinate their use of the reset line.  This
> was relatively easy in the sysetm Cheng-yi has as it's just one driver
> but what if there's mutiple drivers?  That's relatively likely with
> audio where you might have something like a CODEC with a separate power
> amplifier.  The regulator enable stuff is handling this in the core but
> it's less clear where to put that for reset lines.

Yes spot on.

What we need to do for that to work is to move the reference
counting for shared lines over to gpiolib as well, else every subsystem
that needs to share a GPIO line essentially has to reimplement it.

If the consumers are in different subsystems they would even
have to share a reference count and this would lead to a big mess.

So I was thinking to pull that over to gpiolib for the next kernel :)

Hopefully I could do that without breaking anything, but I don't
have a good track record on that so I think the fine people who saw this
breakage will have to help me out.

Yours,
Linus Walleij