вс, 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.
>
>
