Hi Robert, Le jeudi 02 juillet 2009, Moore, Robert a écrit : > could still detect most i2c/smbus/hwmon devices conflicts. > > What exactly are these conflicts? Native Linux drivers trying to access devices which ACPI also wants to access. Most frequently these are SMBus master drivers or hardware monitoring drivers (for Super I/O chips) but virtually any other device type could be affected, due to the fact that ACPI I/O resources do not show up in /proc/ioports and /proc/iomem. The workaround written by Thomas would let the native drivers which are more frequently affected by the problem ask the ACPI subsystem, on a voluntary basis, if a given I/O range is safe to use. While not perfect, it worked reasonably well in practice. Your upstream commit broke this safety mechanism, and now all the past bugs resulting of native driver vs. ACPI conflicts show up again, so you will have to fix it now. Either by reverting your commit, or by coming up with a better safety. I don't know much about ACPI so I can't really comment on a technical perspective. All I care about is the functionality: either concurrent access from native drivers and ACPI must be doable safely, or it must be prevented altogether (which Thomas' code was doing.) I will be happy to answer your questions about the native Linux drivers for SMBus master devices and hardware monitoring devices. I can also help with testing if you want. -- Jean Delvare Suse L3 -- 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
