So this problem is specific to this package and not general DKMS on aarch64 architekture?
Edit: I’m asking because it’s not the only package I’ve tried for this dongle, I’ve also installed the same driver I’m using now from github and there was this error every time. The github project is not for aarch64 only, neither the AUR package.
I was not using a wall charger, only the powerbank with USB-C output with Power Delivery support and USB type A with some kind of fast charging that works with most devices.
Edit: I’ve swtiched back to the linux-pinebookpro because on the newer kernel the charging modes which were working, they have lower currents (between 1,5A and 1,7A) then before (around 2A ± 0.2A).
I’m monitoring some text files in /sys/bus/i2c/devices/4-0022/typec/port0/ directory, currently orientation, device_role, power_role and power_operation_mode. I’m using conky with a small binary that reads these files and do some text formatting to work better with my conky. Here is the source code in C++:
#include <iostream>
#include <fstream>
#include <sstream>
#include <iomanip>
#include <string>
using namespace std;
const string MASTER_PATH = "/sys/bus/i2c/devices/4-0022/typec/port0/";
const string DATA_ROLE_F = "data_role";
const string ORIENTATION_F = "orientation";
const string PORT_TYPE_F = "port_type";
const string POWER_OPERATION_MODE_F = "power_operation_mode";
const string POWER_ROLE_F = "power_role";
const string PREFERRED_ROLE_F = "preferred_role";
const string SUPPORTED_ACCESSORY_MODES_F = "supported_accessory_modes";
const string UEVENT_F = "uevent";
const string USB_POWER_DELIVERY_REVISION_F = "usb_power_delivery_revision";
const string USB_TYPEC_REVISION_F = "usb_typec_revision";
const string VCONN_SOURCE_F = "vconn_source";
constexpr int FILENAMES_SIZE = 4;
const string FILENAMES[FILENAMES_SIZE] = {ORIENTATION_F, DATA_ROLE_F, POWER_ROLE_F, POWER_OPERATION_MODE_F};
const string SHORTCUTS[FILENAMES_SIZE] = {"O", "DR", "PR", "POM"};
bool printFromFile(const int index);
int main()
{
for(int i = 0; i < FILENAMES_SIZE; i++)
{
bool result = printFromFile(i);
if(i < FILENAMES_SIZE - 1){
if(i == 2 || i == 3 || i == 6)
cout << endl;
}
if(!result)
break;
}
cout << endl;
return 0;
}
bool printFromFile(const int index)
{
cout << SHORTCUTS[index] << ":";
ifstream file;
file.open(MASTER_PATH + FILENAMES[index]);
if(!file){
cout << "!file ";
}
else{
stringstream stringStream;
stringStream << file.rdbuf();
file.close();
string contents = stringStream.str();
if(!contents.empty() && contents[contents.length() - 1] == '\n'){
contents.erase(contents.length() - 1);
}
int openBracket = contents.find('[');
int closeBracket = contents.find(']');
if(openBracket != string::npos && closeBracket != string::npos && openBracket < closeBracket){
string strbetween = contents.substr(openBracket+1, closeBracket-openBracket-1);
contents = strbetween;
}
cout << contents << " ";
if(index == 0 && contents == "unknown")
return(false);
else
return(true);
}
}
Feel free to modify it. It doesn’t need any special permissions, just reads the files that are already accessible for your user. I’ve just rattled it off and I’m not very proud of it.
I believe that it is some standard, I just can’t for the life of me remember right now. But yes, if they can’t find it then it’ll at the very minimum put them out of commission until they could find a replacement (which could be a long time). Worst case is you’re right and it essentially bricks.
Now, I still haven’t tried charging via USB-C with it off since this update. I’ll do that tonight and report. Could at least save some folks some headache.
EDIT: Two examples of adapters I’ve found that should be compatible:
https://www.amazon.com/atolla-Standard-Adaptor-External-Positive/dp/B01DPCPAQS (this one has the same output as the shipped charger)
Hey, it’s handy. Thank you.
(I am replying directly to messages but for some reason it seems it’s placing all of my messages as generic replies to the topic.)
Thank you, I encountered the same problem.
The workaround by changing kernels works for me.
I no longer have the original charger since a feline attack.
It would be safer to buy a new one. 
So, there is a charging issue with this update and the PinebookPro when using the kernel linux but not the (older) linux-pinebookpro?
I flashed latest KDE image updated but Kernel still 5.4.x on Pi4 and cannot see Kernel updater in Settings Manager. How to get to latest Kernel?
The default kernel provided by Raspberry Pi is the 5.4 branch.
You can install linux-rpi4-mainline to get 5.9 or linux-rpi4-rc to get 5.10-rc7.
Sorry am new to this but what’s the command if I may ask?
If you are new, you have no reason to want to switch the most critical piece of the system.
I would recommend you stay on 5.4, since it’s a Long Time Support release.
It will get updated to 5.10 eventually, when Raspberry Pi foundation updates their default kernel branch to the new LTS.
I am testing. I wanna try few things out. Please let me know command if you don’t mind. Thanks
sudo pacman -S linux-rpi4-mainline
or
sudo pacman -S linux-rpi4-rc
To get back to the default kernel:
sudo pacman -S linux-rpi4
Much appreciated my friend 
Yes that’s right.
Problem: No longer receiving text messages (SMS). (Sending works fine.)
Carrier: T-Mobile
Country: USA
Installation: Default Pinephone Manjaro Community Edition, fully up-to-date (normally, I update by ‘sudo pacman -Syyu’ with SSH)
The problem started only in the past few days.
Thoughts, anyone? I do not see anything in the ‘known problems’ so far in this thread.
EDIT: This does not have anything to do with the Manjaro update. It is a known problem with the PinePhone handling modems. I have updated the relevant section of the PinePhone FAQ with exact directions for the PinePhone Manjaro CE, which differ slightly from that of the PinePhone with Mobian.
I think you’re right.
I just read something about calls not working on some network provider and there seem to be a temporary fix.
Check this Plasma mobile release post for the fix.
Thank you for the tip. This is actually a different problem, but it is very good to know about the post regarding fixing different modem problems with Manjaro…
For the problem with regard to being able to send SMS messages but not receive them, which is not Manjaro’s problem but, rather, seems to have something to do with ModemManager, see PinePhone FAQ 2.7.1.
Short version:
sudo mmcli -m 3 --messaging-list-sms
Then delete each listed message by number, e.g.:
$ sudo mmcli -m 3 --messaging-delete-sms=77
Repeat with all listed messages.
Hey, did you try charging the Pinebook Pro while turned off? Does it work?