linux-kernel - Re: [PATCH 0/8] PCI, ACPI, x86: Reserve fw allocated resource for hot-add root bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Jan 2013 16:49:41 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <lenb@...nel.org>,
	Taku Izumi <izumi.taku@...fujitsu.com>,
	Jiang Liu <jiang.liu@...wei.com>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	David Howells <dhowells@...hat.com>,
	Michal Simek <monstr@...str.eu>,
	Koichi Yasutake <yasutake.koichi@...panasonic.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH 0/8] PCI, ACPI, x86: Reserve fw allocated resource for
 hot-add root bus

[+cc David, Michal, Koichi, Ben, Paul]

On Fri, Dec 7, 2012 at 12:15 AM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Sat, Nov 3, 2012 at 9:39 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> For root bus hot add, fw could assign some resource for the devices for
>> that root bus before notifying os via acpi, we should check and use those
>> resources at first just like we do for booting path.
>>
>> At first, we need to refactor x86 pci pcibios_allocate related functions
>> for booting path to take bus as parameter.
>>
>> After that, we could use the survey function for hot add root bus.
>>
>> based on pci/yinghai-for-pci-root-bus-hotplug
>>
>> could get from
>>         git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-survey-resources
>>
>> Yinghai Lu (8):
>>   PCI, x86: Separate out pcibios_allocate_bridge_resources()
>>   PCI, x86: Separate out pcibios_allocate_dev_resources()
>>   PCI, x86: Let pcibios_allocate_bus_resources() take bus instead
>>   PCI, x86: Separate out rom resource claim
>>   PCI, x86: Add pcibios_fw_addr_done
>>   PCI, x86: Remove __init for hw/fw allocated functions
>>   PCI, x86: Claim FW allocated resources in hot add path.
>>   PCI, ACPI: reserve fw allocated resource for hot added root bus
>>
>>  arch/x86/pci/i386.c     |  185 +++++++++++++++++++++++++++++++----------------
>>  drivers/acpi/pci_root.c |    4 +-
>>  drivers/pci/bus.c       |    2 +
>>  include/linux/pci.h     |    1 +
>>  4 files changed, 127 insertions(+), 65 deletions(-)
>>
>
> Bjorn,
>
> Can you queue those 8 patches for v3.9 in pci tree?
>
> So I  could resend out other pci root hotplug patches.

I'm really sorry that it's taken me so long to get to these.

I applied these to my pci/yinghai-survey-resources branch.  I
re-ordered the last two and reworked some of the changelogs.

In general these look good.  My main concern is that they only touch
x86, without touching the similar code in frv, microblaze, mn10300,
and powerpc.

This code (pcibios_resource_survey(), pcibios_assign_resources(),
pcibios_allocate_resources(), pcibios_allocate_bus_resources()) was
obviously copied from x86 originally, and I'd like to preserve the
similarity between them.  It would be even better to refactor it so
it's actually *shared*, but I don't think that's a requirement right
now.

If we allow it to diverge now, it will make it harder to refactor and
harder to notice when bug fixes should be applied to all of them.  For
example, looking at pcibios_allocate_resources(), commit 575939cf5
added some SR-IOV support to x86.  Should similar code be added for
frv, microblaze, mn10300, and powerpc?

Anybody else have thoughts on this?

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/