mbox series

[RFC,v2,0/4] PCI: pciehp: Do not turn off slot if presence comes up after link

Message ID 20190220012031.10741-1-mr.nuke.me@gmail.com (mailing list archive)
Headers show
Series PCI: pciehp: Do not turn off slot if presence comes up after link | expand

Message

Alex G. Feb. 20, 2019, 1:20 a.m. UTC
If the presence detect state (PDS) becomes active after the link
comes up (DLLLA), the hotplug code removes the device and then
re-loads the driver. For most devices, this is a mere inconvenience,
and for PCIe storage devices that are part of a RAID set which started
rebuilding, it can get fun.

Ideally, we wouldn't remove perfectly good devices. According to
the old PCIe spec PDS would always have to come up at or before DLLLA.
Since not everyone followed this (looking at you Dell and HPE!!!!),
this now got standardized in PCIe 4.0. (*).

This series has two solutions for this problem, and is intended to
serve as a bikeshedding point for which is better:
 1. Try to wait for PDS _before_ loading the driver
 2. Load as usual, and recognize the delayed PDS event as such

I think (2) is more generic and elegant, but a lot of people seem to
like something similar to (1).

(*) ECN was approved in Nov 2018, and is normative spec text. A lot of
the leaked PCIe 4.0 specs do not have this change.



Alexandru Gagniuc (4):
  PCI: hotplug: Add support for disabling in-band presence
  PCI: pciehp: Do not turn off slot if presence comes up after link
  PCI: hotplug: Wait for PDS when in-band presence is disabled
  PCI: hotplug: Add quirk For Dell nvme pcie switches

 drivers/pci/hotplug/pciehp.h      |  1 +
 drivers/pci/hotplug/pciehp_ctrl.c | 24 ++++++++++++++
 drivers/pci/hotplug/pciehp_hpc.c  | 54 ++++++++++++++++++++++++++++++-
 include/linux/pci.h               |  1 +
 include/uapi/linux/pci_regs.h     |  2 ++
 5 files changed, 81 insertions(+), 1 deletion(-)

Comments

Lukas Wunner Feb. 21, 2019, 3:38 p.m. UTC | #1
On Tue, Feb 19, 2019 at 07:20:26PM -0600, Alexandru Gagniuc wrote:
> This series has two solutions for this problem, and is intended to
> serve as a bikeshedding point for which is better:
>  1. Try to wait for PDS _before_ loading the driver
>  2. Load as usual, and recognize the delayed PDS event as such
> 
> I think (2) is more generic and elegant, but a lot of people seem to
> like something similar to (1).

Either solution LGTM, by now I've also become accustomed to your
preferred solution (2) (i.e. patch [2/4]), so I'm deferring this
question to Bjorn.


> (*) ECN was approved in Nov 2018, and is normative spec text. A lot of
> the leaked PCIe 4.0 specs do not have this change.

I thought it will be incorporated into 5.0, which is why it's missing
in all 4.0 specs?

Thanks,

Lukas
Alex_Gagniuc@Dellteam.com Feb. 21, 2019, 6:17 p.m. UTC | #2
On 2/21/19 9:39 AM, Lukas Wunner wrote:
> On Tue, Feb 19, 2019 at 07:20:26PM -0600, Alexandru Gagniuc wrote:
>> (*) ECN was approved in Nov 2018, and is normative spec text. A lot of
>> the leaked PCIe 4.0 specs do not have this change.
> 
> I thought it will be incorporated into 5.0, which is why it's missing
> in all 4.0 specs?

Once an ECR is approved and promoted to ECN, it becomes normative spec 
text. It's then up to the editors to incorporate the ECN into the 
official spec and publish a more betterrer spec. AFAIK this should 
officially be part of 4.0.

Alex
Bjorn Helgaas April 19, 2019, 12:01 a.m. UTC | #3
Hi Alex,

This has languished a long time (sorry about that), and there were
several review comments.  I know you wanted my opinion on strategy,
but would you mind posting a fresh version with the fixes you've
already done and rebased to v5.1-rc1?

On Tue, Feb 19, 2019 at 07:20:26PM -0600, Alexandru Gagniuc wrote:
> If the presence detect state (PDS) becomes active after the link
> comes up (DLLLA), the hotplug code removes the device and then
> re-loads the driver. For most devices, this is a mere inconvenience,
> and for PCIe storage devices that are part of a RAID set which started
> rebuilding, it can get fun.
> 
> Ideally, we wouldn't remove perfectly good devices. According to
> the old PCIe spec PDS would always have to come up at or before DLLLA.
> Since not everyone followed this (looking at you Dell and HPE!!!!),
> this now got standardized in PCIe 4.0. (*).
> 
> This series has two solutions for this problem, and is intended to
> serve as a bikeshedding point for which is better:
>  1. Try to wait for PDS _before_ loading the driver
>  2. Load as usual, and recognize the delayed PDS event as such
> 
> I think (2) is more generic and elegant, but a lot of people seem to
> like something similar to (1).
> 
> (*) ECN was approved in Nov 2018, and is normative spec text. A lot of
> the leaked PCIe 4.0 specs do not have this change.
> 
> 
> 
> Alexandru Gagniuc (4):
>   PCI: hotplug: Add support for disabling in-band presence
>   PCI: pciehp: Do not turn off slot if presence comes up after link
>   PCI: hotplug: Wait for PDS when in-band presence is disabled
>   PCI: hotplug: Add quirk For Dell nvme pcie switches
> 
>  drivers/pci/hotplug/pciehp.h      |  1 +
>  drivers/pci/hotplug/pciehp_ctrl.c | 24 ++++++++++++++
>  drivers/pci/hotplug/pciehp_hpc.c  | 54 ++++++++++++++++++++++++++++++-
>  include/linux/pci.h               |  1 +
>  include/uapi/linux/pci_regs.h     |  2 ++
>  5 files changed, 81 insertions(+), 1 deletion(-)
> 
> -- 
> 2.19.2
>