[Skiboot] [RFC] occ: Add support for OCC inband sensors

Shilpasri G Bhat shilpa.bhat at linux.vnet.ibm.com
Fri Mar 10 18:20:22 AEDT 2017


Hi,

On 03/10/2017 05:54 AM, Stewart Smith wrote:
> Andrew Jeffery <andrew at aj.id.au> writes:
>> On Thu, 2017-03-09 at 13:44 +0100, Cédric Le Goater wrote:
>>> Hello Shilpasri,
>>>
>>> Thanks for the write up on the OCC sensors. Nice and detailed.
>>>
>>> On the overall design, I think this is exposing too much HW details 
>>> to Linux. I am not sure Linux should even know about OCC or where
>>> the sensors are coming from. Even if this is doable, I would not 
>>> let the kernel loop on the OCC data to collect which sensors are
>>> available. What is being done under :
>>>
>>> 	arch/powerpc/platforms/powernv/opal-occ-sensors.c
>>>
>>> in the Linux driver should be in the firmware IHMO. 
>>>
>>> skiboot should hide the gory details and expose in the device 
>>> tree sensor nodes collected from the different available sources: 
>>> FSP, BMC, OCC, DTS, etc. 
>>>
>>> There is a framework in place in skiboot for that, which may be, 
>>> needs some tuning to add OCC support. But the good thing about it, 
>>> is that the Linux driver comes for free in *all* Linux distros now.
>>
>> I spoke with Stewart a while back about how we should expose sensors to
>> Linux and we reached the same conclusions as Cedric. Lets keep the OCC
>> details contained in the firmware.
> 
> Yep. OCC is merely an implementation detail.
> 
> I'd argue that all sensors should be readable through the OPAL calls. As
> an optimisation, we could add the ability for some opal sensors to be
> read directly from an address by the kernel.
> 
> But yeah, for these sensors, existing kernels should "just work" by
> using the existing OPAL calls.
> 

Yes. I completely agree that the sensors should be exported in device tree. I
will send out a patch for the same in the next iteration.

But there are couple of concerns which this patch is trying to address:

1) If we end up exporting all sensors as device tree nodes then we will bloat
the device tree with 450 sensors per OCC. And it will also increase the OPAL
boot time.

2) Apart from the min/max for each sensor OCC provides three different min/max
which can be reset at runtime. I am not sure if it is a right way to create new
nodes for each min/max per sensor.

Thanks and Regards,
Shilpa



More information about the Skiboot mailing list