linux-kernel - Resend: Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <tencent_AA20462764AFF185EF405043DBC99119F705@qq.com>
Date: Wed, 6 Mar 2024 01:50:25 +0800
From: Yangyu Chen <cyy@...self.name>
To: Conor Dooley <conor@...nel.org>
Cc: Damien Le Moal <dlemoal@...nel.org>,
 linux-riscv@...ts.infradead.org,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>,
 Albert Ou <aou@...s.berkeley.edu>,
 Guo Ren <guoren@...nel.org>,
 devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 Conor Dooley <conor.dooley@...rochip.com>
Subject: Resend: Re: [PATCH v3 5/7] riscv: Kconfig.socs: Allow SOC_CANAAN with
 MMU for K230

The last email was not received in the list due to I didn’t change the mode
to plaintext. Sorry for that. This is a resend email.

> On Mar 6, 2024, at 01:20, Conor Dooley <conor@...nel.org> wrote:
> 
> On Tue, Mar 05, 2024 at 03:47:15PM +0800, Yangyu Chen wrote:
>> On 2024/3/5 07:46, Damien Le Moal wrote:
>>> On 3/5/24 06:05, Yangyu Chen wrote:
>>>> Since K230 was released, SOC_CANAAN is no longer only referred to the K210.
>>>> Remove it depends on !MMU will allow building dts for K230 and remove the
>>>> K210 string from the help message.
>>>> 
>>>> Signed-off-by: Yangyu Chen <cyy@...self.name>
>>>> Reviewed-by: Conor Dooley <conor.dooley@...rochip.com>
>>>> ---
>>>>  arch/riscv/Kconfig.socs | 5 ++---
>>>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>>> 
>>>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>>>> index 623de5f8a208..b4e9b7f75510 100644
>>>> --- a/arch/riscv/Kconfig.socs
>>>> +++ b/arch/riscv/Kconfig.socs
>>>> @@ -75,13 +75,12 @@ config ARCH_CANAAN
>>>>   def_bool SOC_CANAAN
>>>>  config SOC_CANAAN
>>>> - bool "Canaan Kendryte K210 SoC"
>>>> - depends on !MMU
>>> 
>>> This seems wrong to me. The k210 support does require no-mmu. So why remove
>>> this ?
>> 
>> It just allows SOC_CANAAN to be selected when MMU=y. With this patch,
>> nommu_k210_defconfig still works.
> 
> I think the concern here is that this would allow people to build a
> kernel for the k120 with the MMU enabled, not that the existing nommu
> build will be affected.
> 

Aha. I don't think is there anyone will try a build with MMU on
K210. It only has 6MB of memory available to the CPU. For rv64 if
the S-Mode software starts at 2MB, it will only have 4MB for S-Mode
Linux. It's hard to trim the kernel and fit in 4MB and even preserve
some memory for userspace.

I also tried to make nommu_k210_defconfig on gcc 13.2.0, it produced a
1.6M kernel in arch/riscv/boot/Image. But if I use nconfig to set
CONFIG_MMU=y and rebuild, the kernel file will increase to 11M.

> Maybe you could squash in something like the following?
> 
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index b4e9b7f75510..75d55059163f 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -72,15 +72,19 @@ config SOC_VIRT
>   This enables support for QEMU Virt Machine.
> 
> config ARCH_CANAAN
> - def_bool SOC_CANAAN
> + bool "Canaan Kendryte SoCs"
> + help
> +   This enables support for Canaan Kendryte SoC platform hardware.
> 
> config SOC_CANAAN
> - bool "Canaan Kendryte SoC"
> + bool "Canaan Kendryte K210 SoC"
> + depends on !MMU
> + depends on ARCH_CANAAN
> select CLINT_TIMER if RISCV_M_MODE
> select ARCH_HAS_RESET_CONTROLLER
> select PINCTRL
> select COMMON_CLK
> help
> -   This enables support for Canaan Kendryte SoC platform hardware.
> +   This enables support for Canaan Kendryte K210 SoC platform hardware.
> 
> endmenu # "SoC selection"
> 
> (Which reminds me, I really need to go and finish sorting out the ARCH_
> stuff)

Seems like an idea if we want this consideration. But I don't think we need
this as the opinions shown above.

If it should be, I think SOC_CANAAN should be renamed to SOC_K210 or
SOC_CANAAN_K210.