Re: [PATCH v3 4/8] pciehp: Don't disable the link permanently, during removal

[Guenter Roeck <linux@roeck-us.net>]

On Wed, Dec 18, 2013 at 03:20:58AM +0000, Rajat Jain wrote:
> 
> 
> > -----Original Message-----
> > From: Bjorn Helgaas [mailto:bhelgaas@google.com]
> > 
> > [+cc yinghai@kernel.org (seems to be Yinghai's preferred email]
> > 
> > On Tue, Dec 17, 2013 at 12:06:05PM -0800, Rajat Jain wrote:
> > > We need future link up events for hot-add, thus don't disable the link
> > > permanently during device removal. Also, remove the static functions
> > > that are now left unused.
> > 
> > The changelog should mention that this reverts part of 2debd9289997
> > ("PCI:
> > pciehp: Disable/enable link during slot power off/on").
> 
> Sure, I'll add that. 
> 
> > 
> > Yinghai, can you tell us whether this is an issue on your systems?
> >
> 
> Thanks in advance Yinghai. 
> 
> Actually I did not understand the original problem and the solution in the first
> place (so I also do not understand how might disabling of presence detect notification
> help). If you can give more details on the original problem that shall be great. Here
> is what I understood from the commit log:
> 
> The believe the HW looks like this:
> 
> PCIe port <----> Repeater <----> Device.
> 
> An in addition there is the presence detect pin that is connected directly from
> The port to the device. Now, when the device is plugged out, the pin indicates
> No presence. But are you saying the PCIe link from port to repeater is still up?
> 
> Part of log:
> ====================================
>     ...
>     It turns out the root complex is continually trying to train the link to
>     the repeater because the repeater has not been reset.
> 
>     This patch will disable the link at removal time to allow the repeater
>     to be reset properly.
>     ...
> ====================================
> 
> 1) I did not understand why would port try to retrain to the link in either cases -
> Whether the link to the repeater is up or not?
> 
> 2) When no link is seen, is THAT what causes repeater to go down and hence solve the
> Problem?
> 
> 3) I'd expect you'd continuously get "adapter not present" messages if some how
> The driver was trying to add the device. But I did not understand where did
> "adapter present" messages came from?
> 
> Sorry, but I guess I am totally confused now. I'll probably go to sleep :-) 
> 

What, that early ? :-)

I think we may have a similar setup on some of our boards. Maybe we can
reproduce the situation (after we understand what exactly it is and how to
trigger it).

Related to this patch set, I learned today that our Space product uses mpt2sas.
Just in case we need one for testing reset functionality.

Guenter