Re: [PATCH] ACPI: add "auto" to acpi_enforce_resources

Jean Delvare
2009-02-12T12:44:59Z

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