linux-kernel - Re: [PATCH] firmware: smccc: default ARM_SMCCC_SOC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2fmnaxj2ma2bb5iuuu4yzmenp3tsxjko6rziwuaaqr6rqvegbw@s4x6eiwhlkcm>
Date: Mon, 19 Jan 2026 21:46:08 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Bjorn Andersson <andersson@...nel.org>
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 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