Aneesh Kumar K.V wrote:
> Dan Williams <dan.j.williams@xxxxxxxxx> writes:
>
> ....
> > +
> > +/**
> > + * struct pci_tsm - Core TSM context for a given PCIe endpoint
> > + * @pdev: Back ref to device function, distinguishes type of pci_tsm context
> > + * @dsm: PCI Device Security Manager for link operations on @pdev
> > + * @ops: Link Confidentiality or Device Function Security operations
> > + *
> > + * This structure is wrapped by low level TSM driver data and returned by
> > + * probe()/lock(), it is freed by the corresponding remove()/unlock().
> > + *
> > + * For link operations it serves to cache the association between a Device
> > + * Security Manager (DSM) and the functions that manager can assign to a TVM.
> > + * That can be "self", for assigning function0 of a TEE I/O device, a
> > + * sub-function (SR-IOV virtual function, or non-function0
> > + * multifunction-device), or a downstream endpoint (PCIe upstream switch-port as
> > + * DSM).
> > + */
> > +struct pci_tsm {
> > + struct pci_dev *pdev;
> > + struct pci_dev *dsm;
> >
>
> struct pci_dev *dsm_dev?
Sure.
> > + const struct pci_tsm_ops *ops;
> > +};
> > +
> > +/**
> > + * struct pci_tsm_pf0 - Physical Function 0 TDISP link context
> > + * @base: generic core "tsm" context
> > + * @lock: mutual exclustion for pci_tsm_ops invocation
> > + * @doe_mb: PCIe Data Object Exchange mailbox
> > + */
> > +struct pci_tsm_pf0 {
> > + struct pci_tsm base;
> >
>
> struct pci_tsm base_tsm ?
Works for me.
> > + struct mutex lock;
> > + struct pci_doe_mb *doe_mb;
> > +};
> > +
>
>
> Both the above will help when we have names likes
>
> dsm->pci.base.pdev; vs dsm->pci.base_tsm.pdev;
>
> and tsm->dsm vs tsm->dsm_dev
Sounds good.
