iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: John Garry <john.garry@huawei.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	joro@8bytes.org, will@kernel.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/iova: Fix module config properly
Date: Fri, 16 Sep 2022 11:31:22 +0200	[thread overview]
Message-ID: <YyRCatyU+CWEcDkt@orome> (raw)
In-Reply-To: <bdb9abaf-2703-6d4c-9cab-f6e15e3e8b30@huawei.com>

[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]

On Thu, Sep 15, 2022 at 12:45:43PM +0100, John Garry wrote:
> On 14/09/2022 10:47, Thierry Reding wrote:
> > On Tue, Sep 13, 2022 at 03:15:18PM +0100, Robin Murphy wrote:
> > > On 2022-09-13 14:01, John Garry wrote:
> > > > On 13/09/2022 12:47, Robin Murphy wrote:
> > > > > IOMMU_IOVA is intended to be an optional library for users to select as
> > > > > and when they desire. Since it can be a module now, this means that
> > > > > built-in code which has chosen not to select it should not fail to link
> > > > > if it happens to have selected as a module by someone else. Replace
> > > > > IS_ENABLED() with IS_REACHABLE() to do the right thing.
> > > > 
> > > > Hi Robin,
> > > > 
> > > > Recently you mentioned "I wonder if we couldn't replace the IS_ENABLED()
> > > > with IS_REACHABLE() and restore some of the previously-conditional
> > > > selects", and pointed me to 84db889e6d82 as an example of when a
> > > > conditional select was made unconditional.
> > > > 
> > > > So will you also restore some previously-conditional selects next?
> > > 
> > > I figured I'd leave that up to Thierry (and/or anyone else with a vested
> > > interest), but having mulled it over since that previous thread, there's
> > > really no excuse for the API itself not to do the right thing either way, so
> > > I felt compelled to write up this much.
> > 
> > On Tegra specifically, as the commit message says, we don't really care
> > about the conditional selection because practically we always want IOMMU
> > support enabled. So instead of adding back the conditional select it
> > would make more sense to select IOMMU_API instead and then get rid of
> > the handful of #ifdef blocks we have for that.
> 
> Out of curiosity, does the same go to host1x, whose kconfig got the same
> treatment as tegra with regards to selecting IOMMU_IOVA? I mean, will you
> not go back to conditionally selecting IOMMU_IOVA, and instead select
> IOMMU_API and IOMMU_IOVA always?

Yeah, I suspect that that will happen eventually. People would still
have the option of disabling runtime IOMMU support by disabling the
IOMMU via DT, for example, so if they really care about that last bit
of performance, they do have that option.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-09-16  9:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-13 11:47 [PATCH] iommu/iova: Fix module config properly Robin Murphy
2022-09-13 13:01 ` John Garry
2022-09-13 14:15   ` Robin Murphy
2022-09-14  9:47     ` Thierry Reding
2022-09-15 11:45       ` John Garry
2022-09-16  9:31         ` Thierry Reding [this message]
2022-09-14  9:48 ` Thierry Reding
2022-09-26 11:31 ` 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=YyRCatyU+CWEcDkt@orome \
    --to=thierry.reding@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=john.garry@huawei.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.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 NNTP newsgroup(s).