On Wed, Jun 11, 2025 at 10:40:10AM -0600, Keith Busch wrote: > On Wed, Jun 11, 2025 at 09:58:59PM +0530, Manivannan Sadhasivam wrote: > > On Mon, Apr 14, 2025 at 06:11:44PM -0600, Keith Busch wrote: > > > On Tue, Feb 18, 2025 at 08:54:44AM -0800, Keith Busch wrote: > > > > From: Keith Busch <kbusch@xxxxxxxxxx> > > > > > > > > The spec does not provide any upper limit to how long a device may > > > > return Request Retry Status. It just says "Some devices require a > > > > lengthy self-initialization sequence to complete". The kernel > > > > arbitrarily chose 60 seconds since that really ought to be enough. But > > > > there are devices where this turns out not to be enough. > > > > > > > > Since any timeout choice would be arbitrary, and 60 seconds is generally > > > > more than enough for the majority of hardware, let's make this a > > > > parameter so an admin can adjust it specifically to their needs if the > > > > default timeout isn't appropriate. > > > > > > This patch is trying to address timings that have no spec defined > > > behavior, so making it user tunable sounds just more reasonable than a > > > kernel define. If we're not considering upstream options to make this > > > tunable, I think we have no choice but to continue with bespoke > > > out-of-tree solutions. > > > > Do we know the list of devices exhibiting this pattern? And does the time limit > > is deterministic? I'm just trying to see if it is possible to add quirks for > > those devices. > > No. I'm dealing with new devices being actively developed, with new ones > coming out every year, so a quirk list would just be never ending > maintenance pain point. Sounds like you have a lot of devices behaving this way. So can't you quirk them based on VID and CLASS? > The fact I can't point them to off-the-shelf > kernels to test with has been frustrating for everyone. If we just had a > user defined option instead of forcing the kernel's arbitrary choice, > then the problem is solved once and forever. I think nowadays the use of module_params is not encouraged, though in this case, it is already present and you are just trying to add one more option. But, adding a new option for devices from a single vendor might not fly (though only Bjorn could take that call). - Mani -- மணிவண்ணன் சதாசிவம்