"To prevent deadlocks, wherever more than one synchronization object
must be owned, the synchronization
objects must always be released in the order opposite the order in which
they were acquired."
I think the ASL compiler should (does?) validate that.
Bob should comment, but before we could rely on that it would also
need to be ensured that _all_ AML compilers do that, including
the one from Microsoft.
With all that, and the fact that I don't see much of a reason to have
deep synchronization inside these AML's ,
I'm sure BIOS writers come up with things we never thought about.
I think it's going to be a
very rare occasion that we find a lockdep warning inside the AML ..Even
if we did find a problem, that's something we would want to know about
and/or try to get fixed I would think.
I don't see a clear path to fix those if they happen. And just
processing them would already tie up precious bughandling resources.
It borders towards Steinbach's rule.
Now one possibility would be to figure out how to disable lockdep
for them (perhaps optional with default to off).
But on the other hand your patch is non trivial amount of code.
Without the checking (which would seem more like a disadvantage in this case)
the only advantage I can see of the mutexes would be PI handling in RT
kernels, but that's clearly an out of tree usage right now (and also
since AML is not executed in normal operation it's unlikely
that PI for those is really critical for anyone)
Any other reasons right now we would want that in tree?
-Andi
--
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
