type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

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?

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Douglas Gilbert]

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]  <

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

$ ls /sys/bus/acpi/devices/USBC000:00
device:ac  device:ad  hid  modalias  path  physical_node  power  status 
subsystem  uevent  uid  wakeup

Strange that the Thunderbolt module is loaded since I thought only the Intel
variants supported Thunderbolt.

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.]

Doug Gilbert

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
>
> 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.

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

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

>
> Doug Gilbert

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Douglas Gilbert]

On 12/17/23 12:24, Yaroslav Isakov wrote:
> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
>>
>> 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

> 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]

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
>
> On 12/17/23 12:24, Yaroslav Isakov wrote:
> > вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
> >>
> >> 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.
>
>

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
>
> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
> >
> > On 12/17/23 12:24, Yaroslav Isakov wrote:
> > > вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
> > >>
> > >> 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.

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Douglas Gilbert]

On 12/17/23 16:25, Yaroslav Isakov wrote:
> вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
>>
>> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
>>>
>>> On 12/17/23 12:24, Yaroslav Isakov wrote:
>>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
>>>>>
>>>>> 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.

My guess is that Lenovo/AMD have a configuration or timing issue.

Doug Gilbert

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

пн, 18 дек. 2023 г. в 04:46, Douglas Gilbert <dgilbert@interlog.com>:
>
> On 12/17/23 16:25, Yaroslav Isakov wrote:
> > вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
> >>
> >> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
> >>>
> >>> On 12/17/23 12:24, Yaroslav Isakov wrote:
> >>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
> >>>>>
> >>>>> 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
>
>

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Heikki Krogerus]

On Mon, Dec 18, 2023 at 06:45:05PM +0100, Yaroslav Isakov wrote:
> пн, 18 дек. 2023 г. в 04:46, Douglas Gilbert <dgilbert@interlog.com>:
> >
> > On 12/17/23 16:25, Yaroslav Isakov wrote:
> > > вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
> > >>
> > >> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
> > >>>
> > >>> On 12/17/23 12:24, Yaroslav Isakov wrote:
> > >>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
> > >>>>>
> > >>>>> 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.

thanks,

-- 
heikki

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Mark Pearson]

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@interlog.com>:
>> >
>> > On 12/17/23 16:25, Yaroslav Isakov wrote:
>> > > вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
>> > >>
>> > >> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
>> > >>>
>> > >>> On 12/17/23 12:24, Yaroslav Isakov wrote:
>> > >>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
>> > >>>>>
>> > >>>>> 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.

Mark

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Roland Ruckerbauer]

I think I am running into exactly the same issue on my T15 Gen2 AMD
Not surprising since the models are almost identical.


On 17.12.23 17:21, Yaroslav Isakov wrote:
> 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.
>
> thanks,
>

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Mark Pearson]

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@interlog.com>:
>>> >
>>> > On 12/17/23 16:25, Yaroslav Isakov wrote:
>>> > > вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
>>> > >>
>>> > >> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
>>> > >>>
>>> > >>> On 12/17/23 12:24, Yaroslav Isakov wrote:
>>> > >>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
>>> > >>>>>
>>> > >>>>> 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

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

Hello, Mark!

пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>:
>
> 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@interlog.com>:
> >>> >
> >>> > On 12/17/23 16:25, Yaroslav Isakov wrote:
> >>> > > вс, 17 дек. 2023 г. в 21:48, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
> >>> > >>
> >>> > >> вс, 17 дек. 2023 г. в 20:15, Douglas Gilbert <dgilbert@interlog.com>:
> >>> > >>>
> >>> > >>> On 12/17/23 12:24, Yaroslav Isakov wrote:
> >>> > >>>> вс, 17 дек. 2023 г. в 18:08, Douglas Gilbert <dgilbert@interlog.com>:
> >>> > >>>>>
> >>> > >>>>> 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

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Mark Pearson]

On Mon, Mar 18, 2024, at 3:22 PM, Yaroslav Isakov wrote:
> Hello, Mark!
>
> пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>:
>>
>> On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
>> > Hi,
>> >
>> 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?

Yes. From my system:

# ls /sys/class/typec
port0  port0-partner  port1
# ls /sys/class/usb_power_delivery
pd0  pd1  pd2

>
> 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'm not seeing anything under those with this BIOS either

