[PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults

[Thierry Reding]

On Wed, Jun 02, 2021 at 12:40:49PM +0100, Will Deacon wrote:
> On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote:
> > On 02/06/2021 10:52, Thierry Reding wrote:
> > > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote:
> > >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote:
> > >>> On 01/06/2021 20:08, Thierry Reding wrote:
> > >>>> On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:
> > >>>>> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:
> > >>>>>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:
> > >>>>>>> From: Thierry Reding <treding at nvidia.com>
> > >>>>>>>
> > >>>>> Probably best if I queue 3-6 on a separate branch once you send a v3,
> > >>>>> then Krzysztof can pull that in if he needs it.
> > >>>>
> > >>>> Patch 5 has a build-time dependency on patch 1, so they need to go in
> > >>>> together. The reason why I suggested Krzysztof pick these up is because
> > >>>> there is a restructuring series that this depends on, which will go into
> > >>>> Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other
> > >>>> and mostly unrelated stuff as well.
> > >>>
> > >>> I missed that part... what other series are needed for this one? Except
> > >>> Dmitry's power management set I do not have anything in my sight for
> > >>> Tegras memory controllers.
> > >>>
> > >>> Anyway, I can take the memory bits and provide a stable tag with these.
> > >>> Recently there was quite a lot work around Tegra memory controllers, so
> > >>> this makes especially sense if new patches appear.
> > >>
> > >> OK, I think I have now the patchset you talked about - "memory: tegra:
> > >> Driver unification" v2, right?
> > > 
> > > Yes, that's the one. That series is fairly self-contained, but Dmitry's
> > > power management set has dependencies that pull in the regulator, clock
> > > and ARM SoC trees.
> > > 
> > > I did a test merge of the driver unification series with a branch that
> > > has Dmitry's patches and all the dependencies and there are no conflicts
> > > so that, fortunately, doesn't further complicates things.
> > > 
> > > Do you want me to send you a pull request with Dmitry's memory
> > > controller changes? You could then apply the unification series on top,
> > > which should allow this SMMU series to apply cleanly on top of that.
> > 
> > Makes sense and it looks quite bulletproof for future changes. Let's do
> > like this. I will apply your patch 1/10 from this v2 on top of it and
> > driver unification later.
> 
> Okey doke. Thierry -- please let me know which patches I can queue. Having
> the SMMU driver changes in the IOMMU tree really helps in case of conflicts
> with other SMMU changes. As I say, I can put stuff on a separate branch for
> you if it helps.

Given that the SMMU patches have a build-time dependency on the first
patch in the series, and the series depends on the unification series, I
think Krzysztof would have to pull the memory controller branch that I
have with Dmitry's work, apply the unification series on top and then
take patch 1 of this series on top of that. That's the state that you'd
have to pull into the SMMU tree to get the right dependencies.

The SMMU pieces are the leaf of the dependency tree, so technically no
separate branch is needed, because I don't think anybody would have to
pull from it. However, a separate branch might make it easier to back
any of this work out if we have to.

Krzysztof, I do plan on sending out a v3 of the unification series to
address the two cleanups that Dmitry and you have pointed out. After
that I can send out v3 of this series to fix the ordering issue that
Krishna had mentioned. After all of those are applied, would you be able
to provide a stable branch for Will's SMMU tree?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210602/cb70335e/attachment.sig>