Message ID | 20221110015034.7943-2-lihuisong@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp670240wru; Wed, 9 Nov 2022 17:55:11 -0800 (PST) X-Google-Smtp-Source: AMsMyM6wbOHCeM+d9d8ZqqeAwW69jHLGBG1N9y38A2h8B9jblWFVnSS/orEWkTRn3M8H7Muq1APX X-Received: by 2002:a17:907:1b1f:b0:72f:56db:cce9 with SMTP id mp31-20020a1709071b1f00b0072f56dbcce9mr56889765ejc.605.1668045311296; Wed, 09 Nov 2022 17:55:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668045311; cv=none; d=google.com; s=arc-20160816; b=uYKLkqMg0bwUEUI8xoadnHb54UDjrhflnHPkAu79LwoGJZGezEHvBmgx8sssiHyeo1 R4qxD2Vx5z1FFSBazyYvRJ2PqA8O3cbvKx5UoOtj/tIfb4luKu3lqWzWiRlI8+iFIXDz kv2lp8PA8/ZFG5IxvHgxuMP/RkB4KwKoc0WY6L6cV4OSmUiXqatey6wGKmZwvwFr2rsJ aV7gf7MAp79zU8FzxomqK10RweMwnDLyIMSyQEAsawSPpyZ1XBXq54GdGow0JGUbLfpJ qsi34D8Nv4gEfXuXJXbrIl7ymMHfrxLfky/ld5PYZ70P/bJ67HSj+0yuMTurI9149qAs j3Ag== 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; bh=tDE2QwQVAu+A8jsdIDenhVHvQZ14jKqmHFyR6TkCK38=; b=BLCbNGJS1RFFXaYcoXBv8XV8wucuZi1LMsVBP2iXrtR9hJH14DehZT9171TNmfNT8+ kKbNZUh1v40//uPceTBx7AIDQhlv6GU44S2d7oqEkSojAmg0yH5Rd/48mT2Z1a/SbJQZ QByO7l+6X+aobNsevwxMIEj3zuyPI7y0Whi8he5JGKQ0oHPpHqnr4O7Vp4U1jQ87YKTI 0t4nbGFgdu0N49E8pmw7QddqqPobcRaGN8rV9xJr2Zk4G9FPaBiwGm2z7IzqDQKvFB+R FRXptuaFAVeA9+l0sGG1K6e1/qPUyjy5LQBLH80xf1GibxMmeFu8fbW4imgN3OtsaGio ItkQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id du10-20020a17090772ca00b0078c6a12ff3dsi18372005ejc.215.2022.11.09.17.54.48; Wed, 09 Nov 2022 17:55:11 -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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232306AbiKJBw4 (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Wed, 9 Nov 2022 20:52:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231830AbiKJBwu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 9 Nov 2022 20:52:50 -0500 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35B4AB497; Wed, 9 Nov 2022 17:52:49 -0800 (PST) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4N74WQ34YlzpWKF; Thu, 10 Nov 2022 09:49:06 +0800 (CST) Received: from kwepemm600004.china.huawei.com (7.193.23.242) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 10 Nov 2022 09:52:47 +0800 Received: from localhost.localdomain (10.28.79.22) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 10 Nov 2022 09:52:46 +0800 From: Huisong Li <lihuisong@huawei.com> To: <linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org> CC: <rafael@kernel.org>, <sudeep.holla@arm.com>, <rafael.j.wysocki@intel.com>, <wanghuiqiang@huawei.com>, <zhangzekun11@huawei.com>, <wangxiongfeng2@huawei.com>, <tanxiaofei@huawei.com>, <guohanjun@huawei.com>, <xiexiuqi@huawei.com>, <wangkefeng.wang@huawei.com>, <huangdaode@huawei.com>, <lihuisong@huawei.com> Subject: [PATCH 1/3] mailbox: pcc: rename platform interrupt bit macro name Date: Thu, 10 Nov 2022 09:50:32 +0800 Message-ID: <20221110015034.7943-2-lihuisong@huawei.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20221110015034.7943-1-lihuisong@huawei.com> References: <20221110015034.7943-1-lihuisong@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.28.79.22] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, 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?1749072280261019973?= X-GMAIL-MSGID: =?utf-8?q?1749072280261019973?= |
Series |
ACPI: PCC: optimize pcc codes and fix one bug
|
|
Commit Message
Huisong Li
Nov. 10, 2022, 1:50 a.m. UTC
Currently, the name of platform interrupt bit macro, ACPI_PCCT_DOORBELL,
is not very appropriate. The doorbell is generally considered as an action
when send mailbox data. Actually, the macro value comes from Platform
Interrupt in Platform Communications Channel Global Flags. If the bit is
'1', it means that the platform is capable of generating an interrupt to
indicate completion of a command.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
drivers/mailbox/pcc.c | 2 +-
include/acpi/actbl2.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Comments
On Thu, Nov 10, 2022 at 09:50:32AM +0800, Huisong Li wrote: > Currently, the name of platform interrupt bit macro, ACPI_PCCT_DOORBELL, > is not very appropriate. The doorbell is generally considered as an action > when send mailbox data. Actually, the macro value comes from Platform > Interrupt in Platform Communications Channel Global Flags. If the bit is > '1', it means that the platform is capable of generating an interrupt to > indicate completion of a command. > This is touching ACPICA header file, so it must be submitted to ACPICA separately following the guidelines in the github and imported into the kernel. However, I don't see any point in this change. Yes the language "doorbell" is not used in this particular context in the spec, but it is implicit from other parts. I am not opposing the change though if Rafael is OK and ACPICA project accepts it.
在 2022/11/10 18:25, Sudeep Holla 写道: > On Thu, Nov 10, 2022 at 09:50:32AM +0800, Huisong Li wrote: >> Currently, the name of platform interrupt bit macro, ACPI_PCCT_DOORBELL, >> is not very appropriate. The doorbell is generally considered as an action >> when send mailbox data. Actually, the macro value comes from Platform >> Interrupt in Platform Communications Channel Global Flags. If the bit is >> '1', it means that the platform is capable of generating an interrupt to >> indicate completion of a command. >> > This is touching ACPICA header file, so it must be submitted to ACPICA > separately following the guidelines in the github and imported into the > kernel. Got it, thanks. > > However, I don't see any point in this change. Yes the language "doorbell" > is not used in this particular context in the spec, but it is implicit from > other parts. I am not opposing the change though if Rafael is OK and ACPICA > project accepts it. @Rafael, what do you think? >
On Thu, Nov 10, 2022 at 1:17 PM lihuisong (C) <lihuisong@huawei.com> wrote: > > > 在 2022/11/10 18:25, Sudeep Holla 写道: > > On Thu, Nov 10, 2022 at 09:50:32AM +0800, Huisong Li wrote: > >> Currently, the name of platform interrupt bit macro, ACPI_PCCT_DOORBELL, > >> is not very appropriate. The doorbell is generally considered as an action > >> when send mailbox data. Actually, the macro value comes from Platform > >> Interrupt in Platform Communications Channel Global Flags. If the bit is > >> '1', it means that the platform is capable of generating an interrupt to > >> indicate completion of a command. > >> > > This is touching ACPICA header file, so it must be submitted to ACPICA > > separately following the guidelines in the github and imported into the > > kernel. > Got it, thanks. > > > > However, I don't see any point in this change. Yes the language "doorbell" > > is not used in this particular context in the spec, but it is implicit from > > other parts. I am not opposing the change though if Rafael is OK and ACPICA > > project accepts it. > @Rafael, what do you think? Well, I wouldn't send a patch to make this change myself, but if you really care about it, please submit an upstream ACPICA pull request in the first place and we'll see.
在 2022/11/11 3:29, Rafael J. Wysocki 写道: > On Thu, Nov 10, 2022 at 1:17 PM lihuisong (C) <lihuisong@huawei.com> wrote: >> >> 在 2022/11/10 18:25, Sudeep Holla 写道: >>> On Thu, Nov 10, 2022 at 09:50:32AM +0800, Huisong Li wrote: >>>> Currently, the name of platform interrupt bit macro, ACPI_PCCT_DOORBELL, >>>> is not very appropriate. The doorbell is generally considered as an action >>>> when send mailbox data. Actually, the macro value comes from Platform >>>> Interrupt in Platform Communications Channel Global Flags. If the bit is >>>> '1', it means that the platform is capable of generating an interrupt to >>>> indicate completion of a command. >>>> >>> This is touching ACPICA header file, so it must be submitted to ACPICA >>> separately following the guidelines in the github and imported into the >>> kernel. >> Got it, thanks. >>> However, I don't see any point in this change. Yes the language "doorbell" >>> is not used in this particular context in the spec, but it is implicit from >>> other parts. I am not opposing the change though if Rafael is OK and ACPICA >>> project accepts it. >> @Rafael, what do you think? > Well, I wouldn't send a patch to make this change myself, but if you > really care about it, please submit an upstream ACPICA pull request in > the first place and we'll see. All right. Indeed, it doesn't matter. Ignore it. > .
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c index 3c2bc0ca454c..7cee37dd3b73 100644 --- a/drivers/mailbox/pcc.c +++ b/drivers/mailbox/pcc.c @@ -665,7 +665,7 @@ static int pcc_mbox_probe(struct platform_device *pdev) (unsigned long) pcct_tbl + sizeof(struct acpi_table_pcct)); acpi_pcct_tbl = (struct acpi_table_pcct *) pcct_tbl; - if (acpi_pcct_tbl->flags & ACPI_PCCT_DOORBELL) + if (acpi_pcct_tbl->flags & BIT(ACPI_PCCT_FLAGS_PLAT_INTERRUPT_B)) pcc_mbox_ctrl->txdone_irq = true; for (i = 0; i < count; i++) { diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index 655102bc6d14..3840507fdc79 100644 --- a/include/acpi/actbl2.h +++ b/include/acpi/actbl2.h @@ -1810,7 +1810,7 @@ struct acpi_table_pcct { /* Values for Flags field above */ -#define ACPI_PCCT_DOORBELL 1 +#define ACPI_PCCT_FLAGS_PLAT_INTERRUPT_B 1 /* Values for subtable type in struct acpi_subtable_header */