Re: [PATCH] ACPI: EC: Set ec_no_wakeup for Lenovo Go S

[Xino Ni <phnjs211@gmail.com>]

> Hi Xino,
> no problems from my side. We tried our best to have it work but
> sometimes life has it some other way. There is also no problem with
> submitting the patch now, a month before or a month after. The
> attribution is how it should be now, and that was the only problem, so
> it's ok.

Thanks again.

I'd like to share more progress in the debug:

After the BIOS implement standard _BTP method, the sleep-to-dead issue
is not happen again when battery is fully charged, and the fake sleep
heat problem is fixed also. But we observed OS crash to reboot directly
when wake up, same as you observed.

So you are right, the issue can be divided into three parts:
1. _BTP make the OS wake up time to time
2. Touch Panel signal gating device sleep again
3. something from EC/BIOS crashed the OS when wake up

We failed to resolve below two issues, and thanks to the ec_no_wakeup
quirk, we never encounter below two issues after introducing it.

Xino

On 4/1/2025 10:46 PM, Antheas Kapenekakis wrote:
> On Tue, 1 Apr 2025 at 16:17, Xino Ni <phnjs211@gmail.com> wrote:
>>
>>
>>
>> On 4/1/2025 5:01 PM, Antheas Kapenekakis wrote:
>>> Anyways, you got what my problem here was. You nacked and bikeshed
>>> this patch for 2 months, and that was after I did all the background
>>> research, testing and deployed it [1], so you could find the real
>>> cause, which I let you do as a _professional courtesy_. Then, out of a
>>> sudden you are the primary author on a patch I authored and you nacked
>>> and started testing after it was done [2].
>>>
>>> I guess a nicer way of saying this is that you make it hard to
>>> collaborate on kernel development. When I bring up issues to you, do
>>> the background research, bisect, and general grunt work for them, you
>>> do a minor cleanup which is easy for you as a kernel developer, then
>>> strip the credit for them and I have to hunt you down to get some of
>>> it back. This is not a productive environment, I cannot work like
>>> this.
>>>
>>> I think this is the 6th or 8th time this happened but this time it is
>>> particularly egregious, because you had me spend 20 hours debugging
>>> offshoots after my patch was already done in random directions trying
>>> to find a real cause, only to see me get dropped to a normal reported
>>> by, and that is after I told you off very harshly because of [2].
>>> Otherwise the reported-by might have been missing too.
>>>
>>> In any case, there is no point in rehashing this over and over.
>>> Authorship in this series is mostly fine now, so it can go through.
>>>
>>> And to avoid having this conversation again, there is another Legion
>>> Go S [3] patch you nacked and froze the testing for, so you could go
>>> on the manhunt for the real cause of this one. But it will probably be
>>> needed and you will find that as you get TDP controls going. So if you
>>> want me to prepare that in a timely manner, because that one actually
>>> needs rewriting to be posted, now is the time to say so.
>>>
>>> Antheas
>>>
>>> [1] https://github.com/bazzite-org/kernel-bazzite/releases/tag/6.12.12-201
>>> [2] https://gitlab.com/evlaV/linux-integration/-/
>>> commit/6c5a3a96be9b061f07bf9a1bcc33156c932ddf67
>>> [3] https://gitlab.freedesktop.org/drm/amd/-/issues/3929#note_2764760
>>
>> Dear Antheas,
>>
>> Thanks for all the amazing works and advice you have contributed to
>> Legion Go S not only in the kernel but also the HHD, I'm honored to have
>> you help on the product.
>>
>> I'd say it's unfair to blame Mario for this patch submission because
>> it's actually my request to him and it's my failure on ODM management
>> that cannot fix these FW/EC/BIOS wake up issues, we have to submit the
>> patch to upstream as next kernel cycle begins.
>>
>> Further more, I'm very grateful to the specific issue you have spend a
>> lot of personal time on it, you gave a very important guidance in issue
>> debugging and help us clarify the root cause.
>>
>> As the project is the first time I work with the community, definitely I
>> have a long way to learn how to work together and manage the
>> development, so please forgive me on it.
> 
> Hi Xino,
> no problems from my side. We tried our best to have it work but
> sometimes life has it some other way. There is also no problem with
> submitting the patch now, a month before or a month after. The
> attribution is how it should be now, and that was the only problem, so
> it's ok.
> 
> Antheas
> 
>> B/R
>> Xino
>