diff mbox

pci: Use hot-plug capable for testing presence on

Message ID 1419275223-14602-1-git-send-email-keith.busch@intel.com (mailing list archive)
State New, archived
Delegated to: Bjorn Helgaas
Headers show

Commit Message

Keith Busch Dec. 22, 2014, 7:07 p.m. UTC
The PCI-e Base specifically says Hot-Plug Surprise capability is for
removal only, but pciehp checked this to determine if it should handle a
slot event on device add. Lots of platform's pcie slots don't advertise
support for surprise removal, but are perfectly capable of handling
hot-add, so checking surprise removal is not appropriate.

This patch checks the Hot-Plug Capable bit in the slot capabilities to
determine if the detected presence on is a reliable event instead of
Hot-Plug Surprise.

Signed-off-by: Keith Busch <keith.busch@intel.com>
---
 drivers/pci/hotplug/pciehp.h      |    1 +
 drivers/pci/hotplug/pciehp_ctrl.c |    2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

Comments

Keith Busch Jan. 15, 2015, 10:17 p.m. UTC | #1
Any thoughts on this? I've read old threads on the pci lists regarding
the HPS slot capability usage being wrong for hot-add, but it didn't
seem like it was closed.

Right now there are customers reporting hot-add doesn't work on Linux
for this reason, and I'm struggling to come up with a rebuttal to the
other OS developers claiming superiority over Linux for PCI-e hotplug
on popular platforms.

