linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jon Derrick <jonathan.derrick@intel.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andy Shevchenko <andriy.shevchenko@intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Pawel Baldysiak <pawel.baldysiak@intel.com>,
	Sinan Kaya <okaya@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Keith Busch <kbusch@kernel.org>,
	Alexandru Gagniuc <mr.nuke.me@gmail.com>,
	Christoph Hellwig <hch@lst.de>,
	Stuart Hayes <stuart.w.hayes@gmail.com>,
	Lukas Wunner <lukas@wunner.de>
Subject: Re: [RFC 0/9] PCIe Hotplug Slot Emulation driver
Date: Sat, 28 Mar 2020 16:51:23 -0500	[thread overview]
Message-ID: <20200328215123.GA130140@google.com> (raw)
In-Reply-To: <1581120007-5280-1-git-send-email-jonathan.derrick@intel.com>

[+cc Stuart, Lukas]

On Fri, Feb 07, 2020 at 04:59:58PM -0700, Jon Derrick wrote:
> This set adds an emulation driver for PCIe Hotplug. There may be platforms with
> specific configurations that can support hotplug but don't provide the logical
> slot hotplug hardware. For instance, the platform may use an
> electrically-tolerant interposer between the slot and the device.
> 
> This driver utilizes the pci-bridge-emul architecture to manage register reads
> and writes. The underlying functionality of the hotplug emulation driver uses
> the Data Link Layer Link Active Reporting mechanism in a polling loop, but can
> tolerate other event sources such as AER or DPC.
> 
> When enabled and a slot is managed by the driver, all port services are managed
> by the kernel. This is done to ensure that firmware hotplug and error
> architecture does not (correctly) halt/machine check the system when hotplug is
> performed on a non-hotplug slot.
> 
> The driver offers two active mode: Auto and Force.
> auto: The driver will bind to non-hotplug slots
> force: The driver will bind to all slots and overrides the slot's services
> 
> There are three kernel params:
> pciehp.pciehp_emul_mode={off, auto, force}
> pciehp.pciehp_emul_time=<msecs polling time> (def 1000, min 100, max 60000)
> pciehp.pciehp_emul_ports=<PCI [S]BDF/ID format string>
> 
> The pciehp_emul_ports kernel parameter takes a semi-colon tokenized string
> representing PCI [S]BDFs and IDs. The pciehp_emul_mode will then be applied to
> only those slots, leaving other slots unmanaged by pciehp_emul.
> 
> The string follows the pci_dev_str_match() format:
> 
>   [<domain>:]<bus>:<device>.<func>[/<device>.<func>]*
>   pci:<vendor>:<device>[:<subvendor>:<subdevice>]
> 
> When using the path format, the path for the device can be obtained
> using 'lspci -t' and further specified using the upstream bridge and the
> downstream port's device-function to be more robust against bus
> renumbering.
> 
> When using the vendor-device format, a value of '0' in any field acts as
> a wildcard for that field, matching all values.
> 
> The driver is enabled with CONFIG_HOTPLUG_PCI_PCIE_EMUL=y.
> 
> The driver should be considered 'use at own risk' unless the platform/hardware
> vendor recommends this mode.

There's a lot of good work in here, and I don't claim to understand
the use case and all the benefits.

But it seems like quite a lot of additional code and complexity in an
area that's already pretty subtle, so I'm not yet convinced that it's
all worthwhile.

It seems like this would rely on Data Link Layer Link Active
Reporting.  Is that something we could add to pciehp as a generic
feature without making a separate driver for it?  I haven't looked at
this for a while, but I would assume that if we find out that a link
went down, pciehp could/should be smart enough to notice that even if
it didn't come via the usual pciehp Slot Status path.

