Message-ID: <dc26dc7e-a0c1-44db-b719-1d8f34c2470b@oss.qualcomm.com>
Date: Thu, 15 Jan 2026 15:51:33 -0800
From: Satya Durga Srinivasu Prabhala <satya.prabhala@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Sudeep Holla <sudeep.holla@....com>, Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, trilok.soni@....qualcomm.com
Subject: Re: [PATCH] firmware: smccc: default ARM_SMCCC_SOC_ID to disabled

Hello Dmitry,

On 1/15/2026 12:18 PM, Dmitry Baryshkov wrote:

> On Thu, Jan 15, 2026 at 10:42:51AM -0800, Satya Durga Srinivasu Prabhala wrote:
>> Hello Sudeep,
>>
>> Thanks for the feedback.
>>
>> On 1/14/2026 1:01 PM, Sudeep Holla wrote:
>>> On Wed, Jan 14, 2026 at 08:50:23AM -0800, Satya Durga Srinivasu Prabhala wrote:
>>>> Hello Sudeep,
>>>>
>>>> On 1/13/2026 4:29 AM, Sudeep Holla wrote:
>>>>> On Mon, Jan 12, 2026 at 10:24:06PM -0800, Satya Durga Srinivasu Prabhala wrote:
>>>>>> The ARM SMCCC SoC ID driver is currently enabled by default and publishes
>>>>>> SMCCC-provided SoC identification into /sys/bus/soc/devices/socX/*.
>>>>>>
>>>>>> On platforms where a vendor SoC driver already exposes widely-consumed
>>>>>> attributes (e.g. Qualcomm socinfo [1]), enabling the SMCCC driver changes
>>>>>> the format of /sys/devices/soc0/soc_id (e.g. "jep106:XXYY:ZZZZ" instead
>>>>>> of a vendor logical ID like "519") and breaks existing userspace consumers.
>>>>>>
>>>>> Instead of relying on a vendor-specific SoC driver, we should consider
>>>>> disabling it and using the OS-agnostic SoC information interface provided by
>>>>> the firmware.
>>>> Would like to add some history here. Vendor interface existed [1] even
>>>> before
>>>> SMCCC SMC ID was introduced [2]. And there are several user space entities
>>>> which
>>>> uses the soc0 interface already.
>>> True, but that's not the main point.
>> That is one of the point which needs to be considered in my honest opinion.
>> Vendor driver existed from long time (v3.10 Kernels) in Android
>> https://android.googlesource.com/kernel/msm/+/refs/heads/android-msm-angler-3.10-marshmallow-dr/drivers/soc/qcom/socinfo.c
>> and lot of user space entities in Android depends on soc0 which is not just
>> limited
>> Qualcomm user space, but also, 3rd party ones.
>>
>>>>> The presence of this interface strongly suggests that the
>>>>> firmware is designed to support multiple operating systems or software stacks
>>>>> that already depend on it.
>>>> That is correct. We started seeing the issue with user space when our
>>>> firmware
>>>> started implementing support for SMCCC SOC ID recently for non-Linux based
>>>> product.
>>>> As the firmware remain same across OSes, user space is broken on Linux.
>>> What exactly do you mean by "firmware started implementing support for SMCCC
>>> SOC ID recently for non-Linux based product" ? Does that really mean that
>>> you can change the firmware for Linux based products ? I don't think so and
>>> hence we are in this discussion.
>>>
>>> 1. Either it exists in which case deal with it by disabling vendor driver
>>>      and/or fixing the userspace.
>>>
>>> or
>>>
>>> 2. It doesn't exist which is not a problem.
>> Allow me to add some more details, so far, our firmware hasn't been
>> supporting
>> SMCCC SMC ID.  Due a requirement on non-Linux based product, firmware
>> started
>> to support the feature and same firmware is used even on Linux Android
>> (android16-6.12)
>> based product.
>>
>> I would say, firmware started supporting the feature on our newer product
>> instead
>> of firmware being updated on any older products.
> These are two different cases. But as you explicitly state that it is
> only for a new products, then you can fix the userspace to check all
> SoC devices. Broken userspace was never _shipped_ on those.

Though it's a new product with updated firmware which supports the SMCCC 
SOC ID,
Kernel & user space remain same (Android16 based) and shared with other 
SoCs.

>> Now, as the user space remain same and is relying on soc0 interface already,
> Why does it have to be the same for new devices?

It's a software stack composition where Kernel & User space is shared 
and expected
to have no changes (shared with other SoCs / Products as well).

>> user space is broken as SMCCC SOC ID enabled by default which gets compiled
>> into Kernel and takes precedence over vendor driver which is a vendor module
>> in case of Android.
>>
>>> The userspace
>>> tool seem to have made a wrong assumption and can't expect the kernel to
>>> magically fix the issue here.
>>>
>>> E.g. We didn't disable HMP(a.k.a big little platforms) as the assumptions
>>> made by several userspace tools(e.g. lscpu IIRC) was wrong at the time.
>> Sorry, at risk of repeating the same thing again, the user space was using
>> soc0 interface on Linux Android products for a long time base on vendor
>> implementation. While I agree that, user space had some assumptions based
>> on vendor implementation, if not disabling the SMCCC SOC ID by default, we
>> should at-least have a way to disable it (via cmdline) based on vendor
>> requirements.
> How will that command line parameter be set and passed to the kernel?

Either from Device Tree or Bootloader.

>
> A better approach would be to fix the issue where is is broken:
> - Add a switch to the firmware, letting it ignore SMCCC SOC_ID calls
>    (like it was beforehand)
>
> OR
>
> - Fix the userspace
>
> The kernel was never broken, it is not a kernel change that introduced
> the regression. Why are you trying to change the kernel? If it ain't
> broken, don't fix it.

Sure, if we can't do anything in Kernel, we will explore these options.

Powered by blists - more mailing lists