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: <aWY6kx8Bwa_2azIl@bogus>
Date: Tue, 13 Jan 2026 12:29:07 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Satya Durga Srinivasu Prabhala <satya.prabhala@....qualcomm.com>
Cc: Mark Rutland <mark.rutland@....com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Sudeep Holla <sudeep.holla@....com>, 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 12, 2026 at 10:24:06PM -0800, Satya Durga Srinivasu Prabhala wrote:
> The ARM SMCCC SoC ID driver is currently enabled by default and publishes
> SMCCC-provided SoC identification into /sys/bus/soc/devices/socX/*.
> 
> On platforms where a vendor SoC driver already exposes widely-consumed
> attributes (e.g. Qualcomm socinfo [1]), enabling the SMCCC driver changes
> the format of /sys/devices/soc0/soc_id (e.g. "jep106:XXYY:ZZZZ" instead
> of a vendor logical ID like "519") and breaks existing userspace consumers.
> 

Instead of relying on a vendor-specific SoC driver, we should consider
disabling it and using the OS-agnostic SoC information interface provided by
the firmware. The presence of this interface strongly suggests that the
firmware is designed to support multiple operating systems or software stacks
that already depend on it. Aligning the Linux kernel with this
firmware-defined, OS-agnostic mechanism would reduce vendor-specific
dependencies and improve portability. Any gaps can be addressed by enhancing
userspace to correctly parse and consume this information. Given these
advantages, why would this approach not be the better long-term solution?

-- 
Regards,
Sudeep