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]

 



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.

In that case, you don't even to add dummy pcie slot cap...to get pciehp loaded.

Yinghai
--
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]