Message-ID: <ta63kpklakanlc6dnmsqgr7u2o3ghdnt7uyyu3obbjask2voyv@eu6rhwhqzeyv>
Date: Mon, 19 Jan 2026 14:25:38 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Sudeep Holla <sudeep.holla@....com>, 
	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 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

Powered by blists - more mailing lists