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 <c...@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 <c...@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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
