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: <c9801322-2184-4f04-9459-960580ecf6a7@oss.qualcomm.com>
Date: Thu, 30 Oct 2025 11:54:41 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Christian Marangi <ansuelsmth@...il.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 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

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

Konrad