[PATCH 2/3] mach-ux500: export System-on-Chip information via sysfs

[lee.jones@linaro.org (Lee Jones)]

On 13/07/11 14:42, Arnd Bergmann wrote:
> On Wednesday 13 July 2011, Lee Jones wrote:
>> Okay, obviously I'm missing something. I am trying to adhere to your
>> advice, but there must be some communication break-down somewhere down
>> the line. Let me attempt to explain what's going on in my head.
>>
>> You keep asking for the SoC devices to be children of the parent SoC
>> device and as far as I'm concerned they are. Devices appear like this in
>> sysfs:
>>
>> /sys/devices/soc/1   /* 1st SoC */
>> /sys/devices/soc/2   /* 2nd SoC */
>> /sys/devices/soc/3   /* 3rd SoC */
>>
>> etc ...
>>
>> Surely the parent which you speak of is "soc" and each SoC is
>> represented by "1|2|3|..."? Under each directory with a digit naming
>> convention appears that SoC's attributes, namely: "family", "machine",
>> "process", "revision" and "soc_id".
>>
>> If this is incorrect, would you be kind enough to tell me why its
>> incorrect and how you would like it changed/fixed please?
>>
> 
> I'm not talking of the root soc devices but the platform_devices that
> are part of the soc, i.e. interrupt controller, i2c bus, mmc host,
> etc.
> 
> Basically all the devices that are currently statically declared
> in arch/arm/mach-ux500/board-mop500.c and are missing a parent pointer.
> 
> What I'm asking you to do is fix those device declarations to have
> their .dev.parent pointer point to the correct soc device. If there
> are nested buses, they should ideally also be represented as devices
> so you end up with something like
> 
> /sys/devices/soc/1/amba/uart1
>                        /uart2
>                        /i2c/bus1
>                            /bus2/tc35892
>                                 /lp5521
>                        /spi/foo
>                            /bar
>                   /dma
>                 /2/amba/...
> 
> Basically, if you have a soc node, I would expect /sys/devices/platform to
> become empty, and all devices properly parented to where they are actually
> connected.


Ahhhh, well why didn't you say so? I've been racking my brains about
this for ages.:)

Does this have to be coded and submitted with this patch-set? Is there
any way we can accept this one and I'll take this reorganisation of
platform drivers as an action to be completed when I have some more
spare cycles?