> From: Nicolin Chen <nicolinc@xxxxxxxxxx> > Sent: Sunday, September 11, 2022 7:36 AM > > On Thu, Sep 08, 2022 at 09:08:38AM -0300, Jason Gunthorpe wrote: > > On Thu, Sep 08, 2022 at 09:30:57AM +0000, Tian, Kevin wrote: > > > > There are also cases where common kAPIs are called in the attach > > > path which may return -EINVAL and random errno, e.g.: > > > > > > omap_iommu_attach_dev() > > > omap_iommu_attach() > > > iommu_enable() > > > pm_runtime_get_sync() > > > __pm_runtime_resume() > > > rpm_resume() > > > if (dev->power.runtime_error) { > > > retval = -EINVAL; > > > Yes, this is was also on my mind with choosing an unpopular return > > code, it has a higher chance of not coming out of some other kernel > > API > > I wonder if it would be safe to just treat a pm_runtime_get_sync() > failure as -ENODEV, since a PM resume() mostly occurs to the IOMMU > that an IOMMU client/master device is behind, while an iommu_domain > rarely intervenes. Yes, this is a condition preventing the device from being attached by a domain hence converting -EINVAL to -ENODEV probably makes sense. But as replied in another we might want to keep other errno's as is. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization