Laptop (T490) does not reliably detect change from AC to BAT

Hello forum,

i got a problem with my T490 - it does not reliably and in time detect that AC is unplugged.
If I remove the AC (which is USB-C on this machine) it does not detect - mostly after a view minutes it does - sometimes it does not.

The other way round - from BAT to AC is immediately recognized.

The running kernel is 5.8.5-2 but same is true for 5.7.19-2.

When I unplug I get these messages:

dmesg -w
[14377.052592] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.RP09.PEGP.NVDN], AE_NOT_FOUND (20200528/psargs-330)
[14377.052628] ACPI Error: Aborting method \_SB.PCI0.LPCB.EC._Q27 due to previous error (AE_NOT_FOUND) (20200528/psparse-529)

udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[14375.189343] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV  [14376.106619] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)

If at some point the system recognises its in BAT mode now I get this additional messages in udevadm:

udevadm monitor
KERNEL[14496.031770] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight)
UDEV  [14496.033668] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight)

But tlp for example does not switch into BAT mode then still

tlp-stat -s
--- TLP 1.3.1 --------------------------------------------

+++ System Info
System         = LENOVO ThinkPad T490 20N2004AGE
BIOS           = N2IET90W (1.68 )
Release        = "Manjaro Linux"
Kernel         = 5.8.3-2-MANJARO #1 SMP PREEMPT Sat Aug 22 12:35:25 UTC 2020 x86_64
/proc/cmdline  = BOOT_IMAGE=/boot/vmlinuz-5.8-x86_64 root=UUID=fc4a43ed-568f-4c5f-b70e-267676a30677 rw i915.modeset=1 i915.fastboot=1 nmi_watchdog=0 nowatchdog cryptdevice=UUID=82dce2e7-d80f-4317-a9d9-458ce4bd1e52:luks-82dce2e7-d80f-4317-a9d9-458ce4bd1e52 root=/dev/mapper/luks-82dce2e7-d80f-4317-a9d9-458ce4bd1e52 apparmor=1 security=apparmor resume=/dev/mapper/luks-dae8d075-4f8e-4bdd-a837-b2e5053c1bf3 udev.log_priority=3
Init system    = systemd 
Boot mode      = UEFI

+++ TLP Status
State          = enabled
RDW state      = enabled
Last run       = 08:03:01,    262 sec(s) ago
Mode           = AC
Power source   = battery

But if I run tlp start it will correctly restart in BAT mode. (PS: TLP is just a side effect it seems as I already purged and reinstalled it with fresh config)

Any ideas where else to look for debugging or even an idea how to fix it? =)

I had a somewhat similar problem - backing to kernel 5.7 fixed it

Have you tried any other kernel since? I mean its a fix - for now, as 5.7 just got declared EOL - but nothing that will last for ever.
I will give 5.4 a try - if that works it will be a pain to find a kernel regression I fear.

Have you explored the possibility of a hardware issue? Maybe seeing if it changes even in system bios with charge/power lights on the system? Different power adapter?

I ask because I had something similar on an Asus Zenbook UX31e and it turned out that I had to replace the barrel jack on the laptop – it was starting to break from such a tiny barrel and the torquing in usage over the years.

Indeed, that was my very first worry as this was why I had to get the T490 in the first place as my T450s experienced a fatality in the power-delivery circuit and did not charge anymore.
I ruled that out, it does charge, it does register the charger (after all after some minutes also the OS does eventually) and if turned off (so only the baseboard controller running) it does as it should, same if kept in the BIOS or in GRUB.

I tried 3 Lenovo OEM USB-C powerbricks, on each of the two avaliable USB-C ports of the machine so can rule a AW fault out as good as I can.

tl;dr - the only obvious differences between working and not working hide here.

The only thing changed between kernels 5.8.5-2 and 5.4.61-1 is in udevadm monitor:

KERNEL[368.816512] change   /devices/platform/USBC000:00/typec/port1 (typec)
KERNEL[368.816544] remove   /devices/platform/USBC000:00/typec/port1/port1-partner (typec)
UDEV  [368.820110] change   /devices/platform/USBC000:00/typec/port1 (typec)
UDEV  [368.821909] remove   /devices/platform/USBC000:00/typec/port1/port1-partner (typec)

