Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/17/23 16:25, Yaroslav Isakov wrote:
вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@xxxxxxxxx>:

вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@xxxxxxxxxxxx>:

On 12/17/23 12:24, Yaroslav Isakov wrote:
вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@xxxxxxxxxxxx>:

On 12/17/23 11:21, Yaroslav Isakov wrote:
Hello! I recently bought Thinkpad T14 Gen 4 AMD laptop, and I
installed Gentoo on it, with kernel 6.6.4.

Even though type-c ports seems to be working (I checked usb3 flash
stick, lenovo charger, Jabra headset, Yubikey), I cannot see any
devices in /sys/class/(typec,typec_mux,usb_power_delivery).

There are no messages in dmesg at all, mentioning typec. I can see
that modules typec_ucsi, ucsi_acpi, thunderbolt are loaded. I can see
that device TYPEC000 is present on acpi bus, there are files in
/sys/bus/acpi/devices/USBC000:00, but, there is no driver linked in
it.

I tried to recompile module ucsi_acpi, with adding { "USBC000", 0 }
to ucsi_acpi_match, but it did not change anything (except that in
modinfo of this module, USBC000 is now seen.

I tried to decompile SSDT1 table, which has definition of USBC, but
there is nothing in it, which is supicious.

What else can I check, to understand, why can't I see anything in
typec/PD subsystems?


I have a X13 Gen 3 [i5-1240P] which is about 18 months old. Everything you
mention is present plus the typec ports and the associated pd objects:

$ lsucpd
    port0 [pd0]  <<====  partner [pd2]
    port1 [pd1]  <

I guess, it makes no sense to install lsucpd, if it checks /sys/class/typec etc?


A power adapter is connected to port0. Here are the modules loaded:

$ lsmod | grep typec
typec_ucsi             57344  1 ucsi_acpi
roles                  16384  1 typec_ucsi
typec                 114688  1 typec_ucsi
usb_common             20480  4 xhci_hcd,usbcore,uvcvideo,typec_ucsi
$ lsmod | grep ucsi
ucsi_acpi              12288  0
typec_ucsi             57344  1 ucsi_acpi
roles                  16384  1 typec_ucsi
typec                 114688  1 typec_ucsi
usb_common             20480  4 xhci_hcd,usbcore,uvcvideo,typec_ucsi

I have exact same modules.

$ ls /sys/bus/acpi/devices/USBC000:00
device:ac  device:ad  hid  modalias  path  physical_node  power  status
subsystem  uevent  uid  wakeup
Under /sys/bus/acpi/devices/USBC000:00 I have the similar files:
adr  device:48  device:49  hid  modalias  path  physical_node  power
status  subsystem  uevent  uid
As you don't have driver symlink there, too, then it's a red herring,
that lack of driver file is symptom of this issue.


Strange that the Thunderbolt module is loaded since I thought only the Intel
variants supported Thunderbolt.
thundebolt module is now shared with USB4 subsystem, and T14 started
to have USB4 from Gen 3, for AMD variant.

The only thing that I can think of is some BIOS setting. When I poked around
in the X13 BIOS I don't remember any setting that would cause what you are
seeing.]
I checked BIOS settings, but I cannot find anything related

Could you please show, what drivers are used for device:ac and
device:ad, under /sys/bus/acpi/devices/USBC000:00? It seems that if I
have such entries in my /sys/bus/acpi/devices/USBC000:00, at least
ucsi_acpi works properly.

dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ac$ ls -l
total 0
-r--r--r-- 1 root root 4096 Dec 16 19:11 adr
-r--r--r-- 1 root root 4096 Dec 16 19:11 path
lrwxrwxrwx 1 root root    0 Dec 16 19:11 physical_node ->
../../../../platform/USBC000:00/typec/port0
drwxr-xr-x 2 root root    0 Dec 16 19:11 power
lrwxrwxrwx 1 root root    0 Dec 16 16:45 subsystem -> ../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Dec 16 16:45 uevent

dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ac$ cd ../device\:ad
dougg@treten:/sys/bus/acpi/devices/USBC000:00/device:ad$ ls -l
total 0
-r--r--r-- 1 root root 4096 Dec 16 19:11 adr
-r--r--r-- 1 root root 4096 Dec 16 19:11 path
lrwxrwxrwx 1 root root    0 Dec 16 19:11 physical_node ->
../../../../platform/USBC000:00/typec/port1
drwxr-xr-x 2 root root    0 Dec 16 19:11 power
lrwxrwxrwx 1 root root    0 Dec 16 16:45 subsystem -> ../../../../../bus/acpi
-rw-r--r-- 1 root root 4096 Dec 16 16:45 uevent



In my /sys/bus/acpi/devices/USBC000:00/device:(48,49), there are only
adr, path and uevent files, and power and subsytem folders. Subsystem
links to bus/acpi, and path has \_SB_.UBTC.CR01, \_SB_.UBTC.CR02

Mine has the extra physical_node symlinks to typec/port0 and typec/port1
Yes, I have the same as on T14 Gen 3 (Intel). Looks like they have no
driver symlinks, too, but they're working on Intel.

P.S. I tried latest live Fedora, just to see if I forgot to compile
some drivers for custom-built Gentoo kernel, but same issue on Fedora

Below is a fragment of a post from Heikki Krogerus about turning on ucsi debug:

If you want to see the actual UCSI notification in user space, then
that is not possible, but the driver does produce trace output, and I
would actually like to see what we got there. You need debugfs to be
mounted. Then try the following:

          # Unload all UCSI modules
          modprobe -r ucsi_acpi

          # At this point you should plug-in the problematic device

          # Reload the UCSI core module
          modprobe typec_ucsi

          # Enable UCSI tracing
          echo 1 > /sys/kernel/debug/tracing/events/ucsi/enable

          # Now reload the ACPI glue driver
          modprobe ucsi_acpi

          # Unplug the problematic device so that you see the error

          # Finally dump the trace output
          cat /sys/kernel/debug/tracing/trace

So if that works, please send the trace output to me.
[Heikki]
I tried provided commands, both in Gentoo and Fedora - nothing in
trace at all. I guess, it's because ucsi on AMD can see two devices,
but cannot work with them, for some reason. I also checked same
commands on T14 Gen 3 (Intel), and I can see many ucsi_register_port
and ucsi_register_altmode events.



I think I managed to find the issue - looks like on my laptop,
ucsi_register fails in version check, !ucsi->version returns False.
Commenting out this check populates /sys/class/typec and
/sys/class/usb_power_delivery. I did not check yet, if populated data
is correct, but, it's definite progress.

Well spotted.

That is probably the first UCSI read operation that failed. At the very least
ucsi_register() could send a message to the log that it was exiting rather
than leave users guessing.

My guess is that Lenovo/AMD have a configuration or timing issue.

Doug Gilbert






[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux