Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp6858522rdb; Tue, 2 Jan 2024 16:46:34 -0800 (PST) X-Google-Smtp-Source: AGHT+IGhb1yCV0lRI6zLDgk8kPcXkv5DeFmCMJ4/owS5TSIVjnDOwE2+ddjVg5BeQdEGHfak6VoR X-Received: by 2002:a05:6e02:b22:b0:35f:ef56:35a with SMTP id e2-20020a056e020b2200b0035fef56035amr28028239ilu.48.1704242794378; Tue, 02 Jan 2024 16:46:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704242794; cv=none; d=google.com; s=arc-20160816; b=CSbi4lDJNTBBiN9DulGB0B7woo7YhdCDvIJHzIxdyMELbSjWC7VZGICx7VqgR2h7I/ C1EXQYEUgiOk4IyE00jY6sQmUb6xnJE3mqe4PDr89XUzMtSpItf9ry3dZUEx4HHdFqoW 9No6X1U6aOybIiO5BNU0l4RQwSd2Ciyz0BKuAl6GYaWAxcbBLh/jt3sY4hnfPnwbZg3R 6DnT0YRrXtDnjgfJXWc0KEizNbD4Apu4cCSjBy/cybE/FK78Mdnx5qWqSoF/1XZqp2aM 3oi1m0/UJHDtEyPIih1ZkxcwnpPAHhp8ip7SRup5Ik+ggdfevX6XoAJbUCqJqMRm6swS qw3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:user-agent:from:references :in-reply-to:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:dkim-signature; bh=1hNU8BfIre3e1QukJAFr9ZllMWSafWp32nf2QM+XZVU=; fh=rgDCJIJxZZXxbuVfHZ+PpqMddMMlAg5hAgWV3gkbWl8=; b=bcb49fyMA+sNdQsVJnNKoRbXEpYq6PW3vJ7IO6oRKqumjL6qwSDh1MTShw3f/Jvveh r1QlHXtnVbzoIM8XacA4kjcDIDHIH+HFh2FcyV93NxUSmsyPogLyd5g+R6fGhtZ3Vim8 ijPWWeUS8Eoc33B0trTpwplmEVy99mkiyrl0svv/lcqfW5KdTyaIEtJmBZ5VvDzHGAk6 b1xP3z6aKI1y63XcZqAXpmG+MvAq5HlzgnQGLdHVZEbV8Z/NXRMkzK7wpb6qTd1p5eEv 6F217e0wHsSVqSm/baJmJUJXofW5BaEcn5VezANez3EjPVFCSiAXhIV1XcdeIOv/z72p Xx7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=SjpJ7XU4; spf=pass (google.com: domain of linux-kernel+bounces-15007-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15007-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id x6-20020a17090a1f8600b0028c99bc7638si303842pja.74.2024.01.02.16.46.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 16:46:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-15007-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=SjpJ7XU4; spf=pass (google.com: domain of linux-kernel+bounces-15007-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15007-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 213AAB225CD for ; Wed, 3 Jan 2024 00:46:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8445B1108; Wed, 3 Jan 2024 00:46:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="SjpJ7XU4" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE02FEBD for ; Wed, 3 Jan 2024 00:46:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-50e7dff3e9fso7112992e87.2 for ; Tue, 02 Jan 2024 16:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1704242776; x=1704847576; darn=vger.kernel.org; h=cc:to:subject:message-id:date:user-agent:from:references :in-reply-to:mime-version:from:to:cc:subject:date:message-id :reply-to; bh=1hNU8BfIre3e1QukJAFr9ZllMWSafWp32nf2QM+XZVU=; b=SjpJ7XU4N+Vs0jrYCa8lFRMBwEPFoDFM8mr3bNoOos3Maxm/EYhvPd8HxRHQxdNO6F r7TEZEKAphkT9ApmipdeehTu+kMqEcqu9WaEKpCQbYaR/VaO3q4bHseCkAcoo2F1L7fw sM8sH/bI9hRzfKfQ6WQn4pvbLJuCbBtM3jhlE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704242776; x=1704847576; h=cc:to:subject:message-id:date:user-agent:from:references :in-reply-to:mime-version:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1hNU8BfIre3e1QukJAFr9ZllMWSafWp32nf2QM+XZVU=; b=IbGXnmBVFx3Eq7RFejc+zjqLPt3LvJFPRH+pVahLChhL26ucFvV91sHzOABakbk9+v l5tqgOflaJr8bDVuE/XO+habwmFrq/2sUKY6cfON0sNYhTVDr11m4bgBFU6DAiAOhHVf 9FskQMOC9D7x7ySPEpTtcng4DIk7MLg5qYIdRoFEIKaezEQFiOC8RphCHpTP8MCAlWVr 7GAMgr6jFYLNRRTV404Ww4g8x1Bzi3LHI1WCGlRwCf2YlV1a7JjdjFzs2eo0lPMTWE3B EETFJrz8jLz9sIyj7kKV/Srk9I93tOutoBfyLtXCwkKR3eGWYvWLXStJtb6puZSwqeM+ DszQ== X-Gm-Message-State: AOJu0YxZhw+DqHcAucfSn/1qP55/pqRUfLJL5VcdAFFEQ5oQGen/Buxg Av1O4gWHUbCku8o/+NzzYl20PHhG+6G47Pag+ToDkNLKc5bkPPXA0zpxHXM= X-Received: by 2002:a19:f80d:0:b0:50e:9ff8:d590 with SMTP id a13-20020a19f80d000000b0050e9ff8d590mr757326lff.50.1704242776465; Tue, 02 Jan 2024 16:46:16 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 2 Jan 2024 16:46:15 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20240102140734.v4.24.Ieee574a0e94fbaae01fd6883ffe2ceeb98d7df28@changeid> References: <20240102210820.2604667-1-markhas@chromium.org> <20240102140734.v4.24.Ieee574a0e94fbaae01fd6883ffe2ceeb98d7df28@changeid> From: Stephen Boyd User-Agent: alot/0.10 Date: Tue, 2 Jan 2024 16:46:15 -0800 Message-ID: Subject: Re: [PATCH v4 24/24] platform/chrome: cros_ec: Use PM subsystem to manage wakeirq To: LKML , Mark Hasemeyer Cc: Sudeep Holla , AngeloGioacchino Del Regno , Rob Herring , Andy Shevchenko , Krzysztof Kozlowski , Konrad Dybcio , Raul Rangel , Tzung-Bi Shih , Benson Leung , Bhanu Prakash Maiya , Chen-Yu Tsai , Guenter Roeck , Prashant Malani , Rob Barnes , chrome-platform@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Quoting Mark Hasemeyer (2024-01-02 13:07:48) > The cros ec driver is manually managing the wake IRQ by calling > enable_irq_wake()/disable_irq_wake() during suspend/resume. > > Modify the driver to use the power management subsystem to manage the > wakeirq. > > Rather than assuming that the IRQ is wake capable, use the underlying > firmware/device tree to determine whether or not to enable it as a wake > source. Some Chromebooks rely solely on the ec_sync pin to wake the AP > but do not specify the interrupt as wake capable in the ACPI _CRS. For > LPC/ACPI based systems a DMI quirk is introduced listing boards whose > firmware should not be trusted to provide correct wake capable values. The DMI quirk looks to be fixing something. Most likely that should be backported to stable kernels as well? Please split the DMI match table part out of this so that it isn't mixed together with migrating the driver to use the pm wakeirq logic. > For device tree base systems, it is not an issue as the relevant device > tree entries have been updated and DTS is built from source for each > ChromeOS update. It is still sorta an issue. It means that we can't backport this patch without also backporting the DTS patch to the kernel. Furthermore, DTS changes go through different maintainer trees, so having this patch in the kernel without the DTS patch means the bisection hole is possibly quite large. Does using the pm wakeirq logic require the use of 'wakeup-source' property in DT? A quick glance makes me believe it isn't needed, so please split that part out of this patch as well. We should see a patch for the DMI quirk, a patch to use wakeup-source (doubtful that we need it at all though), and a patch to use the pm wakeirq logic instead of hand rolling it again. > > Acked-by: Tzung-Bi Shih > Signed-off-by: Mark Hasemeyer > --- [...] > diff --git a/drivers/platform/chrome/cros_ec.c b/drivers/platform/chrome/cros_ec.c > index badc68bbae8cc..080b479f39a94 100644 > --- a/drivers/platform/chrome/cros_ec.c > +++ b/drivers/platform/chrome/cros_ec.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -168,6 +169,35 @@ static int cros_ec_ready_event(struct notifier_block *nb, > return NOTIFY_DONE; > } > > +static int enable_irq_for_wake(struct cros_ec_device *ec_dev) > +{ > + struct device *dev = ec_dev->dev; > + int ret = device_init_wakeup(dev, true); > + > + if (ret) { > + dev_err(dev, "Failed to enable device for wakeup"); Missing newline on printk message. > + return ret; > + } > + ret = dev_pm_set_wake_irq(dev, ec_dev->irq); > + if (ret) > + device_init_wakeup(dev, false); > + > + return ret; I'd rather see the code formatted like this: int ret; ret = device_init_wakeup(dev, true); if (ret) { dev_err(...); return ret; } ret = dev_pm_set_wake_irq(...); if (ret) device_init_wakeup(dev, false); return ret; Mostly because the first 'if (ret)' requires me to hunt in the variable declaration part of the function to figure out what it is set to instead of looking at the line directly above. > +} > + > +static int disable_irq_for_wake(struct cros_ec_device *ec_dev) > +{ > + int ret; > + struct device *dev = ec_dev->dev; > + > + dev_pm_clear_wake_irq(dev); > + ret = device_init_wakeup(dev, false); > + if (ret) > + dev_err(dev, "Failed to disable device for wakeup"); > + > + return ret; > +} > + > /** > * cros_ec_register() - Register a new ChromeOS EC, using the provided info. > * @ec_dev: Device to register. > @@ -221,6 +251,13 @@ int cros_ec_register(struct cros_ec_device *ec_dev) > ec_dev->irq, err); > goto exit; > } > + dev_dbg(dev, "IRQ: %i, wake_capable: %s\n", ec_dev->irq, This one has a newline :) > + str_yes_no(ec_dev->irq_wake)); > + if (ec_dev->irq_wake) { > + err = enable_irq_for_wake(ec_dev); > + if (err) > + goto exit; > + } > } [...] > diff --git a/drivers/platform/chrome/cros_ec_spi.c b/drivers/platform/chrome/cros_ec_spi.c > index 3e88cc92e8192..102cdc3d1956d 100644 > --- a/drivers/platform/chrome/cros_ec_spi.c > +++ b/drivers/platform/chrome/cros_ec_spi.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -70,6 +71,7 @@ > * @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that > * is sent when we want to turn off CS at the end of a transaction. > * @high_pri_worker: Used to schedule high priority work. > + * @irq_wake: Whether or not irq assertion should wake the system. > */ > struct cros_ec_spi { > struct spi_device *spi; > @@ -77,6 +79,7 @@ struct cros_ec_spi { > unsigned int start_of_msg_delay; > unsigned int end_of_msg_delay; > struct kthread_worker *high_pri_worker; > + bool irq_wake; This is only used in probe. Make it a local variable instead of another struct member to save memory. > }; > > typedef int (*cros_ec_xfer_fn_t) (struct cros_ec_device *ec_dev, > @@ -689,9 +692,10 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev, > return cros_ec_xfer_high_pri(ec_dev, ec_msg, do_cros_ec_cmd_xfer_spi); > } > > -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 device_node *np = dev->of_node; > + struct spi_device *spi = ec_spi->spi; > + struct device_node *np = spi->dev.of_node; > u32 val; > int ret; > > @@ -702,6 +706,8 @@ 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; > + > + ec_spi->irq_wake = spi->irq > 0 && of_property_present(np, "wakeup-source"); Is there any EC SPI device that doesn't want to support wakeup? I'd prefer we introduce a new property or compatible string to indicate that wakeup isn't supported and otherwise always set irq_wake to true. That way DT can change in parallel with the driver instead of in lockstep.