Introduce the /proc/socinfo and use it to export OMAP data
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v5 Latest posting 3/30 of 3 patches 0 repliesNew
- v5 posting 2/30 of 3 patches 0 repliesSuperseded
- v5 posting 1/30 of 3 patches 0 repliesSuperseded
Patches in v5 posting 3/3 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v5 yet.
Cover letter [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Quoted 18 lines · Maxime Coquelin
Quoted 11 lines · Linus Walleij
Quoted 5 lines · Maxime Coquelin
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 machsArbitrary 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 :
Quoted 4 lines
/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
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.