Hello, Mark!
пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@xxxxxxxxx>:
>
> 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
Great to hear, thank you!
> If there's anything in particular you'd like me to confirm let me know.
If /sys/class/typec is populated, I think it should be enough... Just
to double check, is /sys/class/usb_power_delivery populated, too, now?
I also did not manage to see anything in /sys/class/usb_role or
/sys/class/typec_mux, even with my hack - is it expected on AMD,
because of lack of appropriate mux/role switch drivers?
>
> 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
