devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Guenter Roeck <linux@roeck-us.net>, Edward James <eajames@us.ibm.com>
Cc: andrew@aj.id.au, corbet@lwn.net, devicetree@vger.kernel.org,
	eajames.ibm@gmail.com, jdelvare@suse.com, joel@jms.id.au,
	linux-doc@vger.kernel.org, linux-hwmon@vger.kernel.org,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	mark.rutland@arm.com, robh+dt@kernel.org, wsa@the-dreams.de
Subject: Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface
Date: Tue, 10 Jan 2017 11:41:44 -0600	[thread overview]
Message-ID: <1484070104.21117.29.camel@kernel.crashing.org> (raw)
In-Reply-To: <8b182766-32a0-9eb1-7917-14abf811cef5@roeck-us.net>

On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote:
> > Instead of the "online" attribute, what do you think about using the
> > "bind"/"unbind" API to probe the device from user space once the system
> > is powered on? All the hwmon registration would take place in the probe
> > function, it would just occur some time after boot.
> > 
> 
> A more common approach would be to have a platform driver. That platform
> driver would need a means to detect if the OCC is up and running, and
> instantiate everything else once it is.
> 
> A trigger from user space is problematic because there is no guarantee
> that the OCC is really up (or that it even exists).
> 
> An alternative might be to have the hwmon driver poll for the OCC,
> but that would be a bit more difficult and might require a kernel thread
> or maybe asynchronous probing.

Hi Guenter !

I'm not sure I agree with you here ;-)

I'm don't know how much background you got (I missed the beginning of
the discussion) but basically this driver runs on the BMC (system
controller) of the POWER9 server, the OCC is inside the POWER9 chip
itself.

So the presence/power state of the OCC doesn't depend on the BMC
platform kernel code. The BMC userspace controls power up and down to the POWER9, and thus it's the one to know whether the remote is up.

If we were to create a "platform driver", all it would do is get input
from userspace exactly like that sysfs file :-)

So if you don't like the sysfs file that registers/de-registers, which
I sort-of understand, it's a bit of a hack (though a rather efficient
one), I think the bind/unbind approach makes sense. However, I wonder
whether the simplest and most efficient (remember this BMC has a really
slow CPU) is an "online" file sysfs file, though rather than
registering/de-registering the hwmon it would simply make it stop
accessing the HW (and return some known "offline" values).

Cheers,
Ben.


  parent reply	other threads:[~2017-01-10 17:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-30 17:56 [PATCH linux 0/6] drivers: hwmon: Add On-Chip Controller driver eajames.ibm
2016-12-30 17:56 ` [PATCH linux 1/6] hwmon: Add core On-Chip Controller support for POWER CPUs eajames.ibm
     [not found]   ` <1483120568-21082-2-git-send-email-eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-12-30 19:18     ` kbuild test robot
2016-12-30 17:56 ` [PATCH linux 2/6] hwmon: occ: Add sysfs interface eajames.ibm
2016-12-30 19:34   ` Guenter Roeck
2017-01-06 22:17     ` Edward James
2017-01-07 17:15       ` Guenter Roeck
2017-01-08 23:52         ` Andrew Jeffery
2017-01-10 17:45           ` Benjamin Herrenschmidt
2017-01-10 17:41         ` Benjamin Herrenschmidt [this message]
2017-01-10 17:51           ` Guenter Roeck
2017-01-10 23:01             ` Edward James
     [not found] ` <1483120568-21082-1-git-send-email-eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-12-30 17:56   ` [PATCH linux 3/6] hwmon: occ: Add I2C transport implementation for SCOM operations eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w
2016-12-30 17:56   ` [PATCH linux 4/6] hwmon: occ: Add callbacks for parsing P8 OCC datastructures eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w
2016-12-30 17:56   ` [PATCH linux 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC eajames.ibm-Re5JQEeQqe8AvxtiuMwx3w
2017-01-01  0:25     ` kbuild test robot
2017-01-03 22:45     ` Rob Herring
2016-12-30 17:56 ` [PATCH linux 6/6] hwmon: occ: Add callbacks for parsing P9 OCC datastructures eajames.ibm

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=1484070104.21117.29.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=andrew@aj.id.au \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=eajames.ibm@gmail.com \
    --cc=eajames@us.ibm.com \
    --cc=jdelvare@suse.com \
    --cc=joel@jms.id.au \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=wsa@the-dreams.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).