[PATCH] usb: typec: ucsi: acpi: Assume UCSI 1.0 on HP ZBook 8 G2i 14

[PATCH] usb: typec: ucsi: acpi: Assume UCSI 1.0 on HP ZBook 8 G2i 14

[Ihor Urazov via B4 Relay]

From: Ihor Urazov <z0rc3r@gmail.com>

The HP ZBook 8 G2i 14 (board 8ED9) exposes a working UCSI ACPI PPM, but
its UCSI VERSION field reads zero until the first command completes.
ucsi_register() rejects a zero version with -ENODEV, so no Type-C ports
are registered.

The firmware's _DSM READ function (2) is a stub. The mailbox VERSION
field is written only by the EC response handler, after a command
completes, after which it reads 0x0100 (UCSI 1.0). The mailbox is
48 bytes with 16-byte MESSAGE_IN/MESSAGE_OUT fields, the UCSI 1.x
layout, and _DSM function 5 is not implemented.

Add a DMI-specific read_version for this board that substitutes the
version the firmware itself reports, UCSI 1.0, only when VERSION reads
zero. A non-zero firmware version is used as is.

The same firmware defect on the HP ZBook Fury G1i 16 was discussed in
"[RFC PATCH] usb: typec: ucsi: acpi: bootstrap PPM on HP systems with
empty _DSM func 2" [1]. The defect was reported to HP as case
5166176673.

Tested on an HP ZBook 8 G2i 14 with BIOS Y70 01.02.08, from a fresh
boot where VERSION reads zero: three connectors register, the PD
contract and alternate modes of a Thunderbolt dock are reported, and
its DisplayPort output stays up across the PPM reset in ucsi_init().
Dock unplug/replug and s2idle suspend/resume update the connector
state without errors.

Link: https://lore.kernel.org/linux-usb/f3M_fpjtt8FxDqGKcA84vqXmRbKzCBfpCrIK4-jCWvIscER51zkD8qD8FYpz75qZw51rMDRSkUyYlrBvLvdM8CGRY2l8TFVvr4MC1LdTzbc=@interstellar.eu/ [1]
Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
Cc: stable@vger.kernel.org
Cc: Francesco Orro <ncesco@interstellar.eu>
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Ihor Urazov <z0rc3r@gmail.com>
---
Hi Heikki,

on the Fury G1i RFC you asked for the actual UCSI version instead of a
guess. On this board the firmware itself reports 0x0100 once the first
command completes (read back from the mailbox), and the mailbox layout and
missing _DSM function 5 rule out 2.x. HP has been asked to report it from
boot, case 5166176673.
---
 drivers/usb/typec/ucsi/ucsi_acpi.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 5697ccc24ec3..2421a92ecb0e 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -148,6 +148,34 @@ static const struct ucsi_operations ucsi_acer_ops = {
 	.async_control = ucsi_acpi_async_control
 };
 
+static int ucsi_hp_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;
+
+	/* Firmware fills in VERSION (1.0) only after the first command completes */
+	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_hp_ops = {
+	.read_version = ucsi_hp_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 +224,13 @@ static const struct dmi_system_id ucsi_acpi_quirks[] = {
 		},
 		.driver_data = (void *)&ucsi_acer_ops,
 	},
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+			DMI_MATCH(DMI_BOARD_NAME, "8ED9"),
+		},
+		.driver_data = (void *)&ucsi_hp_ops,
+	},
 	{
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),

---
base-commit: 21a7f44fd0765fcc5194130b28767786eba1d1e7
change-id: 20261026-ucsi-hp-zbook-8-g2i-4446ab6e5ed4

Best regards,
--  
Ihor Urazov <z0rc3r@gmail.com>

Re: [PATCH] usb: typec: ucsi: acpi: Assume UCSI 1.0 on HP ZBook 8 G2i 14

[Heikki Krogerus]

On Mon, Oct 26, 2026 at 01:47:52AM +0200, Ihor Urazov via B4 Relay wrote:
> From: Ihor Urazov <z0rc3r@gmail.com>
> 
> The HP ZBook 8 G2i 14 (board 8ED9) exposes a working UCSI ACPI PPM, but
> its UCSI VERSION field reads zero until the first command completes.
> ucsi_register() rejects a zero version with -ENODEV, so no Type-C ports
> are registered.
> 
> The firmware's _DSM READ function (2) is a stub. The mailbox VERSION
> field is written only by the EC response handler, after a command
> completes, after which it reads 0x0100 (UCSI 1.0). The mailbox is
> 48 bytes with 16-byte MESSAGE_IN/MESSAGE_OUT fields, the UCSI 1.x
> layout, and _DSM function 5 is not implemented.
> 
> Add a DMI-specific read_version for this board that substitutes the
> version the firmware itself reports, UCSI 1.0, only when VERSION reads
> zero. A non-zero firmware version is used as is.
> 
> The same firmware defect on the HP ZBook Fury G1i 16 was discussed in
> "[RFC PATCH] usb: typec: ucsi: acpi: bootstrap PPM on HP systems with
> empty _DSM func 2" [1]. The defect was reported to HP as case
> 5166176673.
> 
> Tested on an HP ZBook 8 G2i 14 with BIOS Y70 01.02.08, from a fresh
> boot where VERSION reads zero: three connectors register, the PD
> contract and alternate modes of a Thunderbolt dock are reported, and
> its DisplayPort output stays up across the PPM reset in ucsi_init().
> Dock unplug/replug and s2idle suspend/resume update the connector
> state without errors.
> 
> Link: https://lore.kernel.org/linux-usb/f3M_fpjtt8FxDqGKcA84vqXmRbKzCBfpCrIK4-jCWvIscER51zkD8qD8FYpz75qZw51rMDRSkUyYlrBvLvdM8CGRY2l8TFVvr4MC1LdTzbc=@interstellar.eu/ [1]
> Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
> Cc: stable@vger.kernel.org
> Cc: Francesco Orro <ncesco@interstellar.eu>
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Ihor Urazov <z0rc3r@gmail.com>

Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>

