Aneesh Kumar K.V wrote:
> Dan Williams <dan.j.williams@xxxxxxxxx> writes:
[..]
> > +/**
> > + * struct pci_tsm_pf0 - Physical Function 0 TDISP context
> > + * @state: reflect device initialized, connected, or bound
> > + * @lock: protect @state vs pci_tsm_ops invocation
> > + * @doe_mb: PCIe Data Object Exchange mailbox
> > + */
> > +struct pci_tsm_pf0 {
> > + struct pci_tsm tsm;
> > + enum pci_tsm_state state;
> > + struct mutex lock;
> > + struct pci_doe_mb *doe_mb;
> > +};
> >
>
> While working with a multifunction device, I found that adding lock and
> state to struct pci_tsm simplified the code considerably.
>
> In multifunction setups, it’s possible that multiple functions may
> expose DOE capabilities. In this case, when sending SPDM messages for a
> TDI, should we always use the DOE mailbox of function 0, or should we
> address the mailbox of the specific function involved?
>
> If the latter is preferred, would it make sense to rename the current
> structure—currently representing the base pci_tsm plus the DOE
> mailbox—to something more generic? because it is not more tied to
> physical function 0
Just wanted to circle back on list for this discussion we had off-list.
Specifically, that even for a multi-function device the SPDM session and
IDE setup belongs with physical-function-0 (per PCIe 6.2 11.2.2). So is
it really the case that Linux needs to contend with non-0 functions for
IDE_KM and TDISP?
