[PATCH] powerpc/powernv : Add support to enable sensor groups

[Guenter Roeck]

On Tue, Mar 13, 2018 at 10:02:09PM +1100, Michael Ellerman wrote:
> Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com> writes:
> > On 12/04/2017 10:11 AM, Stewart Smith wrote:
> >> Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com> writes:
> >>> On 11/28/2017 05:07 PM, Michael Ellerman wrote:
> >>>> Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com> writes:
> >>>>
> >>>>> Adds support to enable/disable a sensor group. This can be used to
> >>>>> select the sensor groups that needs to be copied to main memory by
> >>>>> OCC. Sensor groups like power, temperature, current, voltage,
> >>>>> frequency, utilization can be enabled/disabled at runtime.
> >>>>>
> >>>>> Signed-off-by: Shilpasri G Bhat <shilpa.bhat at linux.vnet.ibm.com>
> >>>>> ---
> >>>>> The skiboot patch for the opal call is posted below:
> >>>>> https://lists.ozlabs.org/pipermail/skiboot/2017-November/009713.html
> >>>>
> >>>> Can you remind me why we're doing this with a completely bespoke sysfs
> >>>> API, rather than using some generic sensors API?
> >>>
> >>> Disabling/Enabling sensor groups is not supported in the current generic sensors
> >>> API. And also we dont export all type of sensors in HWMON as not all of them are
> >>> environment sensors (like performance).
> >> 
> >> Are there barriers to adding such concepts to the generic sensors API?
> >
> > Yes.
> >
> > HWMON does not support attributes for a sensor-group. If we are to extend HWMON
> > to add new per-sensor attributes to disable/enable, then we need to do either of
> > the below:
> >
> > 1) If any one of the sensor is disabled then all the sensors belonging to that
> > group will be disabled. OR
> >
> > 2) To disable a sensor group we need to disable all the sensors belonging to
> > that group.
> 
> Either of those sound doable, the first is probably simpler, as long as
> there's some way for userspace to understand that it is modifying the
> state of the whole group.
> 
> > Another problem is hwmon categorizes the sensor-groups based on the type of
> > sensors like power, temp. If OCC allows multiple groups of the same type then
> > this approach adds some more complexity to the user to identify the sensors
> > belonging to correct group.
> 
> I don't really understand this one, what do you mean by "If OCC allows"?
> 
> Also do we really expect users to be using this API? Or rather tools?
> 
> > And lastly HWMON does not allow platform specific non-standard sensor groups
> > like CSM, job-scheduler, profiler.
> 
> Have we actually made specific proposals to the hwmon maintainers on
> adding/changing any of the above? Have they rejected those proposals and
> told us to go away?
> 
Those don't really sound like sensor groups at all. What does "job-scheduler"
or "profiler" have to do with hardware monitoring ? We do allow additional
attributes if it makes sense, but those should be hardware monitoring related.
We also allow registration with other subsystems (such as gpio) if a hardware
monitoring device also has gpio pins and it seems to cumbersome to request
that an mfd driver is written. However, I am not convinced that completely
unrelated attributes should be handled through the hwmon subsystem; if this
is deemed necessary, it rather seems that hardware monitoring is one of many
functionalities of a given chip, and such functionality should be handled
elsewhere.

For the rest (enabling or disabling sensors dynamically), I am not specifically
opposed to improving the hwmon core to add such support, but someone would have
to make a specific proposal. One key problem is that the hwmon API assumes
'static' sensor allocation. The behavior of sensors appearng or disappearing
at runtime (even though it happens) is not well defined. Any proposal along
that line will need to ensure that userspace behavior is well documented.

Thanks,
Guenter