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_ucsiI 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 wakeupUnder /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 ueventIn 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.CR02Mine has the extra physical_node symlinks to typec/port0 and typec/port1Yes, 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 FedoraBelow 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
