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

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

[Jameson Thies]

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.

Jameson Thies (3):
  dt-bindings: Add cros-ec-ucsi to cros-ec-typec device tree
    documentation
  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-typec.yaml | 13 +++++--
 drivers/mfd/cros_ec_dev.c                     | 39 ++++++++++++++++---
 drivers/usb/typec/ucsi/cros_ec_ucsi.c         | 26 ++++++++++++-
 3 files changed, 68 insertions(+), 10 deletions(-)


base-commit: 9fc83373f0ffb8834da48b1446a5c2fef9525bb1
-- 
2.49.0.rc0.332.g42c0ae87b1-goog

[PATCH v1 1/3] dt-bindings: Add cros-ec-ucsi to cros-ec-typec device tree documentation

[Jameson Thies]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="y", Size: 1868 bytes --]

Add documentation for the cros-ec-ucsi device tree definition. Defining
this node will load the cros_ec_ucsi driver which is used for USB-C port
control on PDC based ChromeOS systems. Additionally, update mantainers
list to reflect changes to the ChromeOS USB owners.

Signed-off-by: Jameson Thies <jthies@google.com>
---
 .../bindings/chrome/google,cros-ec-typec.yaml       | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
index 9f9816fbecbc..ab39c5280681 100644
--- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
+++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
@@ -8,17 +8,24 @@ title: Google Chrome OS EC(Embedded Controller) Type C port driver.
 
 maintainers:
   - Benson Leung <bleung@chromium.org>
-  - Prashant Malani <pmalani@chromium.org>
+  - Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
+  - Łukasz Bartosik <ukaszb@chromium.org>
+  - Jameson Thies <jthies@google.com>
+  - Andrei Kuchynski <akuchynski@chromium.org>
 
 description:
   Chrome OS devices have an Embedded Controller(EC) which has access to
   Type C port state. This node is intended to allow the host to read and
   control the Type C ports. The node for this device should be under a
-  cros-ec node like google,cros-ec-spi.
+  cros-ec node like google,cros-ec-spi. On TCPC systems, ChromeOS should
+  use cros-ec-typec. On PDC systems, ChromeOS should use cros-ec-ucsi.
 
 properties:
   compatible:
-    const: google,cros-ec-typec
+    oneOf:
+      - items:
+          - const: google,cros-ec-typec
+          - const: google,cros-ec-ucsi
 
   '#address-cells':
     const: 1
-- 
2.49.0.rc0.332.g42c0ae87b1-goog

Re: [PATCH v1 1/3] dt-bindings: Add cros-ec-ucsi to cros-ec-typec device tree documentation

[Krzysztof Kozlowski]

On 12/03/2025 20:59, Jameson Thies wrote:
> Add documentation for the cros-ec-ucsi device tree definition. Defining
> this node will load the cros_ec_ucsi driver which is used for USB-C port

Your patch does not do it at all.

> control on PDC based ChromeOS systems. Additionally, update mantainers
> list to reflect changes to the ChromeOS USB owners.
> 
> Signed-off-by: Jameson Thies <jthies@google.com>

You need to work on upstream, not downstream trees.

You CC-ed an address, which suggests you do not work on mainline kernel
or you do not use get_maintainers.pl/b4/patman. Please rebase and always
work on mainline or start using mentioned tools, so correct addresses
will be used.

> ---
>  .../bindings/chrome/google,cros-ec-typec.yaml       | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> index 9f9816fbecbc..ab39c5280681 100644
> --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> @@ -8,17 +8,24 @@ title: Google Chrome OS EC(Embedded Controller) Type C port driver.
>  
>  maintainers:
>    - Benson Leung <bleung@chromium.org>
> -  - Prashant Malani <pmalani@chromium.org>
> +  - Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> +  - Łukasz Bartosik <ukaszb@chromium.org>
> +  - Jameson Thies <jthies@google.com>
> +  - Andrei Kuchynski <akuchynski@chromium.org>
>  
>  description:
>    Chrome OS devices have an Embedded Controller(EC) which has access to
>    Type C port state. This node is intended to allow the host to read and
>    control the Type C ports. The node for this device should be under a
> -  cros-ec node like google,cros-ec-spi.
> +  cros-ec node like google,cros-ec-spi. On TCPC systems, ChromeOS should
> +  use cros-ec-typec. On PDC systems, ChromeOS should use cros-ec-ucsi.

What does it mean? How is it related to description?

>  
>  properties:
>    compatible:
> -    const: google,cros-ec-typec
> +    oneOf:
> +      - items:
> +          - const: google,cros-ec-typec
> +          - const: google,cros-ec-ucsi

I don't understand at all why you are growing now this with fallback.
And if you tested your patch, you would see it does not make any sense.

NAK, test your patches before posting.

