On Wed, Mar 06, 2024 at 04:14:33PM +0800, Yangyu Chen wrote: > > > > On Mar 6, 2024, at 16:01, Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote: > > > > On Wed, Mar 06, 2024 at 07:38:52AM +0800, Guo Ren wrote: > > > >> On Wed, Mar 6, 2024 at 7:04 AM Yangyu Chen <cyy@xxxxxxxxxxxx> wrote: > >>> > >>> Since we have Canaan Kendryte K230 with MMU now. The use of SOC_CANAAN > >>> is no longer only referred to K210. Split them and add _K210 suffix > >>> to the name for old SOC_CANAAN. And allows ARCH_CANAAN to be selected > >>> for other Canaan SoCs. > >>> > >>> Signed-off-by: Yangyu Chen <cyy@xxxxxxxxxxxx> > >>> --- > >>> arch/riscv/Kconfig.socs | 8 +++++--- > >>> 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, 19 insertions(+), 15 deletions(-) > > > >> This patch cross so many subsystems, I am not sure about it. If I were > >> you, I would keep SOC_CANAAN and just add SOC_CANAAN_K230. > > > > Right. That is why I didn't try to rename the symbol, and just left it > > as SOC_CANAAN, but if the relevant people ack it, the chances of a > > significant conflict are low. > > > > Maybe I should split this patch into different subsystems for better > review. I think at least drivers/soc/Makefile should changed to use > ARCH_CANAAN. Because we need some SoC drivers for K230 in the future. > And arch/riscv/Makefile should use SOC_CANAAN_K210 instead of > ARCH_CANAAN. Because we should avoid the M-Mode loader build for > other Canaan SoCs except for K210. It seems like what Damien requested is pretty much what's done here. Can you resend this CCing the maintainers for clk pinctrl and reset? If you leave a note under the --- line in this patch about wanting acks to take this via riscv, I don't mind picking up this treewide patch if the individual maintainers ack it. I don't think there's likely to be a significant conflict caused by it going through one tree. I got a k230 board (the canmv one) so I should be able to test this myself before picking stuff up. Cheers, Conor.
Attachment:
signature.asc
Description: PGP signature
