Re: [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb

2021-05-24 Thread Bjorn Andersson
On Mon 24 May 07:03 CDT 2021, Lee Jones wrote:

> On Wed, 8 Jan 2020 at 09:16, Will Deacon  wrote:
> 
> > 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?
> >
> 
> Did this or Thierry's solution ever gain traction?
> 

There was a few pieces that landed in the common code which allowed us
to deal with the quirks of the Qualcomm platform (turned out that just
reading back the settings wasn't the only piece necessary).

The "generic" solution is essentially the second half of
qcom_smmu_cfg_probe(), which ensures that as the SMMU is reset it will
do so with bypass mappings for all stream mappings the boot loader left
us.

> Or are all the parties still 'solving' this downstream?
> 

I believe that Qualcomm has adopted the upstream solution in their
downstream kernel.

Regards,
Bjorn
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb

2021-05-24 Thread Robin Murphy

On 2021-05-24 13:03, Lee Jones wrote:

On Wed, 8 Jan 2020 at 09:16, Will Deacon  wrote:


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?



Did this or Thierry's solution ever gain traction?

Or are all the parties still 'solving' this downstream?


I think this particular series is what eventually ended up upstream as 
07a7f2caaa5a and f9081b8ff593 (plus a couple of tweaks later). Progress 
is slow on the more general solution, but still happening - I see there 
was a new version recently which I've not had time to properly look at yet.


Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb

2021-05-24 Thread Lee Jones
On Wed, 8 Jan 2020 at 09:16, Will Deacon  wrote:

> 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?
>

Did this or Thierry's solution ever gain traction?

Or are all the parties still 'solving' this downstream?


> Thanks,
>
> Will
>
> [1]
> https://lore.kernel.org/lkml/20191209150748.2471814-1-thierry.red...@gmail.com
>


-- 
Lee Jones [李琼斯]
Linaro Services Senior Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 0/3] iommu/arm-smmu: Qualcomm bootsplash/efifb

2020-01-08 Thread Will Deacon
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.red...@gmail.com
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu