linux-kernel - Re: Erroneous sbs-battery sysfs info a MT8173 Chromebook

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ae30adc7-8bcf-4daa-923a-d4a12e2404ea@gmail.com>
Date: Fri, 4 Oct 2024 01:27:50 +0300
From: Alper Nebi Yasak <alpernebiyasak@...il.com>
To: Nícolas F. R. A. Prado <nfraprado@...labora.com>
Cc: chrome-platform@...ts.linux.dev, linux-pm@...r.kernel.org,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Sebastian Reichel <sre@...nel.org>, Benson Leung <bleung@...omium.org>,
 Guenter Roeck <groeck@...omium.org>, Tzung-Bi Shih <tzungbi@...nel.org>,
 Pin-yen Lin <treapking@...omium.org>, linux-mediatek@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: Erroneous sbs-battery sysfs info a MT8173 Chromebook

Hi,

On 2024-10-03 19:08 +03:00, Nícolas F. R. A. Prado wrote:
> On Thu, Oct 03, 2024 at 06:15:49PM +0300, Alper Nebi Yasak wrote:
>> Hello,
>>
>> I have a MT8173 Chromebook ("Lenovo 300e") where I'm getting a lot of 
>> battery-related errors:
>>
>> [   34.678473] sbs-battery 6-000b: sbs_read_string_data_fallback: Returned block_length is longer than 0x20
>> [   34.702079] power_supply_show_property: 5 callbacks suppressed
>> [   34.702096] power_supply sbs-6-000b: driver failed to report `technology' property: -22
>> 
>> [...]
>>
>> I have _another_ MT8173 Chromebook ("ASUS C202X") where things work 
>> fine. But I couldn't find a good mainline kernel version for this one.
>> Anyone have any idea what is going on?
> 
> FWIW, I have also experienced issues reading properties from the SBS batteries
> before on chromebooks:
> 
> https://lore.kernel.org/all/924db470-8163-4454-8f59-f7372a132186@notapiano/
> 
> In those cases it was due to the EC firmware not implementing the SBS commands,
> but that had already been fixed in the latest EC firmware release, so simply
> updating the firmware fixed it.

(Replied there as well for a different board: cozmo)

> I don't know how ectool works, but it might be fetching the battery properties
> through a different mechanism (ie not SBS commands), so this might also be a bug
> in the EC FW despite ectool working.

AFAICT, ectool talks to /dev/cros_ec with EC commands, which makes EC 
send SBS commands to the battery on its own; whereas in the kernel 
driver case it passes kernel's SBS commands through the i2c tunnel.

But never mind all that, I should've looked into ChromeOS kernel 
sources. There's a limited i2c passthrough [1] that's implemented there. 
And this specific battery is failing to recognize a read command due to 
a stop bit or something, so they use this limited passthrough [2]. I've 
managed to apply those on top of linux-next and it makes things work, 
but I have no idea how I'd go about upstreaming it (comments on [1] 
point out it's quite hacky and not used in later boards).

[1] CHROMIUM: i2c: wire a limited smart battery passthrough
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2230594

[2] CHROMIUM: arm64: dts: mt8173-hana: Add google,limited-passthrough property
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/422609