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
Conversation
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
honestly I just find the normal part of the AOSP build system bad enough, the thought of doing something with the kernel instills dread
1
6
(it's the LineageOS kernel build integration, I have absolutely no idea how it works)
1
1
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
I don't like running a totally separate build system within the AOSP build system. It takes a ridiculous amount of time and memory to link the Linux kernel with full LTO and it doesn't use kati so it doesn't handle incremental builds well so I really prefer the AOSP approach.
1
4
Why LTO? Does it have extended hardening properties or is it just 3% optimizing non-bottlenecks?
2
Pixels build the kernels with Clang CFI which requires LTO. If you disable dynamic kernel modules, set -fvisibility=hidden as the default and avoid using ThinLTO, you get much better CFI granularity because it can see that nearly everything can't be indirectly called.
2
3
It's infuriating that this needs LTO because conceptually there's no reason it couldn't just be normal linking with some extended symbol markup.
1
Compiling vs linking is the most critical scalability boundary and compiler folks are determined to tear it down because they love their fancy toy (LTO) and keep building all the actually useful stuff on top of it to push it.
2
The main issue is that with a non-static function, anything in the rest of the program could be taking the address and calling it. Clang/LLVM build a bunch of CFI metadata and optimize it efficiently. If they can see a function can't be indirectly called they end up enforcing it.
The main advantage we're getting from using full LTO is that most non-static functions never have their address taken and by using full LTO we end up enforcing that they can't be indirectly called via CFI. It also substantially reduces CFI overhead so more than usual benefits.
3