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: <aR3UGUlqGFvo5aX5@pie>
Date: Wed, 19 Nov 2025 14:28:41 +0000
From: Yao Zi <ziyao@...root.org>
To: Huacai Chen <chenhuacai@...nel.org>,
	Jiaxun Yang <jiaxun.yang@...goat.com>
Cc: 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 03:51:01PM +0800, Huacai Chen wrote:
> 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.

A fake "200MHz" output sounds much worse than obviously wrong "0MHz":
the latter informs the user something bad happened here, while a
mysterious "200MHz" output only makes it more confusing since no one has
specified so in the failing case.

> >
> > >
> > > 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.

But it is an error and shouldn't be ignored. I agree that panic is too
serious for this, but at least a warning should be issued.

> Huacai

Regards,
Yao Zi


> >
> > Thanks
> > --
> > - Jiaxun
> >