On Sat, Jan 21, 2023 at 08:30:23PM +0100, Arnd Bergmann wrote: > > That feels really odd, and might be worth a bug report to the > > PPC maintainers. > > Right, my first step would be to change all of the current > outliers to use the same set of operations where possible. Sounds good. > > I'd rather avoid multiple callbacks if we can. But maybe solve > > the simple problem first and just pass the paddr and then > > iterate from there. > > Ok, fair enough. This means we can't easily put the kmap_atomic() > into common code for highmem, though the per-page loop would > still work. Yes. Given how messy many of the ops are I think one step at a time is always good. > I was thinking of using STATIC_CALL() as an optimization here, which > I find easier to read and understand than alternatives. One advantage > here is that this allows the actual cache operations to be declared > locally in the architecture without letting drivers call them, > but still update the common code to work without indirect branches. > > The main downside is that this is currently only optimized on > powerpc and x86, both of which don't actually need CPU specific > callbacks. ARC, ARM, and MIPS on the other hand already > have indirect function pointers, RISC-V would likely benefit the > most from either alternatives or static_call, as it already > uses alternatives and has one implementation that is clearly > preferred over the others. For now I'd just keep doing direct calls into the arch code, just for the lower level invalidate, writeback, invalidate+writeback calls as that helps cementinc the logic of which of those to use in well documented core code. And I'm not really sure I'd like to go beyond that - making it too easy pluggable will make people feel more comfortable doing stupid things here. And yes, maybe that's personal because I've warned the RISC-V people years ago that they'll need architectural cache management instructions yesterday and the answer was that no one is going to use them on modern CPUs. *sigh*
