Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1333957pxu; Thu, 8 Oct 2020 09:00:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwxLsJPr/UFj3KcHND0B1TpfRPQi7ZYQ6myPB+JoIZ2YsbThiPUDWB+EOnb5SqTf6abxlVB X-Received: by 2002:a17:906:b01:: with SMTP id u1mr9464470ejg.57.1602172829474; Thu, 08 Oct 2020 09:00:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602172829; cv=none; d=google.com; s=arc-20160816; b=PQpH3wc7Z8SfyruwpVR4UQ1h74zfm8Vw0pC52UlP9TmhzCZJSwO02FrgfnNhvXb5gZ eReVYRf4xWWq4Z4BnElPd3+GbPhD5FIoshll+7C/561JPpp80t2Da0QEw+hFBl93RtpO 8+Wtep3guiClcmUfQkub9DUlMKgaZpjmBrvHif0PMRqkkoIP4laAjtpamZFuXGQ3XpAI 6cXYGxVCxyGZUHT3dvbCWpysIMer8HGdgEytHKqYfhI7NoDHVd1lmqYQ4Slf4WoH/K3o 7RWnm0+IbPPDlKqLsCB7Q1G8WK09SNB5kabvIiMWjCDmU0O6jUNQvMZN8TAyazo4a9vT I6Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ePirmulELbemRTmvtrt1ch9UcEfGnhKa3Vhqxn9QmJ0=; b=GogQtlio4NoQkjkFtKcVV+ZJXTfANvK1L/FjeznBk7mEi/qH87aA5cUJoZK2LjK/oj 224o3rbQM+87NEBCcxY6Bc29c4fgv5yQZ1AopbuaEVci7aY1zv0iPNUoL63EMMOXEA5h 1OKwZhDUsJt62s8kjnAYN7CU75hh6xegLuzDoHMB6dLrUk6AedVNd21efbOycQ96IA+0 tglh0uulWCm6dLCkV1AKcq/V2TiRfiDKkrDwkexZEqerjcipvJDyO//tZW9LMWwlLJDY 6qltqr8gymleIrOLBCmnJ9is5JOlimsak6MJ+k8PoUFSDE4ttnBQ3hS9Be0k3ZEq9AML FuAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HuALeKMk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b29si3946874edn.354.2020.10.08.09.00.04; Thu, 08 Oct 2020 09:00:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=HuALeKMk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731697AbgJHPzV (ORCPT + 99 others); Thu, 8 Oct 2020 11:55:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730186AbgJHPzE (ORCPT ); Thu, 8 Oct 2020 11:55:04 -0400 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1991C0613D2; Thu, 8 Oct 2020 08:55:03 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id w11so7087244lfn.2; 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=HmyJtNLvKPuvoHo7K6ZJNW0ConF/5U8ZciU121keh2441zX0TP/coxCYaHCrsX+CbA gmITmovs2WBDx0NM/0LXf6P1/8fnExDg7nBXj+fsdlQz3YDo0FOrTlomTq/MkHHKY7k0 6SpSU2c5N9tALSjOuAdLQqMMxVyz5yIc+HmLCRVUyc3daUbE0vKeWJ2Nvuw4C0Jtn1IN fneu4YGL1OcyzG+GVRoEsx4xvrqvMlw40AAy8BQ1tAkmjbAQLpmy+fQkWdIyIroJ0wG+ pJae7zP7FjsUW8IioEHm8eYZdRXIPvkLeEoKzwJ7e4PZriglWnF1lbil9grfy4MXvgH9 7OZQ== X-Gm-Message-State: AOAM531QNWydUj7GNAVTmV0QwPzwn1sEZrmvtlAE04T+0L47cJB3SLof 7TTtX1sFxGClrWYr8WFvtv4= 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" Cc: Thomas Bogendoerfer , Hauke Mehrtens , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , Florian Fainelli , bcm-kernel-feedback-list@broadcom.com, Jiaxun Yang , Keguang Zhang , John Crispin , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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