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

[Rajat Jain]

> -----Original Message-----
> From: Guenter Roeck [mailto:groeck7@xxxxxxxxx] On Behalf Of Guenter
> Roeck
> Sent: Tuesday, December 17, 2013 7:40 PM
> To: Rajat Jain
> Cc: Bjorn Helgaas; Rajat Jain; Kenji Kaneshige; Alex Williamson; Yijing
> Wang; linux-pci@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> Y@xxxxxxxxx
> Subject: Re: [PATCH v3 4/8] pciehp: Don't disable the link permanently,
> during removal
> 
> On Wed, Dec 18, 2013 at 03:20:58AM +0000, Rajat Jain wrote:
> >
> >
> > > -----Original Message-----
> > > From: Bjorn Helgaas [mailto:bhelgaas@xxxxxxxxxx]
> > >
> > > [+cc yinghai@xxxxxxxxxx (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 was up until 3 AM last night. "git" (or the ignorance of it) keeps me busy I guess :-)

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

N‹§²æìr¸›yúèšØb²X¬¶ÇvØ^–)Þ{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü}©ž²ÆzÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ßf”ù^jÇy§m…á@A«a¶Úÿ0¶ìh®å’i