On Tue, Jan 20, 2015 at 10:25 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > Yes, it can (in principle). In fact, we have a plan to refine it, but it is > going to take some time. Once we've done that, we'll see how painful it is to > "patch" ACPI tables this way in practice. > > Also there is an ecosystem problem related to distributing such "patches". > Today, distributions don't need to worry about patching buggy platform > firmware, because they get workarounds in the kernel, but if we switch over > to the model in which platform firmware "overlays" need to be provided in > addition to it, then suddenly questions arise about who should be responsible > for making them available, how to avoid duplication of efforts between > distributions etc. > > All of that needs to be clarified before we start making hard statements like > "No in-kernel workarounds for that!" OK so why can't the patching happen in the kernel? If the kernel anyway has to supply some kind of workaround for the issue, it is more a question of where to place it. Whether it does so by patching the ACPI tables or by detecting a bad ACPI thing and working around it at runtime in a certain driver doesn't really matter, does it? They are both in-kernel ACPI fixes, just that one of the mechanisms is generic. I don't understand why this obsession with userspace having to do the ACPI table patching - if kernels should "just work" then put this stuff behind Kconfig and have it in the kernel. Yours, Linus Walleij -- 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
