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] [thread-next>] [day] [month] [year] [list]

Date: Thu, 23 May 2024 10:08:28 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: "Bao D. Nguyen" <quic_nguyenb@...cinc.com>
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 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.

- Mani

-- 
மணிவண்ணன் சதாசிவம்