пн, 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.
>
> Doug Gilbert
>
>
