Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp3012014rdg; Tue, 17 Oct 2023 01:34:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGsKi1Vx/yGXc7Gqqi9oHfTy7WdEszInGPXuD8lkHRE1OlutIz62lGoTn/gRMiqHx17u1hv X-Received: by 2002:a81:844b:0:b0:5a8:1812:a7ee with SMTP id u72-20020a81844b000000b005a81812a7eemr1398044ywf.3.1697531678208; Tue, 17 Oct 2023 01:34:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697531678; cv=none; d=google.com; s=arc-20160816; b=xQcd5LOMqGKTOdtmCNC/sB6dwDB1b9YG7hdQNbbtkJ0QFe1u95rMwNQT6EJQCZpBM8 gYIr/Bc/AlFaulciJ59WStrwrvbTqPlVb/bUze+ZX3LsBVDZYimaMV4d+BtcX7WHVa72 6mWTUBxib9unv7nQkKk0NnrzFWfZQL3Ek5pRUWgktRGFQaXQ8KwU1CDy4HvYFN9EDl/w lybJ0wMHgiUzpXAYHsIffu1AXywBUtHfQsO3Z4WCWzK2IHuHKJgzTb3V1DV4C1FMyGFC INPLWrTXE0ifGpWvOw6wb0CQjh29oE7r6mh7U/yBeJGe9jSprBRa80nzQYz6E1M6Rh1Q 7P4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=W8O9/s2Xak3EeyAhHCz64jPnkAVbzXrK0j8K4gUGF4U=; fh=EoaV8QciXCHfIckRUcOzNTwCDzboy5PgV/0VhQcnlG8=; b=pyUM71ec1vPlGFcdULaTyGOanVlsl3+Z5f0fjnylLH3E+bh89ghWtSiAD3Y+5uZvCj hhtROCaWDrVCmYvnVK15/XPDDO8HeHIYt3M143tn9TGSA2TtDG3By4J7fWjaPB8vD6LF ptbTs00vcLki6Qxd6ntzzJK1DqIqyB6sUNbN6jlZcRxBrbP6BHDJEAD5JjZvhfPXIhhG K1AwleZmQqe4rAuxXCfLCZjAsAzx7A7k8cIvpAzGhv9PjopLNxZJ0Mg9Uv10D9lXNXsZ sJa+nHDQ990Di5a1FDavgJ0creUVqd7NohnzU6hB28GRXqi5e3pj0h22nl2LckP0U+Hh U4Hw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id bq17-20020a056a02045100b00578eafd0826si1381183pgb.398.2023.10.17.01.34.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 01:34:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 8920380417CB; Tue, 17 Oct 2023 01:34:35 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234737AbjJQIe3 (ORCPT + 99 others); Tue, 17 Oct 2023 04:34:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234667AbjJQIe2 (ORCPT ); Tue, 17 Oct 2023 04:34:28 -0400 Received: from bmailout2.hostsharing.net (bmailout2.hostsharing.net [83.223.78.240]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14D9AB6 for ; Tue, 17 Oct 2023 01:34:27 -0700 (PDT) Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id BF837280248D0; Tue, 17 Oct 2023 10:34:21 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id B3DA151FE31; Tue, 17 Oct 2023 10:34:21 +0200 (CEST) Date: Tue, 17 Oct 2023 10:34:21 +0200 From: Lukas Wunner To: Alistair Francis Cc: bhelgaas@google.com, linux-pci@vger.kernel.org, Jonathan.Cameron@huawei.com, alex.williamson@redhat.com, christian.koenig@amd.com, kch@nvidia.com, gregkh@linuxfoundation.org, logang@deltatee.com, linux-kernel@vger.kernel.org, chaitanyak@nvidia.com, rdunlap@infradead.org, Alistair Francis Subject: Re: [PATCH v9 2/3] PCI/DOE: Expose the DOE features via sysfs Message-ID: <20231017083421.GA23168@wunner.de> References: <20231013034158.2745127-1-alistair.francis@wdc.com> <20231013034158.2745127-2-alistair.francis@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231013034158.2745127-2-alistair.francis@wdc.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email 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 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 01:34:35 -0700 (PDT) On Fri, Oct 13, 2023 at 01:41:57PM +1000, Alistair Francis wrote: > +#ifdef CONFIG_SYSFS > +static umode_t pci_doe_sysfs_attr_is_visible(struct kobject *kobj, > + struct attribute *a, int n) > +{ > + struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj)); > + struct pci_doe_mb *doe_mb; > + unsigned long index, j; > + void *entry; > + > + xa_for_each(&pdev->doe_mbs, index, doe_mb) { > + xa_for_each(&doe_mb->feats, j, entry) > + return a->mode; > + } > + > + return 0; > +} Out of curiosity: Does this method prevent creation of a "doe_features" directory for devices which don't have any DOE mailboxes? (If it does, a code comment explaining that might be helpful.) > +const struct attribute_group pci_dev_doe_feature_group = { > + .name = "doe_features", > + .attrs = pci_dev_doe_feature_attrs, > + .is_visible = pci_doe_sysfs_attr_is_visible, > +}; Nit: Wondering why the "=" is aligned for .name and .attrs but not for .is_visible? > +static void pci_doe_sysfs_feature_remove(struct pci_dev *pdev, > + struct pci_doe_mb *doe_mb) > +{ > + struct device *dev = &pdev->dev; > + struct device_attribute *attrs = doe_mb->sysfs_attrs; > + unsigned long i; > + void *entry; Nit: Inverse Christmas tree? > +static int pci_doe_sysfs_feature_populate(struct pci_dev *pdev, > + struct pci_doe_mb *doe_mb) > +{ > + struct device *dev = &pdev->dev; > + struct device_attribute *attrs; > + unsigned long num_features = 0; > + unsigned long vid, type; > + unsigned long i; > + void *entry; > + int ret; > + > + xa_for_each(&doe_mb->feats, i, entry) > + num_features++; > + > + attrs = kcalloc(num_features, sizeof(*attrs), GFP_KERNEL); > + if (!attrs) > + return -ENOMEM; > + > + doe_mb->sysfs_attrs = attrs; > + xa_for_each(&doe_mb->feats, i, entry) { > + sysfs_attr_init(&attrs[i].attr); > + vid = xa_to_value(entry) >> 8; > + type = xa_to_value(entry) & 0xFF; > + attrs[i].attr.name = kasprintf(GFP_KERNEL, > + "0x%04lX:%02lX", vid, type); Nit: Capital X conversion specifier will result in upper case hex characters in filename and contents, whereas existing sysfs attributes such as "vendor", "device" contain lower case hex characters. Might want to consider lower case x for consistency. > +void pci_doe_sysfs_teardown(struct pci_dev *pdev) > +{ > + struct pci_doe_mb *doe_mb; > + unsigned long index; > + > + xa_for_each(&pdev->doe_mbs, index, doe_mb) { > + pci_doe_sysfs_feature_remove(pdev, doe_mb); > + } Nit: Curly braces not necessary. > @@ -1153,6 +1154,10 @@ static void pci_remove_resource_files(struct pci_dev *pdev) > { > int i; > > + if (IS_ENABLED(CONFIG_PCI_DOE)) { > + pci_doe_sysfs_teardown(pdev); > + } Nit: Curly braces not necessary. > @@ -1230,6 +1235,12 @@ static int pci_create_resource_files(struct pci_dev *pdev) > int i; > int retval; > > + if (IS_ENABLED(CONFIG_PCI_DOE)) { > + retval = pci_doe_sysfs_init(pdev); > + if (retval) > + return retval; > + } > + > /* Expose the PCI resources from this device as files */ > for (i = 0; i < PCI_STD_NUM_BARS; i++) { I think this needs to be added to pci_create_sysfs_dev_files() instead. pci_create_resource_files() only deals with creation of resource files, as the name implies, which is unrelated to DOE features. Worse, pci_create_resource_files() is also called from pci_dev_resource_resize_attr(), i.e. every time user space writes to the "resource##n##_resize" attributes. Similarly, the call to pci_doe_sysfs_teardown() belongs in pci_remove_sysfs_dev_files(). Thanks, Lukas