linux-kernel - RE: [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs

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: <74CDBE0F657A3D45AFBB94109FB122FF17518604CA@HQMAIL01.nvidia.com>
Date:	Fri, 9 Dec 2011 08:53:48 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Shawn Guo <shawn.guo@...escale.com>
CC:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: RE: [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32
 SoCs

Shawn Guo wrote at Thursday, December 08, 2011 10:14 PM:
> On Thu, Dec 08, 2011 at 09:47:24PM -0700, Stephen Warren wrote:
...
> > I'm not familiar with imx. For my education, which of the following is true:
> >
> 
> It's the case b).
> 
> > a)
> >
> > * UART TX signal can muxed onto 1 of 16 pins
> > * UART RX signal can muxed onto 1 of 16 pins
> >
> > In this case, you'd just list say "UART A TX" as a legal function for
> > each of those 16 pins. Yes, that's a lot of places, but still do-able.
> >
> > (16 possible positions would be a lot, but I suppose it is possible in HW)
> >
> > b)
> >
> > * UART TX signal can muxed onto 1 of 4 pins
> > * UART RX signal can muxed onto 1 of 4 pins
> > * So, there are 16 (4*4) combinations of these two settings
> >
> > In this case, you'd just list say "UART A TX" for the 4 pins, and "UART
> > A RX" for the other 4 pins. The 16 combinations don't come into play at
> > all; the board-specific mapping table would pick 1 single combination,
> > and represent this as:
> >
> > pin X: function = UART A TX
> > pin Y: function = UART A RX
> 
> We really do not expect per pin function mapping but per block function
> mapping.  That said, the UART driver is going to tell pinctrl subsystem
> "I'm UARTA, please set all my pins up for me".

That's fine; UART A can operate that way with pinctrl used as intended.

The way the pinctrl subsystem is defined is:

The SoC-specific pinctrl driver exposes the per-pin available functions.

The board-specific mapping table selects the function to use for each pin,
based on the board's requirements.

Any other way isn't fully consistent with the way pinctrl works. If we
do see a need for just a single per-board table rather than a separate
per-SoC table, and a per-board mapping table, we should rethink the
pinctrl subsystem...

> > Either way though, whether you put the data into tables in the driver or
> > in the SoC .dtsi file (included by each board's .dts file), the pinctrl
> 
> We are not going to list that into SoC .dtsi file.
> 
> > driver's table really should list all possible options, and the pinctrl
> > mapping table should select just one; that's kinda the whole point of
> > the tables. If you try to put just the used subset into device tree, you
> > won't be able to put it into the .dtsi file since it'll be
> > board-specific, and you'll end up forcing board .dts authors to recreate
> 
> That's what we are going to do.
> 
> > that driver's complete configuration table every time, which seems like
> > a lot of wasted work.

I re-iterate that point...

-- 
nvpublic

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