Messages in this thread | | | Subject | Re: sysfs for my chips | From | Benjamin Herrenschmidt <> | Date | Fri, 11 Oct 2013 08:30:51 +1100 |
| |
On Thu, 2013-10-10 at 22:26 +0200, Geert Uytterhoeven wrote: > > This is not CPUs. CPUs are threads really. Even if they were cores, > that > > still wouldn't cut it. I'm looking at chips here and not all of them > > actually processor chips. The SCOM bus address space is global to a > > physical chip and allows to access various resources that are only > > remotely related to the cores on it. > > What about a "bus" for the sideband bus? That allows to decouple it > from cores, and allows to support non-processor chips, too?
Not sure what you mean .... create a linux bus type with devices on it ?
That's really overkill I think... doable though.
I think sysdev, despite my previous qualms, might be the best way... we could have a "driver" in the form of the actual code that provide that sideband bus access. Right now the platform registers a single global "scom controller", we could make a sysdev instead with an instance per "chip" I suppose...
Though there's still some kind of namespace issue, if I start creating something like /sys/devices/system/chip/<id>/... but ...
That means doing something very platform specific in a location that is very "generic" with a name that's likely to clash with something else later on unless we start introducing a standard concept of "chip" with associated properties but what do that really mean ? With things like DCMs etc... the concept of "chip" is blurry at best.
Also what about other chips that do not participate in that xscom/scom sideband mechanism ? like PCIe device chips, or other random stuff on the mobo ?
I'm trying to solve a very specific problem here, which is to provide a userspace scom access interface. I was trying to avoid a /dev/scom because I would need 32-bit minors or do ioctls and because it seemed simpler to just put it in sysfs somewhere but maybe that won't fly.
A last option is to put it in /sys/firmware/opal (OPAL is our firmware name). Under there, I can put a lot of stuff that's essentially firmware/platform specific. However our "scom" infrastructure is somewhat generic and is used by at least one platform that isn't using OPAL (though arguably that platform is dead: wsp).
Cheers, Ben.
| |