From: Keith Busch <keith.busch@intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Yinghai Lu <yinghai@kernel.org>, Rajat Jain <rajatja@google.com>
Subject: Re: [PATCH] pciehp: Enable hot plug capable detection
Date: Thu, 3 Aug 2017 21:58:45 -0400 [thread overview]
Message-ID: <20170804015844.GA478@localhost.localdomain> (raw)
In-Reply-To: <20170803201034.GW20308@bhelgaas-glaptop.roam.corp.google.com>
On Thu, Aug 03, 2017 at 03:10:34PM -0500, Bjorn Helgaas wrote:
> [+cc Yinghai, Rajat]
>
> On Wed, Aug 02, 2017 at 11:59:24PM -0400, Keith Busch wrote:
> >
> > The part of the specification that suggests PDCE is tied to the hotplug
> > capable bit is the "Slot Control Register" section in 7.8.10 of PCIe
> > Base spec rev4. Specifically:
> >
> > "If the Hot-Plug Capable bit in the Slot Capabilities register is 0b,
> > this bit is permitted to be read-only with a value of 0b"
> >
> > So this control doesn't do anything if hotplug capable is not set.
>
> I thought that might be the part of the spec you were referring to,
> but that's not how I read it :) I read sec 7.8.10 as saying:
>
> - Presence Detect Changed Enable is a read/write bit,
> - However, if Hot-Plug Capable (a HwInit/read-only bit) is 0,
> PDCE may be a read-only 0 (OR it may be read/write)
>
> So I think it's slightly misleading to suggest that PDCE is "tied" to
> HPC. I think the spec allows PDCE to be read/write and to have some
> effect, even if HPC is 0.
>
> I don't know what it would *mean* to have a slot that said "I don't
> support hot-plug operations, but my Presence Detect State might
> change". We've seen some creative uses of pciehp, so I wouldn't be
> surprised if somebody dreamed up a way to use it.
Indeed, in my limited experience I also observe slightly different
behavior that could all be interpreted as spec compliant. Coding the
kernel for one unfortunately risks breaking another. :(
> > The only reference I find on why the code is currently done this way is
> > from this thread:
> >
> > https://marc.info/?l=linux-kernel&m=138688828930718&w=2
> >
> > It seems the current behavior was done this way as a hunch more than
> > anything emperical.
>
> Yeah, this is the sort of thing that niggles at me, but I don't know
> how to resolve it other than to just apply your patch and see if
> anything breaks. There is this hint that presence detect flaps
> sometimes:
>
> http://www.spinics.net/lists/hotplug/msg05812.html
>
> But there's nothing there we can really act on, unless Yinghai or
> Rajat can dredge up something more concrete.
>
> > The problem I'm trying to solve, though, is with a real platform
> > that supports hot-add. The reason it is currently broken with Linux
> > is because this platform advertises "Attention Button Present" when
> > in fact no physical button exists on the platform. Since the kernel
> > doesn't enable presence detect change events when attention button
> > present is set, we don't get hot-add events. We've been working around
> > this by using pciehp_poll_mode=1, but we'd prefer to see this working
> > without kernel parameters.
>
> I agree, using pciehp_poll_mode stinks, and I like your patch.
>
> Can we mention the platform name here, just in case this oddity
> (advertising Attention Button without having a button) is of interest
> in the future?
>
> I propose the following changelog (and I'll add the platform name if
> you can supply it):
This one I'm helping with is based on a COM Express Type 6. The
interesting part is probably the carrier board, which has a PEX8733
bridge. I think its safe to assume not all the available features are
being used, which should be fine, but is why advertised capabilities
are missing their human interfaces.
> PCI: pciehp: Always enable Presence Detect notifications for hotplug slots
>
> Previously we only enabled notification of Presence Detect change events if
> the slot did not advertise an Attention Button.
>
> But there are platforms that support hotplug and advertise "Attention
> Button Present" when in fact there is no physical button. On these
> platforms, we enabled Attention Button notifications, but never got any.
> Presence Detect events occurred, but we left Presence Detect notification
> disabled, so we never noticed them.
>
> Always enable Presence Detect notifications for hotplug slots, even if they
> advertise "Attention Button Present", so we can detect hotplug events.
>
> Signed-off-by: Keith Busch <keith.busch@intel.com>
> [bhelgaas: changelog]
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This sounds great to me. Let me consider Rajat's reply before pulling
the trigger on this one. I initially thought this patch was safe, but
I don't want to break anything.
prev parent reply other threads:[~2017-08-04 1:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 5:15 [PATCH] pciehp: Enable hot plug capable detection Keith Busch
2017-08-02 17:32 ` Bjorn Helgaas
2017-08-03 3:59 ` Keith Busch
2017-08-03 20:10 ` Bjorn Helgaas
2017-08-03 23:00 ` Rajat Jain
2017-08-04 3:46 ` Keith Busch
2017-08-04 5:07 ` Keith Busch
2017-08-04 1:58 ` Keith Busch [this message]
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=20170804015844.GA478@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rajatja@google.com \
--cc=yinghai@kernel.org \
/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).