Re: [PATCH 1/7] cache: ax45mp_cache: refactor cache driver for generic Andes platform support

[Conor Dooley <conor@kernel.org>]

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

On Wed, Apr 01, 2026 at 10:30:41AM +0800, Mina Chou wrote:
> Thank you both, Krzysztof and Conor, for the detailed review.
> I appreciate the feedback and admit this series needed more work
> before sending. I will address all the issues in the next version.

People making mistakes is whatever, as long as they don't keep making
them!

> A bit of background on the motivation: the main goal of this series
> was to prepare the Andes cache driver for a SoC Allwinner Avaotaf1 V821,
> which uses the Andes A27L2 CPU. We wanted to share a single cache driver
> across different Andes CPU variants, which is why we tried to move toward

I don't mind the kernel-side renaming all that much, the compatible
rename is what's problematic.

> more generic naming in both the driver and the compatible strings.
>  
> We have two questions we'd appreciate guidance on:
>   a) On compatible string naming: We'll drop patch [5/7][6/7] and won't
>      rename any existing compatible strings. But we'd like to confirm
>      the preferred approach for A27L2: would it be acceptable to add
>      a generic compatible (andestech,andes-llcache) as an addition?

>      If so, would a CPU-specific compatible (andestech,a27l2-cache)
>      still be required alongside it?

Yes. I think that this cpu-specific compatible is what actually has
value, and adding something generic to all andes CPUs is a "nice to
have" convenience. Also, "andestech,andes-llcache" is a bit of a weak
name, repeating "andes" has no value. There's no code-name or something
for the IP that we could use instead of the second "andes" here?

>   b) On Avaotaf1 V821 support: We are not in a position to submit the
>      DTS on behalf of Allwinner. However, we would like to add the
>      corresponding compatible strings to the existing binding
>      documents (andestech,andes-llcache.yaml, sifive,plic-1.0.0.yaml,
>      and riscv/cpus.yaml) in advance, so that the bindings are ready
>      when Allwinner eventually submits their DTS.

>      Would it be acceptable to upstream binding-only changes without
>      an accompanying DTS at this stage?

Yes, of course. You're not willing to submit the dts, which is
understandable, but for the cache and plic bindings, you are able to add
the soc-specific compatibles for this device, right?

> For the next version, we're thinking of keeping only the changes
> needed to generalize the cache driver, and dropping the improvements
> for now to keep things focused. If you have any suggestion on how
> to approach this, we'd love to hear it.

Whatever you want. The improvements (or at least the things I think
are improvements) seem worth having. The problem was just patches doing
multiple things at once. If you decide to only do the generalisation,
that's fine, just make sure it is broken down so that each of your
bullet points in the commit messages.

Cheers,
Conor.

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