Re: [PATCH v2 1/4] RISC-V: Fix ioremap_cache() and ioremap_wc() for systems with Svpbmt

[Palmer Dabbelt]

On Fri, 23 Sep 2022 03:35:50 PDT (-0700), Arnd Bergmann wrote:
> On Thu, Sep 22, 2022, at 6:35 PM, Palmer Dabbelt wrote:
> > On Thu, 15 Sep 2022 19:24:55 PDT (-0700), apatel@xxxxxxxxxxxxxxxx wrote:
> > > On Tue, Aug 30, 2022 at 10:17 AM Anup Patel <apatel@xxxxxxxxxxxxxxxx> wrote:
> > > > Currently, all flavors of ioremap_xyz() function maps to the generic
> > > > ioremap() which means any ioremap_xyz() call will always map the
> > > > target memory as IO using _PAGE_IOREMAP page attributes. This breaks
> > > > ioremap_cache() and ioremap_wc() on systems with Svpbmt because memory
> > > > remapped using ioremap_cache() and ioremap_wc() will use _PAGE_IOREMAP
> > > > page attributes.
> > > >
> > > > To address above (just like other architectures), we implement RISC-V
> > > > specific ioremap_cache() and ioremap_wc() which maps memory using page
> > > > attributes as defined by the Svpbmt specification.
> > > >
> > > > Fixes: ff689fd21cb1 ("riscv: add RISC-V Svpbmt extension support")
> > > > Co-developed-by: Mayuresh Chitale <mchitale@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Mayuresh Chitale <mchitale@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Anup Patel <apatel@xxxxxxxxxxxxxxxx>
> > >
> > > This is a crucial RC fix. Can you please take this ?
> >
> > Sorry I missed this, I thought it was just part of the rest of this
> > patch set.  That said, I'm not actually sure this is a critical fix:
> > sure it's a performance problem, and if some driver is expecting
> > ioremap_cache() to go fast then possibly a pretty big one, but the only
> > Svpmbt hardware that exists is the D1 and that was just supported this
> > release so it's not a regression.  Maybe that's a bit pedantic, but all
> > this travel has kind of made things a mess and I'm trying to make sure
> > nothing goes off the rails.
>
> I think generally speaking any use of ioremap_cache() in a driver
> is a mistake. The few users that exist are usually from historic
> x86 specific code and are hard to kill off.

Should we just add some sort of CONFIG_ARCH_HAS_IOREMAP_CACHE and then 
ban those drivers from everywhere else?