linux-kernel - Re: [PATCH 0/4] Add support for muxing individual pins

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]

Date:   Fri, 8 Dec 2017 17:22:44 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Linus Walleij <linus.walleij@...aro.org>
CC:     ext Tony Lindgren <tony@...mide.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        <patches@...nsource.cirrus.com>,
        "Bjorn Andersson" <bjorn.andersson@...aro.org>,
        Stephen Warren <swarren@...dotorg.org>
Subject: Re: [PATCH 0/4] Add support for muxing individual pins

On Fri, Dec 08, 2017 at 03:40:49PM +0100, Linus Walleij wrote:
> On Fri, Dec 8, 2017 at 3:29 PM, Charles Keepax
> <ckeepax@...nsource.cirrus.com> wrote:
> 
> > (...) I have finally
> > managed to get some time to look over the pinctrl-single stuff.
> >
> > Naively one could convert the pinctrl-single stuff over to use
> > the patches I proposed creating one large group for the driver
> > and then mux each pin individually from within that.  However I
> > am not really sure it would make sense. From the implementation
> > so far the pinctrl-single stuff appears to target systems where
> > there isn't really a concept of groups. Each pin is just a
> > completely separate entry and you can only configure things one
> > pin at a time. In that case it almost makes more sense to model
> > each pin as an individual group such that it is clearly distinct
> > from the others. My thinking had been more along the lines of you
> > perhaps have a group that represents an I2S port but you can also
> > individually assign each of those pins as a GPIO when not in use
> > as the I2S port.
> 
> So then I toss the qcom driver into the game instead :)
> 
> If you look at drivers/pinctrl/qcom/* e.g. pinctrl-ipq4019.c or
> essentially any of the subdrivers, you find exactly this scenario.
> 
> I am concerned that if we add infrastructure for this, it needs
> to have more than one user. Qualcomm does fit your description
> above I think.
> 

Yeah I could certainly have a hunt through for other users that
would make good candidates to update. The QC driver certainly
looks like it would be capable of muxing individual pins,
although it looks like it might not let you mux an individual
GPIO at the moment, need to dig into that more.

I guess maybe a bigger question is do we think this is a problem
worth solving or should really just be adding a group for each
pin I want to be able to mux?

Thanks,
Charles