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