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: <aWgG8EbNgn_wXPjh@bogus>
Date: Wed, 14 Jan 2026 21:13:20 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Satya Durga Srinivasu Prabhala <satya.prabhala@....qualcomm.com>
Cc: Will Deacon <will@...nel.org>, 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 Wed, Jan 14, 2026 at 08:58:01AM -0800, Satya Durga Srinivasu Prabhala wrote:
> Hello Will,
> 
> On 1/13/2026 2:57 AM, Will Deacon wrote:
> > 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.
> > Isn't the fundamental issue here that you have multiple callers of
> > soc_device_register() and your userspace is only looking at soc0?
> Yes, that is right. The issue is we have several products which already
> uses the soc0 interface as vendor interface [1] existed even before the
> SMCCC SCM ID [2]. Also, per SMCCC specification, SOC ID is an optional
> feature.

Yes it is optional and that means kernel won't complain if it is not
implemented in the firmware.

> So, vendor specific implementation can take precedence over
> standard implementation or a way to disable SMCCC SOC ID could help.
> 

Yet this vendor specific implementation chose to implement the optional
feature when it needed the vendor specific implementation can take precedence
over this. It had the choice and when it implemented it, it choose and
it can't expect the generic OS to ignore firmware standard interface
just because it has vendor specific implementation else where.

And one of the reasons some of the vendors needed this SOC_ID in the
SMCCC is o avoid or have precedence over any other interface(like DT/ACPI)
that can override or provide other information.

-- 
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