All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: linux-pci@vger.kernel.org,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Subject: Re: [PATCH 2/5] pciehp: Don't enable presence notification while surprise removal is not supported.
Date: Wed, 11 Jul 2012 14:48:36 -0600	[thread overview]
Message-ID: <CAErSpo6rEcu3gwScEDxJ7DXzeMpT4DBGgAyhNE9qpPo4wEMouw@mail.gmail.com> (raw)
In-Reply-To: <CAE9FiQU3RbdnBssTT6tiGP9GjtyLHBbdaor2qF=26d8WLf72cw@mail.gmail.com>

On Wed, Jul 11, 2012 at 2:28 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Wed, Jul 11, 2012 at 12:56 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> On Wed, Jul 11, 2012 at 12:49 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>>> On Wed, Jul 11, 2012 at 11:15 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>>>
>>>> What's the connection with HP_SUPR_RM()?  Is it just a coincidence
>>>> that chipsets that set the "Hot-Plug Surprise" bit don't have this
>>>> problem with the Presence Detect State bit?
>>>>
>>>> Using HP_SUPR_RM() seems like a totally bogus way to work around a
>>>> presence detect issue.
>>>
>>> then we should blame the spec.
>>
>> What specifically are you referring to?  I see this Presence Detect State text:
>>
>>   Presence Detect State – This bit indicates the presence of an
>>   adapter in the slot, reflected by the logical “OR” of the Physical
>>   Layer in-band presence detect mechanism and, if present, any
>>   out-of-band presence detect mechanism defined for the slot’s
>>   corresponding form factor. Note that the in-band presence
>>   detect mechanism requires that power be applied to an adapter
>>   for its presence to be detected. Consequently, form factors that
>>   require a power controller for hot-plug must implement a
>>   physical pin presence detect mechanism.
>>
>> But I don't yet see the connection with the Hot-Plug Surprise bit.
>
> Spec does not mention about surprise add clearly.

No, in fact the Hot-Plug Surprise description mentions *removal* twice
and doesn't mention *add* at all.

>>> and if you do the above changing, when plug the card into system,
>>> kernel will bring that card online automatically without press
>>> attention button.
>>> that will be big change.
>>
>> I don't want to make a fundamental change in behavior like that.  I'm
>> just trying to understand why we should handle Presence Detect
>> differently based on the Hot-Plug Surprise bit.
>
> When hotplug surprise is supported, attention button may not there.
> So have to use present bit to trigger the sequence online work, and
> offline clean up work.

Well, there is an "Attention Button Present" bit.  Why wouldn't we use
that instead of trying to infer the button's presence from Hot-Plug
Surprise?

> When hotplug surprise is not there, why should we handle Presence Bit change?
>
>>
>> The attention button is optional.  What happens today when you plug a
>> card into a slot with no attention button?
> if the slot support hotplug surprise, that card will be online automatically.
> if the slot does not support hotplug surprise, but that slot have
> power control,  then could use need sw interface /sys/..../power to
> turn on the power and bring that card online.
>
>
> Yinghai

  reply	other threads:[~2012-07-11 20:49 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-23  7:42 [PATCH 0/5] PCI: hotplug related misc patches Yinghai Lu
2012-06-23  7:42 ` [PATCH 1/5] PCI, acpiphp: remove not used res_lock Yinghai Lu
2012-06-23  7:42 ` [PATCH 2/5] pciehp: Don't enable presence notification while surprise removal is not supported Yinghai Lu
2012-06-26  1:26   ` Kaneshige, Kenji
2012-06-26 18:03     ` Yinghai Lu
2012-07-10 22:56   ` Bjorn Helgaas
2012-07-10 23:12     ` Yinghai Lu
2012-07-10 23:28       ` Bjorn Helgaas
2012-07-10 23:40         ` Yinghai Lu
2012-07-11 16:21     ` Bjorn Helgaas
2012-07-11 17:58       ` Yinghai Lu
2012-07-11 18:15         ` Bjorn Helgaas
2012-07-11 18:49           ` Yinghai Lu
2012-07-11 19:56             ` Bjorn Helgaas
2012-07-11 20:28               ` Yinghai Lu
2012-07-11 20:48                 ` Bjorn Helgaas [this message]
2012-07-11 20:56                   ` Yinghai Lu
2012-07-11 22:24                     ` Bjorn Helgaas
2012-07-12  0:05                       ` Yinghai Lu
2012-07-12 20:20                         ` Bjorn Helgaas
2012-07-13  0:19                           ` Yinghai Lu
2012-07-13 15:30                             ` Bjorn Helgaas
2012-07-13 18:07                               ` Yinghai Lu
2012-06-23  7:42 ` [PATCH 3/5] PCI, acpiphp: Merge acpiphp_debug and debug Yinghai Lu
2012-06-23  7:42 ` [PATCH 4/5] PCI, acpiphp: add is_hotplug_bridge detection Yinghai Lu
2012-07-11 15:50   ` Bjorn Helgaas
2012-07-11 17:14     ` Jason Baron
2012-07-11 19:42       ` Bjorn Helgaas
2012-07-16 16:05         ` Bjorn Helgaas
2012-07-17 14:14         ` Jason Baron
2012-08-15 19:36           ` Bjorn Helgaas
2012-08-20 14:35             ` Jason Baron
2012-08-22 23:19               ` Bjorn Helgaas
2012-09-04 20:55                 ` Jason Baron
2012-06-23  7:42 ` [PATCH 5/5] PCI: add root bus children dev's res to fail list Yinghai Lu
2012-07-10 19:30 ` [PATCH 0/5] PCI: hotplug related misc patches Yinghai Lu
2012-07-11 18:32   ` Bjorn Helgaas

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=CAErSpo6rEcu3gwScEDxJ7DXzeMpT4DBGgAyhNE9qpPo4wEMouw@mail.gmail.com \
    --to=bhelgaas@google.com \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-pci@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.