On 04/09/2014 12:36 PM, 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 I've looked at the ACPI dump across six different systems (3 different vendors, and an intel whitebox), and the data appears to be identical. Could Intel change these? Yes, of course they could, but that's no different from any other undocumented driver in the kernel. > 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. > I think there is -- AFAICT the operations are serialized; if they aren't that is an associated risk. Hopefully someone from Intel will lend a hand here and let me know if I'm doing something horrible ;) > These systems simply don't safely support OS-level i2c access. Possibly -- my interpretation of the ACPI AML could be wrong but it seems like these operations are here for the OS. I'm not denying there is a lot of risk in doing this... P. -- 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
