#927163 linux-image-4.19.0-4-amd64: Missing modules for AXP288 power fuel gauge driver

Package:
src:linux
Source:
linux
Submitter:
Marcus Lundblad
Date:
2022-05-30 13:15:05 UTC
Severity:
wishlist
Tags:
#927163#5
Date:
2019-04-15 19:20:45 UTC
From:
To:
Dear Maintainer,

In #895129 axp288_fuel_gauge was included as a module for x86 platforms.
After that the battery icon was actually showing on my Cherrytrail tablet.
But since then, this has again stopped working (and I'm not sure it was
actually reporting a correct state), and also it never detected the AC power
being connected. I believe there are still some missing stuff to get this
working.

Looking at a commit for ARM I can see this:
https://salsa.debian.org/kernel-team/linux/commit/0138e6bc4eedd8c10ad637e742a4fe6c625c6def

There seems to be some additional things in there.

AXP20X_ADC, CHARGER_AXP20X, BATTERY_AXP20X, GPIO_AXP209,
AXP288_CHARGER, EXTCON_AXP288, AXP288_ADC

Also, looking at the kernel source, there seems to be a case where
the axp288_fuel_gauge module waits for axp288_adc to load (this module
is currently not built for x86):

https://github.com/torvalds/linux/blob/dc4060a5dc2557e6b5aa813bf5b73677299d62d2/drivers/power/supply/axp288_fuel_gauge.c#L774

This probing code was appearantly added late 2017 (so, possibly that code
wasn't in the kernel that was first released in Debian with the
axp288_fuel_gauge module on x86, which might possibly explain why I saw
the inaccurate reading (I recall it always reporting 100%).

Thanks,
//Marcus

#927163#10
Date:
2019-04-18 10:00:35 UTC
From:
To:
Hello Marcus Lundblad,
I don't know if it is related - I own a Baytrail
device that contains also these axp devices.
Back in late 2017 I got some help from Hans de Goede,
who worked that time in that area.
There my battery information was also missing with
the stock debian kernel.

He suggested to build a kernel with the config from a
"v4.14-footrail" branch from following repo first.
https://github.com/jwrdegoede/linux-sunxi/

I could reduce the differences to following:

#        Note on x86 this provides an ACPI OpRegion, so this must be 'y'
#        (builtin) and not a module, as the OpRegion must be available as
#        soon as possible. For the same reason the I2C bus driver options
#        I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_BAYTRAIL must be 'y' too.
#    I2C_DESIGNWARE_PLATFORM=y
#    I2C_DESIGNWARE_BAYTRAIL=y
#    MFD_AXP20X_I2C=y

Could this be relevant for Cherrytrail too?

Kind regards,
Bernhard

#927163#15
Date:
2022-04-18 15:20:51 UTC
From:
To:
Control: tag -1 moreinfo

commit d5c998412628563e86efc90c3ff1be01b0bd397f, part of kernel 5.8
changed PLATFORM to 'y', which in turn (likely) turned CORE into 'y' too

and I guess this one too (it isn't explicitly set, but it is 'y' on the oldest
5.10 amd64 kernel I have installed

These are still 'm' on my oldest 5.10 amd64 kernel ...
(got enabled in 95cf0f2687b7e3efb84a508028167bcc8680a5d3 to fix #895129)

I suspect that this was the crucial missing piece ...
of the 5.10 kernels (previously it was only enabled on arm64 and armhf).

Tino and Markus:
Can you verify whether the issue is fixed with a 5.10+ kernel?

#927163#22
Date:
2022-04-21 06:47:23 UTC
From:
To:
Problem is solved with a recent bullseye kernel. Thanks for working on this!
#927163#27
Date:
2022-05-30 13:11:40 UTC
From:
To:
Version: 5.10.1-1~exp1

Tino already confirmed it was fixed (#964181) and I'm quite sure this is the
same issue. As there hasn't been a response in >1 month, I'm closing this
issue with the same kernel version as well.

If you believe the issue is still present, feel free to reopen this issue.