Alright, now that I am back at the LTS kernel (5.4.61-1) it does work and the outputs are as follows for unplugging AC:

udevadm monitor 
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[368.694774] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[368.816512] change   /devices/platform/USBC000:00/typec/port1 (typec)
KERNEL[368.816544] remove   /devices/platform/USBC000:00/typec/port1/port1-partner (typec)
UDEV  [368.820110] change   /devices/platform/USBC000:00/typec/port1 (typec)
UDEV  [368.821909] remove   /devices/platform/USBC000:00/typec/port1/port1-partner (typec)
UDEV  [368.987101] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[369.004287] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight)
UDEV  [369.006753] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight)
dmesg -w
[  369.433662] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.RP09.PEGP.NVDN], AE_NOT_FOUND (20190816/psargs-330)
[  369.433688] ACPI Error: Aborting method \_SB.PCI0.LPCB.EC._Q27 due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
journalctl -f
Sep 02 17:24:16 hk-01 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.RP09.PEGP.NVDN], AE_NOT_FOUND (20190816/psargs-330)
Sep 02 17:24:16 hk-01 kernel: ACPI Error: Aborting method \_SB.PCI0.LPCB.EC._Q27 due to previous error (AE_NOT_FOUND) (20190816/psparse-529)

and for plugging AC back in:

udevadm monitor
KERNEL[459.123779] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[459.275711] change   /devices/platform/USBC000:00/typec/port1 (typec)
KERNEL[459.275782] add      /devices/platform/USBC000:00/typec/port1/port1-partner (typec)
UDEV  [459.281817] change   /devices/platform/USBC000:00/typec/port1 (typec)
UDEV  [459.286295] add      /devices/platform/USBC000:00/typec/port1/port1-partner (typec)
UDEV  [462.492093] change   /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
KERNEL[462.513504] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight)
UDEV  [462.516600] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight)
dmesg -w
[  459.845868] ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.RP09.PEGP.NVDN], AE_NOT_FOUND (20190816/psargs-330)
[  459.845893] ACPI Error: Aborting method \_SB.PCI0.LPCB.EC._Q26 due to previous error (AE_NOT_FOUND) (20190816/psparse-529)
journalctl -f
Sep 02 17:25:47 hk-01 kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.RP09.PEGP.NVDN], AE_NOT_FOUND (20190816/psargs-330)
Sep 02 17:25:47 hk-01 kernel: ACPI Error: Aborting method \_SB.PCI0.LPCB.EC._Q26 due to previous error (AE_NOT_FOUND) (20190816/psparse-529)

So it seems as only thing changed is running kernel it lies in there? Anyone any idea how to further debug that? I mean I am not new to Linux but neither a dev…

Hello - its me again. Newest findings after trying around a bit more. The problem is caused by booting without the AC (USB-C) beeing atached to the system.

When the machine boots without the power-brick atached two devices are missing from “gnome-power-statistics”:
line_power_ucsi_source_psy_USBC000o001
and
line_power_ucsi_source_psy_USBC000o002
in that case only

line_power_AC

is present and the change in AC/BAT is not detected.

If these two USB devices are present only the USBC000o002 ever changes its “Online” value to true. The USBC000o001 never changes no mater which of the systems two USBC ports I plug the charger into.

I have quite similar issue on my Xiaomi MiNotebook Pro aka TM1701.
This is caused by the updates in USB driver introduced in linux 5.8.

The situation is different from yours though. When I boot without power cable attached, the laptop properly detects that it’s on battery, and USBC000o001 is NOT online, plugging a cable in changes mode to AC, out - battery again, this is a correct behavior. However, when booting WITH cower cord attached, USBC000o001 never changes its online state – it is always on whatever I do, and that gets in a way of proper switching of power plans.

1 Like

Than I guess we are in to hope it will get fixed upstream/kernel soonish™ becaus its terrible anoying specially as more and more Laptops switch to USBC power -.-

