Hi Matthew, Sorry for the late answer. On Wed, 4 Feb 2009 14:20:15 +0000, Matthew Garrett wrote: > On Wed, Feb 04, 2009 at 02:26:06PM +0100, Jean Delvare wrote: > > On Wed, 4 Feb 2009 13:17:09 +0000, Matthew Garrett wrote: > > > Personally, I'd rather that it was "strict" on everything. We might > > > break some existing setups, but they're already working mostly by luck. > > > > Are you the new hwmon and i2c subsystems maintainer and I wasn't aware > > of it? > > If you've got some programmatic way to tell the difference between safe > and dangerous reuse of ACPI resources then that would obviously be > preferable, but I doubt that's practical. I wish we had such a way, but I don't know of any. If someone can think of one, that would be someone who knows ACPI much better than I do. > auto is a compromise that > avoids one specific case of breakage, but it does nothing to protect us > on the majority of systems. Allowing the firmware and the OS to attempt > to access the same hardware without any locking is an invitation for > disaster, and in the absence of any way to prevent the firmware from > doing it... In theory you are, of course, perfectly right. The question is, how do we get there without making people angry because of the regression? I had yet another example a few days ago: http://lists.lm-sensors.org/pipermail/lm-sensors/2009-February/025297.html That system implements an ACPI thermal zone, which apparently reads its values from the second temperature channel of the IT8716F Super-I/O chip. This channels happens to be broken (not sure why but that's not really the point) and returns a wrong temperature value. 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"? In this case, I really would like to be able to blacklist the ACPI thermal device, and let the it87 driver handle the device. If we can have such a blacklist in the kernel, then I am fine switching the resource conflict check to "strict" by default. But is is possible? I would like the ACPI people to tell me. Basically the logic would be as follows: if (not laptop) { if (ACPI thermal zone defined && no custom ACPI code dealing with thermal conditions) { disable ACPI thermal zone and free its resources for native driver } } 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? Is it at least possible to disable the ACPI thermal zone either as a command-line parameter or an internal blacklist? > But. Hans asked for my opinion - the maintainer's is obviously more > relevant. Well, officially I am not the maintainer of the hwmon subsystem, only whose of the i2c subsystem. But the fact is that the resource conflict checking policy affects both the same way. That being said, I'm not sure how worth my opinion (about this specific matter) is these days... What I want you (and everyone) to realize is that just switching the default checking level to strict tomorrow isn't going to work. If we want the default to be strict then we will have to add a number of mechanisms to let the user override this in a way which is as easy and transparent as possible for the user. 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. -- Jean Delvare -- 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
