[BUG] HP OMEN Transcend 14 (board 8E41): GPU power ceiling on 65W USB-C charger is non-deterministic across sessions (25W vs ~65W)

[sjunhyuk1@gmail.com]

Reporting a non-deterministic GPU power ceiling on a 65W USB-C charger,
in case it's useful alongside other recent reports of EC/PD-controller
firmware state issues (Legion Pro 7 16IAX10H, ASUS Vivobook K3605ZV).
I'm not certain this belongs to USB Type-C / UCSI rather than hp-wmi,
so I've sent it to both lists; happy to be redirected.

System
------
Model:  HP OMEN Transcend Gaming Laptop 14-fb1013dx (B94GQUA#ABA)
Board:  8E41
BIOS:   F.05 (confirmed latest via fwupd/LVFS)
GPU:    NVIDIA GeForce RTX 5060 Laptop GPU, VBIOS 98.06.2A.80.62
Driver: NVIDIA Open 610.57.04
Kernel: 7.2.5-3 (Arch, Omarchy)

Symptom
-------
On the OEM-rated 65W USB-C charger, nvidia-smi's "Current Power Limit"
lands on either 25.00W or ~60-65W depending on the boot/reconnect
session, and stays fixed at whichever value for the rest of that
session. A 140W charger reliably gives 50W (VBIOS default TGP);
battery-only reliably gives 40W. Confirmed under gpu_burn 100% load in
both 65W-charger outcomes:

  25W outcome:  24.7-25.5W draw, clock unstable 200-500MHz
  65W outcome:  59.4-64.9W draw, clock stable 1630-1860MHz

Which outcome a given session lands on appears session-scoped, not a
fixed hardware fault: the same physical charger, same port, same
cable produces either result depending on boot/reconnect history.

Ruled out
---------
- Kernel version: same kernel (7.2.5-3-omarchy) produced both the 25W
  and 65W outcomes on different boots.
- Battery charge state: tested 0%, 79%, 98%, 100% within one boot
  session, all still 25W.
- BIOS setting/update: F.05 confirmed latest via fwupd/LVFS; no
  relevant USB-C/adapter option in BIOS setup.
- ucsi_acpi driver presence: blacklisted it entirely, then re-ran the
  known-bad trigger (hot-swap the charger while powered on) - still
  landed on 25W. So the driver being loaded/unloaded is not itself
  the deciding factor.
- HP WMI GPU boost flags (commandtype 0x21/0x22 under command
  HPWMI_GM in hp-wmi.c, the CTGP/PPAB fields of struct
  victus_gpu_power_modes): wrote a read-only probe module issuing
  only the 0x21 GET across all four power states (battery/25W/65W/
  140W-triggered-50W). Raw response was byte-identical (00 01 01 57)
  in every state.
- HP WMI legacy "Smart Adapter" query (commandtype 0x0F under command
  HPWMI_READ; not defined in mainline hp-wmi.c's enum
  hp_wmi_commandtype, but present in a third-party Windows tool as a
  "smart power adapter status" query): also GET-only, also
  byte-identical (05 1c 1c 0d) between the 25W and 65W states.

Workarounds found
------------------
1. Full poweroff, physically unplug/replug the charger, then power
   on. Reliably restores ~65W in testing so far (recovers even from a
   25W-clamped state). An OS reboot alone, with the charger left
   connected, does not help; nor does hot-swapping the charger while
   powered on (that's actually the known trigger for landing on 25W).

2. Live driver reload with no reboot:
       sudo modprobe -r ucsi_acpi && sudo modprobe ucsi_acpi
   From a ~50W "in-between" state reached via a hot-swap, this
   recovered to 65W in 2/2 attempts within a few seconds. From the
   classic 25.00W clamp, it did not help in 2/2 attempts. A
   battery-only control (40W, no charger) showed no change either
   way, suggesting the effect is specific to USB-C PD renegotiation
   rather than a general power-limit reset - but it is clearly not a
   general substitute for (1).

Separately, this board also reproduces the NPCF ACPI-binding issue
described in NVIDIA/open-gpu-kernel-modules#1162 (Power Management
Object stays N/A, Dynamic Boost above the 50W base TGP never
activates) - confirmed via acpidump/iasl decompile, same topology and
field structure as reported there for board 8D40. That explains why
>50W boost never works here, but Power Management Object reads N/A in
both the 25W and 65W states, so it doesn't explain this particular
25W/65W split.

Full write-up with raw capture data:
https://claude.ai/artifact/WDAN76AWk1JpW49ZSGc2Cr

Happy to gather more diagnostics (EC register snapshots, more repro
counts, anything else useful) if that would help narrow this down.