Re: Erroneous sbs-battery sysfs info a MT8173 Chromebook

["Nícolas F. R. A. Prado" <nfraprado@collabora.com>]

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
> [   34.754401] sbs-battery 6-000b: sbs_read_string_data_fallback: Returned block_length is longer than 0x20
> [   34.782568] sbs-battery 6-000b: sbs_read_string_data_fallback: Returned block_length is longer than 0x20
> [   34.806020] power_supply sbs-6-000b: driver failed to report `manufacturer' property: -22
> [   34.826135] power_supply sbs-6-000b: driver failed to report `technology' property: -22
> [   34.844078] sbs-battery 6-000b: sbs_read_string_data_fallback: Returned block_length is longer than 0x20
> [   34.864128] sbs-battery 6-000b: sbs_read_string_data_fallback: Returned block_length is longer than 0x20
> [   34.889015] power_supply sbs-6-000b: driver failed to report `model_name' property: -22
> [   34.895486] power_supply sbs-6-000b: driver failed to report `technology' property: -22
> [   34.945035] sbs-battery 6-000b: sbs_read_string_data_fallback: Returned block_length is longer than 0x20
> 
> These infinitely repeat because upower keeps trying to read them. I also 
> see this which might be important:
> 
> [   18.111500] cros-usbpd-charger cros-usbpd-charger.7.auto: Could not get charger port count
> [   18.197166] sbs-battery 6-000b: sbs-battery: battery gas gauge device registered
> [   18.248105] sbs-battery 6-000b: I2C adapter does not support I2C_FUNC_SMBUS_READ_BLOCK_DATA.
>                Fallback method does not support PEC.
> 
> Properties seem to be stuck to weird values (0xffff ?):
> 
>   $ for f in /sys/class/power_supply/sbs-6-000b/*; do
>       printf "$(basename "$f"):  "
>       cat "$f" 2>/dev/null || echo
>     done
>   capacity:  100
>   capacity_error_margin:  0
>   capacity_level:  Full
>   charge_full:  65535000
>   charge_full_design:  65535000
>   charge_now:  65535000
>   constant_charge_current_max:  65535000
>   constant_charge_voltage_max:  65535000
>   current_avg:  -1000
>   current_now:  -1000
>   cycle_count:  65535
>   device:
>   energy_full:  655350000
>   energy_full_design:  655350000
>   energy_now:  655350000
>   health:  Calibration required
>   hwmon2:
>   manufacture_day:  31
>   manufacture_month:  15
>   manufacturer:  
>   manufacture_year:  2107
>   model_name:
>   of_node:
>   power:
>   present:  1
>   serial_number:  ffff
>   status:  Discharging
>   subsystem:
>   technology:  Unknown
>   temp:  62804
>   time_to_empty_avg:  3932100
>   time_to_empty_now:  3932100
>   time_to_full_avg:  3932100
>   type:  Battery
>   uevent:
>   voltage_max_design:  65535000
>   voltage_min_design:  65535000
>   voltage_now:  65535000
>   wakeup10:
> 
> I suspected a hardware issue, but I can get battery info from the EC 
> just fine with the same kernel:
> 
>   $ sudo ectool battery
>   Battery info:
>     OEM name:               LGC
>     Model number:           L15L3PB
>     Chemistry   :           LiP
>     Serial number:          0E0C
>     Design capacity:        4050 mAh
>     Last full charge:       3341 mAh
>     Design output voltage   11100 mV
>     Cycle count             115
>     Present voltage         11671 mV
>     Present current         344 mA
>     Remaining capacity      2734 mAh
>     Flags                   0x06 BATT_PRESENT DISCHARGING
>   
>   $ sudo ectool version
>   RO version:    hana_v1.1.4824-d58e50539
>   RW version:    hana_v1.1.4825-1473136d99
>   Firmware copy: RW
>   Build info:    hana_v1.1.4825-1473136d99 2021-09-11 00:11:48 @chromeos-ci-firmware-us-central2-d-x32-0-jx9e
> 
> 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.

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.

Thanks,
Nícolas