[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <007101d81eed$4d120a60$e7361f20$@samsung.com>
Date: Fri, 11 Feb 2022 11:15:55 +0900
From: "Kiwoong Kim" <kwmad.kim@...sung.com>
To: "'Avri Altman'" <Avri.Altman@....com>,
<linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<alim.akhtar@...sung.com>, <jejb@...ux.ibm.com>,
<martin.petersen@...cle.com>, <beanhuo@...ron.com>,
<cang@...eaurora.org>, <adrian.hunter@...el.com>,
<sc.suh@...sung.com>, <hy50.seo@...sung.com>,
<sh425.lee@...sung.com>, <bhoon95.kim@...sung.com>,
<vkumar.1997@...sung.com>
Subject: RE: [PATCH v1] scsi: ufs: remove clk_scaling_lock when clkscaling
isn't supported.
> > I think it looks hardware specific.
> > If the feature isn't supported, I think there is no reasonto prevent
> > from
> ^^^
> reason to
>
> > running other functions, such as ufshcd_queuecommand and
> It is no longer used in queuecommand since 5675c381ea51 and 8d077ede48c1
Yeah, you're right. It's just an example. I just want to tell that the lock also protects things that are not related with clk scaling directly.
>
> > ufshcd_exec_dev_cmd, concurrently.
> >
> > So I add a condition at some points protecting with clk_scaling_lock.
> But you still need a way to serialize device management commands.
>
> Thanks,
> Avri
The dev cmd execution period is protected by mutex.
And actual ringing a doorbell is protected by spin lock.
Is there another reason to need clk_scaling_lock even with it?
Thanks.
Kiwoong Kim
Powered by blists - more mailing lists