From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3462A3D3300; Tue, 20 Jan 2026 17:47:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768931239; cv=none; b=fl50EHTt82WmiV79mQhm3Oe/K/f43Cri+al2f6PPdyQiGtCtDi9MOoXP+PklZdlNYOLGehske/7CGGWwblT+TAI8pj0X9lhdSx6CSA2A8EHwNbyjT4vTsICHk5Xd2l95xxrUdB540J3SXlnzsqu55pj6uPYIeO+WiahCMM+pLEU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768931239; c=relaxed/simple; bh=prfSr+SOyeMy+2AAU1lvXC5avOW1gknyG0WZ/nnDxYc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FV7mvDRXlJKlxiIEzfOhnxzDmrTtWDc2j7z3XbdUY170OSTr8PUVR4rm/tjmpbbxchdtfF6kWIiaukQcFOQLcZmb0uDzf+5a2HKqyzQjvszhQrsfaByLP3vUAkyMue8XJiSQoKlyYFBHWHlFwTvXvlOqoxBTLmxvi9dMVoulaWQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=foss.arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=foss.arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E20F91476; Tue, 20 Jan 2026 09:47:09 -0800 (PST) Received: from bogus (e124108.arm.com [10.1.35.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C1D803F632; Tue, 20 Jan 2026 09:47:14 -0800 (PST) Date: Tue, 20 Jan 2026 17:47:11 +0000 From: Sudeep Holla To: Bjorn Andersson Cc: Trilok Soni , Satya Durga Srinivasu Prabhala , Mark Rutland , Sudeep Holla , Lorenzo Pieralisi , linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, trilok.soni@oss.qualcomm.com Subject: Re: [PATCH] firmware: smccc: default ARM_SMCCC_SOC_ID to disabled Message-ID: References: <86331062-301b-40b1-9df1-78f7751508b4@oss.qualcomm.com> <4fab824f-8067-49d7-8e6c-dedd67a8454d@oss.qualcomm.com> <92d90a1e-e993-4044-b152-83a8700f7b63@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Jan 19, 2026 at 11:21:07AM -0600, Bjorn Andersson wrote: > On Mon, Jan 19, 2026 at 02:53:42PM +0000, Sudeep Holla wrote: [...] > > > > OK if we are going there, can we blame the firmware for exposing this > > information which is standard ? Sorry to repeat by firmware is exporting > > that info in OS agnostic way and other OSes use that as the information as > > it is standard way. Why can't we make Linux use or work with that information > > as that removes all these vendor specific fragmentation created over years. > > I certainly don't blame the firmware for providing a generic interface > for exposing such information, it sounds like a good idea to me. My > concern is that we're not "abstracting" this away from the applications, > within the kernel. > I see your point, but the purpose of the SOC_ID interface is to avoid encoding vendor-specific interpretation in the kernel and to push that problem to userspace. If we now need the kernel to provide an abstraction based on vendor-specific information from the device tree and SOC_ID information from the firmware, then I don’t think that’s feasible - SOC_ID was designed specifically so that the kernel wouldn’t interpret it. > I think the UAPI should provide one answer to the question "what target > am I on right now" - not two (or N) different answers. > I’m not sure that’s an exact match for the question. The socX nodes simply indicate which SoCs are present and expose the associated identification information for the system that’s running. It’s not clear whether this is limited to the application processor only, whether it can also include I/O components, or whether the identifier is required to be unique. > > This point is orthogonal to user-space break. > > > > With multiple socX instances exposed the UAPI no longer matches my > interpretation of its purpose (feel free to tell me that I have > misunderstood the purpose). > I can’t say that you’ve misunderstood it; it may be that I’m misunderstanding it. My interpretation is that it provides information about all the SoCs on the system. That could include multiple instances of the same SoC, different variants, or even I/O chips such as Bluetooth or Wi-Fi. That’s my take on the socX nodes, but I may be wrong. > > > 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? > > > > > > > Yes, the standard interface doesn't have much info though, so it could be > > union of it if the applications prefer that way. > > > > > > > > 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 ? > > Based on my understanding of the purpose, that seems reasonable to me. > It's exactly opposite based on my understanding though 😉. > > Also should be change the > > ABI documents to refer it as soc0 and not socX ? > > > > I'm still grappling with the thought of what does it actually mean to > find N socX nodes. Perhaps I'm wrong and the answer is that these are > just different blobs of soc information and userspace should consume > them all? (Just doesn't feel very user friendly to me). > Why ? If the intention was to provide as much information as possible about the running system. -- Regards, Sudeep