[Bug 221065] ideapad_acpi: unexpected charge_types spam on Yoga Pro 7 14ASP9

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221065

--- Comment #70 from Rong Zhang (i@rong.moe) ---
(In reply to boite.pour.spam from comment #67)
> I've read all the comments above and I'm trying to understand how the broken
> ACPI tables would work on Windows. If there's a "deadlock" in the ACPI
> implementation, 

How did you conclude that? No one had mentioned "deadlock". The issue is about:

#1. Errors in mutex acquisition are propagated blindly
#2. Some ACPI methods release a mutex owned by others

I think my conclusion is clear enough:
https://bugzilla.kernel.org/show_bug.cgi?id=221065#c33

> how does Windows works around it? 

Just ask Microsoft and Lenovo.

TBH, comparing Linux to Windows in that way is hardly helpful. On Windows, the
ideapad ACPI methods are used by Lenovo Vantage (or something else), which is a
userspace program. It probably doesn't query charge types after power events,
but blindly assumes nothing has changed. It probably doesn't check ACPI return
values to see if they are insane, but propagates them blindly again. I don't
think "Windows works around it," as burying one's head in the sand works around
nothing.

> If I understand correctly, the solving options are:
> 1. Have Lenovo to fix the ACPI tables (which is very unlikely)
> 2. Implement a "live" ACPI fix with a DSDT override but it won't fix the bad
> releasing of the ACPI's mutex

Again, how did you conclude that? If you used an AI to "help" you understand
the thread, you probably chose the wrong AI.

The easiest thing to fix is, however, "bad releasing" (#2). Just delete or move
several lines of ASL code, and that's it.

But most of the issues here are caused by #1. It generates a lot of garbage
return values, and there's no easy way to distinguish them afterward. Every
method that recursively depends on ECMT must be rewritten, which means that not
only the DSDT, but also some SSDTs, need to be overridden.

I've almost said the same in
https://bugzilla.kernel.org/show_bug.cgi?id=221065#c41

> (but we can probably live with it, since,
> except for the dmesg noise, doesn't break anything)

The error messages generated by ideapad-laptop don't break anything either.
They're harmlessly noisy right after power events, but everything should work
well once the events settle.

> 3. Blacklist both usci_acpi and ideapad-laptop, so that there aren't any
> contender on the mutex anymore, but I'm not clear about what's lost when we
> do so?

It's usually OK to blacklist usci_acpi. Most Lenovo laptops have most USCI
commands stubbed to a certain extent, so they're hardly useful. The EC will
always handle USB-C events itself despite that.

You don't need to blacklist ideapad-laptop if you can live with harmless dmesg
noise.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.