From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Kalle Valo <kvalo@codeaurora.org>,
Thierry Reding <treding@nvidia.com>,
Andy Gross <agross@kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation
Date: Mon, 11 Oct 2021 12:09:21 +0300 [thread overview]
Message-ID: <CAA8EJppAx_bweNhQuQuA5pQkWpyvtYNqttL-fiKgqpJpRqHMKw@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3JwQP1b0KeLRN0UCMmzFn3+gY2oexYUwGyt2bOqC0P4A@mail.gmail.com>
On Mon, 11 Oct 2021 at 09:09, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Oct 11, 2021 at 6:11 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> > On Sun, 10 Oct 2021 at 20:42, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > The patch seems correct, but it becomes overcomplicated. What about:
> > - restoring QCOM_SCM stubs
>
> The stubs are what has led to the previous bugs in this area to often
> go unnoticed for too long, as illustrated by your suggestion
>
> > - making ARM_SMMU select QCOM_SCM if ARM_SMMU_QCOM
>
> I assume you meant "select QCOM_SCM if ARCH_QCOM",
> after we stop using ARM_SMMU_QCOM?
>
> > This would have almost the same result as with your patch, but without
> > extra ARM_SMMU_QCOM Kconfig symbol.
>
> The "almost" is the problem: consider the case of
>
> CONFIG_ARM=y
> CONFIG_COMPILE_TEST=y
> CONFIG_ARCH_QCOM=n
> CONFIG_ARM_SMMU=y
> CONFIG_DRM_MSM=m
> CONFIG_QCOM_SCM=m (selected by DRM_MSM)
>
> The stubs here lead to ARM_SMMU linking against the QCOM_SCM
> driver from built-in code, which fails because QCOM_SCM itself
> is a loadable module.
I see. The idealist in me wishes to change my suggestion to
'select QCOM_SCM if ARCH_QCOM || COMPILE_TEST'
but I have the subtle feeling that this also might fail somehow.
>
> We can move the "select QCOM_SCM" in the ARM_SMMU_QCOM
> symbol if we make that a tristate though, if you want to separate it
> a little more.
This would complicate things a bit, as we would no longer be able to
use 'arm-smmu-$(CONFIG_ARM_SMMU_QCOM) +=' construct.
--
With best wishes
Dmitry
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Andy Gross <agross@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Thierry Reding <treding@nvidia.com>,
Robin Murphy <robin.murphy@arm.com>,
Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation
Date: Mon, 11 Oct 2021 12:09:21 +0300 [thread overview]
Message-ID: <CAA8EJppAx_bweNhQuQuA5pQkWpyvtYNqttL-fiKgqpJpRqHMKw@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3JwQP1b0KeLRN0UCMmzFn3+gY2oexYUwGyt2bOqC0P4A@mail.gmail.com>
On Mon, 11 Oct 2021 at 09:09, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Oct 11, 2021 at 6:11 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> > On Sun, 10 Oct 2021 at 20:42, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > The patch seems correct, but it becomes overcomplicated. What about:
> > - restoring QCOM_SCM stubs
>
> The stubs are what has led to the previous bugs in this area to often
> go unnoticed for too long, as illustrated by your suggestion
>
> > - making ARM_SMMU select QCOM_SCM if ARM_SMMU_QCOM
>
> I assume you meant "select QCOM_SCM if ARCH_QCOM",
> after we stop using ARM_SMMU_QCOM?
>
> > This would have almost the same result as with your patch, but without
> > extra ARM_SMMU_QCOM Kconfig symbol.
>
> The "almost" is the problem: consider the case of
>
> CONFIG_ARM=y
> CONFIG_COMPILE_TEST=y
> CONFIG_ARCH_QCOM=n
> CONFIG_ARM_SMMU=y
> CONFIG_DRM_MSM=m
> CONFIG_QCOM_SCM=m (selected by DRM_MSM)
>
> The stubs here lead to ARM_SMMU linking against the QCOM_SCM
> driver from built-in code, which fails because QCOM_SCM itself
> is a loadable module.
I see. The idealist in me wishes to change my suggestion to
'select QCOM_SCM if ARCH_QCOM || COMPILE_TEST'
but I have the subtle feeling that this also might fail somehow.
>
> We can move the "select QCOM_SCM" in the ARM_SMMU_QCOM
> symbol if we make that a tristate though, if you want to separate it
> a little more.
This would complicate things a bit, as we would no longer be able to
use 'arm-smmu-$(CONFIG_ARM_SMMU_QCOM) +=' construct.
--
With best wishes
Dmitry
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Kalle Valo <kvalo@codeaurora.org>,
Thierry Reding <treding@nvidia.com>,
Andy Gross <agross@kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation
Date: Mon, 11 Oct 2021 12:09:21 +0300 [thread overview]
Message-ID: <CAA8EJppAx_bweNhQuQuA5pQkWpyvtYNqttL-fiKgqpJpRqHMKw@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3JwQP1b0KeLRN0UCMmzFn3+gY2oexYUwGyt2bOqC0P4A@mail.gmail.com>
On Mon, 11 Oct 2021 at 09:09, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Oct 11, 2021 at 6:11 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> > On Sun, 10 Oct 2021 at 20:42, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > The patch seems correct, but it becomes overcomplicated. What about:
> > - restoring QCOM_SCM stubs
>
> The stubs are what has led to the previous bugs in this area to often
> go unnoticed for too long, as illustrated by your suggestion
>
> > - making ARM_SMMU select QCOM_SCM if ARM_SMMU_QCOM
>
> I assume you meant "select QCOM_SCM if ARCH_QCOM",
> after we stop using ARM_SMMU_QCOM?
>
> > This would have almost the same result as with your patch, but without
> > extra ARM_SMMU_QCOM Kconfig symbol.
>
> The "almost" is the problem: consider the case of
>
> CONFIG_ARM=y
> CONFIG_COMPILE_TEST=y
> CONFIG_ARCH_QCOM=n
> CONFIG_ARM_SMMU=y
> CONFIG_DRM_MSM=m
> CONFIG_QCOM_SCM=m (selected by DRM_MSM)
>
> The stubs here lead to ARM_SMMU linking against the QCOM_SCM
> driver from built-in code, which fails because QCOM_SCM itself
> is a loadable module.
I see. The idealist in me wishes to change my suggestion to
'select QCOM_SCM if ARCH_QCOM || COMPILE_TEST'
but I have the subtle feeling that this also might fail somehow.
>
> We can move the "select QCOM_SCM" in the ARM_SMMU_QCOM
> symbol if we make that a tristate though, if you want to separate it
> a little more.
This would complicate things a bit, as we would no longer be able to
use 'arm-smmu-$(CONFIG_ARM_SMMU_QCOM) +=' construct.
--
With best wishes
Dmitry
_______________________________________________
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-10-11 9:09 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-10 2:33 [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation Dmitry Baryshkov
2021-10-10 2:33 ` Dmitry Baryshkov
2021-10-10 2:33 ` Dmitry Baryshkov
2021-10-10 4:16 ` Bjorn Andersson
2021-10-10 4:16 ` Bjorn Andersson
2021-10-10 4:16 ` Bjorn Andersson
2021-10-10 17:42 ` Arnd Bergmann
2021-10-10 17:42 ` Arnd Bergmann
2021-10-10 17:42 ` Arnd Bergmann
2021-10-11 4:06 ` Steev Klimaszewski
2021-10-11 4:06 ` Steev Klimaszewski
2021-10-11 4:06 ` Steev Klimaszewski
2021-10-11 4:11 ` Dmitry Baryshkov
2021-10-11 4:11 ` Dmitry Baryshkov
2021-10-11 4:11 ` Dmitry Baryshkov
2021-10-11 6:08 ` Arnd Bergmann
2021-10-11 6:08 ` Arnd Bergmann
2021-10-11 6:08 ` Arnd Bergmann
2021-10-11 9:09 ` Dmitry Baryshkov [this message]
2021-10-11 9:09 ` Dmitry Baryshkov
2021-10-11 9:09 ` Dmitry Baryshkov
2021-10-11 9:56 ` Arnd Bergmann
2021-10-11 9:56 ` Arnd Bergmann
2021-10-11 9:56 ` Arnd Bergmann
2021-10-12 3:34 ` Dmitry Baryshkov
2021-10-12 3:34 ` Dmitry Baryshkov
2021-10-12 3:34 ` Dmitry Baryshkov
2021-10-12 3:35 ` Dmitry Baryshkov
2021-10-12 3:35 ` Dmitry Baryshkov
2021-10-12 3:35 ` Dmitry Baryshkov
2021-10-10 4:34 ` Steev Klimaszewski
2021-10-10 4:34 ` Steev Klimaszewski
2021-10-10 4:34 ` Steev Klimaszewski
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=CAA8EJppAx_bweNhQuQuA5pQkWpyvtYNqttL-fiKgqpJpRqHMKw@mail.gmail.com \
--to=dmitry.baryshkov@linaro.org \
--cc=agross@kernel.org \
--cc=arnd@arndb.de \
--cc=bjorn.andersson@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kvalo@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=treding@nvidia.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 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.