linux-kernel - [PATCH v1 0/3] Load cros_ec_ucsi from OF and ACPI definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250930012352.413066-1-jthies@google.com>
Date: Tue, 30 Sep 2025 01:23:45 +0000
From: Jameson Thies <jthies@...gle.com>
To: akuchynski@...omium.org, abhishekpandit@...omium.org, krzk+dt@...nel.org, 
	robh@...nel.org, bleung@...omium.org, heikki.krogerus@...ux.intel.com, 
	ukaszb@...omium.org, tzungbi@...nel.org
Cc: devicetree@...r.kernel.org, chrome-platform@...ts.linux.dev, 
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Jameson Thies <jthies@...gle.com>
Subject: [PATCH v1 0/3] Load cros_ec_ucsi from OF and ACPI definitions

The ChromeOS UCSI driver (cros_ec_ucsi) currently gets added as
subdevice of cros_ec_dev. But without it being defined by an ACPI
node or in the OF device tree, the typec connectors are not correctly
associated with other part of the device tree. This series updates the
cros_ec_ucsi driver to load based on device definitions in ACPI and OF.
It also changes the cros_ec_dev driver to block adding cros_ec_ucsi
as a subdevice if it is defined in the device tree.

For context, I initially sent out this series for review in March 2025
(https://lkml.kernel.org/20250312195951.1579682-1-jthies@google.com/).

Patch 1/3 has been updated to address comments from the initial review.
There were some open questions on patch 3/3 regarding adding MFD
children when there is no cros_ec_ucsi node and parents conditionally
checking if a child exists to create one.

The expected behavior of this series is to only add the cros_ec_ucsi
subdevice when there isn't a corresponding FW node because always adding
it would result in multiple cros_ec_ucsi devices and too many ports
being registered with the USB Type-C connector class on devices with
correctly defined FW nodes. It also does not look for a child node to
create a child. It is looking for a child of the parent EC device to
only add cros_ec_ucsi if it does not already exist as a sibling.

Jameson Thies (3):
  dt-bindings: chrome: Add Cros EC UCSI driver
  usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
  mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI

 .../bindings/chrome/google,cros-ec-ucsi.yaml  | 71 +++++++++++++++++++
 drivers/mfd/cros_ec_dev.c                     | 38 ++++++++--
 drivers/usb/typec/ucsi/cros_ec_ucsi.c         | 25 ++++++-
 3 files changed, 127 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/chrome/google,cros-ec-ucsi.yaml

base-commit: 48633acccf38d706d7b368400647bb9db9caf1ae
-- 
2.51.0.570.gb178f27e6d-goog