lkml.org 
[lkml]   [2012]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver
From
On Thu, Sep 20, 2012 at 5:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:

> A corner case is the one where you have different versions of the same
> IP block (e.g. the pinctrl) and the kernel cannot find out which one it
> is by looking at registers inside it or on the parent bus, but only
> by looking at other hardware (CPU core revision, or PCI device ID of
> the root complex).

So this is the case I'm thinking of. We have e.g. differens small flags
through platform data depending on cpu_is_ux* in the ux500.

Currently we modify platform data in the board files, just as we
switch some cache handling etc as we know this or that
ASIC has different sized cache.

> We have a precedent of at91 doing this, but I don't
> like it too much because that still means having to change the driver
> again if you get a new SoC with the same IP block but a different version
> register,

I don't like that either.

> To avoid that, I'd prefer using separate "compatible"
> values, at least if the hardware is already described in separate .dtsi
> files.

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

Yours,
Linus Walleij


\
 
 \ /
  Last update: 2012-09-20 22:01    [W:0.340 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site