[PATCH] firmware: smccc: default ARM_SMCCC_SOC_ID to disabled

[PATCH] firmware: smccc: default ARM_SMCCC_SOC_ID to disabled

[Satya Durga Srinivasu Prabhala]

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.

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@oss.qualcomm.com>
---
 drivers/firmware/smccc/Kconfig | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
index 15e7466179a6..f830d11ebdca 100644
--- a/drivers/firmware/smccc/Kconfig
+++ b/drivers/firmware/smccc/Kconfig
@@ -18,8 +18,11 @@ config HAVE_ARM_SMCCC_DISCOVERY
 config ARM_SMCCC_SOC_ID
 	bool "SoC bus device for the ARM SMCCC SOC_ID"
 	depends on HAVE_ARM_SMCCC_DISCOVERY
-	default y
+	default n
 	select SOC_BUS
 	help
 	  Include support for the SoC bus on the ARM SMCCC firmware based
 	  platforms providing some sysfs information about the SoC variant.
+	  Note: Several vendor platforms provide their own SoC information
+	  drivers under drivers/soc/*. To avoid conflicting sysfs attribute
+	  formats in /sys/devices/socX/*, this driver defaults to disabled.

---
base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73
change-id: 20260112-disable_smccc_soc_id-ed09ef4d777f

Best regards,
-- 
Satya Durga Srinivasu Prabhala <satya.prabhala@oss.qualcomm.com>

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

[Mukesh Ojha]

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.
> 
> 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@oss.qualcomm.com>

Fixes tag ??

> ---
>  drivers/firmware/smccc/Kconfig | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
> index 15e7466179a6..f830d11ebdca 100644
> --- a/drivers/firmware/smccc/Kconfig
> +++ b/drivers/firmware/smccc/Kconfig
> @@ -18,8 +18,11 @@ config HAVE_ARM_SMCCC_DISCOVERY
>  config ARM_SMCCC_SOC_ID
>  	bool "SoC bus device for the ARM SMCCC SOC_ID"
>  	depends on HAVE_ARM_SMCCC_DISCOVERY
> -	default y
> +	default n
>  	select SOC_BUS
>  	help
>  	  Include support for the SoC bus on the ARM SMCCC firmware based
>  	  platforms providing some sysfs information about the SoC variant.
> +	  Note: Several vendor platforms provide their own SoC information
> +	  drivers under drivers/soc/*. To avoid conflicting sysfs attribute
> +	  formats in /sys/devices/socX/*, this driver defaults to disabled.
> 
> ---
> base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73
> change-id: 20260112-disable_smccc_soc_id-ed09ef4d777f
> 
> Best regards,
> -- 
> Satya Durga Srinivasu Prabhala <satya.prabhala@oss.qualcomm.com>
> 

-- 
-Mukesh Ojha

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

[Sudeep Holla]

On Tue, Jan 13, 2026 at 01:34:05PM +0530, Mukesh Ojha 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.
> > 
> > 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@oss.qualcomm.com>
> 
> Fixes tag ??
> 

Sorry which commit is broken ?

-- 
Regards,
Sudeep

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

[Will Deacon]

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.

Isn't the fundamental issue here that you have multiple callers of
soc_device_register() and your userspace is only looking at soc0?

Will

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

[Satya Durga Srinivasu Prabhala]

Hello Will,

On 1/13/2026 2:57 AM, Will Deacon 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.
> Isn't the fundamental issue here that you have multiple callers of
> soc_device_register() and your userspace is only looking at soc0?
Yes, that is right. The issue is we have several products which already
uses the soc0 interface as vendor interface [1] existed even before the
SMCCC SCM ID [2]. Also, per SMCCC specification, SOC ID is an optional
feature. So, vendor specific implementation can take precedence over
standard implementation or a way to disable SMCCC SOC ID could help.

Best,
Satya
>
> Will
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/qcom/socinfo.c?id=efb448d0a3fca01bb987dd70963da6185b81751e
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/smccc/soc_id.c?id=821b67fa46390baea0ac5139a60eaa48805261b2 

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

[Sudeep Holla]

On Wed, Jan 14, 2026 at 08:58:01AM -0800, Satya Durga Srinivasu Prabhala wrote:
> Hello Will,
> 
> On 1/13/2026 2:57 AM, Will Deacon 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.
> > Isn't the fundamental issue here that you have multiple callers of
> > soc_device_register() and your userspace is only looking at soc0?
> Yes, that is right. The issue is we have several products which already
> uses the soc0 interface as vendor interface [1] existed even before the
> SMCCC SCM ID [2]. Also, per SMCCC specification, SOC ID is an optional
> feature.

Yes it is optional and that means kernel won't complain if it is not
implemented in the firmware.

> So, vendor specific implementation can take precedence over
> standard implementation or a way to disable SMCCC SOC ID could help.
> 

Yet this vendor specific implementation chose to implement the optional
feature when it needed the vendor specific implementation can take precedence
over this. It had the choice and when it implemented it, it choose and
it can't expect the generic OS to ignore firmware standard interface
just because it has vendor specific implementation else where.

And one of the reasons some of the vendors needed this SOC_ID in the
SMCCC is o avoid or have precedence over any other interface(like DT/ACPI)
that can override or provide other information.

-- 
Regards,
Sudeep

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

[Dmitry Baryshkov]

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.

> 
> 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@oss.qualcomm.com>
> ---
>  drivers/firmware/smccc/Kconfig | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

-- 
With best wishes
Dmitry

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

[Satya Durga Srinivasu Prabhala]

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.

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@oss.qualcomm.com>
>> ---
>>   drivers/firmware/smccc/Kconfig | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>

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

[Dmitry Baryshkov]

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?

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.

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

> 
> 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@oss.qualcomm.com>
> > > ---
> > >   drivers/firmware/smccc/Kconfig | 5 ++++-
> > >   1 file changed, 4 insertions(+), 1 deletion(-)
> > > 

-- 
With best wishes
Dmitry

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

[Sudeep Holla]

On Wed, Jan 14, 2026 at 09:37:24PM +0200, 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?
> 
> 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.
> 
> 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).
> 

Completely agree to all the points made here.

-- 
Regards,
Sudeep

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@oss.qualcomm.com>
>>>> ---
>>>>    drivers/firmware/smccc/Kconfig | 5 ++++-
>>>>    1 file changed, 4 insertions(+), 1 deletion(-)
>>>>

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

[Dmitry Baryshkov]

On Thu, Jan 15, 2026 at 12:14:15PM -0800, Satya Durga Srinivasu Prabhala wrote:
> 
> 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.

As I wrote in another email, you are correct here. But not precise.
Userspace had certain assumptions regarding vendor _firmware_.

The whole situation is different from e.g. somebody deciding to add
soc_device_register() call to the BT/WiFi SoC driver. In the latter case
it would be a kernel regressing the userspace (which is generally
disallowed). In you case it's Qualcomm firmware regressing
Qualcomm-specific Android userspace.

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

But you already have. Kconfig options, etc. What you can do is turn
ARM_SMCCC_SOC_ID into a module (I'm not sure if SMCCC maintainers would
agree to that, but at least it is something which makes sense to me).

> > > 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@oss.qualcomm.com>
> > > > > ---
> > > > >    drivers/firmware/smccc/Kconfig | 5 ++++-
> > > > >    1 file changed, 4 insertions(+), 1 deletion(-)
> > > > > 

-- 
With best wishes
Dmitry

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

[Sudeep Holla]

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. 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. Aligning the Linux kernel with this
firmware-defined, OS-agnostic mechanism would reduce vendor-specific
dependencies and improve portability. Any gaps can be addressed by enhancing
userspace to correctly parse and consume this information. Given these
advantages, why would this approach not be the better long-term solution?

-- 
Regards,
Sudeep

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

[Satya Durga Srinivasu Prabhala]

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.
> 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.
> Aligning the Linux kernel with this
> firmware-defined, OS-agnostic mechanism would reduce vendor-specific
> dependencies and improve portability. Any gaps can be addressed by enhancing
> userspace to correctly parse and consume this information.
Agree. Updating entire use space would need time and we are looking to see
if vendor specific interface can be given priority over the standard 
interface.
>   Given these
> advantages, why would this approach not be the better long-term solution?
As mentioned above, existing user space will be broken and fixing 
existing user
space is going to take time. As the feature itself is "optional" from SMCCC
specification, if we can't disable by default, we should at-least have a way
to disable the feature by other means.


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/soc/qcom/socinfo.c?id=efb448d0a3fca01bb987dd70963da6185b81751e
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/smccc/soc_id.c?id=821b67fa46390baea0ac5139a60eaa48805261b2 

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

[Sudeep Holla]

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.

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


> > Aligning the Linux kernel with this
> > firmware-defined, OS-agnostic mechanism would reduce vendor-specific
> > dependencies and improve portability. Any gaps can be addressed by enhancing
> > userspace to correctly parse and consume this information.
> Agree. Updating entire use space would need time and we are looking to see
> if vendor specific interface can be given priority over the standard
> interface.

That statement simply doesn't make sense at all. Your product took all the
effort to implement standards and then you don't want to use it at all.
As per your claims it is not even broken(in terms of data from the sysfs
files), so I don't know what to say here, sorry ?

> >   Given these
> > advantages, why would this approach not be the better long-term solution?
> As mentioned above, existing user space will be broken and fixing existing
> user space is going to take time. As the feature itself is "optional" from SMCCC
> specification, if we can't disable by default, we should at-least have a way
> to disable the feature by other means.
>

The data given to the userspace from the kernel is not broken. 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.

-- 
Regards,
Sudeep

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

[Satya Durga Srinivasu Prabhala]

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.

Now, as the user space remain same and is relying on soc0 interface already,
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.

>>> Aligning the Linux kernel with this
>>> firmware-defined, OS-agnostic mechanism would reduce vendor-specific
>>> dependencies and improve portability. Any gaps can be addressed by enhancing
>>> userspace to correctly parse and consume this information.
>> Agree. Updating entire use space would need time and we are looking to see
>> if vendor specific interface can be given priority over the standard
>> interface.
> That statement simply doesn't make sense at all. Your product took all the
> effort to implement standards and then you don't want to use it at all.
> As per your claims it is not even broken(in terms of data from the sysfs
> files), so I don't know what to say here, sorry ?

As mentioned above, the requirement was for a non-Linux based OS which 
impacted
Linux Android baseline.
>>>    Given these
>>> advantages, why would this approach not be the better long-term solution?
>> As mentioned above, existing user space will be broken and fixing existing
>> user space is going to take time. As the feature itself is "optional" from SMCCC
>> specification, if we can't disable by default, we should at-least have a way
>> to disable the feature by other means.
>>
> The data given to the userspace from the kernel is not broken.

Yes, that's well understood.
> 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.

Best,
Satya

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

[Dmitry Baryshkov]

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.

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

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

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.

-- 
With best wishes
Dmitry

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.

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

[Bjorn Andersson]

On Thu, Jan 15, 2026 at 10:18:38PM +0200, Dmitry Baryshkov wrote:
> On Thu, Jan 15, 2026 at 10:42:51AM -0800, Satya Durga Srinivasu Prabhala wrote:
[..]
> 
> The kernel was never broken, it is not a kernel change that introduced
> the regression. Why are you trying to change the kernel?

I always thought you had one of these per SoC, so assuming a that a
single-soc system presented one entry would make sense to me.

The kernel is supposed to abstract away hardware details, that's clearly
not what we're doing here.

> If it ain't broken, don't fix it.
> 

Get over yourself.

Regards,
Bjorn

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

[Sudeep Holla]

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.
> 
> Now, as the user space remain same and is relying on soc0 interface already,
> 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.
> 

See below example of lscpu and HMP.

> > > > Aligning the Linux kernel with this
> > > > firmware-defined, OS-agnostic mechanism would reduce vendor-specific
> > > > dependencies and improve portability. Any gaps can be addressed by enhancing
> > > > userspace to correctly parse and consume this information.
> > > Agree. Updating entire use space would need time and we are looking to see
> > > if vendor specific interface can be given priority over the standard
> > > interface.
> > That statement simply doesn't make sense at all. Your product took all the
> > effort to implement standards and then you don't want to use it at all.
> > As per your claims it is not even broken(in terms of data from the sysfs
> > files), so I don't know what to say here, sorry ?
> 
> As mentioned above, the requirement was for a non-Linux based OS which
> impacted Linux Android baseline.

Read that again and think. If other products can cope and are made to cope
up with the new SOC_ID interface, why is Linux so special not to follow that
and fix the userspace to start using new interface. If just getting ID and not
name is the main issue here, consider moving to the updated spec or patch up
in the userspace.

> > > >    Given these
> > > > advantages, why would this approach not be the better long-term solution?
> > > As mentioned above, existing user space will be broken and fixing existing
> > > user space is going to take time. As the feature itself is "optional" from SMCCC
> > > specification, if we can't disable by default, we should at-least have a way
> > > to disable the feature by other means.
> > > 
> > The data given to the userspace from the kernel is not broken.
> 
> Yes, that's well understood.

Thanks and that dictates the direction of these discussions.

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

It was the case with lscpu too. We didn't disable HMP just because lscpu 
didn't understand or just read cpu0 data. It is exactly the case with
the userspace tool you are mentioning here. Kernel is not providing wrong
data.

From the ABI document in the kernel, it has been marked as socX since its
initial addition in 2012. So clearly userspace got it wrong and no one
realised it until now. There is no argument that data provided from the kernel
is wrong in these discussions. So I have nothing else to add unfortunately.

-- 
Regards,
Sudeep

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

[Satya Durga Srinivasu Prabhala]

Hello Sudeep,

Thanks for the discussion & feedback.

Wanted to check on below possibilities to disable the SMCCC SOC ID at 
the vendor end, can you help comment?
1. Introduce cmdline option
    We are trying to pursue that in Android Kernel - 
https://android-review.googlesource.com/c/kernel/common/+/3912874
2. Mark SMCCC SMC ID driver as tristate & module as suggested by Dmitry

If any of these other options are agreeable, will send separate patch.

On 1/16/2026 2:39 AM, Sudeep Holla 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.
>>
>> Now, as the user space remain same and is relying on soc0 interface already,
>> 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.
>>
> See below example of lscpu and HMP.
>
>>>>> Aligning the Linux kernel with this
>>>>> firmware-defined, OS-agnostic mechanism would reduce vendor-specific
>>>>> dependencies and improve portability. Any gaps can be addressed by enhancing
>>>>> userspace to correctly parse and consume this information.
>>>> Agree. Updating entire use space would need time and we are looking to see
>>>> if vendor specific interface can be given priority over the standard
>>>> interface.
>>> That statement simply doesn't make sense at all. Your product took all the
>>> effort to implement standards and then you don't want to use it at all.
>>> As per your claims it is not even broken(in terms of data from the sysfs
>>> files), so I don't know what to say here, sorry ?
>> As mentioned above, the requirement was for a non-Linux based OS which
>> impacted Linux Android baseline.
> Read that again and think. If other products can cope and are made to cope
> up with the new SOC_ID interface, why is Linux so special not to follow that
> and fix the userspace to start using new interface. If just getting ID and not
> name is the main issue here, consider moving to the updated spec or patch up
> in the userspace.
>
>>>>>     Given these
>>>>> advantages, why would this approach not be the better long-term solution?
>>>> As mentioned above, existing user space will be broken and fixing existing
>>>> user space is going to take time. As the feature itself is "optional" from SMCCC
>>>> specification, if we can't disable by default, we should at-least have a way
>>>> to disable the feature by other means.
>>>>
>>> The data given to the userspace from the kernel is not broken.
>> Yes, that's well understood.
> Thanks and that dictates the direction of these discussions.
>
>>> 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.
>>
> It was the case with lscpu too. We didn't disable HMP just because lscpu
> didn't understand or just read cpu0 data. It is exactly the case with
> the userspace tool you are mentioning here. Kernel is not providing wrong
> data.
>
>  From the ABI document in the kernel, it has been marked as socX since its
> initial addition in 2012. So clearly userspace got it wrong and no one
> realised it until now. There is no argument that data provided from the kernel
> is wrong in these discussions. So I have nothing else to add unfortunately.
>
-- 
Kind Regards,
Satya

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

[Trilok Soni]

On 1/16/2026 12:53 PM, Satya Durga Srinivasu Prabhala wrote:
> Hello Sudeep,
> 
> Thanks for the discussion & feedback.
> 
> Wanted to check on below possibilities to disable the SMCCC SOC ID at the vendor end, can you help comment?
> 1. Introduce cmdline option
>    We are trying to pursue that in Android Kernel - https://android-review.googlesource.com/c/kernel/common/+/3912874
> 2. Mark SMCCC SMC ID driver as tristate & module as suggested by Dmitry
> 
> If any of these other options are agreeable, will send separate patch.

You broke the replies by top-posting here. 

> 
> On 1/16/2026 2:39 AM, Sudeep Holla 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.
>>>
>>> Now, as the user space remain same and is relying on soc0 interface already,
>>> 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.
>>>
>> See below example of lscpu and HMP.
>>
>>>>>> Aligning the Linux kernel with this
>>>>>> firmware-defined, OS-agnostic mechanism would reduce vendor-specific
>>>>>> dependencies and improve portability. Any gaps can be addressed by enhancing
>>>>>> userspace to correctly parse and consume this information.
>>>>> Agree. Updating entire use space would need time and we are looking to see
>>>>> if vendor specific interface can be given priority over the standard
>>>>> interface.
>>>> That statement simply doesn't make sense at all. Your product took all the
>>>> effort to implement standards and then you don't want to use it at all.
>>>> As per your claims it is not even broken(in terms of data from the sysfs
>>>> files), so I don't know what to say here, sorry ?
>>> As mentioned above, the requirement was for a non-Linux based OS which
>>> impacted Linux Android baseline.
>> Read that again and think. If other products can cope and are made to cope
>> up with the new SOC_ID interface, why is Linux so special not to follow that
>> and fix the userspace to start using new interface. If just getting ID and not
>> name is the main issue here, consider moving to the updated spec or patch up
>> in the userspace.
>>
>>>>>>     Given these
>>>>>> advantages, why would this approach not be the better long-term solution?
>>>>> As mentioned above, existing user space will be broken and fixing existing
>>>>> user space is going to take time. As the feature itself is "optional" from SMCCC
>>>>> specification, if we can't disable by default, we should at-least have a way
>>>>> to disable the feature by other means.
>>>>>
>>>> The data given to the userspace from the kernel is not broken.
>>> Yes, that's well understood.
>> Thanks and that dictates the direction of these discussions.
>>
>>>> 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.
>>>
>> It was the case with lscpu too. We didn't disable HMP just because lscpu
>> didn't understand or just read cpu0 data. It is exactly the case with
>> the userspace tool you are mentioning here. Kernel is not providing wrong
>> data.
>>
>>  From the ABI document in the kernel, it has been marked as socX since its
>> initial addition in 2012. So clearly userspace got it wrong and no one
>> realised it until now. There is no argument that data provided from the kernel
>> is wrong in these discussions. So I have nothing else to add unfortunately.
>>

I believe that point(s) we have not touched upon are following:

There will be thousands of Android applications using the native interfaces
in the playstore in various regions like US and China and so on, which relies
on getting the SOC_ID to understand the product and enable / disable some features.

For example, benchmarks like GeekBench or Antutu may also be reading these
interfaces.

There are apps. in certain regions which are still not updated from "32-bit"
to 64-bit on Android yet as an example and there may be no way to reach out
to those developers to fix but apps. are still used by many users.  

If we need to move all of these third-party applications to this new interface
then we have to "break them" before we fix them. Do we want to have such approach?

We should not have enabled this feature as "default y" in the first place and should
have kept it as "tristate" or kept it disabled in my opinion.

---Trilok Soni

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

[Bjorn Andersson]

On Fri, Jan 16, 2026 at 03:53:57PM -0800, Trilok Soni wrote:
> On 1/16/2026 12:53 PM, Satya Durga Srinivasu Prabhala wrote:
> > Hello Sudeep,
> > 
> > Thanks for the discussion & feedback.
> > 
> > Wanted to check on below possibilities to disable the SMCCC SOC ID at the vendor end, can you help comment?
> > 1. Introduce cmdline option
> >    We are trying to pursue that in Android Kernel - https://android-review.googlesource.com/c/kernel/common/+/3912874
> > 2. Mark SMCCC SMC ID driver as tristate & module as suggested by Dmitry
> > 
> > If any of these other options are agreeable, will send separate patch.
> 
> You broke the replies by top-posting here. 
> 
> > 
> > On 1/16/2026 2:39 AM, Sudeep Holla wrote:
> >> On Thu, Jan 15, 2026 at 10:42:51AM -0800, Satya Durga Srinivasu Prabhala wrote:
[..]
> >>>> 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.
> >>>
> >> It was the case with lscpu too. We didn't disable HMP just because lscpu
> >> didn't understand or just read cpu0 data. It is exactly the case with
> >> the userspace tool you are mentioning here. Kernel is not providing wrong
> >> data.
> >>
> >>  From the ABI document in the kernel, it has been marked as socX since its
> >> initial addition in 2012. So clearly userspace got it wrong and no one
> >> realised it until now. There is no argument that data provided from the kernel
> >> is wrong in these discussions. So I have nothing else to add unfortunately.
> >>
> 
> I believe that point(s) we have not touched upon are following:
> 
> There will be thousands of Android applications using the native interfaces
> in the playstore in various regions like US and China and so on, which relies
> on getting the SOC_ID to understand the product and enable / disable some features.
> 
> For example, benchmarks like GeekBench or Antutu may also be reading these
> interfaces.
> 
> There are apps. in certain regions which are still not updated from "32-bit"
> to 64-bit on Android yet as an example and there may be no way to reach out
> to those developers to fix but apps. are still used by many users.  
> 
> If we need to move all of these third-party applications to this new interface
> then we have to "break them" before we fix them. Do we want to have such approach?
> 
> We should not have enabled this feature as "default y" in the first place and should
> have kept it as "tristate" or kept it disabled in my opinion.
> 

Kconfig defaults are not a good way to solve such conflicts, there's
nothing saying that ACK wouldn't =y this in their config because it make
sense for a subset of devices.

I share your concerns about the impact to user space applications where
the authors interpreted the API in the same way as I did - there will be
1 soc instance per soc...

Regards,
Bjorn

> ---Trilok Soni
> 
> 

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

[Sudeep Holla]

On Fri, Jan 16, 2026 at 03:53:57PM -0800, Trilok Soni wrote:
> 
> I believe that point(s) we have not touched upon are following:
> 
> There will be thousands of Android applications using the native interfaces
> in the playstore in various regions like US and China and so on, which relies
> on getting the SOC_ID to understand the product and enable / disable some features.
> 
> For example, benchmarks like GeekBench or Antutu may also be reading these
> interfaces.
> 
> There are apps. in certain regions which are still not updated from "32-bit"
> to 64-bit on Android yet as an example and there may be no way to reach out
> to those developers to fix but apps. are still used by many users.  
> 

Fair enough, but apps get updated on Android phones every day. So sorry if I
don’t consider this as something impossible. I do understand many apps are not
actively developed, yet that is no reason to say the wrong assumptions made by
these apps are correct.

> If we need to move all of these third-party applications to this new interface
> then we have to "break them" before we fix them. Do we want to have such approach?
> 

Sorry, which new interface are you referring to?
Are we still talking about /sys/devices/socX/?
If so, are you suggesting that X=0 and X=1 represent two different interfaces?
If that’s the case, I honestly have no words.

> We should not have enabled this feature as "default y" in the first place and should
> have kept it as "tristate" or kept it disabled in my opinion.
> 

Sorry, but how do you envision this working with a single defconfig? Please
consider the issues on platforms beyond the ones you’re focused on as well.

-- 
Regards,
Sudeep

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

[Bjorn Andersson]

On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> On Fri, Jan 16, 2026 at 03:53:57PM -0800, Trilok Soni wrote:
> > 
> > I believe that point(s) we have not touched upon are following:
> > 
> > There will be thousands of Android applications using the native interfaces
> > in the playstore in various regions like US and China and so on, which relies
> > on getting the SOC_ID to understand the product and enable / disable some features.
> > 
> > For example, benchmarks like GeekBench or Antutu may also be reading these
> > interfaces.
> > 
> > There are apps. in certain regions which are still not updated from "32-bit"
> > to 64-bit on Android yet as an example and there may be no way to reach out
> > to those developers to fix but apps. are still used by many users.  
> > 
> 
> Fair enough, but apps get updated on Android phones every day. So sorry if I
> don’t consider this as something impossible. I do understand many apps are not
> actively developed, yet that is no reason to say the wrong assumptions made by
> these apps are correct.
> 

It might be what you're saying is true, at least for the top-10
applications in the app store. But that is not how we manage or maintain
the userspace interface in the Linux kernel - we don't break userspace.

> > If we need to move all of these third-party applications to this new interface
> > then we have to "break them" before we fix them. Do we want to have such approach?
> > 
> 
> Sorry, which new interface are you referring to?
> Are we still talking about /sys/devices/socX/?
> If so, are you suggesting that X=0 and X=1 represent two different interfaces?
> If that’s the case, I honestly have no words.
> 

Please do have words, because I really would like to understand what the
expectation of userspace is in the even that there's both soc0 and soc1,
regardless of which is which.

What does it even mean to have two different socs presented here? How
would userspace know which one to refer to? Should it refer to both and
guess which one makes more sense to it?


To me, when you decided to add a second caller to soc_device_register()
you created a regression in the userspace interface. If nothing else
it's a leaky abstraction.

> > We should not have enabled this feature as "default y" in the first place and should
> > have kept it as "tristate" or kept it disabled in my opinion.
> > 
> 
> Sorry, but how do you envision this working with a single defconfig? Please
> consider the issues on platforms beyond the ones you’re focused on as well.
> 

Glad that we're on the same page regarding both defconfig and
our considerations.

Regards,
Bjorn

> -- 
> Regards,
> Sudeep
> 

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

[Sudeep Holla]

On Sun, Jan 18, 2026 at 03:16:50PM -0600, Bjorn Andersson wrote:
> On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> > On Fri, Jan 16, 2026 at 03:53:57PM -0800, Trilok Soni wrote:
> > > 
> > > I believe that point(s) we have not touched upon are following:
> > > 
> > > There will be thousands of Android applications using the native interfaces
> > > in the playstore in various regions like US and China and so on, which relies
> > > on getting the SOC_ID to understand the product and enable / disable some features.
> > > 
> > > For example, benchmarks like GeekBench or Antutu may also be reading these
> > > interfaces.
> > > 
> > > There are apps. in certain regions which are still not updated from "32-bit"
> > > to 64-bit on Android yet as an example and there may be no way to reach out
> > > to those developers to fix but apps. are still used by many users.  
> > > 
> > 
> > Fair enough, but apps get updated on Android phones every day. So sorry if I
> > don’t consider this as something impossible. I do understand many apps are not
> > actively developed, yet that is no reason to say the wrong assumptions made by
> > these apps are correct.
> > 
> 
> It might be what you're saying is true, at least for the top-10
> applications in the app store. But that is not how we manage or maintain
> the userspace interface in the Linux kernel - we don't break userspace.
> 

Agreed, but I still think socX != soc0 and that is wrong assumption by the
application. Anyways, if more people think it is user-space break, I accept
it.

> > > If we need to move all of these third-party applications to this new interface
> > > then we have to "break them" before we fix them. Do we want to have such approach?
> > > 
> > 
> > Sorry, which new interface are you referring to?
> > Are we still talking about /sys/devices/socX/?
> > If so, are you suggesting that X=0 and X=1 represent two different interfaces?
> > If that’s the case, I honestly have no words.
> > 
> 
> Please do have words, because I really would like to understand what the
> expectation of userspace is in the even that there's both soc0 and soc1,
> regardless of which is which.
> 

OK if we are going there, can we blame the firmware for exposing this
information which is standard ? Sorry to repeat by firmware is exporting
that info in OS agnostic way and other OSes use that as the information as
it is standard way. Why can't we make Linux use or work with that information
as that removes all these vendor specific fragmentation created over years.
This point is orthogonal to user-space break.

> What does it even mean to have two different socs presented here? How
> would userspace know which one to refer to? Should it refer to both and
> guess which one makes more sense to it?
> 

Yes, the standard interface doesn't have much info though, so it could be
union of it if the applications prefer that way.

> 
> To me, when you decided to add a second caller to soc_device_register()
> you created a regression in the userspace interface. If nothing else
> it's a leaky abstraction.
> 

In that case, shouldn't soc_device_register() made to give error when an
attempt to call it more that one time then ? Also should be change the
ABI documents to refer it as soc0 and not socX ?

> > > We should not have enabled this feature as "default y" in the first place and should
> > > have kept it as "tristate" or kept it disabled in my opinion.
> > > 
> > 
> > Sorry, but how do you envision this working with a single defconfig? Please
> > consider the issues on platforms beyond the ones you’re focused on as well.
> > 
> 
> Glad that we're on the same page regarding both defconfig and
> our considerations.
> 

Thanks.

-- 
Regards,
Sudeep

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

[Dmitry Baryshkov]

On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote:
> On Sun, Jan 18, 2026 at 03:16:50PM -0600, Bjorn Andersson wrote:
> > On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> > 
> > To me, when you decided to add a second caller to soc_device_register()
> > you created a regression in the userspace interface. If nothing else
> > it's a leaky abstraction.
> > 
> 
> In that case, shouldn't soc_device_register() made to give error when an
> attempt to call it more that one time then ? Also should be change the
> ABI documents to refer it as soc0 and not socX ?

Then the whole SoC bus is an overkill. But I have a strange question
here. Consider the device having the "BT / WiFi SoC" next to the main
SoC. Is that SoC a legit target to export informaiton through sysfs /
soc bus?

-- 
With best wishes
Dmitry

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

[Sudeep Holla]

On Mon, Jan 19, 2026 at 06:44:23PM +0200, Dmitry Baryshkov wrote:
> On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote:
> > On Sun, Jan 18, 2026 at 03:16:50PM -0600, Bjorn Andersson wrote:
> > > On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> > > 
> > > To me, when you decided to add a second caller to soc_device_register()
> > > you created a regression in the userspace interface. If nothing else
> > > it's a leaky abstraction.
> > > 
> > 
> > In that case, shouldn't soc_device_register() made to give error when an
> > attempt to call it more that one time then ? Also should be change the
> > ABI documents to refer it as soc0 and not socX ?
> 
> Then the whole SoC bus is an overkill. But I have a strange question
> here. Consider the device having the "BT / WiFi SoC" next to the main
> SoC. Is that SoC a legit target to export informaiton through sysfs /
> soc bus?
> 

Just for clarity, I agree with you and there could be duplication of
information if there are multiple source for that information. E.g.,
the setup in this discussion where the EL3 firmware provides SOC_ID
information via SMCCC SOC_ID and DT providing vendor specific information
about the platform. Both are getting exported via sysfs but the problem
here is SOC_ID has displaced vendor specific DT info from soc0 to soc1.

We are exploring ways to see how user space can survive this.

-- 
Regards,
Sudeep

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

[Dmitry Baryshkov]

On Mon, Jan 19, 2026 at 04:56:32PM +0000, Sudeep Holla wrote:
> On Mon, Jan 19, 2026 at 06:44:23PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote:
> > > On Sun, Jan 18, 2026 at 03:16:50PM -0600, Bjorn Andersson wrote:
> > > > On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> > > > 
> > > > To me, when you decided to add a second caller to soc_device_register()
> > > > you created a regression in the userspace interface. If nothing else
> > > > it's a leaky abstraction.
> > > > 
> > > 
> > > In that case, shouldn't soc_device_register() made to give error when an
> > > attempt to call it more that one time then ? Also should be change the
> > > ABI documents to refer it as soc0 and not socX ?
> > 
> > Then the whole SoC bus is an overkill. But I have a strange question
> > here. Consider the device having the "BT / WiFi SoC" next to the main
> > SoC. Is that SoC a legit target to export informaiton through sysfs /
> > soc bus?
> > 
> 
> Just for clarity, I agree with you and there could be duplication of
> information if there are multiple source for that information. E.g.,
> the setup in this discussion where the EL3 firmware provides SOC_ID
> information via SMCCC SOC_ID and DT providing vendor specific information
> about the platform. Both are getting exported via sysfs but the problem
> here is SOC_ID has displaced vendor specific DT info from soc0 to soc1.

I understand the context and I understand that we ended up having two
soc devices for the main SoC. And that's exactly why I'm asking about
the WCN SoC exporting the information through the same interface. If it
is a legit user, then it is a possible outcome that WCN binds to soc0
while the main core gets bound to soc1 (even without SMCCC_ID in place).

Likewise if WCN if a legit user of soc_device_register(), then we can't
make it fail after registering the first entry.

> 
> We are exploring ways to see how user space can survive this.

-- 
With best wishes
Dmitry

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

[Bjorn Andersson]

On Mon, Jan 19, 2026 at 07:20:09PM +0200, Dmitry Baryshkov wrote:
> On Mon, Jan 19, 2026 at 04:56:32PM +0000, Sudeep Holla wrote:
> > On Mon, Jan 19, 2026 at 06:44:23PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote:
> > > > On Sun, Jan 18, 2026 at 03:16:50PM -0600, Bjorn Andersson wrote:
> > > > > On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> > > > > 
> > > > > To me, when you decided to add a second caller to soc_device_register()
> > > > > you created a regression in the userspace interface. If nothing else
> > > > > it's a leaky abstraction.
> > > > > 
> > > > 
> > > > In that case, shouldn't soc_device_register() made to give error when an
> > > > attempt to call it more that one time then ? Also should be change the
> > > > ABI documents to refer it as soc0 and not socX ?
> > > 
> > > Then the whole SoC bus is an overkill. But I have a strange question
> > > here. Consider the device having the "BT / WiFi SoC" next to the main
> > > SoC. Is that SoC a legit target to export informaiton through sysfs /
> > > soc bus?
> > > 
> > 
> > Just for clarity, I agree with you and there could be duplication of
> > information if there are multiple source for that information. E.g.,
> > the setup in this discussion where the EL3 firmware provides SOC_ID
> > information via SMCCC SOC_ID and DT providing vendor specific information
> > about the platform. Both are getting exported via sysfs but the problem
> > here is SOC_ID has displaced vendor specific DT info from soc0 to soc1.
> 
> I understand the context and I understand that we ended up having two
> soc devices for the main SoC. And that's exactly why I'm asking about
> the WCN SoC exporting the information through the same interface. If it
> is a legit user, then it is a possible outcome that WCN binds to soc0
> while the main core gets bound to soc1 (even without SMCCC_ID in place).
> 
> Likewise if WCN if a legit user of soc_device_register(), then we can't
> make it fail after registering the first entry.
> 

But by this definition, a vast variety of discrete IP should register
with this interface - instead of providing such information in their
respective functional interface.

My interpretation is that the soc_device_register() related to the
entity which is represented as /soc in your DeviceTree.

For a broader "dumping ground for different IP to register their
version information", we'd need some way to associate each entity with
the related component - which I believe there is none, because then you
could have used the specific driver interface in the first place.

(I.e. there's no representation of the WCN SoC in our system, we have
representations for the PMU, the WiFi, and the BT core, but not the
whole).

Regards,
Bjorn

> > 
> > We are exploring ways to see how user space can survive this.
> 
> -- 
> With best wishes
> Dmitry

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

[Dmitry Baryshkov]

On Mon, Jan 19, 2026 at 11:25:31AM -0600, Bjorn Andersson wrote:
> On Mon, Jan 19, 2026 at 07:20:09PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Jan 19, 2026 at 04:56:32PM +0000, Sudeep Holla wrote:
> > > On Mon, Jan 19, 2026 at 06:44:23PM +0200, Dmitry Baryshkov wrote:
> > > > On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote:
> > > > > On Sun, Jan 18, 2026 at 03:16:50PM -0600, Bjorn Andersson wrote:
> > > > > > On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> > > > > > 
> > > > > > To me, when you decided to add a second caller to soc_device_register()
> > > > > > you created a regression in the userspace interface. If nothing else
> > > > > > it's a leaky abstraction.
> > > > > > 
> > > > > 
> > > > > In that case, shouldn't soc_device_register() made to give error when an
> > > > > attempt to call it more that one time then ? Also should be change the
> > > > > ABI documents to refer it as soc0 and not socX ?
> > > > 
> > > > Then the whole SoC bus is an overkill. But I have a strange question
> > > > here. Consider the device having the "BT / WiFi SoC" next to the main
> > > > SoC. Is that SoC a legit target to export informaiton through sysfs /
> > > > soc bus?
> > > > 
> > > 
> > > Just for clarity, I agree with you and there could be duplication of
> > > information if there are multiple source for that information. E.g.,
> > > the setup in this discussion where the EL3 firmware provides SOC_ID
> > > information via SMCCC SOC_ID and DT providing vendor specific information
> > > about the platform. Both are getting exported via sysfs but the problem
> > > here is SOC_ID has displaced vendor specific DT info from soc0 to soc1.
> > 
> > I understand the context and I understand that we ended up having two
> > soc devices for the main SoC. And that's exactly why I'm asking about
> > the WCN SoC exporting the information through the same interface. If it
> > is a legit user, then it is a possible outcome that WCN binds to soc0
> > while the main core gets bound to soc1 (even without SMCCC_ID in place).
> > 
> > Likewise if WCN if a legit user of soc_device_register(), then we can't
> > make it fail after registering the first entry.
> > 
> 
> But by this definition, a vast variety of discrete IP should register
> with this interface - instead of providing such information in their
> respective functional interface.

I *suppose* that was the intention. Otherwise there is little point in
having socX defined in the ABI.

> 
> My interpretation is that the soc_device_register() related to the
> entity which is represented as /soc in your DeviceTree.
> 
> For a broader "dumping ground for different IP to register their
> version information", we'd need some way to associate each entity with
> the related component - which I believe there is none, because then you
> could have used the specific driver interface in the first place.

We can be using of_node / fwnode pointers for that (where available).
However, I guess, there would be no fwnode for SMCCC SOC_ID.

> (I.e. there's no representation of the WCN SoC in our system, we have
> representations for the PMU, the WiFi, and the BT core, but not the
> whole).

The mapping is really a separate topic. I can imagine "just an
enumeration" kind of ABI.

-- 
With best wishes
Dmitry

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

[Bjorn Andersson]

On Mon, Jan 19, 2026 at 09:46:08PM +0200, Dmitry Baryshkov wrote:
> On Mon, Jan 19, 2026 at 11:25:31AM -0600, Bjorn Andersson wrote:
> > On Mon, Jan 19, 2026 at 07:20:09PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, Jan 19, 2026 at 04:56:32PM +0000, Sudeep Holla wrote:
> > > > On Mon, Jan 19, 2026 at 06:44:23PM +0200, Dmitry Baryshkov wrote:
> > > > > On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote:
> > > > > > On Sun, Jan 18, 2026 at 03:16:50PM -0600, Bjorn Andersson wrote:
> > > > > > > On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> > > > > > > 
> > > > > > > To me, when you decided to add a second caller to soc_device_register()
> > > > > > > you created a regression in the userspace interface. If nothing else
> > > > > > > it's a leaky abstraction.
> > > > > > > 
> > > > > > 
> > > > > > In that case, shouldn't soc_device_register() made to give error when an
> > > > > > attempt to call it more that one time then ? Also should be change the
> > > > > > ABI documents to refer it as soc0 and not socX ?
> > > > > 
> > > > > Then the whole SoC bus is an overkill. But I have a strange question
> > > > > here. Consider the device having the "BT / WiFi SoC" next to the main
> > > > > SoC. Is that SoC a legit target to export informaiton through sysfs /
> > > > > soc bus?
> > > > > 
> > > > 
> > > > Just for clarity, I agree with you and there could be duplication of
> > > > information if there are multiple source for that information. E.g.,
> > > > the setup in this discussion where the EL3 firmware provides SOC_ID
> > > > information via SMCCC SOC_ID and DT providing vendor specific information
> > > > about the platform. Both are getting exported via sysfs but the problem
> > > > here is SOC_ID has displaced vendor specific DT info from soc0 to soc1.
> > > 
> > > I understand the context and I understand that we ended up having two
> > > soc devices for the main SoC. And that's exactly why I'm asking about
> > > the WCN SoC exporting the information through the same interface. If it
> > > is a legit user, then it is a possible outcome that WCN binds to soc0
> > > while the main core gets bound to soc1 (even without SMCCC_ID in place).
> > > 
> > > Likewise if WCN if a legit user of soc_device_register(), then we can't
> > > make it fail after registering the first entry.
> > > 
> > 
> > But by this definition, a vast variety of discrete IP should register
> > with this interface - instead of providing such information in their
> > respective functional interface.
> 
> I *suppose* that was the intention. Otherwise there is little point in
> having socX defined in the ABI.
> 
> > 
> > My interpretation is that the soc_device_register() related to the
> > entity which is represented as /soc in your DeviceTree.
> > 
> > For a broader "dumping ground for different IP to register their
> > version information", we'd need some way to associate each entity with
> > the related component - which I believe there is none, because then you
> > could have used the specific driver interface in the first place.
> 
> We can be using of_node / fwnode pointers for that (where available).
> However, I guess, there would be no fwnode for SMCCC SOC_ID.
> 

I prefer a model where the kernel abstracts the hardware and firmware
away from userspace, and presents useful and purposeful information to
the applications.


When I cat /proc/cpuinfo I get an abstract representation of the CPU
cores that are visible to the current system, I don't have to
cross-reference the output against some hardware/firmware description
table to make sense of the data.

It could have told me about the CPU core(s?) in the WCN chip dangling
off that PCIe link...but it would also have made the output absolutely
useless.

> > (I.e. there's no representation of the WCN SoC in our system, we have
> > representations for the PMU, the WiFi, and the BT core, but not the
> > whole).
> 
> The mapping is really a separate topic. I can imagine "just an
> enumeration" kind of ABI.
> 

Let's imagine a more concrete example. I'm implementing some service and
I want to use the value from the "serial_number" soc attribute to
identify the device. I read soc[012]/serial_number and get 3 different
answers (in "random" order!).

Would that interface be useful to you without any form of means to
determine which set of attributes is representing which "SoC"?

Regards,
Bjorn

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

[Bjorn Andersson]

On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote:
> On Sun, Jan 18, 2026 at 03:16:50PM -0600, Bjorn Andersson wrote:
> > On Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> > > On Fri, Jan 16, 2026 at 03:53:57PM -0800, Trilok Soni wrote:
> > > > 
> > > > I believe that point(s) we have not touched upon are following:
> > > > 
> > > > There will be thousands of Android applications using the native interfaces
> > > > in the playstore in various regions like US and China and so on, which relies
> > > > on getting the SOC_ID to understand the product and enable / disable some features.
> > > > 
> > > > For example, benchmarks like GeekBench or Antutu may also be reading these
> > > > interfaces.
> > > > 
> > > > There are apps. in certain regions which are still not updated from "32-bit"
> > > > to 64-bit on Android yet as an example and there may be no way to reach out
> > > > to those developers to fix but apps. are still used by many users.  
> > > > 
> > > 
> > > Fair enough, but apps get updated on Android phones every day. So sorry if I
> > > don’t consider this as something impossible. I do understand many apps are not
> > > actively developed, yet that is no reason to say the wrong assumptions made by
> > > these apps are correct.
> > > 
> > 
> > It might be what you're saying is true, at least for the top-10
> > applications in the app store. But that is not how we manage or maintain
> > the userspace interface in the Linux kernel - we don't break userspace.
> > 
> 
> Agreed, but I still think socX != soc0 and that is wrong assumption by the
> application. Anyways, if more people think it is user-space break, I accept
> it.
> 
> > > > If we need to move all of these third-party applications to this new interface
> > > > then we have to "break them" before we fix them. Do we want to have such approach?
> > > > 
> > > 
> > > Sorry, which new interface are you referring to?
> > > Are we still talking about /sys/devices/socX/?
> > > If so, are you suggesting that X=0 and X=1 represent two different interfaces?
> > > If that’s the case, I honestly have no words.
> > > 
> > 
> > Please do have words, because I really would like to understand what the
> > expectation of userspace is in the even that there's both soc0 and soc1,
> > regardless of which is which.
> > 
> 
> OK if we are going there, can we blame the firmware for exposing this
> information which is standard ? Sorry to repeat by firmware is exporting
> that info in OS agnostic way and other OSes use that as the information as
> it is standard way. Why can't we make Linux use or work with that information
> as that removes all these vendor specific fragmentation created over years.

I certainly don't blame the firmware for providing a generic interface
for exposing such information, it sounds like a good idea to me. My
concern is that we're not "abstracting" this away from the applications,
within the kernel.

I think the UAPI should provide one answer to the question "what target
am I on right now" - not two (or N) different answers.

> This point is orthogonal to user-space break.
> 

With multiple socX instances exposed the UAPI no longer matches my
interpretation of its purpose (feel free to tell me that I have
misunderstood the purpose).

> > What does it even mean to have two different socs presented here? How
> > would userspace know which one to refer to? Should it refer to both and
> > guess which one makes more sense to it?
> > 
> 
> Yes, the standard interface doesn't have much info though, so it could be
> union of it if the applications prefer that way.
> 
> > 
> > To me, when you decided to add a second caller to soc_device_register()
> > you created a regression in the userspace interface. If nothing else
> > it's a leaky abstraction.
> > 
> 
> In that case, shouldn't soc_device_register() made to give error when an
> attempt to call it more that one time then ?

Based on my understanding of the purpose, that seems reasonable to me.

> Also should be change the
> ABI documents to refer it as soc0 and not socX ?
> 

I'm still grappling with the thought of what does it actually mean to
find N socX nodes. Perhaps I'm wrong and the answer is that these are
just different blobs of soc information and userspace should consume
them all? (Just doesn't feel very user friendly to me).

Regards,
Bjorn

> > > > We should not have enabled this feature as "default y" in the first place and should
> > > > have kept it as "tristate" or kept it disabled in my opinion.
> > > > 
> > > 
> > > Sorry, but how do you envision this working with a single defconfig? Please
> > > consider the issues on platforms beyond the ones you’re focused on as well.
> > > 
> > 
> > Glad that we're on the same page regarding both defconfig and
> > our considerations.
> > 
> 
> Thanks.
> 
> -- 
> Regards,
> Sudeep

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

[Sudeep Holla]

On Mon, Jan 19, 2026 at 11:21:07AM -0600, Bjorn Andersson wrote:
> On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote:

[...]

> > 
> > OK if we are going there, can we blame the firmware for exposing this
> > information which is standard ? Sorry to repeat by firmware is exporting
> > that info in OS agnostic way and other OSes use that as the information as
> > it is standard way. Why can't we make Linux use or work with that information
> > as that removes all these vendor specific fragmentation created over years.
> 
> I certainly don't blame the firmware for providing a generic interface
> for exposing such information, it sounds like a good idea to me. My
> concern is that we're not "abstracting" this away from the applications,
> within the kernel.
> 

I see your point, but the purpose of the SOC_ID interface is to avoid encoding
vendor-specific interpretation in the kernel and to push that problem to
userspace. If we now need the kernel to provide an abstraction based on
vendor-specific information from the device tree and SOC_ID information from
the firmware, then I don’t think that’s feasible - SOC_ID was designed
specifically so that the kernel wouldn’t interpret it.

> I think the UAPI should provide one answer to the question "what target
> am I on right now" - not two (or N) different answers.
> 

I’m not sure that’s an exact match for the question. The socX nodes simply
indicate which SoCs are present and expose the associated identification
information for the system that’s running. It’s not clear whether this is
limited to the application processor only, whether it can also include I/O
components, or whether the identifier is required to be unique.

> > This point is orthogonal to user-space break.
> > 
> 
> With multiple socX instances exposed the UAPI no longer matches my
> interpretation of its purpose (feel free to tell me that I have
> misunderstood the purpose).
> 

I can’t say that you’ve misunderstood it; it may be that I’m misunderstanding
it. My interpretation is that it provides information about all the SoCs on
the system. That could include multiple instances of the same SoC, different
variants, or even I/O chips such as Bluetooth or Wi-Fi. That’s my take on the
socX nodes, but I may be wrong.

> > > What does it even mean to have two different socs presented here? How
> > > would userspace know which one to refer to? Should it refer to both and
> > > guess which one makes more sense to it?
> > > 
> > 
> > Yes, the standard interface doesn't have much info though, so it could be
> > union of it if the applications prefer that way.
> > 
> > > 
> > > To me, when you decided to add a second caller to soc_device_register()
> > > you created a regression in the userspace interface. If nothing else
> > > it's a leaky abstraction.
> > > 
> > 
> > In that case, shouldn't soc_device_register() made to give error when an
> > attempt to call it more that one time then ?
> 
> Based on my understanding of the purpose, that seems reasonable to me.
> 

It's exactly opposite based on my understanding though 😉.

> > Also should be change the
> > ABI documents to refer it as soc0 and not socX ?
> > 
> 
> I'm still grappling with the thought of what does it actually mean to
> find N socX nodes. Perhaps I'm wrong and the answer is that these are
> just different blobs of soc information and userspace should consume
> them all? (Just doesn't feel very user friendly to me).
> 

Why ? If the intention was to provide as much information as possible
about the running system.

-- 
Regards,
Sudeep

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

[Bjorn Andersson]

On Fri, Jan 16, 2026 at 12:53:18PM -0800, Satya Durga Srinivasu Prabhala wrote:
> Hello Sudeep,
> 
> Thanks for the discussion & feedback.
> 
> Wanted to check on below possibilities to disable the SMCCC SOC ID at the
> vendor end, can you help comment?
> 1. Introduce cmdline option
>    We are trying to pursue that in Android Kernel -
> https://android-review.googlesource.com/c/kernel/common/+/3912874
> 2. Mark SMCCC SMC ID driver as tristate & module as suggested by Dmitry

What happens when I boot a system with module autoloading?

What is the expected behavior of userspace when it faces two soc nodes?

Regards,
Bjorn

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

[Neil Armstrong]

On 1/13/26 07:24, 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.
> 
> 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@oss.qualcomm.com>
> ---
>   drivers/firmware/smccc/Kconfig | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
> index 15e7466179a6..f830d11ebdca 100644
> --- a/drivers/firmware/smccc/Kconfig
> +++ b/drivers/firmware/smccc/Kconfig
> @@ -18,8 +18,11 @@ config HAVE_ARM_SMCCC_DISCOVERY
>   config ARM_SMCCC_SOC_ID
>   	bool "SoC bus device for the ARM SMCCC SOC_ID"
>   	depends on HAVE_ARM_SMCCC_DISCOVERY
> -	default y
> +	default n
>   	select SOC_BUS
>   	help
>   	  Include support for the SoC bus on the ARM SMCCC firmware based
>   	  platforms providing some sysfs information about the SoC variant.
> +	  Note: Several vendor platforms provide their own SoC information
> +	  drivers under drivers/soc/*. To avoid conflicting sysfs attribute
> +	  formats in /sys/devices/socX/*, this driver defaults to disabled.
> 
> ---
> base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73
> change-id: 20260112-disable_smccc_soc_id-ed09ef4d777f
> 
> Best regards,

Disabling it by default impacts other platforms, the arm64 kernel is designed
to be generic and run on any platform with defconfig and from the same build,
please don't forget that.

If you want to ship an arm64 kernel tailored for Qualcomm platforms, you're
allowed, and you're also allowed to disable ARM_SMCCC_SOC_ID.

The soc sysfs interface is designed to support multiple source of information,
from vendor (like qcom socinfo) and smccc ID. And this is well documented,
and pretty obvious...

Neil

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

[Sudeep Holla]

On Wed, Jan 14, 2026 at 06:12:29PM +0100, Neil Armstrong wrote:
> On 1/13/26 07:24, 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.
> > 
> > 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@oss.qualcomm.com>
> > ---
> >   drivers/firmware/smccc/Kconfig | 5 ++++-
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
> > index 15e7466179a6..f830d11ebdca 100644
> > --- a/drivers/firmware/smccc/Kconfig
> > +++ b/drivers/firmware/smccc/Kconfig
> > @@ -18,8 +18,11 @@ config HAVE_ARM_SMCCC_DISCOVERY
> >   config ARM_SMCCC_SOC_ID
> >   	bool "SoC bus device for the ARM SMCCC SOC_ID"
> >   	depends on HAVE_ARM_SMCCC_DISCOVERY
> > -	default y
> > +	default n
> >   	select SOC_BUS
> >   	help
> >   	  Include support for the SoC bus on the ARM SMCCC firmware based
> >   	  platforms providing some sysfs information about the SoC variant.
> > +	  Note: Several vendor platforms provide their own SoC information
> > +	  drivers under drivers/soc/*. To avoid conflicting sysfs attribute
> > +	  formats in /sys/devices/socX/*, this driver defaults to disabled.
> > 
> > ---
> > base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73
> > change-id: 20260112-disable_smccc_soc_id-ed09ef4d777f
> > 
> > Best regards,
> 
> Disabling it by default impacts other platforms, the arm64 kernel is designed
> to be generic and run on any platform with defconfig and from the same build,
> please don't forget that.
> 
> If you want to ship an arm64 kernel tailored for Qualcomm platforms, you're
> allowed, and you're also allowed to disable ARM_SMCCC_SOC_ID.
> 

Exactly!

> The soc sysfs interface is designed to support multiple source of information,
> from vendor (like qcom socinfo) and smccc ID. And this is well documented,
> and pretty obvious...
> 

Indeed, otherwise soc_device_register() would have failed for more than one
calls to it if that was the design/intention.

-- 
Regards,
Sudeep

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

[Satya Durga Srinivasu Prabhala]

Hello Neil,

On 1/14/2026 9:12 AM, Neil Armstrong wrote:
> On 1/13/26 07:24, 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.
>>
>> 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@oss.qualcomm.com>
>> ---
>>   drivers/firmware/smccc/Kconfig | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/smccc/Kconfig 
>> b/drivers/firmware/smccc/Kconfig
>> index 15e7466179a6..f830d11ebdca 100644
>> --- a/drivers/firmware/smccc/Kconfig
>> +++ b/drivers/firmware/smccc/Kconfig
>> @@ -18,8 +18,11 @@ config HAVE_ARM_SMCCC_DISCOVERY
>>   config ARM_SMCCC_SOC_ID
>>       bool "SoC bus device for the ARM SMCCC SOC_ID"
>>       depends on HAVE_ARM_SMCCC_DISCOVERY
>> -    default y
>> +    default n
>>       select SOC_BUS
>>       help
>>         Include support for the SoC bus on the ARM SMCCC firmware based
>>         platforms providing some sysfs information about the SoC 
>> variant.
>> +      Note: Several vendor platforms provide their own SoC information
>> +      drivers under drivers/soc/*. To avoid conflicting sysfs attribute
>> +      formats in /sys/devices/socX/*, this driver defaults to disabled.
>>
>> ---
>> base-commit: b71e635feefc852405b14620a7fc58c4c80c0f73
>> change-id: 20260112-disable_smccc_soc_id-ed09ef4d777f
>>
>> Best regards,
>
> Disabling it by default impacts other platforms, the arm64 kernel is 
> designed
> to be generic and run on any platform with defconfig and from the same 
> build,
> please don't forget that.

Thanks.

> If you want to ship an arm64 kernel tailored for Qualcomm platforms, 
> you're
> allowed, and you're also allowed to disable ARM_SMCCC_SOC_ID.

Not entirely true. Say in case of Android / GKI, ARM_SMCCC_SOC_ID gets 
enabled
by default and we do not have a way to disable it.

> The soc sysfs interface is designed to support multiple source of 
> information,
> from vendor (like qcom socinfo) and smccc ID. And this is well 
> documented,
> and pretty obvious...

Yes, it is indeed obvious. The point to note is vendor interface existed
from long time and unfortunately user space had made certain assumptions.
All, we need is a way for vendor to choose which interface to be provided
to user space to make sure user space isn't broken.

> Neil