Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3511794pxp; Tue, 8 Mar 2022 16:18:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+ruTyl52NKmqtft4bsctRSKZRL1gQZgSFlOFXoVPiE8ewA0+57KbF3cbvn02dun0txc1J X-Received: by 2002:a17:90b:906:b0:1be:e765:882 with SMTP id bo6-20020a17090b090600b001bee7650882mr7587718pjb.152.1646785092942; Tue, 08 Mar 2022 16:18:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646785092; cv=none; d=google.com; s=arc-20160816; b=ia2a+NHfxaThUX2jy2L3+FEz/MEpUrgd+SbgPUW2ju2g8TIZA5wp95Ji64TTM1UMN1 CJa8yNomIT8pzpIncPKgVGrKYjjGdqrmVmTM+nbCUz0P3xFId3v7DBOduz501CtGUYD/ kCuPwYDI3Fp5Wvikwe/IruvdXAG4IJo3U6g4vGfNwG8wYtWz9Oz3XoxdX2FZwMpgEHcy VfAVvF3sAzlLhf07FBALS53KLJGJ5KurRkT0FiiwwGeO/760nAdC84Om5LzI6gOIE5hr 9EGvMSyv6QTt/MVAr/ro7t8mVv8LslkBu+U8/S64Vot8NeTHbW76XZfWEnjN5X1hzN8N lMOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=lzbAVhwq23kQUjqg+/3qo+IqYcQrnRM1+mtj1M7G5kQ=; b=U7l8H5DaqkLOxJLB9XS7wrw7lbSU31mdqNUCgjma8R7TxQeKx9qgKxsIDNBYO9spwE js9kD4QuxZ0kxy0qMtZd1dq7bkyDm/aQE5MrldA8sVaw9Z5sm2fdmdWMDx8ECHdxOX6f h0zcmxcyWaNAtDdvkPkPEg0hGTEZXrxgCEUoqrfaL5Nr6JWq6UpKfx3pErN/GomPtTeu wwzr1thS50DNPdO64Q80G10npAzD+lOvfHMfkhPREluMdA2CcWZsdlK8FMov1BizkNHJ zzprv6rOOeWNMT5ricZKfHftSpMhX4mngnQFONDLAY5dtYxN6lsv4irK92YCywqA6mXy nusw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id h10-20020a170902f70a00b001513f2d8b19si392333plo.375.2022.03.08.16.18.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 16:18:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B2BBCBA772; Tue, 8 Mar 2022 15:43:59 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343871AbiCGXK2 (ORCPT + 99 others); Mon, 7 Mar 2022 18:10:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236037AbiCGXKZ (ORCPT ); Mon, 7 Mar 2022 18:10:25 -0500 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DC22DFD08; Mon, 7 Mar 2022 15:09:30 -0800 (PST) Received: by angie.orcam.me.uk (Postfix, from userid 500) id BCAF992009C; Tue, 8 Mar 2022 00:09:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id B5C4A92009B; Mon, 7 Mar 2022 23:09:28 +0000 (GMT) Date: Mon, 7 Mar 2022 23:09:28 +0000 (GMT) From: "Maciej W. Rozycki" To: Mike Rapoport cc: Thomas Bogendoerfer , Tiezhu Yang , Andrew Morton , Xuefeng Li , linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem= parameter In-Reply-To: Message-ID: References: <1646108941-27919-1-git-send-email-yangtiezhu@loongson.cn> <1646108941-27919-2-git-send-email-yangtiezhu@loongson.cn> <20220304151052.GA27642@alpha.franken.de> <20220304153517.GA28487@alpha.franken.de> <20220307162909.GA18728@alpha.franken.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Mar 2022, Mike Rapoport wrote: > > So can I just limit amount of memory without interfering with normal > > memory detection ? > > Maybe it's better to add a new encoding to mem= that will have the semantics > of limiting amount of memory? > > E.g. > > mem=384M@ > > would mean "only use 384M of memory that firmware reported" while > > mem=384M would mean "set memory to 0 - 384M" as it does now. I think you're going in the right direction, we'd just need to sort out the most reasonable syntax for the new semantics; `mem=384M@' just seems too analogous to me to `mem=384M@0'. Maybe `mem=384M-'? NB that would have to work with the existing overrides, for e.g.: `mem=192M@0 mem=192M@256M mem=384M-' to produce the following memory ranges available for use: Normal [mem 0x0000000000000000-0x000000000bffffff] Normal [mem 0x0000000010000000-0x0000000017ffffff] (so that you can paste the final cap at some command prompt and still have earlier parameters respected that may have been passed by the firmware or bootloader, or built in). Maciej