> > For now I will remove the ACPICA update from my test branch > > so that it doesn't block the unrelated patches that should go up now. > > The ACPICA update will still be available on a dedicated acpica branch. > > OK, thanks. I'll resync with gti-acpi and will go through another round of > squirting patches at everyone. Andrew, the acpi-test tree is ready for you to resume pulling it. (for those of you who pull it and update the result: Sorry -- I created new history, as I dropped both the acpica and sysfs branches from "test" -- the are available only on their dedicated branches. At the moment, the only thing in acpi-test that I don't think is both ready and appropriate for for 2.6.20-rc1 is the bay driver. > But the problem remains: there is outstanding work in ACPICA which > conflicts with outstanding x86/x86_64 work. Once those two patchsets > finally coincide somewhere, things will blow up. Alexey and I looked at this today and we think we can modify the ACPICA update to touch fewer lines and cause fewer conflicts. So the plan is to shrink the patch, merge it back into acpi-test, let it stew in -mm, and then push to 2.6.21. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
