[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB52761E126D797ED865DC3E8B8C479@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 13 Sep 2022 02:24:27 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>,
Robin Murphy <robin.murphy@....com>,
Joerg Roedel <joro@...tes.org>,
Jason Gunthorpe <jgg@...dia.com>
CC: "will@...nel.org" <will@...nel.org>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
"marcan@...can.st" <marcan@...can.st>,
"sven@...npeter.dev" <sven@...npeter.dev>,
"alyssa@...enzweig.io" <alyssa@...enzweig.io>,
"robdclark@...il.com" <robdclark@...il.com>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
"mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
"gerald.schaefer@...ux.ibm.com" <gerald.schaefer@...ux.ibm.com>,
"orsonzhai@...il.com" <orsonzhai@...il.com>,
"baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
"zhang.lyra@...il.com" <zhang.lyra@...il.com>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
"vdumpa@...dia.com" <vdumpa@...dia.com>,
"jonathanh@...dia.com" <jonathanh@...dia.com>,
"jean-philippe@...aro.org" <jean-philippe@...aro.org>,
"cohuck@...hat.com" <cohuck@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"shameerali.kolothum.thodi@...wei.com"
<shameerali.kolothum.thodi@...wei.com>,
"thunder.leizhen@...wei.com" <thunder.leizhen@...wei.com>,
"christophe.jaillet@...adoo.fr" <christophe.jaillet@...adoo.fr>,
"yangyingliang@...wei.com" <yangyingliang@...wei.com>,
"jon@...id-run.com" <jon@...id-run.com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"asahi@...ts.linux.dev" <asahi@...ts.linux.dev>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: RE: [PATCH v6 1/5] iommu: Return -EMEDIUMTYPE for incompatible domain
and device/group
> From: Nicolin Chen <nicolinc@...dia.com>
> 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.
Powered by blists - more mailing lists