I checked on an Intel platform on my desk (P14s G3) and those aren't populated there either...so not sure this is AMD specific.
I'm being lazy and not looking at the kernel code - what would we expect to see in those entries?

Mark

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

Hello, Mark!

пн, 18 мар. 2024 г. в 20:42, Mark Pearson <mpearson@squebb.ca>:
>
>
>
> On Mon, Mar 18, 2024, at 3:22 PM, Yaroslav Isakov wrote:
> > Hello, Mark!
> >
> > пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>:
> >>
> >> On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
> >> > Hi,
> >> >
> >> 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?
>
> Yes. From my system:
>
> # ls /sys/class/typec
> port0  port0-partner  port1
> # ls /sys/class/usb_power_delivery
> pd0  pd1  pd2
>

Great! These are the ones I saw with my workaround, too.
> >
> > 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'm not seeing anything under those with this BIOS either
>
> I checked on an Intel platform on my desk (P14s G3) and those aren't populated there either...so not sure this is AMD specific.
> I'm being lazy and not looking at the kernel code - what would we expect to see in those entries?

According to https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-usb_role,
with /sys/class/usb_role, we can switch between host and device modes.
My main interest there is typec_displayport driver - to be able to see
altmode info (not sure, though, in which /sys directory). With my
workaround, I failed to see this driver detecting my dock, so, I was
wondering, if it's caused by wrong UCSI version reported, or some
other driver missing (DP altmode is working with the doc, just no info
from typec_displayport driver)

BTW, what is the version of ucsi reported from firmware? I wonder, if
it will work with this change
https://lore.kernel.org/linux-usb/20240209223824.622869-1-abhishekpandit@chromium.org/

>
> Mark

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Mark Pearson]

Hi

On Wed, Mar 20, 2024, at 2:38 PM, Yaroslav Isakov wrote:
> Hello, Mark!
>
> пн, 18 мар. 2024 г. в 20:42, Mark Pearson <mpearson@squebb.ca>:
>>
>>
>>
>> On Mon, Mar 18, 2024, at 3:22 PM, Yaroslav Isakov wrote:
>> > Hello, Mark!
>> >
>> > пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>:
>> >>
>> >> On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
>> >> > Hi,
>> >> >
>> >> 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?
>>
>> Yes. From my system:
>>
>> # ls /sys/class/typec
>> port0  port0-partner  port1
>> # ls /sys/class/usb_power_delivery
>> pd0  pd1  pd2
>>
>
> Great! These are the ones I saw with my workaround, too.
>> >
>> > 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'm not seeing anything under those with this BIOS either
>>
>> I checked on an Intel platform on my desk (P14s G3) and those aren't populated there either...so not sure this is AMD specific.
>> I'm being lazy and not looking at the kernel code - what would we expect to see in those entries?
>
> According to 
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-usb_role,
> with /sys/class/usb_role, we can switch between host and device modes.
> My main interest there is typec_displayport driver - to be able to see
> altmode info (not sure, though, in which /sys directory). With my
> workaround, I failed to see this driver detecting my dock, so, I was
> wondering, if it's caused by wrong UCSI version reported, or some
> other driver missing (DP altmode is working with the doc, just no info
> from typec_displayport driver)
>
> BTW, what is the version of ucsi reported from firmware? I wonder, if
> it will work with this change
> https://lore.kernel.org/linux-usb/20240209223824.622869-1-abhishekpandit@chromium.org/
>
Just as a note - BIOS 1.36 was released with the fix. Available on LVFS.

Mark

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

