Received: by 2002:a89:413:0:b0:1fd:dba5:e537 with SMTP id m19csp1368240lqs; Sat, 15 Jun 2024 06:05:45 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXZtlZZ9PS6wBNiwjXqeJfouPSrtcrOE3gLPt4odYbGV1pYLqPf2EbIxWxtFcPd/iQEL/itaXllAta/wsSX93f6+YwCcN+l0W15ge/c5Q== X-Google-Smtp-Source: AGHT+IGrBEdiPYXv8xMHkacQnJJBp7VobwP3i9nabpdjEuPrmIMtuujJcIhPV51ZRDR/4bH1AFwx X-Received: by 2002:a05:622a:93:b0:441:569a:9c67 with SMTP id d75a77b69052e-44216b19eb8mr70607501cf.56.1718456745153; Sat, 15 Jun 2024 06:05:45 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718456745; cv=pass; d=google.com; s=arc-20160816; b=DCRGXnErDTTNoowT57gE00Gc+Ij75hkXSEoAm9TpRycE8GxwsNDnW+O/xI/PBBmRVu KP95vc+gGWDEucX7g/RgkfcdKRDxfKOVezhMeSvdsc0jcmYpjXlNqFpV+cge1sUm51u0 zWukKeqxYl/I9F54Y7zD0sFLb2doWy2Z1gHmqkJF//l+31VgwhKM1XJCcM8wkmYg19uZ LluLWRAeD0CbEdh3EMdZ0d39FP0NLVhRqKCflq+6VmGBU0dBfs11e3X0of3YHKBxZhXg 7E8GbTxztu9mK+J9dX0un0/NJobNKPiCm1tsLLDOSPDeUFXekAmtu1MQSiMHsM6m2dvj 6TAQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=/VEtjQjEcd+5NPQhKCvhHrCtcAjy01sljMx4WMAgVm0=; fh=EoaV8QciXCHfIckRUcOzNTwCDzboy5PgV/0VhQcnlG8=; b=lpzFL+RhA3jX4h/iAfPjRs2kcEE7hp3jOiOrIjHPRQegXilil4IWRJ5HSl0P2Nr/xw 4yPQCIoU16s8Vb35VtxTC+lX+EPquSgWRJpcXF+zfLje47kyGzJ8Lfzuhjc863f3RN/I pIjk0CnWT+pVmzxCBnkmS9x0br30IFGmvSGMFZvDyfc8LncaHZVhgZO01ceTy6zVzcnU 4JaapSUSlrZxMlonRl7Am4TSpPDWk6qyuxWLxnclL+4wKxtPm3ZBxv4Dsf8gFnTUMQDw a7VR5Uh480OnP1i2aSBX0ACct4ymgKdVz3FMp+P9lCkht3OGbvkcV/vdpnye9Ju5Ystb zreQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-215890-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-215890-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id d75a77b69052e-441ef3bb049si63119901cf.135.2024.06.15.06.05.44 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jun 2024 06:05:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-215890-linux.lists.archive=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; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-215890-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-215890-linux.lists.archive=gmail.com@vger.kernel.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 D7F881C211A1 for ; Sat, 15 Jun 2024 13:05:44 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 05D2E482CA; Sat, 15 Jun 2024 13:05:36 +0000 (UTC) Received: from bmailout1.hostsharing.net (bmailout1.hostsharing.net [83.223.95.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AD0251B285; Sat, 15 Jun 2024 13:05:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.223.95.100 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718456735; cv=none; b=jFtJ7a7sEpMqazBLItNP8mVizp7/Q4K7fNnjp6rgqN5ucuyff2c8ak4HakIsZY20B2uVheisSKBhvvZO+ZuhXVGyo+cdgk7QqkiN98eFPymftkO30PxFRTtrFdKrcBqIeEgudZGZ3aSl7ASj9861mOTC6zKmeK/IOnqYZUSvy4k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718456735; c=relaxed/simple; bh=PxvYVUDmSnJy5C0v0jn32DnB33DAEZOJYRfL5ECT/Qk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=epXA1qU8NRftWJBmNNCTT2YoLHQpSPUXtUlBDjbbBmumL+5b/lEqi10psThKXsg2+Rp7wQBzjeAXqDbNv1zsZdbhHuXMgRAc4OOahEcOJ4R2lrETftXCnL1nsweAwzqVE0rGHYtiZZUx5g/oyd8Czn24sBP7c64yQRzDyi48k4Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de; spf=none smtp.mailfrom=h08.hostsharing.net; arc=none smtp.client-ip=83.223.95.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=wunner.de Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=h08.hostsharing.net Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (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 TLS RSA CA G1" (verified OK)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 576F33000D7C9; Sat, 15 Jun 2024 15:05:29 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 3D6E62EE137; Sat, 15 Jun 2024 15:05:29 +0200 (CEST) Date: Sat, 15 Jun 2024 15:05:29 +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 v11 3/4] PCI/DOE: Expose the DOE features via sysfs Message-ID: References: <20240614001244.925401-1-alistair.francis@wdc.com> <20240614001244.925401-3-alistair.francis@wdc.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240614001244.925401-3-alistair.francis@wdc.com> On Fri, Jun 14, 2024 at 10:12:43AM +1000, Alistair Francis wrote: > --- a/drivers/pci/doe.c > +++ b/drivers/pci/doe.c [...] > +#ifdef CONFIG_SYSFS > +static ssize_t doe_discovery_show(struct device *dev, > + struct device_attribute *attr, > + char *buf) > +{ > + return sysfs_emit(buf, "0001:00\n"); > +} > +DEVICE_ATTR_RO(doe_discovery); If you want to use "0001:00" as filename but can't because "0001:00_show()" would not be a valid function name in C, I think there's no harm in manually expanding the macro to: struct device_attribute dev_attr_doe_discovery = \ __ATTR(0001:00, 0444, pci_doe_sysfs_feature_show, NULL); That also avoids the need to have an extra doe_discovery_show() function. Intuitively, when I saw there's a "doe_discovery" attribute, my first thought was: "Oh maybe I need to write something there to (re-)initiate DOE discovery?" > +static umode_t pci_doe_features_sysfs_attr_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; > + unsigned long vid, type; > + void *entry; > + > + xa_for_each(&pdev->doe_mbs, index, doe_mb) { > + xa_for_each(&doe_mb->feats, j, entry) { > + vid = xa_to_value(entry) >> 8; > + type = xa_to_value(entry) & 0xFF; > + > + if (vid == 0x01 && type == 0x00) { Wherever possible, PCI_VENDOR_ID_PCI_SIG and PCI_DOE_PROTOCOL_DISCOVERY macros should be used in lieu of 0x0001 and 0x00. > + /* > + * This is the DOE discovery protocol > + * Every DOE instance must support this, so we > + * give it a useful name. > + */ > + return a->mode; > + } > + } > + } > + > + return 0; > +} I agree with Jonathan that at first glance one would assume that this function just always returns a->mode. > +static bool pci_doe_features_sysfs_group_visible(struct kobject *kobj) > +{ > + struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj)); > + struct pci_doe_mb *doe_mb; > + unsigned long index; > + > + xa_for_each(&pdev->doe_mbs, index, doe_mb) { > + if (!xa_empty(&doe_mb->feats)) > + return true; > + } > + > + return false; So in principle, doe_mb->feats should never be empty because the discovery protocol is always supported, right? Wouldn't it then suffice to just check for: + if (!xa_empty(&pdev->doe_mbs)) + return true; Or alternatively: + return !xa_empty(&pdev->doe_mbs); Thanks, Lukas