All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex <alex@alstergee.com>
To: Huang Wei <huangwei@kylinos.cn>, heikki.krogerus@linux.intel.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: typec: ucsi: do not register UCSI on Lenovo Legion Pro 7 16IAX10H
Date: Tue, 25 Aug 2026 21:58:14 -0600	[thread overview]
Message-ID: <48aea360-bc09-4d0b-8f0d-84e6da3c61c8@alstergee.com> (raw)
In-Reply-To: <20260826034658.2170407-1-huangwei@kylinos.cn>

Applied on top of Ubuntu 26.04's linux-source-7.0.0 (7.0.0-30.30, kernel
7.0.0-30-generic).  Hunks applied cleanly at -18 line offset. Built just
ucsi_acpi.ko out-of-tree against the running kernel's headers, MOK-signed,
inserted at runtime.

Probe correctly hits the ignore list and refuses to register:

   ucsi_acpi USBC000:00: UCSI implementation in firmware is broken, ignoring

/sys/class/power_supply/ucsi-source-psy-* is absent afterwards (probe
returned before ucsi_register).  A USB-C PD charger connected during the
swap remained connected across the module reload: BAT0 status stayed
Charging, capacity climbed 70% -> 71% during the test, ADP0 online = 1
throughout.  Consistent with the EC handling PD autonomously.

BIOS is Q7CN78WW (2026-04), same behaviour as reported.

Tested-by: Alex Bartz <alex@alstergee.com>

Thanks.

On 8/25/26 9:46 PM, Huang Wei wrote:
> The EC firmware of the Lenovo Legion Pro 7 16IAX10H (DMI product name
> 83F5) has a broken UCSI implementation: GET_PDOS returns no source
> capabilities, GET_CONNECTOR_STATUS reports an incomplete RDO, and any
> UCSI traffic disturbs the EC's autonomous USB-C Power Delivery
> negotiation. With ucsi_acpi bound, chargers connect only briefly and
> then drop, and voltage_now reads 0; with the driver blacklisted, the
> EC negotiates full PD contracts on its own and charging works normally.
>
> The problem is unaffected by BIOS updates up to Q7CN78WW (2026-04).
> The AMD sibling Legion Pro 7 16AFR10H (product name 83RU) reportedly
> uses the same EC firmware, but it is left out of the quirk until the
> failure is confirmed on that model.
>
> Skip probe on this machine, which is equivalent to the blacklist
> workaround the reporter verified to restore charging.
>
> Reported-by: Alex Bartz <alex@alstergee.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221142
> Signed-off-by: Huang Wei <huangwei@kylinos.cn>
> ---
>   drivers/usb/typec/ucsi/ucsi_acpi.c | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
> index 18286d3e9cc5..9f36f8cfce4a 100644
> --- a/drivers/usb/typec/ucsi/ucsi_acpi.c
> +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
> @@ -173,6 +173,21 @@ static const struct dmi_system_id ucsi_acpi_quirks[] = {
>   	{ }
>   };
>   
> +/*
> + * Platforms with a completely broken UCSI implementation in firmware.
> + * Do not register UCSI at all on these machines.
> + */
> +static const struct dmi_system_id ucsi_acpi_ignore[] = {
> +	{
> +		/* Lenovo Legion Pro 7 16IAX10H: broken EC UCSI firmware */
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "83F5"),
> +		},
> +	},
> +	{ }
> +};
> +
>   static void ucsi_acpi_notify(acpi_handle handle, u32 event, void *data)
>   {
>   	struct ucsi_acpi *ua = data;
> @@ -199,6 +214,12 @@ static int ucsi_acpi_probe(struct platform_device *pdev)
>   	if (adev->dep_unmet)
>   		return -EPROBE_DEFER;
>   
> +	if (dmi_check_system(ucsi_acpi_ignore)) {
> +		dev_info(&pdev->dev,
> +			 "UCSI implementation in firmware is broken, ignoring\n");
> +		return -ENODEV;
> +	}
> +
>   	ua = devm_kzalloc(&pdev->dev, sizeof(*ua), GFP_KERNEL);
>   	if (!ua)
>   		return -ENOMEM;

  reply	other threads:[~2026-08-26  3:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26  3:46 [PATCH] usb: typec: ucsi: do not register UCSI on Lenovo Legion Pro 7 16IAX10H Huang Wei
2026-08-26  3:58 ` Alex [this message]
2026-08-26 13:31 ` [PATCH v2] " Huang Wei
2026-08-31 10:15   ` Heikki Krogerus
2026-08-31 10:49     ` Greg KH
2026-09-02  9:05   ` [PATCH v3] " Huang Wei
2026-09-07 10:34     ` Heikki Krogerus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48aea360-bc09-4d0b-8f0d-84e6da3c61c8@alstergee.com \
    --to=alex@alstergee.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=huangwei@kylinos.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.