Messages in this thread | | | Subject | Re: [RFC PATCH] powerpc: Convert ____flush_dcache_icache_phys() to C | From | Christophe Leroy <> | Date | Thu, 22 Aug 2019 07:06:03 +0200 |
| |
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
| |