Change set acpi_enforce_resources default to strict ?

Hans de Goede hdegoede at redhat.com
Tue Jan 13 08:27:56 UTC 2009


Hi Dave,

The ACPI subsystem has a kernelcmdline setting called acpi_enforce_resources 
which defaults to lax, I would like to propose to change this the default to 
strict in *rawhide*.

As you may (not) know I'm an active contributor to the lm_sensors project both 
to the userspace tools as to the kernel part (I've written and maintained 
numerous hwmon drivers, and yes feel free to assign any hwmon Fedora kernel 
bugs to me like you're doing with webcams :)

Anyways back to changing the acpi_enforce_resources default, this change 
effects only the following 3 functions:
acpi_check_resource_conflict()
acpi_check_region()
acpi_check_mem_region()

These 3 methods only get used by smbus controller drivers and superio hwmon 
drivers. Actually they were added on our (lm_sensors project) request. The 
problem these functions try to fix is that sometimes the ACPI (byte)code 
touches hwmon IC's for doing things like thermalmanagement while we are banging 
the same IO's from native drivers. This is not good!

So know all hwmon drivers which do direct IO (i2c drivers go through the smbus 
controller) call these functions to check if the ACPI tables claim the IO 
resources the smbus controller or superio hwmon driver touches. The idea here 
is that if ACPI claims the IO, the driver refuses to load. However this could 
be seen as a regression by users, as they were able to read their sensors using 
the native hwmon drivers before and now no longer will. Not loading however 
ofcourse is the safe and thus sane thing to do.

As not loading could be seen as a regression the acpi_enforce_resources default 
is lax, which only causes a warning when ACPI claims the same resources as the 
driver is using, changing this to strict will outright make the driver not 
load. We would like to probe the water with how hard this change will make 
people scream, hence I would like to make this change in rawhide (and yes you 
may redirect all blame to me).

So are you ok with giving this a try?

Regards,

Hans




More information about the kernel mailing list