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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <690347ee.050a0220.21ee29.8092@mx.google.com>
Date: Thu, 30 Oct 2025 12:11:40 +0100
From: Christian Marangi <ansuelsmth@...il.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Ilia Lin <ilia.lin@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Raag Jadav <raag.jadav@...el.com>, Arnd Bergmann <arnd@...db.de>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] cpufreq: qcom-nvmem: add compatible fallback for
 ipq806x for no SMEM

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