RE: [PATCH] PCI, pciehp: Turn on link a while to workaround presense detection

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

 




> -----Original Message-----
> From: yhlu.kernel@xxxxxxxxx [mailto:yhlu.kernel@xxxxxxxxx] On Behalf Of
> Yinghai Lu
> Sent: Monday, December 09, 2013 12:20 PM
> To: Rajat Jain
> Cc: Ethan Zhao; Bjorn Helgaas; linux-pci@xxxxxxxxxxxxxxx; Kenji
> Kaneshige; stable@xxxxxxxxxxxxxxx; Guenter Roeck
> Subject: Re: [PATCH] PCI, pciehp: Turn on link a while to workaround
> presense detection
> 
> On Mon, Dec 9, 2013 at 11:35 AM, Rajat Jain <rajatjain@xxxxxxxxxxx>
> wrote:
> 
> > Actually there are situations where the presence detect signal does
> not make much sense, because the card is not really plugged out
> physically. For e.g. how do we deal with PCIe end points that may be on
> the board itself, but say come out of reset after the bootup? Or go
> down during a firmware upgrade and again come back up after the
> upgrade?
> >
> 
> That is driver's job.
> mpt2sas driver does diag_reset.
> 
Possibly, but quite frankly, after looking into that code, it seems quite dirty
to me. Of course, that is my personal opinion only. It may suggest, however,
assuming that the mpt2sas driver's resent handler causes a link down/link up 
sequence of events, that there is a valid case for the boot option.
I don't entirely understand, though, how that driver manages to reset its 
PCIe interface without the need to re-initialize it, but maybe I am just
missing something.

There are a number of other problems with the in-driver approach.
For example, it would require the driver to re-program the chip's PCIe
configuration space, as it will be 'vanilla' after the reset. Not even
sure how this can work, since that includes the chip BAR registers
and various other configuration registers which are normally set by the
PCIe subsystem. I'd rather handle this through the PCIe subsystem
instead of kludging around the problem in the driver.

Another problem is resulting boot delays. If link up/down is handled through
the PCIe subsystem, we can have the driver return -EPROBE_DEFER in the initial
probe, and everything just works automatically like magic. Waiting in probe
for the chip to re-initialize itself would add substantial delay to the boot
sequence. With several such chips in the system that can add up to a lot.

Even if we manage to implement all this, we still didn't solve our other
problems, which include chips which are activated after initial PCIe scan,
chips which (unfortunately) tend to hang up themselves without notice,
and real OIR devices which don't implement "correct" PCIe OIR handling.

Rajat's patch solves all those problems, and in my opinion it does so
quite elegantly.

Guenter


--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]