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

[Rong Zhang <i@rong.moe>]

Hi Ali,

On Wed, 2026-10-14 at 18:05 +0300, Ali Ahmet Memiş wrote:
> On Wed, Oct 14, 2026 at 03:45:10PM +0200, Hans de Goede wrote:
> > Hmm, I wonder if we should export the lock added in patch 1/3 and
> > then also take that in the ACPI EC interrupt handler ?
> > 
> > The ACPI code already uses a threaded IRQ handler for both EC GPIO
> > IRQs and GPEs so sleeping in the handler should be ok.
> 
> Sleeping is fine, but the interrupt handler completes the EC
> transactions, so taking the lock there would deadlock an exclusive
> _BST.  Doing it in acpi_ec_event_processor() where the _Qxx methods
> are evaluated, works though.  With the brightness key queries also
> running the \GTST copy, 283 of 891 _BST reads were broken without it
> and 0 of 804 with it.
> 
> > I'm just thinking that if we're going to do this it would be nice to
> > cover the bko221065 UCSI case too.
> 
> UCSI and _Qxx alone aren't enough there.  I emulated the ECMT users
> from the 83DR tables and the EC helpers kept waiting up to ~680 ms of
> their 1 s timeout behind GBMD/SBMC until the ideapad methods were
> exclusive too.

Nah. Emulation doesn't count at all.

Without a real EC, any call to ECCC or RDER (called by GBMD and SBMC)
times out because CMDB is never reset to 0:

        CMDB = Arg0
        Local0 = 0x0100
        While ((Local0 && CMDB))
        {
            Sleep (0x02)
            Local0--
        }

Thus, any call to ECCC or RDER consumes at least 200ms in emulation, but
in reality it doesn't.

If the EC is really stuck for such a long time in reality, the platform
will shut down or reset itself.

Thanks,
Rong

> 
> > Note this is something which can be done on top of this set.
> 
> I can send a series on top of this one for the EC queries, UCSI and
> ideapad if that sounds good.