Re: [PATCHv2] pci: allow user specifiy a reset poll timeout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux