LKML Archive on
 help / Atom feed
From: Bjorn Helgaas <>
To: joeyli <>
Cc: "Lee, Chun-Yi" <>,
	Bjorn Helgaas <>,
	Thomas Gleixner <>,
	Ingo Molnar <>, "H . Peter Anvin" <>,,,
Subject: Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus
Date: Mon, 13 Aug 2018 13:45:16 -0500
Message-ID: <> (raw)
In-Reply-To: <20180812001413.GC3570@linux-l9pv.suse>

On Sun, Aug 12, 2018 at 08:15:45AM +0800, joeyli wrote:
> On Fri, Aug 10, 2018 at 08:58:37AM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 10, 2018 at 05:25:01PM +0800, joeyli wrote:
> > > On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote:
> > > ...
> [...snip]
> > > hm... I have another question that it may not relates to this issue. I
> > > was tracing the code path of PCI hot-remove/hotplug. Base on spec, looks
> > > that the RST# should be asserted when hot-remove. And the memory decode
> > > bit must be set to zero after RST# be asserted. But I didn't see that
> > > any kernel PCI/ACPI code set RST#. The only possible code to set RST# is
> > > in POWER architecture. Do you know who assert the RST# when hot-remove?    
> > 
> > RST# is a conventional PCI signal (not a PCIe signal).  In any case, I
> > would expect signals like that to be handled by hardware, not by
> > software.  What section of the spec are you looking at?  I wouldn't
> In PCI Hot-Plug Spec v1.1
> 2.2.1 Hot Removal
> The Hot-Plug System Driver uses the Hot-Plug Controller to do the following:
> a) Assert RST# to the slot and isolate the slot from the rest of the bus, in
>    either order.
> b) Power down the slot.
> c) Change the optional slot-state indicator, as defined in Section 3.1.1, to show
>    that the slot is off.
> In the above description, it said that "Hot-Plug System Driver" should done
> the job. So I was think that kernel driver must asserts RST#, but I didn't
> find that in kernel code.

I don't think there's much in that spec that's still relevant unless
you are using conventional PCI.  Most current hardware would be using
PCIe, and the PCIe spec itself covers hotplug (PCIe r4.0, sec 6.7).

Prior to PCIe, hotplug wasn't directly included in the PCI spec, and
there were several varieties of hotplug controllers (SHPC, Compaq
hotplug controller, IBM hotplug controller, CompactPCI, etc.)

The PCI Hot-Plug spec covers the high-level model but doesn't have the
details of any of these controllers.  There is a separate spec for the
SHPC ("PCI Standard Hot-Plug Controller and Subsystem Specification",
r1.0, June 20, 2001), which does talk about requirements for RST#.
But even there I don't see a way for software to directly control
RST#; it looks like software programs the Slot Control Logic, which in
turn manages RST# based on commands from the software and hardware
inputs like presence detect.

> Then, in PCI Local Bus spec v2.2, it mentions:
> Table 6-1: Command Register Bits
> Bit Location            Description
> 0                       ...State after RST# is 0.
> 1                       ...State after RST# is 0.
> So, after hot-remove the RST# must be asserted and the IO/memory
> decode bit should also be set to zero.
> I was tracing the kerenl hot-remove code for RST# because I
> want to make sure that kernel didn't change the RST# state from
> firmware.
> ...

> But I still confused about the "Hot-Plug System Driver" wording in
> PCI Hot-Plug Spec. The "Hot-Plug System Driver " means a kernel
> driver?

I would interpret "Hot-Plug System Driver" to refer to one of the
kernel PCI hotplug drivers (pciehp, shpcpd, cpqphp, ibmphp, etc.)


      reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-24 11:01 Lee, Chun-Yi
2018-08-06 21:48 ` Bjorn Helgaas
2018-08-08 15:53   ` joeyli
2018-08-08 21:23     ` Bjorn Helgaas
2018-08-10  9:25       ` joeyli
2018-08-10 13:58         ` Bjorn Helgaas
2018-08-12  0:15           ` joeyli
2018-08-13 18:45             ` Bjorn Helgaas [this message]

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox