Re: sysfs for my chips

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.