Message-ID: <qv2do4mmxrlspkr2b2vzsozedxzdocoyapymll63laowljue3d@ycq3mlxrrllt>
Date: Mon, 19 Jan 2026 11:21:07 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Trilok Soni <trilokkumar.soni@....qualcomm.com>, 
	Satya Durga Srinivasu Prabhala <satya.prabhala@....qualcomm.com>, Mark Rutland <mark.rutland@....com>, 
	Lorenzo Pieralisi <lpieralisi@...nel.org>, linux-arm-msm@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, trilok.soni@....qualcomm.com
Subject: Re: [PATCH] firmware: smccc: default ARM_SMCCC_SOC_ID to disabled

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

Powered by blists - more mailing lists