linux-kernel - Re: sysfs for my chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Oct 2013 08:30:51 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Greg KH <gregkh@...uxfoundation.org>, Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: sysfs for my chips

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/