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: <3ldzdsyspd3s6on3cwyanjeheegoeba6kn6qaybojtqeca7335@cyemyxk6kck4>
Date: Mon, 19 Jan 2026 19:20:09 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Bjorn Andersson <andersson@...nel.org>,
        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 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.

> 
> We are exploring ways to see how user space can survive this.

-- 
With best wishes
Dmitry