> -----Original Message----- > From: yhlu.kernel@xxxxxxxxx [mailto:yhlu.kernel@xxxxxxxxx] On Behalf Of > Yinghai Lu > Sent: Tuesday, December 10, 2013 1:44 PM > To: Guenter Roeck > Cc: Rajat Jain; Ethan Zhao; Bjorn Helgaas; linux-pci@xxxxxxxxxxxxxxx; > Kenji Kaneshige; stable@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] PCI, pciehp: Turn on link a while to workaround > presense detection > > On Mon, Dec 9, 2013 at 4:34 PM, Guenter Roeck <groeck@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. > > According to your description, i think you can do them with scripts in > user land and your driver. > Your driver should have provide interface to load fw. > Have a scripts and load fw, and from /sys stop and remove related pci > devices. > then rescan corresponding bridge later. The FW itself is accessible through an eeprom and can be updated that way. To load it we need to set a flag in the device PCI memory space which causes the entire chip including its PCIe interface to reset. Sure, we can handle rescan from userspace. However, that is quite vulnerable and messy (eg don't try to initiate a rescan without first explicitly removing any devices which have since been reset, removed, and/or reinitialized). Do anything wrong, or in the wrong sequence, and the PCIe data structures in the kernel are completely messed up. This may be ok for experimental code, but I would not want to ship it to a customer. Besides, it still doesn't solve all problems such as to detect hung devices. Handling it in the kernel is much more straightforward and cleaner. 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