Re: [PATCH v5 6/6] soc: renesas: Add L2 cache management for RZ/Five SoC

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

On Fri, Dec 16, 2022 at 09:04:20PM +0100, Arnd Bergmann wrote:
> On Fri, Dec 16, 2022, at 17:32, Palmer Dabbelt wrote:
> > On Thu, 15 Dec 2022 23:02:58 PST (-0800), Christoph Hellwig wrote:
> >> On Thu, Dec 15, 2022 at 01:40:30PM -0800, Palmer Dabbelt wrote:
> >>> Given that we already moved the SiFive one out it seems sane to just start
> >>> with the rest in drivers/soc/$VENDOR.  Looks like it was Christoph's idea to
> >>> do the move, so I'm adding him in case he's got an opinion (and also the SOC
> >>> alias, as that seems generally relevant).
> >>
> >> Well, it isn't an integral architecture feature, so it doesn't really
> >> beloing into arch.  Even the irqchip and timer drivers that are more
> >> less architectural are in drivers/ as they aren't really core
> >> architecture code.
> >
> > That makes sense to me, it just looks like the SiFive ccache is the only 
> > one that's in drivers/soc/$VENDOR, the rest are in arch.  It looks like 
> > mostly older ports that have vendor-specific cache files in arch (ie, 
> > arm has it but arm64 doesn't).  Maybe that's just because the newer 
> > architectures sorted out standard ISA interfaces for these and thus 
> > don't need the vendor-specific bits?  I think we're likely to end up 
> > with quite a few of these vendor-specific cache management schemes on 
> > RISC-V.
> >
> > I'm always happy to keep stuff out of arch/riscv, though.  So maybe we 
> > just buck the trend here and stick to drivers/soc/$VENDOR like we did 
> > for the first one?
> 
> I don't particularly like drivers/soc/ to become more of a dumping
> ground for random drivers. If there are several SoCs that have the
> same requirement to do a particular thing, the logical step would
> be to put them into a proper subsystem, with a well-defined interface
> to dma-mapping and virtualization frameworks.
> 
> The other things we have in drivers/soc/ are usually either
> soc_device drivers for identifying the system, or they export
> interfaces used by soc specific drivers.

Sounds like that's two "not in my back yard" votes from the maintainers
in question..
Doing drivers/cache would allow us to co-locate the RISC-V cache
management bits since it is not just going to be the ax45mp l2 driver
that will need to have them.

Would it be okay to put this driver in soc/andestech for now & then move
it, and the SiFive one, once we've got patches posted for cache
management with that?

Thanks,
Conor.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]