Re: [PATCH v3 10/21] PCI/TSM: Rename pf0 to host

[Alistair]

On Wed, 2026-09-16 at 03:11 +0100, Jonathan Cameron wrote:
> On Fri, 11 Sep 2026 15:00:59 +1000
> Alistair <alistair@xxxxxxxxxxxxx> wrote:
> 
> > On Wed, 2026-09-09 at 00:01 +0100, Jonathan Cameron wrote:
> > > On Tue,  1 Sep 2026 11:03:36 +1000
> > > alistair23@xxxxxxxxx wrote:
> > >   
> > > > From: Alistair Francis <alistair.francis@xxxxxxx>
> > > > 
> > > > Rename pci_tsm_pf0 to pci_tsm_host (and rename variables and
> > > > function
> > > > names from pf0 to host) as part of converting pci_tsm_host
> > > > to be any device that knows how to speak any of CMA, IDE, or
> > > > TDISP.  
> > > 
> > > I'm not against the change, but I would like at least one example
> > > of
> > > 'what' other type of device you plan to use this for.
> > > 
> > > vf or something else?  
> > 
> > It's based on the reply here: https://lkml.org/lkml/2026/6/18/1741
> > 
> > I don't know PCIe that well, so honestly I'm not sure.
> 
> Yeah, that's about both VFs and other physical functions.
> Those can exist on both real EPs and RCiEPs.
> 
> > 
> > My use case is a root complex integrated endpoint
> 
> Any more info to share on that? Why isn't it attested etc as
> part of the host given it's integrated? Or is SPDM a path to

Oh, sorry. It's not integrated in the sense of on the board. It's just
a PCIe attached NVMe device. You can see the example for testing with
QEMU in the cover letter.

> something other than simple attestation here?  Fine to do it this
> way, just seems like overkill so I'm curious what the application
> is.

The next step is to expand this to support other transports, like the
storage ones.

Alistair

> 
> Jonathan