On Fri, Feb 28, 2020 at 10:25:56AM +0000, Andre Przywara wrote: > On Fri, 28 Feb 2020 10:04:47 +0000 > Will Deacon <[email protected]> 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 <[email protected]> wrote: > > > > > > > > On Tue, Feb 18, 2020 at 11:13:16AM -0600, Rob Herring wrote: > > > > > Cc: Will Deacon <[email protected]> > > > > > Cc: Robin Murphy <[email protected]> > > > > > Cc: Joerg Roedel <[email protected]> > > > > > Cc: [email protected] > > > > > Signed-off-by: Rob Herring <[email protected]> > > > > > --- > > > > > 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 _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
