On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
> 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.
>
Just to confirm that I've tested a trial BIOS from the FW team and it fixes the issue (shows up under /sys/class/typec
If there's anything in particular you'd like me to confirm let me know.
I've asked the FW team for confirmation when the fix will be released. Expect it to take a while as the test/release process can take some time
Mark
