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

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

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