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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88BF5C43457 for ; Thu, 8 Oct 2020 16:51:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0899B21D7D for ; Thu, 8 Oct 2020 16:51:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mnOq0Hif"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nhUB611p" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0899B21D7D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BzypCQPJ/pZig6BGIK8Urs5YWTWtO2WjXcZsjTrsdE8=; b=mnOq0HifH3TrywP1iLo316AxH Hb7w9Ou+PnBrQLleGh5miMXVREICA5xy4bNU6M7zDJHaTFm40SKya+8JBUiX8KQBFrxErdluokSsV etpvNdTL5itU9yJ6Zktx8CLaKG1ddGbAEvvhMIlJwG9ngfVqgy2ZguHQ9OhWreiQyAR3sddOOovFk /aWlLPjgbOEj81rtwpBJrspZyhTyn/d/bXntfzatYjTCoWwlMtEPwAYfh0LHb80vChwccJIzxTeKm ylFiJl6RYoe3wwzH/8RH4ScQNQhScbLCDi7gAgZj9v37vyIFDZXr0Dq4WDo6OoZ5UVb42SyPsL7U6 442BGt1iA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQZ76-00065U-FM; Thu, 08 Oct 2020 16:49:56 +0000 Received: from mail-pg1-x544.google.com ([2607:f8b0:4864:20::544]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQZ72-00064N-Di for linux-arm-kernel@lists.infradead.org; Thu, 08 Oct 2020 16:49:53 +0000 Received: by mail-pg1-x544.google.com with SMTP id r21so1440089pgj.5 for ; Thu, 08 Oct 2020 09:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=etkEQubuil182k3C5BVo92E36PMRBTYONF0xOmMx994=; b=nhUB611p0AMA34WZHbcfv4F8z/HholYpZGUj0swudfsaD8TMmDd0Lv4+Ew3zoYA0pt 0paCTIXiHgUFBw2WsfJUjNPpXpWUhzk5ciBDBZc4aEQR1X8sgrD3JOcPQ0Xx2Q+Nmato B4N/wF5ixnS8rmFKUKfUbIH4Z47uAEaHIKwYBsGJBDMG/9OSEhItrS44K9Ui3Rr+cmSM LmF1/kS6fy26Y//OEphaSL+ZkiFChAmWWiluWLVQDcpN08F7IOLqkdxa4lZYUaUuRfRk C5SsexIl66MRf4Z++lTNGAJsMs+fgYNbE4OVxsc1OGrUCerfvZtLT7v6GPK9AXqO3RIb Xfhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=etkEQubuil182k3C5BVo92E36PMRBTYONF0xOmMx994=; b=p5vzEjEsTsrpxJ6Bcrt/vhoxyBXuC0kuHrN0qMRKZjLykOjZAh9IZqa2PRByKc4chN 93MmG0p8FiZL3/ZnkP4Vkc0+5N17kzE93CNyed9ytqOOueCMz6TCqrJJcj8JM0Jl73o/ H82sJSVm9QVUv7NSuZiWyePj8Y1X8ifqHAw5+nM3Rh9inYhBzDqdja3AsBBUCURbRCpl dj8Wbl+Qk2bOvyZ5gsD6ugNnT9mKUeAYD33TanqhdcANCSog+fF1TGN/duRdkYDHaysZ znaO1TK0trCkLDbUf/nciztO8sS7zowpegJOEEtORPRqH8N1q0orHALwtxMjC1fdmsGg Eeng== X-Gm-Message-State: AOAM530ucT9AI6jkKjJ/aByLcMVEx1iol3l11g/6qnkLauxYp8QtU/Wq s3dqNCfI4Cq9vYX4uFUarjpi9snckPP7nA== X-Google-Smtp-Source: ABdhPJw8oO//XgT0mpyq/nBfE7h02sQTemmm7/n2bAm2ae1eWE5Ve3E3ySf2SKmEJCqyM5W8K0cSYg== X-Received: by 2002:a17:90a:f198:: with SMTP id bv24mr9135831pjb.230.1602175789695; Thu, 08 Oct 2020 09:49:49 -0700 (PDT) Received: from [192.168.1.3] (ip68-111-84-250.oc.oc.cox.net. [68.111.84.250]) by smtp.gmail.com with ESMTPSA id q8sm7868758pfl.100.2020.10.08.09.49.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Oct 2020 09:49:48 -0700 (PDT) To: Serge Semin , "Maciej W. Rozycki" References: <20201008084357.42780-1-tsbogend@alpha.franken.de> <20201008152006.4khkbzsxqmmz76rw@mobilestation> <20201008155454.kaal2bchjq7wusqr@mobilestation> From: Florian Fainelli Subject: Re: [PATCH v2] MIPS: replace add_memory_region with memblock Message-ID: <91e52fa1-ecf9-7acc-62f6-16fccfae927c@gmail.com> Date: Thu, 8 Oct 2020 09:49:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20201008155454.kaal2bchjq7wusqr@mobilestation> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201008_124952_466367_124E9E4B X-CRM114-Status: GOOD ( 23.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Fainelli , Hauke Mehrtens , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , linux-mips@vger.kernel.org, Jiaxun Yang , linux-kernel@vger.kernel.org, Thomas Bogendoerfer , bcm-kernel-feedback-list@broadcom.com, John Crispin , Keguang Zhang , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 10/8/2020 8:54 AM, Serge Semin wrote: > On Thu, Oct 08, 2020 at 04:30:35PM +0100, Maciej W. Rozycki wrote: >> On Thu, 8 Oct 2020, Serge Semin wrote: >> >>> At least I don't see a decent reason to preserve them. The memory registration >>> method does nearly the same sanity checks. The memory reservation function >>> defers a bit in adding the being reserved memory first. That seems redundant, >>> since the reserved memory won't be available for the system anyway. Do I miss >>> something? >> > >> At the very least it serves informational purposes as it shows up in >> /proc/iomem. > > I thought about that, but /proc/iomem prints the System RAM up. Adding the reserved > memory regions to be just memory region first still seem redundant, since > reserving a non-reflected in memory region most likely indicates an erroneous > dts. I failed to find that, but do the kernel or DTC make sure that the reserved > memory regions has actual memory behind? (At least in the framework of the > memblock.memory vs memblock.reserved arrays or in the DT source file) AFAICT DTC does not do any validation that regions you declare in /memreserve or /reserved-memory are within the 'reg' property defined for the /memory node. Not that it could not but that goes a little beyond is compiler job. The kernel ought to be able to do that validation through memblock but there could be valid use cases behind declaring a reserved memory region that is not backed by a corresponding DRAM region. For instance if you hotplugged memory through the sysfs probe interface, and that memory was not initially declared in the Device Tree, but there were reserved regions within that hot-plugged range that you would have to be aware of, then this would break. > > I also don't see the other platforms doing that, since the MIPS arch only > redefines these methods. So if a problem of adding a reserved memory with > possible no real memory behind exist, it should be fixed in the cross-platform > basis, don't you think? Would we be breaking any use case if we stopped allowing reserved region that are not part of DRAM being declared? -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel