Re: [RFC PATCH] powerpc: Convert ____flush_dcache_icache_phys() to C

[Christophe Leroy]

Le 22/08/2019 Ã 02:27, Alastair D'Silva a ÃcritÂ:
> On Wed, 2019-08-21 at 22:27 +0200, Christophe Leroy wrote:
> > Le 20/08/2019 Ã 06:36, Alastair D'Silva a Ãcrit :
> > > On Fri, 2019-08-16 at 15:52 +0000, Christophe Leroy wrote:
> >
> > [...]
> >
> > > Thanks Christophe,
> > >
> > > I'm trying a somewhat different approach that requires less
> > > knowledge
> > > of assembler. Handling of CPU_FTR_COHERENT_ICACHE is outside this
> > > function. The code below is not a patch as my tree is a bit messy,
> > > sorry:
> >
> > Can we be 100% sure that GCC won't add any code accessing some
> > global
> > data or stack while the Data MMU is OFF ?
> >
> > Christophe
>
> +mpe
>
> I'm not sure how we would go about making such a guarantee, but I've
> tied every variable used to a register and addr is passed in a
> register, so there is no stack usage, and every call in there only
> operates on it's operands.
>
> The calls to the inline cache helpers (for the PPC32 case) are all
> constants, so I can't see a reasonable scenario where there would be a
> function call and reordered to after the DR bit is turned off, but I
> guess if we want to be paranoid, we could always add an mb() call
> before the DR bit is manipulated to prevent the compiler from
> reordering across the section where the data MMU is disabled.

Anyway, I think the benefit of converting that function to C is pretty 
small. flush_dcache_range() and friends were converted to C mainly in 
order to inline them. But this __flush_dcache_icache_phys() is too big 
to be worth inlining, yet small and stable enough to remain in assembly 
for the time being.

So I suggest you keep it aside your series for now, just move 
PURGE_PREFETCHED_INS inside it directly as it will be the only remaining 
user of it.

Christophe