Message-ID: <20090212134434.719d6f7a@hyperion.delvare>
Date:	Thu, 12 Feb 2009 13:44:34 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	Hans de Goede <hdegoede@...hat.com>, Len Brown <lenb@...nel.org>,
	Luca Tettamanti <kronos.it@...il.com>,
	Thomas Renninger <trenn@...e.de>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI: add "auto" to acpi_enforce_resources

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists