Re: [PATCH] firmware: smccc: default ARM_SMCCC_SOC_ID to disabled

[Satya Durga Srinivasu Prabhala]

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.