[PATCH] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read

[Cedric Le Goater]

On 03/26/2015 10:44 AM, Cedric Le Goater wrote:
> On 03/26/2015 12:07 AM, Stewart Smith wrote:
>> Cédric Le Goater <clg at fr.ibm.com> writes:
>>> Currently, when a sensor value is read, the kernel calls OPAL, which in
>>> turn builds a message for the FSP, and waits for a message back. 
>>>
>>> The new device tree for OPAL sensors [1] adds new sensors that can be 
>>> read synchronously (core temperatures for instance) and that don't need 
>>> to wait for a response.
>>>
>>> This patch modifies the opal call to accept an OPAL_SUCCESS return value
>>> and cover the case above.
>>>
>>> [1] https://lists.ozlabs.org/pipermail/skiboot/2015-March/000639.html
>>>
>>> Signed-off-by: Cédric Le Goater <clg at fr.ibm.com>
>>> ---
>>>
>>>  We still uselessly reserve a token (for the response) and take a
>>>  lock, which might raise the need of a new 'opal_sensor_read_sync' 
>>>  call.
>>
>> Actually.... why do we take a lock around the OPAL calls at all?
> 
> The sensor service in OPAL only handles one FSP request at a time and 
> returns OPAL_BUSY if one is already in progress. The lock covers this case 
> but we could also remove it return EBUSY to the driver or even retry the 
> call. That might be dangerous though. 
> 
> Changing OPAL to handle simultaneously multiple requests does not seem really 
> necessary, it won't speed up the communication with the FSP and that is the
> main bottleneck.

opal_get_sensor_data() is mixing OPAL return codes and errnos. I will send
a v2 addressing this problem first.

C.