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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20181012164424.GE2340@sirena.org.uk>
Date:   Fri, 12 Oct 2018 18:44:24 +0200
From:   Mark Brown <broonie@...nel.org>
To:     jacopo mondi <jacopo@...ndi.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Jon Hunter <jonathanh@...dia.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Cheng-yi Chiang <cychiang@...omium.org>
Subject: Re: [PATCH v2] regulator/gpio: Allow nonexclusive GPIO access

On Fri, Oct 12, 2018 at 04:26:12PM +0200, jacopo mondi wrote:

> Sorry, I'm going slightly OT with this, but please read below.

> On Fri, Oct 12, 2018 at 02:54:12PM +0200, Linus Walleij wrote:
> > This allows nonexclusive (simultaneous) access to a single
> > GPIO line for the fixed regulator enable line. This happens

> I might have a use case for shared GPIO lines used as 'simple' reset
> signal for camera devices and not for regulators.

This recently came up in ASoC too with audio CODECs sharing reset lines,
there was a discussion started with the reset API maintainer though no
response yet.  CCing in Cheng-yi who had that problem.  Not deleting
context for that.

> See drivers/media/i2c/ov772x.c FIXME note in power_on() function at:
> https://elixir.bootlin.com/linux/latest/source/drivers/media/i2c/ov772x.c#L832
> 
> The reset line is in this case is passed to the driver by board file:
> https://elixir.bootlin.com/linux/latest/source/arch/sh/boards/mach-migor/setup.c#L350
> 
> As you can see PTT3 is used for both sensors (I know, questionable
> HW design...)
> 
> 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.

> Please note this is an ancient architecture that boots from board
> files, but the same might happen in modern designs with OF support. Is
> there any clean way to handle shared GPIOs I might not be aware of for
> those systems?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)