linux-kernel - Re: [PATCH v2] LoongArch: Remove LOONGARCH

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] [day] [month] [year] [list]

Message-ID: <CAAhV-H4DcfChTDtE+y926Taynwcz5wkpRa9+L4JBgCTbZjJkRw@mail.gmail.com>
Date:   Fri, 22 Jul 2022 15:48:50 +0800
From:   Huacai Chen <chenhuacai@...nel.org>
To:     WANG Xuerui <kernel@...0n.name>
Cc:     Tiezhu Yang <yangtiezhu@...ngson.cn>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        loongarch@...ts.linux.dev, LKML <linux-kernel@...r.kernel.org>,
        Jianmin Lv <lvjianmin@...ngson.cn>
Subject: Re: [PATCH v2] LoongArch: Remove LOONGARCH_CPUCFG48 and some CSR definitions

Hi, all,

On Fri, Jul 22, 2022 at 3:34 PM WANG Xuerui <kernel@...0n.name> wrote:
>
> On 2022/7/22 14:58, Tiezhu Yang wrote:
> >
> >
> > On 07/20/2022 04:32 PM, Tiezhu Yang wrote:
> >> According to the configuration information accessible by the CPUCFG
> >> instruction [1] and the Overview of Control and Status Registers [2],
> >> we can not see the descriptions about LOONGARCH_CPUCFG48 (0x30),
> >> LOONGARCH_CSR_PRID (0xc0), LOONGARCH_CSR_MCSR* (0xc0 ~ 0xff) and
> >> LOONGARCH_CSR_UCAWIN* (0x100 ~ 0x109), they are not used in the
> >> current kernel code.
> >>
> >> LOONGARCH_CPUCFG48 may be used only in the firmware layer, it should
> >> not be used in the future for kernel developers, remove the related
> >> LOONGARCH_CPUCFG48 definitions.
> >>
> >> LOONGARCH_CSR_MCSR* is shadow of LOONGARCH_CPUCFG*, no need to access
> >> LOONGARCH_CSR_MCSR* and LOONGARCH_CSR_PRID through CSR instruction,
> >> use CPUCFG instruction to access LOONGARCH_CPUCFG* is enough, so also
> >> remove LOONGARCH_CSR_MCSR* and LOONGARCH_CSR_PRID definitions.
> >>
> >> LOONGARCH_CSR_UCAWIN* may be not implemented in hardware, use CSR
> >> instruction to access them is meaningless, so also remove the related
> >> LOONGARCH_CSR_UCAWIN* definitions.
> >>
> >> The intention of this patch is to keep consistent between the code and
> >> the manual.
> >>
> >> [1]
> >> https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#the-configuration-information-accessible-by-the-cpucfg-instruction
> >> [2]
> >> https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#table-overview-of-control-and-status-registers
> >>
> >> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
> >> ---
> >>
> >> v2:
> >>   -- Remove LOONGARCH_CSR_PRID and LOONGARCH_CSR_UCAWIN*
> >>   -- Modify the patch subject and update the commit message
> >>
> >>  arch/loongarch/include/asm/loongarch.h | 229
> >> ---------------------------------
> >>  1 file changed, 229 deletions(-)
> >> Hi all,
> >
> > Are you OK with this change? Any comments will be much appreciated.
>
> Sorry for not getting to this earlier; $DAY_JOB is taking its toll on my
> Linux contributions these days.
>
> IMO, it's probably better to keep the definitions for documentation
> purposes.
>
> As a Loongson employee, you may be aware of the fact that your company's
> "official" documentation is often lacking, and this information you're
> removing is not found elsewhere. So for preserving this knowledge,
> either (1) ask your documentation people to properly record these
> information in official docs then you can go ahead removing them here,
> or (2) just keep the content here if (1) isn't doable for any reason.
> You do want 3rd-parties to freely develop on your platforms, making full
> use of the products' capabilities, don't you? ;-)
I agree with Xuerui, and I have already had an offline discussion with
Tiezhu about why we want to keep it.
There are various drivers that provide large register definitions, the
most notable one is amdgpu (their registers are obviously not "all in
use"), you can see drivers/gpu/drm/amd/amdgpu/sid.h as an example.

Regards,
Huacai

>
>