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] [day] [month] [year] [list]

Message-ID: <mzs5vq2jsrmb6kdriuxawbamyim6dhgy34ne6tucnhlalt5y3w@ghckxur3cn6m>
Date: Sun, 18 Jan 2026 15:16:50 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: 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 Sun, Jan 18, 2026 at 02:31:23PM +0000, Sudeep Holla wrote:
> On Fri, Jan 16, 2026 at 03:53:57PM -0800, Trilok Soni wrote:
> > 
> > I believe that point(s) we have not touched upon are following:
> > 
> > There will be thousands of Android applications using the native interfaces
> > in the playstore in various regions like US and China and so on, which relies
> > on getting the SOC_ID to understand the product and enable / disable some features.
> > 
> > For example, benchmarks like GeekBench or Antutu may also be reading these
> > interfaces.
> > 
> > There are apps. in certain regions which are still not updated from "32-bit"
> > to 64-bit on Android yet as an example and there may be no way to reach out
> > to those developers to fix but apps. are still used by many users.  
> > 
> 
> Fair enough, but apps get updated on Android phones every day. So sorry if I
> don’t consider this as something impossible. I do understand many apps are not
> actively developed, yet that is no reason to say the wrong assumptions made by
> these apps are correct.
> 

It might be what you're saying is true, at least for the top-10
applications in the app store. But that is not how we manage or maintain
the userspace interface in the Linux kernel - we don't break userspace.

> > If we need to move all of these third-party applications to this new interface
> > then we have to "break them" before we fix them. Do we want to have such approach?
> > 
> 
> Sorry, which new interface are you referring to?
> Are we still talking about /sys/devices/socX/?
> If so, are you suggesting that X=0 and X=1 represent two different interfaces?
> If that’s the case, I honestly have no words.
> 

Please do have words, because I really would like to understand what the
expectation of userspace is in the even that there's both soc0 and soc1,
regardless of which is which.

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?


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.

> > We should not have enabled this feature as "default y" in the first place and should
> > have kept it as "tristate" or kept it disabled in my opinion.
> > 
> 
> Sorry, but how do you envision this working with a single defconfig? Please
> consider the issues on platforms beyond the ones you’re focused on as well.
> 

Glad that we're on the same page regarding both defconfig and
our considerations.

Regards,
Bjorn

> -- 
> Regards,
> Sudeep
>