From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>, Yicong Yang <yangyicong@huawei.com>
Cc: mark.rutland@arm.com, prime.zeng@huawei.com,
alexander.shishkin@linux.intel.com, linux-pci@vger.kernel.org,
linuxarm@huawei.com, Yicong Yang <yangyicong@hisilicon.com>,
daniel.thompson@linaro.org, peterz@infradead.org,
mingo@redhat.com, helgaas@kernel.org, liuqi115@huawei.com,
mike.leach@linaro.org, suzuki.poulose@arm.com,
coresight@lists.linaro.org, acme@kernel.org,
zhangshaokun@hisilicon.com, linux-arm-kernel@lists.infradead.org,
mathieu.poirier@linaro.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
iommu@lists.linux-foundation.org, leo.yan@linaro.org
Subject: Re: [PATCH v3 8/8] iommu/arm-smmu-v3: Make default domain type of HiSilicon PTT device to identity
Date: Tue, 15 Feb 2022 13:30:26 +0000 [thread overview]
Message-ID: <9018a1d9-4d42-3a99-dbc6-c55139abcb1e@arm.com> (raw)
In-Reply-To: <20220215130044.GA7154@willie-the-truck>
On 2022-02-15 13:00, Will Deacon wrote:
> On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
>> On 2022/1/24 21:11, Yicong Yang wrote:
>>> The DMA of HiSilicon PTT device can only work with identical
>>> mapping. So add a quirk for the device to force the domain
>>> passthrough.
>>>
>>> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
>>> ---
>>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> index 6dc6d8b6b368..6f67a2b1dd27 100644
>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> @@ -2838,6 +2838,21 @@ static int arm_smmu_dev_disable_feature(struct device *dev,
>>> }
>>> }
>>>
>>> +#define IS_HISI_PTT_DEVICE(pdev) ((pdev)->vendor == PCI_VENDOR_ID_HUAWEI && \
>>> + (pdev)->device == 0xa12e)
>>> +
>>> +static int arm_smmu_def_domain_type(struct device *dev)
>>> +{
>>> + if (dev_is_pci(dev)) {
>>> + struct pci_dev *pdev = to_pci_dev(dev);
>>> +
>>> + if (IS_HISI_PTT_DEVICE(pdev))
>>> + return IOMMU_DOMAIN_IDENTITY;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static struct iommu_ops arm_smmu_ops = {
>>> .capable = arm_smmu_capable,
>>> .domain_alloc = arm_smmu_domain_alloc,
>>> @@ -2863,6 +2878,7 @@ static struct iommu_ops arm_smmu_ops = {
>>> .sva_unbind = arm_smmu_sva_unbind,
>>> .sva_get_pasid = arm_smmu_sva_get_pasid,
>>> .page_response = arm_smmu_page_response,
>>> + .def_domain_type = arm_smmu_def_domain_type,
>>> .pgsize_bitmap = -1UL, /* Restricted during device attach */
>>> .owner = THIS_MODULE,
>>> };
>>>
>>
>> Is this quirk ok with the SMMU v3 driver? Just want to confirm that I'm on the
>> right way to dealing with the issue of our device.
>
> I don't think the quirk should be in the SMMUv3 driver. Assumedly, you would
> have the exact same problem if you stuck the PTT device behind a different
> type of IOMMU, and so the quirk should be handled by a higher level of the
> stack.
Conceptually, yes, but I'm inclined to be pragmatic here. Default domain
quirks could only move out as far as the other end of the call from
iommu_get_def_domain_type() - it's not like we could rely on some flag
in a driver which may not even be loaded yet, let alone matched to the
device. And even then there's an equal and opposite argument for why the
core code should have to maintain a list of platform-specific quirks
rather than code specific to the relevant platforms. The fact is that a
HiSilicon RCiEP is not going to end up behind anything other than a
HiSilicon IOMMU, and if those ever stop being SMMUv3 *and* such a quirk
still exists we can worry about it then.
Ugly as it is, this is the status quo. I don't recall anyone ever
arguing that the equivalent quirks for Intel integrated graphics should
be made generic ;)
Cheers,
Robin.
next prev parent reply other threads:[~2022-02-15 13:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 13:11 [PATCH v3 0/8] Add support for HiSilicon PCIe Tune and Trace device Yicong Yang
2022-01-24 13:11 ` [PATCH v3 1/8] hwtracing: Add trace function " Yicong Yang
2022-02-07 11:42 ` Jonathan Cameron
2022-02-08 11:07 ` Yicong Yang
2022-02-14 12:51 ` Yicong Yang
2022-02-07 18:11 ` John Garry
2022-02-08 8:57 ` Yicong Yang
2022-01-24 13:11 ` [PATCH v3 2/8] hisi_ptt: Register PMU device for PTT trace Yicong Yang
2022-02-07 11:42 ` Jonathan Cameron
2022-02-08 7:41 ` Yicong Yang
2022-01-24 13:11 ` [PATCH v3 3/8] hisi_ptt: Add support for dynamically updating the filter list Yicong Yang
2022-01-24 13:11 ` [PATCH v3 4/8] hisi_ptt: Add tune function support for HiSilicon PCIe Tune and Trace device Yicong Yang
2022-02-07 11:49 ` Jonathan Cameron
2022-02-08 7:08 ` Yicong Yang
2022-01-24 13:11 ` [PATCH v3 5/8] perf tool: Add support for HiSilicon PCIe Tune and Trace device driver Yicong Yang
2022-02-07 11:55 ` Jonathan Cameron
2022-01-24 13:11 ` [PATCH v3 6/8] docs: Add HiSilicon PTT device driver documentation Yicong Yang
2022-02-07 12:12 ` Jonathan Cameron
2022-02-08 11:09 ` Yicong Yang
2022-01-24 13:11 ` [PATCH v3 7/8] MAINTAINERS: Add maintainer for HiSilicon PTT driver Yicong Yang
2022-01-24 13:11 ` [PATCH v3 8/8] iommu/arm-smmu-v3: Make default domain type of HiSilicon PTT device to identity Yicong Yang
2022-02-08 8:05 ` John Garry
2022-02-08 11:21 ` Yicong Yang
2022-02-08 11:56 ` John Garry
2022-02-08 12:20 ` Yicong Yang
2022-02-14 12:55 ` Yicong Yang
2022-02-15 13:00 ` Will Deacon
2022-02-15 13:30 ` Robin Murphy [this message]
2022-02-15 13:42 ` Will Deacon
2022-02-15 14:29 ` Robin Murphy
2022-02-16 9:35 ` Yicong Yang
2022-02-07 9:40 ` [PATCH v3 0/8] Add support for HiSilicon PCIe Tune and Trace device Yicong Yang
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=9018a1d9-4d42-3a99-dbc6-c55139abcb1e@arm.com \
--to=robin.murphy@arm.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=daniel.thompson@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liuqi115@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=prime.zeng@huawei.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yangyicong@hisilicon.com \
--cc=yangyicong@huawei.com \
--cc=zhangshaokun@hisilicon.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).