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=-3.7 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,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 56945C433DF for ; Thu, 8 Oct 2020 16:04:11 +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 A681521D7D for ; Thu, 8 Oct 2020 16:04:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wAiuAk9E"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HuALeKMk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A681521D7D 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=cJzkjFMReeVWLEPZNNVCJf6qN5QLmExqROvDiT0uANs=; b=wAiuAk9Ep2IcdQe/XdeKZOSeg Iw6kuCtW6+KbHwBD9POWmfqnSCUAaWVRtTcS9HBjqpBgo9lArfJY26ZavFjU/9ZPOBI/u1dF6qs73 wOW/UqZc7zb7fOs2gORD0tsjTdwVNbRoohMlPcLIT+2CUrlrDe7NOq6FL0NUZkj2PwH+K5YxhxcNu qO6avr39nugnFm9hb0d/JiLCng29eLvRH1NqGGlO6GeihNcVrY4Rg36fmMAkMhuK+rFP4+4mvhPEp TEC2m/q541lMaL3MljBoXZCBKdtERTYAHaFMraAVFnfBRRyknEy7ujF+JYVnd+4Aaqc6q1sF0FHxh 0yqFb1ieg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQYMo-0001vT-EO; Thu, 08 Oct 2020 16:02:06 +0000 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQYG0-0006Pq-TL for linux-arm-kernel@lists.infradead.org; Thu, 08 Oct 2020 15:55:19 +0000 Received: by mail-lf1-x141.google.com with SMTP id j30so4680112lfp.4 for ; Thu, 08 Oct 2020 08:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ePirmulELbemRTmvtrt1ch9UcEfGnhKa3Vhqxn9QmJ0=; b=HuALeKMkxI4SLsKQjgqOGmNSIDeVYltC73/Yj4UI87bXqfJq74J8/hw8zWvy9Zkb+i szje/tJUYMYKTudq1R+jE5Vs8Pt6AK3wPbJ3CYjrzMLqGYAnAXx2NO40mSzFchT3HyET zzUvN1prB9QFDj3axzAYtW7AffFM+9ow9CXgdTk5Y+O0s0L+5c+gTGP2Q7omKwQHc+EG usL0jvBxnYoM5meYbDUL8FNaAp8YhimfHVcbKUEoAD6Y/00etCr25Ex3p/Br2/XSkBQN GK94GAXQlBiPW9TO7tJAo6j8akBBLS1L1WlWXwbBkSbu/ufntrn9mBJtyZ4urDHwIN04 SoOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ePirmulELbemRTmvtrt1ch9UcEfGnhKa3Vhqxn9QmJ0=; b=nzlpBrnfGjQPT24hyYJ/XED0K8Bw0wl1yF6UG6E2W89MWUIcOgmNR7Ox/5XjEgK+/e zC/9i9/+smhxwXtGC7er8mSz04QVTOzHe7Au/Z/QeLlYcsjXmb1V3IuKHqzYGsB6aOtV aeg41xDbZULxby6mKgSlv+MxegRN1x3Ca8CML20BZvoFT+NSkGIGuqkNxTgck4cc95F7 lxCmJ/zSHG8maH6RzRWamFjWsDEMIrJuhV2OIizu7ZBEtf6A5ro4HWRm4jy5wuSbXlSZ fndIAJKMQ7YLh2BMfQsU+/z0tOPVovpCjPUrQQf7vk19b1Qbt4nuCBwgtxDDoTFSZSgy Q2KA== X-Gm-Message-State: AOAM531PEZ5KDfoSXD3UkTfwMudD3bHWT3iOqjHzg+QiV9ah4/IvKzVg IItmz+wZyfUzQ9l5ODIH8bo= X-Google-Smtp-Source: ABdhPJzNNaKa9cL9Ahg57qPnO8bieFDsZh3HOQjO+aYYfAjiTNAuWtUsY1Wrob3YJf5clnYGp1cwpA== X-Received: by 2002:ac2:4c12:: with SMTP id t18mr2627311lfq.285.1602172502127; Thu, 08 Oct 2020 08:55:02 -0700 (PDT) Received: from mobilestation ([95.79.141.114]) by smtp.gmail.com with ESMTPSA id 137sm60079lfi.246.2020.10.08.08.55.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Oct 2020 08:55:01 -0700 (PDT) Date: Thu, 8 Oct 2020 18:54:54 +0300 From: Serge Semin To: "Maciej W. Rozycki" Subject: Re: [PATCH v2] MIPS: replace add_memory_region with memblock Message-ID: <20201008155454.kaal2bchjq7wusqr@mobilestation> References: <20201008084357.42780-1-tsbogend@alpha.franken.de> <20201008152006.4khkbzsxqmmz76rw@mobilestation> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201008_115505_106726_BC5713F3 X-CRM114-Status: GOOD ( 17.70 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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) 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? -Sergey > > Maciej _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel