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
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]
