https://bugzilla.kernel.org/show_bug.cgi?id=221866
--- Comment #21 from David Del Sol ([email protected]) --- Correction to the kernel-version hypothesis above (I overstated it): the slow state is INTERMITTENT, not kernel-determined. Identical conditions re-run on 7.1.6 now returned full charging (~32 W at 66%), whereas the earlier first-run-on-7.1.6 slow reading was 2.5 W. So: same kernel, same hard-reset, same stock cmdline, same SoC รข one fast, one slow. The reliable facts: - The firmware selects the charge profile during early EC initialization: AC present at EC power-on tends to select a low-current profile, AC inserted after boot selects full current; the choice is then latched in EC RAM across warm reboots and power cycles until the 30 s hard reset (which also resets the BIOS settings, explaining why Secure Boot must be re-enabled). - The one behavior that IS deterministic on both 7.1.6 and 7.1.8: boot without the charger, plug it in after the OS is up -> ~31-33 W every time. That is the reliable workaround. - acpi_osi= is a coincidence artifact (Linux default-claims Windows 2022; firmware has no _OSI("Windows 2022") checks; only Windows 2009/2015 -> TSOS). So this is best tracked as a firmware/EC quirk with a boot procedure workaround, not a kernel regression. Withdrawing the patch and the ACPI/OSI approach remains correct. Stopping hard-resets is advisable since each wipes BIOS settings. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
