On Sat, 15 Mar 2008, Tilman Schmidt wrote: > > Sorry to say, it doesn't. That is, it does shut up the warning I > reported, but there's a new one appearing now instead, three lines > later. I've reverted the whole thing. Or rather, since there were various small fixup commits over time, and a simple revert doesn't really work, I ended up just removing the option and the code that was conditional on it - that way, if we really want to fight this out some time (after 2.6.25 is out) or some vendor wants to use a known-broken option anyway, there's a simple and fairly clean commit to revert the revert. It's commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a9e0d685553af76cb6ae2af93cca4913e7fcd47 for details if you aren't a git person. But quite frankly I don't think that we even want to re-introduce this in that form. If we really want to have a dynamic custom DSDT, I think we should do the whole DSDT replacement *much* later by ACPI (like just before driver loading or something like that). If the BIOS-provided DSDT is _so_ broken that we cannot even get core stuff like the CPU's going, I think it has more serious issues than any custom DSDT will ever fix, but letting ACPI actually switch DSDT's at run-time (instead of just replacing it when looking for it very very early in the boot sequence) in order to work around some device issues sounds reasonably sane. So how about aiming to make that DSDT-replacement something you can do from any kernel module, _after_ the original DSDT has already been parsed? And then the whole "load it from initrd" turns into a regular thing that we can do pretty early, but that we don't have to do quite _this_ early! Linus -- 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
