On Wed, 16 Jul 2008, Jesse Barnes wrote: > > I'm open to suggestions here about a couple of caveats with this pull: > - it's not merged up to master (though the conflicts are fairly trivial, > you can check out my linux-next-merge branch to see how I handled them) Ok, I handled them without checking your branch, just because I actually like feeling like I know what I'm doing. That said, when I inevitably fail, just humor me, and send me a patch to fix it up, mentioning how I missed a really "subtle" thing, and the fact that it didn't even compile wasn't really my fault. I'm special. My mom told me so. And I want the re-assurance. > - it contains a revert for a patch I thought might be ready but have since > chickened out on. I didn't want to rebase since I'm carrying some > changes from the ACPI tree That's fine. But do double-check the end result. There's lots of small details (for example, I did try to just undo the damage from the "overlong lines caused somebody to violate all the _other_ coding style rules" patch), but this code from setup_64.c: +#ifdef CONFIG_PCI + if (pci_early_dump_regs) + early_dump_pci_devices(); +#endif that your branch had added I put in the new shared 'setup.c', and while I think I put it in the right place, somebody needs to double-check it. Anyway, I've committed what I think is the right resolve, and it's compiled etc, but I want to reboot it before I push out (so if there is something seriously broken I can just holler for help or perhaps try to fixure it out myself before publicising it), so it's not there yet. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
