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