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.
--
Regards,
Yi Liu
