[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB527658C31268EB4A8411EDE88C4C9@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 20 Sep 2022 06:24:58 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>,
"joro@...tes.org" <joro@...tes.org>,
"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
"will@...nel.org" <will@...nel.org>,
"robin.murphy@....com" <robin.murphy@....com>,
"robdclark@...il.com" <robdclark@...il.com>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
"agross@...nel.org" <agross@...nel.org>,
"bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
"matthias.bgg@...il.com" <matthias.bgg@...il.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>,
"jean-philippe@...aro.org" <jean-philippe@...aro.org>,
"sricharan@...eaurora.org" <sricharan@...eaurora.org>
CC: "jgg@...dia.com" <jgg@...dia.com>,
"konrad.dybcio@...ainline.org" <konrad.dybcio@...ainline.org>,
"yong.wu@...iatek.com" <yong.wu@...iatek.com>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
"vdumpa@...dia.com" <vdumpa@...dia.com>,
"jonathanh@...dia.com" <jonathanh@...dia.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"shameerali.kolothum.thodi@...wei.com"
<shameerali.kolothum.thodi@...wei.com>,
"christophe.jaillet@...adoo.fr" <christophe.jaillet@...adoo.fr>,
"thunder.leizhen@...wei.com" <thunder.leizhen@...wei.com>,
"quic_saipraka@...cinc.com" <quic_saipraka@...cinc.com>,
"jon@...id-run.com" <jon@...id-run.com>,
"yangyingliang@...wei.com" <yangyingliang@...wei.com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"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-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>
Subject: RE: [PATCH v3 3/6] iommu: Add return value rules to attach_dev op and
APIs
> From: Nicolin Chen <nicolinc@...dia.com>
> Sent: Thursday, September 15, 2022 3:54 PM
>
> +/**
> + * iommu_attach_device - Attach a device to an IOMMU domain
> + * @domain: IOMMU domain to attach
> + * @dev: Device that will be attached
> + *
> + * Returns 0 on success and error code on failure
> + *
> + * Note that EINVAL may be returned as a soft failure if the domain and
> device
> + * are incompatible: if the domain has already been used or configured in
> some
I didn't get the meaning of the 'if' part.
> + * way, attaching the same device to a different domain may succeed.
> Otherwise,
> + * it may still represent some fundamental problem.
I'm not sure what the sentence after 'otherwise' actually adds to the
caller. There is no way to differentiate incompatibility vs. fundamental
problem, hence pointless for the caller to know this fact.
IMHO just state that the caller can treat -EINVAL as soft failure indicating
incompatibility issue between domain and device.
Later for @attach_dev you can add that driver may return (but not
recommend) -EINVAL for some fundamental problems.
Powered by blists - more mailing lists