linux-kernel - Re: [RFC PATCH 2/3] pinctrl: imx: add pinmux-imx53 support

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: <20111206080544.GF4585@pengutronix.de>
Date:	Tue, 6 Dec 2011 09:05:44 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Shawn Guo <shawn.guo@...escale.com>
Cc:	Lothar Waßmann <LW@...O-electronics.de>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linus.walleij@...ricsson.com,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org, kernel@...gutronix.de,
	Dong Aisheng <b29396@...escale.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 2/3] pinctrl: imx: add pinmux-imx53 support

Hi,

On Tue, Dec 06, 2011 at 08:33:28AM +0100, Lothar Waßmann wrote:
> Shawn Guo writes:
> > On Mon, Dec 05, 2011 at 10:18:38PM +0100, Sascha Hauer wrote:
> > > Freescale has named the pins after their primary function which is quite
> > > confusing.
> > > 
> > > The above means:
> > > 
> > > MX53_PATA_DATA8 -> mux mode 4
> > > MX53_PATA_DATA9 -> mux mode 4
> > > ...
> > > 
> > > This brings me to the point that currently we have the pins described as
> > > 
> > > #define MX53_PAD_<name>__<function>
> > > 
> > But that's also the reason why we have so many lengthy iomux-mx*.h on
> > imx.  Taking iomux-mx53.h for example, it's a 109K header with 1219
> > LOC, but probably only 10% of the definitions will actually be used.
> > 
> Which has the benefit of having correct pin definitions for everyone
> to use. If developers who need to use currently unused pindefs have to
> create them on their own, there will always be a good chance in
> getting them wrong.
Another upside is, that adding the complete list once doesn't result in
conflicts if two people add new definitions in the same timeframe. As
the header are only cpp symbols that don't hurt at runtime I think
having them complete is better than the incremental approach.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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/