Re: [PATCH 3/3] cpufreq: qcom-nvmem: add compatible fallback for ipq806x for no SMEM

[Christian Marangi <ansuelsmth@gmail.com>]

On Thu, Oct 30, 2025 at 11:54:41AM +0100, Konrad Dybcio wrote:
> On 10/30/25 11:28 AM, Christian Marangi wrote:
> > On Thu, Oct 30, 2025 at 09:56:24AM +0100, Konrad Dybcio wrote:
> >> On 10/29/25 2:33 PM, Christian Marangi wrote:
> >>> On some IPQ806x SoC SMEM might be not initialized by SBL. This is the
> >>> case for some Google devices (the OnHub family) that can't make use of
> >>> SMEM to detect the SoC ID.
> >>
> >> Oh this is (the unpleasant kind of ) interesting.. Is there any sort
> >> of uboot/kernel tree for these machines available?
> >>
> > 
> > There is some sort of source but quite confusing. From the info they use
> > coreboot and chromeos.
> > 
> > Looking at the source they comment everything related to SMEM
> > (confirming the fact that they actually don't init it)
> > 
> > [1] https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/firmware-storm-6315.B/src/board/storm
> > [2] https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-storm-6315.B
> 
> Hmm odd..
> 
> The patch itself looks mostly good, although you e.g. assign
> qcom,ipq8069 -> QCOM_ID_IPQ8065 even though QCOM_ID_IPQ8069 exists
> 
> This doesn't cause any difference in behavior within this driver but
> looks slightly funky
>

Well yes I did to simplify the logic.

> Should we perhaps do this patching in smem.c instead, in case other
> drivers try to retrieve the ID in the future?
> 

Well we would hide the fact that SMEM is not available. SMEM gives
precise info while this operates on some kind of fallback measure. If
someone wrongly sets the compatible and use the most generic one
(qcom,ipq8064) then we would parse the wrong ID.

Also looking at the user of those API it's really just cpufreq and apss
for ipq60xx so maybe not worth? (we would also have to add additional
logic to fallback only for some specific SoC)

-- 
	Ansuel