Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp832291imu; Thu, 22 Nov 2018 06:06:05 -0800 (PST) X-Google-Smtp-Source: AFSGD/X0Cl0TTNgx6AV2etZD01FflPKedQTTXuCcN+h5EUdTdAf2qzq7QRGrLVmcJqM8/XcQh+9R X-Received: by 2002:a63:d846:: with SMTP id k6mr10402794pgj.251.1542895565488; Thu, 22 Nov 2018 06:06:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542895565; cv=none; d=google.com; s=arc-20160816; b=mA1YtihEwcCIwRLlgRFg9WahSg2cOpv95vRySJqTQPanIAIGDyhPRvMfj+b/ztL183 qJJGilN/lMnDCTJgZOJWCbTDivIVgfb0dfKmFMX3bsveuJvCInAAWriXJPY9wWic/xpZ CAY4gYnhbWsMj4mwJgJWGBD7odkenjhJ7T7o4YaERWPKotQUTVFRHKzJizcyK+j5gtYa 2EvT+zna9B0MvApnK11kUpoVu3uPeNzbNcJr29uYIrebnc9uAdQVaSE/xeW88b3RW2NT WbhTlOSCHLAzAGM/iV1eXZxi9VwYVZLJWgPsQOnr1SCLhdedJt9GPTl3QNlRUMCS2ZU7 FPpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=QiMemOWtBIqCq1kvpML97aUDTRO9auLVHx+zVLFhrH0=; b=KDlDW6TgcshFj8PRDY5zQ5+HQM36aHf5PXbl5AIez/tINCtOLGpephTPCWkwGmKmbJ 8F5xD3V8AInP6PXtAyu3nsxZlLgb3lgBJEMtG4RyhlcCMR4Yi4TrYnT4HFUzSZsWFmPc NTWa1xYmIkjsp4XlY6J4GGVbr0Td5vHIMUDoHkuQtveW2WqSgMjo3cNZnRKlvuOw7QQs vdfj7XHNYXXegE295OYprm0IEgWNN33nb5iZkRlpLw9CmzpZbzUYKGF4ESVN58NeGdrZ 15YdJJ+TuVVwqq+UZj2tj5uohB04oehB0AQDzi7c8PJqSf0fwG23PyySNWW9KoScOrjW WSjw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cc17si21323932plb.265.2018.11.22.06.05.51; Thu, 22 Nov 2018 06:06:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391714AbeKVN3D (ORCPT + 99 others); Thu, 22 Nov 2018 08:29:03 -0500 Received: from mailgw02.mediatek.com ([210.61.82.184]:2131 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1731067AbeKVN3D (ORCPT ); Thu, 22 Nov 2018 08:29:03 -0500 X-UUID: 0fd465dc1d524ac3bbf514f304526ab1-20181122 X-UUID: 0fd465dc1d524ac3bbf514f304526ab1-20181122 Received: from mtkcas09.mediatek.inc [(172.21.101.178)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 826227019; Thu, 22 Nov 2018 10:51:29 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs03n1.mediatek.inc (172.21.101.181) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 22 Nov 2018 10:51:28 +0800 Received: from [172.21.77.33] (172.21.77.33) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Thu, 22 Nov 2018 10:51:28 +0800 Message-ID: <1542855088.15789.6.camel@mtkswgap22> Subject: Re: [RFC PATCH] of: make MAX_RESERVED_REGIONS configurable From: Miles Chen To: Rob Herring CC: Frank Rowand , , "linux-kernel@vger.kernel.org" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , , Date: Thu, 22 Nov 2018 10:51:28 +0800 In-Reply-To: References: <1542787873-8429-1-git-send-email-miles.chen@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-11-21 at 10:39 -0600, Rob Herring wrote: > On Wed, Nov 21, 2018 at 2:11 AM wrote: > > > > From: Miles Chen > > > > When we use more than 32 entries in /resered-memory, > > there will be an error message: "not enough space all defined regions.". > > We can increase MAX_RESERVED_REGIONS to fix this. > > > > commit 22f8cc6e3373 ("drivers: of: increase MAX_RESERVED_REGIONS to 32") > > increased MAX_RESERVED_REGIONS to 32 but I'm not sure if increasing > > MAX_RESERVED_REGIONS to 64 is suitable for everyone. > > > > In this RFC patch, CONFIG_MAX_OF_RESERVED_REGIONS is added and used as > > MAX_RESERVED_REGIONS. Add a sanity test to make sure that > > MAX_RESERVED_REGIONS is less than INIT_MEMBLOCK_REGIONS. > > Users can configure CONFIG_MAX_OF_RESERVED_REGIONS according to their > > need. > > I don't want a kconfig option for this. I think it should be dynamic instead. > > The current flow is like this: > > for each reserved node: > - call memblock_reserve > - Add info to reserved_mem array > > I think we should change it to: > > for each reserved node: > - call memblock_reserve > - count number of nodes > > Alloc array using memblock_alloc > > for each reserved node: > - Add info to reserved_mem array > thanks for your comment. I reviewed the flow and it might be easier to count the nodes and setup array first: for each reserved node: - count number of nodes Alloc array using memblock_alloc for each reserved node: - call memblock_reserve - Add info to reserved_mem array What do you think? > Rob