From: Will Deacon <will@kernel.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>,
linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
Patrick Daly <pdaly@codeaurora.org>,
Pratik Patel <pratikp@codeaurora.org>,
Rob Clark <robdclark@gmail.com>,
treding@nvidia.com
Subject: Re: [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb
Date: Wed, 8 Jan 2020 09:16:42 +0000 [thread overview]
Message-ID: <20200108091641.GA15147@willie-the-truck> (raw)
In-Reply-To: <20191226221709.3844244-1-bjorn.andersson@linaro.org>
On Thu, Dec 26, 2019 at 02:17:06PM -0800, Bjorn Andersson wrote:
> These patches implements the stream mapping inheritance that's necessary in
> order to not hit a security violation as the display hardware looses its stream
> mapping during initialization of arm-smmu in various Qualcomm platforms.
>
> This was previously posted as an RFC [1], changes since then involves the
> rebase and migration of the read-back code to the Qualcomm specific
> implementation, the mapping is maintained indefinitely - to handle probe
> deferring clients - and rewritten commit messages.
I don't think we should solve this in a Qualcomm-specific manner. Please can
you take a look at the proposal from Thierry [1] and see whether or not it
works for you?
Thanks,
Will
[1] https://lore.kernel.org/lkml/20191209150748.2471814-1-thierry.reding@gmail.com
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Patrick Daly <pdaly@codeaurora.org>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, treding@nvidia.com,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org,
Pratik Patel <pratikp@codeaurora.org>
Subject: Re: [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb
Date: Wed, 8 Jan 2020 09:16:42 +0000 [thread overview]
Message-ID: <20200108091641.GA15147@willie-the-truck> (raw)
In-Reply-To: <20191226221709.3844244-1-bjorn.andersson@linaro.org>
On Thu, Dec 26, 2019 at 02:17:06PM -0800, Bjorn Andersson wrote:
> These patches implements the stream mapping inheritance that's necessary in
> order to not hit a security violation as the display hardware looses its stream
> mapping during initialization of arm-smmu in various Qualcomm platforms.
>
> This was previously posted as an RFC [1], changes since then involves the
> rebase and migration of the read-back code to the Qualcomm specific
> implementation, the mapping is maintained indefinitely - to handle probe
> deferring clients - and rewritten commit messages.
I don't think we should solve this in a Qualcomm-specific manner. Please can
you take a look at the proposal from Thierry [1] and see whether or not it
works for you?
Thanks,
Will
[1] https://lore.kernel.org/lkml/20191209150748.2471814-1-thierry.reding@gmail.com
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Rob Clark <robdclark@gmail.com>,
Patrick Daly <pdaly@codeaurora.org>,
linux-arm-msm@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
treding@nvidia.com, Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org,
Pratik Patel <pratikp@codeaurora.org>
Subject: Re: [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb
Date: Wed, 8 Jan 2020 09:16:42 +0000 [thread overview]
Message-ID: <20200108091641.GA15147@willie-the-truck> (raw)
In-Reply-To: <20191226221709.3844244-1-bjorn.andersson@linaro.org>
On Thu, Dec 26, 2019 at 02:17:06PM -0800, Bjorn Andersson wrote:
> These patches implements the stream mapping inheritance that's necessary in
> order to not hit a security violation as the display hardware looses its stream
> mapping during initialization of arm-smmu in various Qualcomm platforms.
>
> This was previously posted as an RFC [1], changes since then involves the
> rebase and migration of the read-back code to the Qualcomm specific
> implementation, the mapping is maintained indefinitely - to handle probe
> deferring clients - and rewritten commit messages.
I don't think we should solve this in a Qualcomm-specific manner. Please can
you take a look at the proposal from Thierry [1] and see whether or not it
works for you?
Thanks,
Will
[1] https://lore.kernel.org/lkml/20191209150748.2471814-1-thierry.reding@gmail.com
_______________________________________________
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:[~2020-01-08 9:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-26 22:17 [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb Bjorn Andersson
2019-12-26 22:17 ` Bjorn Andersson
2019-12-26 22:17 ` Bjorn Andersson
2019-12-26 22:17 ` [PATCH 1/3] iommu/arm-smmu: Don't blindly use first SMR to calculate mask Bjorn Andersson
2019-12-26 22:17 ` Bjorn Andersson
2019-12-26 22:17 ` Bjorn Andersson
2019-12-26 22:17 ` [PATCH 2/3] iommu/arm-smmu: Expose s2cr and smr structs to impl Bjorn Andersson
2019-12-26 22:17 ` Bjorn Andersson
2019-12-26 22:17 ` Bjorn Andersson
2019-12-26 22:17 ` [PATCH 3/3] iommu/arm-smmu: Allow inherting stream mapping from bootloader Bjorn Andersson
2019-12-26 22:17 ` Bjorn Andersson
2019-12-26 22:17 ` Bjorn Andersson
2020-01-08 9:16 ` Will Deacon [this message]
2020-01-08 9:16 ` [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb Will Deacon
2020-01-08 9:16 ` Will Deacon
2021-05-24 12:03 ` Lee Jones
2021-05-24 12:48 ` Robin Murphy
2021-05-24 12:48 ` Robin Murphy
2021-05-24 12:48 ` Robin Murphy
2021-05-25 3:28 ` Bjorn Andersson
2021-05-25 3:28 ` Bjorn Andersson
2021-05-25 3:28 ` Bjorn Andersson
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=20200108091641.GA15147@willie-the-truck \
--to=will@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pdaly@codeaurora.org \
--cc=pratikp@codeaurora.org \
--cc=robdclark@gmail.com \
--cc=robin.murphy@arm.com \
--cc=treding@nvidia.com \
/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.