Hi Jean, Rudolf,
1* It requires that we modify each driver individually. It's quite a shame that we have to update drivers all around the kernel tree with specific code to workaround a problem which is originally located in a single place (the ACPI subsystem.) That being said this isn't a blocker point, if this is the only way, we'll do it. But that's a rather great amount of work.
These additions to drivers might help with the kernel virtualization.
2* It seems to incur a signficant performance penalty. ____request_resource isn't cheap as far as I know. And in the absence of conflict, you are even allocating and releasing the resource on _each_ I/O operation, which certainly isn't cheap either. Again, it is not a blocker point, after all this is a workaround for an improper behavior of the acpi subsystem, this performance penalty is the price to pay. But there is also a performance penalty for legitimate I/O access, which worries me more.
I thought Rudolf's patch allocated the resource in the driver (w83627ehf) and ACPI contacted the driver when it could not allocate the resource. Since ACPI never *really* wants to allocate the resource, is there a fast-path check it could do? This would help performance.
3* What about concurrent accesses from ACPI itself? Unless we have a guarantee that only one kernel thread can run AML code at a given moment, I can imagine a conflict happening, as your code protects us well against ACPI and driver concurrent accesses, but not against two concurrent ACPI accesses. But I'm not familiar with ACPI - maybe we do have this guarantee? OTOH, if this ever happens, well, it would happen even without your code.
All of ACPI uses the same "virtualized" access mechanism, so even if two threads are poking at the bank select register in a race condition (that would be awful code, I think) they would see the same virtual behavior.
So for now I tend to think that the idea of a global AML lock proposed by Pavel Machek and Bodo Eggert would be more efficient. And it wouldn't need any driver-specific code, so it would be much more simple to implement. The drawback being that we serialize more than we really need to (e.g. the hardware monitoring driver will not be allowed to access the chip when _any_ AML code is running, not just when the AML code accesses the hardware monitoring chip, and if two drivers want to check the AML lock, they'll exclude each other as well.) But I wonder if this is a problem in practice. Maybe we'll have to make some profiling on both solutions and compare.
I like the virtualized driver method (if it wasn't obvious!) but the global AML lock works also. It will be interesting to see profiling of both solutions. David - 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
