Bug 210425

Why is it a regression? Has this functionality ever worked on this hardware? I'm guessing it hasn't ever worked, but if it did, the last kernel version where it worked would be useful.

Yes it has worked in the past. I *think* it broke with 5.8.something. Or at least that's when I started noticing https://gitlab.freedesktop.org/upower/upower/-/issues/126, which turned out to be a kernel regression.

Still exists in 5.10.12

I have the issue on a Panasonic CF-MX4.Running XFCE on Debian. When unplugging, no prooblem. When plugging back the power cord, keyboard in not more responsive, nor the mouse. The only possiblr action is to try switching off. Then I have the shutdown pop-up, where I am allowed to click confirmation for shutdown or reboot. That is a serious issue. 

Release        = Debian GNU/Linux 10 (buster)
Kernel         = 4.19.0-17-amd64 #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64

It seems to me `ucsi_resume()` should take into account that connectors can be plugged-in/out while the system is suspended.

Upon wake-up it should someway scan its connectors and notify userspace then.

Instead resume only hook the notification after the fact and does not check current state. 

> int ucsi_resume(struct ucsi *ucsi)
> {
>       u64 command;
>
>       /* Restore UCSI notification enable mask after system resume */
>       command = UCSI_SET_NOTIFICATION_ENABLE | ucsi->ntfy;
>
>       return ucsi_send_command(ucsi, command, NULL, 0);
> }

Consequently after suspending, unplugging AC and resuming

> cat /sys/class/power_supply/ucsi-source-psy-USBC000\:001/online
> 1
Regardless of the connector state (re-plugging is not signaled either).
We don't get any `udevadm monitor` notification from the usci subsystem.

AFAICT We should have a call to "power_supply_changed(usci->connector[i]->psy);" somewhere for the usci connector concerned resulting from `ucsi_resume` after the connector state has been updated with `ucsi_handle_connector_change()` for instance. But I don't know about the work_struct API. 
Either this or a bug in `ucsi_handle_connector_change()` not taking into account the unplugged-during-suspend usecase. 

I would welcome any code hint to come up with a proper patch or a patch that I would be happy to test.

My hardware is a DELL XPS 9370.

Also the driver ucsi_acpi_platform_driver does not hook to platform_driver  resume() suspend()

This might be the right place to handle resume/suspend.

Found the usci intel documentation:
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/usb-type-c-ucsi-spec.pdf might be of use.

I have this naive patch that fix the main issue:

diff --git drivers/usb/typec/ucsi/ucsi.c drivers/usb/typec/ucsi/ucsi.c
index d0c63afaf345..a679359c98be 100644
--- drivers/usb/typec/ucsi/ucsi.c
+++ drivers/usb/typec/ucsi/ucsi.c
@@ -187,11 +187,22 @@ EXPORT_SYMBOL_GPL(ucsi_send_command);
 int ucsi_resume(struct ucsi *ucsi)
 {
        u64 command;
+       int ret;
+       int i;
 
        /* Restore UCSI notification enable mask after system resume */
        command = UCSI_SET_NOTIFICATION_ENABLE | ucsi->ntfy;
 
-       return ucsi_send_command(ucsi, command, NULL, 0);
+       ret = ucsi_send_command(ucsi, command, NULL, 0);
+       if (ret)
+               return ret;
+
+       /* update all connectors */
+       for (i = 0; i < ucsi->cap.num_connectors; i++) {
+               ucsi_connector_change(ucsi, i);
+       }
+
+       return ret;
 }
 EXPORT_SYMBOL_GPL(ucsi_resume);
 /* -------------------------------------------------------------------------- */


Will probably post to LKML

Still an issue with 5.15.0. ThinkPad T480s, Debian Sid.

$ uname -a
Linux lines 5.15.0-3-amd64 #1 SMP Debian 5.15.15-1 (2022-01-18) x86_64 GNU/Linux

I have been facing this issue since the last two months or so. This problem is very troubling as the low battery indicators no longer showing up resulting in hard poweroffs and other issues. Could anyone also try to comment on the status of this bug report?

My hardware is Lenovo Ideapad Flex 5 - 14ARE05. For a more detailed description of my kernel and hardware this hardware probe can be helpful: https://linux-hardware.org/?probe=981deab8ee

$ uname -a
Linux archlinux 5.15.19-1-lts #1 SMP Tue, 01 Feb 2022 17:37:22 +0000 x86_64 GNU/Linux

