From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Robin Murphy <robin.murphy@arm.com>,
Bjorn Andersson <andersson@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>, Will Deacon <will@kernel.org>,
Joerg Roedel <joro@8bytes.org>, Rob Herring <robh@kernel.org>
Cc: Marijn Suijten <marijn.suijten@somainline.org>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
Johan Hovold <johan+linaro@kernel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: iommu: arm,smmu-v3: Add SC8280XP compatible
Date: Wed, 27 Mar 2024 20:23:51 +0100 [thread overview]
Message-ID: <65669ccc-3d95-496f-aa82-4ecbf4c11290@linaro.org> (raw)
In-Reply-To: <9b2a681e-1191-4cf7-8da7-14aa2c1fa455@arm.com>
On 19.03.2024 2:53 PM, Robin Murphy wrote:
> On 2024-03-09 1:31 pm, Konrad Dybcio wrote:
>> The smmu-v3 binding currently doesn't differentiate the SoCs it's
>> implemented on. This is a poor design choice that may bite in the future,
>> should any quirks surface.
>
> That doesn't seem entirely fair to say - the vast majority of bindings don't have separate compatibles for every known integration of the same implementation in different SoCs. And in this case we don't have per-implementation compatibles for quirks and errata because the implementation is architecturally discoverable from the SMMU_IIDR register.
>
> We have the whole mess for QCom SMMUv2 because the effective *implementation* is a mix of hardware and hypervisor, whose behaviour does seem to vary on almost a per-SoC basis. I'm not at all keen to start repeating that here without very good reason, and that of "documenting" a device which we typically expect to not even be accessible isn't really convincing me...
From my POV as an arch dts maintainer, this often ends up being the only
way to retroactively add some conditional action into the code - the kernel
is supposed to be backwards compatible with older device trees.
And so far it's been almost by luck that all of the smmuv3 implementations
have been a straight copy-and-paste of the reference design (or close enough),
I don't believe this will be for much longer.
Konrad
next prev parent reply other threads:[~2024-03-27 19:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-09 13:31 [PATCH v2 0/2] Describe SC8280XP PCIe SMMU Konrad Dybcio
2024-03-09 13:31 ` [PATCH v2 1/2] dt-bindings: iommu: arm,smmu-v3: Add SC8280XP compatible Konrad Dybcio
2024-03-10 8:46 ` Krzysztof Kozlowski
2024-03-19 13:53 ` Robin Murphy
2024-03-27 19:23 ` Konrad Dybcio [this message]
2024-03-09 13:31 ` [PATCH v2 2/2] arm64: dts: qcom: sc8280xp: Describe the PCIe SMMUv3 Konrad Dybcio
2024-03-18 1:31 ` Bjorn Andersson
2024-03-18 9:21 ` Konrad Dybcio
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=65669ccc-3d95-496f-aa82-4ecbf4c11290@linaro.org \
--to=konrad.dybcio@linaro.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=johan+linaro@kernel.org \
--cc=joro@8bytes.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).