linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steev Klimaszewski <steev@kali.org>
To: Arnd Bergmann <arnd@arndb.de>,
	Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@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: Sun, 10 Oct 2021 23:06:59 -0500	[thread overview]
Message-ID: <e655dd45-7d08-b82b-75b7-a9aa3bd4c50e@kali.org> (raw)
In-Reply-To: <CAK8P3a3irqEVH2e9wCK4MSSBKRW-n8pFSzYBks9ri-hepewkUw@mail.gmail.com>


On 10/10/21 12:42 PM, Arnd Bergmann wrote:
> On Sun, Oct 10, 2021 at 6:17 AM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
>> On Sat 09 Oct 21:33 CDT 2021, Dmitry Baryshkov wrote:
>>
>>> After commit 424953cf3c66 ("qcom_scm: hide Kconfig symbol") arm-smmu got
>>> qcom_smmu_impl_init() call guarded by IS_ENABLED(CONFIG_ARM_SMMU_QCOM).
>>> However the CONFIG_ARM_SMMU_QCOM Kconfig entry does not exist, so the
>>> qcom_smmu_impl_init() is never called.
>>>
>>> So, let's fix this by always calling qcom_smmu_impl_init(). It does not
>>> touch the smmu passed unless the device is a non-Qualcomm one. Make
>>> ARM_SMMU select QCOM_SCM for ARCH_QCOM.
> Sorry about this bug. I was sure I had it working, but I lost part of the commit
> during a rebase, and my randconfig builds still succeeded without it, so I
> sent a wrong version.
>
>> Arnd's intention was to not force QCOM_SCM to be built on non-Qualcomm
>> devices. But as Daniel experienced, attempting to boot most Qualcomm
>> boards without this results in a instant reboot.
>>
>> I think it's okay if we tinker with CONFIG_ARM_SMMU_QCOM for v5.16, but
>> we're getting late in v5.15 so I would prefer if we make sure this works
>> out of the box.
> Yes, makes sense. For reference, see below for how I would fix this properly,
> this is what I had intended to have in the patch. Feel free to pick
> either version
> as the immediate bugfix. I'll give the below a little more randconfig testing
> overnight though. The pasted version of the patch is probably
> whitespace-damaged,
> let me know if you would like me to send it as a proper patch.
>
>         Arnd
>
> 8<-----
> Subject: iommu: fix ARM_SMMU_QCOM compilation
>
> My previous bugfix ended up making things worse for the QCOM IOMMU
> driver when it forgot to add the Kconfig symbol that is getting used to
> control the compilation of the SMMU implementation specific code
> for Qualcomm.
>
> Fixes: 424953cf3c66 ("qcom_scm: hide Kconfig symbol")
> Reported-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ----
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index c5c71b7ab7e8..2dfe744ddd97 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -311,6 +311,7 @@ config ARM_SMMU
>          select IOMMU_API
>          select IOMMU_IO_PGTABLE_LPAE
>          select ARM_DMA_USE_IOMMU if ARM
> +       select QCOM_SCM if ARM_SMMU_QCOM
>          help
>            Support for implementations of the ARM System MMU architecture
>            versions 1 and 2.
> @@ -355,6 +356,13 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
>            'arm-smmu.disable_bypass' will continue to override this
>            config.
>
> +config ARM_SMMU_QCOM
> +       def_bool y
> +       depends on ARM_SMMU && ARCH_QCOM
> +       help
> +         When running on a Qualcomm platform that has the custom variant
> +         of the ARM SMMU, this needs to be built into the SMMU driver.
> +
>   config ARM_SMMU_V3
>          tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
>          depends on ARM64

FWIW, I tested this patch on the Lenovo Yoga C630 with Dmitry's patch 
backed out, and this does the right thing as well.

So if we go this route instead of the other patch, Tested-By: Steev 
Klimaszewski <steev@kali.org>


  reply	other threads:[~2021-10-11  4:07 UTC|newest]

Thread overview: 11+ 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  4:16 ` Bjorn Andersson
2021-10-10 17:42   ` Arnd Bergmann
2021-10-11  4:06     ` Steev Klimaszewski [this message]
2021-10-11  4:11     ` Dmitry Baryshkov
2021-10-11  6:08       ` Arnd Bergmann
2021-10-11  9:09         ` Dmitry Baryshkov
2021-10-11  9:56           ` Arnd Bergmann
2021-10-12  3:34             ` Dmitry Baryshkov
2021-10-12  3:35     ` Dmitry Baryshkov
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=e655dd45-7d08-b82b-75b7-a9aa3bd4c50e@kali.org \
    --to=steev@kali.org \
    --cc=agross@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=dmitry.baryshkov@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 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).