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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30A2CC76196 for ; Thu, 6 Apr 2023 15:48:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78A7E6B0071; Thu, 6 Apr 2023 11:48:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73AE06B0074; Thu, 6 Apr 2023 11:48:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 602A96B0075; Thu, 6 Apr 2023 11:48:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4F78A6B0071 for ; Thu, 6 Apr 2023 11:48:50 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2E83EABBAE for ; Thu, 6 Apr 2023 15:48:50 +0000 (UTC) X-FDA: 80651399220.22.AA7ADEC Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 34CE0120013 for ; Thu, 6 Apr 2023 15:48:47 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZMF5k7KK; spf=pass (imf29.hostedemail.com: domain of robh+dt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=robh+dt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680796127; a=rsa-sha256; cv=none; b=K+cj2uCaHcG+9eRNYptQ+0cpWXXWqrEPaa9vqw4qV79XwPkK5hz1ww7mWI8ly/0juBn2dC vmECQczjJuMhh5WDihJNyzocfUzuLaq2WvDdkntfkor75nRNWCdeHLhXoLbjx0o9AXzZp6 n68v2iHxlJJD2VYTaTklKDbZr8CxoFU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZMF5k7KK; spf=pass (imf29.hostedemail.com: domain of robh+dt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=robh+dt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680796127; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tMaxfyEmrlnt3/FU5Ifbn87HMaUzq6qpNmAZ9bWTa0w=; b=To9zWRqhedRy+rhdAcGYWTsEpmkmRu6zFSNH/Lws1ipOsu7gXlwrlIaIfgbRv1wFRbIfJt YfqpbpY1lgAUbHdw2v2h66JXTXvg7PjfUbOOIpL+hDcgJQmV+5v30J62rHIhjKXMvlmJfe iyg/j5U7TGkj0B+PhusKWioFlPSjqL0= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 424FC646FC for ; Thu, 6 Apr 2023 15:48:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 46E7FC4339B for ; Thu, 6 Apr 2023 15:48:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680796125; bh=gCMj7rHc2vXcOYr+ShATDoCKp8S/RUyCf67KISWSutM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZMF5k7KKffyKyYyX7yspk2IyYCGQcqbQ7LzxlG0zX2jKbDx2pOFdE+SdtfFTELZzu FwuO9NAHPoZsCLnHSQWoYxNOd4EZptbNtaEiKJnCtGDzm6HX4olb1dHGrW0yhImCOR b37KPZ+7G8xuKUiVRNVrCB8boMqXobaklI/WLzcrmlJeD33tNmnMgcPDuPBLb3Ev91 b+nIaoXvfjTF5tUEoFUBsDbcjQckoybX5C2qhTRZ2RR8OFJ2zqjYJjwUbQsRbq9JlC AYOTinadPVJ62rmoAO7oI8CG+gnG2hnBIDQ5LcvEQIEpNVnoCeYyIeJm9xS/EIn+RM 2S4Fih8rtiKlw== Received: by mail-yb1-f175.google.com with SMTP id i6so46642245ybu.8 for ; Thu, 06 Apr 2023 08:48:45 -0700 (PDT) X-Gm-Message-State: AAQBX9c37E62VXDyvN0CjWC8hhtjyWhzoE5DiykII48janvs3w3tUwlq yDbwcRU0n94wSwJK6IekvXz1V0kAjJ8GntSmPA== X-Google-Smtp-Source: AKy350Zzc2mowfFyIPi/dfoj4PLjaJFeaGp+GLAx0yBecFNH8tMSD++w2H0z7ixo8hKG1Kc7Dvdk1MZHPK6dVBFWaNg= X-Received: by 2002:a25:cad1:0:b0:b75:3fd4:1b31 with SMTP id a200-20020a25cad1000000b00b753fd41b31mr2367088ybg.1.1680796124084; Thu, 06 Apr 2023 08:48:44 -0700 (PDT) MIME-Version: 1.0 References: <20230406151429.524591-1-tanure@linux.com> <20230406151429.524591-3-tanure@linux.com> In-Reply-To: <20230406151429.524591-3-tanure@linux.com> From: Rob Herring Date: Thu, 6 Apr 2023 10:48:31 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] of: fdt: Allow the kernel to mark nomap regions received from fdt To: Lucas Tanure Cc: Frank Rowand , Mike Rapoport , Andrew Morton , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jbrunet@baylibre.com, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, martin.blumenstingl@googlemail.com, narmstrong@baylibre.com, stefan@agner.ch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 34CE0120013 X-Rspamd-Server: rspam01 X-Stat-Signature: mn75kr454n6hn69yx8meccrh84xwmc5r X-HE-Tag: 1680796127-877395 X-HE-Meta: U2FsdGVkX19PHmpwx8R/l41hqinAI/jlKEtteObLvJvSAXOQ849MUsnoNgb7jB5N+QyyUIAI3dpCxMzqMRps7aQ1UEPDdoLgLHEOfwoobBYuIsEeJJJKewchTZahaG3e2qRXLSpDywXWCg7bsqn8DWWbHiFk3q3E+Xreu5IVLUXQjrzdU/0MGJE0KlAUgbGOkrgpkocqT/Anw3XK+a3pOrfZQnu2O5x//vT0ZpXmEO/0Bt+mT25Opx8l0+pvtyLIXiS8s6bzZq4zWNSsnPlPDEC4I3yVow62x190y87oEntkAtaKqOZzq0VZOf5kZJjG7v06aSp+eCns3WoQx98KuhelGQSd/MXMYJOcK7opZf8wVG5zQkeIWbdC3MkskbWWEly5WrN9p83MJC9DMkcIoAnaWaMf5inpszccUCHMHcg6R2cA6ZAEvr3a33euCzOzXjWU8YMS6l6djaSOIbVig8wCd/1u5z8Ig00V5kL4Fd7BnY0RRd2Lp7WR8TAF6NDViJvUr5NpLjGusDxHNVxlJ2DnmPaJd4PEv71/N0TW3RqRcta7wfbJ43Pj0vz3TOdHKqjTW3IlbLidF/mg9UHsjoPYWPVf6r1bdfGV7bIb96KSliiIDB/3SgUMejCLmf/uASeGo6yr9acmn+eUxx9k2CjJV1MCcok54Jb+pQldqld+m1Of0wR98JsgdXJAP6wPjVs717dymCeUEx1hQMpRb/kROmhz3p/7zU908KoB49dej9vWmdwBJTqU0os2jXxiGJmvZagmVSjH4fNp/YpTqfTtRTf+q98FmCSmU+Da3aRQdAUXZAxb3CR0LCF+zPUJ78nlO6noR7EczTxIweDAmgjxR1OPMaoJgDefJd8y5adocItN4WqwNiZhxbrZ4xPakglf0/mUmay7Tdi6m4yjh/ONXPs5EhfMrqP/i0ELZV+B7d7zLln+LPs7WFx92jnbyZ/xm5ShBhhRZnUktEK qWPbpHlg Qy9Z1NBHaSBWT/A3gnpTMZscIuL9a7CHJLeAlpYZWFZznbMOkpg8U+UD3aB6oxmkHYCNXKicpXdMsxHNrVhKpK5LKrYU5CUNnAl+NplnXddEnwiH1YlVojBs+ms5H6QuluMkGWJ3o3BQpBd0Sj66G7j+l0d6x0IVKpf0mqajg/ofYbeyZYeWk186ZvefcrCoo+oJxI6umgLE58zRsafcBoI91T4DO3o3GLJ65TaIPyTzD9yp+0xK8UsLOoaPkt9hylSesg459Y6Leg9CwR12wrM9pINzntUS9vb5UAYxxT9WuO1ALP1LFaHgbe9aoAPMpqr4G8UZGn85FnKqPZ6J+4ZITbfX6fbKZp2J44n/VPm1l4e9nwereQbVtyVJevD4SegRyU2/vUMEiAp1vcRH549vng97vZQVOt4Wi0OtQq4AHa0ZLHxJ0fLMX+vQ2M1gD+5ML/ECf1S7jyMeLj8XDugOTuuaam76qI3X8EgDTk3klsxe/hCLWipproA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 6, 2023 at 10:14=E2=80=AFAM Lucas Tanure wro= te: > > Reserved regions can be described in FDT and device trees, but FDT doesn'= t > provide the related flags, like nomap. It took me a minute to understand what you meant by FDT vs. device trees. Use the exact things you are talking about: /memreserve/ and /reserved-memory node. > So allow the kernel to mark regions where the base and size received from > the device tree are the same as the base and region on FDT. > Here we trust that the device tree has a more updated description of the > region than the one received from FDT. > > Signed-off-by: Lucas Tanure > --- > drivers/of/fdt.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index d1a68b6d03b3..754a7ea4f45c 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -482,11 +482,13 @@ static int __init early_init_dt_reserve_memory(phys= _addr_t base, > if (nomap) { > /* > * If the memory is already reserved (by another region),= we > - * should not allow it to be marked nomap, but don't worr= y > - * if the region isn't memory as it won't be mapped. > + * should not allow it to be marked nomap, unless is the = exact same region > + * (same base and size), which the kernel knows better an= d should be allowed to mark > + * it as nomap. > + * But don't worry if the region isn't memory as it won't= be mapped. > */ > - if (memblock_overlaps_region(&memblock.memory, base, size= ) && > - memblock_is_region_reserved(base, size)) > + if (memblock_overlaps_region(&memblock.memory, base, size= ) =3D=3D MEMBLOCK_OVERLAPS && > + memblock_is_region_reserved(base, size) =3D=3D MEMBLO= CK_OVERLAPS) Won't this fail to work as IIRC memblock will merge regions when they are adjacent and have the same atrributes. Perhaps instead, the DT code should ignore any /memreserve/ entries that are also in /reserved-memory. I would suggest just reverse the order they are processed, but I suspect that might cause some regression. This code is all fragile especially with platforms putting in 100 regions. Finally, perhaps fix u-boot. The reason the reserved location goes in both places was to support an OS not supporting /reserved-memory. I think that support has been in place for a lot longer than anyone would care about. Rob