Still happening on 5.17.0 on a Thinkpad X1 Gen 7.

Steps to reproduce:

1. Unplug USB-C charger

2. Correctly detected as unplugged:
   % cat /sys/class/power_supply/ucsi-source-psy-USBC000:002/online
   0

3. plug USB-C charger

4. Correctly detected as plugged:
   % cat /sys/class/power_supply/ucsi-source-psy-USBC000:002/online
   1

5. Close the lid and wait for the laptop to sleep

6. Unplug USB-C charger while the laptop is suspended

7. Wake up the laptop

8. BUG: Still detected as plugged!
   % cat /sys/class/power_supply/ucsi-source-psy-USBC000:002/online
   1


Info:

  % uname -a
  Linux giskard 5.17.0-0.rc3.89.fc36.x86_64 #1 SMP PREEMPT Mon Feb 7 14:58:45 UTC 2022 
x86_64 x86_64 x86_64 GNU/Linux

I have this problem aswell on Thinkpad X1 nano

Linux XXX 5.15.27 #1 SMP PREEMPT Tue Mar 8 18:18:11 CST 2022 x86_64 11th Gen Intel(R) Core(TM) i5-1140G7 @ 1.10GHz GenuineIntel GNU/Linux

I can't find any workaround that work on my system. Is there any command that can be ran to force check if a power supply is present ? For now, I have to reboot the laptop, or plug/unplug the charger once after resuming from sleep.