I’ve already talked to kernel devs, they made a patch that worked for me, hope they will commit it soon.
First try this, if you’re OK with patching and building kernel yourself: [PATCH 0/2] UCSI race condition resulting in wrong port state - Benjamin Berg
That’s probably is about your issue.

Thank you!

I will see if I can read me into that - have never done that before; But to be honest, have coped with it long enough to potentially sit through it till the end XD

Thanks a lot for making sure this gets fixed!

1 Like

Oh no, don’t thank me. Real heroes are those people who fix bugs in code (after they introduce them lol). I’m just an annoying person begging for a “feeeeeeeeeks pleeeeeease” :pray: :rofl:

1 Like

So the fix is in linux 5.10-rc4 now. Try switching to Unstable branch and wait for Manjaro’s kernel update.

1 Like

Ok cool, but that means the 5.10 rc4 thats now in the repos isnt yet patched?
Edit: 5.10.rc4.d1115.g09162bc-1 that is what I mean

$ git log

commit 09162bc32c880a791c6c0668ce0745cf7958f576 (HEAD -> master, tag: v5.10-rc4, origin/master, origin/HEAD)
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Nov 15 16:44:31 2020 -0800

    Linux 5.10-rc4

09162bc

09162bc

Just install it and check if your issue is gone.

Sadly not gone - now “line_power_AC” and “line_power_ucsi_source_psy_USBC000o001” are stuck at “online = yes” and system stays in AC mode no mather what.

You should really try updating your BIOS, installing and enabling acpid, and if no luck – contacting kernel devs with a bugreport.

1 Like

But the easiest thing you can do is to build 5.10-rc4 with Ben’s patches and install it::

  1. Go to https://gitlab.manjaro.org/packages/core/linux510 and look around
  2. Clone the repository with git clone https://gitlab.manjaro.org/packages/core/linux510.git
  3. Save the following to 0001.patch and 0002.patch:
0001.patch
From: Benjamin Berg <benjamin@sipsolutions.net>
To: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guenter Roeck <linux@roeck-us.net>,
	linux-kernel@vger.kernel.org, Benjamin Berg <bberg@redhat.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Subject: [PATCH 1/2] usb: typec: ucsi: acpi: Always decode connector change information
Date: Fri,  9 Oct 2020 16:40:46 +0200
Message-ID: <20201009144047.505957-2-benjamin@sipsolutions.net> (raw)
In-Reply-To: <20201009144047.505957-1-benjamin@sipsolutions.net>

From: Benjamin Berg <bberg@redhat.com>

Normal commands may be reporting that a connector has changed. Always
call the usci_connector_change handler and let it take care of
scheduling the work when needed.
Doing this makes the ACPI code path identical to the CCG one.

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Benjamin Berg <bberg@redhat.com>
---
 drivers/usb/typec/ucsi/ucsi_acpi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
index fbfe8f5933af..04976435ad73 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -103,11 +103,12 @@ static void ucsi_acpi_notify(acpi_handle handle, u32 event, void *data)
 	if (ret)
 		return;
 
+	if (UCSI_CCI_CONNECTOR(cci))
+		ucsi_connector_change(ua->ucsi, UCSI_CCI_CONNECTOR(cci));
+
 	if (test_bit(COMMAND_PENDING, &ua->flags) &&
 	    cci & (UCSI_CCI_ACK_COMPLETE | UCSI_CCI_COMMAND_COMPLETE))
 		complete(&ua->complete);
-	else if (UCSI_CCI_CONNECTOR(cci))
-		ucsi_connector_change(ua->ucsi, UCSI_CCI_CONNECTOR(cci));
 }
 
 static int ucsi_acpi_probe(struct platform_device *pdev)
-- 
2.26.2 
0002.patch
From: Benjamin Berg <benjamin@sipsolutions.net>
To: linux-usb@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guenter Roeck <linux@roeck-us.net>,
	linux-kernel@vger.kernel.org, Benjamin Berg <bberg@redhat.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Subject: [PATCH 2/2] usb: typec: ucsi: Work around PPM losing change information
