Luca Tettamanti wrote:
On Thu, Jan 8, 2009 at 5:15 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
[...]
So back to the discussion about changing the default of
acpi_enforce_resources to strict, Jean and I have been discussing this on
IRC and we feel it will most likely cause too much pain. So we would like to
suggest to make the default depend up on the motherboard. Our plan is to
have the default be "auto" and that will mean "lax", unless the motherboard
is atk0110 (Asus ACPI interface for reading hwmon data) capable and in that
case "auto" will mean "strict"
Hum, that would mean putting ATK specific code into ACPI subsystem.
It's not pretty :S
Agreed, an alternative Jean and I discussed was to make the default strict for
all Asus boards, that would be easier (simple strcmp on baseboard
manufacturer). I don't know how large the atk detection code is.
The plan is then to merge this acpi subsystem change and the atk0110 driver
at the same time, so that people will get different hwmon capabilities, but
won't loose hwmon capabilities all together. Important note: this is meant
as an temporary state of affairs, the end goal is to make the checking
strict.
Luca do you think you could do a patch implementing the described "auto"
value for acpi_enforce_resources ?
So the logic would be:
- if ATK node is present and the driver is enabled -> strict
- otherwise -> auto
No the logic would be:
if (acpi_enforce_resources == auto) {
if (atk0110)
acpi_enforce_resources = strict;
else
acpi_enforce_resources = lax;
}
- DMI which would require an entry for each mobo (notebooks don't have
the ATK interface)
Yes, if the atk0110 case is too trouble some, changing this over to make auto
be strict on all Asus boards is ok too.
- an initcall in the ATK driver that overrides the value of
acpi_enforce_resources to strict
That won't work, the atk0110 driver might be a module and the conflicting
drivers could be loaded first.
Regards,
Hans
--
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
