mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Mark Pearson" <mpearson-lenovo@squebb.ca>
To: kernel@resetko.pl,
	"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	"Guenter Roeck" <linux@roeck-us.net>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Daniel Dev" <daniel.dev@noex.uk>,
	stable@vger.kernel.org
Subject: Re: [PATCH] usb: typec: ucsi: acpi: Assume UCSI 1.0 on Lenovo ThinkPad T14 Gen 2a
Date: Sun, 01 Nov 2026 17:50:27 -0500	[thread overview]
Message-ID: <8d0c94b6-8fd0-4fde-8af5-ade15e142a0e@app.fastmail.com> (raw)
In-Reply-To: <20261031-ucsi-lenovo-t14g2a-v1-1-183751e63c02@resetko.pl>

Hi Stanislaw,

On Sat, Oct 31, 2026, at 5:40 PM, Stanisław Titenko via B4 Relay wrote:
> From: Stanisław Titenko <kernel@resetko.pl>
>
> The Lenovo ThinkPad T14 Gen 2a exposes a functional UCSI ACPI PPM but
> the firmware leaves the VERSION field of the UCSI mailbox at zero.
>
> ucsi_register() rejects a zero version with -ENODEV, leaving the
> system without registered USB Type-C connectors. Without an OPM, the
> embedded controller does not complete DisplayPort Alternate Mode setup
> when a USB-C dock or monitor that supplies power is connected after
> boot, so the display stays dark while USB and charging work.
>
> The mailbox uses the 48-byte UCSI 1.x layout, and the PPM works
> correctly when UCSI 1.0 is assumed.
>
> Add a DMI-specific UCSI operation for the ThinkPad T14 Gen 2a that
> substitutes UCSI 1.0 only when firmware reports a zero version.
> Preserve any valid non-zero firmware version.
>
> Tested on a ThinkPad T14 Gen 2a with BIOS 1.33 (R1MET63W): both
> Type-C connectors register, and plugging and replugging a USB-C
> monitor with an integrated hub and power delivery brings up
> DisplayPort Alternate Mode each time.
>
> Reported-by: Daniel Dev <daniel.dev@noex.uk>
> Closes: 
> https://lore.kernel.org/linux-usb/b1Wn_eFvTFShGbd970WWl4CWhge_6P2x7Wb6rab3QHNlE4OJ4p__O-QN3B6I-308ftr5oV5Zr7vywA0vdvmtNw6E0YJnVM2ek_5DcFnkXB0=@noex.uk/
> Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
> Cc: stable@vger.kernel.org
> Assisted-by: pi:claude-opus-5-5
> Signed-off-by: Stanisław Titenko <kernel@resetko.pl>

This platform was Linux certified so let me see if I can get the FW team to look at it (it is an older platform, but it looks like it's still under support)
I don't have this HW myself, so I'll need to ask the team in Japan to reproduce the issue. My personal preference would be to try and get the FW fixed first and do the quirk if for some reason that isn't possible.

> ---
>  drivers/usb/typec/ucsi/ucsi_acpi.c | 34 
> ++++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c 
> b/drivers/usb/typec/ucsi/ucsi_acpi.c
> index 5697ccc24ec3..33747e24353f 100644
> --- a/drivers/usb/typec/ucsi/ucsi_acpi.c
> +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
> @@ -148,6 +148,33 @@ static const struct ucsi_operations ucsi_acer_ops 
> = {
>  	.async_control = ucsi_acpi_async_control
>  };
> 
> +static int ucsi_lenovo_read_version(struct ucsi *ucsi, u16 *version)
> +{
> +	struct ucsi_acpi *ua = ucsi_get_drvdata(ucsi);
> +	int ret;
> +
> +	ret = ucsi_acpi_read_version(ucsi, version);
> +	if (ret)
> +		return ret;
> +
> +	if (!*version) {
> +		dev_warn(ua->dev, "UCSI version is zero, assuming 1.0\n");
> +		*version = UCSI_VERSION_1_0;
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct ucsi_operations ucsi_lenovo_ops = {
> +	.read_version = ucsi_lenovo_read_version,
> +	.read_cci = ucsi_acpi_read_cci,
> +	.poll_cci = ucsi_acpi_poll_cci,
> +	.read_message_in = ucsi_acpi_read_message_in,
> +	.write_message_out = ucsi_acpi_write_message_out,
> +	.sync_control = ucsi_sync_control_common,
> +	.async_control = ucsi_acpi_async_control
> +};
> +
>  static int ucsi_gram_sync_control(struct ucsi *ucsi, u64 command, u32 *cci,
>  				  void *val, size_t len, void *msg_out,
>  				  size_t msg_out_size)
> @@ -196,6 +223,13 @@ static const struct dmi_system_id ucsi_acpi_quirks[] = {
>  		},
>  		.driver_data = (void *)&ucsi_acer_ops,
>  	},
> +	{
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T14 Gen 2a"),
> +		},
> +		.driver_data = (void *)&ucsi_lenovo_ops,
> +	},
>  	{
>  		.matches = {
>  			DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
>

1) Couldn't you just reuse the ucsi_acer_ops quirk?

2) Better to use DMI_BOARD_NAME for the DMI match. For the T14 G2 AMD there are two possible matches - "20XK" and "20XL".

Thanks
Mark

      reply	other threads:[~2026-11-01 22:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-31 21:40 Stanisław Titenko via B4 Relay
2026-11-01 22:50 ` Mark Pearson [this message]

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=8d0c94b6-8fd0-4fde-8af5-ade15e142a0e@app.fastmail.com \
    --to=mpearson-lenovo@squebb.ca \
    --cc=daniel.dev@noex.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=kernel@resetko.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®