[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <170203d2-c24e-3154-042d-fd8473767207@quicinc.com>
Date: Wed, 22 May 2024 22:40:33 -0700
From: "Bao D. Nguyen" <quic_nguyenb@...cinc.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
CC: Bart Van Assche <bvanassche@....org>, <quic_cang@...cinc.com>,
<quic_nitirawa@...cinc.com>, <avri.altman@....com>,
<beanhuo@...ron.com>, <adrian.hunter@...el.com>,
<martin.petersen@...cle.com>, <linux-scsi@...r.kernel.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
"James
E.J. Bottomley" <jejb@...ux.ibm.com>,
Stanley Chu <stanley.chu@...iatek.com>,
Peter Wang <peter.wang@...iatek.com>,
Po-Wen Kao <powen.kao@...iatek.com>,
Maramaina Naresh <quic_mnaresh@...cinc.com>,
open list
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 1/2] scsi: ufs: core: Support Updating UIC Command
Timeout
On 5/22/2024 9:38 PM, Manivannan Sadhasivam wrote:
> On Wed, May 22, 2024 at 01:51:06PM -0700, Bao D. Nguyen wrote:
>> On 5/22/2024 11:16 AM, Bart Van Assche wrote:
>>> On 5/22/24 00:01, Bao D. Nguyen wrote:
>>>> interrupt starvations happen occasionally because the uart may
>>>> print long debug messages from different modules in the system.
>>>
>>> I think that's a bug in the UART driver that should be fixed in the
>>> UART driver.
>>
>> Thanks Bart.
>> I am not familiar with the UART drivers. I looked at some UART code and it
>> could be interpreted as their choice of implementation.
>> During product development, the UART may be used. However, when the
>> development completes, most likely the UART logging is disabled due to
>> performance reason.
>>
>> This change is to give flexibility to the SoCs to use the UART
>> implementation of their choice and to choose the desired UIC command timeout
>> without affecting the system stability or the default hardcoded UIC timeout
>> value of 500ms that others may be using.
>>
>
> If UART runs in atomic context for 500ms, then it is doomed.
>
> But for increasing the UIC timeout, I agree that the flexibility is acceptable.
> In that case, please use a user configurable option like cmdline etc... instead
> of hardcoding the value in glue drivers.
Thanks Mani. Bart also suggested something along that line.
Thanks, Bao
>
> - Mani
>
Powered by blists - more mailing lists