[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aPX-ZxwaweJjtv3J@kuha.fi.intel.com>
Date: Mon, 20 Oct 2025 12:18:31 +0300
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: "Chia-Lin Kao (AceLan)" <acelan.kao@...onical.com>,
"Chen, Antony" <antony.chen@...el.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Fedor Pchelkin <boddah8794@...il.com>,
Andrei Kuchynski <akuchynski@...omium.org>,
Venkat Jayaraman <venkat.jayaraman@...el.com>,
Myrrh Periwinkle <myrrhperiwinkle@...labs.xyz>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: typec: ucsi: Detect and skip duplicate altmodes
from buggy firmware
+Antony
On Thu, Oct 16, 2025 at 01:53:32PM +0800, Chia-Lin Kao (AceLan) wrote:
> Some firmware implementations incorrectly return the same altmode
> multiple times at different offsets when queried via UCSI_GET_ALTERNATE_MODES.
> This causes sysfs duplicate filename errors and kernel call traces when
> the driver attempts to register the same altmode twice:
>
> sysfs: cannot create duplicate filename '/devices/.../typec/port0/port0.0/partner'
> typec-thunderbolt port0-partner.1: failed to create symlinks
> typec-thunderbolt port0-partner.1: probe with driver typec-thunderbolt failed with error -17
>
> Detect duplicate altmodes by comparing SVID and VDO before registration.
> If a duplicate is detected, skip it and print a single clean warning
> message instead of generating a kernel call trace:
>
> ucsi_acpi USBC000:00: con0: Firmware bug: duplicate partner altmode SVID 0x8087 at offset 1, ignoring. Please update your system firmware.
>
> This makes the error handling more user-friendly while still alerting
> users to the firmware bug.
>
> The fix applies to all three recipient types: partner (SOP), port (CON),
> and plug (SOP_P) altmodes.
>
> Fixes: a79f16efcd00 ("usb: typec: ucsi: Add support for the partner USB Modes")
> Cc: stable@...r.kernel.org
> Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@...onical.com>
Thank you for the patch. Before going forward with this, I would like
to make sure that Dell is not using the GET_ALTERNATE_MODES command in
some customised way deliberately, and that this really is a bug in the
EC firmware.
After seeing the trace output when this happens, it looked to me as
the first response to the GET_ALTERNATE_MODES fills the MID field in
the response data structure with different SVIDs for some reason
(maybe with all supported SVIDs)? If that's deliberate it means we
should drop the first response, and start registering from the second
one.
If I've understood correctly, we have people contacting Dell about
this.
thanks,
--
heikki
Powered by blists - more mailing lists