Re: [PATCH 0/3] ACPI: Serialize battery methods and INT3403 _TMP

[Hans de Goede <johannes.goede@oss.qualcomm.com>]

Hi,

On 15-Oct-26 13:45, Rong Zhang wrote:
> Hi Ali,
> 
> Thanks for working on this!
> 
> The series is generally in a good shape. I just have a few minor
> comments.
> 
> On Wed, 2026-10-14 at 16:26 +0300, Ali Ahmet Memiş wrote:
>> As discussed in [1], add exclusive variants of acpi_evaluate_object()
>> and acpi_evaluate_integer() and use them for the battery methods and
>> INT3403 _TMP, which interleave badly on ThinkPad P1 Gen2 and P53.
>>
>> UCSI (bko221065) is not converted.  
>>
> 
> Please leave a link to the bko bug, so that readers don't need to
> assemble the link themselves.
> 
>> There the contention is on a
> 
> After carefully auditing the ASL code again, I've just found the root
> cause of the mutex acquisition timeout.
> 
> It's hard to notice, but \_SB.PCI0.LPC0.EC0.RDER being declared as
> "Serialized" causes an ABBA deadlock:
> 
> Thread 1 (battery)                         Thread 2 (ideapad-laptop)
> -----------------------------------------  ---------------------------------------
> serialize \_SB.BAT0._BIX                   serialize \_SB.PCI0.LPC0.EC0.VPC0.GBMD
> evaluate \_SB.BAT0._BIX                    evaluate \_SB.PCI0.LPC0.EC0.VPC0.GBMD
>   acquire ECMT [A]
>   serialize \_SB.PCI0.LPC0.EC0.RDIF          serialize \_SB.PCI0.LPC0.EC0.RDER [B]
>   evaluate \_SB.PCI0.LPC0.EC0.RDIF           evaluate \_SB.PCI0.LPC0.EC0.RDER
>     serialize \_SB.PCI0.LPC0.EC0.RDER [B]      acquire ECMT [A]
> 
> That's why merging battery notifications significantly reduced the
> frequency of mutex acquisition timeout.
> 
>> firmware AML mutex that _Qxx EC queries also take, which a wrapper
>> around acpi_evaluate_object() cannot cover, and Rong's notification
>> merging in 7.3 already reduces it on the battery side.
> 
> Lock contention is not the root cause, and EC queries and UCSI _DSM are
> just innocent victims of the ABBA deadlock.

Hmm, ok so since \_SB.BAT0._BIX takes ECMT itself instead of relying
on \_SB.PCI0.LPC0.EC0.RDER taking it (1), this means that not just
the ideapad-laptop GBMD method call but anything calling
\_SB.PCI0.LPC0.EC0.RDER may cause this abba dead-lock, right?
Are we sure nothing else is calling  \_SB.PCI0.LPC0.EC0.RDER ?

Regards,

Hans


1) I guess ACPI mutexes may be taken nested from the same thread