[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <32c122e6-d87d-307b-72c8-a0ac74c42602@acm.org>
Date: Wed, 4 Jan 2023 14:34:11 -0800
From: Bart Van Assche <bvanassche@....org>
To: Avri Altman <Avri.Altman@....com>,
Johan Hovold <johan+linaro@...nel.org>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>
Cc: Alim Akhtar <alim.akhtar@...sung.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Can Guo <quic_cang@...cinc.com>
Subject: Re: [PATCH] scsi: ufs: core: fix devfreq deadlocks
On 1/3/23 00:24, Avri Altman wrote:
>
>> On 12/22/22 02:21, Johan Hovold wrote:
>>> + /* Enable Write Booster if we have scaled up else disable it */
>>> + if (ufshcd_enable_wb_if_scaling_up(hba))
>>> + ufshcd_wb_toggle(hba, scale_up);
>>
>> Hi Asutosh,
>>
>> This patch is the second complaint about the mechanism that toggles the
>> WriteBooster during clock scaling. Can this mechanism be removed entirely?
> commit 87bd05016a64 that introduced UFSHCD_CAP_WB_WITH_CLK_SCALING enables
> the platform vendors and OEMs to maintain wb toggling - should they choose so.
> Why remove it in its entirety?
Hi Avri,
I'm in favor of keeping kernel code simple :-)
UFSHCD_CAP_WB_WITH_CLK_SCALING controls whether or not clock scaling
affects the WriteBooster depending on which host controller is in use.
Shouldn't this depend on which UFS device is present instead of on the
type of host controller?
Thanks,
Bart.
Powered by blists - more mailing lists