From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e06smtp17.uk.ibm.com (e06smtp17.uk.ibm.com [195.75.94.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 660551A0151 for ; Thu, 26 Mar 2015 23:58:48 +1100 (AEDT) Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 26 Mar 2015 12:58:44 -0000 Message-ID: <5514027D.8010501@fr.ibm.com> Date: Thu, 26 Mar 2015 13:58:37 +0100 From: Cedric Le Goater MIME-Version: 1.0 To: Stewart Smith , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read References: <1427305834-6737-1-git-send-email-clg@fr.ibm.com> <5513D514.1000504@fr.ibm.com> In-Reply-To: <5513D514.1000504@fr.ibm.com> Content-Type: text/plain; charset=utf-8 Cc: Neelesh Gupta , skiboot@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 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 >>> --- >>> >>> 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.