On Sat, Apr 20, 2024 at 01:45:57PM +0800, Yi Liu wrote: > On 2024/4/17 16:49, Tian, Kevin wrote: > > > 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. > > @Jason, how about your thought? :) Adding a "pasid-num-bits" may be > more straightforward. Sure, just make sure it doesn't leak memory... Jason