Hello, Mark!
вт, 11 июн. 2024 г. в 14:39, Mark Pearson <mpearson@squebb.ca>:
>
> Hi
>
> On Wed, Mar 20, 2024, at 2:38 PM, Yaroslav Isakov wrote:
> > Hello, Mark!
> >
> > пн, 18 мар. 2024 г. в 20:42, Mark Pearson <mpearson@squebb.ca>:
> >>
> >>
> >>
> >> On Mon, Mar 18, 2024, at 3:22 PM, Yaroslav Isakov wrote:
> >> > Hello, Mark!
> >> >
> >> > пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>:
> >> >>
> >> >> On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
> >> >> > Hi,
> >> >> >
> >> >> 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?
> >>
> >> Yes. From my system:
> >>
> >> # ls /sys/class/typec
> >> port0  port0-partner  port1
> >> # ls /sys/class/usb_power_delivery
> >> pd0  pd1  pd2
> >>
> >
> > Great! These are the ones I saw with my workaround, too.
> >> >
> >> > 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'm not seeing anything under those with this BIOS either
> >>
> >> I checked on an Intel platform on my desk (P14s G3) and those aren't populated there either...so not sure this is AMD specific.
> >> I'm being lazy and not looking at the kernel code - what would we expect to see in those entries?
> >
> > According to
> > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-usb_role,
> > with /sys/class/usb_role, we can switch between host and device modes.
> > My main interest there is typec_displayport driver - to be able to see
> > altmode info (not sure, though, in which /sys directory). With my
> > workaround, I failed to see this driver detecting my dock, so, I was
> > wondering, if it's caused by wrong UCSI version reported, or some
> > other driver missing (DP altmode is working with the doc, just no info
> > from typec_displayport driver)
> >
> > BTW, what is the version of ucsi reported from firmware? I wonder, if
> > it will work with this change
> > https://lore.kernel.org/linux-usb/20240209223824.622869-1-abhishekpandit@chromium.org/
> >
> Just as a note - BIOS 1.36 was released with the fix. Available on LVFS.
I tried 1.36 (R2FET56W) when it was released, but it did not fix my
issue. I have it installed, for sure:
sudo dmidecode | grep 1.36
    Version: R2FET56W (1.36 )
but kernel still sees result of ret = ucsi->ops->read(ucsi,
UCSI_VERSION, &ucsi->version, sizeof(ucsi->version)); as 0

I also have latest EC firmware, too (corresponding to BIOS version)
I'll try to reset BIOS to default setting, to check if it will help.
>
> Mark

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Mark Pearson]

On Tue, Jun 11, 2024, at 8:45 AM, Yaroslav Isakov wrote:
> Hello, Mark!
> вт, 11 июн. 2024 г. в 14:39, Mark Pearson <mpearson@squebb.ca>:
>>
>> Hi
>>
>> On Wed, Mar 20, 2024, at 2:38 PM, Yaroslav Isakov wrote:
>> > Hello, Mark!
>> >
>> > пн, 18 мар. 2024 г. в 20:42, Mark Pearson <mpearson@squebb.ca>:
>> >>
>> >>
>> >>
>> >> On Mon, Mar 18, 2024, at 3:22 PM, Yaroslav Isakov wrote:
>> >> > Hello, Mark!
>> >> >
>> >> > пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>:
>> >> >>
>> >> >> On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> 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?
>> >>
>> >> Yes. From my system:
>> >>
>> >> # ls /sys/class/typec
>> >> port0  port0-partner  port1
>> >> # ls /sys/class/usb_power_delivery
>> >> pd0  pd1  pd2
>> >>
>> >
>> > Great! These are the ones I saw with my workaround, too.
>> >> >
>> >> > 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'm not seeing anything under those with this BIOS either
>> >>
>> >> I checked on an Intel platform on my desk (P14s G3) and those aren't populated there either...so not sure this is AMD specific.
>> >> I'm being lazy and not looking at the kernel code - what would we expect to see in those entries?
>> >
>> > According to
>> > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-usb_role,
>> > with /sys/class/usb_role, we can switch between host and device modes.
>> > My main interest there is typec_displayport driver - to be able to see
>> > altmode info (not sure, though, in which /sys directory). With my
>> > workaround, I failed to see this driver detecting my dock, so, I was
>> > wondering, if it's caused by wrong UCSI version reported, or some
>> > other driver missing (DP altmode is working with the doc, just no info
>> > from typec_displayport driver)
>> >
>> > BTW, what is the version of ucsi reported from firmware? I wonder, if
>> > it will work with this change
>> > https://lore.kernel.org/linux-usb/20240209223824.622869-1-abhishekpandit@chromium.org/
>> >
>> Just as a note - BIOS 1.36 was released with the fix. Available on LVFS.
> I tried 1.36 (R2FET56W) when it was released, but it did not fix my
> issue. I have it installed, for sure:
> sudo dmidecode | grep 1.36
>     Version: R2FET56W (1.36 )
> but kernel still sees result of ret = ucsi->ops->read(ucsi,
> UCSI_VERSION, &ucsi->version, sizeof(ucsi->version)); as 0
>
> I also have latest EC firmware, too (corresponding to BIOS version)
> I'll try to reset BIOS to default setting, to check if it will help.

Strange - let me check. I did test the trial FW on my system but haven't updated to the release version yet.
Thanks for letting me know

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

