[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Saravana Kannan
skannan at codeaurora.org
Thu Mar 3 00:55:39 EST 2011
On 03/02/2011 02:53 AM, Maxime Coquelin wrote:
> On 03/02/2011 11:36 AM, Linus Walleij wrote:
>> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
>> <maxime.coquelin-nonst at stericsson.com> wrote:
>>
>>> I think we should have a tree like this :
>>>
>>> /sys/devices/system/soc/
>>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for
>>> all machs
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have
>> 32-bit
>> etc.
>
> Yes, here is the difficulty. For example, in our case, the SoC unique ID
> is 160 bits long.
> Maybe it would be a better solution to get rid of this unified file, and
> keep only mach specific entries? I mean :
>
> /sys/devices/system/soc/
> /sys/devices/system/soc/mach_name
> /sys/devices/system/soc/foo_id
> /sys/devices/system/soc/bar_id
Sorry for the late reply guys. Got wrapped up is some other stuff.
I'm with Maxime on getting rid of the unique id file. It's not as if
it's unique across all machs and archs. Any user space caring to look at
the id will anyway have to check the mach/family first. So, there is no
point in having this unique id file. It just adds more weirdness and
complexity to deal with the different formats or ways each family wants
to export the id. Actually, in the case of MSM, we don't have any need
to export unique id. We just want to export what type of soc it is
within the MSM family.
As for the path, it's not clear we have settled on the final path. I see
us ping-pong between /sys/devices/system/soc/ and
/sys/devices/system/soc/mach/. Can we drop the "mach" subdir? Seems
pointless.
The mandatory file, I would like to call it "family", since "mach" is
too specific (omap3 and omap4 is my usual example -- they can have one
implementation of socinfo and report the family as "omap"). We don't
want people to misunderstand "mach" to be an accurate representation of
the xxxx in mach-xxxx.
The patch that adds this should probably allow each socinfo
implementation to specify the family name and an array of attributes
(struct attribute *) that can be used to expose whatever else they want
to export.
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
More information about the linux-arm-kernel
mailing list