Hi Bjorn, Sorry for the late answer. On Wed, 2 Jan 2008 11:30:55 -0700, Bjorn Helgaas wrote: > Even if the BIOS does not declare an IT87xxF as an independent device, > there may be AML that uses the chip internally. For example, the > BIOS could declare a thermal zone with a _TMP method, and the _TMP > method could use the IT87xxF to read the temperature. In that case, > the BIOS would still need to declare the IT87xxF resources so the OS > doesn't place another device on top of it. Thomas Renninger's patch set should handle this case. It's in -mm at the moment and I guess we'll merge most of it in 2.6.25. > (...) An easy way to do this > is with a PNP0C02 "motherboard" device, which just says "these > resources are in use, but the OS needn't attach a driver to this > device." How do I see if a given motherboard does this or not? For example I have a motherboard here that says: 0290-029f : pnp 00:04 How do I know if this is a "PNP0C02 motherboard device" I am supposed not to touch, or a device that I can attach a native hwmon driver to? And more importantly, how does the it87 driver (or any other hwmon driver) know about it? I'm all for updating the hwmon drivers to cooperate better with PNP in order to prevent clashes between the BIOS and the OS, but I just don't know how I am supposed to do that. > > And what "collision" are you talking about? > > I meant the problem where we place two devices at the same address, > causing one to stop working. I wrote "even if it87 isn't present," > which is ambiguous -- I meant that we need something that works even > when the it87 _driver_ isn't present. I agree then. I don't think this has much to do with PNP though. What this is calling for is a Super-I/O subsystem that detects the Super-I/O and instantiate devices out of it. That way the drivers for these devices (in particular hardware monitoring drivers, watchdog drivers, some parport drivers...) would no longer need to instantiate their devices themselves, thus matching the device driver model much better. I've seen patches float around but so far I could never find the time to look into them (and I fear it's unlikely to change anytime soon.) > (...) > Well, it's true that PNP does not need to describe ALL devices in the > system. However, it should describe all devices to which the OS should > bind a driver. The BIOS writer has the discretion to hide devices from > the OS by omitting them from the ACPI namespace. If he does that, his > assumption is that the OS will ignore the device (but of course, he's > thinking about a Plug-and-Play-compliant OS like Windows). Even under Windows, I pretty much doubt that any monitoring application cares about what the BIOS says. Motherboard vendor applications have enough information about each board model to know what they can do or not without asking the BIOS. Third-party applications probably just poke at known I/O locations (pretty much like the Linux hwmon drivers do) and hope for the best. > (...) > I think my patch to request only the ports actually used by the it87 > driver is sufficient to solve the current problem. If we find that > a BIOS neglects to reserve some of the ports decoded by the IT87xxF, > we can add a PNP quirk to handle that. But I'm not aware of any > problems like that yet. I'm not aware of such a problem 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
