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

[Douglas Gilbert <dgilbert@interlog.com>]

On 12/17/23 16:25, Yaroslav Isakov wrote:
> вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
>>
>> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
>>>
>>> On 12/17/23 12:24, Yaroslav Isakov wrote:
>>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
>>>>>
>>>>> 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