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

[Marc Zyngier]

On Thu, 05 Dec 2024 11:23:05 +0000,
Sibi Sankar <quic_sibis@xxxxxxxxxxx> wrote:
> 
> 
> 
> On 11/5/24 23:42, Marc Zyngier wrote:
> > 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.
> 
> The PERF_LEVEL_GET implementation in the SCP firmware side
> is the reason for the crash :|, currently there is a bug
> in the kernel that picks up index that we set with LEVEL_SET
> with fast channel and that masks the crash. I was told the
> crash happens when idle states are enabled and a regular
> LEVEL_GET message is triggered from the kernel. This was
> fixed a while back but it will take a while to flow back
> to all the devices. It should already be out CRD's.

But this fix will never reach some platforms, such as the devkit, and
we cannot mandate that people update to the latest anyway. How do we
distinguish between good and bad firmware versions?

Thanks,

	M.

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