linux-kernel - Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

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: <20120920213636.2ee27d41@skate>
Date:	Thu, 20 Sep 2012 21:36:36 +0200
From:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Andrew Lunn <andrew@...n.ch>,
	Russell King <linux@....linux.org.uk>,
	Jason Cooper <jason@...edaemon.net>,
	Stephen Warren <swarren@...dotorg.org>,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Lior Amsalem <alior@...vell.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Rob Landley <rob@...dley.net>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>
Subject: Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

Dear Linus Walleij,

On Thu, 20 Sep 2012 21:28:20 +0200, Linus Walleij wrote:

> So what I'm after is whether in this case statically encoding this
> onto the .dtsi files is the right thing to do, or whether the boot loader
> or kernel should runtime-modify the device tree, patching in
> the ASIC-specific info, just like device tree files can override
> properties from include files.
> 
> Or if this is a bad idea.
> 
> Nobody is doing that right now AFAICT, but it is surely possible....

If I understand correctly, we would like drivers to be able to read
some common "system" registers to figure out which SoC variant we are
running on. Such feature should normally be provided by code in
arch/arm/mach-*/ and called by drivers, but we are trying to eliminate
all dependencies of driver code on architecture code, correct?

So, wouldn't we need a small, architecture-independent, infrastructure,
through which architecture-specific code could "register" at boot
time which SoC we are running on, and drivers could query this
information from the common infrastructure?

Of course, the major problem is to figure out what is the good
representation for this SoC identifier. Do we need a big list of SoCs
like we had machine IDs? A simple string? Or maybe there is just no
good way, and the whole idea is moot.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/