On Tue, 11 Jun 2024, 15:46 Mark Pearson, <mpearson@squebb.ca> wrote:
>
>
>
> On Tue, Jun 11, 2024, at 8:45 AM, Yaroslav Isakov wrote:
> > Hello, Mark!
> > вт, 11 июн. 2024 г. в 14:39, Mark Pearson <mpearson@squebb.ca>:
> >>
> >> Hi
> >>
> >> On Wed, Mar 20, 2024, at 2:38 PM, Yaroslav Isakov wrote:
> >> > Hello, Mark!
> >> >
> >> > пн, 18 мар. 2024 г. в 20:42, Mark Pearson <mpearson@squebb.ca>:
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Mar 18, 2024, at 3:22 PM, Yaroslav Isakov wrote:
> >> >> > Hello, Mark!
> >> >> >
> >> >> > пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>:
> >> >> >>
> >> >> >> On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> 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?
> >> >>
> >> >> Yes. From my system:
> >> >>
> >> >> # ls /sys/class/typec
> >> >> port0  port0-partner  port1
> >> >> # ls /sys/class/usb_power_delivery
> >> >> pd0  pd1  pd2
> >> >>
> >> >
> >> > Great! These are the ones I saw with my workaround, too.
> >> >> >
> >> >> > 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'm not seeing anything under those with this BIOS either
> >> >>
> >> >> I checked on an Intel platform on my desk (P14s G3) and those aren't populated there either...so not sure this is AMD specific.
> >> >> I'm being lazy and not looking at the kernel code - what would we expect to see in those entries?
> >> >
> >> > According to
> >> > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-usb_role,
> >> > with /sys/class/usb_role, we can switch between host and device modes.
> >> > My main interest there is typec_displayport driver - to be able to see
> >> > altmode info (not sure, though, in which /sys directory). With my
> >> > workaround, I failed to see this driver detecting my dock, so, I was
> >> > wondering, if it's caused by wrong UCSI version reported, or some
> >> > other driver missing (DP altmode is working with the doc, just no info
> >> > from typec_displayport driver)
> >> >
> >> > BTW, what is the version of ucsi reported from firmware? I wonder, if
> >> > it will work with this change
> >> > https://lore.kernel.org/linux-usb/20240209223824.622869-1-abhishekpandit@chromium.org/
> >> >
> >> Just as a note - BIOS 1.36 was released with the fix. Available on LVFS.

BTW, I cannot see it in fwupdmgr, I have only 1.35 there (I had to
update via ISO from pcsupport.lenovo.com):

LC_ALL=en_US.UTF8 fwupdmgr get-releases
WARNING: UEFI ESP partition not detected or configured
See https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found for
more information.
0.    Cancel
1.    83cd12f4f179d6eb6964a74a006840294f7e9c4e (Embedded Controller)
2.    6c946da70cfcaaf4a1d4660f82906333c1c96b8d (System Firmware)
3.    362301da643102b9f38477387e2193e57abaa590 (UEFI dbx)
Choose device [0-3]: 2
LENOVO 21K3003RCK
│
├─ThinkPad T14/P14s Gen 4 and T16/P16s Gen 2 AMD System Update:
│     New version:        0.1.35
│     Remote ID:          lvfs
│     Release ID:         88330

>
> > I tried 1.36 (R2FET56W) when it was released, but it did not fix my
> > issue. I have it installed, for sure:
> > sudo dmidecode | grep 1.36
> >     Version: R2FET56W (1.36 )
> > but kernel still sees result of ret = ucsi->ops->read(ucsi,
> > UCSI_VERSION, &ucsi->version, sizeof(ucsi->version)); as 0
> >
> > I also have latest EC firmware, too (corresponding to BIOS version)
> > I'll try to reset BIOS to default setting, to check if it will help.
>
> Strange - let me check. I did test the trial FW on my system but haven't updated to the release version yet.
> Thanks for letting me know


BTW,

Re: type-c subsystem is empty on Thinkpad T14 Gen 4 AMD

[Yaroslav Isakov]

Hello!
After updating system firmware to 1.37, /sys/class/typec and
/sys/class/usb_power_delivery are populated. Thank you!

