@@ -46,18 +46,27 @@ int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data)
mutex_lock(&opal_sensor_mutex);
ret = opal_sensor_read(sensor_hndl, token, &data);
- if (ret != OPAL_ASYNC_COMPLETION)
- goto out_token;
+ switch (ret) {
+ case OPAL_ASYNC_COMPLETION:
+ ret = opal_async_wait_response(token, &msg);
+ if (ret) {
+ pr_err("%s: Failed to wait for the async response, %d\n",
+ __func__, ret);
+ goto out_token;
+ }
- ret = opal_async_wait_response(token, &msg);
- if (ret) {
- pr_err("%s: Failed to wait for the async response, %d\n",
- __func__, ret);
- goto out_token;
- }
+ ret = be64_to_cpu(msg.params[1]);
+
+ *sensor_data = be32_to_cpu(data);
+ break;
- *sensor_data = be32_to_cpu(data);
- ret = be64_to_cpu(msg.params[1]);
+ case OPAL_SUCCESS:
+ *sensor_data = be32_to_cpu(data);
+ break;
+
+ default:
+ break;
+ }
out_token:
mutex_unlock(&opal_sensor_mutex);
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. However, some sensors can be read synchronously (core temperatures for instance) and don't need to wait for a response. This patch modifies the opal call to accept an OPAL_SUCCESS return value and not wait for a response if this is the case. But, 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. Signed-off-by: Cédric Le Goater <clg@fr.ibm.com> --- arch/powerpc/platforms/powernv/opal-sensor.c | 29 +++++++++++++++++--------- 1 file changed, 19 insertions(+), 10 deletions(-)