From: Stuart Hayes <stuart.w.hayes@gmail.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Austin Bolen <austin_bolen@dell.com>,
keith.busch@intel.com, Alexandru Gagniuc <mr.nuke.me@gmail.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
"Gustavo A . R . Silva" <gustavo@embeddedor.com>,
Sinan Kaya <okaya@kernel.org>,
Oza Pawandeep <poza@codeaurora.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
lukas@wunner.de, Stuart Hayes <stuart.w.hayes@gmail.com>
Subject: [PATCH v2 0/3] PCI: pciehp: Do not turn off slot if presence comes up after link
Date: Fri, 11 Oct 2019 16:51:24 -0400 [thread overview]
Message-ID: <20191011205127.4884-1-stuart.w.hayes@gmail.com> (raw)
In older PCIe specs, PDS (presence detect) would come up when the
"in-band" presence detect pin connected, and would be up before DLLLA
(link active).
In PCIe 4.0 (as an ECN) and in PCIe 5.0, there is a new bit to show if
in-band presence detection can be disabled for the slot, and another bit
that disables it--and a recommendation that it should be disabled if it
can be. In addition, certain OEMs disable in-band presence detection
without implementing these bits.
This means it is possible to get a "card present" interrupt after the
link is up and the driver is loaded. This causes an erroneous removal
of the device driver, followed by an immediate re-probing.
This patch set defines these new bits, uses them to disable in-band
presence detection if it can be, waits for PDS to go up if in-band
presence detection is disabled, and adds a DMI table that will let us
know if we should assume in-band presence is disabled on a system.
The first two patches in this set come from a patch set that was
submitted but not accepted many months ago by Alexandru Gagniuc [1].
The first is unmodified, the second has the commit message and timeout
modified.
[1] https://patchwork.kernel.org/cover/10909167/
[v3,0/4] PCI: pciehp: Do not turn off slot if presence comes up after link
v2:
- modify loop in pcie_wait_for_presence to do..while
Alexandru Gagniuc (2):
PCI: pciehp: Add support for disabling in-band presence
PCI: pciehp: Wait for PDS if in-band presence is disabled
Stuart Hayes (1):
PCI: pciehp: Add dmi table for in-band presence disabled
drivers/pci/hotplug/pciehp.h | 1 +
drivers/pci/hotplug/pciehp_hpc.c | 45 +++++++++++++++++++++++++++++++-
include/uapi/linux/pci_regs.h | 2 ++
3 files changed, 47 insertions(+), 1 deletion(-)
--
2.18.1
next reply other threads:[~2019-10-11 20:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-11 20:51 Stuart Hayes [this message]
2019-10-11 20:51 ` [PATCH v2 1/3] PCI: pciehp: Add support for disabling in-band presence Stuart Hayes
2019-10-11 20:51 ` [PATCH v2 2/3] PCI: pciehp: Wait for PDS if in-band presence is disabled Stuart Hayes
2019-10-12 7:34 ` Andy Shevchenko
2019-10-11 20:51 ` [PATCH v2 3/3] PCI: pciehp: Add dmi table for in-band presence disabled Stuart Hayes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191011205127.4884-1-stuart.w.hayes@gmail.com \
--to=stuart.w.hayes@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=austin_bolen@dell.com \
--cc=bhelgaas@google.com \
--cc=gustavo@embeddedor.com \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=mr.nuke.me@gmail.com \
--cc=okaya@kernel.org \
--cc=poza@codeaurora.org \
--cc=rafael.j.wysocki@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).