Re: [PATCH v1 0/5] riscv: Kconfig.socs: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210

[Conor Dooley]

Yangyu,

And Linus/Stephen/Philipp I guess!

On Fri, Mar 29, 2024 at 01:03:22AM +0800, Yangyu Chen wrote:
> Since SOC_FOO should be deprecated from patch [1], and cleanup for other
> SoCs is already in the mailing list [2,3,4], so we deprecate the use of
> SOC_CANAAN and use ARCH_CANAAN for SoCs vendored by Canaan instead from now
> on.
> 
> However, the K210 SoC is so special for NoMMU and built for loader.bin, if
> we share the ARCH_CANAAN symbol directly for K210 and other new SoCs which
> has MMU and no need for loader, it will confuse some users who may try to
> boot MMU Kernel on K210, but it will fail. Thus, this patch set renamed the
> original use of SOC_CANAAN to SOC_CANAAN_K210 for K210 SoC, as Damien
> suggested from the list [5]. Then, it made some adaptations for soc, clk,
> pinctrl, and reset drivers.
> 
> Note: This patch set is used to prepare for Canaan K230 Support, which is
> on the mailing list [6]. The next revision for the K230 support patch will
> be based on this patch set.

Please, if you don't completely understand what I tell you to do, ask me
to clarify. Asking for more information on what to do is not a problem,
it saves effort for everyone if you ask rather than submit another
version. This patchset has the same sort of problem as was pointed
out on the v5 and v6 of the k230 support.
All patches in this series must go through the same tree, if they don't
then the relevant drivers will not compile in the subsystem trees. As
the new symbol will not be defined there. This is why I said that you
should solicit acks from the subsystem maintainers to take this all via
the soc tree - but you do have to explicitly ask for them! I suggested
doing it under the --- line in each patch, as often maintainers ignore
the parts of a series that do not involve them (I know I do this with
dt-bindings *all* the time).

The only way this works without taking everything via one tree is if we
introduce ARCH_CANAAN for 6.10-rc1, switch every driver subsystem over in
6.11-rc1 and then delete the Kconfig symbol after 6.11-rc1. Although I
also waited with my SOC_FOO symbol removals because I wanted the
ARCH_FOO symbols to propagate into .configs, I followed the process
above so that things could be taken into subsystem trees without
preventing building the drivers.

I'm perfectly happy to take the whole series via the soc tree, but I need
acks on the clk, pinctrl and reset patches before I can do that.

Thanks,
Conor.

> [1] https://lore.kernel.org/linux-riscv/20221121221414.109965-1-conor@xxxxxxxxxx/
> [2] https://lore.kernel.org/linux-riscv/20240305-praying-clad-c4fbcaa7ed0a@spud/
> [3] https://lore.kernel.org/linux-riscv/20240305-fled-undrilled-41dc0c46bb29@spud/
> [4] https://lore.kernel.org/linux-riscv/20240305-stress-earflap-d7ddb8655a4d@spud/
> [5] https://lore.kernel.org/linux-riscv/2b0511af-1b5b-4c90-a673-c9113bb58142@xxxxxxxxxx/
> [6] https://lore.kernel.org/linux-riscv/tencent_F76EB8D731C521C18D5D7C4F8229DAA58E08@xxxxxx/
> 
> Yangyu Chen (5):
>   riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210
>   soc: canaan: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210
>   clk: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
>   pinctrl: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
>   reset: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
> 
>  arch/riscv/Kconfig.socs                        | 10 ++++++++--
>  arch/riscv/Makefile                            |  2 +-
>  arch/riscv/configs/nommu_k210_defconfig        |  3 ++-
>  arch/riscv/configs/nommu_k210_sdcard_defconfig |  3 ++-
>  drivers/clk/Kconfig                            |  4 ++--
>  drivers/pinctrl/Kconfig                        |  4 ++--
>  drivers/reset/Kconfig                          |  4 ++--
>  drivers/soc/Makefile                           |  2 +-
>  drivers/soc/canaan/Kconfig                     |  4 ++--
>  9 files changed, 22 insertions(+), 14 deletions(-)
> 
> -- 
> 2.43.0
>

Attachment: signature.asc
Description: PGP signature