Conversation

Replying to and
I think your best bet to figure out if this is the issue is disabling the module in your kernel build and disabling the sanity checks for kernel module loading so that the init scripts in vendor can successfully load the stock OS build of the HTC battery module from there.
1
2
It's entirely possible to build it as a dynamic kernel module and include it in vendor, but it's easier to build it into the kernel which is why most aftermarket OS builds take that approach. Stock OS uses dynamic modules to optimize loading time and make kernels more generic.
1
1
It's a recurring issue that we deal with across a bunch of drivers. The drivers only work if their firmware and configuration files are usable when they're initialized and they often assume that those are available when they're loaded. If built into the kernel, they're broken.
2
4
Replying to and
this... requires enough effort that I might just live with partially broken charging. especially given that I still haven't fixed the problem with the USB3 pairs in the connector that makes `adb sideload` very hard to use
1
1
Replying to and
Based on that error message, I'm fairly certain that the battery driver or battery is the issue though. If you look at drivers/power/htc_battery.c, you can see it's involved in negotiating the charging rate. Since there's thermal throttling, etc. batteries are very involved.
2
2
Replying to and
We use the AOSP way of building it separately and including it in the AOSP build as a prebuilt. Qualcomm has always included a way to run the kernel build in-tree via a wrapper in each kernel source tree as a hack for development. LineageOS turned that into a generic system.
2
2