Re: [RFC PATCH 06/11] iommu: arm-smmu: Remove Calxeda secure mode quirk

[Will Deacon <will@kernel.org>]

On Fri, Feb 28, 2020 at 10:25:56AM +0000, Andre Przywara wrote:
> On Fri, 28 Feb 2020 10:04:47 +0000
> Will Deacon <will@kernel.org> wrote:
> 
> Hi,
> 
> > On Tue, Feb 25, 2020 at 04:01:54PM -0600, Rob Herring wrote:
> > > On Tue, Feb 18, 2020 at 11:20 AM Will Deacon <will@kernel.org> wrote:  
> > > >
> > > > On Tue, Feb 18, 2020 at 11:13:16AM -0600, Rob Herring wrote:  
> > > > > Cc: Will Deacon <will@kernel.org>
> > > > > Cc: Robin Murphy <robin.murphy@arm.com>
> > > > > Cc: Joerg Roedel <joro@8bytes.org>
> > > > > Cc: iommu@lists.linux-foundation.org
> > > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > > ---
> > > > > Do not apply yet.  
> > > >
> > > > Pleeeeease? ;)
> > > >  
> > > > >  drivers/iommu/arm-smmu-impl.c | 43 -----------------------------------
> > > > >  1 file changed, 43 deletions(-)  
> > > >
> > > > Yes, I'm happy to get rid of this. Sadly, I don't think we can remove
> > > > anything from 'struct arm_smmu_impl' because most implementations fall
> > > > just short of perfect.
> > > >
> > > > Anyway, let me know when I can push the button and I'll queue this in
> > > > the arm-smmu tree.  
> > > 
> > > Seems we're leaving the platform support for now, but I think we never
> > > actually enabled SMMU support. It's not in the dts either in mainline
> > > nor the version I have which should be close to what shipped in
> > > firmware. So as long as Andre agrees, this one is good to apply.  
> > 
> > Andre? Can I queue this one for 5.7, please?
> 
> I was wondering how much of a pain it is to keep it in? AFAICS there are
> other users of the "impl" indirection. If those goes away, I would be
> happy to let Calxeda go.

The impl stuff is new, so we'll keep it around. The concern is more about
testing (see below).

> But Eric had the magic DT nodes to get the SMMU working, and I used that
> before, with updating the DT either on flash or dynamically via U-Boot.

What did you actually use the SMMU for, though? The
'arm_iommu_create_mapping()' interface isn't widely used and, given that
highbank doesn't support KVM, the use-cases for VFIO are pretty limited
too.

> So I don't know exactly *how* desperate you are with removing this, or if
> there are other reasons than "negative diffstat", but if possible I would
> like to keep it in.

It's more that we *do* make quite a lot of changes to the arm-smmu driver
and it's never tested with this quirk. If you're stepping up to run smmu
tests on my queue for each release on highbank, then great, but otherwise
I'd rather not carry the code for fun. The change in diffstat is minimal
(we're going to need to hooks for nvidia, who broke things in a different
way).

Also, since the hooks aren't going away, if you /do/ end up using the SMMU
in future, then we could re-add the driver quirk without any fuss.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel