From: Thierry Reding <thierry.reding@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Prathamesh Shete <pshete@nvidia.com>,
joro@8bytes.org, adrian.hunter@intel.com, ulf.hansson@linaro.org,
jonathanh@nvidia.com, p.zabel@pengutronix.de,
linux-mmc@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, will@kernel.org,
iommu@lists.linux.dev, anrao@nvidia.com, smangipudi@nvidia.com,
kyarlagadda@nvidia.com, Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH v10 1/4] iommu: Always define struct iommu_fwspec
Date: Thu, 3 Nov 2022 15:01:15 +0100 [thread overview]
Message-ID: <Y2PJq27wkVwPg6rp@orome> (raw)
In-Reply-To: <6be39bae-f325-12e0-374b-a27c9ee2ef2b@arm.com>
[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]
On Thu, Nov 03, 2022 at 12:23:20PM +0000, Robin Murphy wrote:
> On 2022-11-03 04:38, Prathamesh Shete wrote:
> > In order to fully make use of the !IOMMU_API stub functions, make the
> > struct iommu_fwspec always available so that users of the stubs can keep
> > using the structure's internals without causing compile failures.
>
> I'm really in two minds about this... fwspecs are an internal detail of the
> IOMMU API that are meant to be private between individual drivers and
> firmware code, so anything poking at them arguably does and should depend on
> CONFIG_IOMMU_API. It looks like the stub for dev_iommu_fwspec_get() was only
> added for the sake of one driver that was misusing it where it really wanted
> device_iommu_mapped(), and has since been fixed, so if anything my
> preference would be to remove that stub :/
Tegra has been using this type of weak dependency on IOMMU_API mainly in
order to allow building without the IOMMU support on some old platforms
where people may actually care about the kernel size (Tegra20 systems
were sometimes severely constrained and don't have anything that we'd
call an IOMMU today).
We have similar stubs in place for most other major subsystems in order
to allow code to simply compile out if the subsystem is disabled, which
is quite convenient for sharing code between platforms that may want a
given feature and other platforms that may not want it, without causing
too much of a hassle with compile-testing.
> I don't technically have much objection to this patch in isolation, but what
> I don't like is the direction of travel it implies. I see the anti-pattern
> is only spread across Tegra drivers, making Tegra-specific assumptions, so
> in my view the best answer would be to abstract that fwpsec dependency into
> a single Tegra-specific helper, which would better represent the nature of
> what's really going on here.
I don't see how this is an anti-pattern. It might not be common for
drivers to need to reach into iommu_fwspec, so that might indeed be
specific to Tegra (for whatever reason our IP seems to want extra
flexibility), but the general pattern of using stubs is wide-spread,
so I don't see why IOMMU_API would need to be special.
Of course we could get rid of the stubs and make these hard
dependencies, but I suspect some people may then get mad that they can
no longer disable the IOMMU dependency.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-11-03 14:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 10:51 [PATCH] iommu: Always define struct iommu_fwspec Thierry Reding
2022-10-20 11:32 ` Ulf Hansson
2022-10-27 9:11 ` Thierry Reding
2022-10-27 12:07 ` Ulf Hansson
2022-10-28 13:02 ` [PATCH v9 1/4] iommu: Add dummy dev_iommu_fwspec_get() helper Prathamesh Shete
2022-10-28 13:02 ` [PATCH v9 2/4] mmc: sdhci-tegra: Separate Tegra194 and Tegra234 SoC data Prathamesh Shete
2022-10-28 13:02 ` [PATCH v9 3/4] mmc: sdhci-tegra: Add support to program MC stream ID Prathamesh Shete
2022-10-28 13:02 ` [PATCH v9 4/4] mmc: sdhci-tegra: Issue CMD and DAT resets together Prathamesh Shete
2022-11-02 15:27 ` [PATCH v9 1/4] iommu: Add dummy dev_iommu_fwspec_get() helper Ulf Hansson
2022-11-03 4:38 ` [PATCH v10 1/4] iommu: Always define struct iommu_fwspec Prathamesh Shete
2022-11-03 4:38 ` [PATCH v10 2/4] mmc: sdhci-tegra: Separate Tegra194 and Tegra234 SoC data Prathamesh Shete
2022-11-03 4:38 ` [PATCH v10 3/4] mmc: sdhci-tegra: Add support to program MC stream ID Prathamesh Shete
2022-11-03 11:30 ` Robin Murphy
2022-11-03 4:38 ` [PATCH v10 4/4] mmc: sdhci-tegra: Issue CMD and DAT resets together Prathamesh Shete
2022-11-03 10:59 ` [PATCH v10 1/4] iommu: Always define struct iommu_fwspec Ulf Hansson
2022-11-03 12:23 ` Robin Murphy
2022-11-03 14:01 ` Thierry Reding [this message]
2022-11-03 14:55 ` Ulf Hansson
2022-11-03 17:35 ` Robin Murphy
2022-11-04 14:35 ` Ulf Hansson
2022-11-07 9:39 ` Thierry Reding
2022-11-04 14:38 ` Thierry Reding
2022-11-07 9:48 ` Thierry Reding
2022-11-03 12:59 ` [PATCH] " Joerg Roedel
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=Y2PJq27wkVwPg6rp@orome \
--to=thierry.reding@gmail.com \
--cc=adrian.hunter@intel.com \
--cc=anrao@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jonathanh@nvidia.com \
--cc=joro@8bytes.org \
--cc=kyarlagadda@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=pshete@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=smangipudi@nvidia.com \
--cc=treding@nvidia.com \
--cc=ulf.hansson@linaro.org \
--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