Hi,
On Tue, Dec 19, 2023, at 5:02 AM, Heikki Krogerus wrote:
> On Mon, Dec 18, 2023 at 06:45:05PM +0100, Yaroslav Isakov wrote:
>> пн, 18 дек. 2023 г. в 04:46, Douglas Gilbert <dgilbert@xxxxxxxxxxxx>:
>> >
>> > 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.
>> It returns -ENODEV, which, I guess, is a signal for code, which
>> detects devices, that this module doesn't support this device.
>>
>> P.S. Looks like power_delivery code works properly, even with
>> version==0 - lsucpd shows proper directions, even with my Pixel 7,
>> which can charge laptop. Also it shows correct data for
>> voltage/current, for "partner" device. It also shows proper data in
>> power_supply subsystem. The only thing which is not working,
>> currently, is displayport altmode not showing, for dockstation I
>> have... But this might be missing module, or something else... I'll
>> try this on Intel laptop, and will debug it further.
>>
>> >
>> > My guess is that Lenovo/AMD have a configuration or timing issue.
>>
>> I tried to add loop, re-reading version in case if it's zero, but,
>> even after 10 tries, it's returning zero, so, it's some weird behavior
>> of UCSI on this AMD laptop. I wonder, what should be the proper fix,
>> then.
>
> You need to report this to Lenovo. This is an issue in their firmware.
>
> We can work around this by adding DMI quirk where we hardcode the UCSI
> version for your system, but before we do that, you should try to get
> Lenovo to fix their firmware.
>
I got forwarded this report from the support team. Was able to reproduce this on my system.
I have internal ticket LO-2879 open and we'll look into it.
Mark
