Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp2726624rdh; Sun, 26 Nov 2023 17:34:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IEtRlfFyLWF6qvUnW621u/nWfhwvmkrPkdmT6FjugEz0oU92T9s5sOSYfgiUIPXUQOjF+9t X-Received: by 2002:a05:6a00:c94:b0:6cc:b448:3654 with SMTP id a20-20020a056a000c9400b006ccb4483654mr4607654pfv.18.1701048857979; Sun, 26 Nov 2023 17:34:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701048857; cv=none; d=google.com; s=arc-20160816; b=x4VGyvhxBDKC9yEiI3XiVcp5AWwCV0xFc5m5AFC/qoHXSKt3hr55MLv5HGQMEJmADJ RlS2KAd5oJkRnJ9PxEK0kR48F5dJSShDzuEVtgK50Hc2XCFJ9PXGxrVPk1fVuwt+gBIZ RyX7tmdxyV6qsm2I4wPmGv+Pq/s8LHnzuLTrhkjXeehFt+/GKlPJUTjFI3+NR7uEqwlk 0notQud68MHSaQWsn+jahpx8zDSyCPpOoseqWoAConiIxI0aemfcv8zBvceGW08sId6h nH0xYuupv0bZM3c4Lsoiok7HlQVVdGtQqDbQ+fIaxzMLuLECpLqOiNNj4o2yAqUJMKbp fekQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=exSDwXFeg4tRtu8OOAQcg6R6IERO9LLPK6uGwsxAb+w=; fh=8ikcPhg1+IvwMU4tUTt+Y5aDn+9ZQ2papQJ91dbZy/8=; b=i3y+7BIiZ4FnToUHtVYfscMbzHhmtyUY9hsWyH76N5X8l9jLeK9hyQOCuzqvWRozd9 vx1LVeaimpySOiI/frrwpkYxNAXgtEa09fsPzNc0JZJDRFHuP6RjkUPbUmNKSoAhrb5Q p/xwKvcJM470C3e57aFRMM9jWfbI5+8rV/A/iL/ETXHTfCMtviAuJrjJX83EnLFxXajo 8HeJo4hqjqh08O/zKqD9RR52f6lyUN/1Fk+LP15lYrKdSVRwbIDepZuzeijxTnhU3MVj 6gmcHCg7rYBdIUvfO5yTBBAhNQ2todyjqsaON4yakTmpDzUngKhttOITCKTLjf0l6qse rnkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id j9-20020a056a00234900b0068e47f1fc7esi9033075pfj.159.2023.11.26.17.34.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Nov 2023 17:34:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id E6A6B806664C; Sun, 26 Nov 2023 17:34:16 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229495AbjK0BeF (ORCPT + 99 others); Sun, 26 Nov 2023 20:34:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229379AbjK0BeE (ORCPT ); Sun, 26 Nov 2023 20:34:04 -0500 Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81ACE10F; Sun, 26 Nov 2023 17:34:10 -0800 (PST) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046060;MF=xueshuai@linux.alibaba.com;NM=1;PH=DS;RN=17;SR=0;TI=SMTPD_---0Vx7cD-F_1701048846; Received: from 30.240.112.131(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0Vx7cD-F_1701048846) by smtp.aliyun-inc.com; Mon, 27 Nov 2023 09:34:08 +0800 Message-ID: <71fa699f-5130-401a-bf4a-3271579a8dda@linux.alibaba.com> Date: Mon, 27 Nov 2023 09:34:05 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v11 3/5] PCI: Move pci_clear_and_set_dword() helper to PCI header Content-Language: en-US To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Bjorn Helgaas Cc: ilkka@os.amperecomputing.com, kaishen@linux.alibaba.com, yangyicong@huawei.com, will@kernel.org, Jonathan.Cameron@huawei.com, baolin.wang@linux.alibaba.com, robin.murphy@arm.com, chengyou@linux.alibaba.com, LKML , linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, rdunlap@infradead.org, mark.rutland@arm.com, zhuo.song@linux.alibaba.com, renyu.zj@linux.alibaba.com References: <20231121013400.18367-1-xueshuai@linux.alibaba.com> <20231121013400.18367-4-xueshuai@linux.alibaba.com> From: Shuai Xue In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL 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: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Sun, 26 Nov 2023 17:34:17 -0800 (PST) + Bjorn for PCI. On 2023/11/22 21:14, Ilpo Järvinen wrote: Hi, Ilpo, Thank you for your reply. Please see my comments inline. > On Tue, 21 Nov 2023, Shuai Xue wrote: > >> The clear and set pattern is commonly used for accessing PCI config, >> move the helper pci_clear_and_set_dword() from aspm.c into PCI header. >> In addition, rename to pci_clear_and_set_config_dword() to retain the >> "config" information and match the other accessors. >> >> No functional change intended. >> >> Signed-off-by: Shuai Xue >> Acked-by: Bjorn Helgaas >> Tested-by: Ilkka Koskinen >> --- >> drivers/pci/access.c | 12 ++++++++ >> drivers/pci/pcie/aspm.c | 65 +++++++++++++++++++---------------------- >> include/linux/pci.h | 2 ++ >> 3 files changed, 44 insertions(+), 35 deletions(-) >> >> diff --git a/drivers/pci/access.c b/drivers/pci/access.c >> index 6554a2e89d36..6449056b57dd 100644 >> --- a/drivers/pci/access.c >> +++ b/drivers/pci/access.c >> @@ -598,3 +598,15 @@ int pci_write_config_dword(const struct pci_dev *dev, int where, >> return pci_bus_write_config_dword(dev->bus, dev->devfn, where, val); >> } >> EXPORT_SYMBOL(pci_write_config_dword); >> + >> +void pci_clear_and_set_config_dword(const struct pci_dev *dev, int pos, >> + u32 clear, u32 set) > > Just noting that annoyingly the ordering within the name is inconsistent > between: > pci_clear_and_set_config_dword() > and > pcie_capability_clear_and_set_dword() > > And if changed, it would be again annoyingly inconsistent with > pci_read/write_config_*(), oh well... And renaming pci_read/write_config_* > into the hierarchical pci_config_read/write_*() form for would touch only > ~6k lines... ;-D I think it is a good question, but I don't have a clear answer. I don't know much about the name history. As you mentioned, the above two accessors are the foundation operation, may it comes to @Bjorn decision. The pci_clear_and_set_config_dword() is a variant of bellow pci accessors: pci_read_config_dword() pci_write_config_dword() At last, they are consistend :) > >> + pci_clear_and_set_config_dword(child, >> + child->l1ss + PCI_L1SS_CTL1, 0, >> + cl1_2_enables); > > Adding clear and set only variants into the header like there are for > pcie_capability_*() would remove the need to add those 0 parameters. > IMO, it improves code readability considerably. > Agreed. Best Regards, Shuai