Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp11277rdb; Thu, 21 Dec 2023 00:58:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IHoYLzwZUHOKahlJDCx9Ie7E9U8KrIuNUGHtqr2qmN+P1OyJYvESbYLnu2ILOihhodHLFiF X-Received: by 2002:a19:914b:0:b0:50e:61bc:66c4 with SMTP id y11-20020a19914b000000b0050e61bc66c4mr176937lfj.121.1703149104703; Thu, 21 Dec 2023 00:58:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703149104; cv=none; d=google.com; s=arc-20160816; b=wuvF1JcDxSGqRTL8lI8qNsc2aDH8piVenwurVP5kuU41HnAF3nofztHFRDbTVvNe7T ICxnWASw/hlG4wudr706xD7ufIhggqOuUM3SS/hYsPVmKvJpsO8at5C4ITA1d6G7OfDj PxW5vCUAWRbP3y9pIuv743FLsJtMgrGvWJbrd9eS24Q8uBgDsdWLubjsdIXIuYtIdWae BkNlGOJ39fA6YlHHJnk8JQUZne7s3zcdzgGdjS0ImpKTDCt1dfrNvzPj2D/r/i110HeX +azwfb/v0XUuChIVfELDF3K/aeDfdkUYRvn4yLFV3za5skO9d5I216gRIuhcALYcQOBQ ylGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=LQWVXb2aKyRJ8PtFnJTDXTs1qDoSKCWoGQ5qr3w2TKk=; fh=TykIQcb3B/9hugvV7JlcSpSQMtJjrCQQeprIQNfkkjo=; b=0CdOLiMRXWBecIL4eSui5yMpS6g6C/sQRoGuBB+JfCOzxqQuDfDB0ruhjGCK4kPVAE dVsiUcH53+KOqowq4TMCNS+HuulHLmAFq0CSzlMxbWMwpYFhup5A8/hg9/A4n+h5MzZ6 xVpEkwso5o2g+TYl1v7JEbGb5gBC+IPaPG7e6ApA+vg3nFXvFoyTBm00UsZ2tuLdiIiN jBQkRTO2Cixp5OiLHk0Hp8wPZIIu1N008v3Pvpp2Uhc8EpkaFJq82mX23qqqgizwhXrY VGBSlIotX7/iTOv0R1Zmi00FjCsT4r22IGBJzbh1mfa/jMGX6dHJ6T8DoVqRwsL8PXln AM/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hb0pT7TY; spf=pass (google.com: domain of linux-kernel+bounces-8031-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-8031-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id o26-20020a509b1a000000b0054c7fcb8334si672521edi.274.2023.12.21.00.58.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Dec 2023 00:58:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-8031-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hb0pT7TY; spf=pass (google.com: domain of linux-kernel+bounces-8031-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-8031-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 4873B1F21E19 for ; Thu, 21 Dec 2023 08:58:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A38CD210F6; Thu, 21 Dec 2023 08:58:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hb0pT7TY" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB65C208DE; Thu, 21 Dec 2023 08:58:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98173C433C8; Thu, 21 Dec 2023 08:58:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703149092; bh=gLq6owYsi5+HzSEWjDiTXSIZh7zeqkTrjBurAO/BXVM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hb0pT7TYb6E2npKuG1J8kJlRD8022tec43nOjCXNzAfTKOW4HSo6vhCKgic7S/MS7 zT0KXYfeJvUFWhw32SigZV/GPh/px0g2h5y0r4MnE5NMyoh5Htf8dLbgJB/NWV9jXw nxlK381fmNuArHKuK9bzObZMLaP9u2HbVu1TGRzMyrUJuMio7kf79aVMH5VhkX0aGR xNPobhJ0Z83rEd2MWsC8SNMBSjtadWPOMB2NKBGbSi3pMbag1zH3JZcD+QKh5Ind3H wQXx0OEXTp4/jAyE2xSCIZcZ8D6ZzHt5nxqMMer7sE0mcCWizpFQsGzVoZ23YMCo7C vfYYISIamm6kg== Date: Thu, 21 Dec 2023 16:58:07 +0800 From: Tzung-Bi Shih To: Mark Hasemeyer Cc: LKML , AngeloGioacchino Del Regno , Krzysztof Kozlowski , Raul Rangel , Konrad Dybcio , Andy Shevchenko , Rob Herring , Sudeep Holla , Benson Leung , Bhanu Prakash Maiya , Chen-Yu Tsai , Guenter Roeck , Lee Jones , Prashant Malani , Rob Barnes , Stephen Boyd , chrome-platform@lists.linux.dev Subject: Re: [PATCH v2 22/22] platform/chrome: cros_ec: Use PM subsystem to manage wakeirq Message-ID: References: <20231220235459.2965548-1-markhas@chromium.org> <20231220165423.v2.22.Ieee574a0e94fbaae01fd6883ffe2ceeb98d7df28@changeid> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231220165423.v2.22.Ieee574a0e94fbaae01fd6883ffe2ceeb98d7df28@changeid> On Wed, Dec 20, 2023 at 04:54:36PM -0700, Mark Hasemeyer wrote: > The IRQ wake logic was added on an interface basis (lpc, spi, uart) as > opposed to adding it to cros_ec.c because the i2c subsystem already > enables the wakirq (if applicable) on our behalf. The setting flow are all the same. I think helper functions in cros_ec.c help to deduplicate the code. > diff --git a/drivers/platform/chrome/cros_ec_lpc.c b/drivers/platform/chrome/cros_ec_lpc.c [...] > +static const struct dmi_system_id untrusted_fw_irq_wake_capable[] = { > + { > + .ident = "Brya", > + .matches = { > + DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Brya") > + } > + }, > + { > + .ident = "Brask", > + .matches = { > + DMI_MATCH(DMI_PRODUCT_FAMILY, "Google_Brask") > + } > + }, > + { } > +} > +MODULE_DEVICE_TABLE(dmi, untrusted_fw_irq_wake_capable); Does it really need `MODULE_DEVICE_TABLE`? > +static bool cros_ec_should_force_irq_wake_capable(void) Suggestion: either drop "cros_ec_" prefix or use "cros_ec_lpc_" prefix. > @@ -428,20 +453,36 @@ static int cros_ec_lpc_probe(struct platform_device *pdev) > * Some boards do not have an IRQ allotted for cros_ec_lpc, > * which makes ENXIO an expected (and safe) scenario. > */ > - irq = platform_get_irq_optional(pdev, 0); > - if (irq > 0) > + irq = platform_get_irq_resource_optional(pdev, 0, &irqres); > + if (irq > 0) { > ec_dev->irq = irq; > - else if (irq != -ENXIO) { > + if (cros_ec_should_force_irq_wake_capable()) Please see suggestion above. > ret = cros_ec_register(ec_dev); > if (ret) { > - dev_err(dev, "couldn't register ec_dev (%d)\n", ret); > + dev_err_probe(dev, ret, "couldn't register ec_dev (%d)\n", ret); The change is irrelevant to the series. > + if (irq_wake) { > + ret = device_init_wakeup(dev, true); > + if (ret) { > + dev_err_probe(dev, ret, "Failed to init device for wakeup"); > + return ret; > + } > + ret = dev_pm_set_wake_irq(dev, irq); > + if (ret) > + return ret; > + } [...] > @@ -470,6 +512,8 @@ static void cros_ec_lpc_remove(struct platform_device *pdev) > acpi_remove_notify_handler(adev->handle, ACPI_ALL_NOTIFY, > cros_ec_lpc_acpi_notify); > > + dev_pm_clear_wake_irq(dev); > + device_init_wakeup(dev, false); Is it safe to call them anyway regardless of `irq_wake` in cros_ec_lpc_probe()? > diff --git a/drivers/platform/chrome/cros_ec_spi.c b/drivers/platform/chrome/cros_ec_spi.c [...] > -static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device *dev) > +static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct spi_device *spi) > { > - struct device_node *np = dev->of_node; > + struct cros_ec_device *ec_dev = spi_get_drvdata(spi); > + struct device_node *np = spi->dev.of_node; struct spi_device *spi = ec_spi->spi; [1] [1]: https://elixir.bootlin.com/linux/v6.6/source/drivers/platform/chrome/cros_ec_spi.c#L751 > + if (!np) > + return; > + The change is an improvement (or rather say it could change behavior). But strictly speaking, the change is irrelevant to the series. > @@ -702,6 +710,11 @@ static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device *dev) > ret = of_property_read_u32(np, "google,cros-ec-spi-msg-delay", &val); > if (!ret) > ec_spi->end_of_msg_delay = val; > + > + if (ec_dev->irq > 0 && of_property_read_bool(np, "wakeup-source")) { Or just use `spi->irq`[2]. [2]: https://elixir.bootlin.com/linux/v6.6/source/drivers/platform/chrome/cros_ec_spi.c#L762 They are the same, but does of_property_present() make more sense? > @@ -768,6 +778,9 @@ static int cros_ec_spi_probe(struct spi_device *spi) > sizeof(struct ec_response_get_protocol_info); > ec_dev->dout_size = sizeof(struct ec_host_request); > > + /* Check for any DT properties */ > + cros_ec_spi_dt_probe(ec_spi, spi); `spi` is possibly not needed. See comment above. > @@ -776,19 +789,31 @@ static int cros_ec_spi_probe(struct spi_device *spi) > > err = cros_ec_register(ec_dev); > if (err) { > - dev_err(dev, "cannot register EC\n"); > + dev_err_probe(dev, err, "cannot register EC\n"); The change is irrelevant to the series. > - device_init_wakeup(&spi->dev, true); > + if (ec_spi->irq_wake) { > + err = device_init_wakeup(dev, true); > + if (err) { > + dev_err_probe(dev, err, "Failed to init device for wakeup\n"); > + return err; > + } > + err = dev_pm_set_wake_irq(dev, ec_dev->irq); > + if (err) > + dev_err_probe(dev, err, "Failed to set irq(%d) for wake\n", ec_dev->irq); The part is different from what the patch changed in cros_ec_lpc.c. Better to be consistent. - Just return vs. dev_err_probe(). - %i vs. %d. > static void cros_ec_spi_remove(struct spi_device *spi) > { > struct cros_ec_device *ec_dev = spi_get_drvdata(spi); > + struct device *dev = ec_dev->dev; > > + dev_pm_clear_wake_irq(dev); > + device_init_wakeup(dev, false); Ditto, is it safe to just call them regardless of `ec_spi->irq_wake`? > diff --git a/drivers/platform/chrome/cros_ec_uart.c b/drivers/platform/chrome/cros_ec_uart.c [...] > @@ -301,13 +307,31 @@ static int cros_ec_uart_probe(struct serdev_device *serdev) > > serdev_device_set_client_ops(serdev, &cros_ec_uart_client_ops); > > - return cros_ec_register(ec_dev); > + /* Register a new cros_ec device */ > + ret = cros_ec_register(ec_dev); > + if (ret) { > + dev_err(dev, "Couldn't register ec_dev (%d)\n", ret); From reading the changes above, I thought it would use dev_err_probe(). > + if (ec_uart->irq_wake) { > + ret = device_init_wakeup(dev, true); > + if (ret) { > + dev_err_probe(dev, ret, "Failed to init device for wakeup"); > + return ret; > + } > + ret = dev_pm_set_wake_irq(dev, ec_uart->irq); Ditto, better to be consistent. > static void cros_ec_uart_remove(struct serdev_device *serdev) > { > struct cros_ec_device *ec_dev = serdev_device_get_drvdata(serdev); > + struct device *dev = ec_dev->dev; > > + dev_pm_clear_wake_irq(dev); > + device_init_wakeup(dev, false); Ditto, is it safe to just call them regardless of `ec_uart->irq_wake`?