(In reply to Méven Car from comment #7)
> I have this naive patch that fix the main issue:
> 
> diff --git drivers/usb/typec/ucsi/ucsi.c drivers/usb/typec/ucsi/ucsi.c
> index d0c63afaf345..a679359c98be 100644
> --- drivers/usb/typec/ucsi/ucsi.c
> +++ drivers/usb/typec/ucsi/ucsi.c
> @@ -187,11 +187,22 @@ EXPORT_SYMBOL_GPL(ucsi_send_command);
>  int ucsi_resume(struct ucsi *ucsi)
>  {
>         u64 command;
> +       int ret;
> +       int i;
>  
>         /* Restore UCSI notification enable mask after system resume */
>         command = UCSI_SET_NOTIFICATION_ENABLE | ucsi->ntfy;
>  
> -       return ucsi_send_command(ucsi, command, NULL, 0);
> +       ret = ucsi_send_command(ucsi, command, NULL, 0);
> +       if (ret)
> +               return ret;
> +
> +       /* update all connectors */
> +       for (i = 0; i < ucsi->cap.num_connectors; i++) {
> +               ucsi_connector_change(ucsi, i);
> +       }
> +
> +       return ret;
>  }
>  EXPORT_SYMBOL_GPL(ucsi_resume);
>  /*
> -------------------------------------------------------------------------- */
> 
> 
> Will probably post to LKML

any update about your fix?

same problem on 5.15.38

Does not appear with Arch Linux 5.18.1-arch1-1 any more.

(In reply to Bastian Rieck from comment #14)
> Does not appear with Arch Linux 5.18.1-arch1-1 any more.

Odd, I still experience the bug with Manjaro kernel 5.18.3-1. Plug in the charger, boot, sleep, unplug, wake from sleep, and the system reports it's still plugged in. I'm sticking with the 5.4 kernel series on my laptop until this gets fixed.

Are there any other Arch users out there (or users of other distributions) who have the problem solved on the 5.18 kernels?

(In reply to Daniel Morgan from comment #15)
> (In reply to Bastian Rieck from comment #14)
> > Does not appear with Arch Linux 5.18.1-arch1-1 any more.
> 
> Odd, I still experience the bug with Manjaro kernel 5.18.3-1. Plug in the
> charger, boot, sleep, unplug, wake from sleep, and the system reports it's
> still plugged in. I'm sticking with the 5.4 kernel series on my laptop until
> this gets fixed.
> 
> Are there any other Arch users out there (or users of other distributions)
> who have the problem solved on the 5.18 kernels?

I celebrated too early---the problem just re-appeared; I am now wondering whether this might be indicative of a timing issue, because I could change power status ~1–2 times after waking up.

Can confirm it happens using Feren OS and kernel 5.13.0-51-generic

Confirming still happens on Fedora 36, 5.18.5-200.fc36.x86_64
ThinkPad T13 Gen 3

(In reply to grzegorz.alibozek from comment #12)
> (In reply to Méven Car from comment #7)
> > I have this naive patch that fix the main issue:
> > 
> > diff --git drivers/usb/typec/ucsi/ucsi.c drivers/usb/typec/ucsi/ucsi.c
> > index d0c63afaf345..a679359c98be 100644
> > --- drivers/usb/typec/ucsi/ucsi.c
> > +++ drivers/usb/typec/ucsi/ucsi.c
> > @@ -187,11 +187,22 @@ EXPORT_SYMBOL_GPL(ucsi_send_command);
> >  int ucsi_resume(struct ucsi *ucsi)
> >  {
> >         u64 command;
> > +       int ret;
> > +       int i;
> >  
> >         /* Restore UCSI notification enable mask after system resume */
> >         command = UCSI_SET_NOTIFICATION_ENABLE | ucsi->ntfy;
> >  
> > -       return ucsi_send_command(ucsi, command, NULL, 0);
> > +       ret = ucsi_send_command(ucsi, command, NULL, 0);
> > +       if (ret)
> > +               return ret;
> > +
> > +       /* update all connectors */
> > +       for (i = 0; i < ucsi->cap.num_connectors; i++) {
> > +               ucsi_connector_change(ucsi, i);
> > +       }
> > +
> > +       return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(ucsi_resume);
> >  /*
> > --------------------------------------------------------------------------
> */
> > 
> > 
> > Will probably post to LKML
> 
> any update about your fix?

I was wrong, I did not test properly, or at least I am unsure.
I am not familiar with the code base and it would take a long to learn about the API to properly find a proper solution. 

I hope a usci maintainer will have a look.

I recently switched to slackware current with kernel 5.18.14 and the problem is still present

I don't know if it's related:

sie 17 18:06:54 kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-110)
sie 17 18:06:54 kernel: ucsi_acpi USBC000:00: PPM init failed (-110)

on 5.19.2-arch1-1

currently the problem occurs even when I plug and unplug the charger on a working laptop.

arch linux, 5.19.5-arch1-1

Created attachment 301729 [details]
UCSI resume

Grzegorz, thanks for letting me know about this issue.

Can someone if this helps?

Happy to check---can I just apply this to a current HEAD checkout of the kernel? (It's been a while since I last compiled my own kernel)

Heikki, it looks like it is solving the problem after waking up,
Thanks :) 

I have one more case:

1. reboot
2. plug in the power adapter
3. plug out the power adapter

 . after going to sleep and waking up, the state is now set correctly

it is possible?

correcting the problem occurs on the dock: Lenovo Thinkpad Ultra Dock 40AJ,
in journalctl i see:
sep 03 08:33:25 kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-110)

but the main problem seems to be resolved

(In reply to Grzegorz Alibożek from comment #26)
> correcting the problem occurs on the dock: Lenovo Thinkpad Ultra Dock 40AJ,
> in journalctl i see:
> sep 03 08:33:25 kernel: ucsi_acpi USBC000:00: ucsi_handle_connector_change:
> GET_CONNECTOR_STATUS failed (-110)
> 
> but the main problem seems to be resolved

Okay. In your case this bug may be just a symptom of that other issue. So my patch may just be a workaround in your case, but how about the others? Does everybody with this issue see that warning when they resume?

There is another report for that issue. I think it's best that we try to solve that first: https://bugzilla.kernel.org/show_bug.cgi?id=216426

for the sake of clarity, I had this warning also before your patch.

Will you post the change request to the Linux kernel?

I'll clean up the patch and send it out tomorrow.

Ok, thanks :)

Quick update. Bastien saw a WARNING that my patch causes. The warning is caused by unbalanced DisplayPort alt mode driver's module reference count. I'm still working on that.

(In reply to Heikki Krogerus from comment #32)
> Quick update. Bastien saw a WARNING that my patch causes.

I don't remember seeing anything, I don't even have the hardware to trigger this.

(In reply to Bastien Nocera from comment #33)
> I don't remember seeing anything, I don't even have the hardware to trigger
> this.

Sorry, Bastian not Bastien:
https://lore.kernel.org/linux-usb/27257661.hdJqBvvX10@nimue/#t

The DisplayPort alt mode is activated (in the code) before the DP alt mode driver is bound to it in that case. I don't know exactly why is that happening - I have a theory, but I can reproduce the problem, so I can't test anything. Bear with me.

Dear Heikki,

Thanks for your great work. I was unable to reproduce the DP bug so far. Will try some more.

Best,
  Bastian

I'm still testing, currently on 5.19.12-arch1 and everything works fine

@Heikki, maybe problem which @Bastian had was caused by:

usb: typec: ucsi: add a common function ucsi_unregister_connectors()

and is now resolved, because this commit was reverted in 5.19.8

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.19.8&id=3d4044c9e6d2e3f11f1f8b5e0ee8647d3eb1afad

Maybe... Okay, I'll resend the fix later this week.
I'll test it one more time first.

@heikki Today i have installed 5.19.17 kernel (btw it appears to be the last 5.19.X kernel) I have saw that you made a fix regarding usci but the issue is still present on my machine. So I don't know if this fix was referring to this specific issue, please let me know :)
thanks

(In reply to Adrien from comment #39)
> @heikki Today i have installed 5.19.17 kernel (btw it appears to be the last
> 5.19.X kernel) I have saw that you made a fix regarding usci but the issue
> is still present on my machine. So I don't know if this fix was referring to
> this specific issue, please let me know :)
> thanks

The fix for this bug is not in v5.19.17. It's not even part of mainline yet.

It's now waiting in Greg's tree (there are actually two patches, but you can just keep an eye on this one):
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linus&id=99f6d43611135bd6f211dec9e88bb41e4167e304

Once it get's applied - presumable withing the next couple of weeks - I'm expecting there to be a bot that reacts by changing the status of this bug. We shall see.

(In reply to Heikki Krogerus from comment #40)
> (In reply to Adrien from comment #39)
> > @heikki Today i have installed 5.19.17 kernel (btw it appears to be the
> last
> > 5.19.X kernel) I have saw that you made a fix regarding usci but the issue
> > is still present on my machine. So I don't know if this fix was referring
> to
> > this specific issue, please let me know :)
> > thanks
> 
> The fix for this bug is not in v5.19.17. It's not even part of mainline yet.
> 
> It's now waiting in Greg's tree (there are actually two patches, but you can
> just keep an eye on this one):
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-
> linus&id=99f6d43611135bd6f211dec9e88bb41e4167e304
> 
> Once it get's applied - presumable withing the next couple of weeks - I'm
> expecting there to be a bot that reacts by changing the status of this bug.
> We shall see.

Thanks a lot for these information. I will keep an eye on status updates.

(In reply to Heikki Krogerus from comment #40)

> Once it get's applied - presumable withing the next couple of weeks - I'm
> expecting there to be a bot that reacts by changing the status of this bug.
> We shall see.

I can confirm it is not in 6.0.2-2 on Manjaro.
Using a Lenovo L15, 1st Gen.

I'm not sure if it's okay to report here, but it seems like changes made here breake resume from suspend on my laptop. 
Archlinux kernel 6.0.6- resumes fine
Archlinux kernel 6.0.7- hangs on resume, laptop appears to stuck, nothing works except GUI displayed but not updated and I get errors saying something like
RIP: 0010:ucsi_resume+0x2a/0x70

Lenovo ThinkBook 13s-IML

If it's inappropriate to report such issue here, could you please guide me how to report, I'm totally new to kernel issue reporting.

Just checked with 6.1.0-rc5-1-mainline package wich is a "patchless" kernel from Archlinux AUR and the problem still occurs.

Submitted a bug https://bugzilla.kernel.org/show_bug.cgi?id=216697

This is working for me as of Kernel 6.0.10-300.fc37.x86_64 (64-bit) on Fedora 37.

Works for me too with kernel 6.1.6 on Slackware (current)

Exact same issue. Not sure how to reproduce it. Just want to add my versions

Operating System: Kubuntu 22.10
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.0-35-generic (64-bit)

Graphics Platform: X11
Processors: 16 × 12th Gen Intel® Core™ i7-1260P
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: LG Electronics
Product Name: 14ZB90Q-G.AAC6U1
System Version: 0.1

Created attachment 303880 [details]
upower result unplugged

Any chance the reason the icon shows plugged in when it's not, is because power supply always show as YES whether plugged in or not.

(In reply to wyattb from comment #49)
> Any chance the reason the icon shows plugged in when it's not, is because
> power supply always show as YES whether plugged in or not.

I'm not sure that problem is related to this one.

I don't think your kernel has the fix for this one. I don't know to which 5.19.x release the fix was included, but it definitely is not available in v5.19.0.