[RFC PATCH V4 6/6] riscv: soc: Add Allwinner SoC kconfig option

[Heinrich Schuchardt]

On 9/14/21 7:16 AM, Samuel Holland wrote:
> On 9/13/21 10:49 PM, Heinrich Schuchardt wrote:
>> Calling a Kconfig menu item "Allwinner SoCs" which includes all
>> future Allwinner SoCs irritates me. How about CONFIG_SOC_SUNXI_D1
>> instead?
> 
> Would you want to have a separate option for each new SoC? That seems
> like the only way to split things up, if you want to be more specific
> than than "sunxi" (or equivalently "sun20i", which is the codename for
> the RISC-V series).
> 
> Except at the very beginning (sun4i-sun7i), there have not been clear
> generational boundaries between the various sunxi SoCs, so most of the
> 32-bit ones already get lumped into a single symbol (MACH_SUN8I). And
> there is a single Kconfig symbol, ARCH_SUNXI, for all 64-bit Allwinner SoCs.

On arm64 we have avoided SoC specific Kconfig symbols and left it to the 
defconfig to select all SoC specific drivers. Generally the tendency of 
the defconfigs is to provide a multiarch kernel. So this should be ok on 
RISC-V too.

I was just concerned about the 8250 driver assigned to something called 
"Allwinner SoCs" which didn't seem future proof.

> 
> There is enough overlap in peripherals that you need a common symbol for
> the peripheral drivers anyway. How about... ARCH_SUNXI? There are 90+
> uses of this symbol throughout drivers/ and sound/, and I have found
> that more than half of them apply to the D1 (see e.g. this commit[1] and
> some of its ancestors).

Looking at the current use of ARCH_SUNXI in drivers reusing the same 
name on RISC-V makes sense.

Best regards

Heinrich

> 
> RISC-V has so far adopted a CONFIG_SOC_xxx naming scheme, which is
> different from arm/arm64's CONFIG_ARCH_xxx pattern. But now we have a
> case where a SoC family is split between the two architectures. I'm all
> for consistency with the names of other RISC-V platform symbols, but it
> seems that reusing the existing ARCH_SUNXI symbol would be better than
> cluttering up the driver Kconfig files with a duplicate.
> 
> Regards,
> Samuel
> 
> [1]: https://github.com/smaeul/linux/commit/7841e5c32366
>