Guenter Roeck [off-list ref] wrote on 01/10/2017 11:51:12 AM:

From: Guenter Roeck <linux@roeck-us.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Edward James/Austin/IBM@IBMUS, 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
Date: 01/10/2017 11:51 AM
Subject: Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface

On Tue, Jan 10, 2017 at 11:41:44AM -0600, Benjamin Herrenschmidt wrote:

quoted

On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote:

quoted

quoted

Instead of the "online" attribute, what do you think about using

the

quoted

quoted

quoted

"bind"/"unbind" API to probe the device from user space once the

system

quoted

quoted

quoted

is powered on? All the hwmon registration would take place in the

probe

quoted

quoted

quoted

function, it would just occur some time after boot.

A more common approach would be to have a platform driver. That

platform

quoted

quoted

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

quoted

quoted

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

quoted

quoted

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.

quoted

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).

I don't like that too much either; it still looks like a hack.
How about using bind/unbind then ?

Bind/unbind works very well in testing. Only thing we have to figure out is
how to stop the driver loading during BMC boot... but I don't think the
solution will be in this patch set. I'll put together a v2 for tomorrow.

Thanks,
Eddie

Guenter