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 69FD125F798 for ; Fri, 2 Jan 2026 23:01:14 +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=1767394875; cv=none; b=MeORNno4rPx+oD5qyGo29ezVm1SQ2XUz5a/pnPuZQt6C0X0tfyFjatlTIQYd4Xh3a+f2tv+ZzfYOAczRHdkEgry4XyrBXJqUqd2tmLn1YktCNKOED4OMhL7xFaiXK8WyvGVbOE2rElDRSrSvJI/F9JuUPb6jQKPbqkExgctza74= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767394875; c=relaxed/simple; bh=OCbaEKUqVNRSFGQWwUoJL72xfSL9vDWFXC3M2S4N7fs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CQvoooS48IJNzcnaSqR1IXrxdL5kBpWLbX+ARD8OUwz/yiNFUAZVyMgT1nCWCnWFYM4NAyXDbANmb6YaFzqnXGnk8LAD43Gd6OkXuxVwYAfeOqitlU/Rc5HmwQIw2WkoQetdzNX5XuTSHOAc447E3+zQz/quxj3eIB/2Ix2nB/o= 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=YRo+3b1Z; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Y9ES01Bg; 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="YRo+3b1Z"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Y9ES01Bg" Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6029W2GS824403 for ; Fri, 2 Jan 2026 23:01:13 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= b3OTeFOaQb58wR8asUs+5Bv3nru7hCHc4Esj5jAEU4c=; b=YRo+3b1Z/m5Dylux 5EVsknToCHHRGPAJTTZ1vBLvbQMowmL35UG4cWnn4hONsdjTfQM8X2wmoAGqbUwO fxDGIKKohHpO+telDUjlLSzXhTMZ3qI99wxYjZ/TUrAI7kzzCYp5M6h1Me00iz6p ZPW8hzScB1jnHo2euHRl1eFl1Uy2OmeZ8wy2xawxLckUoh4dVJy3s4bgP035YnJn xruoT+pzIz4jrD257IunTBS6WusABcKgC/raBvCzeGoidhWRRvVPm9bKHI/UBNVF 2UHK/3EjnqttNTNYDedoaH9/M9ftlyzfyn6Rn/WeHP8HCtOcISnfPEyqycZ3h4gE uPPb7w== Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4bd8534ech-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 02 Jan 2026 23:01:13 +0000 (GMT) Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-b98e6ff908aso33891139a12.2 for ; Fri, 02 Jan 2026 15:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1767394873; x=1767999673; 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=b3OTeFOaQb58wR8asUs+5Bv3nru7hCHc4Esj5jAEU4c=; b=Y9ES01BgN2HE/4xqepjwnmNC6vMgrKbsEBK5UsPJVe6syYw3/ze8UNq0J9w/b3PF5I 4jxqZkZogLUAYcQv9WjZ1WmEDMDJPUdYNYIPrXClBK+4z+Fjw9XR+dByLtizMtYzwhH1 l/XlidPpscGOE5FQftdJElpNO0A6Tfy1XUkqfJUuG6yzuv3b1c9czVeohRO4uxfVEuXM PzrS41/fwCUtKQ475DI9nCf4qE73QaZosiaR4Wg0h5oUKjF527ybItMpG4Ttx3dDC4g/ WA26R4T8QU7I/NI7De6Cr2Qa0oGiaoNjxUnV6KAUXbt5+joifegK1TbEKOwO/oNOGMSd qhxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767394873; x=1767999673; 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=b3OTeFOaQb58wR8asUs+5Bv3nru7hCHc4Esj5jAEU4c=; b=QR2dilCNPaqYEci2dI2SNkUBQpe2MYL6rug8WCjraRBBQuM+Yf+9U3OzYoBX4RhhUJ 3J2pJrs9umV2QfehAQVAhwZO0xq/dk+2uC1dC2CE0acIU52GCVOMC8D3DEEMLAzxvtUF bazfrSIVGubghK6PYCKabtgrzI69p/ZLw1GT/z08kukYmNaRsupQtayyQ4gDERJjMgsQ BjL3UgKJE9uusmzrU/yc9mMYS71aqRnz5RPJ51GK4F/ApQ6qsMv1m/WfPag/PlXXSneE fI323FaOQI2y0cPmvL37YFixofNL87zPUXHpHeJt9G3Lf2PoLCIq84SG32/Yw9GKvUGn c+xQ== X-Forwarded-Encrypted: i=1; AJvYcCUXFwWeKFJbwBLCKVm/6xaDAQrDXLINYiWsPnXdPDrCIliyYTkfuiQtJmKW5PX7mS3C1W6cyDMS7rLqYJs=@vger.kernel.org X-Gm-Message-State: AOJu0YzUM91fL5/rABnDNZa9kocA6rf9L2fcQNeF8TaypuazrYB6lETz tk6Tvphf7imy/Eiw7uA6H0ULoS1oGi2S/Jm9GuCFr6kGGa1fJ6+suaQZkxnzKejfPGFcrAHFJJx w+oWVBVg4SEuiOfdGey6KrC/DP6muQH8vBxnWsn47gquZ84hMeqMROqtZl/EJhbJaWZY= X-Gm-Gg: AY/fxX5uy+9rd0b6ak8z5Jx6jY5mKLVYAbO0F2BDHpYPeSI4oi8LzGUsTUnZ+I7zDY6 6LwlKs6ek3OQDkwfSp3snMu/zqL2Frhz6gKPqLZGPEd8cXRfCBYiwW3ZTAbQ495NasYeahKr6I0 apy6GkXyQdSxgSHGC2Z3b+K1+OEM9dc+SpDoA7cv9rC+OYuXoT+ONMfkIr/M1O3aLKfprA4103r Mbwlt56ZWtOV+iN2Lc4bIvd0Uefoh7be8LPKAf4ZxycTHNjVPS7ZGfaqb13mPcijT9aV9bVyZrl eunAC6j1rbJtM6ElGYCNrTJOlFLEbG/r2H6DetX7TV0grhRJb7rVRPGa4f4DfvCORC+twyI2mGU JDQHCACJ0ACbkP1zj+N78RbvaDqCv3UtkmIxFkNz6cunZTT1/0rvfA6iiM6EZN1/KgtefxuLp7g == X-Received: by 2002:a05:7301:2aaf:b0:2ae:506b:4b05 with SMTP id 5a478bee46e88-2b05ec6f3c4mr25270506eec.27.1767394872474; Fri, 02 Jan 2026 15:01:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IF5EitizlliS+rSAvKNLC290H+9iTiSCypg+98RCwq2Jc/ptsUK+jo6pJwm9qtXZHoXSeq46Q== X-Received: by 2002:a05:7301:2aaf:b0:2ae:506b:4b05 with SMTP id 5a478bee46e88-2b05ec6f3c4mr25270481eec.27.1767394871826; Fri, 02 Jan 2026 15:01:11 -0800 (PST) Received: from [10.71.110.87] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b05fe5653esm93661329eec.1.2026.01.02.15.01.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Jan 2026 15:01:11 -0800 (PST) Message-ID: Date: Fri, 2 Jan 2026 15:01:10 -0800 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] of: reserved_mem: Allow reserved_mem framework detect "cma=" kernel param To: Rob Herring , Marek Szyprowski Cc: ye.li@oss.nxp.com, kernel@oss.qualcomm.com, saravanak@google.com, akpm@linux-foundation.org, david@redhat.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, robin.murphy@arm.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux.dev, quic_c_gdjako@quicinc.com References: <20251210002027.1171519-1-oreoluwa.babatunde@oss.qualcomm.com> <99dc91c9-59fd-47c5-b1d9-157bda86ad59@samsung.com> Content-Language: en-US From: Oreoluwa Babatunde In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: Q7so3nTfJleUHaqe6zPRqTGZU57A5Nuf X-Authority-Analysis: v=2.4 cv=fL80HJae c=1 sm=1 tr=0 ts=69584e39 cx=c_pps a=oF/VQ+ItUULfLr/lQ2/icg==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=vUbySO9Y5rIA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=hD80L64hAAAA:8 a=COk6AnOGAAAA:8 a=EUspDBNiAAAA:8 a=f-5fy8xPqO0yBxf2x6wA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=3WC7DwWrALyhR5TkjVHa:22 a=TjNXssC_j7lpFel5tvFf:22 X-Proofpoint-ORIG-GUID: Q7so3nTfJleUHaqe6zPRqTGZU57A5Nuf X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMTAyMDIwOCBTYWx0ZWRfX2P7LtfCDb9Zy FxfDBZXn0q16u1kixp+ivZXzEgGiPd6XSIFf+6kBZPrT10edrsYeiil23a0gb1iPYPTMbJ3UFap 5vSVircMPNzyICn89jyNuWotpn5MS8VF5Iu8o4dTkhd9+90O64fxujlf9vNPoGrMqW6AlH+XXkE Dt4I5szGqhVQz9ZgJq1y5bXmWKtmRnRyEfeEuRRQf2ELGXm3o/c6ijHNMA09X+iv5xS/w7P+9u1 baCDaP652gvDrTUEcOqtlLWqPpoq0sXK76/AigDZbEtX++WpNgLD7qtkJIDBAqA0Wj/xQRPrlN6 p6IwUuUUb5Epn1l+PEVyLLD/6ji8EaYyyNPGuAVY635lltyVPGIQFXYy385gaWYOUauaRjZkd6c q/M7TxVX/IGYzVXx0W8WAJcpipoOwmJ9MR0u1Npodj0gwhivzVWRa8t07PO+iYNxwhcW0Zq9o/G 4jy9EDcmz9tL+mVXZUA== 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-02_04,2025-12-31_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 phishscore=0 spamscore=0 impostorscore=0 adultscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2512120000 definitions=main-2601020208 On 12/18/2025 6:42 AM, Rob Herring wrote: > On Thu, Dec 18, 2025 at 3:55 AM Marek Szyprowski > wrote: >> >> On 10.12.2025 15:07, Rob Herring wrote: >>> On Tue, Dec 9, 2025 at 6:20 PM Oreoluwa Babatunde >>> wrote: >>>> When initializing the default cma region, the "cma=" kernel parameter >>>> takes priority over a DT defined linux,cma-default region. Hence, give >>>> the reserved_mem framework the ability to detect this so that the DT >>>> defined cma region can skip initialization accordingly. >>> Please explain here why this is a new problem. Presumably the >>> RESERVEDMEM_OF_DECLARE hook after commit xxxx gets called before the >>> early_param hook. And why is it now earlier? >>> >>> I don't really like the state/ordering having to be worried about in 2 places. >> >> I also don't like this spaghetti, but it originates from >> commit 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved >> memory regions are processed") and the first fixup for it: 2c223f7239f3 >> ("of: reserved_mem: Restructure call site for >> dma_contiguous_early_fixup()"). > > Honestly, this code wasn't great before. Every time it is touched it > breaks someone. > >> It looks that it is really hard to make reserved memory >> initialization fully dynamic assuming that the cma related fixups have >> to be known before populating kernel memory pages tables. I also advised >> in >> https://lore.kernel.org/all/be70bdc4-bddd-4afe-8574-7e0889fd381c@samsung.com/ >> to simply increase the size of the static table to make it large enough for the sane use cases, but >> it turned out that this approach was already discussed and rejected: >> https://lore.kernel.org/all/1650488954-26662-1-git-send-email-quic_pdaly@quicinc.com/ > > I guess the question is what's a sane limit? After 128, are we going > to accept 256? I really suspect we are just enabling some further > abuse of /reserved-memory downstream. For example, I could imagine > there's micromanaging the location of media/graphics buffers so they > end up in specific DRAM banks to optimize accesses. No one ever wants > to detail why they want/need more regions. An earlier patch which requested an increase to the static size of the reserved_mem array did include some breakdown as to why a larger size could be needed. Eg: cma regions, dma-buf heaps, Guest VMs, hypervisors, etc. https://lore.kernel.org/all/1650488954-26662-1-git-send-email-quic_pdaly@quicinc.com/ I also see the same problem of if we are using a static size and just increase it to 128, what happens when someone else needs 256? This is why some form of dynamic sizing makes sense to me. > >> Maybe it would make sense to revert the mentioned changes and get back >> to such simple approach - to make the size of the static table >> configurable in the Kconfig? > > I'd rather not resort to a kconfig option. > What issues do you see with using a Kconfig as a solution for this? Regards, Oreoluwa