[PATCH 2/3] mach-ux500: export System-on-Chip information via sysfs
Lee Jones
lee.jones at linaro.org
Wed Jul 13 10:31:26 EDT 2011
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?
More information about the linux-arm-kernel
mailing list