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 C600EF47CA9 for ; Thu, 5 Mar 2026 18:44:44 +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-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=p/InfKTyXkgN1PvmXo/6+5rZe0iozex09wg2bfgN7qQ=; b=sdpoa1GNX0b2pd4cTHFm/S+BuA a+kJ7TmJGMT5JtdRKsMvgmnkLzg4L6zr1LAnx4nqWTI+JYodbMQdvM70HVT8kq+gqdqGCIRwI1JNd nKYEUBWuN34ZbxEqqucBBp0p2tDtHZ03LU6TryRJcRtZWGzCv4Nfwam63sDOCoDFRccT3yMhIPu6F /k80bNFoN3U2kwXOQ/YGlRnclGjuGqMBRmyNpTUZmu9kVXNlRbiIhr9okvq8UsPqAa8auVkemcBc2 ebASjEWhY6eXUahop7r2t3koCLc2IYcKaGP37r7ubHAdMUgb2WlUdvKEbkczoVS/tjT7IIA9TOsWE ZbBZ29Iw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vyDgd-00000002PHs-1fqm; Thu, 05 Mar 2026 18:44:39 +0000 Received: from mail-northcentralusazhn150130003.outbound.protection.outlook.com ([2a01:111:f403:d918::3] helo=CH4PR04CU002.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vyDgZ-00000002PHW-3Ulm for linux-arm-kernel@lists.infradead.org; Thu, 05 Mar 2026 18:44:37 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=N1SAZpS6ZaqJsZXYfrw0RRTjWhLEkVCZ0eRYS5trB/7Q2VsGTnhObpl8iDfx8B9N8kndbqF5SBGIVLbHzevP/fDuSoBCTgPqveyabi2XLTk5NBFvzGAWuOOiYeuJdzmnmJ3+4uieG+YgyQLRAZper+4V/GDRa3Z5bw0PSWxsrbJ1vPzuiPcAh2+ffK7+8QUZs1LPjCO5l+GIrFVmFDFYohYXeeUucaqe1XWO6JiVeDhPPFLm1v5Ohti/bQ8suSvPc5XZNSXiObtQVyXLyb212k2EyVSPET7vOE6KX6uyyPx0NXpXMwn3I98ZWrBjXB1yGeJ8W+SbH3KeZOkmfFbPQg== 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=p/InfKTyXkgN1PvmXo/6+5rZe0iozex09wg2bfgN7qQ=; b=kTsXxskQVid1/icpPYxJ3smD1Rs/AOogtaAvFoMuQcOjanA0GCZ9nDYegyP5vZ3m6MNoxXv0UnTGIUCJJnSqxZxsjEfg45CN8X6dpA02p5wmwGHHrGaYdQesKrwZY0z8/s52903LwWDx6kux5sBDdJel72rbe2Tm6z2pObNMocI2v78IeMoA4tTM7lZJtsbiJbqUxuvLcWWf74dUSGVrVAQd1sg79UEDx+uxPo+BW98Cn/uK9F/8W4hMGm1CE1LXE307BvJn4Id5OE8voAzvoSFG6HX7Ge1JFsU3Ji7R2PWOs3IVGUNKRcofFSiFOsqv2g9cpgPdBKmLV7nfaVaEVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 198.47.21.195) smtp.rcpttodomain=vger.kernel.org smtp.mailfrom=ti.com; dmarc=pass (p=quarantine sp=none pct=100) action=none header.from=ti.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p/InfKTyXkgN1PvmXo/6+5rZe0iozex09wg2bfgN7qQ=; b=W9/68gUQ8B15ZaovfWlonDrEKpyySDIGS0lQ01xTpovJOTwnTRenSu9VaQSOLUQvzHlWQ1pbyRS2cn1w50KITU+hzqzu5e+xarG/Z7PjqrxILm05/BFrQwTUcYLKLiJuwfA8loTeEqOnQdNF1MX5oiWGqlRIw+YNedv3zhBrogw= Received: from PH7P221CA0061.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:328::15) by BY5PR10MB4243.namprd10.prod.outlook.com (2603:10b6:a03:210::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 18:44:33 +0000 Received: from CY4PEPF0000E9D9.namprd05.prod.outlook.com (2603:10b6:510:328:cafe::9c) by PH7P221CA0061.outlook.office365.com (2603:10b6:510:328::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9632.23 via Frontend Transport; Thu, 5 Mar 2026 18:44:20 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 198.47.21.195) smtp.mailfrom=ti.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=ti.com; Received-SPF: Pass (protection.outlook.com: domain of ti.com designates 198.47.21.195 as permitted sender) receiver=protection.outlook.com; client-ip=198.47.21.195; helo=flwvzet201.ext.ti.com; pr=C Received: from flwvzet201.ext.ti.com (198.47.21.195) by CY4PEPF0000E9D9.mail.protection.outlook.com (10.167.241.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 5 Mar 2026 18:44:30 +0000 Received: from DFLE210.ent.ti.com (10.64.6.68) by flwvzet201.ext.ti.com (10.248.192.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.20; Thu, 5 Mar 2026 12:44:29 -0600 Received: from DFLE215.ent.ti.com (10.64.6.73) by DFLE210.ent.ti.com (10.64.6.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.20; Thu, 5 Mar 2026 12:44:25 -0600 Received: from lelvem-mr05.itg.ti.com (10.180.75.9) by DFLE215.ent.ti.com (10.64.6.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.20 via Frontend Transport; Thu, 5 Mar 2026 12:44:25 -0600 Received: from [10.249.42.149] ([10.249.42.149]) by lelvem-mr05.itg.ti.com (8.18.1/8.18.1) with ESMTP id 625IiO7G2857803; Thu, 5 Mar 2026 12:44:25 -0600 Message-ID: Date: Thu, 5 Mar 2026 12:44:24 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ti: sci: Drop fake 'const' on handle pointer To: Krzysztof Kozlowski , Nishanth Menon , Tero Kristo , Santosh Shilimkar , Michael Turquette , "Stephen Boyd" , Peter Ujfalusi , "Vinod Koul" , Frank Li , Thomas Gleixner , Ulf Hansson , Bjorn Andersson , Mathieu Poirier , "Philipp Zabel" , Dave Gerlach , , , , , , CC: References: <20260223202426.566958-2-krzysztof.kozlowski@oss.qualcomm.com> <195cc8dc-8642-481c-8bdd-f5409ab8f5b5@ti.com> <5b6a4284-4766-424c-9171-feaa08c52ad1@oss.qualcomm.com> <2d852f07-0bd9-4076-b0dd-93425ed237f4@ti.com> Content-Language: en-US From: Andrew Davis In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY4PEPF0000E9D9:EE_|BY5PR10MB4243:EE_ X-MS-Office365-Filtering-Correlation-Id: 7d3e5d10-6700-41b6-26fc-08de7ae73c5a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|7416014|36860700016|34020700016|376014|921020|12100799066; X-Microsoft-Antispam-Message-Info: 01QlmEKCQw7H221QOm+anKMleDiJ9ZE4YBF+79avqADBK4K/enYpewwf3vBq4SGmocoJwpZslIeVWQnb9k2Fgul6SJzHoCKkMhpivWEvyoPgzyiDdjnt3znfqeTsAUwol7bgEb2970jkp2EJlhpScUj3W3ZTzu30KPWWhzriMlj7TYyJAEKfoFRbhzOgYBHU0DJjJ6kBI679tMMbk9Y5qoV/E3xPReQ2CaSYOHuSOuuxJyX9a9tNmZ7V2yQqJBLs3UvDmQpITDrHigp9dm9lrCTUPhpuobKP94ea3+B357wVkI+dLTOzTwlFBzBkAwVYSCmc53/m5APAigdmqzzHUpWMFfOM/Ud64GH81EkMI6NupKVlMuQqNV+XUIZdeOAJo+vDdcm0luCi+UVW2A7haYelsQM5jvAoGrXd5i4+sYzdSa8d2sgvic0z+LcOCsuOiVOekGqDvyUJOZyBsMmKHtIhIpYLbV/SztG6CNNuqkq+z/i1C0UY40C77vZjdTEmFFbR5iyrtbtGUwV5kUGoAQE27Sa0mUxuamjdp1HGH1BR47e+NvV+JK5gdpXLScvxxi65efhcB5vOiWNywvLcW+oYt5RPZI0hDxW95nQ3xLnq4/UPYLZSq+wBuaLrwfStkePFp0Qk05W1DQrly3zwEOw9ezDFXc4P3WgOAgaKXNZDKm2oDjVR650IltpJ2/lWs5dAY9zyqUOzJfTxdEaq9wfLjQfqn7X8OPSxf0AoNHzbEBbN1t2n1Ztpv9pH2kmhD2QYmTn9XpsRWzfjDLZZpQ== X-Forefront-Antispam-Report: CIP:198.47.21.195;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:flwvzet201.ext.ti.com;PTR:ErrorRetry;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(7416014)(36860700016)(34020700016)(376014)(921020)(12100799066);DIR:OUT;SFP:1501; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 4FuUm2GQ70MA6Za6CwN0A8qOHHhEcmC3rNs0LekX1f7ImeEC62VJbClbsFHY39fyVoLLKaD6zH/iPc/9gTzX4fBnSgcTigasGu1Z/U5Q6D72mIiK+Wbu7R4H6ImS1o9HlxNBeKmhpgXN90cHxU7T4XVslTSa3PN5w9xNm+FtUbFb3OM6EOxSE+vJ844dWnfuf9FbZ5I5HWbLO2jI4Rf4yoAldUKB+jMoBM7bH5FZ4NypLb0SD6Jc1nqi3B2kxic1HeGQMRQVLuT0bimeV/F13OAS/X5juiFb6pOi+97TCNKFwU3SWEjgQJUw0SzmO4vt8nEQWK2VjPNStDDCJbmNTfarqAaMZm4U7QVmBoEtuRA9i09ii0srbqgExxj36Xxyv+K/R2qc8FhS+1Wvia6bYnXE4bAYN//2PXMQHumMPMnEOn9tSizTkmTLORB0JrKi X-OriginatorOrg: ti.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 18:44:30.0881 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7d3e5d10-6700-41b6-26fc-08de7ae73c5a X-MS-Exchange-CrossTenant-Id: e5b49634-450b-4709-8abb-1e2b19b982b7 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=e5b49634-450b-4709-8abb-1e2b19b982b7;Ip=[198.47.21.195];Helo=[flwvzet201.ext.ti.com] X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000E9D9.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4243 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260305_104436_054618_0DCEA68F X-CRM114-Status: GOOD ( 29.22 ) 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 On 3/5/26 9:59 AM, Krzysztof Kozlowski wrote: > On 05/03/2026 16:52, Andrew Davis wrote: >>>>> The code is not correct logically, either, because functions like >>>>> ti_sci_get_handle() and ti_sci_put_handle() are meant to modify the >>>>> handle reference counting, thus they must modify the handle. >>>> >>>> The reference counting is handled outside of the ti_sci_handle struct, >>>> the contents of the handle are never modified after it is created. >>>> >>>> The const is only added by functions return a handle to consumers. >>>> We cannot return non-const to consumer drivers or then they would >>>> be able to modify the content without a compiler warning, which would >>>> be a real problem. >>> >>> This is the same argument as making pointer to const the pointer freed >>> via kfree() (or free() in userspace). kfree() does not modify the >>> contents of the pointer, right? The same as getting putting handle does >>> not modify the handle... >>> >> >> In that argument, if we wanted the consumer of the pointer to not free() >> it we would return a const pointer, free()'ing that would result in the >> warning we want (discards const qualifier). >> >> If you could somehow malloc() from a const area in memory then free() >> doesn't modify the pointed to values, only the non-const record keeping >> which would be stored outside of the const memory. So even in this analogy >> there isn't a problem. > > I am not saying about malloc. I am saying about free() which does not > modify the freed memory. > And if you look, kfree() in Linux takes a const pointer. We also do not modify the content of the pointer we are given either, so we should be okay using const by the same reasoning. >> >>> The point is that storing the reference counter outside of handle does >>> not make the argument correct. Logically when you get a reference, you >>> increase the counter, so it is not a pointer to const. And the code >>> agrees, because you must drop the const. >>> >> >> The record keeping memory is not const and can be modified. >> >> And where do we drop the const? The outer "struct ti_sci_info" was never >> const to begin with, so no dropped const. > > We discuss about different points. I did not say the outer memory is > const. I said that you drop the const - EXPLICITLY - from the pointer to > handle. > Only because container_of() forces the const to be dropped, that is out of our control. But we never modify handle though the non-const parent struct. > And that API which gets a handle (increases reference count) via pointer > to const is completely illogical, because increasing refcnt is already > modifying it. Just because you store the refcnt outside, does not change > the fact that API is simply confusing. > If the refcnt is not inside the const struct, then the contents are not changed, therefor const is still correct. Even if the content of handle were in fixed ROM, nothing would break here. >> >> If the issue is that the handle is not const inside that outer struct >> we could fix that, >> >> struct ti_sci_info { >> ... >> - struct ti_sci_handle handle; >> + const struct ti_sci_handle handle; >> ... >> }; >> >> And with that change even your original commit message example issue >> goes away, >> >> struct ti_sci_info *info = handle_to_ti_sci_info(handle); >> info->handle.version.abi_major = 0; >> >> would now fail to work to compile. > > But you cannot do that for other reasons in your code because you DO > modify the handle in all the APIs which you call "pointer to const". > Show me *any* API that modifies the handle. The *only* time handle contents are modified is when initialized in probe() and functions called only by probe(), never in any API function. If the thing making this confusing is that the const gets dropped by container_of() then it seems there is a new version of that now that explicitly fixes that issue we could move to[0] with a small modification. Andrew [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/container_of.h#n26 > > Best regards, > Krzysztof