On Mon, 22 Dec 2014, Keith Busch wrote:
> The PCI-e Base specifically says Hot-Plug Surprise capability is for
> removal only, but pciehp checked this to determine if it should handle a
> slot event on device add. Lots of platform's pcie slots don't advertise
> support for surprise removal, but are perfectly capable of handling
> hot-add, so checking surprise removal is not appropriate.
>
> This patch checks the Hot-Plug Capable bit in the slot capabilities to
> determine if the detected presence on is a reliable event instead of
> Hot-Plug Surprise.
>
> Signed-off-by: Keith Busch <keith.busch@intel.com>
> ---
> drivers/pci/hotplug/pciehp.h      |    1 +
> drivers/pci/hotplug/pciehp_ctrl.c |    2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
> index b115219..b91eefb 100644
> --- a/drivers/pci/hotplug/pciehp.h
> +++ b/drivers/pci/hotplug/pciehp.h
> @@ -126,6 +126,7 @@ struct controller {
> #define ATTN_LED(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_AIP)
> #define PWR_LED(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_PIP)
> #define HP_SUPR_RM(ctrl)	((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPS)
> +#define HP_CAP(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPC)
> #define EMI(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_EIP)
> #define NO_CMD_CMPL(ctrl)	((ctrl)->slot_cap & PCI_EXP_SLTCAP_NCCS)
> #define PSN(ctrl)		(((ctrl)->slot_cap & PCI_EXP_SLTCAP_PSN) >> 19)
> diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
> index ff32e85..996c313 100644
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -532,7 +532,7 @@ static void interrupt_event_handler(struct work_struct *work)
> 		pciehp_green_led_off(p_slot);
> 		break;
> 	case INT_PRESENCE_ON:
> -		if (!HP_SUPR_RM(ctrl))
> +		if (!HP_CAP(ctrl))
> 			break;
> 		ctrl_dbg(ctrl, "Surprise Insertion\n");
> 		handle_surprise_event(p_slot);
> -- 
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas Jan. 16, 2015, 8:33 p.m. UTC | #2
[+cc Rajat]

On Mon, Dec 22, 2014 at 12:07:03PM -0700, Keith Busch wrote:
> The PCI-e Base specifically says Hot-Plug Surprise capability is for
> removal only, but pciehp checked this to determine if it should handle a
> slot event on device add. Lots of platform's pcie slots don't advertise
> support for surprise removal, but are perfectly capable of handling
> hot-add, so checking surprise removal is not appropriate.
> 
> This patch checks the Hot-Plug Capable bit in the slot capabilities to
> determine if the detected presence on is a reliable event instead of
> Hot-Plug Surprise.
> 
> Signed-off-by: Keith Busch <keith.busch@intel.com>

This seems reasonable to me, and I applied it to pci/hotplug for v3.20.

Does this fix a bug you've observed?  If so, I'll include details or a
pointer in the changelog.

2b3940b60626 ("PCI: pciehp: Remove a non-existent card, regardless of
"surprise" capability") made it so we handle unexpected loss of presence
detect even if the slot doesn't advertise Hot-Plug Surprise.  I suppose we
could make a similar argument that if a card shows up, maybe we should do
something with it regardless of what the slot advertises for Hot-Plug
Capable.

> ---
>  drivers/pci/hotplug/pciehp.h      |    1 +
>  drivers/pci/hotplug/pciehp_ctrl.c |    2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
> index b115219..b91eefb 100644
> --- a/drivers/pci/hotplug/pciehp.h
> +++ b/drivers/pci/hotplug/pciehp.h
> @@ -126,6 +126,7 @@ struct controller {
>  #define ATTN_LED(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_AIP)
>  #define PWR_LED(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_PIP)
>  #define HP_SUPR_RM(ctrl)	((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPS)
> +#define HP_CAP(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPC)
>  #define EMI(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_EIP)
>  #define NO_CMD_CMPL(ctrl)	((ctrl)->slot_cap & PCI_EXP_SLTCAP_NCCS)
>  #define PSN(ctrl)		(((ctrl)->slot_cap & PCI_EXP_SLTCAP_PSN) >> 19)
> diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
> index ff32e85..996c313 100644
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -532,7 +532,7 @@ static void interrupt_event_handler(struct work_struct *work)
>  		pciehp_green_led_off(p_slot);
>  		break;
>  	case INT_PRESENCE_ON:
> -		if (!HP_SUPR_RM(ctrl))
> +		if (!HP_CAP(ctrl))
>  			break;
>  		ctrl_dbg(ctrl, "Surprise Insertion\n");
>  		handle_surprise_event(p_slot);
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rajat Jain Jan. 16, 2015, 8:50 p.m. UTC | #3
Hello,

>>
>> Signed-off-by: Keith Busch <keith.busch@intel.com>
>
> This seems reasonable to me, and I applied it to pci/hotplug for v3.20.

Yes, I agree.

>
> Does this fix a bug you've observed?  If so, I'll include details or a
> pointer in the changelog.
>
> 2b3940b60626 ("PCI: pciehp: Remove a non-existent card, regardless of
> "surprise" capability") made it so we handle unexpected loss of presence
> detect even if the slot doesn't advertise Hot-Plug Surprise.  I suppose we
> could make a similar argument that if a card shows up, maybe we should do
> something with it regardless of what the slot advertises for Hot-Plug
> Capable.

Ummm ... may be not. From The PCI Hotplug Spec ver 1.1. section 2.2.2
(Hot Insertion)
 ==================================================================
A slot must be powered down and isolated from the bus before an add-in
card can be
inserted. The process of making a slot ready for insertion depends
upon the particular
Platform and operating system. The following general sequence of steps
is necessary to
insert an add-in card into a slot after it is powered down and ready
for insertion:

1. The user inserts the new add-in card.
2. The user notifies the Hot-Plug Service to turn on the slot
containing the new add-in
card.
3. The Hot-Plug Service issues a Hot-Plug Primitive to the Hot-Plug
System Driver to
turn on the appropriate slot.
===============================================================

Also, I recall I read somewhere in the specs about the need to use the
button to initiate hot-plug. This change would make the button
useless, no?

I'm thinking the user may have reasons to have the card plugged-in,
but not have it turned on. The card may be a back-up for example, to
be turned on (to enable an alternate path) in case of some other card
fails etc. Or may be other application reasons. Thoughts?

Thanks,

Rajat


<span class="sewoi9i5w58ly4q"><br></span>>
>> ---
>>  drivers/pci/hotplug/pciehp.h      |    1 +
>>  drivers/pci/hotplug/pciehp_ctrl.c |    2 +-
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
>> index b115219..b91eefb 100644
>> --- a/drivers/pci/hotplug/pciehp.h
>> +++ b/drivers/pci/hotplug/pciehp.h
>> @@ -126,6 +126,7 @@ struct controller {
>>  #define ATTN_LED(ctrl)               ((ctrl)->slot_cap & PCI_EXP_SLTCAP_AIP)
>>  #define PWR_LED(ctrl)                ((ctrl)->slot_cap & PCI_EXP_SLTCAP_PIP)
>>  #define HP_SUPR_RM(ctrl)     ((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPS)
>> +#define HP_CAP(ctrl)         ((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPC)
>>  #define EMI(ctrl)            ((ctrl)->slot_cap & PCI_EXP_SLTCAP_EIP)
>>  #define NO_CMD_CMPL(ctrl)    ((ctrl)->slot_cap & PCI_EXP_SLTCAP_NCCS)
>>  #define PSN(ctrl)            (((ctrl)->slot_cap & PCI_EXP_SLTCAP_PSN) >> 19)
>> diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
>> index ff32e85..996c313 100644
>> --- a/drivers/pci/hotplug/pciehp_ctrl.c
>> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
>> @@ -532,7 +532,7 @@ static void interrupt_event_handler(struct work_struct *work)
>>               pciehp_green_led_off(p_slot);
>>               break;
>>       case INT_PRESENCE_ON:
>> -             if (!HP_SUPR_RM(ctrl))
>> +             if (!HP_CAP(ctrl))
>>                       break;
>>               ctrl_dbg(ctrl, "Surprise Insertion\n");
>>               handle_surprise_event(p_slot);
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keith Busch Jan. 16, 2015, 9:24 p.m. UTC | #4
On Fri, 16 Jan 2015, Rajat Jain wrote:
>> 2b3940b60626 ("PCI: pciehp: Remove a non-existent card, regardless of
>> "surprise" capability") made it so we handle unexpected loss of presence
>> detect even if the slot doesn't advertise Hot-Plug Surprise.  I suppose we
>> could make a similar argument that if a card shows up, maybe we should do
>> something with it regardless of what the slot advertises for Hot-Plug
>> Capable.
>
> Ummm ... may be not. From The PCI Hotplug Spec ver 1.1. section 2.2.2
> (Hot Insertion)
> ==================================================================
> A slot must be powered down and isolated from the bus before an add-in
> card can be
> inserted. The process of making a slot ready for insertion depends
> upon the particular
> Platform and operating system. The following general sequence of steps
> is necessary to
> insert an add-in card into a slot after it is powered down and ready
> for insertion:
>
> 1. The user inserts the new add-in card.
> 2. The user notifies the Hot-Plug Service to turn on the slot
> containing the new add-in
> card.
> 3. The Hot-Plug Service issues a Hot-Plug Primitive to the Hot-Plug
> System Driver to
> turn on the appropriate slot.
> ===============================================================
>
> Also, I recall I read somewhere in the specs about the need to use the
> button to initiate hot-plug. This change would make the button
> useless, no?
>
> I'm thinking the user may have reasons to have the card plugged-in,
> but not have it turned on. The card may be a back-up for example, to
> be turned on (to enable an alternate path) in case of some other card
> fails etc. Or may be other application reasons. Thoughts?

Maybe I need to try this on an add-in card. I'm using front-loading
SFF devices which don't have attention buttons. I would have expected
these slots to have the hot-plug surprise capability set, but there's
enough platforms in existnace that don't have it set, but can handle
add events just fine otherwise. So while this patch fixes that scenario,
I don't want to break others.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Helgaas Jan. 16, 2015, 11:44 p.m. UTC | #5
On Fri, Jan 16, 2015 at 2:50 PM, Rajat Jain <rajatxjain@gmail.com> wrote:
> Hello,
>
>>>
>>> Signed-off-by: Keith Busch <keith.busch@intel.com>
>>
>> This seems reasonable to me, and I applied it to pci/hotplug for v3.20.
>
> Yes, I agree.
>
>>
>> Does this fix a bug you've observed?  If so, I'll include details or a
>> pointer in the changelog.
>>
>> 2b3940b60626 ("PCI: pciehp: Remove a non-existent card, regardless of
>> "surprise" capability") made it so we handle unexpected loss of presence
>> detect even if the slot doesn't advertise Hot-Plug Surprise.  I suppose we
>> could make a similar argument that if a card shows up, maybe we should do
>> something with it regardless of what the slot advertises for Hot-Plug
>> Capable.
>
> Ummm ... may be not. From The PCI Hotplug Spec ver 1.1. section 2.2.2
> (Hot Insertion)
>  ==================================================================
> A slot must be powered down and isolated from the bus before an add-in
> card can be
> inserted. The process of making a slot ready for insertion depends
> upon the particular
> Platform and operating system. The following general sequence of steps
> is necessary to
> insert an add-in card into a slot after it is powered down and ready
> for insertion:
>
> 1. The user inserts the new add-in card.
> 2. The user notifies the Hot-Plug Service to turn on the slot
> containing the new add-in
> card.
> 3. The Hot-Plug Service issues a Hot-Plug Primitive to the Hot-Plug
> System Driver to
> turn on the appropriate slot.
> ===============================================================
>
> Also, I recall I read somewhere in the specs about the need to use the
> button to initiate hot-plug. This change would make the button
> useless, no?
>
> I'm thinking the user may have reasons to have the card plugged-in,
> but not have it turned on. The card may be a back-up for example, to
> be turned on (to enable an alternate path) in case of some other card
> fails etc. Or may be other application reasons. Thoughts?

If there's an Attention Button, we definitely want to leave the card
powered off until the user presses the button.  With an Attention
Button, I think the flow looks like this:

  - Slot is initially powered off
  - Slot hardware includes Attention Button
  - pcie_enable_notification() enables Attention Button interrupt but
not Presence Detect Changed interrupt
  - User inserts card
  - Port may detect card presence (but pciehp hasn't enabled interrupt)
  - User presses attention button
  - Port asserts Attention Button interrupt
  - OS turns on power to slot

If there's no Attention Button, e.g., for an ExpressCard slot or
Keith's SFF devices, I think it looks like this:

  - Slot is initially powered off
  - Slot hardware does not include an Attention Button
  - pcie_enable_notification() enables Presence Detect Changed
interrupt but not Attention Button interrupt
  - User inserts card
  - Port detects card presence and asserts Presence Detect Changed interrupt
  - ** Here is Keith's change to check Hot-Plug Capable instead of
Hot-Plug Surprise **
  - OS turns on power to slot

I *think* it's already superfluous to check Hot-Plug Capable, because
get_port_device_capability() in portdrv_core.c already checks for
that, and if it's not set, I don't think pciehp will claim the Port.
If that's true, then I should drop Keith's patch, and we should just
remove the HP_SUPR_RM test altogether.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index b115219..b91eefb 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -126,6 +126,7 @@  struct controller {
 #define ATTN_LED(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_AIP)
 #define PWR_LED(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_PIP)
 #define HP_SUPR_RM(ctrl)	((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPS)
+#define HP_CAP(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_HPC)
 #define EMI(ctrl)		((ctrl)->slot_cap & PCI_EXP_SLTCAP_EIP)
 #define NO_CMD_CMPL(ctrl)	((ctrl)->slot_cap & PCI_EXP_SLTCAP_NCCS)
 #define PSN(ctrl)		(((ctrl)->slot_cap & PCI_EXP_SLTCAP_PSN) >> 19)
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
index ff32e85..996c313 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -532,7 +532,7 @@  static void interrupt_event_handler(struct work_struct *work)
 		pciehp_green_led_off(p_slot);
 		break;
 	case INT_PRESENCE_ON:
-		if (!HP_SUPR_RM(ctrl))
+		if (!HP_CAP(ctrl))
 			break;
 		ctrl_dbg(ctrl, "Surprise Insertion\n");
 		handle_surprise_event(p_slot);