linux-kernel - Re: Unplugging USB-C charger cable causes `ucsi_acpi USBC000:00: ucsi_handle_connector

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZWCdVWRGzh/2RSs3@kuha.fi.intel.com>
Date:   Fri, 24 Nov 2023 14:55:49 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Paul Menzel <pmenzel@...gen.mpg.de>
Cc:     linux-usb@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: Unplugging USB-C charger cable causes `ucsi_acpi USBC000:00:
 ucsi_handle_connector_change: ACK failed (-110)`

Hi,

> > Just list what you have in /sys/class/typec/ before and after plugging
> > a device to the port:
> > 
> >          ls /sys/class/typec/
> 
> Sorry, here you go:
> 
> With charger:
> 
>     $ ls /sys/class/typec/
>     port0  port0-partner
> 
> After unplugging the charger:
> 
>     $ LANG= ls /sys/class/typec/
>     port0

Thanks. The interface does not appear to be completely stuck, which is
what I wanted to check.

> By the way, Linux logs the ucsi_handle_connector_change line around five
> second after unplugging the USB Type-C charger cable.
> 
> Kind regards,
> Paul
> 
> PS: In the logs since October 30th, I see the three distinct lines below:
> 
> 1.  ucsi_acpi USBC000:00: failed to re-enable notifications (-110)
> 2.  ucsi_acpi USBC000:00: GET_CONNECTOR_STATUS failed (-110)
> 3.  ucsi_acpi USBC000:00: ucsi_handle_connector_change: ACK failed (-110)
> 
> Is it documented somewhere what -100 means?

That is the error code, and 110 means Timeout. The driver waits 5s,
which should be more than enough. If the firmware does not respond
within that 5s, it will most likely never respond.

Two of those errors mean that the driver has sent a command to the
firmware but the firmware never completes the command.

The ACK failure means that the driver tries to acknowledge a connector
change event (that you get for example when you plug or unplug the
cable) indicating that the driver has now processed the event, but the
firmware does not react to that acknowledgement like it should.

So the firmware is not behaving correctly in all these cases. I could
try to see if we can workaround those issues, but I would need to be
able reproduce the problems. Unfortunately I do not have XPS 13 9360.

But none of those problems are critical if the interface really
continues to work.

thanks,

-- 
heikki