All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: sysfs for my chips
Date: Thu, 10 Oct 2013 15:19:48 +1100	[thread overview]
Message-ID: <1381378788.4330.30.camel@pasglop> (raw)

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.

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.

What's the current trend of the day for that sort of thing ? I'd rather
avoid yet-another-chardev-with-ioctl's here ...

Cheers,
Ben.



             reply	other threads:[~2013-10-10  4:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-10  4:19 Benjamin Herrenschmidt [this message]
2013-10-10  7:03 ` [PATCH] sysfs/bin: Fix size handling overflow for bin_attribute Benjamin Herrenschmidt
2013-10-10 17:38   ` Greg KH
2013-10-10 17:40     ` Greg KH
2013-10-10 20:02       ` Benjamin Herrenschmidt
2013-10-10 17:44 ` sysfs for my chips Greg KH
2013-10-10 20:01   ` Benjamin Herrenschmidt
2013-10-10 20:26     ` Geert Uytterhoeven
2013-10-10 21:30       ` Benjamin Herrenschmidt
2013-10-11  6:52         ` Geert Uytterhoeven
2013-10-11  9:06           ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1381378788.4330.30.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.