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

On 03/26/2015 12:07 AM, Stewart Smith wrote:

Cédric Le Goater [off-list ref] writes:

quoted

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 <redacted>
---

 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.

C.