linux-kernel - Re: [PATCH V2 04/14] LoongArch: Adjust boot & setup for 32BIT/64BIT

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: <CAAhV-H6aM+nsK39iTDw1Fec25C7+D2UTh92X6FPf3gDouuyejQ@mail.gmail.com>
Date: Wed, 19 Nov 2025 15:51:01 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
Cc: Yao Zi <ziyao@...root.org>, Huacai Chen <chenhuacai@...ngson.cn>, 
	Arnd Bergmann <arnd@...db.de>, f@...root.org, loongarch@...ts.linux.dev, 
	linux-arch@...r.kernel.org, Xuefeng Li <lixuefeng@...ngson.cn>, 
	Guo Ren <guoren@...nel.org>, Xuerui Wang <kernel@...0n.name>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 04/14] LoongArch: Adjust boot & setup for 32BIT/64BIT

On Wed, Nov 19, 2025 at 2:03 PM Jiaxun Yang <jiaxun.yang@...goat.com> wrote:
>
>
>
> On Wed, 19 Nov 2025, at 12:28 PM, Huacai Chen wrote:
> [...]
> >> Per the schema for LoongArch CPUs (loongarch/cpus.yaml), "clocks"
> >> property is also described as mandantory, thus I don't think such
> >> fallback makes sense.
> > Yes, "clocks" is mandatory in theory, but sometimes is missing in
> > practice, at least in QEMU. On the other hand, if "clocks" really
> > always exist, then the error checking in fdt_cpu_clk_init() can also
> > be removed. So the fallback makes sense.
>
> IMHO this should be fixed on QEMU side, but I recall QEMU do have clock
> supplied in generic fdt?
It is difficult to fix, you can have a try. :)
If without fallback, cpuinfo shows 0MHz now.

>
> >
> > Why pick 200MHz? That is because we assume the constant timer is
> > 100MHz (which is true for all real machines), 200MHz is the minimal
> > multiple of 100MHz, it is more reasonable than 0MHz.
>
> Maybe better panic here :-)
No, this is not a fatal error, we don't need to treat everything as
fatal. As you know, many "BUG_ON" have been replaced with "WARN_ON" in
kernel.

Huacai

>
> Thanks
> --
> - Jiaxun
>