Best regards,
Krzysztof

Re: [PATCH v1 1/3] dt-bindings: Add cros-ec-ucsi to cros-ec-typec device tree documentation

[Krzysztof Kozlowski]

On 12/03/2025 20:59, Jameson Thies wrote:
> Add documentation for the cros-ec-ucsi device tree definition. Defining
> this node will load the cros_ec_ucsi driver which is used for USB-C port
> control on PDC based ChromeOS systems. Additionally, update mantainers
> list to reflect changes to the ChromeOS USB owners.
> 
> Signed-off-by: Jameson Thies <jthies@google.com>
> ---
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters

A nit, subject: drop second/last, redundant "device tree documentation".
The "dt-bindings" prefix is already stating that these are "device tree
documentation".
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18

Best regards,
Krzysztof

Re: [PATCH v1 1/3] dt-bindings: Add cros-ec-ucsi to cros-ec-typec device tree documentation

[Jameson Thies]

Hi Krzysztof, thank you for taking a look at this series. Clearly it
needs some more work. I’ll follow up with a v2 addressing your
comments.

> > -  cros-ec node like google,cros-ec-spi.
> > +  cros-ec node like google,cros-ec-spi. On TCPC systems, ChromeOS should
> > +  use cros-ec-typec. On PDC systems, ChromeOS should use cros-ec-ucsi.
>
> What does it mean? How is it related to description?

TCPCs and PDCs are different components which can be used for power
delivery messaging on USB-C ports. On ChromeOS devices, they are
mutually exclusive. This line is just saying which driver should be
chosen based on the USB-C port hardware. But, I see that type of
information isn’t really relevant for the device tree documentation.

Thanks,
Jameson

[PATCH v1 2/3] usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions

[Jameson Thies]

Add support for cros_ec_ucsi to load based on "google,cros-ec-ucsi"
compatible devices and "GOOG0021" ACPI nodes.

Signed-off-by: Jameson Thies <jthies@google.com>
---
 drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/ucsi/cros_ec_ucsi.c b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
index c605c8616726..d916893b8908 100644
--- a/drivers/usb/typec/ucsi/cros_ec_ucsi.c
+++ b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
@@ -5,11 +5,13 @@
  * Copyright 2024 Google LLC.
  */
 
+#include <linux/acpi.h>
 #include <linux/container_of.h>
 #include <linux/dev_printk.h>
 #include <linux/jiffies.h>
 #include <linux/mod_devicetable.h>
 #include <linux/module.h>
+#include <linux/of.h>
 #include <linux/platform_data/cros_ec_commands.h>
 #include <linux/platform_data/cros_usbpd_notify.h>
 #include <linux/platform_data/cros_ec_proto.h>
@@ -226,7 +228,6 @@ static void cros_ucsi_destroy(struct cros_ucsi_data *udata)
 static int cros_ucsi_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
 	struct cros_ucsi_data *udata;
 	int ret;
 
@@ -236,7 +237,14 @@ static int cros_ucsi_probe(struct platform_device *pdev)
 
 	udata->dev = dev;
 
-	udata->ec = ec_data->ec_dev;
+	if (is_acpi_device_node(dev->fwnode) || is_of_node(dev->fwnode)) {
+		udata->ec = dev_get_drvdata(pdev->dev.parent);
+	} else {
+		struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
+
+		udata->ec = ec_data->ec_dev;
+	}
+
 	if (!udata->ec)
 		return dev_err_probe(dev, -ENODEV, "couldn't find parent EC device\n");
 
@@ -317,10 +325,24 @@ static const struct platform_device_id cros_ucsi_id[] = {
 };
 MODULE_DEVICE_TABLE(platform, cros_ucsi_id);
 