Date: Fri,  9 Oct 2020 16:40:47 +0200
Message-ID: <20201009144047.505957-3-benjamin@sipsolutions.net> (raw)
In-Reply-To: <20201009144047.505957-1-benjamin@sipsolutions.net>

From: Benjamin Berg <bberg@redhat.com>

Some/many PPMs are simply clearing the change bitfield when a
notification on a port is acknowledge. Unfortunately, doing so means
that any changes between the GET_CONNECTOR_STATUS and ACK_CC_CI commands
is simply lost.

Work around this by re-fetching the connector status afterwards. We can
then infer any changes that we see have happened but that may not be
respresented in the change bitfield.

We end up with the following actions:
 1. UCSI_GET_CONNECTOR_STATUS, store result, update unprocessed_changes
 2. UCSI_GET_CAM_SUPPORTED, discard result
 3. ACK connector change
 4. UCSI_GET_CONNECTOR_STATUS, store result
 5. Infere lost changes by comparing UCSI_GET_CONNECTOR_STATUS results
 6. If PPM reported a new change, then restart in order to ACK
 7. Process everything as usual.

The worker is also changed to re-schedule itself if a new change
notification happened while it was running.

Doing this fixes quite commonly occurring issues where e.g. the UCSI
power supply would remain online even thought the ThunderBolt cable was
unplugged.

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Benjamin Berg <bberg@redhat.com>
---
 drivers/usb/typec/ucsi/ucsi.c | 125 ++++++++++++++++++++++++++++------
 drivers/usb/typec/ucsi/ucsi.h |   2 +
 2 files changed, 107 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index 758b988ac518..fad8680be7ab 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -53,7 +53,7 @@ static int ucsi_acknowledge_connector_change(struct ucsi *ucsi)
 	ctrl = UCSI_ACK_CC_CI;
 	ctrl |= UCSI_ACK_CONNECTOR_CHANGE;
 
-	return ucsi->ops->async_write(ucsi, UCSI_CONTROL, &ctrl, sizeof(ctrl));
+	return ucsi->ops->sync_write(ucsi, UCSI_CONTROL, &ctrl, sizeof(ctrl));
 }
 
 static int ucsi_exec_command(struct ucsi *ucsi, u64 command);
@@ -625,21 +625,113 @@ static void ucsi_handle_connector_change(struct work_struct *work)
 	struct ucsi_connector *con = container_of(work, struct ucsi_connector,
 						  work);
 	struct ucsi *ucsi = con->ucsi;
+	struct ucsi_connector_status pre_ack_status;
+	struct ucsi_connector_status post_ack_status;
 	enum typec_role role;
+	u16 inferred_changes;
+	u16 changed_flags;
 	u64 command;
 	int ret;
 
 	mutex_lock(&con->lock);
 
