Re: [RFC PATCH 0/2] usb: Link USB devices with their USB Type-C partner counterparts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023-08-28 05:21, Heikki Krogerus wrote:
On Thu, Aug 24, 2023 at 12:51:04PM -0400, Douglas Gilbert wrote:
On 2023-08-23 04:56, Heikki Krogerus wrote:
Hi Douglas,

On Tue, Aug 22, 2023 at 10:52:12AM -0400, Douglas Gilbert wrote:
On 2023-08-22 09:32, Heikki Krogerus wrote:
On a related matter, I wonder why there aren't symlinks between typec ports
(under /sys/class/typec ) and/or the corresponding pd objects (under
/sys/class/usb_power_delivery ) to the related power_supply objects under
/sys/class/power_supply . For example under the latter directory I see:
      $ ls | more
      AC
      BAT0
      hidpp_battery_1
      ucsi-source-psy-USBC000:001
      ucsi-source-psy-USBC000:002

Those last two power supplies are obviously connected to typec port0 and port1
(but offset by 1). Those power_supply objects hold inaccurate data which I hope
will improve in time. Significantly power_supply objects don't seem to report
the direction of the power. Here is a little utility I have been working on
to report the USB Type-C port/pd disposition on my machine:
      $ lsucpd
      port0 [pd0]  > {5V, 0.9A}
      port1 [pd1]  <<===  partner: [pd8]

My laptop (Thinkpad X13 G3) has two type-C ports and port1 is a sink with a
PD contract. I would like that second line to have 20V, 3.25A appended to it
but there are several issues:
    - no typec or pd symlink to ucsi-source-psy-USBC000:002
    - that power supply_object says it is online (correct) with a voltage_now:
      5000000 uV (incorrect) and current_now: 3000000 uA (incorrect). See below.

    ucsi-source-psy-USBC000:002 $ ls_name_value
      current_max : 3250000
      current_now : 3000000
      online : 1
      scope : Unknown
      type : USB
      uevent : <removed>
      usb_type : C [PD] PD_PPS
      voltage_max : 20000000
      voltage_min : 5000000
      voltage_now : 5000000

I'm glad you brought that up. The major problem with the Type-C power
supplies is that the Type-C connector class does not actually take
care of them. They are all registered by the device drivers, and all
of them seem to expose different kind of information. In your case the
power supplies are registered by the UCSI driver, and the above may
indicate a bug in that driver.

Hi,
Thanks for the background.

My X13 Gen 3 (i5-1240P) uses the typec_ucsi and ucsi_acpi modules. Some time
back in a post you explained how to use debugfs with ucsi. Following that
procedure, just after a 20 Volt PD contract is negotiated on port 0 I see:

     # cat /sys/kernel/debug/tracing/trace
     ....
      kworker/0:1-18718   [000] ..... 137813.407189: ucsi_connector_change:
         port0 status: change=0000, opmode=5, connected=1, sourcing=0,
         partner_flags=1, partner_type=1,
         request_data_obj=1304b12c, BC status=1

That RDO is incorrect, the top nibble (1) is the index of the default Vsafe5v
PDO. The correct PDO index would be 4 in this case. The source is an Apple 140W
USB-C power adapter so I doubt that it is breaking any PD 3.0/3.1 protocol
rules.

The driver reads the RDO from the UCSI interface, so if it's wrong,
there is possibly a problem in the Embedded Controller firmware :-(.

According the a PD analyzer (km002c) only one Request is sent by the sink:
82 10 d6 59 87 43 which it decodes as "Pos: 4 Fixed: 20V, 4.7A" which is
Accepted and 200 ms later a PS RDY is sent by the source and Vbus
transitions from from 5.17 Volts to 20.4 Volts. So I can see no Request for
PDO index 1 being sent.

With acpi_listen the following traffic occurs just after the power adapter
is plugged into port 0:
   battery PNP0C0A:00 00000080 00000001
   battery PNP0C0A:00 00000080 00000001
   ibm/hotkey LEN0268:00 00000080 00006032
   ac_adapter ACPI0003:00 00000080 00000001
   ac_adapter ACPI0003:00 00000080 00000001
   ibm/hotkey LEN0268:00 00000080 00006030
   thermal_zone LNXTHERM:00 00000081 00000000
   ibm/hotkey LEN0268:00 00000080 00006030
   thermal_zone LNXTHERM:00 00000081 00000000

Hope this helps if you find time to look at this.

Thank you. I'll try to reproduce the issue this week, but I don't have
that exact model of Thinkpad available I'm afraid (UCSI tends to
behave a little bit differently on every single platform).

Could it be a CPU generation thing? My CPU is 12th generation (2022) and
there is another report of a Lenovo P15gen2 (11th generation 2021 I assume)
not reporting PDOs at all. I have an older Dell XPS 9380 which has an 8th
generation CPU (3 USB-C port and no Type A ports) that has no UCSI support.
So do PDOs and the active RDO get properly reported on 13th generation
CPUs?

Doug Gilbert



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux