> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx> > Sent: Monday, April 15, 2024 1:42 PM > > On 4/12/24 4:15 PM, Yi Liu wrote: > > Today, the iommu layer gets the max_pasids by pci_max_pasids() or > reading > > the "pasid-num-bits" property. This requires the non-PCI devices to have a > > "pasid-num-bits" property. Like the mock device used in iommufd selftest, > > otherwise the max_pasids check would fail in iommu layer. > > > > While there is an alternative, the iommu layer can allow the iommu driver > > to set the max_pasids in its probe_device() callback and populate it. This > > is simpler and has no impact on the existing cases. > > > > Suggested-by: Jason Gunthorpe<jgg@xxxxxxxxxx> > > Signed-off-by: Yi Liu<yi.l.liu@xxxxxxxxx> > > --- > > drivers/iommu/iommu.c | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > The code does not appear to match the commit message here. > > The code in change is a refactoring by folding the max_pasid assignment > into its helper. However, the commit message suggests a desire to expose > some kind of kAPI for device drivers. > it's not about exposing a new kAPI. Instead it allows the driver to manually set dev->iommu->max_pasids before calling iommu_init_device(). kind of another contract to convey the max pasid. But as how you are confused, I prefer to defining a "pasid-num-bits" property in the mock driver. It's easier to understand.
