On Tue, 10 Feb 2009 14:08:29 +0000, Matthew Garrett wrote: > On Tue, Feb 10, 2009 at 02:57:16PM +0100, Jean Delvare wrote: > > > In theory you are, of course, perfectly right. The question is, how do > > we get there without making people angry because of the regression? > > The only thing we can do is add a printk that informs users that passing > a boot argument will allow them to use the drivers as they used to. Good point. > > The same chip can be driven by our native it87 driver, which, on this > > specific board, provides support for 9 voltages, 3 fans, and 1 working > > temperature. Do we really have to tell the user to not use the it87 > > driver and instead use the ACPI thermal driver "because that's what the > > firmware wants"? > > It's valid (if dumb) for vendors to design their platforms such that > enabling ACPI and then not using the thermal code may result in hardware > damage. We have no way of determining that in advance, so all we can do > is tell the user that they can pass an argument if they know it's safe > to do so. OK, I understand. > > But I guess there is no way to know what exactly the ACPI thermal zone > > is doing, except by looking at the DSDT, so this can't be automated? > > Correct. > > > Is it at least possible to disable the ACPI thermal zone either as a > > command-line parameter or an internal blacklist? > > It's possible, and we could certainly add an argument to do so. However, > removing support for the kernel use of the thermal zone doesn't prevent > the firmware from making calls to the thermal code itself. There's no > real way we can block that. > > > One approach that may work is to change the default based on the ACPI > > implementation year (I think the info is available, right?) We could > > default to strict for systems with year >= 2009. This may still prevent > > users from getting the best out of their system, but at least won't > > cause a regression for users of older systems where the native driver > > has been used so far. I know it's not an ideal solution, but ACPI > > implementations aren't ideal either. > > The problem with this approach is that we still end up with a large > number of malfunctioning machines. Well, that's what we have at the moment and the world didn't end. Enabling strict checks for a subset of machines is always an improvement compared to the current situation. > Really, I don't think there's any way > to handle this other than defaulting to strict, letting the default be > changed at run and boot time and printing a message when a driver is > refused permission to bind. Distributions that want to obtain the > previous behaviour can change the default back. Anyway, as I already wrote elsewhere in this thread, I no longer object to the change you propose. I won't instigate it, but if it happens, and care is taken to address the foreseeable downfalls, fine with me. Thanks, -- Jean Delvare -- 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
