[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170911160449.GA11886@kroah.com>
Date: Mon, 11 Sep 2017 09:04:49 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Srishti Sharma <srishtishar@...il.com>
Cc: gilad@...yossef.com, linux-crypto@...r.kernel.org,
driverdev-devel@...uxdriverproject.org, devel@...verdev.osuosl.org,
linux-kernel@...r.kernel.org, outreachy-kernel@...glegroups.com
Subject: Re: [PATCH] Staging: ccree: Don't use volatile for monitor_lock
On Mon, Sep 11, 2017 at 09:29:31PM +0530, Srishti Sharma wrote:
> The use of volatile for the variable monitor_lock is unnecessary.
>
> Signed-off-by: Srishti Sharma <srishtishar@...il.com>
> ---
> drivers/staging/ccree/ssi_request_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/ccree/ssi_request_mgr.c b/drivers/staging/ccree/ssi_request_mgr.c
> index e5c2f92..7d77941 100644
> --- a/drivers/staging/ccree/ssi_request_mgr.c
> +++ b/drivers/staging/ccree/ssi_request_mgr.c
> @@ -49,7 +49,7 @@ struct ssi_request_mgr_handle {
> dma_addr_t dummy_comp_buff_dma;
> struct cc_hw_desc monitor_desc;
>
> - volatile unsigned long monitor_lock;
> + unsigned long monitor_lock;
While volatile is not right, odds are, this is still totally wrong as
well. How about using a "real" lock instead?
thanks,
greg k-h
Powered by blists - more mailing lists