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: <i4zd3jesjrbljym7xuhwo5v7gwbsbuesuarnxr462eeuosevij@64hcfdzht6w3>
Date: Mon, 19 Jan 2026 11:25:31 -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 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.

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.

(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).

Regards,
Bjorn

> > 
> > We are exploring ways to see how user space can survive this.
> 
> -- 
> With best wishes
> Dmitry