[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1cb4db5f707692afedb005e2577f667f5e48e66e.camel@gmail.com>
Date: Tue, 15 Feb 2022 12:00:00 +0100
From: Bean Huo <huobean@...il.com>
To: Kiwoong Kim <kwmad.kim@...sung.com>,
'Adrian Hunter' <adrian.hunter@...el.com>,
'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, 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.
On Sat, 2022-02-12 at 13:44 +0900, Kiwoong Kim wrote:
> > The error handler really should have exclusive access. One of the
> > places
> > you change does explain that:
> >
> > * Hold the scaling lock just in case dev cmds
> > * are sent via bsg and/or sysfs.
> > */
> > - down_write(&hba->clk_scaling_lock);
> > + if (ufshcd_is_clkscaling_supported(hba))
> > + down_write(&hba->clk_scaling_lock);
>
> Yeah.., I saw the comment but didn't get why.
>
> Is there anyone who knows why it's necessary for all SoCs?
> At lease, I know there is no reason to forbid concurrent executions
> of dev cmd and power mode change.
>
> If there's nothing, how about adding a quick to ignore it?
>
> Thanks.
> Kiwoong Kim
>
The name of clk_scaling_lock has explained everything, for the platform
which doesn't support load-based clk scaling, doesn't need to hold this
lock.
Acked-by: Bean Huo <beanhuo@...ron.com>
Powered by blists - more mailing lists