Skip to content

UCSI: Discover Identity / cable e-marker passthrough, and full v2+ MESSAGE_IN in EC tunnel #78

New issue
New issue
Open
Open
UCSI: Discover Identity / cable e-marker passthrough, and full v2+ MESSAGE_IN in EC tunnel#78

Description

@HuggeK
HuggeK
opened on Feb 23, 2026

Summary
Expose USB-PD partner and cable identity (Discover Identity / cable e-marker) to the OS through UCSI,
and make sure the EC's UCSI tunnel passes full UCSI v2+ responses.

1. Discover Identity / cable e-marker passthrough
Linux shows partner and cable identity in /sys/class/typec/*/identity and portN-cable/ when the
UCSI firmware provides it. On Framework boards this data is missing, and Linux logs
GET_CABLE_PROPERTY failed (-5) on several boards.

UCSI offers two routes:

  • GET_CABLE_PROPERTY: cable speed, current, type, plug, PD revision. Normative for the PD
    controller since UCSI 3.0 (UCSI 3.1, Table 6-90).
  • GET_PD_MESSAGE with Response Message Type = Discover Identity and Recipient = SOP (partner) or
    SOP' (cable e-marker). Effectively optional (bmOptionalFeatures bit 8).

2. Full v2+ MESSAGE_IN in the EC tunnel
The forum thread confirmed the EC tunnels UCSI to the CCG controllers. In
zephyr/program/framework/src/ucsi.c (branch fwk-sakura-20260429) the EC reads the UCSI VERSION
from the CCG and handles <2.0 and ≥2.0 layouts, but for ≥2.0 it copies only 34 bytes of
MESSAGE_IN (message_in_max_length). UCSI 2.0+ allows 256 bytes, so larger responses (e.g.
GET_PD_MESSAGE, EPR GET_PDOS) can be truncated.

Questions

  1. Which UCSI version and bmOptionalFeatures does the CCG firmware report on each board (especially
    Laptop 16 and 13 Pro)? Is GET_PD_MESSAGE supported?
  2. Is GET_CABLE_PROPERTY failing in the CCG firmware or in the EC tunnel?
  3. Would a PR raising the MESSAGE_IN copy to the full v2+ size be accepted and tested against the PD
    firmware?

Data from testers
Read-only script (GET_CAPABILITY / GET_CONNECTOR_CAPABILITY only):
Forum thread for results:
Earlier thread: https://community.frame.work/t/what-pd-controllers-and-can-discover-identity-usb-power-delivery-commands-be-used/79489
New Thread for call of tester of it: https://community.frame.work/t/usb-c-pd-on-linux-via-ucsi-what-does-each-framework-board-support-call-for-testers/86037

Activity

  1. HuggeK
    changed the title [-]Can you pipe through the Discovery Identity from the USB PD chips onto the EC and then away to a kernel driver to get the info to the OS?[/-] [+]UCSI: expose Discover Identity and cable e-marker info (GET_PD_MESSAGE / GET_CABLE_PROPERTY) to the OS[/+] on Nov 9, 2026
  2. HuggeK
    changed the title [-]UCSI: expose Discover Identity and cable e-marker info (GET_PD_MESSAGE / GET_CABLE_PROPERTY) to the OS[/-] [+]UCSI: Discover Identity / cable e-marker passthrough, and full v2+ MESSAGE_IN in EC tunnel[/+] on Nov 9, 2026

  3. HuggeK commented on Nov 9, 2026

    @HuggeK
    HuggeK
    on Nov 9, 2026
    Author

    Updated the title and description with findings from the EC source and the UCSI 3.1 spec.

  4. HuggeK commented on Nov 9, 2026

    @HuggeK
    HuggeK
    on Nov 9, 2026
    Author

    Longer-term idea: an open UCSI PPM in the EC ("Option A")

    For context, how I understand the current stack on CCG boards:

    Linux/Windows (OPM)
     │  UCSI over ACPI (BIOS mailbox, USBC000)
     ▼
EC (NPCX993)  ── tunnels UCSI: copies CONTROL / CCI / MESSAGE_IN/OUT
     │  I2C (CCG UCSI registers), one bus per CCG
     ▼
CCG8 ×2  ── LPM + PPM: runs the PD policy, alt modes, Thunderbolt retimers (I2C), SMLink to the SoC
     │
   USB-C ports

    Option A keeps the CCGs (and Thunderbolt/USB4 handling) exactly as they are, but replaces the
    tunnel with a real UCSI PPM in the EC, talking to the CCGs as LPMs over I2C (UCSI 3.x, chapter 5
    "PPM-LPM Interface Protocol"):

    Linux/Windows (OPM)
     │  UCSI ≥2.0 over ACPI (256-byte mailbox)
     ▼
EC: open UCSI PPM  ── aggregates both CCGs, full-size buffers, quirk handling, platform policy
     │  UCSI commands to each LPM over I2C
     ▼
CCG8 ×2 (LPM)  ── PD negotiation, alt modes, retimers (unchanged)

    What this would enable without new hardware:

    • Full-size UCSI v2+ messages end-to-end (no 34-byte limit), so EPR PDOs and GET_PD_MESSAGE work.
    • Workarounds for PD firmware quirks in open code (e.g. the duplicated/dropped PDOs seen with EPR
      chargers), instead of waiting for PD firmware releases.
    • Open platform policy in the always-on EC: charge-power levels, PPS/AVS choices, weak-charger
      reporting, and power-budget sharing between the two CCGs, exposed to the OS via standard UCSI
      (SET_POWER_LEVEL, SET_PDOS, READ_POWER_LEVEL).
    • The same behaviour on Linux and Windows, since both just talk UCSI.

    Building blocks that already exist:

    • Chrome EC has a UCSI PPM subsystem (zephyr/subsys/ucsi), present in this tree but not enabled on
      the 13 Pro. It would need a driver for the CCG8 as an LPM.
    • The EC already accesses the CCG UCSI registers over I2C (src/ucsi.c), so the transport exists.

    What it would need from each layer:

    • CCG firmware: solid UCSI 3.x LPM behaviour (the normative commands in UCSI 3.1 Table 6-90).
    • EC: the PPM plus a CCG8 LPM driver.
    • UEFI: the UCSI ≥2.0 ACPI mailbox and the _DSM function Windows expects.

    Not asking for this now. I'd mainly like to know whether Framework would be open to it, and whether
    community contributions to the EC side would be welcome.

  5. HuggeK commented on Nov 9, 2026

    @HuggeK
    HuggeK
    on Nov 9, 2026
    Author

    Linux 7.3: new cable-based alt-mode check, and why correct cable identity now matters

    Linux 7.3 adds typec_cable_altmode_unsupported() (Andrei Kuchynski, ChromeOS), used by the
    DisplayPort and Thunderbolt alt-mode drivers. It reads the cable's Discover Identity (SOP') and
    blocks alt modes for passive USB 2.0-only cables and for active cables without the matching
    SOP' alt mode.

    Current impact on Framework boards: likely none. During review it was changed so that a
    missing cable identity gives CABLE_SUPPORT_UNKNOWN and doesn't block the alt mode. Heikki noted
    UCSI GET_CABLE_PROPERTY is optional. Since Framework's PD firmware provides no cable identity
    (GET_PD_MESSAGE not advertised; GET_CABLE_PROPERTY fails with -5 on a 13 AMD 7840U, BIOS 3.20,
    PD 0.0.1C), DP/TBT behaviour shouldn't change.

    But:

    1. Framework users don't get the benefit of the check (e.g. clear reporting when a USB 2.0-only
      cable can't carry DisplayPort).
    2. If cable identity is added later, it must be correct and complete. A truncated or corrupted
      ID header could make Linux wrongly treat a capable cable as USB 2.0-only and refuse DP/TBT.
      That's another reason to fix the empty error-status responses and the 34-byte MESSAGE_IN limit
      in the EC tunnel together with any identity support.

    So supporting GET_PD_MESSAGE (Identity, SOP') or a working GET_CABLE_PROPERTY is no longer just
    "nice to have": the kernel now acts on this data.

  6. HuggeK commented on Nov 9, 2026

    @HuggeK
    HuggeK
    on Nov 9, 2026
    Author

    Follow-up: why this matters beyond Linux tooling, and a suggested order of work

    At LPC 2026, Google's Android USB team presented "Modernizing Android USB: Userspace AOA, Multi-UDC,
    Type-C, and Framework APIs": https://lpc.events/event/20/contributions/2559/

    Key points from the slides:

    • Android 17 adopts the kernel's USB Type-C connector class.
    • Goal: "thin" USB HALs. Move standardised logic into the upstream kernel instead of vendor code.
    • Things they want upstream that vendors currently do in HALs include charger compliance
      detection/reporting      , data-path disable (TCPM / UCSI / EC) and linking connectors to their
      power supply      .
    • Their "USB Advanced Protection Mode" (all USB data off, charging kept) needs one switch that works
      across TCPC+TCPM, EC/UCSI and custom ECs.

    With Android coming to laptops (Googlebook), Linux and Android will increasingly rely on UCSI to get
    this data from PD controllers on laptops. Together with the Linux 7.3 cable alt-mode check (above),
    the kernel side is moving fast. On Framework boards the missing piece is the firmware.

    Suggested order of work

    1. PD controller firmware (prerequisite for every path)
    Ask Infineon for a CCGx firmware update that:

    • fixes the failing GET_CABLE_PROPERTY (-5) and GET_PDOS (-70) responses, and the empty/"undefined"
      GET_ERROR_STATUS replies (seen on a 13 AMD 7840U, BIOS 3.20, PD 0.0.1C);
    • implements UCSI 3.1 properly: the normative LPM commands in Table 6-90 (GET_PDOS with SPR/EPR
      Range, GET_CABLE_PROPERTY, SET_POWER_LEVEL incl. PPS/AVS fields, SET_PDOS, READ_POWER_LEVEL,
      GET_LPM_PPM_INFO, SET_SINK_PATH), plus GET_PD_MESSAGE (Discover Identity SOP/SOP', Source Caps
      Extended).
      Without this, neither of the transport options below can deliver the data.

    2. Transport to the OS: two options

    • (a) ACPI/BIOS UCSI mailbox (Insyde/Compal): update to the UCSI ≥2.0 layout (256-byte
      MESSAGE_IN/OUT, _DSM as Windows requires). Windows needs this path anyway, so it's the
      practical baseline for both OSes.
    • (b) EC as a real UCSI PPM + cros_ec_ucsi: Linux already has an upstream UCSI transport over
      ChromeOS EC host commands, which is "loaded if the ChromeOS EC implements a PPM":
      https://lkml.iu.edu/hypermail/linux/kernel/2404.1/01362.html (series: https://lwn.net/Articles/1000308/).
      A 2026 series also lets it be loaded from ACPI/OF descriptions:
      https://lkml.iu.edu/hypermail/linux/kernel/2604.0/06154.html
      Framework's EC is Chrome EC-based and already talks host commands to Linux (framework_tool).
      For Linux this would bypass the BIOS mailbox entirely, and everything would be in open code.

    These don't have to compete. The EC could be the PPM behind both: the ACPI mailbox becomes a
    thin transport to the EC's PPM for Windows, and Linux can use either ACPI or cros_ec_ucsi. Only one
    transport should be active per OS, so ports aren't registered twice. Chrome EC's PPM
    (zephyr/subsys/ucsi) is already in this tree.

    3. Longer term: the EC as a full PPM (see the Option A comment above): full-size messages,
    workarounds for PD firmware quirks, and open platform policy (charge-power levels, PPS/AVS, weak
    charger reporting) in the always-on EC.

    In short: step 1 (Infineon firmware) unlocks everything; step 2a is needed for Windows anyway;
    an EC PPM (2b/3) would make the whole stack open and future-proof. Would Framework be willing to
    raise step 1 with Infineon?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions