Hi Arnd, On Wed, Oct 5, 2022 at 10:58 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Tue, Oct 4, 2022, at 7:42 PM, Conor Dooley wrote: > > On Mon, Oct 03, 2022 at 11:32:22PM +0100, Prabhakar wrote: > >> > >> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > >> --- > >> arch/riscv/include/asm/cacheflush.h | 8 + > >> arch/riscv/include/asm/errata_list.h | 2 + > >> arch/riscv/include/asm/sbi.h | 1 + > >> arch/riscv/mm/dma-noncoherent.c | 20 ++ > > > > Stupid question maybe, but I assume you mixed the driver addition and > > the changes to arch/riscv for the sake of easily creating the RFC? > > > >> drivers/soc/renesas/Makefile | 4 + > >> drivers/soc/renesas/rzf/Makefile | 3 + > >> drivers/soc/renesas/rzf/ax45mp_cache.c | 365 +++++++++++++++++++++++++ > >> drivers/soc/renesas/rzf/rzf_sbi.h | 27 ++ > > My feeling is that L2 cache behavior should live in arch/riscv > rather than drivers/soc/, since this is not specific to a SoC > family but rather the CPU core. I would also expect that the > actual implementation and DT binding can be shared with > non-renesas SoCs using the same CPU core. > Totally agree it is related to the CPU core and not the SoC. During the BoF session it was agreed that unratified extensions code shouldnt go under the arch/riscv. Since the code has vendor specific SBI calls RISC-V maintainers asked to move it SoC specific so that maintenance of the code falls under SoC vendors. Cheers, Prabhakar