+	/*
+	 * Some/many PPMs have an issue where all fields in the change bitfield
+	 * are cleared when an ACK is send. This will causes any change
+	 * between GET_CONNECTOR_STATUS and ACK to be lost.
+	 *
+	 * We work around this by re-fetching the connector status afterwards.
+	 * We then infer any changes that we see have happened but that may not
+	 * be represented in the change bitfield.
+	 *
+	 * Also, even though we don't need to know the currently supported alt
+	 * modes, we run the GET_CAM_SUPPORTED command to ensure the PPM does
+	 * not get stuck in case it assumes we do.
+	 * Always do this, rather than relying on UCSI_CONSTAT_CAM_CHANGE to be
+	 * set in the change bitfield.
+	 *
+	 * We end up with the following actions:
+	 *  1. UCSI_GET_CONNECTOR_STATUS, store result, update unprocessed_changes
+	 *  2. UCSI_GET_CAM_SUPPORTED, discard result
+	 *  3. ACK connector change
+	 *  4. UCSI_GET_CONNECTOR_STATUS, store result
+	 *  5. Infere lost changes by comparing UCSI_GET_CONNECTOR_STATUS results
+	 *  6. If PPM reported a new change, then restart in order to ACK
+	 *  7. Process everything as usual.
+	 *
+	 * We may end up seeing a change twice, but we can only miss extremely
+	 * short transitional changes.
+	 */
+
+	/* 1. First UCSI_GET_CONNECTOR_STATUS */
+	command = UCSI_GET_CONNECTOR_STATUS | UCSI_CONNECTOR_NUMBER(con->num);
+	ret = ucsi_send_command(ucsi, command, &pre_ack_status,
+				sizeof(pre_ack_status));
+	if (ret < 0) {
+		dev_err(ucsi->dev, "%s: GET_CONNECTOR_STATUS failed (%d)\n",
+			__func__, ret);
+		goto out_unlock;
+	}
+	con->unprocessed_changes |= pre_ack_status.change;
+
+	/* 2. Run UCSI_GET_CAM_SUPPORTED and discard the result. */
+	command = UCSI_GET_CAM_SUPPORTED;
+	command |= UCSI_CONNECTOR_NUMBER(con->num);
+	ucsi_send_command(con->ucsi, command, NULL, 0);
+
+	/* 3. ACK connector change */
+	clear_bit(EVENT_PENDING, &ucsi->flags);
+	ret = ucsi_acknowledge_connector_change(ucsi);
+	if (ret) {
+		dev_err(ucsi->dev, "%s: ACK failed (%d)", __func__, ret);
+		goto out_unlock;
+	}
+
+	/* 4. Second UCSI_GET_CONNECTOR_STATUS */
 	command = UCSI_GET_CONNECTOR_STATUS | UCSI_CONNECTOR_NUMBER(con->num);
-	ret = ucsi_send_command(ucsi, command, &con->status,
-				sizeof(con->status));
+	ret = ucsi_send_command(ucsi, command, &post_ack_status,
+				sizeof(post_ack_status));
 	if (ret < 0) {
 		dev_err(ucsi->dev, "%s: GET_CONNECTOR_STATUS failed (%d)\n",
 			__func__, ret);
 		goto out_unlock;
 	}
 
+	/* 5. Inferre any missing changes */
+	changed_flags = pre_ack_status.flags ^ post_ack_status.flags;
+	inferred_changes = 0;
+	if (UCSI_CONSTAT_PWR_OPMODE(changed_flags) != 0)
+		inferred_changes |= UCSI_CONSTAT_POWER_OPMODE_CHANGE;
+
+	if (changed_flags & UCSI_CONSTAT_CONNECTED)
+		inferred_changes |= UCSI_CONSTAT_CONNECT_CHANGE;
+
+	if (changed_flags & UCSI_CONSTAT_PWR_DIR)
+		inferred_changes |= UCSI_CONSTAT_POWER_DIR_CHANGE;
+
+	if (UCSI_CONSTAT_PARTNER_FLAGS(changed_flags) != 0)
+		inferred_changes |= UCSI_CONSTAT_PARTNER_CHANGE;
+
+	if (UCSI_CONSTAT_PARTNER_TYPE(changed_flags) != 0)
+		inferred_changes |= UCSI_CONSTAT_PARTNER_CHANGE;
+
+	/* Mask out anything that was correctly notified in the later call. */
+	inferred_changes &= ~post_ack_status.change;
+	if (inferred_changes)
+		dev_dbg(ucsi->dev, "%s: Inferred changes that would have been lost: 0x%04x\n",
+			__func__, inferred_changes);
+
+	con->unprocessed_changes |= inferred_changes;
+
+	/* 6. If PPM reported a new change, then restart in order to ACK */
+	if (post_ack_status.change)
+		goto out_unlock;
+
+	/* 7. Continue as if nothing happened */
+	con->status = post_ack_status;
+	con->status.change = con->unprocessed_changes;
+	con->unprocessed_changes = 0;
+
 	role = !!(con->status.flags & UCSI_CONSTAT_PWR_DIR);
 
 	if (con->status.change & UCSI_CONSTAT_POWER_OPMODE_CHANGE ||
@@ -676,28 +768,19 @@ static void ucsi_handle_connector_change(struct work_struct *work)
 			ucsi_unregister_partner(con);
 	}
 
