drivers/firmware/smccc/Kconfig | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
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>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
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
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
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
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
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
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
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
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
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
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
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
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 >
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
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
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
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
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
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
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
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
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
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 > >
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
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
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.
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
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(-) >>
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
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(-) >>>>
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.