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 C4B85C76196 for ; Thu, 6 Apr 2023 16:06:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30FD96B0071; Thu, 6 Apr 2023 12:06:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BECF6B0074; Thu, 6 Apr 2023 12:06:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 160ED6B0075; Thu, 6 Apr 2023 12:06:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 000E26B0071 for ; Thu, 6 Apr 2023 12:06:10 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A85CA160791 for ; Thu, 6 Apr 2023 16:06:10 +0000 (UTC) X-FDA: 80651442900.30.F6F4EC5 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by imf02.hostedemail.com (Postfix) with ESMTP id 227168000D for ; Thu, 6 Apr 2023 16:06:06 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=ilJZDzEi; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf02.hostedemail.com: domain of neil.armstrong@linaro.org designates 209.85.221.48 as permitted sender) smtp.mailfrom=neil.armstrong@linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680797167; h=from:from:sender:reply-to: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=tGBcjAE6j139nGrIeCa4gFdeD5NsoReg/shcLBHBhms=; b=2uIfcf11QfsyCkqAuY8eeD2jIVJqaVYAS9u2tyxGz53tE6vAWTnqCPKrL2rboendgkEKOT gqONQASr65QdZKaY4APjjGdCP8CQcKxvaooacmyaZGNS6F+5nMhAugrAYQLwaamdXgovyb wYJz8jjAnP7A6aj4nDS4bj/HBexhCrk= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=ilJZDzEi; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf02.hostedemail.com: domain of neil.armstrong@linaro.org designates 209.85.221.48 as permitted sender) smtp.mailfrom=neil.armstrong@linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680797167; a=rsa-sha256; cv=none; b=065rSvbU4Md0ZpvLJxin1Z250dMQT3Fa/9obd9cyF7RJa6emtMLCVD6wxbgHi6dnz/7RPH umOqlT5MXfFVuZ6v8NkFaLdw5TlMhGCVe/CGi7l3lYAyQ//g/hVSQL7tZUYKdnTT9xlj8r OoO8SQc+dRopFCR88IV/D88EGUGX20s= Received: by mail-wr1-f48.google.com with SMTP id l12so39998992wrm.10 for ; Thu, 06 Apr 2023 09:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680797165; x=1683389165; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:reply-to:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=tGBcjAE6j139nGrIeCa4gFdeD5NsoReg/shcLBHBhms=; b=ilJZDzEidBWQIUC/WEyHBGDCmt0cL+CP5MSZDpG5JB4DEmx+iCCm2eolefvzKHqePs pPr5KEMziD1SfnzjcT7+V2LbK6NO4kGSMU9+vrMBiNxCUo+0yCJLJXN1GOd8xnTsrDFP 5ttKj7hXEN+WARyIDBN+aJMbKgLwykkxseBQlNWWYddQ7j24/HTKyL2rfD5d9YgpSvH8 NCOWr7ne1XNH4RceyRoq74JZKlfolKiIu4uOwzNmkdyjCaRkkE3yNkOn5sgi+Brd7EQ9 BxsNdGp4804+wu6FlQ7CxoZI5ausQcPB0JIBbA10IeZTz+Q1A1ccbUueZTedCg1t2U74 YoGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680797165; x=1683389165; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:reply-to:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tGBcjAE6j139nGrIeCa4gFdeD5NsoReg/shcLBHBhms=; b=yxg5XJ/Rt9H23ONo/PDSRAZ2ibiTY7TOynjNpBg5ntdxgKD3MQlluJVGm2kJIq5EQz hCcfDQL/rHPZvlB2C6pL/iXnoneNFgCOrZYu0+Z2ZeeUE4CBasB72eNRUJlDc6qZqZ34 K9JspH8A6y/KdIKkzs0xmAUVTwkZ64IKJTD4aOu70ZLH2aLO7qq9r+KSaBzLZt67Zo8z dyXSmA5Y/aus+wnryMzo05VmI0+uTzUcOZ1yE1zfia3LDEmJI4FkTvqPL5FwHKtrHgmW 9rlkXbF+GFJtz2nCScbLmRz3kRFKcRtkGul9TS8j6XZxiqTfWVfjhXEOeKebPVSEbN2z jbBg== X-Gm-Message-State: AAQBX9ealgUbY4Sh3MwgBFhbz+qK4X7eUrQDBL2sLLNtP9uSu/HLwrYp FiNwi84mTgiSWgeUY5RHh+zweA== X-Google-Smtp-Source: AKy350Z6NL84QoajoMkHAcqHoiPnqfDtjwjHP1ozYJ3eK1bhBdJxqz9vdxU74lO60iF0AtXdxGpuBg== X-Received: by 2002:a5d:6584:0:b0:2ee:ee98:efbe with SMTP id q4-20020a5d6584000000b002eeee98efbemr1836418wru.58.1680797165454; Thu, 06 Apr 2023 09:06:05 -0700 (PDT) Received: from ?IPV6:2a01:e0a:982:cbb0:8569:a62a:11bd:c344? ([2a01:e0a:982:cbb0:8569:a62a:11bd:c344]) by smtp.gmail.com with ESMTPSA id b10-20020a5d634a000000b002e116cbe24esm2112794wrw.32.2023.04.06.09.06.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Apr 2023 09:06:05 -0700 (PDT) Message-ID: <9835aeba-6e4c-0594-427b-9990fc07407a@linaro.org> Date: Thu, 6 Apr 2023 18:06:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Reply-To: neil.armstrong@linaro.org Subject: Re: [PATCH 2/2] of: fdt: Allow the kernel to mark nomap regions received from fdt Content-Language: en-US To: Rob Herring , 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 References: <20230406151429.524591-1-tanure@linux.com> <20230406151429.524591-3-tanure@linux.com> From: Neil Armstrong Organization: Linaro Developer Services In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 227168000D X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: sgj8ai3yc5sub1wmqqufte3hm9pdotti X-HE-Tag: 1680797166-488719 X-HE-Meta: U2FsdGVkX18KZdQ7PHIEBIIObESRn9Rney/h37MAPwkCSkXbSKXv/shhYa/sUSS9rkymMOdkOQYRxTA1HkfrVgnhHyFAjALwIWejx/ooXPXsqYJwhcwWpLKtqsP/A9BQM8QOXTr198omobs1OO/VIr9p9+QsZZsN7F4TD6kD9Ew/NAtpnkCuQHmb0OjUC1sKvG91UIduhHAHJTZRhxYSMoa3UVocTEdWRNy1YOTxUiJWDifja65gBrTnHXWJAjabv47/dvZSggkgByPlGvigaWMmeiuEpPz81tiZDJdHT31XY1mDXJz+YlSIEE/rMcBpQbI/FH0D76TBo6X1zM1UTxy+S6LZ/GOuX3QIswIz2VJtDWt+qv12/FptLkDmHJILlv8rRxVKDdKK7Yh5D0YE6BVYdbjSYoCITXaf7k7U2U03pK6axil0u7WqJF6BuucDXjvX7jhQZDJ9K/v8tU4pxyi+j/NwkgiUrbYm7Q+YY/FWpCoFpyRqJaoEC9zNqnqlXcQLdRrVRJ17g8XBidG6Z2fBUVHhf9Pe4HSwEvKn3sPNeZtGhYr7o64Uq2IY7Ri3FPXMH10+44FjbNA2VeNhJqdZ5Jc3woWQijtQ9tWJA1V0nEgPJmlcbEq+OlhWOs+qX+atU7U0i2Ua1O6DFN2WLOk3lpvBmC3n3we5gpMD4EGvX2Wu92/QpxW09bizpFUNZXSFR583FEPnu2A7KgSxEm1IjM06+LJEXrULd3cVSjlJiOIq/0lk0rOp57YXW5neowCSxAWPgInt0EhWifdqQMbrlhPIMldrsHMLF2NNJwqTGo39ErTmiVAketB0zFVef3wZFJ6BVqHihr+nBEO2GRJU+/Q69stIkHlPcu7g1PKN31vkz9hpHPXC1AS+QWDAGnlQ3R3xLhaCWqHkDS6ZrG4q34pPxQdGtkULpD8GkQshH3NMLQwHRkB2DTggBxHRR5CfCVPPJl+h38NOaOs YNl84urC yNhHnDFByD2JD/Ok8oIyPeQ9S+7gteDYOSuXw5SdmrIWn/7SiSvuUoYATQzbCTSzdEfrPj54/NJGNLhkAbW+9gHazQNx3ezbzCsk0hplZk5sp/dA57G/LHy1G6c3v1nM8yb90TrhIlLpZURzOZX6F5762O7Uljv4TWU5VRsabOk7SChuM2rs5qeOW5K2dq7ZU7CF7GDHKM8HpQpORVNbyaoBM95Vdjbvljyl7iHb15ufuhpB5neIyKkRdDujYBFaSa92sCgze/3nBoRdCk2OtsYL0DMNhXR80BiFp84Sz+P4JHWNW1WZHuXfpEl/2KwB01eI6kQQGahxJTxeoZ66heSigCg5enThpXLegmZ8fLlU1KpjxtqmeH6o9b8Ukf3UuwEklH8kb/1927Yr1ZIRRGtexDcnDxreCCAlOWM/tiTy/3INT7L6hbACw0VwgH1RuVeE+gpn5wikniNmy0uQbVOy/yJ8Y1pyJ1iUuqU4VECSlGgCSmS26Bxg3gWdBj+NiuWndsQ0qPg43ZDYbSIYj5UxwN5xmreMQ9sQRRhFCrClg9UPT8hS4+EEKNUqK4PJuVKLscHXS92wsQwG/7w2o9mucycoEPA1ssYfmkmEYx17JZrlgK2KROa8CNGInFibKFj8WCXa9xoa8QKcODFzfXYBXVE4lj2FMIovV+tZuajmSJbksHMA0p4OTXeoQSZ6UKgkU7xefVka5Mto= 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 06/04/2023 17:48, Rob Herring wrote: > On Thu, Apr 6, 2023 at 10:14 AM Lucas Tanure wrote: >> >> 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 worry >> - * 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 and 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) == MEMBLOCK_OVERLAPS && >> + memblock_is_region_reserved(base, size) == MEMBLOCK_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. Fixing U-Boot won't fix already tagged and in-the-field mainline u-boot releases that adds /memreserve/ entries, so yes u-boot should be definitely fixed but Linux should ignore the /memreserve/ entries when they matches an /reserved-memory node like when the U-Boot /memreserve/ code was added. Neil > > Rob > > _______________________________________________ > linux-amlogic mailing list > linux-amlogic@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-amlogic