All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Rui Wang <rui.y.wang@intel.com>
Cc: tglx@linutronix.de, rjw@rjwysocki.net, tony.luck@intel.com,
	bhelgaas@google.com, linux-acpi@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot
Date: Thu, 16 Jun 2016 12:09:59 -0500	[thread overview]
Message-ID: <20160616170958.GA7250@localhost> (raw)
In-Reply-To: <1465711569-19406-1-git-send-email-rui.y.wang@intel.com>

On Sun, Jun 12, 2016 at 02:06:09PM +0800, Rui Wang wrote:
> On Saturday, June 11, 2016 12:43 AM, Bjorn Helgaas wrote:
> > On Wed, Jun 08, 2016 at 05:32:44PM +0800, Rui Wang wrote:
> > > @@ -1779,8 +1780,12 @@ void __init
> > > pci_assign_unassigned_resources(void)
> > >  {
> > >  	struct pci_bus *root_bus;
> > >
> > > -	list_for_each_entry(root_bus, &pci_root_buses, node)
> > > +	list_for_each_entry(root_bus, &pci_root_buses, node) {
> > >  		pci_assign_unassigned_root_bus_resources(root_bus);
> > > +#ifdef CONFIG_X86
> > > +		acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge));
> > > +#endif
> > 
> > This seems like a strange place to call acpi_ioapic_add().  Your object is to call
> > acpi_ioapic_add() during root bus enumeration.
> > 
> > I assume we *can't* call acpi_ioapic_add() from acpi_pci_root_add() at boot
> > time, for some reason you'll explain.  But is there a reason we have to call it
> > from pci_assign_unassigned_resources() (where it requires an ifdef) instead
> > of from pcibios_assign_resources(), which is already x86-specific?
> > 
> > In acpi_pci_root_add(), we have this:
> > 
> >   acpi_pci_root_add(...)
> >   {
> >     ...
> >     if (hotadd)
> >       acpi_ioapic_add(root);
> > 
> > So the obvious question is why don't we just remove the "if (hotadd)"
> > and call acpi_ioapic_add() always.
> > 
> > I'm sure the reason is some ordering problem, but we need a comment in
> > acpi_pci_root_add() about why the obvious solution doesn't work.
> 
> Yes it's an ording issue. acpi_ioapic_add() and also ioapic_insert_resources()
> have to be later than pci initialization in order to deal with IOAPICs mapped
> on a PCI BAR. There's a comment about this inside pcibios_resource_survey()
> above ioapic_insert_resources(). We can also add a comment inside
> acpi_pci_root_add(), though.
>
> And yes calling acpi_ioapic_add() in pcibios_assign_resources() doesn't require
> ifdef CONFIG_X86. But it'll require a loop to iterate through the root buses,
> and call acpi_ioapic_add() within the loop. pci_assign_unassigned_resources()
> already has that loop. Do you still prefer adding it to
> pcibios_assign_resources() ?

ioapic_insert_resources() is x86-specific, but I'm not sure why; it
seems like it does things that should be applicable to ia64 as well.

acpi_ioapic_add() is not x86-specific, and it is called from
acpi_pci_root_add() for the hot-add case.  You're adding an
x86-xpecific call in pci_assign_unassigned_resources().  Why should
the hot-add case be for all arches, but the boot-time case only for
x86?

  reply	other threads:[~2016-06-16 17:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08  6:59 [PATCH V2 0/3] ioapic hot-removal bugs Rui Wang
2016-06-08  6:59 ` [PATCH V2 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot Rui Wang
2016-06-08  8:05   ` kbuild test robot
2016-06-08  8:05     ` kbuild test robot
2016-06-08  9:32   ` [PATCH V3 " Rui Wang
2016-06-10 12:57     ` Thomas Gleixner
2016-06-10 13:56       ` Rafael J. Wysocki
2016-06-10 16:43     ` Bjorn Helgaas
2016-06-12  6:06       ` Rui Wang
2016-06-16 17:09         ` Bjorn Helgaas [this message]
2016-06-22  7:13           ` Rui Wang
2016-06-22 14:53             ` Bjorn Helgaas
2016-06-24 15:18               ` Rui Wang
2016-06-22  7:40           ` [PATCH V4 " Rui Wang
2016-06-22 15:14             ` Bjorn Helgaas
2016-06-23  5:11               ` Unknown, 
2016-06-23  5:11                 ` 
2016-06-23  5:11                 ` 
2016-06-23 17:34                 ` Bjorn Helgaas
2016-06-24 15:30                   ` Rui Wang
2016-06-26  3:44                   ` [PATCH V5 " Rui Wang
2016-08-08 20:22                     ` Bjorn Helgaas
2016-08-09  3:23                       ` Rui Wang
2016-08-09 12:09                         ` Rafael J. Wysocki
2016-06-08  6:59 ` [PATCH V2 2/3] x86/ioapic: Fix wrong pointers in ioapic_setup_resources() Rui Wang
2016-06-10  9:45   ` [tip:x86/urgent] " tip-bot for Rui Wang
2016-06-10 12:01   ` [tip:x86/apic] x86/ioapic: Fix incorrect " tip-bot for Rui Wang
2016-06-10 12:48   ` [tip:x86/urgent] " tip-bot for Rui Wang
2016-06-08  6:59 ` [PATCH V2 3/3] x86/ioapic: Simplify ioapic_setup_resources() Rui Wang
2016-06-10  9:48   ` [tip:x86/apic] " tip-bot for Rui Wang
2016-06-10 12:54   ` tip-bot for Rui Wang

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=20160616170958.GA7250@localhost \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rui.y.wang@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.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.