Received-SPF: pass (google.com: domain of linux-kernel+bounces-187011-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <170203d2-c24e-3154-042d-fd8473767207@quicinc.com>
Date: Wed, 22 May 2024 22:40:33 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [PATCH v1 1/2] scsi: ufs: core: Support Updating UIC Command
 Timeout
Content-Language: en-US
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
CC: Bart Van Assche <bvanassche@acm.org>, <quic_cang@quicinc.com>,
        <quic_nitirawa@quicinc.com>, <avri.altman@wdc.com>,
        <beanhuo@micron.com>, <adrian.hunter@intel.com>,
        <martin.petersen@oracle.com>, <linux-scsi@vger.kernel.org>,
        Alim Akhtar <alim.akhtar@samsung.com>,
        "James
 E.J. Bottomley" <jejb@linux.ibm.com>,
        Stanley Chu <stanley.chu@mediatek.com>,
        Peter Wang <peter.wang@mediatek.com>,
        Po-Wen Kao <powen.kao@mediatek.com>,
        Maramaina Naresh <quic_mnaresh@quicinc.com>,
        open list
	<linux-kernel@vger.kernel.org>
References: <cover.1716359578.git.quic_nguyenb@quicinc.com>
 <292d7702e946ca513af51236ca9e38bf1b1eb269.1716359578.git.quic_nguyenb@quicinc.com>
 <cb05bc3f-5fb0-45aa-961b-bb9edc007407@acm.org>
 <d4d7ac49-1055-5305-99b5-af8e1428c746@quicinc.com>
 <20240523043828.GA5758@thinkpad>
From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
In-Reply-To: <20240523043828.GA5758@thinkpad>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

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
>