Hi Matthew, On Wed, 9 Apr 2014 16:36:32 +0000, Matthew Garrett wrote: > On Wed, 2014-04-09 at 12:22 -0400, Prarit Bhargava wrote: > > RFC and a work in progress ... I need to go through and do a bunch of error > > condition checking, more testing, etc. I'm just throwing this out there to see > > if anyone has any major concerns about doing something like this. > > This isn't really a good approach. These aren't standardised ACPI > methods, so you have no guarantee that they exist. The fact that a > method with one of these names exists is no guarantee that it has the > same behaviour as the ones on your board. There's no guarantee that > you're not racing against the firmware. > > These systems simply don't safely support OS-level i2c access. But people need that. And they have been for almost a decade. It's about time that hardware vendors realize that. Yes, I mean Intel, amongst others. Prarit's approach may not be perfect but it has the merit of bringing the topic for discussion, at last. And using his driver would still be much safer than using i2c-i801 with acpi_enforce_resources=lax. If we can come up with a detection method that is reliable enough, it looks completely acceptable to me. Of course it would be much better if vendors could just implement the standard SMBus CMI interface, but having a way to deal with existing hardware and BIOSes is still good. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
