From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B1E191F03DE for ; Wed, 25 Feb 2026 14:00:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772028049; cv=none; b=ga6OinB5qjOKV1uIt8XinktNRtr0fAL+DAdvfY4+uzzYhh0AhfDX7DL7U9ddi8J+GbjHB6a7aSGSRLZyj+JNiXnYPkKLh/CS8DPHCV747zJuOKJhUNIbzT7J5zf5fnmeaond+dwRGt+nzZvy/VbDI3JdIo9GTIDY0BCkHGQgwT8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772028049; c=relaxed/simple; bh=oXWq7ZKppyOqoUwMd00YgZ68r0g8MU/hDohRVD2+w2Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UhJhl/lPXZdupw7yMCD2ITvz5THSV7qn4tZ1tehE9xg+fI9tY3064jXeen1iSmX3amu1VPNoUZFEKwerJFWPBHKYtGepLV4QY+qSL6hEXB7LDc5tWSi8iFRtk0IsuxZyb07nMjnnwfwSbQEtx2QeknUCkKhUr9AafXtcftrlrug= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=PCtwohfE; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="PCtwohfE" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-480706554beso79690085e9.1 for ; Wed, 25 Feb 2026 06:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1772028046; x=1772632846; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=v83nX06CFNonzs3aaey88JZD1iHRYlh5Rsz4acoeN6I=; b=PCtwohfEdvCchQQCABCeY8lYDYrQzUvCap6M+pc/f5Xtd8yZ8XPRj658kB7HPnXrIg 9l0uQfwKzEcMxwg4BKHWVjDH1x3+xNZh3LUXMjYvLR/6bE4cEFl1rUkLd1jpSTXReB19 qmGazQrohP3AuHigkoudW4hJN48GmSKbc2Vk5ADAIzoPbMw26+KnkYJtiB/I6GyM9gnq JeWyJ9/Vlp+AKXr9MpcfhTnRWq1mPbkXFnDAvcpBZb1mfCzPr65HdkhO+kugQDm1rNNg YsVt/zqT2WC9rOPDz5TyP9IGMpGUTrpR6mGOp439w93duG/xsPpkJp+8ISrsTcFy5oKE CgHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772028046; x=1772632846; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=v83nX06CFNonzs3aaey88JZD1iHRYlh5Rsz4acoeN6I=; b=RlJWnus8hO93q5aioUy0gjaJIlBkcOjdY8b3UJcDSVVQVBTViu1EPD0M+7foqqJiES mtdNl9BHJb3+4Jiy9/zg7xo1qjgJVB1BAM/wHsZ8fLiNYpBj62D5GDZrbVXxyryRwUm/ pHgTdtLC5QRCdLpozGMBBp1cPvnFFvZYTGHXnN9JRs7aVl3cFw6bMAmA1c49teSFSp1a T9399athfRJKhr6DrciVyKN2GVzerBx+wXXtNsrRrjPPGXRbJom0z1Yer6USPDZzXXO2 yOieN9cTqqV6nFUM+J+xRmA5v8ohPSBYQuhxe5uVC4ThJUOSRCp72jmV8xzVfnJbXBZy pcSg== X-Forwarded-Encrypted: i=1; AJvYcCUtcXAgGcPFmL/F4bYl6lhd5E6EyCGUcC1pEKB42MpvTlQ7HwWHCIsoL7AVSo+G4G6vkek7pOPvda792TU=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0CfKQ1hmmNPuI0vfr27tQc3r5DseHyGM4PDeZ1WHtrPTH/Gom +YWDNgQWuwKrlklKCJakALibmGk4oziYJZ26/Rsvx8U6E6C6y3cklu6MvYyljI3HVf0= X-Gm-Gg: ATEYQzz2UTaksQKni1enNEjcPGiwxtaafaRbEs0n28oc6ZFcExJtstFNeVJjTRH2Oqm 3wFzASEc3I0QuAlANCubrpkCjDYqDOs/w81D3mCQCpKV1dtB99A+CB3W2Net5lNj9P2mpO7czx7 9z9YAGiZZqUM2DdS2uOXsGKvMbJHydLdxOTvBwGpzTfO4YeGjQQj29TMTpXSOCTDxhTL7QpO4bf u9a77boai+gjGHYscMVz7ifp8TMI0C05P30Bn9k4mXCJJmghJyBR3vlDItDmjjh5tbL0ea8ukDX DkYDjsCGLTPj/FXfZUKNF2gNaRDXZF18YtJhYD0t6vj4pwHO5s476HGZYfoH0DzDjCEtf2GQb24 KfMJlbq8rs02tc0a5C/tEy7+AWHaZECD/U1sBsq83NTjgTy41l2ZLuoOt77LER6l6Z07pbAFRA1 Irp5VfT1r8FwfAsaIeYUcg5OmdDxsiHinB X-Received: by 2002:a05:600c:3e1b:b0:483:703e:4ad9 with SMTP id 5b1f17b1804b1-483c219b659mr8852985e9.19.1772028045947; Wed, 25 Feb 2026 06:00:45 -0800 (PST) Received: from [10.11.12.108] ([79.115.63.134]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43970c09897sm35367670f8f.17.2026.02.25.06.00.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Feb 2026 06:00:45 -0800 (PST) Message-ID: <279baf9e-ef05-4217-9357-94d21bd93978@linaro.org> Date: Wed, 25 Feb 2026 16:00:43 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] firmware: exynos-acpm: Drop fake 'const' on handle pointer To: Krzysztof Kozlowski , Krzysztof Kozlowski , Sylwester Nawrocki , Chanwoo Choi , Alim Akhtar , Michael Turquette , Stephen Boyd , =?UTF-8?Q?Andr=C3=A9_Draszik?= , Lee Jones , linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org References: <20260224104203.42950-2-krzysztof.kozlowski@oss.qualcomm.com> <3e5001a6-ea3c-4304-8db3-bbe616eb4015@oss.qualcomm.com> Content-Language: en-US From: Tudor Ambarus In-Reply-To: <3e5001a6-ea3c-4304-8db3-bbe616eb4015@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/25/26 12:48 PM, Krzysztof Kozlowski wrote: > On 24/02/2026 13:57, Tudor Ambarus wrote: >> Hi Krzysztof, >> >> On 2/24/26 12:42 PM, Krzysztof Kozlowski wrote: >>> All the functions operating on the 'handle' pointer are claiming it is a >>> pointer to const thus they should not modify the handle. In fact that's >>> a false statement, because first thing these functions do is drop the >>> cast to const with container_of: >>> >>> struct acpm_info *acpm = handle_to_acpm_info(handle); >>> >>> And with such cast the handle is easily writable with simple: >>> >>> acpm->handle.ops.pmic_ops.read_reg = NULL; >>>> The code is not correct logically, either, because functions like >>> acpm_get_by_node() and acpm_handle_put() are meant to modify the handle >>> reference counting, thus they must modify the handle. Modification here >> >> You are right that casting away const via container_of to modify the >> parent's reference count is incorrect, so dropping the const from the >> handle argument makes sense. >> >> However, to address the underlying issue of the operations being >> writable (e.g., acpm->handle.ops.pmic_ops.read_reg = NULL), I think we >> should also decouple the ops from the handle struct and keep them strictly >> constant in .rodata. >> >> How about we apply your fix for the signatures, and I follow up with >> (or we include) a patch to do the following: >> >> struct acpm_handle { >> const struct acpm_ops *ops; // Changed from embedded struct to pointer >> }; >> >> static const struct acpm_ops exynos_acpm_driver_ops = { >> .dvfs_ops = { >> .set_rate = acpm_dvfs_set_rate, >> .get_rate = acpm_dvfs_get_rate, >> }, >> .pmic_ops = { >> .read_reg = acpm_pmic_read_reg, >> .write_reg = acpm_pmic_write_reg, >> // ... other ops >> }, >> }; >> >> and in probe: >> acpm->handle.ops = &exynos_acpm_driver_ops; >> >> This way, the handle safely reflects the mutability of its container, >> but our function pointers remain fully protected. > > Yes, this makes sense. > Will you come with a follow up patch or do you want me to ACK this and do the follow up patch myself? Both options are fine by mine. Thanks! ta