ppc: inlining iowrite32be and friends (was: Re: [PATCH v2 03/23] soc: fsl: qe: avoid ppc-specific io accessors)

On 29/10/2019 08.43, Christophe Leroy wrote:

Le 25/10/2019 à 14:40, Rasmus Villemoes a écrit :

quoted

In preparation for allowing to build QE support for architectures
other than PPC, replace the ppc-specific io accessors. Done via

$ spatch --sp-file io.cocci --in-place drivers/soc/fsl/qe/

As discussed already, this patch changes io accesors from inline to
outline, this has a performance impact on powerpc32 like 83xx.

Could you please include in your series before this patch a patch to
change generic io accessors to inline on powerpc ?

Well, it's complicated. I was hoping someone could explain why those are
OOL in the first place. The history of arch/powerpc/kernel/iomap.c and
the makefile fragment including it is a bit messy - first of all, the
file itself talks about "ppc64 implementation" but is obviously used for
all ppc32 (while the ppc64 platforms that set PPC_INDIRECT_PIO also get
GENERIC_IOMAP, i.e. lib/iomap.c).

So, what I wanted to do was to make the accessors inline when
!PPC_INDIRECT_PIO && !PPC_INDIRECT_MMIO. But then I need to avoid
including asm-generic/iomap.h, because that declares these as extern.
OTOH, I think I do need some of the declarations from that file, e.g. at
least pci_iounmap, and perhaps also the *_rep versions, unless they
should also be inlined.

I'm happy to give it a try, but I think that belongs in a separate
series. The first few attempts are almost certain to generate some 0day
reports.

Question for powerpc maintainers: Is there a fundamental reason
iowrite32be and friends are out-of-line on PPC32 (more generally, the
PPC platforms that set neither PPC_INDIRECT_PIO or PPC_INDIRECT_MMIO)?
If so, there's no point trying to make them inline, and I'd have to
address Christophe's concern by introducing private qe_iowrite32be()
etc. wrappers.

Thanks,
Rasmus