> Jon Derrick (9):
>   PCI: pci-bridge-emul: Update PCIe register behaviors
>   PCI: pci-bridge-emul: Eliminate reserved member
>   PCI: pci-bridge-emul: Provide a helper to set behavior
>   PCI: pciehp: Indirect slot register operations
>   PCI: Add pcie_port_slot_emulated stub
>   PCI: pciehp: Expose the poll loop to other drivers
>   PCI: Move pci_dev_str_match to search.c
>   PCI: pciehp: Add hotplug slot emulation driver
>   PCI: pciehp: Wire up pcie_port_emulate_slot and pciehp_emul
> 
>  drivers/pci/hotplug/Makefile      |   4 +
>  drivers/pci/hotplug/pciehp.h      |  28 +++
>  drivers/pci/hotplug/pciehp_emul.c | 378 ++++++++++++++++++++++++++++++++++++++
>  drivers/pci/hotplug/pciehp_hpc.c  | 136 ++++++++++----
>  drivers/pci/pci-acpi.c            |   3 +
>  drivers/pci/pci-bridge-emul.c     |  95 +++++-----
>  drivers/pci/pci-bridge-emul.h     |  10 +
>  drivers/pci/pci.c                 | 163 ----------------
>  drivers/pci/pcie/Kconfig          |  14 ++
>  drivers/pci/pcie/portdrv_core.c   |  14 +-
>  drivers/pci/probe.c               |   2 +-
>  drivers/pci/search.c              | 162 ++++++++++++++++
>  include/linux/pci.h               |   8 +
>  13 files changed, 775 insertions(+), 242 deletions(-)
>  create mode 100644 drivers/pci/hotplug/pciehp_emul.c
> 
> -- 
> 1.8.3.1
> 

  parent reply	other threads:[~2020-03-28 21:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 23:59 [RFC 0/9] PCIe Hotplug Slot Emulation driver Jon Derrick
2020-02-07 23:59 ` [RFC 1/9] PCI: pci-bridge-emul: Update PCIe register behaviors Jon Derrick
2020-02-08  9:55   ` Andy Shevchenko
2020-03-28 21:42   ` Bjorn Helgaas
2020-02-08  0:00 ` [RFC 2/9] PCI: pci-bridge-emul: Eliminate reserved member Jon Derrick
2020-03-28 21:43   ` Bjorn Helgaas
2020-02-08  0:00 ` [RFC 3/9] PCI: pci-bridge-emul: Provide a helper to set behavior Jon Derrick
2020-02-08  0:00 ` [RFC 4/9] PCI: pciehp: Indirect slot register operations Jon Derrick
2020-02-08  0:00 ` [RFC 5/9] PCI: Add pcie_port_slot_emulated stub Jon Derrick
2020-02-08  0:00 ` [RFC 6/9] PCI: pciehp: Expose the poll loop to other drivers Jon Derrick
2020-02-08  0:00 ` [RFC 7/9] PCI: Move pci_dev_str_match to search.c Jon Derrick
2020-02-08  0:00 ` [RFC 8/9] PCI: pciehp: Add hotplug slot emulation driver Jon Derrick
2020-02-08  0:00 ` [RFC 9/9] PCI: pciehp: Wire up pcie_port_emulate_slot and pciehp_emul Jon Derrick
2020-02-10  7:01 ` [RFC 0/9] PCIe Hotplug Slot Emulation driver Christoph Hellwig
2020-02-10 15:05   ` Derrick, Jonathan
2020-02-10 16:58     ` hch
2020-02-10 17:09       ` Derrick, Jonathan
2020-03-28 21:51 ` Bjorn Helgaas [this message]
2020-03-30 17:43   ` Derrick, Jonathan
2020-03-30 17:49     ` hch
2020-04-01 21:45     ` 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=20200328215123.GA130140@google.com \
    --to=helgaas@kernel.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=hch@lst.de \
    --cc=jonathan.derrick@intel.com \
    --cc=kbusch@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lukas@wunner.de \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mr.nuke.me@gmail.com \
    --cc=okaya@kernel.org \
    --cc=pawel.baldysiak@intel.com \
    --cc=stuart.w.hayes@gmail.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).