From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 8F31D31076A for ; Tue, 13 Jan 2026 15:31:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768318285; cv=none; b=NkOAi4DwoUMh9sfoQ8lq1JQg5gE3PO1UDJ99tUAZeItqlZHnWjLcuZ89/nhA/r/f0Q59LDfoVeMO+3e1z6FJFm6TDm8pC4hi7dts/1vzSmndIDjuuSBYRXdwhrt5v/5tR9h2Mi58F+s01apW3iYJWDWklZjNFb3UFAE62w+xbCA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768318285; c=relaxed/simple; bh=pagwsMEhIBmSOcK4BaiKARoNQzk6E3odr509GL2yYFo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IBWNNIyV4fBgXnO1Vws9lfWC4l0JdaKZqeQsOYcj/idxZDVo+k28xAgZ8nUIBrUcaN+zlBmVtxJ809a3rRSsJ29bNA8vS+edsdZ0kxtXiWYwCIwQghWBTXyhlKlubLMyv0ekTRNCChfJhuCAbNZ4qM6PiNeEBtpj/5EE0L7bRuM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=NDuBqgf2; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=HaL8lkod; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="NDuBqgf2"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="HaL8lkod" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 60DEaeNs405670 for ; Tue, 13 Jan 2026 15:31:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= Jdh/o+SXQDB+611mtKFjE/D68KoXr5mEtsYbTZq6sHI=; b=NDuBqgf2zIg+H73n i6AtMEXz6x5zXjXzrYrAyKNFRBSo9tcOl+8FFlednRWBrPPTu6Tn2nML5zR0OQrL q7TjA+gyj8esCth8LQ94/XNe/yuGGEd9s0DoQyjR4xv37mXSAbmLdcg4+3U/AqTH RzZUvrygy6dPloZ73RjXgb+7AyLbCygJUV6Xt2aN2Da5JEO+kuJDN/csT0yfoK5R 0U50xIj/IkbofXQRRgHzKZuzX+tboeTmaId8X8pAZgxQaDIH/kB3UYX37Kuq8Eh6 moH1OK6Gd4CioisOiVJL6FfmnaMXxZQ5fPzEZyiCerLX/8cuNcZSxhr6nbJi5whD j4nXKA== Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4bnn06rsh8-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 13 Jan 2026 15:31:22 +0000 (GMT) Received: by mail-vs1-f71.google.com with SMTP id ada2fe7eead31-5efb28afa7cso151540137.1 for ; Tue, 13 Jan 2026 07:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1768318282; x=1768923082; 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=Jdh/o+SXQDB+611mtKFjE/D68KoXr5mEtsYbTZq6sHI=; b=HaL8lkodFUcO92YrvazBaQu/aQLdg7YtKv04239Q3n2x2MfusNBtkoc0iq476ezamT pNKucTWBycR8blecu+cGZblOpJFWDJ0cmeyagQ76fiFFGMH+MPm4HHN+CYehfEFVz8nU +Ji2V7Me3Z7uag4xUphdFFZ6Sn06OjLmur5pFJ6Dk20hoHaF7D+uLAm4tPZ2yVQn8WLY AJutBRKudD2xqyYXmP7CKHo6vwWr5mEODZOvb5TG/s9u9eunAVDy96/2PJGhUseONgVK dXFKBzx+KnXPwKyeZl3HE5gW5HzntxbVe+g4l5EQtnLW278K0BbrW0vzm5yac6fSs+fK D02w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768318282; x=1768923082; 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=Jdh/o+SXQDB+611mtKFjE/D68KoXr5mEtsYbTZq6sHI=; b=GQwAPyzEA5XspbXFLbrHyxt8KtbUfdcaXmx3Gph4EeLwLnmFb1UMIoBAOPy257jZHs ZSrrfgByY6xIVyJgoPNPNtPk6ex4PmKNgj4dkcSbqpLGB7MhajIjrkBzbbp1uJItiGxj u98YaqpZQWx2jxuG+YTHkgaErroLNEq2cLoFwBricEbopUEC03NRH1t2z9fYjTk7epRA /UoE0Bhsn+hFl5lYRd+iiyETKXVahgZ1q5CSncATHOHGYQBx5Rmcy2uV9mgDXi+SJn3C 0Op4rSjtVSmtpgALccAmymbhZIBkkPhJhSYcPmsbFVoRmQw5zRQHaODNrXDb1JwFgkey uc6Q== X-Forwarded-Encrypted: i=1; AJvYcCXYZzzhQ9s5bTvpL2swir4IHYtosxBEqE611qGHUd+qB7A57+XDORAKpt6beyzv2+4gWsS/jO1tqbjD0fk=@vger.kernel.org X-Gm-Message-State: AOJu0YwqFV29W/EPRDJ5W2WxH5WopplVlJpLp/FG+8R6DZ9VUhqR++EY rFmm9v1Jxh6EYY2fnLtscYgCbfYu1QV1Cq7kbWBzHS8uJadUWNk966bqUPZXEF3Fal3NIPwHrNB kspQ2OBc1ByR0oBknYgTNN85M31A/VUSMM/JOzJL/0G4WkDusjUFf5h58Y+mdhR7poDc= X-Gm-Gg: AY/fxX765P9GFg0MU6NKAM0LNZewB8vu+z0ua4LhI/udSTBsRspK5R0ceg9iDeVsbtd oPMDkyVf04GIH5rAxsniFFK0Uis+4I9ibwtN0bKfamDfqlGbC2uhVhmm2thJRXh1j8s1HZGXFuH QqA95sFUyoHzlYyIVMZXTf16iSWF6+ejRZzshfSJXsTFmalHgVw8VI9HevGBa86exVjhhiliVAV TJvW+kBAVAa6gwyCot02RcqQS94gWSFSOVx2Cvoz56b3SxZZZe8IDN+XvZKuUgQgolV4uI2DJyG dmjPPf/DOU+CFZYRXnDbRDGmrY9tZq9znoI5XEAyrLDQ7jPRAwBdls6bonuAshVYq2EIxlU99QU b0oDQ7f8GhXm0Ul0AWeyUcKxsMd/pr+ymxdC1ct404m/cegGzgeLGD0gJeCI0GqKBnl0= X-Received: by 2002:a05:6122:c1ce:b0:55b:ac1:d05f with SMTP id 71dfb90a1353d-5634735d2e6mr3999007e0c.0.1768318279999; Tue, 13 Jan 2026 07:31:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IEJaDNb89277U09zQgcbIRSDmN8Tc2NQbPIkmYjjiiCT9F6GWII0ZfQNvgvatDzT93Kgyw+wg== X-Received: by 2002:a05:6122:c1ce:b0:55b:ac1:d05f with SMTP id 71dfb90a1353d-5634735d2e6mr3998977e0c.0.1768318279128; Tue, 13 Jan 2026 07:31:19 -0800 (PST) Received: from [192.168.119.254] (078088045245.garwolin.vectranet.pl. [78.88.45.245]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b87207e08a7sm519832466b.55.2026.01.13.07.31.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 07:31:18 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 16:31:15 +0100 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 v3 2/3] soc: qcom: ubwc: Get HBB from SMEM To: Dmitry Baryshkov , Bjorn Andersson Cc: Konrad Dybcio , Kees Cook , "Gustavo A. R. Silva" , Rob Clark , Sean Paul , Akhil P Oommen , Dmitry Baryshkov , Abhinav Kumar , Jessica Zhang , Marijn Suijten , David Airlie , Simona Vetter , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-hardening@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org References: <20260108-topic-smem_dramc-v3-0-6b64df58a017@oss.qualcomm.com> <20260108-topic-smem_dramc-v3-2-6b64df58a017@oss.qualcomm.com> Content-Language: en-US From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: wDcExg72eAGmLJFUhRi8r-R7uGwAQr8x X-Authority-Analysis: v=2.4 cv=ZODaWH7b c=1 sm=1 tr=0 ts=6966654a cx=c_pps a=P2rfLEam3zuxRRdjJWA2cw==:117 a=FpWmc02/iXfjRdCD7H54yg==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=EUspDBNiAAAA:8 a=KxVwwE8FzcsyeGkQqd4A:9 a=QEXdDO2ut3YA:10 a=ODZdjJIeia2B_SHc_B0f:22 X-Proofpoint-ORIG-GUID: wDcExg72eAGmLJFUhRi8r-R7uGwAQr8x X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTEzMDEyOSBTYWx0ZWRfXzdXZrB4LLUSx RHO7oCksnt+EJiIQe0Up4XcuenT4vXHkYaL+5FvRG7mqsFj98nO7PciFFEYvkFaYS5BW2IZVzjl VjPqGDMPDxNASSE8FdR7jM21vPO5mkXoB2SYOENpW4IxfOIf5p4+rfJyxj5l5is6yqjbCe8MiKl GSVeb5BrCFOZyy7nQOrFnaUtZ08DqiGP3d24WRH3NGeskSDTRhZNmJyPtlio3i/G2kvdG/nkPZY rlpgCDZZJh9O3H8ylWePw8iWOQ4QLWr43+LbJSqMBiyRL9661Q14QnUbOlpNiNLPiMAd5fbAIu7 KtmKqGfIBco/AAYR+kUhyyzYWABTEKMTomuKSe1CBuEeMv9Da8KV8aFgiEK5D3jNfx1TBQ4ZNwr ndj9HoPqSLBBKm7w3oSCtxm1H6v9gX4UK4PPLLtwXF0mlgkrV+sOoTOAR1TzPdkQi0Yr4+LzVMG 0AsiWNH8+msGKtQHODQ== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2026-01-13_03,2026-01-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 priorityscore=1501 spamscore=0 impostorscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2512120000 definitions=main-2601130129 On 1/10/26 11:45 AM, Dmitry Baryshkov wrote: > On Fri, Jan 09, 2026 at 11:50:46AM -0600, Bjorn Andersson wrote: >> On Fri, Jan 09, 2026 at 05:21:10AM +0200, Dmitry Baryshkov wrote: >>> On Thu, Jan 08, 2026 at 11:49:54AM -0600, Bjorn Andersson wrote: >>>> On Thu, Jan 08, 2026 at 04:45:49PM +0200, Dmitry Baryshkov wrote: >>>>> On Thu, Jan 08, 2026 at 03:21:51PM +0100, Konrad Dybcio wrote: >>>>>> From: Konrad Dybcio >>>>>> >>>>>> To make sure the correct settings for a given DRAM configuration get >>>>>> applied, attempt to retrieve that data from SMEM (which happens to be >>>>>> what the BSP kernel does, albeit with through convoluted means of the >>>>>> bootloader altering the DT with this data). >>>>>> >>>>>> Signed-off-by: Konrad Dybcio >>>>>> >>>>>> --- >>>>>> I'm not sure about this approach - perhaps a global variable storing >>>>>> the selected config, which would then be non-const would be better? >>>>> >>>>> I'd prefer if const data was const, split HBB to a separate API. >>>>> >>>> >>>> I agree, but I'd prefer to avoid a separate API for it. >>>> >>>> Instead I'd like to either return the struct by value (after updating >>>> the hbb), but we then loose the ability to return errors, or by changing >>>> the signature to: >>>> >>>> int qcom_ubwc_config_get_data(struct qcom_ubwc_cfg_data *data) >>>> >>>> This costs us an additional 16 bytes in each client (as the pointer is >>>> replaced with the data), but I think it's a cleaner API. >>> >>> What about: >>> >>> const struct qcom_ubwc_cfg_data qcom_ubwc_config_get_data(u32 *hbb) >>> >>> I really want to keep the data as const and, as important, use it as a >>> const pointer. >>> >> >> I guess the question is what are you actually trying to achive; my goal >> was to keep the base data constant, but I'm guessing that you also want >> to retain the "const" classifier in the client's context struct (e.g. >> the "mdss" member in struct dpu_kms) >> >> If we're returning the data by value, there's no way for you to mark >> it as "const" in the calling code's context object (as by definition you >> shouldn't be able to change the value after initializing the object). > > And I, of course, misssed one star: > > const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(u32 *hbb) > > This leaks the knowledge that HBB is slightly different kind of property > than the rest of UBWC data. > >> >> You also can't return the data by value and then track it by reference - >> as that value lives on the stack. This has the benefit of making the >> lifecycle of that object clear (it lives in each client) - but perhaps >> not a goal of ours... >> >> How come the ubwc config is const but the hbb isn't? >> >> >> If we want both the per-target data to remain const and data in the >> client's context to be carrying the const qualifier, the one solution I >> can see is: >> >> const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void) >> { >> const struct qcom_ubwc_cfg_data *data; >> static struct qcom_ubwc_cfg_data cfg; >> int hbb; >> >> ... >> >> data = of_machine_get_match_data(qcom_ubwc_configs); >> ... >> >> hbb = qcom_smem_dram_get_hbb(); >> ... >> >> cfg = *data; >> cfg.highest_bank_bit = hbb; >> >> return &cfg; >> } >> >> But we'd need to deal with the race in cfg assignment... > > static struct qcom_ubwc_cfg_data *cfg; > static DEFINE_MUTEX(cfg_mutex); > const struct qcom_ubwc_cfg_data *qcom_ubwc_config_get_data(void) > { > const struct qcom_ubwc_cfg_data *data; > int hbb; > > guard(mutex)(&cfg_mutex); > > if (cfg) > return cfg; > > data = of_machine_get_match_data(qcom_ubwc_configs); > if (!data) > return ERR_PTR(-ENOMEM); > > hbb = qcom_smem_dram_get_hbb(); > if (hbb = -ENODATA) > hbb = 15; /* I think it was default */ > else if (hbb < 0) > return ERR_PTR(hbb); > > cfg = kmemdup(data, sizeof(*data), GFP_KERNEL); > if (!cfg) > return ERR_PTR(-ENOMEM); > > cfg->highest_bank_bit = hbb; > > return cfg; > } > > This potentially leaks sizeof(*data) memory if the module gets removed. > Granted that all users also use qcom_ubwc_config_get_data() symbol, it > should be safe to kfree(cfg) on module removal. I really don't understand why you'd want a separate API for hbb, if hbb is already available from the larger struct *and* if a driver needs to know about the value of hbb, it really needs to know about all the other values as well Konrad