From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: <joro@8bytes.org>, <will@kernel.org>, <lorenzo.pieralisi@arm.com>,
<robh+dt@kernel.org>, <guohanjun@huawei.com>,
<sudeep.holla@arm.com>, <rjw@rjwysocki.net>, <lenb@kernel.org>,
<robin.murphy@arm.com>, <eric.auger@redhat.com>,
<iommu@lists.linux-foundation.org>, <devicetree@vger.kernel.org>,
<linux-acpi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-accelerators@lists.ozlabs.org>, <baolu.lu@linux.intel.com>,
<jacob.jun.pan@linux.intel.com>, <kevin.tian@intel.com>,
<vdumpa@nvidia.com>, <zhangfei.gao@linaro.org>,
<shameerali.kolothum.thodi@huawei.com>, <vivek.gautam@arm.com>
Subject: Re: [PATCH v10 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Fri, 22 Jan 2021 10:58:32 +0000 [thread overview]
Message-ID: <20210122105832.00002dcb@Huawei.com> (raw)
In-Reply-To: <YAqSCKeN2o+GsISZ@myrica>
On Fri, 22 Jan 2021 09:51:20 +0100
Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> On Thu, Jan 21, 2021 at 07:12:36PM +0000, Jonathan Cameron wrote:
> > > @@ -2502,6 +2647,7 @@ static void arm_smmu_release_device(struct device *dev)
> > >
> > > master = dev_iommu_priv_get(dev);
> > > WARN_ON(arm_smmu_master_sva_enabled(master));
> > > + iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
> > > arm_smmu_detach_dev(master);
> > > arm_smmu_disable_pasid(master);
> > > arm_smmu_remove_master(master);
> >
> > The lack of symmetry here bothers me a bit, but it's already true, so I guess
> > this case is fine as well.
>
> Normally the device driver calls iommu_dev_feat_disable(SVA) which does
> iopf_queue_remove_device(). This is just a safety net in case the device
> gets removed without the driver properly cleaning up (which will WARN as
> well)
Ah makes sense. Maybe it's worth a comment in the code for future generations
of tired code readers?
>
> >
> > ...
> > >
> > > @@ -2785,6 +2946,7 @@ static int arm_smmu_cmdq_init(struct arm_smmu_device *smmu)
> > > static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
> > > {
> > > int ret;
> > > + bool sva = smmu->features & ARM_SMMU_FEAT_STALLS;
> >
> > FEAT_SVA?
>
> Ugh yes, thanks. I left this as a bool instead of moving into the test
> below because the PRI patch reuses it, but I think I'll just move it down
> when resending.
Makes sense.
>
> Thanks,
> Jean
>
> >
> > >
> > > /* cmdq */
> > > ret = arm_smmu_init_one_queue(smmu, &smmu->cmdq.q, ARM_SMMU_CMDQ_PROD,
> > > @@ -2804,6 +2966,12 @@ static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
> > > if (ret)
> > > return ret;
> > >
> > > + if (sva && smmu->features & ARM_SMMU_FEAT_STALLS) {
> >
> > Isn't this checking same thing twice?
> >
> > > + smmu->evtq.iopf = iopf_queue_alloc(dev_name(smmu->dev));
> > > + if (!smmu->evtq.iopf)
> > > + return -ENOMEM;
> > > + }
> > > +
> > > /* priq */
> > > if (!(smmu->features & ARM_SMMU_FEAT_PRI))
> > > return 0;
> > > @@ -3718,6 +3886,7 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
> > > iommu_device_unregister(&smmu->iommu);
> > > iommu_device_sysfs_remove(&smmu->iommu);
> > > arm_smmu_device_disable(smmu);
> > > + iopf_queue_free(smmu->evtq.iopf);
> > >
> > > return 0;
> > > }
> >
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: vivek.gautam@arm.com, guohanjun@huawei.com, will@kernel.org,
linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
lenb@kernel.org, devicetree@vger.kernel.org,
kevin.tian@intel.com, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org
Subject: Re: [PATCH v10 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Fri, 22 Jan 2021 10:58:32 +0000 [thread overview]
Message-ID: <20210122105832.00002dcb@Huawei.com> (raw)
In-Reply-To: <YAqSCKeN2o+GsISZ@myrica>
On Fri, 22 Jan 2021 09:51:20 +0100
Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> On Thu, Jan 21, 2021 at 07:12:36PM +0000, Jonathan Cameron wrote:
> > > @@ -2502,6 +2647,7 @@ static void arm_smmu_release_device(struct device *dev)
> > >
> > > master = dev_iommu_priv_get(dev);
> > > WARN_ON(arm_smmu_master_sva_enabled(master));
> > > + iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
> > > arm_smmu_detach_dev(master);
> > > arm_smmu_disable_pasid(master);
> > > arm_smmu_remove_master(master);
> >
> > The lack of symmetry here bothers me a bit, but it's already true, so I guess
> > this case is fine as well.
>
> Normally the device driver calls iommu_dev_feat_disable(SVA) which does
> iopf_queue_remove_device(). This is just a safety net in case the device
> gets removed without the driver properly cleaning up (which will WARN as
> well)
Ah makes sense. Maybe it's worth a comment in the code for future generations
of tired code readers?
>
> >
> > ...
> > >
> > > @@ -2785,6 +2946,7 @@ static int arm_smmu_cmdq_init(struct arm_smmu_device *smmu)
> > > static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
> > > {
> > > int ret;
> > > + bool sva = smmu->features & ARM_SMMU_FEAT_STALLS;
> >
> > FEAT_SVA?
>
> Ugh yes, thanks. I left this as a bool instead of moving into the test
> below because the PRI patch reuses it, but I think I'll just move it down
> when resending.
Makes sense.
>
> Thanks,
> Jean
>
> >
> > >
> > > /* cmdq */
> > > ret = arm_smmu_init_one_queue(smmu, &smmu->cmdq.q, ARM_SMMU_CMDQ_PROD,
> > > @@ -2804,6 +2966,12 @@ static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
> > > if (ret)
> > > return ret;
> > >
> > > + if (sva && smmu->features & ARM_SMMU_FEAT_STALLS) {
> >
> > Isn't this checking same thing twice?
> >
> > > + smmu->evtq.iopf = iopf_queue_alloc(dev_name(smmu->dev));
> > > + if (!smmu->evtq.iopf)
> > > + return -ENOMEM;
> > > + }
> > > +
> > > /* priq */
> > > if (!(smmu->features & ARM_SMMU_FEAT_PRI))
> > > return 0;
> > > @@ -3718,6 +3886,7 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
> > > iommu_device_unregister(&smmu->iommu);
> > > iommu_device_sysfs_remove(&smmu->iommu);
> > > arm_smmu_device_disable(smmu);
> > > + iopf_queue_free(smmu->evtq.iopf);
> > >
> > > return 0;
> > > }
> >
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jean-Philippe Brucker <jean-philippe@linaro.org>
Cc: vivek.gautam@arm.com, guohanjun@huawei.com, will@kernel.org,
lorenzo.pieralisi@arm.com, joro@8bytes.org,
linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
lenb@kernel.org, devicetree@vger.kernel.org,
kevin.tian@intel.com, jacob.jun.pan@linux.intel.com,
eric.auger@redhat.com, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
shameerali.kolothum.thodi@huawei.com,
iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org,
baolu.lu@linux.intel.com
Subject: Re: [PATCH v10 10/10] iommu/arm-smmu-v3: Add stall support for platform devices
Date: Fri, 22 Jan 2021 10:58:32 +0000 [thread overview]
Message-ID: <20210122105832.00002dcb@Huawei.com> (raw)
In-Reply-To: <YAqSCKeN2o+GsISZ@myrica>
On Fri, 22 Jan 2021 09:51:20 +0100
Jean-Philippe Brucker <jean-philippe@linaro.org> wrote:
> On Thu, Jan 21, 2021 at 07:12:36PM +0000, Jonathan Cameron wrote:
> > > @@ -2502,6 +2647,7 @@ static void arm_smmu_release_device(struct device *dev)
> > >
> > > master = dev_iommu_priv_get(dev);
> > > WARN_ON(arm_smmu_master_sva_enabled(master));
> > > + iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
> > > arm_smmu_detach_dev(master);
> > > arm_smmu_disable_pasid(master);
> > > arm_smmu_remove_master(master);
> >
> > The lack of symmetry here bothers me a bit, but it's already true, so I guess
> > this case is fine as well.
>
> Normally the device driver calls iommu_dev_feat_disable(SVA) which does
> iopf_queue_remove_device(). This is just a safety net in case the device
> gets removed without the driver properly cleaning up (which will WARN as
> well)
Ah makes sense. Maybe it's worth a comment in the code for future generations
of tired code readers?
>
> >
> > ...
> > >
> > > @@ -2785,6 +2946,7 @@ static int arm_smmu_cmdq_init(struct arm_smmu_device *smmu)
> > > static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
> > > {
> > > int ret;
> > > + bool sva = smmu->features & ARM_SMMU_FEAT_STALLS;
> >
> > FEAT_SVA?
>
> Ugh yes, thanks. I left this as a bool instead of moving into the test
> below because the PRI patch reuses it, but I think I'll just move it down
> when resending.
Makes sense.
>
> Thanks,
> Jean
>
> >
> > >
> > > /* cmdq */
> > > ret = arm_smmu_init_one_queue(smmu, &smmu->cmdq.q, ARM_SMMU_CMDQ_PROD,
> > > @@ -2804,6 +2966,12 @@ static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
> > > if (ret)
> > > return ret;
> > >
> > > + if (sva && smmu->features & ARM_SMMU_FEAT_STALLS) {
> >
> > Isn't this checking same thing twice?
> >
> > > + smmu->evtq.iopf = iopf_queue_alloc(dev_name(smmu->dev));
> > > + if (!smmu->evtq.iopf)
> > > + return -ENOMEM;
> > > + }
> > > +
> > > /* priq */
> > > if (!(smmu->features & ARM_SMMU_FEAT_PRI))
> > > return 0;
> > > @@ -3718,6 +3886,7 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
> > > iommu_device_unregister(&smmu->iommu);
> > > iommu_device_sysfs_remove(&smmu->iommu);
> > > arm_smmu_device_disable(smmu);
> > > + iopf_queue_free(smmu->evtq.iopf);
> > >
> > > return 0;
> > > }
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-22 11:56 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 12:36 [PATCH v10 00/10] iommu: I/O page faults for SMMUv3 Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` [PATCH v10 01/10] iommu: Fix comment for struct iommu_fwspec Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` [PATCH v10 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` [PATCH v10 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` [PATCH v10 04/10] iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-22 1:54 ` Lu Baolu
2021-01-22 1:54 ` Lu Baolu
2021-01-22 1:54 ` Lu Baolu
2021-01-21 12:36 ` [PATCH v10 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` [PATCH v10 06/10] iommu: Add a page fault handler Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` [PATCH v10 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-22 10:35 ` Auger Eric
2021-01-22 10:35 ` Auger Eric
2021-01-22 10:35 ` Auger Eric
2021-01-21 12:36 ` [PATCH v10 08/10] dt-bindings: document stall property for IOMMU masters Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` [PATCH v10 09/10] ACPI/IORT: Enable stall support for platform devices Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 18:57 ` Jonathan Cameron
2021-01-21 18:57 ` Jonathan Cameron
2021-01-21 18:57 ` Jonathan Cameron
2021-01-21 12:36 ` [PATCH v10 10/10] iommu/arm-smmu-v3: Add " Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 12:36 ` Jean-Philippe Brucker
2021-01-21 19:12 ` Jonathan Cameron
2021-01-21 19:12 ` Jonathan Cameron
2021-01-21 19:12 ` Jonathan Cameron
2021-01-22 8:51 ` Jean-Philippe Brucker
2021-01-22 8:51 ` Jean-Philippe Brucker
2021-01-22 8:51 ` Jean-Philippe Brucker
2021-01-22 10:58 ` Jonathan Cameron [this message]
2021-01-22 10:58 ` Jonathan Cameron
2021-01-22 10:58 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210122105832.00002dcb@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=baolu.lu@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=eric.auger@redhat.com \
--cc=guohanjun@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=lenb@kernel.org \
--cc=linux-accelerators@lists.ozlabs.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=sudeep.holla@arm.com \
--cc=vdumpa@nvidia.com \
--cc=vivek.gautam@arm.com \
--cc=will@kernel.org \
--cc=zhangfei.gao@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.