I've tried plugging it into a PD power source. absolutely nothing happens. no charging, no PD messages, nothing.
¯\_ (ツ)_/¯
Conversation
Which phone model is it? I might actually have the solution to your problem.
1
2
For the Pixel 2 XL, the issue we had is that the LG battery kernel module was broken when built into the kernel instead of loaded as a dynamic kernel module. I'd guess that you're using an OS build with it built into the kernel and maybe it's missing appropriate workarounds.
2
2
13
The non-XL Pixel 2 has an HTC battery kernel module. It's possible that it has a similar issue. We had a couple fixes applied for the Pixel 2 XL. The issue that I used to have is that fast charging wouldn't kick in with a generic charger or USB-C to the computer.
2
4
yeah that sounds exactly like what i'm experiencing. i think i've only seen fast charging with power banks and such. it's non-XL.
1
1
I don't think we had a commit fixing it for the non-XL variant but I remember it being an issue. It's probably a similar issue. In my experience, both in-tree and out-of-tree Linux kernel driver modules are often broken when built into the kernel instead of dynamically loaded.
1
2
It's easier to build them into the kernel than dealing with building modules and putting them in vendor. For GrapheneOS we can't even do that as a workaround for issues like this because we want dynamic kernel modules disabled. Easiest solution is probably dynamically loading it.
1
1
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.
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
Show replies