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

Message-ID: <CAAhV-H7OFnEjen0B6JbBvjrcgNDnOsXqKV1wp7KaRxKjkRYfrg@mail.gmail.com>
Date: Wed, 19 Nov 2025 22:43:21 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Yao Zi <ziyao@...root.org>
Cc: Jiaxun Yang <jiaxun.yang@...goat.com>, 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 10:29 PM Yao Zi <ziyao@...root.org> wrote:
>
> 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.
All CPU freq in QEMU TCG is fake, even if it is provided by DTS. But
if someone fixes QEMU, I'm happy to remove this part.

>
> > >
> > > >
> > > > 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.
Yes, it is better to add a warning.


Huacai
>
> > Huacai
>
> Regards,
> Yao Zi
>
>
> > >
> > > Thanks
> > > --
> > > - Jiaxun
> > >
>