> ---
> Hi Heikki,
> 
> on the Fury G1i RFC you asked for the actual UCSI version instead of a
> guess. On this board the firmware itself reports 0x0100 once the first
> command completes (read back from the mailbox), and the mailbox layout and
> missing _DSM function 5 rule out 2.x. HP has been asked to report it from
> boot, case 5166176673.
> ---
>  drivers/usb/typec/ucsi/ucsi_acpi.c | 35 +++++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
> index 5697ccc24ec3..2421a92ecb0e 100644
> --- a/drivers/usb/typec/ucsi/ucsi_acpi.c
> +++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
> @@ -148,6 +148,34 @@ static const struct ucsi_operations ucsi_acer_ops = {
>  	.async_control = ucsi_acpi_async_control
>  };
>  
> +static int ucsi_hp_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;
> +
> +	/* Firmware fills in VERSION (1.0) only after the first command completes */
> +	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_hp_ops = {
> +	.read_version = ucsi_hp_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 +224,13 @@ static const struct dmi_system_id ucsi_acpi_quirks[] = {
>  		},
>  		.driver_data = (void *)&ucsi_acer_ops,
>  	},
> +	{
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "HP"),
> +			DMI_MATCH(DMI_BOARD_NAME, "8ED9"),
> +		},
> +		.driver_data = (void *)&ucsi_hp_ops,
> +	},
>  	{
>  		.matches = {
>  			DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
> 
> ---
> base-commit: 21a7f44fd0765fcc5194130b28767786eba1d1e7
> change-id: 20261026-ucsi-hp-zbook-8-g2i-4446ab6e5ed4
> 
> Best regards,
> --  
> Ihor Urazov <z0rc3r@gmail.com>
> 

-- 
heikki

Re: [PATCH] usb: typec: ucsi: acpi: Assume UCSI 1.0 on HP ZBook 8 G2i 14

[Huang Wei]

Hi Ihor,

I had a look at this - the approach looks right, and it follows the
precedent that's already in the tree: ucsi_acer_read_version()
handles the exact same zero-version firmware behaviour on the Acer
Nitro ANV15-41 with the same read-then-substitute pattern, so this
is the second instance of a recurring problem class rather than a
one-off hack. Overriding read_version() is also the clean hook: it's
called from exactly one place in the core (ucsi_register()), so the
substitution fires once per probe, and passing non-zero versions
through unchanged means a later re-registration picks up the real
firmware value once the firmware has filled it in.

One small thing: the Fixes tag points at c1b0bc2dabfa, but the
failure mode being fixed - registration rejected with -ENODEV when
VERSION reads zero - only exists since bdc62f2bae8f ("usb: typec:
ucsi: Simplified registration and I/O API"), which introduced the
!version check. Might be worth pointing the Fixes tag there instead
for accurate attribution, though given the machine is new enough the
stable backport range is academic either way.

Reviewed-by: Huang Wei <huangwei@kylinos.cn>

Thanks,
Huang Wei

Re: [PATCH] usb: typec: ucsi: acpi: Assume UCSI 1.0 on HP ZBook 8 G2i 14

[Francesco Orro]

Hi Ihor,

On Mon, Oct 26, 2026 at 01:47:52AM +0200, Ihor Urazov via B4 Relay wrote:
> The same firmware defect on the HP ZBook Fury G1i 16 was discussed in
> "[RFC PATCH] usb: typec: ucsi: acpi: bootstrap PPM on HP systems with
> empty _DSM func 2" [1]. The defect was reported to HP as case
> 5166176673.

Thanks for picking this up, and for opening the HP case.

The Fury G1i 16 is DMI board "8DE2". Its "UcsiAcpi" SSDT (BIOS X96
01.05.01) matches what you describe for 8ED9: the mailbox is
0x30 bytes with 16-byte MESSAGE_IN/MESSAGE_OUT, _DSM function 0
returns 0x0f (functions 0-3 only), function 2 is a stub, and VERSION
is written only on the EC response path (_Q27 -> UQDC -> UETO, copied
from EC0.UB00/UB01). A PPM_RESET through function 1 completes in
URST(), which sets RESET_COMPLETE directly without going through UETO,
so it does not fill in VERSION either.

I have not run your patch on the Fury yet, so this is based on the
tables only. If an 8DE2 entry next to 8ED9 is wanted, I can test it.

Thanks,
Francesco