From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8372FCD8C9D for ; Mon, 8 Jun 2026 11:26:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=mN+u0pCJSsPAoXFbYCcI3ncWrm0wZKcAiKPT7u/ARIY=; b=i66CBKJTS/VPLe7NJQgnmjdqLn 7/m3QANnh6CKuW9HyScT5xsYnoVp49JhXvyw/4SL8zHMZwXDTDNPddVsq5MnytLD9CMuB9nX+63rt 7vZFc9pMbY9LU3i/70Tk/wyPpqeUJPgsW5eKX6xzgCRvuYe066uFziG1Y0zci8UpViG7pXHvn8VY1 mB84bEE29N7SSiKqp73UoQ+XyKcSqOdh+yhPDsv1QjzDzllqyJarQ7x9CHk7tkbKlTY+S3TC714jG dp6zozr36WwdJ1wgORJFdsbSpMExUpreYsGFj+uzXZ5VU4v9Y/V3CHE7rxLVwp1b+6x9igA9OkiA2 1mMX8Ndw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wWY7s-00000003QM8-3SbN; Mon, 08 Jun 2026 11:26:40 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wWY7r-00000003QM1-0tAw for linux-arm-kernel@lists.infradead.org; Mon, 08 Jun 2026 11:26:39 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id A8F3340674; Mon, 8 Jun 2026 11:26:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 246951F00893; Mon, 8 Jun 2026 11:26:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780917998; bh=mN+u0pCJSsPAoXFbYCcI3ncWrm0wZKcAiKPT7u/ARIY=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=mT3HVqaw3DuU9tlhMrY09QOQltV352yiglepQMcHm1SLLiT/ypbKxV45DUzvAKld8 EgGc4D5icVebi8W9iO1+Ms150cbeb7qE6vmDzUFOy0iqcvpIzEoHKvsOnSvANbhBCU YXQR3kHpKdx7v6wtMdhC9GbGkVcL8GT5egeSbhRBFj4Nl2BpotRLND1c43xt6Hd7/d e1yImNR4cPh8ikhKGwRxWIMpYHZKO1EejAwZbDUenP6/OiXIXKFnn6fROU/l0RJQnR Apj2v3s+UBe3X/kCk1+VkwAxJ6TbpQkE67WclAO6R8hShS3KldHQF117mEixaxtveo A3ECAMAWS50Xg== X-Mailer: emacs 30.2 (via feedmail 11-beta-1 I) From: Aneesh Kumar K.V To: Suzuki K Poulose , Sudeep Holla Cc: linux-coco@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Catalin Marinas , Greg KH , Jeremy Linton , Jonathan Cameron , Lorenzo Pieralisi , Mark Rutland , Will Deacon , Steven Price Subject: Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device In-Reply-To: References: <20260527100233.428018-1-aneesh.kumar@kernel.org> <20260527100233.428018-4-aneesh.kumar@kernel.org> <20260603-determined-bumblebee-of-promise-e633d6@sudeepholla> <20260604-juicy-daft-starling-3eec1f@sudeepholla> Date: Mon, 08 Jun 2026 16:56:29 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Suzuki K Poulose writes: > On 08/06/2026 09:19, Aneesh Kumar K.V wrote: >> Sudeep Holla writes: >> >>> On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote: >>>> Sudeep Holla writes: >>>> >>>> ... ... >>> I was trying to avoid conditional compilation altogether and hence the >>> reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64) >>> in above snippet must come as some condition to this generic probe. >>> >>> Adding any more logic or callback defeats the bus idea here if we need >>> to rely/depend on multiple conditional compilation or callbacks IMO. >>> >>> Let's find see if it can work with what we are adding now and may add in >>> near future and then decide. >>> >> >> If we move all the conditional checks to the driver probe path, then I >> think this can work. Something like the below: >> >> struct smccc_device_info { >> u32 func_id; >> bool requires_smc; >> const char *device_name; >> }; >> >> static const struct smccc_device_info smccc_devices[] __initconst = { >> { >> .func_id = ARM_SMCCC_TRNG_VERSION, >> .requires_smc = false, >> .device_name = "arm-smccc-trng", >> }, >> >> { >> .func_id = RSI_ABI_VERSION, > > Don't we need parameters passed to this (Requested Interface version for > e.g.) ? See more below. > The idea is that we only check whether the function ID is supported. All other conditional logic should be handled in the driver probe path, as demonstrated by the changes in drivers/char/hw_random/arm_smccc_trng.c. > >> .requires_smc = true, >> .device_name = RSI_DEV_NAME, >> }, >> }; >> >> static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev) >> { >> unsigned long ret; >> struct arm_smccc_res res; >> >> if (smccc_conduit == SMCCC_CONDUIT_NONE) >> return false; >> >> if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC) >> return false; >> >> arm_smccc_1_1_invoke(smccc_dev->func_id, &res); >> ret = res.a0; >> >> if ((s32)ret == SMCCC_RET_NOT_SUPPORTED) > > Is this a reliable check for all possible SMCCC services ? i.e., Are we > expected to get RET_NOT_SUPPORTED for any service for which the backend > is not available ? > That is correct. That is what the SMCCC specification says > Also, as pointed out RSI_ABI_VERSION may return other errors based on > the input (requested version, e.g., RSI_ERROR_INPUT) and we may still go > ahead and register the device ? > Correct, and the driver probe will check for the minimum and maximum supported versions. >> return false; >> >> return true; >> } >> >> static int __init smccc_devices_init(void) >> { >> struct arm_smccc_device *sdev; >> const struct smccc_device_info *smccc_dev; >> >> for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) { >> smccc_dev = &smccc_devices[i]; >> >> if (!smccc_probe_smccc_device(smccc_dev)) >> continue; >> >> sdev = arm_smccc_device_register(smccc_dev->device_name); >> if (IS_ERR(sdev)) >> pr_err("%s: could not register device: %ld\n", >> smccc_dev->device_name, PTR_ERR(sdev)); >> >> } >> >> return 0; >> } >> device_initcall(smccc_devices_init); >> >> with the diff to hw_random/smccc_trng >> >> modified arch/arm64/include/asm/archrandom.h >> @@ -12,7 +12,7 @@ >> >> extern bool smccc_trng_available; >> >> -static inline bool __init smccc_probe_trng(void) >> +static inline bool smccc_probe_trng(void) >> { >> struct arm_smccc_res res; >> >> modified drivers/char/hw_random/arm_smccc_trng.c >> @@ -19,6 +19,8 @@ >> #include >> #include >> >> +#include >> + >> #ifdef CONFIG_ARM64 >> #define ARM_SMCCC_TRNG_RND ARM_SMCCC_TRNG_RND64 >> #define MAX_BITS_PER_CALL (3 * 64UL) >> @@ -98,6 +100,10 @@ static int smccc_trng_probe(struct arm_smccc_device *sdev) >> { >> struct hwrng *trng; >> >> + /* validate the minimum version requirement */ >> + if (!smccc_probe_trng()) >> + return -ENODEV; >> + >> trng = devm_kzalloc(&sdev->dev, sizeof(*trng), GFP_KERNEL); >> if (!trng) >> return -ENOMEM; >> >> We can also move arch/arm64/include/asm/rsi_smc.h to >> include/linux/arm-rsi-smccc.h. There was a suggestion to move these > > super minor nit: arm-smccc-rsi.h ? > -aneesh