On Sun, Jan 22, 2023 at 12:04:35PM +0100, Arnd Bergmann wrote:
> > 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.
>
> I fear the bigger risk is still making the functions callable
> from device driver code than it is to make the functions
> globally settable.
>
> You introduced the mips version in f8c55dc6e828 ("MIPS: use generic
> dma noncoherent ops for simple noncoherent platforms"), which
> was clearly meant as an implementation detail, yet we already
> have a driver that slipped in with 3bdffa8ffb45 ("Input: Add
> N64 controller driver") that just calls this directly rather
> than using the dma-mapping interface.
MIPS actually has a bit of a history of these odd bypasses that
it seems like this driver copied. rmk has been very worried by
this bypassing, and in general I agree. But there's only so
much we can do except for auditing drivers. Especially as none of
these helpers is exported and built-in only drivers are quite rare.
> > 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*
>
> To be fair, from the ISA point of view, it really shouldn't
> be necessary as long as you have a sane SoC design.
> In practice there are always chips that are cutting corners,
> or use the new CPU core as a drop-in for an existing
> design. Arm SBSA tried to enforce the same thing and also
> failed for pretty much the same reason.
Not wiring up IP blocks for cache coherency is cheap. So it totally
makes sense for dirt cheap SOCs, or even for low performance periphals
in general. The GPU folks also believe they can make some things
faster by deliberately turning coherency off on SOCs that support
coherency.
In addition to that cache maintainance is absolutely needed for NVDIMM
support.