+static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {
+	{ "GOOG0021", 0 },
+	{ }
+};
+MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);
+
+static const struct of_device_id cros_ucsi_of_match[] = {
+	{ .compatible = "google,cros-ec-ucsi", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);
+
 static struct platform_driver cros_ucsi_driver = {
 	.driver = {
 		.name = KBUILD_MODNAME,
 		.pm = &cros_ucsi_pm_ops,
+		.acpi_match_table = cros_ec_ucsi_acpi_device_ids,
+		.of_match_table = cros_ucsi_of_match,
 	},
 	.id_table = cros_ucsi_id,
 	.probe = cros_ucsi_probe,
-- 
2.49.0.rc0.332.g42c0ae87b1-goog

[PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI

[Jameson Thies]

Check for cros_ec_ucsi to be defined in the OF device tree or an ACPI
node. If it is defined by either OF or ACPI, it does not need to be
added as a subdevice of cros_ec_dev.

Signed-off-by: Jameson Thies <jthies@google.com>
---
 drivers/mfd/cros_ec_dev.c | 39 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 9f84a52b48d6..5fb6cd20c5ec 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2014 Google, Inc.
  */
 
+#include <linux/acpi.h>
 #include <linux/dmi.h>
 #include <linux/kconfig.h>
 #include <linux/mfd/core.h>
@@ -128,11 +129,6 @@ static const struct cros_feature_to_cells cros_subdevices[] = {
 		.mfd_cells	= cros_ec_rtc_cells,
 		.num_cells	= ARRAY_SIZE(cros_ec_rtc_cells),
 	},
-	{
-		.id		= EC_FEATURE_UCSI_PPM,
-		.mfd_cells	= cros_ec_ucsi_cells,
-		.num_cells	= ARRAY_SIZE(cros_ec_ucsi_cells),
-	},
 	{
 		.id		= EC_FEATURE_HANG_DETECT,
 		.mfd_cells	= cros_ec_wdt_cells,
@@ -169,6 +165,15 @@ static const struct mfd_cell cros_ec_vbc_cells[] = {
 	{ .name = "cros-ec-vbc", }
 };
 
+
+static int ucsi_acpi_match(struct device *dev, void *data)
+{
+	struct acpi_device_id ucsi_acpi_device_ids[] = {
+		{ "GOOG0021", 0 },
+	};
+	return !!acpi_match_device(ucsi_acpi_device_ids, dev);
+}
+
 static void cros_ec_class_release(struct device *dev)
 {
 	kfree(to_cros_ec_dev(dev));
@@ -256,6 +261,30 @@ static int ec_device_probe(struct platform_device *pdev)
 		}
 	}
 
+	/*
+	 * FW nodes can load cros_ec_ucsi, but early PDC devices did not define
+	 * the required nodes. On PDC systems without FW nodes for cros_ec_ucsi,
+	 * the driver should be added as an mfd subdevice.
+	 */
+	if (cros_ec_check_features(ec, EC_FEATURE_USB_PD) &&
+	    cros_ec_check_features(ec, EC_FEATURE_UCSI_PPM)) {
+		struct device *acpi_dev = device_find_child(ec->ec_dev->dev,
+							    NULL,
+							    ucsi_acpi_match);
+
+		if (!!acpi_dev) {
+			put_device(acpi_dev);
+		} else if (!of_find_compatible_node(NULL, NULL, "google,cros-ec-ucsi")) {
+			retval = mfd_add_hotplug_devices(ec->dev,
+						cros_ec_ucsi_cells,
+						ARRAY_SIZE(cros_ec_ucsi_cells));
+			if (retval)
+				dev_warn(ec->dev,
+					 "failed to add cros_ec_ucsi: %d\n",
+					 retval);
+		}
+	}
+
 	/*
 	 * UCSI provides power supply information so we don't need to separately
 	 * load the cros_usbpd_charger driver.
-- 
2.49.0.rc0.332.g42c0ae87b1-goog

Re: [PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI

[Krzysztof Kozlowski]

On 12/03/2025 20:59, Jameson Thies wrote:
> Check for cros_ec_ucsi to be defined in the OF device tree or an ACPI
> node. If it is defined by either OF or ACPI, it does not need to be
> added as a subdevice of cros_ec_dev.

No, it does not have to. You just populate the children and appropriate
devices will be created automatically. None of parent devices should
ever check if the child exist to create a child - it makes no sense.

Best regards,
Krzysztof

Re: [PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI

[Krzysztof Kozlowski]

On 13/03/2025 08:11, Krzysztof Kozlowski wrote:
> On 12/03/2025 20:59, Jameson Thies wrote:
>> Check for cros_ec_ucsi to be defined in the OF device tree or an ACPI
>> node. If it is defined by either OF or ACPI, it does not need to be
>> added as a subdevice of cros_ec_dev.
> 
> No, it does not have to. You just populate the children and appropriate

Uh, I did not notice that it is !of_find_compatible_node(), so this
comment should be rephrased - you just add MFD children anyway and if
there is no node, they won't be created.

> devices will be created automatically. None of parent devices should
> ever check if the child exist to create a child - it makes no sense.

This is still valid - none of parents should be poking around to see if
there is a child or not. The core handles it, DT handles it etc.

Best regards,
Krzysztof

Re: [PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI

[kernel test robot]

Hi Jameson,

kernel test robot noticed the following build errors:

[auto build test ERROR on 9fc83373f0ffb8834da48b1446a5c2fef9525bb1]

url:    https://github.com/intel-lab-lkp/linux/commits/Jameson-Thies/dt-bindings-Add-cros-ec-ucsi-to-cros-ec-typec-device-tree-documentation/20250313-040216
base:   9fc83373f0ffb8834da48b1446a5c2fef9525bb1
patch link:    https://lore.kernel.org/r/20250312195951.1579682-4-jthies%40google.com
patch subject: [PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI
config: i386-buildonly-randconfig-001-20250313 (https://download.01.org/0day-ci/archive/20250313/202503132256.f6p359iT-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250313/202503132256.f6p359iT-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202503132256.f6p359iT-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/mfd/cros_ec_dev.c: In function 'ec_device_probe':
>> drivers/mfd/cros_ec_dev.c:273:61: error: passing argument 3 of 'device_find_child' from incompatible pointer type [-Werror=incompatible-pointer-types]
     273 |                                                             ucsi_acpi_match);
         |                                                             ^~~~~~~~~~~~~~~
         |                                                             |
         |                                                             int (*)(struct device *, void *)
   In file included from include/linux/acpi.h:14,
                    from drivers/mfd/cros_ec_dev.c:8:
   include/linux/device.h:1101:49: note: expected 'device_match_t' {aka 'int (*)(struct device *, const void *)'} but argument is of type 'int (*)(struct device *, void *)'
    1101 |                                  device_match_t match);
         |                                  ~~~~~~~~~~~~~~~^~~~~
   cc1: some warnings being treated as errors


vim +/device_find_child +273 drivers/mfd/cros_ec_dev.c

   181	
   182	static int ec_device_probe(struct platform_device *pdev)
   183	{
   184		int retval = -ENOMEM;
   185		struct device_node *node;
   186		struct device *dev = &pdev->dev;
   187		struct cros_ec_platform *ec_platform = dev_get_platdata(dev);
   188		struct cros_ec_dev *ec = kzalloc(sizeof(*ec), GFP_KERNEL);
   189		struct ec_response_pchg_count pchg_count;
   190		int i;
   191	
   192		if (!ec)
   193			return retval;
   194	
   195		dev_set_drvdata(dev, ec);
   196		ec->ec_dev = dev_get_drvdata(dev->parent);
   197		ec->dev = dev;
   198		ec->cmd_offset = ec_platform->cmd_offset;
   199		ec->features.flags[0] = -1U; /* Not cached yet */
   200		ec->features.flags[1] = -1U; /* Not cached yet */
   201		device_initialize(&ec->class_dev);
   202	
   203		for (i = 0; i < ARRAY_SIZE(cros_mcu_devices); i++) {
   204			/*
   205			 * Check whether this is actually a dedicated MCU rather
   206			 * than an standard EC.
   207			 */
   208			if (cros_ec_check_features(ec, cros_mcu_devices[i].id)) {
   209				dev_info(dev, "CrOS %s MCU detected\n",
   210					 cros_mcu_devices[i].desc);
   211				/*
   212				 * Help userspace differentiating ECs from other MCU,
   213				 * regardless of the probing order.
   214				 */
   215				ec_platform->ec_name = cros_mcu_devices[i].name;
   216				break;
   217			}
   218		}
   219	
   220		/*
   221		 * Add the class device
   222		 */
   223		ec->class_dev.class = &cros_class;
   224		ec->class_dev.parent = dev;
   225		ec->class_dev.release = cros_ec_class_release;
   226	
   227		retval = dev_set_name(&ec->class_dev, "%s", ec_platform->ec_name);
   228		if (retval) {
   229			dev_err(dev, "dev_set_name failed => %d\n", retval);
   230			goto failed;
   231		}
   232	
   233		retval = device_add(&ec->class_dev);
   234		if (retval)
   235			goto failed;
   236	
   237		/* check whether this EC is a sensor hub. */
   238		if (cros_ec_get_sensor_count(ec) > 0) {
   239			retval = mfd_add_hotplug_devices(ec->dev,
   240					cros_ec_sensorhub_cells,
   241					ARRAY_SIZE(cros_ec_sensorhub_cells));
   242			if (retval)
   243				dev_err(ec->dev, "failed to add %s subdevice: %d\n",
   244					cros_ec_sensorhub_cells->name, retval);
   245		}
   246	
   247		/*
   248		 * The following subdevices can be detected by sending the
   249		 * EC_FEATURE_GET_CMD Embedded Controller device.
   250		 */
   251		for (i = 0; i < ARRAY_SIZE(cros_subdevices); i++) {
   252			if (cros_ec_check_features(ec, cros_subdevices[i].id)) {
   253				retval = mfd_add_hotplug_devices(ec->dev,
   254							cros_subdevices[i].mfd_cells,
   255							cros_subdevices[i].num_cells);
   256				if (retval)
   257					dev_err(ec->dev,
   258						"failed to add %s subdevice: %d\n",
   259						cros_subdevices[i].mfd_cells->name,
   260						retval);
   261			}
   262		}
   263	
   264		/*
   265		 * FW nodes can load cros_ec_ucsi, but early PDC devices did not define
   266		 * the required nodes. On PDC systems without FW nodes for cros_ec_ucsi,
   267		 * the driver should be added as an mfd subdevice.
   268		 */
   269		if (cros_ec_check_features(ec, EC_FEATURE_USB_PD) &&
   270		    cros_ec_check_features(ec, EC_FEATURE_UCSI_PPM)) {
   271			struct device *acpi_dev = device_find_child(ec->ec_dev->dev,
   272								    NULL,
 > 273								    ucsi_acpi_match);
   274	
   275			if (!!acpi_dev) {
   276				put_device(acpi_dev);
   277			} else if (!of_find_compatible_node(NULL, NULL, "google,cros-ec-ucsi")) {
   278				retval = mfd_add_hotplug_devices(ec->dev,
   279							cros_ec_ucsi_cells,
   280							ARRAY_SIZE(cros_ec_ucsi_cells));
   281				if (retval)
   282					dev_warn(ec->dev,
   283						 "failed to add cros_ec_ucsi: %d\n",
   284						 retval);
   285			}
   286		}
   287	
   288		/*
   289		 * UCSI provides power supply information so we don't need to separately
   290		 * load the cros_usbpd_charger driver.
   291		 */
   292		if (cros_ec_check_features(ec, EC_FEATURE_USB_PD) &&
   293		    !cros_ec_check_features(ec, EC_FEATURE_UCSI_PPM)) {
   294			retval = mfd_add_hotplug_devices(ec->dev,
   295							 cros_usbpd_charger_cells,
   296							 ARRAY_SIZE(cros_usbpd_charger_cells));
   297	
   298			if (retval)
   299				dev_warn(ec->dev, "failed to add usbpd-charger: %d\n",
   300					 retval);
   301		}
   302	
   303		/*
   304		 * Lightbar is a special case. Newer devices support autodetection,
   305		 * but older ones do not.
   306		 */
   307		if (cros_ec_check_features(ec, EC_FEATURE_LIGHTBAR) ||
   308		    dmi_match(DMI_PRODUCT_NAME, "Link")) {
   309			retval = mfd_add_hotplug_devices(ec->dev,
   310						cros_ec_lightbar_cells,
   311						ARRAY_SIZE(cros_ec_lightbar_cells));
   312			if (retval)
   313				dev_warn(ec->dev, "failed to add lightbar: %d\n",
   314					 retval);
   315		}
   316	
   317		/*
   318		 * The PD notifier driver cell is separate since it only needs to be
   319		 * explicitly added on platforms that don't have the PD notifier ACPI
   320		 * device entry defined.
   321		 */
   322		if (IS_ENABLED(CONFIG_OF) && ec->ec_dev->dev->of_node) {
   323			if (cros_ec_check_features(ec, EC_FEATURE_USB_PD)) {
   324				retval = mfd_add_hotplug_devices(ec->dev,
   325						cros_usbpd_notify_cells,
   326						ARRAY_SIZE(cros_usbpd_notify_cells));
   327				if (retval)
   328					dev_err(ec->dev,
   329						"failed to add PD notify devices: %d\n",
   330						retval);
   331			}
   332		}
   333	
   334		/*
   335		 * The PCHG device cannot be detected by sending EC_FEATURE_GET_CMD, but
   336		 * it can be detected by querying the number of peripheral chargers.
   337		 */
   338		retval = cros_ec_cmd(ec->ec_dev, 0, EC_CMD_PCHG_COUNT, NULL, 0,
   339				     &pchg_count, sizeof(pchg_count));
   340		if (retval >= 0 && pchg_count.port_count) {
   341			retval = mfd_add_hotplug_devices(ec->dev,
   342						cros_ec_pchg_cells,
   343						ARRAY_SIZE(cros_ec_pchg_cells));
   344			if (retval)
   345				dev_warn(ec->dev, "failed to add pchg: %d\n",
   346					 retval);
   347		}
   348	
   349		/*
   350		 * The following subdevices cannot be detected by sending the
   351		 * EC_FEATURE_GET_CMD to the Embedded Controller device.
   352		 */
   353		retval = mfd_add_hotplug_devices(ec->dev, cros_ec_platform_cells,
   354						 ARRAY_SIZE(cros_ec_platform_cells));
   355		if (retval)
   356			dev_warn(ec->dev,
   357				 "failed to add cros-ec platform devices: %d\n",
   358				 retval);
   359	
   360		/* Check whether this EC instance has a VBC NVRAM */
   361		node = ec->ec_dev->dev->of_node;
   362		if (of_property_read_bool(node, "google,has-vbc-nvram")) {
   363			retval = mfd_add_hotplug_devices(ec->dev, cros_ec_vbc_cells,
   364							ARRAY_SIZE(cros_ec_vbc_cells));
   365			if (retval)
   366				dev_warn(ec->dev, "failed to add VBC devices: %d\n",
   367					 retval);
   368		}
   369	
   370		return 0;
   371	
   372	failed:
   373		put_device(&ec->class_dev);
   374		return retval;
   375	}
   376	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI

[kernel test robot]

Hi Jameson,

kernel test robot noticed the following build errors:

[auto build test ERROR on 9fc83373f0ffb8834da48b1446a5c2fef9525bb1]

url:    https://github.com/intel-lab-lkp/linux/commits/Jameson-Thies/dt-bindings-Add-cros-ec-ucsi-to-cros-ec-typec-device-tree-documentation/20250313-040216
base:   9fc83373f0ffb8834da48b1446a5c2fef9525bb1
patch link:    https://lore.kernel.org/r/20250312195951.1579682-4-jthies%40google.com
patch subject: [PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI
config: x86_64-buildonly-randconfig-003-20250313 (https://download.01.org/0day-ci/archive/20250313/202503132357.RnlF5A0E-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250313/202503132357.RnlF5A0E-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202503132357.RnlF5A0E-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/mfd/cros_ec_dev.c:273:12: error: incompatible function pointer types passing 'int (struct device *, void *)' to parameter of type 'device_match_t' (aka 'int (*)(struct device *, const void *)') [-Wincompatible-function-pointer-types]
     273 |                                                             ucsi_acpi_match);
         |                                                             ^~~~~~~~~~~~~~~
   include/linux/device.h:1101:21: note: passing argument to parameter 'match' here
    1101 |                                  device_match_t match);
         |                                                 ^
   1 error generated.


vim +273 drivers/mfd/cros_ec_dev.c

   181	
   182	static int ec_device_probe(struct platform_device *pdev)
   183	{
   184		int retval = -ENOMEM;
   185		struct device_node *node;
   186		struct device *dev = &pdev->dev;
   187		struct cros_ec_platform *ec_platform = dev_get_platdata(dev);
   188		struct cros_ec_dev *ec = kzalloc(sizeof(*ec), GFP_KERNEL);
   189		struct ec_response_pchg_count pchg_count;
   190		int i;
   191	
   192		if (!ec)
   193			return retval;
   194	
   195		dev_set_drvdata(dev, ec);
   196		ec->ec_dev = dev_get_drvdata(dev->parent);
   197		ec->dev = dev;
   198		ec->cmd_offset = ec_platform->cmd_offset;
   199		ec->features.flags[0] = -1U; /* Not cached yet */
   200		ec->features.flags[1] = -1U; /* Not cached yet */
   201		device_initialize(&ec->class_dev);
   202	
   203		for (i = 0; i < ARRAY_SIZE(cros_mcu_devices); i++) {
   204			/*
   205			 * Check whether this is actually a dedicated MCU rather
   206			 * than an standard EC.
   207			 */
   208			if (cros_ec_check_features(ec, cros_mcu_devices[i].id)) {
   209				dev_info(dev, "CrOS %s MCU detected\n",
   210					 cros_mcu_devices[i].desc);
   211				/*
   212				 * Help userspace differentiating ECs from other MCU,
   213				 * regardless of the probing order.
   214				 */
   215				ec_platform->ec_name = cros_mcu_devices[i].name;
   216				break;
   217			}
   218		}
   219	
   220		/*
   221		 * Add the class device
   222		 */
   223		ec->class_dev.class = &cros_class;
   224		ec->class_dev.parent = dev;
   225		ec->class_dev.release = cros_ec_class_release;
   226	
   227		retval = dev_set_name(&ec->class_dev, "%s", ec_platform->ec_name);
   228		if (retval) {
   229			dev_err(dev, "dev_set_name failed => %d\n", retval);
   230			goto failed;
   231		}
   232	
   233		retval = device_add(&ec->class_dev);
   234		if (retval)
   235			goto failed;
   236	
   237		/* check whether this EC is a sensor hub. */
   238		if (cros_ec_get_sensor_count(ec) > 0) {
   239			retval = mfd_add_hotplug_devices(ec->dev,
   240					cros_ec_sensorhub_cells,
   241					ARRAY_SIZE(cros_ec_sensorhub_cells));
   242			if (retval)
   243				dev_err(ec->dev, "failed to add %s subdevice: %d\n",
   244					cros_ec_sensorhub_cells->name, retval);
   245		}
   246	
   247		/*
   248		 * The following subdevices can be detected by sending the
   249		 * EC_FEATURE_GET_CMD Embedded Controller device.
   250		 */
   251		for (i = 0; i < ARRAY_SIZE(cros_subdevices); i++) {
   252			if (cros_ec_check_features(ec, cros_subdevices[i].id)) {
   253				retval = mfd_add_hotplug_devices(ec->dev,
   254							cros_subdevices[i].mfd_cells,
   255							cros_subdevices[i].num_cells);
   256				if (retval)
   257					dev_err(ec->dev,
   258						"failed to add %s subdevice: %d\n",
   259						cros_subdevices[i].mfd_cells->name,
   260						retval);
   261			}
   262		}
   263	
   264		/*
   265		 * FW nodes can load cros_ec_ucsi, but early PDC devices did not define
   266		 * the required nodes. On PDC systems without FW nodes for cros_ec_ucsi,
   267		 * the driver should be added as an mfd subdevice.
   268		 */
   269		if (cros_ec_check_features(ec, EC_FEATURE_USB_PD) &&
   270		    cros_ec_check_features(ec, EC_FEATURE_UCSI_PPM)) {
   271			struct device *acpi_dev = device_find_child(ec->ec_dev->dev,
   272								    NULL,
 > 273								    ucsi_acpi_match);
   274	
   275			if (!!acpi_dev) {
   276				put_device(acpi_dev);
   277			} else if (!of_find_compatible_node(NULL, NULL, "google,cros-ec-ucsi")) {
   278				retval = mfd_add_hotplug_devices(ec->dev,
   279							cros_ec_ucsi_cells,
   280							ARRAY_SIZE(cros_ec_ucsi_cells));
   281				if (retval)
   282					dev_warn(ec->dev,
   283						 "failed to add cros_ec_ucsi: %d\n",
   284						 retval);
   285			}
   286		}
   287	
   288		/*
   289		 * UCSI provides power supply information so we don't need to separately
   290		 * load the cros_usbpd_charger driver.
   291		 */
   292		if (cros_ec_check_features(ec, EC_FEATURE_USB_PD) &&
   293		    !cros_ec_check_features(ec, EC_FEATURE_UCSI_PPM)) {
   294			retval = mfd_add_hotplug_devices(ec->dev,
   295							 cros_usbpd_charger_cells,
   296							 ARRAY_SIZE(cros_usbpd_charger_cells));
   297	
   298			if (retval)
   299				dev_warn(ec->dev, "failed to add usbpd-charger: %d\n",
   300					 retval);
   301		}
   302	
   303		/*
   304		 * Lightbar is a special case. Newer devices support autodetection,
   305		 * but older ones do not.
   306		 */
   307		if (cros_ec_check_features(ec, EC_FEATURE_LIGHTBAR) ||
   308		    dmi_match(DMI_PRODUCT_NAME, "Link")) {
   309			retval = mfd_add_hotplug_devices(ec->dev,
   310						cros_ec_lightbar_cells,
   311						ARRAY_SIZE(cros_ec_lightbar_cells));
   312			if (retval)
   313				dev_warn(ec->dev, "failed to add lightbar: %d\n",
   314					 retval);
   315		}
   316	
   317		/*
   318		 * The PD notifier driver cell is separate since it only needs to be
   319		 * explicitly added on platforms that don't have the PD notifier ACPI
   320		 * device entry defined.
   321		 */
   322		if (IS_ENABLED(CONFIG_OF) && ec->ec_dev->dev->of_node) {
   323			if (cros_ec_check_features(ec, EC_FEATURE_USB_PD)) {
   324				retval = mfd_add_hotplug_devices(ec->dev,
   325						cros_usbpd_notify_cells,
   326						ARRAY_SIZE(cros_usbpd_notify_cells));
   327				if (retval)
   328					dev_err(ec->dev,
   329						"failed to add PD notify devices: %d\n",
   330						retval);
   331			}
   332		}
   333	
   334		/*
   335		 * The PCHG device cannot be detected by sending EC_FEATURE_GET_CMD, but
   336		 * it can be detected by querying the number of peripheral chargers.
   337		 */
   338		retval = cros_ec_cmd(ec->ec_dev, 0, EC_CMD_PCHG_COUNT, NULL, 0,
   339				     &pchg_count, sizeof(pchg_count));
   340		if (retval >= 0 && pchg_count.port_count) {
   341			retval = mfd_add_hotplug_devices(ec->dev,
   342						cros_ec_pchg_cells,
   343						ARRAY_SIZE(cros_ec_pchg_cells));
   344			if (retval)
   345				dev_warn(ec->dev, "failed to add pchg: %d\n",
   346					 retval);
   347		}
   348	
   349		/*
   350		 * The following subdevices cannot be detected by sending the
   351		 * EC_FEATURE_GET_CMD to the Embedded Controller device.
   352		 */
   353		retval = mfd_add_hotplug_devices(ec->dev, cros_ec_platform_cells,
   354						 ARRAY_SIZE(cros_ec_platform_cells));
   355		if (retval)
   356			dev_warn(ec->dev,
   357				 "failed to add cros-ec platform devices: %d\n",
   358				 retval);
   359	
   360		/* Check whether this EC instance has a VBC NVRAM */
   361		node = ec->ec_dev->dev->of_node;
   362		if (of_property_read_bool(node, "google,has-vbc-nvram")) {
   363			retval = mfd_add_hotplug_devices(ec->dev, cros_ec_vbc_cells,
   364							ARRAY_SIZE(cros_ec_vbc_cells));
   365			if (retval)
   366				dev_warn(ec->dev, "failed to add VBC devices: %d\n",
   367					 retval);
   368		}
   369	
   370		return 0;
   371	
   372	failed:
   373		put_device(&ec->class_dev);
   374		return retval;
   375	}
   376	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI

[Jameson Thies]

Echoing my response on patch 1/3, thank you for taking a look at this.
I’ll follow up with a v2 series to address your comments and resolve
the build issues. Additional responses below.

> > devices will be created automatically. None of parent devices should
> > ever check if the child exist to create a child - it makes no sense.
>
> This is still valid - none of parents should be poking around to see if
> there is a child or not. The core handles it, DT handles it etc.
>

Understood, we can remove this for DT. We need to keep part of this
check for ACPI because there are platforms which need this driver and
haven't defined proper ACPI nodes in their FW to load cros_ec_ucsi.

Thanks,
Jameson

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

[Jameson Thies]

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

[PATCH v1 3/3] mfd: cros_ec: Don't add cros_ec_ucsi if it is defined in OF or ACPI

[Jameson Thies]

On devices with a UCSI PPM in the EC, check for cros_ec_ucsi to be
defined in the OF device tree or an ACPI node. If it is defined by
either OF or ACPI, it does not need to be added as a subdevice of
cros_ec_dev.

Signed-off-by: Jameson Thies <jthies@google.com>
---
 drivers/mfd/cros_ec_dev.c | 40 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index dc80a272726b..b0523f6541d2 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2014 Google, Inc.
  */
 
+#include <linux/acpi.h>
 #include <linux/dmi.h>
 #include <linux/kconfig.h>
 #include <linux/mfd/core.h>
@@ -131,11 +132,6 @@ static const struct cros_feature_to_cells cros_subdevices[] = {
 		.mfd_cells	= cros_ec_rtc_cells,
 		.num_cells	= ARRAY_SIZE(cros_ec_rtc_cells),
 	},
-	{
-		.id		= EC_FEATURE_UCSI_PPM,
-		.mfd_cells	= cros_ec_ucsi_cells,
-		.num_cells	= ARRAY_SIZE(cros_ec_ucsi_cells),
-	},
 	{
 		.id		= EC_FEATURE_HANG_DETECT,
 		.mfd_cells	= cros_ec_wdt_cells,
@@ -177,6 +173,16 @@ static const struct mfd_cell cros_ec_vbc_cells[] = {
 	{ .name = "cros-ec-vbc", }
 };
 
+static int ucsi_acpi_match(struct device *dev, const void *data)
+{
+	struct acpi_device_id ucsi_acpi_device_ids[] = {
+		{ "GOOG0021", 0 },
+		{"", 0},
+	};
+	return !!acpi_match_device(ucsi_acpi_device_ids, dev);
+}
+
+
 static void cros_ec_class_release(struct device *dev)
 {
 	kfree(to_cros_ec_dev(dev));
@@ -264,6 +270,30 @@ static int ec_device_probe(struct platform_device *pdev)
 		}
 	}
 
+	/*
+	 * FW nodes can load cros_ec_ucsi, but early PDC devices did not define
+	 * the required nodes. On PDC systems without FW nodes for cros_ec_ucsi,
+	 * the driver should be added as an mfd subdevice.
+	 */
+	if (cros_ec_check_features(ec, EC_FEATURE_USB_PD) &&
+	    cros_ec_check_features(ec, EC_FEATURE_UCSI_PPM)) {
+		struct device *acpi_dev = device_find_child(ec->ec_dev->dev,
+							    NULL,
+							    ucsi_acpi_match);
+
+		if (!!acpi_dev) {
+			put_device(acpi_dev);
+		} else if (!of_find_compatible_node(NULL, NULL,
+						    "google,cros-ec-ucsi")) {
+			retval = mfd_add_hotplug_devices(
+				ec->dev, cros_ec_ucsi_cells,
+				ARRAY_SIZE(cros_ec_ucsi_cells));
+			if (retval)
+				dev_warn(ec->dev,
+				    "failed to add cros_ec_ucsi: %d\n", retval);
+		}
+	}
+
 	/*
 	 * UCSI provides power supply information so we don't need to separately
 	 * load the cros_usbpd_charger driver.
-- 
2.51.0.570.gb178f27e6d-goog