Re: [PATCH V7 0/2] qcom: x1e80100: Enable CPUFreq

[Marc Zyngier]

On Tue, 05 Nov 2024 16:57:07 +0000,
Johan Hovold <johan@xxxxxxxxxx> wrote:
> 
> On Fri, Nov 01, 2024 at 02:43:57PM +0000, Marc Zyngier wrote:
> > On Fri, 01 Nov 2024 14:19:54 +0000,
> > Johan Hovold <johan@xxxxxxxxxx> wrote:
> 
> > > The side-effects and these remaining warnings are addressed by this
> > > series:
> > > 
> > > 	https://lore.kernel.org/all/20241030125512.2884761-1-quic_sibis@xxxxxxxxxxx/
> > > 
> > > but I think we should try to make the warnings a bit more informative
> > > (and less scary) by printing something along the lines of:
> > > 
> > > 	arm-scmi arm-scmi.0.auto: [Firmware Bug]: Ignoring duplicate OPP 3417600 for NCC
> > > 
> > > instead.
> > 
> > Indeed. Seeing [Firmware Bug] has a comforting feeling of
> > familiarity... :)
> > 
> > I wonder whether the same sort of reset happen on more "commercial"
> > systems (such as some of the laptops). You expect that people look at
> > the cpufreq stuff closely, and don't see things exploding like we are.
> 
> I finally got around to getting my Lenovo ThinkPad T14s to boot (it
> refuses to start the kernel when using GRUB, and it's not due to the
> known 64 GB memory issue as it only has 32 GB)

<cry>
I know the feeling. My devkit can't use GRUB either, so I added a
hook to the GRUB config to generate EFI scripts that directly execute
the kernel with initrd, dtb, and command line.

This is probably the worse firmware I've seen in a very long while.
</cry>

> and can confirm that it
> hard resets when accessing the cpufreq sysfs attributes as well.

Right. So this also happens on non-abandonware machines.

> On the bright side, at least I don't see any warnings due to duplicate
> OPPs on this machine (x1e78100, latest UEFI fw).

One bug fixed...

	M.

-- 
Without deviation from the norm, progress is not possible.