| From: |
| Amber Kao <amber.kao-AT-ite.com.tw> |
| To: |
| Greg Kroah-Hartman <gregkh-AT-linuxfoundation.org>, Rob Herring <robh-AT-kernel.org>, Krzysztof Kozlowski <krzk+dt-AT-kernel.org>, Conor Dooley <conor+dt-AT-kernel.org>, Jeson Yang <jeson.yang-AT-ite.com.tw>, Yaode Fang <Yaode.Fang-AT-ite.com.tw>, Bling Chiang <Bling.Chiang-AT-ite.com.tw>, Eric Su <Eric.Su-AT-ite.com.tw>, Doreen Lin <doreen.lin-AT-ite.com.tw>, Heikki Krogerus <heikki.krogerus-AT-linux.intel.com> |
| Subject: |
| [PATCH 0/2] Add support for ITE IT885x USB PD controller |
| Date: |
| Mon, 15 Jun 2026 21:47:38 +0800 |
| Message-ID: |
| <20260615-ucsi-itepd-feature-v1-0-a826cfd0df6a@ite.com.tw> |
| Cc: |
| <linux-usb-AT-vger.kernel.org>, <devicetree-AT-vger.kernel.org>, <linux-kernel-AT-vger.kernel.org>, Amber Kao <amber.kao-AT-ite.com.tw> |
| Archive-link: |
| Article |
This series adds Device Tree bindings and driver support for the ITE IT885x
USB Type-C Power Delivery controller over I2C. The driver uses the auxiliary
bus to spawn UCSI and Alternate Mode child devices from the main I2C core
driver.
Note: This driver has not been tested on physical hardware. Runtime
verification was performed using i2c-stub emulation with force-binding
on an x86_64 virtual machine.
Testing performed:
- checkpatch.pl: no errors or warnings
- dtschema (dt_binding_check): no errors or warnings
- Sparse static analysis (C=2 W=1): no errors or warnings
- checkstack.pl: no functions exceed 512-byte stack limit on x86_64 and arm64
- Dependency check (allnoconfig + make): all dependency is been added
- Kconfig tristate: tested =m, =y, =n and allmodconfig
- Cross-compilation: x86_64, arm64, arm32, powerpc64
- CONFIG_SMP and CONFIG_PREEMPT: both on and off
- Strict warning mode (W=1 EXTRA_CFLAGS=-W): no new warnings
- Fault injection (CONFIG_FAILSLAB): error paths verified on modified kernel
Question regarding Fault Injection testing:
Since physical hardware is currently unavailable for testing, my approach to
verifying the error handling paths was to temporarily modify the driver code
(e.g., forcing a function to return -ENOMEM), run the mock tests, and then
revert the code once passed. Is this ad-hoc instrumentation approach
acceptable for submission under these constraints, or is there an officially
recommended fault injection method that the community prefers for this kind of validation?
Signed-off-by: Amber Kao <amber.kao@ite.com.tw>
---
Amber Kao (2):
dt-bindings: usb: Add ITE IT885x support
usb: typec: ucsi: Add ITE IT885x Type-C PD controller driver
.../devicetree/bindings/usb/ite,itepd-it885x.yaml | 109 ++++
MAINTAINERS | 15 +
drivers/usb/typec/ucsi/Kconfig | 15 +
drivers/usb/typec/ucsi/Makefile | 1 +
drivers/usb/typec/ucsi/itepd.c | 481 ++++++++++++++++++
drivers/usb/typec/ucsi/itepd.h | 64 +++
drivers/usb/typec/ucsi/itepd_altmode.c | 438 ++++++++++++++++
drivers/usb/typec/ucsi/ucsi_itepd.c | 558 +++++++++++++++++++++
8 files changed, 1681 insertions(+)
---
base-commit: 8fde5d1d47f69db6082dfa34500c27f8485389a5
change-id: 20260605-ucsi-itepd-feature-95e6dcee4fc5
Best regards,
--
Amber Kao <amber.kao@ite.com.tw>
