Message ID | 20231220165423.v2.17.I29b26a7f3b80fac0a618707446a10b6cc974fdaf@changeid |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-7670-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2483:b0:fb:cd0c:d3e with SMTP id q3csp85421dyi; Wed, 20 Dec 2023 16:00:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IGHL9b+L4IWWioC8KyKisaSCvzAbFsuQU6TDc/Xj0KDy3UpwJc3BF5dWisEqZZ7Z20DS3Yc X-Received: by 2002:a05:620a:4304:b0:77f:3cda:3eb6 with SMTP id u4-20020a05620a430400b0077f3cda3eb6mr5599994qko.34.1703116836320; Wed, 20 Dec 2023 16:00:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703116836; cv=none; d=google.com; s=arc-20160816; b=luu1ky1ezQ5zM5oOP603M2qCD9I0KDYkwVRUzNIpHARF+UMdD7gmZM0zSVrJm+tXMQ t8tnMqZK+dWuYVCVcUhwOaNpM7QfA1d95QkRgFAF8VaoycjuhUpzqyjrvla07152rq20 RKknGgxpha9eYsr5UZJP2uMTG1i1HpdvUfY4rYrPUBnA/7fRvGwr8BSQiqsFQrHsJqnF rHClVdpdg1uZVC+xV+aPh8UfR0kB1Wk64YgJ6/3kGvXdYAW+gkyE0zjqpjIA5HgFeME/ KMQEcDVT608alYRY92boEMpuf+6PK7GYR2XW/GOgvD2JarhQvDZf9w+So2mu52OzjkXk yLqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=ZKh5FX4xH2A55TvaLBm+1lswVT7mH5LMvN7VXVfLl8c=; fh=v2Ht5y747k1l/Ai2xsaBh2LNlmR666WlTsnQ09U8XlM=; b=vjzScedlacArR2/AV1hJfJ3wQhN386bwzoTFuy7N+HAjjlC/pXgK6K5xlPKfc48eoG 6Y+TzKzXFxBMTISL21pUeAfNdk80FY6Z9rtemc7OG1sCgKcGtRXHFubN5Yrfk4bn3I3q +3L771MyddkGeUt2S2HccKvmU0HSYa+/lVAsdtgv91Ue/6TZ9R4bWT/wpP3ozSjgMtYA 921iUnEtI5DrvupRefvbEjSQzFB1Yf5eOCtJkzLxrLwpM3a1Ds+ENc3UspsDJr5iWIaF ohogv3x37OZPbiOZwVr4LpaMj5HailTSU4qHrQoCroY0dRPix9SDJ/5wIvtxddQyahwn 9vTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ieMQxj5w; spf=pass (google.com: domain of linux-kernel+bounces-7670-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7670-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id sq18-20020a05620a4ad200b007811ecd0405si56584qkn.684.2023.12.20.16.00.36 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 16:00:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-7670-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ieMQxj5w; spf=pass (google.com: domain of linux-kernel+bounces-7670-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7670-ouuuleilei=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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 2017F1C22B9D for <ouuuleilei@gmail.com>; Thu, 21 Dec 2023 00:00:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 66D4B4F209; Wed, 20 Dec 2023 23:55:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="ieMQxj5w" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (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 7C94C4F5FA for <linux-kernel@vger.kernel.org>; Wed, 20 Dec 2023 23:55:24 +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-il1-f177.google.com with SMTP id e9e14a558f8ab-35fc6eb9075so619165ab.1 for <linux-kernel@vger.kernel.org>; Wed, 20 Dec 2023 15:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1703116523; x=1703721323; darn=vger.kernel.org; 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=ZKh5FX4xH2A55TvaLBm+1lswVT7mH5LMvN7VXVfLl8c=; b=ieMQxj5wfYGB1TiYeOYZCbjVxOt4Rz94IXWdMs4OMMQukhyWpk8iRfK8F32s6INq3n nP40GVvM2bHStM/qkxPwfs8LybFBxzjdxyP+k6qvzJhCaY3nSyE9tjr2weZMiifFyjrC QltXU3YE+xn5zUxK+U3RA6KCXBGJ2/y4ge17c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703116523; x=1703721323; 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=ZKh5FX4xH2A55TvaLBm+1lswVT7mH5LMvN7VXVfLl8c=; b=gNiCMIoyrWOv3BxpnxrCw5xBHUlyi/5hhjBjVsERQLh8DMTnkuvgNWlUim6eg6jDK2 eVK8w+UVZ9XJjMg6yelzW7cHJwjcy/t0nTbefsOQR3/aTz9Ylayk9f5YunSA+fnOLOrA 3+6ZnY36Ve6+ZEum91TFBFotzDsXtHL2xqc81XZCcWbZez8c9S0An0SeI+pWu9uLR7pE BRnVfYKKWCfH2rEZjDq0zwIm4z93NDFblYQ8Xw2pWCwAN7mYmM9cOgu7Tt9LXTC0iz2T O8WaX+K+uMqS0ThsnWxUm1XEt10mScZtf4Gw4XWsN+paiBOQwSfdFjI0trMFhNE+NXQI JgLw== X-Gm-Message-State: AOJu0YxXcVg/l900N2OpKgXYvUtk/gVWuPMzEuCY4pgG893bp86Mrah7 gWO5VKD42sxL0PlUdzsEfha0EiEJLiA6B/NaDBWIDxNjfQ== X-Received: by 2002:a05:6e02:1bc4:b0:35d:4463:5dd2 with SMTP id x4-20020a056e021bc400b0035d44635dd2mr2680020ilv.16.1703116523652; Wed, 20 Dec 2023 15:55:23 -0800 (PST) Received: from markhas1.lan (71-218-50-136.hlrn.qwest.net. [71.218.50.136]) by smtp.gmail.com with ESMTPSA id bp22-20020a056638441600b0046b39a6f404sm177805jab.17.2023.12.20.15.55.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 15:55:23 -0800 (PST) From: Mark Hasemeyer <markhas@chromium.org> To: LKML <linux-kernel@vger.kernel.org> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Tzung-Bi Shih <tzungbi@kernel.org>, Raul Rangel <rrangel@chromium.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Andy Shevchenko <andriy.shevchenko@intel.com>, Rob Herring <robh@kernel.org>, Sudeep Holla <sudeep.holla@arm.com>, Mark Hasemeyer <markhas@chromium.org>, Frank Rowand <frowand.list@gmail.com>, Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org Subject: [PATCH v2 17/22] of: irq: add wake capable bit to of_irq_resource() Date: Wed, 20 Dec 2023 16:54:31 -0700 Message-ID: <20231220165423.v2.17.I29b26a7f3b80fac0a618707446a10b6cc974fdaf@changeid> X-Mailer: git-send-email 2.43.0.472.g3155946c3a-goog In-Reply-To: <20231220235459.2965548-1-markhas@chromium.org> References: <20231220235459.2965548-1-markhas@chromium.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785847439420938070 X-GMAIL-MSGID: 1785847439420938070 |
Series |
Improve IRQ wake capability reporting and update the cros_ec driver to use it
|
|
Commit Message
Mark Hasemeyer
Dec. 20, 2023, 11:54 p.m. UTC
Add wake capability information to the IRQ resource. Wake capability is
assumed based on conventions provided in the devicetree wakeup-source
binding documentation. An interrupt is considered wake capable if the
following are true:
1. A wakeup-source property exits in the same device node as the
interrupt.
2. The IRQ is marked as dedicated by setting its interrupt-name to
"wakeup".
The wakeup-source documentation states that dedicated interrupts can use
device specific interrupt names and device drivers are still welcome to
use their own naming schemes. This API is provided as a helper if one is
willing to conform to the above conventions.
The ACPI subsystems already provides similar APIs that allow one to
query the wake capability of an IRQ. This brings closer feature parity
to the devicetree.
Signed-off-by: Mark Hasemeyer <markhas@chromium.org>
---
Changes in v2:
-Update logic to return true only if wakeup-source property and
"wakeup" interrupt-name are defined
-irq->IRQ, api->API
drivers/of/irq.c | 32 +++++++++++++++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
Comments
On Wed, Dec 20, 2023 at 04:54:31PM -0700, Mark Hasemeyer wrote: > Add wake capability information to the IRQ resource. Wake capability is > assumed based on conventions provided in the devicetree wakeup-source > binding documentation. An interrupt is considered wake capable if the > following are true: > 1. A wakeup-source property exits in the same device node as the > interrupt. > 2. The IRQ is marked as dedicated by setting its interrupt-name to > "wakeup". > > The wakeup-source documentation states that dedicated interrupts can use > device specific interrupt names and device drivers are still welcome to > use their own naming schemes. This API is provided as a helper if one is > willing to conform to the above conventions. > > The ACPI subsystems already provides similar APIs that allow one to > query the wake capability of an IRQ. This brings closer feature parity > to the devicetree. ... > r->start = r->end = irq; > r->flags = IORESOURCE_IRQ | irqd_get_trigger_type(irq_get_irq_data(irq)); > + if (__of_irq_wake_capable(dev, index)) > + r->flags |= IORESOURCE_IRQ_WAKECAPABLE; > r->name = name ? name : of_node_full_name(dev); irq_flags = irqd_get_trigger_type(irq_get_irq_data(irq)); if (__of_irq_wake_capable(dev, index)) irq_flags |= IORESOURCE_IRQ_WAKECAPABLE; *r = DEFINE_RES_NAMED(irq, 1, name ?: of_node_full_name(dev), irq_flags); ? ... Or even refactor ioport.h (in a separate patch) as we seems already have two users (and might be more in the existing code): #define DEFINE_RES_IRQ_NAMED_FLAGS(_irq, _name, _flags) \ DEFINE_RES_NAMED((_irq), 1, (_name), (_flags) | IORESOURCE_IRQ) #define DEFINE_RES_IRQ_NAMED(_irq, _name) \ DEFINE_RES_IRQ_NAMED_FLAGS((_irq), (_name), 0) #define DEFINE_RES_IRQ(_irq) \ DEFINE_RES_IRQ_NAMED((_irq), NULL) (Note, I will Ack such a patch once it appears.)
On Wed, 20 Dec 2023 16:54:31 -0700, Mark Hasemeyer wrote: > Add wake capability information to the IRQ resource. Wake capability is > assumed based on conventions provided in the devicetree wakeup-source > binding documentation. An interrupt is considered wake capable if the > following are true: > 1. A wakeup-source property exits in the same device node as the > interrupt. > 2. The IRQ is marked as dedicated by setting its interrupt-name to > "wakeup". > > The wakeup-source documentation states that dedicated interrupts can use > device specific interrupt names and device drivers are still welcome to > use their own naming schemes. This API is provided as a helper if one is > willing to conform to the above conventions. > > The ACPI subsystems already provides similar APIs that allow one to > query the wake capability of an IRQ. This brings closer feature parity > to the devicetree. > > Signed-off-by: Mark Hasemeyer <markhas@chromium.org> > --- > > Changes in v2: > -Update logic to return true only if wakeup-source property and > "wakeup" interrupt-name are defined > -irq->IRQ, api->API > > drivers/of/irq.c | 32 +++++++++++++++++++++++++++++++- > 1 file changed, 31 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring <robh@kernel.org>
> Or even refactor ioport.h (in a separate patch) as we seems already have > two users (and might be more in the existing code): > > #define DEFINE_RES_IRQ_NAMED_FLAGS(_irq, _name, _flags) \ > DEFINE_RES_NAMED((_irq), 1, (_name), (_flags) | IORESOURCE_IRQ) > #define DEFINE_RES_IRQ_NAMED(_irq, _name) \ > DEFINE_RES_IRQ_NAMED_FLAGS((_irq), (_name), 0) > #define DEFINE_RES_IRQ(_irq) \ > DEFINE_RES_IRQ_NAMED((_irq), NULL) > > (Note, I will Ack such a patch once it appears.) I'll add a new patch to the series. I'll probably include the MEM, IO, and RES variants as well.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 174900072c18c..7583adf386220 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -383,11 +383,39 @@ int of_irq_parse_one(struct device_node *device, int index, struct of_phandle_ar } EXPORT_SYMBOL_GPL(of_irq_parse_one); +/** + * __of_irq_wake_capable - Determine whether a given IRQ index is wake capable + * + * The IRQ is considered wake capable if the following are true: + * 1. wakeup-source property exists + * 2. provided IRQ index is labelled as a dedicated wakeirq + * + * This logic assumes the provided IRQ index is valid. + * + * @dev: pointer to device tree node + * @index: zero-based index of the IRQ + * Return: True if provided IRQ index for #dev is wake capable. False otherwise. + */ +static bool __of_irq_wake_capable(const struct device_node *dev, int index) +{ + int wakeindex; + + if (!of_property_read_bool(dev, "wakeup-source")) + return false; + + wakeindex = of_property_match_string(dev, "interrupt-names", "wakeup"); + return wakeindex >= 0 && wakeindex == index; +} + /** * of_irq_to_resource - Decode a node's IRQ and return it as a resource * @dev: pointer to device tree node - * @index: zero-based index of the irq + * @index: zero-based index of the IRQ * @r: pointer to resource structure to return result into. + * + * Return: Linux IRQ number on success, or 0 on the IRQ mapping failure, or + * -EPROBE_DEFER if the IRQ domain is not yet created, or error code in case + * of any other failure. */ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r) { @@ -411,6 +439,8 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r) r->start = r->end = irq; r->flags = IORESOURCE_IRQ | irqd_get_trigger_type(irq_get_irq_data(irq)); + if (__of_irq_wake_capable(dev, index)) + r->flags |= IORESOURCE_IRQ_WAKECAPABLE; r->name = name ? name : of_node_full_name(dev); }