linux-kernel - Re: RE : [PATCH 0/4] Pinmux subsystem

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: <BANLkTinMxzrPS1GsTV1+poNGTxBpUFyBiw@mail.gmail.com>
Date:	Fri, 13 May 2011 09:05:17 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Matthieu Castet <matthieu.castet@...rot.com>
Cc:	Sascha Hauer <s.hauer@...gutronix.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	Martin Persson <martin.persson@...ricsson.com>,
	Lee Jones <lee.jones@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: RE : [PATCH 0/4] Pinmux subsystem

2011/5/12 Matthieu Castet <matthieu.castet@...rot.com>:

> Enumerating all possible case will be impossible because of the number of possible cases
> (and hardware guys can be very creative).

As mentioned in the document the subsystem is not about discrete
mathematics, i.e
we have no intent on enumerating every possible mux setting, only the ones that
are relevant for your electronics at hand.

> If spi can be in  { A8, A7, A6, A5 } and
> { G4, G3, G2, G1 }, Then you can output the spi on :
> - { A8, A7, A6, A5 }
> - { A8, A7, A6, G1 }
> - { A8, A7, G2, A5 }
> [...]
> - { G4, G3, G2, A5 }
> - { G4, G3, G2, G1 }
> You have 2^4 = 16 cases

Do you use all of them in practice?

> Pin muxing is really board specific  and shouldn't be in a "generic" driver.

It is rather package (PGA/BGA etc) specific than board specific. The board
is about what of the packaging options you actually use. As
mentioned in previous discussions you can pass in the actual configuration
of the mux settings from platform data, if we have device tree we can let the
board file dts inherit a package descriptor. All of this outside the
kernel tree.

So we define the function groups for the package that will actually be used
by the devices in the board files that we have.

And my first assumption is that those really aren't that many, and my second
assumption is that you would still have to have board-specific code to handle
every individual pin somewhere under mach-xxxx and this is what we're
currently trying to get away from.

> But what you could abstract is a way to select a configuration of a pin,
> not a group of pin for the board files.

The groups of pins are used when you're muxing devices, usually these use
more than one pin. And that is why we connect them to the devices
themselves with a mapping.

You can still allocate and mux individual pins for GPIO. Are there other
single-pin usecases?

Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/