вт, 11 июн. 2024 г. в 16:02, Yaroslav Isakov <yaroslav.isakov@gmail.com>:
>
> On Tue, 11 Jun 2024, 15:46 Mark Pearson, <mpearson@squebb.ca> wrote:
> >
> >
> >
> > On Tue, Jun 11, 2024, at 8:45 AM, Yaroslav Isakov wrote:
> > > Hello, Mark!
> > > вт, 11 июн. 2024 г. в 14:39, Mark Pearson <mpearson@squebb.ca>:
> > >>
> > >> Hi
> > >>
> > >> On Wed, Mar 20, 2024, at 2:38 PM, Yaroslav Isakov wrote:
> > >> > Hello, Mark!
> > >> >
> > >> > пн, 18 мар. 2024 г. в 20:42, Mark Pearson <mpearson@squebb.ca>:
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Mon, Mar 18, 2024, at 3:22 PM, Yaroslav Isakov wrote:
> > >> >> > Hello, Mark!
> > >> >> >
> > >> >> > пн, 18 мар. 2024 г. в 19:48, Mark Pearson <mpearson@squebb.ca>:
> > >> >> >>
> > >> >> >> On Thu, Feb 22, 2024, at 9:30 AM, Mark Pearson wrote:
> > >> >> >> > Hi,
> > >> >> >> >
> > >> >> >> 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?
> > >> >>
> > >> >> Yes. From my system:
> > >> >>
> > >> >> # ls /sys/class/typec
> > >> >> port0  port0-partner  port1
> > >> >> # ls /sys/class/usb_power_delivery
> > >> >> pd0  pd1  pd2
> > >> >>
> > >> >
> > >> > Great! These are the ones I saw with my workaround, too.
> > >> >> >
> > >> >> > 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'm not seeing anything under those with this BIOS either
> > >> >>
> > >> >> I checked on an Intel platform on my desk (P14s G3) and those aren't populated there either...so not sure this is AMD specific.
> > >> >> I'm being lazy and not looking at the kernel code - what would we expect to see in those entries?
> > >> >
> > >> > According to
> > >> > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-usb_role,
> > >> > with /sys/class/usb_role, we can switch between host and device modes.
> > >> > My main interest there is typec_displayport driver - to be able to see
> > >> > altmode info (not sure, though, in which /sys directory). With my
> > >> > workaround, I failed to see this driver detecting my dock, so, I was
> > >> > wondering, if it's caused by wrong UCSI version reported, or some
> > >> > other driver missing (DP altmode is working with the doc, just no info
> > >> > from typec_displayport driver)
> > >> >
> > >> > BTW, what is the version of ucsi reported from firmware? I wonder, if
> > >> > it will work with this change
> > >> > https://lore.kernel.org/linux-usb/20240209223824.622869-1-abhishekpandit@chromium.org/
> > >> >
> > >> Just as a note - BIOS 1.36 was released with the fix. Available on LVFS.
>
> BTW, I cannot see it in fwupdmgr, I have only 1.35 there (I had to
> update via ISO from pcsupport.lenovo.com):
>
> LC_ALL=en_US.UTF8 fwupdmgr get-releases
> WARNING: UEFI ESP partition not detected or configured
> See https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-found for
> more information.
> 0.    Cancel
> 1.    83cd12f4f179d6eb6964a74a006840294f7e9c4e (Embedded Controller)
> 2.    6c946da70cfcaaf4a1d4660f82906333c1c96b8d (System Firmware)
> 3.    362301da643102b9f38477387e2193e57abaa590 (UEFI dbx)
> Choose device [0-3]: 2
> LENOVO 21K3003RCK
> │
> ├─ThinkPad T14/P14s Gen 4 and T16/P16s Gen 2 AMD System Update:
> │     New version:        0.1.35
> │     Remote ID:          lvfs
> │     Release ID:         88330
>
> >
> > > I tried 1.36 (R2FET56W) when it was released, but it did not fix my
> > > issue. I have it installed, for sure:
> > > sudo dmidecode | grep 1.36
> > >     Version: R2FET56W (1.36 )
> > > but kernel still sees result of ret = ucsi->ops->read(ucsi,
> > > UCSI_VERSION, &ucsi->version, sizeof(ucsi->version)); as 0
> > >
> > > I also have latest EC firmware, too (corresponding to BIOS version)
> > > I'll try to reset BIOS to default setting, to check if it will help.
> >
> > Strange - let me check. I did test the trial FW on my system but haven't updated to the release version yet.
> > Thanks for letting me know
>
>
> BTW,