linux-kernel - Re: [PATCH v1 1/2] scsi: ufs: core: Support Updating UIC Command Timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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
>