> -----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 linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