-	if (con->status.change & UCSI_CONSTAT_CAM_CHANGE) {
-		/*
-		 * We don't need to know the currently supported alt modes here.
-		 * Running GET_CAM_SUPPORTED command just to make sure the PPM
-		 * does not get stuck in case it assumes we do so.
-		 */
-		command = UCSI_GET_CAM_SUPPORTED;
-		command |= UCSI_CONNECTOR_NUMBER(con->num);
-		ucsi_send_command(con->ucsi, command, NULL, 0);
-	}
-
 	if (con->status.change & UCSI_CONSTAT_PARTNER_CHANGE)
 		ucsi_partner_change(con);
 
-	ret = ucsi_acknowledge_connector_change(ucsi);
-	if (ret)
-		dev_err(ucsi->dev, "%s: ACK failed (%d)", __func__, ret);
-
 	trace_ucsi_connector_change(con->num, &con->status);
 
 out_unlock:
-	clear_bit(EVENT_PENDING, &ucsi->flags);
+	if (test_and_clear_bit(EVENT_PENDING, &ucsi->flags)) {
+		schedule_work(&con->work);
+		mutex_unlock(&con->lock);
+		return;
+	}
+
+	clear_bit(EVENT_PROCESSING, &ucsi->flags);
 	mutex_unlock(&con->lock);
 }
 
@@ -715,7 +798,9 @@ void ucsi_connector_change(struct ucsi *ucsi, u8 num)
 		return;
 	}
 
-	if (!test_and_set_bit(EVENT_PENDING, &ucsi->flags))
+	set_bit(EVENT_PENDING, &ucsi->flags);
+
+	if (!test_and_set_bit(EVENT_PROCESSING, &ucsi->flags))
 		schedule_work(&con->work);
 }
 EXPORT_SYMBOL_GPL(ucsi_connector_change);
diff --git a/drivers/usb/typec/ucsi/ucsi.h b/drivers/usb/typec/ucsi/ucsi.h
index cba6f77bea61..543d54a33cb9 100644
--- a/drivers/usb/typec/ucsi/ucsi.h
+++ b/drivers/usb/typec/ucsi/ucsi.h
@@ -296,6 +296,7 @@ struct ucsi {
 #define EVENT_PENDING	0
 #define COMMAND_PENDING	1
 #define ACK_PENDING	2
+#define EVENT_PROCESSING	3
 };
 
 #define UCSI_MAX_SVID		5
@@ -322,6 +323,7 @@ struct ucsi_connector {
 
 	struct typec_capability typec_cap;
 
+	u16 unprocessed_changes;
 	struct ucsi_connector_status status;
 	struct ucsi_connector_capability cap;
 	struct power_supply *psy;
-- 
2.26.2
  1. Edit PKGBUILD adding the these patches filenames right below the section # ARCH Patches:
...
# ARCH Patches
'0001.patch'
'0002.patch'
...
  1. Save PKGBUILD as PKGBUILD_Ben
  2. Run updpkgsums PKGBUILD_Ben
  3. Run makepkg -i -p PKGBUILD_Ben, this will build and install both kernel and kernel headers.
  4. Reboot to check if it helped.

The same could be done with with 5.9 kernel, I suppose.

1 Like

Building it myself AND updating the bios (they sneaked a 1.70 version in without me noticing) fixed it. Now the system (finally) responds as expected.

Thank you very much!

1 Like

Yeah, good news finally!
Are you sure that only a combination of two actions worked for you? I mean, maybe it could be enough just to update the firmware. Try booting with unpatched 5.9 to make sure. If it was fixed because of the patches, then contact Benjamin and Heikki Krogerus via mail and tell them that it worked for you, because for now it seems those patches are not queued for mainline Linux tree, and you probably will have to build kernel(s) forever :wink:

Sorry typing on the go, the text is full of errors.

PS: the first link I posted in this thread, it is a mailing list. This is how you can contact them both.

Or we can ask @nightmare-2021 to add those patches to Manjaro’s 5.9 and 5.10, if possible.