From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazon11011005.outbound.protection.outlook.com [52.101.52.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67CBC395AF2 for ; Thu, 9 Jul 2026 07:45:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.52.5 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783583134; cv=fail; b=cQEQ31HgeAN5iHHxunLBvHvftTQkm/cxUeZFmdC2AA0kjC5CXP4eGLJQZLYcP9AX0VRd0PH5NBZSXO/eOjCVeaelJnqatylmmKJQiQXHVmbjFCIFidwAjeStgX3mnL7pUg8Grbs9+RIDE7YfJbooaznI78i4wzhLfvudIyuRMB8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783583134; c=relaxed/simple; bh=eMwL4e8+PbJ2d6xYKfyx8JjXbVYiXEllKBhZGwoWrd4=; h=Message-ID:Date:Cc:Subject:To:References:From:In-Reply-To: Content-Type:MIME-Version; b=il5irDrrs2RWJqSDAev/xzoJ3agVREicY4oOXlfqutN/PipZW644Iie7yzfTSlLynZWdSB9vbWNfYL/KjLY3jQzeTUMxuaG26VtoRQTtT293pXGwVIzDM2VR8EphZR3yvLJ+4MOK9jcAp+XMFuIADt3FHe0Wd6JPGHwI+JdLdP0= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=altera.com; spf=pass smtp.mailfrom=altera.com; dkim=pass (2048-bit key) header.d=altera.com header.i=@altera.com header.b=jzpbHO+g; arc=fail smtp.client-ip=52.101.52.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=altera.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=altera.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=altera.com header.i=@altera.com header.b="jzpbHO+g" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OaLeFE28P4MXcIXVnbrUm1/sps6nGR++DNb+H3QQRcb7AGP4rHPpKX9Qm2UJJghmO+pFbZCJL6YIM/K4J7dxRxsH4a/KFJ4WbCgWgLvjq3sqVX1wUPufpPeb9c3FK40etO5x8Rihc1T3Fl0oFL6LgxUBMXEpKOa7qVXMmxHNIHjhdb+D8ktPz+7TJFPxLFzGDxA+/CQ7fOra2Uq96NsWBAHofPBYRhWsTA0IYG3yamrDmD2fseRjn36F5z/NKOIAhi1oodw03Z0gGIbDZxKw+C2ozbk715aRu6hBAjDIDOCVzuPCZnXVCWaA7TPNxjlNgA6Se1jtJ4XjjUICdrKaDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rewO7doiKJfJMN2AI4749Ucr85qs+3CSRwsShd2PEH4=; b=BldheqhpfE4hkvgfeM+dy2/s7NSgfVmlxUHt0VC4TEdZhgPA1HfWrXQemFOcztjO1RqqHfWeD7b9Fii7MMHulpOpMErCF175MSCVSjEF0ExSnUbW2LtBFi0QhtNiokL/gpDcxB35p98mCJl613Fl45snIqahW1KtLXSDKrR9K5lc8sEQEX6vscXrmAfEdjev+h+fY8Hkz5AL3CqkYCQJFBfxpT0t161rBekpT8lrN/MuMuvCYhcAlZI7NMXlqv/X9iXvtQbuo8aOfL+OHpOoPm7pmRlsQEwchl9aFWHgn7E4ql2FWHBCzPv61497pCz68MppfHTAQBhyggzZSrhMgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=altera.com; dmarc=pass action=none header.from=altera.com; dkim=pass header.d=altera.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=altera.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rewO7doiKJfJMN2AI4749Ucr85qs+3CSRwsShd2PEH4=; b=jzpbHO+glzEgcVzHs3S2YncHtgOuF4bZ0wKBdRiMqLrfITDTv+uCi0XhhfPHG3mJ1886GC2njcV1KMeBoucA60Q58RGvxryyBy1tHeg6wtpBrXf8TZqTu1a8H+WbQ7OEA16i3EKX+XQMeUzZ9TWcBLIFLSo1QSLgDCXg9ztDMkREpjPfzNJO4u26F2Uw7vod9BSViJP2q01uGi3MZAmd+DBENLm8BbenJlaBDmgvyk7bCNRT/RNAyIdoKVT6cLcEOZw9pNR0ah1Va1IRAYbG/2lEclROTYq3RR5HInleI26dPqPxmdrphzgdWUZub3CACzbwUt+a8h1cB0HAsapvyQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=altera.com; Received: from PH0PR03MB6560.namprd03.prod.outlook.com (2603:10b6:510:b2::12) by SJ0PR03MB5902.namprd03.prod.outlook.com (2603:10b6:a03:2da::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.15; Thu, 9 Jul 2026 07:45:28 +0000 Received: from PH0PR03MB6560.namprd03.prod.outlook.com ([fe80::5364:bd7:85a:f07b]) by PH0PR03MB6560.namprd03.prod.outlook.com ([fe80::5364:bd7:85a:f07b%5]) with mapi id 15.21.0181.014; Thu, 9 Jul 2026 07:45:27 +0000 Message-ID: <4996ef0c-1157-4bfe-b315-212fb63d6696@altera.com> Date: Thu, 9 Jul 2026 15:45:19 +0800 User-Agent: Mozilla Thunderbird Cc: hang.suan.wang@altera.com, muhammad.nazim.amirul.nazle.asmade@altera.com, tze.yee.ng@altera.com, chee.nouk.phoon@altera.com, genevieve.chan@altera.com Subject: Re: [PATCH v1 0/2] Add Altera SoCFPGA Crypto Service (FCS) driver To: Dinh Nguyen , linux-kernel@vger.kernel.org, "Michael S . Tsirkin" , Huacai Chen , Florian Fainelli , Chen-Yu Tsai References: Content-Language: en-US From: Hang Suan Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SG2PR04CA0206.apcprd04.prod.outlook.com (2603:1096:4:187::21) To PH0PR03MB6560.namprd03.prod.outlook.com (2603:10b6:510:b2::12) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR03MB6560:EE_|SJ0PR03MB5902:EE_ X-MS-Office365-Filtering-Correlation-Id: c08d60f4-875e-4d73-3519-08dedd8e0ade X-MS-Exchange-AtpMessageProperties: SA X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|366016|1800799024|6133799003|11063799006|56012099006|4143699003|18002099003|22082099003|55112099003|4133799003|3023799007; X-Microsoft-Antispam-Message-Info: +cGqJ4/51aNvHyRQH8cuYUOPTD6+RioKAX9Q6o+qTtqOGq+X5lh35v7aDgNRYUpCUeD8BREmPzhZtZc8pDT9autvRw6BWhGMdmXHhTU9B7Z1Wh8m4thcI3VvAyGSOFaLXXSQbV60qSRaraeO7qyMvZmVreOKm1JaLGvgAV4IwcDh84ZoM5MwcYQZoSYGJ9Yo7YsLt4SgRyvmhgJxMShm6L5K2hPYN4jBG4n+PmPcwmwnfq/cjN53tltK4qgG05MqFvdg/mjkuyzGtjDifmETnPJVrzkBR6NHtvOJGZKX+WAqtwoP47ZgTnOFnBVr/UWZaICafG6tz1Y31Mib16W5S5Sne8fh6G52WZH1n7uTXKBU6sZNc+AuHwkPEkcI9xce0WU5GluzcIamv46sC4GdelRZ/VtFqIdSK23YBB/TR8eu1O4pEECp266ZqtMGQTYy96oOhWs2haaTEkNTPvDvNYH4gGgD2s736VbWMOJFqdE3HR5trubgMpXtQwp2shnuRJLAFMko6c0HMSbo3pmKOJw6ufM3epuEo9jciKo98q4+dpe4KyWDr7I2oMWzq89Q+RN5J/ZHrAdb286BtQkGkqRJT9Q0kNL3JcX0iexpxpQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR03MB6560.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(23010399003)(366016)(1800799024)(6133799003)(11063799006)(56012099006)(4143699003)(18002099003)(22082099003)(55112099003)(4133799003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b0E5RHZDN3ptZUx6ZW9UTUhkYWxHM25teW44SjkxbGJqK3k2Qk5UK0daSU1i?= =?utf-8?B?VURWc3hnVk9GSlcxaUlUUUxDSmhLTFQ5QS81dExqRnZqemtIcXBrU28vbURv?= =?utf-8?B?bG9zUEtlTHp6T2p5Ymovb05tZ1krMkNDWlVtNkQwcGhRelNrbHF4aEhINnpk?= =?utf-8?B?T2tRbEhCNUQrR3lIVVNPZkVOT2NWQXRoYjZuSWx3ZEZBWlZBeEFVbGtPbnc5?= =?utf-8?B?UDQ0eURXek5OVmNhREtzNStoS3lySnlyVnk5VElUYXFjcU1qQWt3a3pIcnow?= =?utf-8?B?QjJwL1lvR1YybmVvRFN4Z3lYcnJSM24zVytvVS9oZUdzSnJFNlo2ZllMcGVk?= =?utf-8?B?b1RYbDNUSUpYdjJ0SjVVN0hxWWp4WmZmUjBteTVUVlIrSTlSZ1FIUWQ0WEU1?= =?utf-8?B?QkcwUDl4Vmc5QllQd2NjTnplRHdVYklzUzVhUktIZVhrVnVFS0p6NHVweXFD?= =?utf-8?B?Z1dydzd3N0RtSkpzNDY1TTg3Qld2bnQxT0lnZWcreUZLY2dySjFhdldGNkVL?= =?utf-8?B?WFMvdEJuYWRPS2d2WTZzanF4MEE1Mlo3ZmlmK1VwQmgzdE1iOFVSU05hb0Js?= =?utf-8?B?aUtmaXNuMVYvMmZDTEJLU1VWMXRNREpvQWxyTEQ4dzVzdjVSVTFSbU1zWnVY?= =?utf-8?B?SW5NZDBQRmxDKytyWHVINlYrRGYyNDdaTTFHRi9ZdmJaUmVaWjdzUEo1K2Y2?= =?utf-8?B?Mk1MRUJwcDF2NFJIdkdqaTA0QUxOYStWMkJ6VGU5dWZIZTFjT0VMSmhLVVoz?= =?utf-8?B?NkJ0b0E4MFhobGthRHQwdytGODJhZVZVL0htRVJuUmxyTXhmaW02ZGQzcTBS?= =?utf-8?B?aTM4MkRIai9iY0tYU2Z0dEplbVZ3UWZZbUM4VXN5YWFsRHhJNVZWMUJGd0Rm?= =?utf-8?B?YkMveXUwMWkraWd0NDd0Wng5WWFweGdsZnlWdmU4Mk54bFVOMUFkK2Vqek1B?= =?utf-8?B?SFdUajB5ay8xNWptWlB1MytrRU1jdGtTZU1JUlZySGtacGFlL1pSS2JZOEhl?= =?utf-8?B?N0t3QnN6MnZva2lHL00xK0kxK1lzclpCK1ZHRzRtSnptUkZlL09nQnFIajZR?= =?utf-8?B?aERTcFlMUmRuN0hhUzhZc0NFZTRQc2p2QVRmWFNyb2htUkxZWGh1K3BudG1j?= =?utf-8?B?VWZLTnFKWlErSWVqZmhxVFgycEtBcHVIK1A3STFDTXNXZitIL1FQZ2RiRFF3?= =?utf-8?B?Z2xtMWRMYzJPNE05Tmh3bkw3ZDE5R1F0RFFXRlk0L2Y4dE4zb2VTSHd4Uk5l?= =?utf-8?B?QmtWc04rSmg1MlZ5YU9JZ0NRenp0RCtOMEVWS2pVaU9TekNadGc5MU1EUmFD?= =?utf-8?B?RkVwaWppd1lJU1l2NGM3RlNlN3M3V0lJTkVCSXE3eUFpalN2djFIaHVDZFh1?= =?utf-8?B?WHRiM0s5UEFjbVY0cFhwZ3hrTXJua2F6VkJYYk1ZcXQva2JGSU5JSFphUEFm?= =?utf-8?B?VTJxUDZGRUlxRlRaQVdSMFU1djdBNlB1Q1RqTzBGL3JBa1BOSXJBK2ZQRWFJ?= =?utf-8?B?eVgvZ0dwUkxzK3RZZjlteWN0OThnOGZaNDdqY2p5eVdqNGhwSUt3aEZGL3Fr?= =?utf-8?B?RUJYNjhoYkR1d0NnMUVoLzY2UlZ0ZEoxL2k5cG1rZ3dwOGFsOXJYQzY0NHBp?= =?utf-8?B?aHg2b0VETUtnVUFZeXpNeDhXTUdMKzdMOHlPV3ZTTjZCZHJIZFZkV2ROeHdq?= =?utf-8?B?NjI0MDhXQmFuZE11WVVoNkpYTUhoQ1NCbkVaNms0Z2VHNFNVUlUyaFZyRkNy?= =?utf-8?B?VjVUZ3o0aEtTQUJQM2lYWDRtbTY3eVhHNDVxeE1xeWpJcDZhTFo1VEJFT0dX?= =?utf-8?B?VkJrUGd6bEdBMlo3MVByeWJqRHJkak0zZXFYaGhJUkNmZEttY25NbWZja2Vr?= =?utf-8?B?WTdkTzhxa09PMy9DdUdzZHhwY2F2T1lGd3ZaeFRJQWk1OVphVGxCWTdnMUc5?= =?utf-8?B?VWdkYjFMMlFlNXlXMHlSMEJ6QTlyWFlvbGpCMW9MQ1prTitDbG1lWUtuWiti?= =?utf-8?B?KzhwakVRejJGdkJKVGU2S1l6OVZoM3duS2ZDeHFuN3QvWmtuVWRzdkF5YmhL?= =?utf-8?B?NXJudjRDc2QxUWdKdjJ5SzhGK1NMZkxIQXlpQzMvZ2RZanZPMTNuNzlJV1FR?= =?utf-8?B?Kzk0TFUrbHJ1L0VscUIraSthRVRGanVKNmRmL3gybnNXYVdTNlRhNTJVSXlY?= =?utf-8?B?SWlIVzRCRi8rdlJMNUdabDBnNDBDNXBaQlE2OURqUzdKUHNuY3V1Wis5Snk1?= =?utf-8?B?SW81eXY3RmVydytKT3FvYy9XeEpvUWcvTzR0MWV6Z0VvZklRNzJubDM1OHhC?= =?utf-8?B?L2RtNVJjREZZanZBeEJNS1NrSjBPTjBHTGlEejcwSE5rQ1Nqc3UwRUlXRkFD?= =?utf-8?Q?y5ZnHXh34oaBWw48=3D?= X-OriginatorOrg: altera.com X-MS-Exchange-CrossTenant-Network-Message-Id: c08d60f4-875e-4d73-3519-08dedd8e0ade X-MS-Exchange-CrossTenant-AuthSource: PH0PR03MB6560.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2026 07:45:27.6728 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: fbd72e03-d4a5-4110-adce-614d51f2077a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: l7JUat7itI3Xi0NdZEmgKnqzYwqVIeLyPaC4NFuTvxmMo4Wx5EIC8UOQ7YHT9W6d9bEAus+zh4sM/1G2G5iKSKmwlLd2xrIqC36QemVhUQE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5902 On 6/7/2026 8:33 pm, Dinh Nguyen wrote: > > > On 7/1/26 02:39, hang.suan.wang@altera.com wrote: >> From: Hang Suan Wang >> >> This series adds support for the Altera SoCFPGA Crypto Service (FCS), the >> runtime cryptographic interface provided by the Secure Device Manager >> (SDM). The SDM is the hardware security controller in Altera SoCFPGA >> devices. It acts as the root-of-trust device and controls access to >> built-in cryptographic hardware such as AES, SHA, a true random number >> generator, and Intel PUF. The SDM is responsible for security-critical >> functions including secure boot, FPGA bitstream authentication and optional >> decryption, remote system update, and runtime crypto services. On the HPS >> side, software reaches the SDM through a mailbox interface exposed in Linux >> via the stratix10-svc layer, which uses Arm Trusted Firmware SIP SMC calls >> underneath. >> >> The FPGA Crypto Service (FCS) is the runtime crypto interface provided by >> the SDM. It covers services such as random number generation, AES >> operations, HMAC/SHA, key management, attestation, and related security >> functions. >> >> This series implements one FCS feature: the Secure Data Object Service >> (SDOS), which protects sensitive data at rest. With SDOS the SDM encrypts >> and decrypts data using a key derived from a device-unique root key that >> never leaves the secure boundary, plus an SDM-generated IV. The host never >> handles raw key material or IVs: it supplies plaintext and receives an >> authenticated ciphertext object (and vice versa for decryption). A primary >> use case is black key provisioning, where operational keys are installed in >> protected form without ever being exposed in cleartext. >> >> The driver reaches the SDM through the existing stratix10-svc mailbox using >> the Arm Trusted Firmware SIP SMC transport. Data buffers are allocated from >> the service-layer memory pool, which provides physically-contiguous memory >> whose physical address is handed to the SDM. >> >> The series is organized as follows: >>   - Patch 1 (prerequisite) extends the stratix10-svc service layer with the >>     FCS command codes and matching SIP SMC function IDs, adds the Agilex 5 >>     (intel,agilex5-svc) match, and registers a "stratix10-fcs" platform >>     device that an FCS client driver binds to. >> >>   - Patch 2 adds the FCS firmware driver implementing SDOS encrypt/decrypt >>     and the crypto-session lifecycle, exposed via sysfs. It relies on the >>     command codes and the device from patch 1, so patch 1 must be applied >>     first. >> >> Testing: >>   - Built for arm64 (defconfig + CONFIG_ALTERA_SOCFPGA_FCS=m). >> > > There are a few sashiko comments on this. Can you verify that they are applicable? > > https://sashiko.dev/#/patchset/cover.1782888532.git.hang.suan.wang%40altera.com > > Thanks, > Dinh Thanks for the sashiko review. Responses below, grouped by disposition. === Fixes coming in v2 === 1) Async payload not returned (stratix10_svc_async_prepare_response) Correct. stratix10_svc_async_poll() zeroes data, and prepare_response() never sets kaddr1 for COMMAND_FCS_CRYPTO_OPEN_SESSION and COMMAND_FCS_SDOS_DATA_EXT, so the client reads priv->resp = 0. The session ID and SDOS output length never reach userspace. This is not about SDM trustworthiness -- the payload register is simply never forwarded. Fixed in v2. 2) wait_for_completion_timeout() units Correct. SVC_FCS_REQUEST_TIMEOUT_MS is in milliseconds but is passed directly as jiffies, so the real timeout scales with CONFIG_HZ (2 s at HZ=1000, 20 s at HZ=100). I'll wrap it with msecs_to_jiffies() and drop the redundant TIMEOUT define in favor of the named _MS macro. Same fix for the wait_for_completion_io_timeout() call on the async path. Fixed in v2. 3) Freeing the handle on timeout (UAF risk) The handle is kernel-only; the SDM tracks only an integer transaction_id, so firmware never touches the handle. But on timeout stratix10_svc_async_poll() returns -EAGAIN (SDM still BUSY) and the old code called stratix10_svc_async_done(), freeing the handle and releasing the transaction_id while the SDM still owned it -- enabling id reuse/aliasing (and a real UAF once handle->cb is wired up). Fix: on -EAGAIN, return -ETIMEDOUT without async_done(), leaving the transaction tracked so its id is not recycled; only terminal OK/ERROR statuses free the handle. Fully reclaiming a never-completing transaction needs SVC-layer cancellation, which I'll track as a follow-up. Fixed in v2. 4) SDOS missing UUID check Correct. fcs_session_close() validates sdos.suuid against priv->uuid_id, but fcs_sdos_crypt() does not, so the token is ignored. I'll add the same uuid_equal() check early in fcs_sdos_crypt(). Clarification: the attrs are DEVICE_ATTR_WO (root-only by default), so it is not an unprivileged bypass, but the missing check is still wrong and weakens per-session ownership. Fixed in v2. 5) Premature free of DMA buffer on timeout Correct. fcs_svc_send_request() will return a distinct code (-EINPROGRESS) for the in-flight abort so fcs_sdos_crypt() skips freeing s_buf/d_buf on that path (leaking them safely with the abandoned transaction) while still freeing them on genuine send failures. Fixed in v2. 6) NULL-deref / singleton priv Agreed. The mutex cannot guard this since it lives inside priv, so mutex_lock(&priv->lock) is exactly what dereferences NULL. FCS is inherently single-instance (one SDM / one SVC_CLIENT_FCS channel), so fcs_init() will return -EBUSY if priv is already set (checked before allocating, so a rejected second probe cannot NULL a bound instance), plus a NULL-guard in fcs_acquire_cmd_ctx(). This also covers the devm_kzalloc() overwrite/orphan concern. Fixed in v2. 7) Uninitialized priv->platform Correct, it was never assigned and always returned 0. Since there is no platform-detection source wired up, I've removed the platform sysfs attribute and its supporting code (fcs_get_platform(), the platform field, the unused AGILEX5_PLAT define) rather than ship a stub. It can be reintroduced with real detection later. Fixed in v2. 8) DEVICE_ATTR on a raw kobject (wrong first arg / panic) Right, attaching device_attributes to a standalone kobject means the callbacks get a struct kobject * where they expect struct device *. Fixed: attributes are now attached to the platform device via .dev_groups, and the manual kobject_create_and_add() is removed. This also resolves the related comments about using pdev->dev.kobj instead of a global /sys/kernel/fcs_sysfs directory, and the sysfs_create_groups() type mismatch. 9) fw_np refcount in stratix10_svc_init() of_find_matching_node() does drop the reference on fw_np, so it is used ref-less by of_platform_populate(). This is pre-existing and unrelated to this series, and causes no observable failure because the firmware node is static (non-OF_DYNAMIC) and never freed. I'd prefer to address it as a separate standalone fix to keep this series focused. 10) Dropping arg[3] in the sync copy Intentional. stratix10_svc_send() copies only arg[0..2] into stratix10_svc_data, the FIFO entry for the synchronous mailbox thread, whose commands use at most arg[0..1]. arg[3] is used solely by the async SMC path (stratix10_svc_async_send()), which reads p_msg->arg[3] directly and never goes through the FIFO struct. No command loses data. 11) Overwriting priv->session_id on repeated open The previous session is not leaked: the SDM rejects opening a new session while one is active, so fcs_session_open() takes the priv->status error path and returns before the memcpy into priv->session_id; the existing session_id/uuid_id are preserved and remain closable. 12) Passing a struct fcs_cmd_context * through the sysfs buffer Acknowledged; this is not standard sysfs ASCII I/O. It is the current design choice for this interface, since the controls are mostly scalar and independent. 13) Raw pointers in the copied-in struct / 32-bit compat Acknowledged; the context embeds native pointers, so layout and pointer widths differ between 32-bit userspace and a 64-bit kernel. That is the current design.