[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bdd52dc0-85dd-4000-b5dd-c2c22f5b8ba1@acm.org>
Date: Wed, 22 May 2024 14:01:49 -0700
From: Bart Van Assche <bvanassche@....org>
To: "Bao D. Nguyen" <quic_nguyenb@...cinc.com>, quic_cang@...cinc.com,
quic_nitirawa@...cinc.com, avri.altman@....com, beanhuo@...ron.com,
adrian.hunter@...el.com, martin.petersen@...cle.com
Cc: linux-scsi@...r.kernel.org, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"open list:ARM/QUALCOMM SUPPORT" <linux-arm-msm@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 2/2] scsi: ufs: qcom: Update the UIC Command Timeout
On 5/22/24 13:56, Bao D. Nguyen wrote:
> On 5/22/2024 11:18 AM, Bart Van Assche wrote:
>> Since the described issue is only encountered during development, why to
>> modify the UIC command timeout unconditionally?
>
> The vendors can enjoy the default 500ms UIC timeout if they prefer.
> As long as they don't write to hba->uic_cmd_timeout in the vendor's initialization routine, the default value of 500ms will be used.
Since this issue is not vendor specific, I think it would be better to
modify the UFSHCI core driver only. Has it been considered to introduce a
kernel module parameter for setting the UIC command timeout instead of the
approach of this patch? As you probably know there are multiple mechanisms
for specifying kernel module parameters, e.g. the bootargs parameter in the
device tree.
Thanks,
Bart.
Powered by blists - more mailing lists