All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Sinan Kaya <okaya@codeaurora.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Oza Pawandeep <poza@codeaurora.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Dongdong Liu <liudongdong3@huawei.com>, Wei Zhang <wzhang@fb.com>,
	Timur Tabi <timur@codeaurora.org>,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH v12 0/6] Address error and recovery for AER and DPC
Date: Wed, 14 Mar 2018 14:50:50 -0600	[thread overview]
Message-ID: <20180314205049.GE29867@localhost.localdomain> (raw)
In-Reply-To: <a52d2e0b-d319-bb34-8610-455d8c7ddad9@codeaurora.org>

On Mon, Mar 12, 2018 at 11:47:12PM -0400, Sinan Kaya wrote:
> 
> The spec is recommending code to use "Hotplug Surprise" to differentiate
> these two cases we are looking for. 
> 
> The use case Keith is looking for is for hotplug support. 
> The case I and Oza are more interested is for error handling on platforms
> with no hotplug support.
> 
> According to the spec, if "Hotplug Surprise" is set in slot capabilities,
> then hotplug driver handles link up and DPC driver doesn't interfere with
> its operation. Hotplug driver observes link up interrupt like it is doing today.
> When link up event is observed, hotplug driver will do the enumeration.
> 
> If "Hotplug Surprise" bit is not set, it is the job of the DPC driver to
> bring up the link. I believe this path should follow the AER driver path
> as there is a very well defined error reporting and recovery framework
> in the code.
> 
> The link comes back up automatically when DPC driver handles its interrupt
> very similar to what secondary bus reset does for AER. I don't believe
> there is a hotplug possibility under this condition since it is not supported
> to begin with.
> 
> Should we plumb the "Hotplug Surprise" condition into the code to satisfy
> both cases and leave the error handling path according to this code series?

I'm on board with this, but I think you mean "Hotplug Capable" rather
than "Hotplug Surprise". The former may co-exist with DPC and handles
the link-ups, leaving DPC responsible for handling the link-down.

The "Hotplug Surprise" capability is recommended to not co-exist with DPC
since that capability may suppress the "surprise link down" notification
that DPC needs to see in order to trigger.

If the "Hotplug Capable" bit is not set, detecting the link-up after a
DPC event would have to fall under a different component's responsibility,
so I think I'm finally seeing your point.

  reply	other threads:[~2018-03-14 20:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28 17:04 [PATCH v12 0/6] Address error and recovery for AER and DPC Oza Pawandeep
2018-02-28 17:04 ` [PATCH v12 1/6] PCI/AER: Rename error recovery to generic PCI naming Oza Pawandeep
2018-02-28 17:04 ` [PATCH v12 2/6] PCI/AER: Factor out error reporting from AER Oza Pawandeep
2018-02-28 17:04 ` [PATCH v12 3/6] PCI/PORTDRV: Implement generic find service Oza Pawandeep
2018-03-06 14:02   ` Sinan Kaya
2018-03-08  7:56     ` poza
2018-02-28 17:04 ` [PATCH v12 4/6] PCI/DPC: Unify and plumb error handling into DPC Oza Pawandeep
2018-02-28 17:04 ` [PATCH v12 5/6] PCI: Unify wait for link active into generic PCI Oza Pawandeep
2018-02-28 17:04 ` [PATCH v12 6/6] PCI/DPC: Enumerate the devices after DPC trigger event Oza Pawandeep
2018-03-11 22:03 ` [PATCH v12 0/6] Address error and recovery for AER and DPC Bjorn Helgaas
2018-03-12  3:03   ` Sinan Kaya
2018-03-12 14:25     ` Keith Busch
2018-03-12 14:46       ` poza
2018-03-12 14:58         ` Keith Busch
2018-03-12 15:34           ` poza
2018-03-12 17:33             ` Keith Busch
2018-03-12 17:41               ` Sinan Kaya
2018-03-12 17:56                 ` Keith Busch
2018-03-12 19:47       ` Bjorn Helgaas
2018-03-12 23:26         ` Keith Busch
2018-03-13  3:47           ` Sinan Kaya
2018-03-14 20:50             ` Keith Busch [this message]
2018-03-14 21:00               ` Sinan Kaya
2018-05-08 19:25           ` Bjorn Helgaas
2018-03-12 14:01   ` poza

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=20180314205049.GE29867@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=helgaas@kernel.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liudongdong3@huawei.com \
    --cc=okaya@codeaurora.org \
    --cc=pombredanne@nexb.com \
    --cc=poza@codeaurora.org \
    --cc=tglx@linutronix.de \
    --cc=timur@codeaurora.org \
    --cc=wzhang@fb.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 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.