Message ID | 20221117114818.v7.3.Ie23c217d69ff25d7354db942613f143bbc8ef891@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp575775wrr; Thu, 17 Nov 2022 11:11:02 -0800 (PST) X-Google-Smtp-Source: AA0mqf4UosnRHjHiCYLacWFcI/Zfzn5nDswrEVKDRPiFAZlJquIRF05Pe3KDReCAaA+pmUZA64GJ X-Received: by 2002:a17:907:766c:b0:7af:6ab:1d8d with SMTP id kk12-20020a170907766c00b007af06ab1d8dmr3203536ejc.211.1668712261968; Thu, 17 Nov 2022 11:11:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668712261; cv=none; d=google.com; s=arc-20160816; b=MruFE7IPHL8G1uWyAyg3yJ15MOccsE7hDchhIkttYp8mHUeqZUgNyA3GDwxJNSv6B/ nLg7ujG6TI8IwqY4u/kW0Q09zFh0fYnJbMabYqKuBbG7JX974bNyQZUd3o/cn7cNMJdH CmLNopbzumQeOl8nOz2QSaHFlNHcyI5VDdjUS58eGBQkjhgvcnnFzkUg4h8aLJxc6ANp GzrO2WJJIpDFHndzVmCX9g42aoGsRwz3lj5bFnhUtfJ5VmSEgMCbewx9GqJuZynjhN1O z5M5YOOGzfoXt7moUwrxnCaTK1kXSsw2SETFU70Fhi+cm/0Df9CdpR0BF3GXxWQ4fK5w TI9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=vwzrdAjSSAlR7tomqz0SMFI6hrURlEbNjDi6TcOBnt0=; b=yD17JwoGuXiWkPBTTeDK2634A2nVT9jow1ZSlgKlac8i2EKxgLUEkiQ7FRjVuDp/0R jk3GDAvKlKlyZC+ceJTVC6nMvcjM4V+Sllv7jVMwsuMm5t1UDjP5nDqdXyh+xBNdmVap 98sz7c9vln4a4/HMPrwwEQEyUrBifgZsbJg5OXJ48ag9PKjENr0EtF3RVHggXBr43bol WWisUPysf1XZ2Xw8CMHo1xL898wr7el+Kqd61G2Wk9CLZV5+m83Ar1op20TbDez1BWwQ EVUcdUHusizVycttq1hXbq6vTlVz0ExrJiDBGYiFY2vwfr0vo93NN3IayQTBsgCsh0QN rpRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=E44uNGH0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ss28-20020a170907c01c00b0078de4629958si961364ejc.248.2022.11.17.11.10.37; Thu, 17 Nov 2022 11:11:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=E44uNGH0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240638AbiKQStg (ORCPT <rfc822;a1648639935@gmail.com> + 99 others); Thu, 17 Nov 2022 13:49:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239783AbiKQSt0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 17 Nov 2022 13:49:26 -0500 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 725525917F for <linux-kernel@vger.kernel.org>; Thu, 17 Nov 2022 10:49:23 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id z3so2084088iof.3 for <linux-kernel@vger.kernel.org>; Thu, 17 Nov 2022 10:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vwzrdAjSSAlR7tomqz0SMFI6hrURlEbNjDi6TcOBnt0=; b=E44uNGH0u4GiDI9/R8ntoTWwFpkCtXbQQISOpey6uGAk8d9oQyqEokIve+OP7X6gVR vBmMGMWfG2WltzzHPFvFHfREQNQwg7TMLrWzUDVYt2IXsK6xdSGVW8g67dbp11FwLfUj fTbO/ELwd/VaXdxMYgeS87+EWIbSshQFaJ334= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vwzrdAjSSAlR7tomqz0SMFI6hrURlEbNjDi6TcOBnt0=; b=H6B/CPpVTIQ+uvAU6aPQWBdZfIT3cKeC5P7dwmo5j7pG0/SE3faLoDnHJbZaCL/wAu ao+SPfAtLOZNVheSbEFM2h73aQkXnXWNKLl6GQOLI5E4++N8m0D6hdI03GcxKU+Iekqr oITZu83Fs+lT2nev1FNisSZgHm/DFMpJiQPrwPeiVaMcN0F74CIP0+hYRJSNhfWhGB6s 9GMIcv55gNrYjBGRJrf0nwiSrzkkkQ41CZO3E2qMmPiazCYztb1bYmNLNwV6KLa72BKr uMHkVpDoXyeHNA3cY6llFhgaCCLlFjHxoxYwOH6aidW0W6IOGEi3HVtsvr84/tiz+2Eu W90g== X-Gm-Message-State: ANoB5pkIxHApAGVYQEOi3bEk0sxjlKrFJMTZjx5/fa9QVbzPHV7pXZ8k y8ug6tdnERoMghk4/eu86HeuFCbFNLCaNUmBtnk= X-Received: by 2002:a02:5dc1:0:b0:375:eb33:f73e with SMTP id w184-20020a025dc1000000b00375eb33f73emr1609076jaa.171.1668710963450; Thu, 17 Nov 2022 10:49:23 -0800 (PST) Received: from markhas1.corp.google.com ([100.107.108.223]) by smtp.gmail.com with ESMTPSA id q6-20020a02a986000000b00363faa1ea9asm503282jam.15.2022.11.17.10.49.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 10:49:23 -0800 (PST) From: Mark Hasemeyer <markhas@chromium.org> To: LKML <linux-kernel@vger.kernel.org> Cc: Raul Rangel <rrangel@chromium.org>, Mark Hasemeyer <markhas@chromium.org>, Bhanu Prakash Maiya <bhanumaiya@chromium.org>, Benson Leung <bleung@chromium.org>, Enric Balletbo i Serra <enric.balletbo@collabora.com>, Guenter Roeck <groeck@chromium.org>, chrome-platform@lists.linux.dev Subject: [PATCH v7 3/3] platform/chrome: cros_ec_uart: Add DT enumeration support Date: Thu, 17 Nov 2022 11:48:48 -0700 Message-Id: <20221117114818.v7.3.Ie23c217d69ff25d7354db942613f143bbc8ef891@changeid> X-Mailer: git-send-email 2.38.1.584.g0f3c55d4c2-goog In-Reply-To: <20221117114818.v7.1.If7926fcbad397bc6990dd725690229bed403948c@changeid> References: <20221117114818.v7.1.If7926fcbad397bc6990dd725690229bed403948c@changeid> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749771628468915250?= X-GMAIL-MSGID: =?utf-8?q?1749771628468915250?= |
Series |
[v7,1/3] platform/chrome: cros_ec_uart: Add cros-ec-uart transport layer
|
|
Commit Message
Mark Hasemeyer
Nov. 17, 2022, 6:48 p.m. UTC
Existing firmware uses the "PRP0001" _HID and an associated compatible string to enumerate the cros_ec_uart. Add DT enumeration support for already shipped firmware. Signed-off-by: Bhanu Prakash Maiya <bhanumaiya@chromium.org> Signed-off-by: Mark Hasemeyer <markhas@chromium.org> --- Changes in v7: - Move PRP0001 enumeration support to its own commit drivers/platform/chrome/cros_ec_uart.c | 8 ++++++++ 1 file changed, 8 insertions(+)
Comments
On Thu, Nov 17, 2022 at 11:48:48AM -0700, Mark Hasemeyer wrote: > @@ -392,6 +393,12 @@ static int __maybe_unused cros_ec_uart_resume(struct device *dev) > static SIMPLE_DEV_PM_OPS(cros_ec_uart_pm_ops, cros_ec_uart_suspend, > cros_ec_uart_resume); > > +static const struct of_device_id cros_ec_uart_of_match[] = { > + { .compatible = "google,cros-ec-uart" }, > + {} > +}; > +MODULE_DEVICE_TABLE(of, cros_ec_uart_of_match); It would need a guard for checking CONFIG_OF. Similar to what `cros_ec_uart_acpi_id` does. > @@ -405,6 +412,7 @@ static struct serdev_device_driver cros_ec_uart_driver = { > .driver = { > .name = "cros-ec-uart", > .acpi_match_table = ACPI_PTR(cros_ec_uart_acpi_id), > + .of_match_table = cros_ec_uart_of_match, It would need be wrapped by `of_match_ptr()`. Similar to what `ACPI_PTR()` does.
> > @@ -392,6 +393,12 @@ static int __maybe_unused cros_ec_uart_resume(struct device *dev) > > static SIMPLE_DEV_PM_OPS(cros_ec_uart_pm_ops, cros_ec_uart_suspend, > > cros_ec_uart_resume); > > > > +static const struct of_device_id cros_ec_uart_of_match[] = { > > + { .compatible = "google,cros-ec-uart" }, > > + {} > > +}; > > +MODULE_DEVICE_TABLE(of, cros_ec_uart_of_match); > > It would need a guard for checking CONFIG_OF. Similar to what > `cros_ec_uart_acpi_id` does. > > > @@ -405,6 +412,7 @@ static struct serdev_device_driver cros_ec_uart_driver = { > > .driver = { > > .name = "cros-ec-uart", > > .acpi_match_table = ACPI_PTR(cros_ec_uart_acpi_id), > > + .of_match_table = cros_ec_uart_of_match, > > It would need be wrapped by `of_match_ptr()`. Similar to what > `ACPI_PTR()` does. I'm not sure we want a guard in this case because we compile the kernel without CONFIG_OF enabled for (most?) x86 platforms. Yet we still need the device tree code to enumerate using the PRP0001 _HID method.
On Tue, Nov 29, 2022 at 11:13:04AM -0700, Mark Hasemeyer wrote: > > > @@ -392,6 +393,12 @@ static int __maybe_unused cros_ec_uart_resume(struct device *dev) > > > static SIMPLE_DEV_PM_OPS(cros_ec_uart_pm_ops, cros_ec_uart_suspend, > > > cros_ec_uart_resume); > > > > > > +static const struct of_device_id cros_ec_uart_of_match[] = { > > > + { .compatible = "google,cros-ec-uart" }, > > > + {} > > > +}; > > > +MODULE_DEVICE_TABLE(of, cros_ec_uart_of_match); > > > > It would need a guard for checking CONFIG_OF. Similar to what > > `cros_ec_uart_acpi_id` does. > > > > > @@ -405,6 +412,7 @@ static struct serdev_device_driver cros_ec_uart_driver = { > > > .driver = { > > > .name = "cros-ec-uart", > > > .acpi_match_table = ACPI_PTR(cros_ec_uart_acpi_id), > > > + .of_match_table = cros_ec_uart_of_match, > > > > It would need be wrapped by `of_match_ptr()`. Similar to what > > `ACPI_PTR()` does. > > I'm not sure we want a guard in this case because we compile the kernel without > CONFIG_OF enabled for (most?) x86 platforms. Yet we still need the device > tree code to enumerate using the PRP0001 _HID method. I'm not familiar to ACPI. However, I thought it should add the compatible string in the _DSD instead of using of_match for the case. See example in [1]. [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id
On Wed, Nov 30, 2022 at 12:10 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote: > > On Tue, Nov 29, 2022 at 11:13:04AM -0700, Mark Hasemeyer wrote: > > > > @@ -392,6 +393,12 @@ static int __maybe_unused cros_ec_uart_resume(struct device *dev) > > > > static SIMPLE_DEV_PM_OPS(cros_ec_uart_pm_ops, cros_ec_uart_suspend, > > > > cros_ec_uart_resume); > > > > > > > > +static const struct of_device_id cros_ec_uart_of_match[] = { > > > > + { .compatible = "google,cros-ec-uart" }, > > > > + {} > > > > +}; > > > > +MODULE_DEVICE_TABLE(of, cros_ec_uart_of_match); > > > > > > It would need a guard for checking CONFIG_OF. Similar to what > > > `cros_ec_uart_acpi_id` does. > > > > > > > @@ -405,6 +412,7 @@ static struct serdev_device_driver cros_ec_uart_driver = { > > > > .driver = { > > > > .name = "cros-ec-uart", > > > > .acpi_match_table = ACPI_PTR(cros_ec_uart_acpi_id), > > > > + .of_match_table = cros_ec_uart_of_match, > > > > > > It would need be wrapped by `of_match_ptr()`. Similar to what > > > `ACPI_PTR()` does. > > > > I'm not sure we want a guard in this case because we compile the kernel without > > CONFIG_OF enabled for (most?) x86 platforms. Yet we still need the device > > tree code to enumerate using the PRP0001 _HID method. > > I'm not familiar to ACPI. However, I thought it should add the compatible > string in the _DSD instead of using of_match for the case. See example > in [1]. > > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id Correct, we need to add the compatible string inside the _DSD. This is what we currently do for all of our released devices: ``` Device (CRFP) { Name (_HID, "PRP0001") // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (_DDN, "Fingerprint Reader") // _DDN: DOS Device Name Name (_DSD, Package (0x02) // _DSD: Device-Specific Data { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */, Package (0x03) { Package (0x02) { "compatible", "google,cros-ec-uart" }, ... } } } ``` Since we define our `_HID` as `PRP0001` we need the `of_match_table` so the ACPI node can bind.
On Wed, Nov 30, 2022 at 09:52:29AM -0700, Raul Rangel wrote: > On Wed, Nov 30, 2022 at 12:10 AM Tzung-Bi Shih <tzungbi@kernel.org> wrote: > > > > On Tue, Nov 29, 2022 at 11:13:04AM -0700, Mark Hasemeyer wrote: > > > > > @@ -392,6 +393,12 @@ static int __maybe_unused cros_ec_uart_resume(struct device *dev) > > > > > static SIMPLE_DEV_PM_OPS(cros_ec_uart_pm_ops, cros_ec_uart_suspend, > > > > > cros_ec_uart_resume); > > > > > > > > > > +static const struct of_device_id cros_ec_uart_of_match[] = { > > > > > + { .compatible = "google,cros-ec-uart" }, > > > > > + {} > > > > > +}; > > > > > +MODULE_DEVICE_TABLE(of, cros_ec_uart_of_match); > > > > > > > > It would need a guard for checking CONFIG_OF. Similar to what > > > > `cros_ec_uart_acpi_id` does. > > > > > > > > > @@ -405,6 +412,7 @@ static struct serdev_device_driver cros_ec_uart_driver = { > > > > > .driver = { > > > > > .name = "cros-ec-uart", > > > > > .acpi_match_table = ACPI_PTR(cros_ec_uart_acpi_id), > > > > > + .of_match_table = cros_ec_uart_of_match, > > > > > > > > It would need be wrapped by `of_match_ptr()`. Similar to what > > > > `ACPI_PTR()` does. > > > > > > I'm not sure we want a guard in this case because we compile the kernel without > > > CONFIG_OF enabled for (most?) x86 platforms. Yet we still need the device > > > tree code to enumerate using the PRP0001 _HID method. > > > > > I'm not familiar to ACPI. However, I thought it should add the compatible > > string in the _DSD instead of using of_match for the case. See example > > in [1]. > > > > [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html#device-tree-namespace-link-device-id > > Correct, we need to add the compatible string inside the _DSD. This is > what we currently do for all of our released devices: > ``` > Device (CRFP) > { > Name (_HID, "PRP0001") // _HID: Hardware ID > Name (_UID, Zero) // _UID: Unique ID > Name (_DDN, "Fingerprint Reader") // _DDN: DOS Device Name > Name (_DSD, Package (0x02) // _DSD: Device-Specific Data > { > ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device > Properties for _DSD */, > Package (0x03) > { > Package (0x02) > { > "compatible", > "google,cros-ec-uart" > }, > ... > } > } > } > ``` > > Since we define our `_HID` as `PRP0001` we need the `of_match_table` > so the ACPI node can bind. I see. I also found some more examples: - 3c3969a0c99b ("iio:adc:ti-adc12138: Switch to generic firmware properties and drop of_match_ptr") - a70bbbe387d0 ("nfc: pn533: drop of_match_ptr from device ID table")
diff --git a/drivers/platform/chrome/cros_ec_uart.c b/drivers/platform/chrome/cros_ec_uart.c index b5f72f0104985..d44efb78bc881 100644 --- a/drivers/platform/chrome/cros_ec_uart.c +++ b/drivers/platform/chrome/cros_ec_uart.c @@ -11,6 +11,7 @@ #include <linux/kernel.h> #include <linux/module.h> #include <linux/acpi.h> +#include <linux/of.h> #include <linux/platform_data/cros_ec_commands.h> #include <linux/platform_data/cros_ec_proto.h> #include <linux/serdev.h> @@ -392,6 +393,12 @@ static int __maybe_unused cros_ec_uart_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(cros_ec_uart_pm_ops, cros_ec_uart_suspend, cros_ec_uart_resume); +static const struct of_device_id cros_ec_uart_of_match[] = { + { .compatible = "google,cros-ec-uart" }, + {} +}; +MODULE_DEVICE_TABLE(of, cros_ec_uart_of_match); + #ifdef CONFIG_ACPI static const struct acpi_device_id cros_ec_uart_acpi_id[] = { { "GOOG0019", 0 }, @@ -405,6 +412,7 @@ static struct serdev_device_driver cros_ec_uart_driver = { .driver = { .name = "cros-ec-uart", .acpi_match_table = ACPI_PTR(cros_ec_uart_acpi_id), + .of_match_table = cros_ec_uart_of_match, .pm = &cros_ec_uart_pm_ops, }, .probe = cros_ec_uart_probe,