Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3873395pxu; Mon, 12 Oct 2020 03:40:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3+07dK3rOqZpeT2SV6+gg8uG1NlhoZyAZ1+8sd+9bTPxkvaxZOxU4qyop8UYmzoTu7NG+ X-Received: by 2002:a17:906:354c:: with SMTP id s12mr27740361eja.263.1602499203152; Mon, 12 Oct 2020 03:40:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602499203; cv=none; d=google.com; s=arc-20160816; b=CnumfHqTXY3cZ2d5U0Z5FFAgnhmfXHDqSdlxAESOa+Mh5u/pXgoek4TQZ6tDEhBS8T k5t72bSo/VZJyz4wiyAvUjt/1Mympi3vXevl4JpEfx7blOfx8LM2Rl8G7A/e4i1LMwoW BLRo2QP+cQ6U6LPkRNvrTr6rKvHSZvQQnxj1Nl4oQVjtB5lt2ixxtKHcIx+M51A4EkGe aWOCd39aCaElyNbvStFT9RxIe7BPUG4gDwWYATYOz3Tss/imbm9bdb3CLztqEePfecVG tbUhgZbsz9j8cRTjA1AZB8YdbyJnOtZ5gxXhpwGzysaC6SOj6aex2EZqkWOojBp6iECY ocEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=WZu2ZJgxmqRA+4rOPaLDNTHDAX+yGlssccVJRc/8twc=; b=wuLb1BkbdC2SDWdvAQfVXFNH8wtuVinQwgTAXGgYassVn7+FamSN5XllxG80WcyDc2 GXmZPnv/XAOuViu3jsgy6UfdIWirnfTRFEtLNeOos7HDVzJNIpriT1AHfjdTJYf19oOJ CJsDiVeGOjhD6gMdHJtAxrsAo2wbVbbCISc65iLd2ZhDAJe1rUR4JcJu+/LGoOvJJOYR tTY38eszygmlPHk3keXpoYpTzmU7O0SoJzRIMTbZx/j9ATQsv6kCerxuPIUxQmlC75gq dbVpRyRz0vLvJAbGAiLotVvrA3zwfhI/J/G2/C/gy2ADb7BYAAjn9UWI/t2p8noasJcV m+ZA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bm17si11730726ejb.356.2020.10.12.03.39.40; Mon, 12 Oct 2020 03:40:03 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387612AbgJLKiS (ORCPT + 99 others); Mon, 12 Oct 2020 06:38:18 -0400 Received: from elvis.franken.de ([193.175.24.41]:58426 "EHLO elvis.franken.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387597AbgJLKiS (ORCPT ); Mon, 12 Oct 2020 06:38:18 -0400 Received: from uucp (helo=alpha) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1kRvDc-0008KW-00; Mon, 12 Oct 2020 12:38:16 +0200 Received: by alpha.franken.de (Postfix, from userid 1000) id 15B15C1129; Mon, 12 Oct 2020 12:01:17 +0200 (CEST) Date: Mon, 12 Oct 2020 12:01:17 +0200 From: Thomas Bogendoerfer To: Serge Semin Cc: Hauke Mehrtens , =?utf-8?B?UmFmYcWCIE1pxYJlY2tp?= , Florian Fainelli , bcm-kernel-feedback-list@broadcom.com, "Maciej W. Rozycki" , 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: <20201012100117.GA6959@alpha.franken.de> References: <20201008084357.42780-1-tsbogend@alpha.franken.de> <20201008152006.4khkbzsxqmmz76rw@mobilestation> <20201009120752.GA10588@alpha.franken.de> <20201009141537.ijj4cr45zqtkh4yz@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201009141537.ijj4cr45zqtkh4yz@mobilestation> User-Agent: Mutt/1.5.23 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 09, 2020 at 05:15:37PM +0300, Serge Semin wrote: > On Fri, Oct 09, 2020 at 02:07:52PM +0200, Thomas Bogendoerfer wrote: > > On Thu, Oct 08, 2020 at 06:20:06PM +0300, Serge Semin wrote: > > > > @@ -426,13 +387,14 @@ static int __init early_parse_memmap(char *p) > > > > > > > > if (*p == '@') { > > > > start_at = memparse(p+1, &p); > > > > - add_memory_region(start_at, mem_size, BOOT_MEM_RAM); > > > > + memblock_add(start_at, mem_size); > > > > } else if (*p == '#') { > > > > pr_err("\"memmap=nn#ss\" (force ACPI data) invalid on MIPS\n"); > > > > return -EINVAL; > > > > } else if (*p == '$') { > > > > start_at = memparse(p+1, &p); > > > > > > > - add_memory_region(start_at, mem_size, BOOT_MEM_RESERVED); > > > > + memblock_add(start_at, mem_size); > > > > + memblock_reserve(start_at, mem_size); > > > > > > I suppose we could remove the memory addition from here too. What do you think? > > > > > I'm not sure about that, add_memory_region() did a memblock_add > > and then memblock_reserve for BOOT_MEM_RESERVED, that's why I changed > > it that way. > > The main question here whether we need to preserve the MIPS-specific semantics > of the kernel 'memmap' parameter. Currently the memmap parameter passed with > '$' specifier will be perceived as a reserved RAM region, while, for instance, > the same parameter on x86 will be converted to a region, which won't be > registered in memblock at all, so the system won't be able to reuse it if it's > needed to be (see parse_memmap_one() and e820__memblock_setup() for details). > > I don't really know what approach is correct... > Documentation/admin-guide/kernel-parameters.txt isn't certain about that. It > says that the region must be reserved, but no words whether it is supposed to be > mappable or non-mappable. I leave it as in v3 of the patch for now. If we come to the point what the correct semantic should be, we can change it. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]