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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 10 Oct 2013 10:44:57 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	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, Oct 10, 2013 at 03:19:48PM +1100, Benjamin Herrenschmidt wrote:
> Hi Greg !
> 
> (random CC list of clueful people)
> 
> On some new powerpc platforms (non-hypervisor or rather linux is the
> hypervisor), I want to expose a bunch of stuff per "chip", the chips
> being currently the processor chips and the "centaurs" (think of them as
> the bottom half of the memory controllers).
> 
> Among other, I want a sysfs file in there to access "xscom" on the chip
> which is a sideband bus used for low level stuff (think jtag on steroid)
> which we can use, among others, for chip health monitoring, general
> debugging and diagnostics, etc...
> 
> I might add more such as VPD, model information, etc... later or at
> least a link to corresponding device-tree node.

So a mixture of things that traditionally have been in /proc/cpuinfo?

I've always wanted to see the cpuinfo files turn into sysfs files, so
that tools can parse them "properly" and not have to do different things
on different arches, like the proc/cpuinfo file is today (a mess).

> How do you suggest I expose that ? So far I've been thinking about
> something like
> 
> 	/sys/chips/{processor,centaur}/chip#/files
> 
> or to avoid namespace clashes
> 
> 	/sys/firmware/chips/{processor,centaur}/chip#/files
> 
> Or maybe just
> 
> 	/sys/firmware/chips/chip#/files
> 
> (the chip type can be inferred from the chip#, they use the same space
> at least as far my firmware exposes them to Linux)
> 
> (the actual access to xscom goes via firmware tho it makes *some* sense)
> 
> But I could instead create platform devices corresponding to the
> device-tree representation of each of those chips ... and have the
> platform devices contain the magic attributes. That's a bit more
> convoluted though.

We already create platform devices for the cpus in the system in
/sys/devices/system/, so can you just hang the attribute files off of
those platform devices?

And system devices seem like the correct thing for your "chips" that are
not cpus, right?

thanks,

greg k-h
--
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/