[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BD04AF0D5BE72443A0B69C1C0486AD3ECE8D8973@exchdb03.mips.com>
Date: Mon, 10 Oct 2011 23:49:06 +0000
From: "Zhu, DengCheng" <dczhu@...s.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>
CC: "jbarnes@...tuousgeek.org" <jbarnes@...tuousgeek.org>,
"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
"monstr@...str.eu" <monstr@...str.eu>,
"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
"paulus@...ba.org" <paulus@...ba.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
"Barzilay, Eyal" <eyal@...s.com>,
"Fortuna, Zenon" <zenon@...s.com>,
"dengcheng.zhu@...il.com" <dengcheng.zhu@...il.com>
Subject: RE: [RESEND PATCH v3 0/2] Pass resources to pci_create_bus() and
fix MIPS PCI resources
2011/10/11 Bjorn Helgaas <bhelgaas@...gle.com>
>
> On Fri, Oct 7, 2011 at 3:50 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> > On Wed, Aug 31, 2011 at 8:48 PM, Deng-Cheng Zhu <dczhu@...s.com> wrote:
> >> (Resending the patch set to include more arch maintainers.)
> >>
> >> Change the pci_create_bus() interface to pass in available resources to get them
> >> settled down early. This is to avoid possible resource conflicts while doing
> >> pci_scan_slot() in pci_scan_child_bus(). Note that pcibios_fixup_bus() can get
> >> rid of such conflicts, but it's done AFTER scanning slots.
> >>
> >> In addition, MIPS PCI resources are now fixed using this new interface.
> >
> > Jesse, I assume these are headed for the 3.2 merge window, right?
>
> I tried to build on these patches to convert x86 to using the new
> pci_create_bus() interface, but I couldn't figure out a nice way to
> handle an arbitrary number of resources.
>
> We made pci_create_bus() take a "struct pci_bus_resource *"
> (https://lkml.org/lkml/2011/8/26/88):
>
> struct pci_bus *pci_create_bus(struct device *parent, int bus,
> struct pci_ops *ops, void *sysdata,
> struct pci_bus_resource *bus_res);
>
> Where pci_bus_resource looks like this:
>
> struct pci_bus_resource {
> struct list_head list;
> struct resource *res;
> unsigned int flags;
> };
>
> Conceptually, we're passing a list of resources to pci_create_bus(),
> which I think is the right thing. But I think the best way to do that
> is by passing a pointer to a struct list_head, not a pointer to a
> pci_bus_resource.
>
> If we pass a pci_bus_resource, we're basically using that as a
> container for a list (as per include/linux/list.h), but it's not a
> well-formed list. Normally a list contains one list_head per element,
> plus an extra list_head for the head of the list. There's a nice
> drawing on page 296 of http://lwn.net/images/pdf/LDD3/ch11.pdf.
>
> The list built in your MIPS patch (https://lkml.org/lkml/2011/8/26/89)
> consists of two pci_bus_resource structs (each with a list_head), but
> there's no third list_head for the head of the list. I think if you
> tried to use list_for_each_entry() to iterate through the list, it
> would not work correctly.
>
> I'll post a slightly modified series to show what I mean. Take a look
> and see if it makes sense to you.
Yes, I can easily understand what you mean, because this point was ever
considered while writing this patch series. We pass the element list as
opposed to a list_head for the head of the element list because we simply
want to link the elements into pci_bus->resources in pci_create_bus(). This
can be done by a single line:
list_add_tail(&b->resources, &bus_res->list);
In addition, if we need to do list_for_each_entry() on the list, our target
should always be pci_bus->resources rather than the pci_bus_resource list
which is passed into pci_create_bus() to be part (the meat) of
pci_bus->resources.
Deng-Cheng
--
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/
Powered by blists - more mailing lists