[RFC PATCHv2 1/2] Export SoC info through sysfs
arnd at arndb.de
Thu Apr 7 17:29:23 EDT 2011
On Thursday 07 April 2011, Lee Jones wrote:
> On 11/03/11 22:13, Arnd Bergmann wrote:
> > On Friday 11 March 2011 23:03:33 Greg KH wrote:
> >> On Fri, Mar 11, 2011 at 10:42:43PM +0100, Arnd Bergmann wrote:
> >>> On Friday 11 March 2011 20:33:30 Greg KH wrote:
> >>>> Make this a "real" device not /sys/socinfo please. It can be a platform
> >>>> device that export the needed information, that way you can have
> >>>> multiple ones.
> >>> Note that the version 1 of this patch had a device, and I argued against
> >>> that patch on the basis that anything under /sys/devices/ should
> >>> reflect an actual part of the hardware, which socinfo by itself
> >>> does not.
> >> Why is the overall SoC not a device? cpus are (well, they will be in a
> >> few kernel versions in the future), so what makes the other bits somehow
> >> "special"?
> > The suggestion was to have a single disconnected device stuck
> > in /sys/devices/system/socinfo, and only have it there to
> > contain device attributes that can be collected from random
> > places in the system, such hardcoded board specific data,
> > or read from registers that belong to another device.
> > A real device IMHO would be one that has specific hardware
> > properties, such as its own set of device registers or other
> > devices that are attached to it and that are represented
> > as children of this device.
> Unfortunately, Maxime is extremely busy at the moment, so I have taken
> over to finally get this thing upstream. Just for clarification what's
> the final verdict on the location of this entry? Something that we can
> all agree on.
I'll try to capture the opinions from the other people as well,
hopefully this represents a consensus. Please correct me otherwise.
I believe the uncontroversial parts are:
* Make it not an entry but a device with certain properties.
* Make the naming so that you can have more than one of them.
* Put all devices on an SoC that uses this scheme underneath that
device by setting their parents to the SoC device.
For the location of the device, I have not seen a clear consensus yet,
but I'm fine with eihter of these:
For the implementation, I'd suggest adding an soc_device_register()
function that gets passed the necessary data and returns the struct device
that can then be used as the parent in all platform_device_register calls.
More information about the linux-arm-kernel