Messages in this thread | | | Date | Fri, 4 May 2012 13:07:35 -0700 | Subject | Re: [PATCH -v11 00/30] PCI: allocate pci bus num range for unassigned bridge busn | From | Yinghai Lu <> |
| |
On Thu, May 3, 2012 at 4:47 PM, Bjorn Helgaas <bhelgaas@google.com> wrote: > >> It could detect the conflicts. later could add code to resolve the conflicts. > > This is in "Add busn_res operation functions". I think this makes > sense, too. If you look at the branch I started merging > (topic/yinghai-busn-alloc), I tweaked it to print the conflicting > resource when the insertion fails. That information is almost always > useful when debugging, so it'd be nice if you picked that up, too.
ok, will check that branch and put that change in.
> >>> - In some of the arches (sparc, powerpc), you added a bus number >>> resource right next to existing first_busno, last_busno fields. So >>> now that data lives two places, which will bite us later. >> >> then later we should kill first_busno and last_busno in those arches. > > I want to be sensitive to the arch maintainers by doing our homework, > minimizing the number of patches we ask them to review, and grouping > related changes all at one time. I propose the following, using > powerpc as an example: > > - Add "struct resource busn_res" to struct pci_bus. > - powerpc: Replace pci_controller.first_busno/last_busno by "struct > resource busno" everywhere. This will touch many places, but should > be completely mechanical and obvious. > - powerpc: Replace all pci_bus.secondary/subordinate references with > busn_res. This also be only obvious changes. > - powerpc: Add the pci_add_resource() and pci_bus_update_busn_res_end() calls. > - powerpc: Add pci_bus_insert_busn_res() call in > of_scan_pci_bridge(). (This is currently buried in the "Remove > secondary/subordinate in pci_bus" patch, but it doesn't fit there.) > - Replace all non-arch pci_bus.secondary/subordinate references with > busn_res. Obvious changes only. > - Remove secondary/subordinate from struct pci_bus. > - Add pci_bus_insert_busn_res() calls. Again, this is logically > separate from "Remove secondary/subordinate in pci_bus". > > I would split up the "Remove secondary/subordinate in pci_bus" patch, > which currently touches 30 files across 11 arches, so an arch > maintainer doesn't have to read the whole patch.
could split that a little. not sure if it is worth it.
1. core update subordinate and busn_res.end at same time. 2. update subordinate and busn_res.end at same time 2. remove using secondary/subordinate in arch 3. remove using secondary/suborindate in core
> > Ben, Dave, feel free to chime in if I'm going astray. > > I did a fair amount of work updating changelogs and tweaking the code > in my topic/yinghai-busn-alloc branch. I know I'm currently a > bottleneck here, and it's worse because I'm a bit obsessive. It would > save me time if you picked up those tweaks so I don't have to re-do > them.
ok, will pick them up.
> > You have over 100 patches outstanding, and I'm having a hard time > making forward progress. I think we need to focus on just replacing > secondary/subordinate with busn_res, doing the corresponding > arch-specific replacements, and adding the insert_resource() stuff to > build the resource trees for bus numbers. I'm not going to merge the > probe_resource() stuff, so let's defer that and the resource > assignment stuff for later. Also defer the unrelated > pci_hp_add_bridge() stuff that crept into your for-pci-busn-alloc > branch. If you defer all that stuff and split out the arch stuff, > that should leave us with around 30 patches that deal *only* with > adding busn_res and building the resource trees. I don't think this > will fix any bugs or add any new functionality, but at least it's a > manageable step towards getting the infrastructure in place, so it's > reasonable to consider merging it.
let me check if i change to that order.
> > These patches need to appear on the mailing list. In general, people > aren't going to pull your git tree and review them as I've been doing. > But *only* post the stuff mentioned above (busn_res and related > things). I'm not ready to consider the rest yet, so they would only > confuse things.
ok.
Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |