EC returns a CCI Error when querying for GET_CABLE_PROPERTY (0x11) #72

Activity

1. KateDavidsonGS commented on Jan 30, 2026

   

   KateDavidsonGS

   on Jan 30, 2026

   More actions

   I have the same thing in my logs on my AMD Ryzen 5 7640U Framework 13 whenever I connect the charger.

   Probably not relevant but I have my charge limit set to 60% in UEFI 🤷🏻‍♀️

   14:24:00 kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
   11:45:59 kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
   
2. mitar commented on Nov 3, 2026

   

   mitar

   on Nov 3, 2026

   More actions

   I see the same unknown error 256 on a Framework Laptop 13 (AMD Ryzen AI 9 HX 370, BIOS 04.02, EC lilac-4.0.2-fdbf549, PD controllers 0.0.21, Linux 7.0), but here it comes from a different command than GET_CABLE_PROPERTY: GET_ALTERNATE_MODES for the cable plug (SOP'). In case it helps someone looking into this, this is how to find which command fails without patching the kernel.

   256 is bit 8 of the error status, UCSI_ERROR_UNDEFINED, which the kernel prints as "unknown error". The kernel calls ucsi_read_error() after every command whose CCI has the error bit set, so a kprobe with a stack trace there shows which command it was:

   cd /sys/kernel/tracing
   echo "p:ucsi_err typec_ucsi:ucsi_read_error" >> kprobe_events
   echo stacktrace > events/kprobes/ucsi_err/trigger
   echo 1 > events/kprobes/ucsi_err/enable
   # unplug and plug in a USB-C device, then:
   cat trace

   Unplugging and plugging in my dock gives two hits, matching the two kernel messages at that moment:

   ucsi_err: (ucsi_read_error+0x0/0xe0 [typec_ucsi])
    => ucsi_read_error
    => ucsi_read_pdos
    => ucsi_get_pdos.part.0
    => ucsi_get_src_pdos
    => ucsi_poll_worker
   ucsi_acpi USBC000:00: UCSI_GET_PDOS failed (-95)
   
   ucsi_err: (ucsi_read_error+0x0/0xe0 [typec_ucsi])
    => ucsi_read_error
    => ucsi_register_altmodes
    => ucsi_check_cable
    => ucsi_poll_worker
   ucsi_acpi USBC000:00: unknown error 256
   

   The second one is ucsi_check_cable() calling ucsi_register_altmodes(con, UCSI_RECIPIENT_SOP_P), so GET_ALTERNATE_MODES with recipient SOP'. The kernel only sends it because GET_CAPABILITY sets UCSI_CAP_ALT_MODE_DETAILS. It fails on the first query: no plug alternate mode is registered, and the plug never has its number of alternate modes set (/sys/class/typec/port0-plug0/number_of_alternate_modes stays empty). I get one such error for every port with something attached at every boot, and one each time I plug in the dock. Here that is the dock's cable on one port and an expansion card in the other bay on the same side, which the PD controller reports as a passive cable with a Type-A plug end (/sys/class/typec/port1-cable/type and plug_type). Neither has alternate modes as a plug. For a plug without alternate modes I would expect an empty answer instead of an error.

   As far as I can tell from zephyr/program/framework/src/ucsi.c, the EC passes GET_ALTERNATE_MODES through to the PD controller and returns its answer, so the error would come from the PD controller's firmware. If a PD firmware change is not practical, the EC could perhaps answer this command for SOP' with no alternate modes when the PD controller reports an error.

   The first hit is GET_PDOS for the partner's source PDOs right after the dock is attached or the laptop resumes: the error status is UCSI_ERROR_INCOMPATIBLE_PARTNER, which the kernel turns into -95. Later reads work: the dock's source capabilities (5 V to 20 V, 4.5 A at 20 V) are listed under /sys/class/usb_power_delivery/, so this one seems to be only a timing issue.

   Nothing is broken by either error, charging and the dock work. They only fill the kernel log, and they make it look like USB-C has a problem.