From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: <linux-coco@lists.linux.dev>, <linux-pci@vger.kernel.org>,
<aik@amd.com>, <yilun.xu@linux.intel.com>,
<aneesh.kumar@kernel.org>, <bhelgaas@google.com>,
<gregkh@linuxfoundation.org>
Subject: Re: [PATCH v7 3/9] PCI: Introduce pci_walk_bus_reverse(), for_each_pci_dev_reverse()
Date: Wed, 29 Oct 2025 14:00:02 +0000 [thread overview]
Message-ID: <20251029140002.0000596f@huawei.com> (raw)
In-Reply-To: <20251024020418.1366664-4-dan.j.williams@intel.com>
On Thu, 23 Oct 2025 19:04:12 -0700
Dan Williams <dan.j.williams@intel.com> wrote:
> PCI/TSM, the PCI core functionality for the PCIe TEE Device Interface
> Security Protocol (TDISP), has a need to walk all subordinate functions of
> a Device Security Manager (DSM) to setup a device security context. A DSM
> is physical function 0 of multi-function or SR-IOV device endpoint, or it
> is an upstream switch port.
>
> In error scenarios or when a TEE Security Manager (TSM) device is removed
> it needs to unwind all established DSM contexts.
>
> Introduce reverse versions of PCI device iteration helpers to mirror the
> setup path and ensure that dependent children are handled before parents.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Bit of archaeology was needed as there are some existing oddities in the
functions this is based on.
My suggestions for this are don't use guard() and drop the void * cast that
we should cleanup in the existing code.
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index f26aec6ff588..1c981ca72b03 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -8,6 +8,7 @@
> */
> #include <linux/module.h>
> #include <linux/kernel.h>
> +#include <linux/cleanup.h>
> #include <linux/pci.h>
> #include <linux/errno.h>
> #include <linux/ioport.h>
> @@ -432,6 +433,27 @@ static int __pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void
> return ret;
> }
>
> +static int __pci_walk_bus_reverse(struct pci_bus *top,
> + int (*cb)(struct pci_dev *, void *),
> + void *userdata)
> +{
> + struct pci_dev *dev;
> + int ret = 0;
> +
> + list_for_each_entry_reverse(dev, &top->devices, bus_list) {
> + if (dev->subordinate) {
> + ret = __pci_walk_bus_reverse(dev->subordinate, cb,
> + userdata);
> + if (ret)
> + break;
> + }
> + ret = cb(dev, userdata);
> + if (ret)
> + break;
> + }
> + return ret;
I see this is local style so fair enough, but I'd have gone with early
returns as it's a simple case of return ret if it is ever set.
> +}
> +/**
> + * pci_walk_bus_reverse - walk devices on/under bus, calling callback.
> + * @top: bus whose devices should be walked
> + * @cb: callback to be called for each device found
> + * @userdata: arbitrary pointer to be passed to callback
> + *
> + * Same semantics as pci_walk_bus(), but walks the bus in reverse order.
> + */
> +void pci_walk_bus_reverse(struct pci_bus *top,
> + int (*cb)(struct pci_dev *, void *), void *userdata)
> +{
> + guard(rwsem_read)(&pci_bus_sem);
So this ends up different to pci_walk_bus. I'd be tempted to just
not bother bringing a single guard() usage here. Gain is trivial and
mixing and matching style in a file isn't particularly nice.
I'd not mind changing pci_walk_bus() as well but that would need
to be a trivial precursor patch I think.
> + __pci_walk_bus_reverse(top, cb, userdata);
> +}
> +EXPORT_SYMBOL_GPL(pci_walk_bus_reverse);
> +
> diff --git a/drivers/pci/search.c b/drivers/pci/search.c
> index 53840634fbfc..e6e84dc62e82 100644
> --- a/drivers/pci/search.c
> +++ b/drivers/pci/search.c
> @@ -282,6 +282,45 @@ static struct pci_dev *pci_get_dev_by_id(const struct pci_device_id *id,
> return pdev;
> }
>
> +static struct pci_dev *pci_get_dev_by_id_reverse(const struct pci_device_id *id,
> + struct pci_dev *from)
> +{
> + struct device *dev;
> + struct device *dev_start = NULL;
> + struct pci_dev *pdev = NULL;
> +
> + if (from)
> + dev_start = &from->dev;
> + dev = bus_find_device_reverse(&pci_bus_type, dev_start, (void *)id,
That (void *) is casting away a const but bus_find_device_reverse takes
a const void *.
I think you are fine just relying on implicit cast for that parameter.
Not that important and pci_get_device_by_id() does have same odd casting.
Looks like way back bus_find_device() didn't take a const pointer
Seems to be true in 3.19 (random choice jumping back through time on elixir)
but not sure when it changed.
Anyhow, would be nice to clean that up in existing code if anyone is bored
enough.
> + match_pci_dev_by_id);
> + if (dev)
> + pdev = to_pci_dev(dev);
> + pci_dev_put(from);
> + return pdev;
> +}
next prev parent reply other threads:[~2025-10-29 14:00 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 2:04 [PATCH v7 0/9] PCI/TSM: Core infrastructure for PCI device security (TDISP) Dan Williams
2025-10-24 2:04 ` [PATCH v7 1/9] coco/tsm: Introduce a core device for TEE Security Managers Dan Williams
2025-10-29 13:33 ` Jonathan Cameron
2025-10-29 23:47 ` dan.j.williams
2025-10-30 1:00 ` Alexey Kardashevskiy
2025-10-30 9:04 ` Carlos López
2025-10-30 23:16 ` dan.j.williams
2025-10-24 2:04 ` [PATCH v7 2/9] PCI/IDE: Enumerate Selective Stream IDE capabilities Dan Williams
2025-10-29 13:42 ` Jonathan Cameron
2025-10-29 23:55 ` dan.j.williams
2025-10-30 0:59 ` Alexey Kardashevskiy
2025-10-30 21:13 ` dan.j.williams
2025-10-30 21:37 ` Bjorn Helgaas
2025-10-30 23:56 ` Alexey Kardashevskiy
2025-10-31 0:34 ` dan.j.williams
2025-10-31 1:20 ` Bjorn Helgaas
2025-10-30 8:34 ` Aneesh Kumar K.V
2025-10-24 2:04 ` [PATCH v7 3/9] PCI: Introduce pci_walk_bus_reverse(), for_each_pci_dev_reverse() Dan Williams
2025-10-29 14:00 ` Jonathan Cameron [this message]
2025-10-29 16:05 ` dan.j.williams
2025-10-30 19:36 ` dan.j.williams
2025-10-24 2:04 ` [PATCH v7 4/9] PCI/TSM: Establish Secure Sessions and Link Encryption Dan Williams
2025-10-26 3:18 ` kernel test robot
2025-10-29 15:53 ` Jonathan Cameron
2025-10-30 19:56 ` dan.j.williams
2025-10-30 1:13 ` Alexey Kardashevskiy
2025-10-30 8:35 ` Aneesh Kumar K.V
2025-10-24 2:04 ` [PATCH v7 5/9] PCI: Add PCIe Device 3 Extended Capability enumeration Dan Williams
2025-10-24 2:04 ` [PATCH v7 6/9] PCI: Establish document for PCI host bridge sysfs attributes Dan Williams
2025-10-29 16:04 ` Jonathan Cameron
2025-10-24 2:04 ` [PATCH v7 7/9] PCI/IDE: Add IDE establishment helpers Dan Williams
2025-10-25 16:53 ` Aneesh Kumar K.V
2025-10-29 18:57 ` dan.j.williams
2025-10-29 16:25 ` Jonathan Cameron
2025-10-24 2:04 ` [PATCH v7 8/9] PCI/IDE: Report available IDE streams Dan Williams
2025-10-29 16:31 ` Jonathan Cameron
2025-10-30 20:48 ` dan.j.williams
2025-10-24 2:04 ` [PATCH v7 9/9] PCI/TSM: Report active " Dan Williams
2025-10-29 16:34 ` Jonathan Cameron
2025-10-30 21:03 ` dan.j.williams
2025-10-30 2:05 ` Alexey Kardashevskiy
2025-10-27 10:01 ` [PATCH v7 0/9] PCI/TSM: Core infrastructure for PCI device security (TDISP) Aneesh Kumar K.V
2025-10-29 5:20 ` Alexey Kardashevskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251029140002.0000596f@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=yilun.xu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).