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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <bcff0cc8-8950-4cbc-9af4-8e5787ad0253@oss.qualcomm.com>
Date: Thu, 30 Oct 2025 12:16:29 +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 12:11 PM, Christian Marangi wrote:
> 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.

I'm fine with it I think.. it's just a small hack after all

>> 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)

Right, maybe this patch is the right approach

Let's see if others have any reservations

Konrad