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

[Sudeep Holla <sudeep.holla@arm.com>]

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