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

[Satya Durga Srinivasu Prabhala]

On 1/14/2026 11:37 AM, Dmitry Baryshkov wrote:
> On Wed, Jan 14, 2026 at 10:04:21AM -0800, Satya Durga Srinivasu Prabhala wrote:
> > Hello Dmitry,
> >
> > On 1/13/2026 3:25 AM, Dmitry Baryshkov 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.
> > > >
> > > > Flip the default of CONFIG_ARM_SMCCC_SOC_ID from y to n. Platforms that
> > > > prefer SMCCC over a vendor driver can explicitly enable it.
> > > NAK, the userspace should not depend on the exact kernel configuration.
> > > Consider working with distribution kernels, which would enable this
> > > driver anyway.
> > As I mentioned in the other replies, vendor interface exists before the
> > standard
> > interface and user space heavily relies on soc0 already. If not disabling
> > the
> > SMCCC SOC ID by default. I believe, we should  at-least have a way to make
> > sure vendors can disable SMCCC SOC ID by some means or have vendor
> > interface takes precedence.
> Please correct me if I'm wrong, what do you observe? SMCCC device on
> soc0 and qcom_socinfo at soc1?

Yes, that is absolutely correct, Dmitry.

> In such a case the ABI file, Documentation/ABI/testing/sysfs-devices-soc clearly
> defines that there might be several different SoC devices (identified by
> different drivers, etc). If the userspace depends on qcom_socinfo device
> being soc0, then the userspace is broken.


Yes, there is no question about that. User space had certain assumption on
SoC Devices. The point to note is, user space had those assumptions based on
vendor interfaces which existed from long time.


> Last, but not least, the soc_id format is documented in the ABI
> document. It is clearly allowed to have jep106 format in the soc_id. So,
> I think, you have two options: disable SMCCC 1.2+ in the firmware or
> adapt the userspace. You can't control e.g. the kernel that will be
> running on your platform (it very well can be a standard distro kernel
> from Debian, Ubuntu or Fedora, which obviously will have that driver
> enabled).


IMHO, vendors at-least should have a way to choose what interface needs 
to be
exposed to user space (vendor vs SMCCC).


> > Best,
> > Satya
> > > > This avoids unexpected format changes and keeps the generic SoC sysfs
> > > > stable on systems that rely on vendor-specific identification.
> > > >
> > > > [1]
> > > > Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/qcom/socinfo.c
> > > >
> > > > Signed-off-by: Satya Durga Srinivasu Prabhala <satya.prabhala@xxxxxxxxxxxxxxxx>
> > > > ---
> > > >    drivers/firmware/smccc/Kconfig | 5 ++++-
> > > >    1 file changed, 4 insertions(+), 1 deletion(-)