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]

Date:   Fri, 12 Oct 2018 19:14:58 +0200
From:   jacopo mondi <jacopo@...ndi.org>
To:     Mark Brown <broonie@...nel.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

Hi Mark,

On Fri, Oct 12, 2018 at 06:44:24PM +0200, Mark Brown wrote:
> 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.
>

Thanks

> > 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

That's exactly why the current implementation in those drivers is not
even sub-optimal :)

> 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.
>

Isn't DT the natural place where to define a reset line (or any kind of
shared GPIO line) as shared? And for non-OF archs, the board file?

Maybe I should start by adding the NONEXCLUSIVE flags to the ones accepted
by gpio lookup tables and see how it looks?

Thanks
   j


> > 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" (820 bytes)