[PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

Ben Dooks ben.dooks at codethink.co.uk
Fri Sep 21 06:56:06 EDT 2012

On 20/09/12 20:36, Thomas Petazzoni wrote:
> 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.

I think this is a bad idea, it means you can't try and re-use an
older kernel on an newer SoC design which may be broadly compatible
without changing the kernel source to add these flag checks.

I also don't like information hidden away that the user cannot see.
Having the device specifically named allows us to see from sysfs
exactly what we are dealing with.

Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

More information about the linux-arm-kernel mailing list