Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp485625imm; Wed, 19 Sep 2018 02:05:40 -0700 (PDT) X-Google-Smtp-Source: ANB0VdY34buZ0npB3/fr74zIDzcjNwOGunmv47rwASChI8thYHr4YIo4NjO3ok3tVpNxCKy5L4F7 X-Received: by 2002:a62:b0e:: with SMTP id t14-v6mr34640545pfi.36.1537347940232; Wed, 19 Sep 2018 02:05:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537347940; cv=none; d=google.com; s=arc-20160816; b=yJqmEmtyOuxB14i8II2Z8fWuJpnhEXEiYLNKtUPJv67EAgoF2SuonbqxLbXEs/Gbpm ikBEbAZ5iNfp9qaJiTglsRmMugsuxRRtTNylf1gDYtfNIqB2sKaojrFGSlECYEUaSPMl gfljY2YArHux2mkIXu7d7hVKiEAfLQ5edT5vqzt+IrxB/xKVCm39wHvYMzbX1H8PFjTC lNY0WyoUdLEp39DL5F2smmbDGl4KmubHnhCNGSIevqjpfxUGheaiwmgzZvcB3C03cCkL pCppmSiaGPvYUatafjH192sM3zv47kuKZaYe/xQWtoTJRMyoAdf4ynePfeZ325FBt0rd m0PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=RZWph9J1uBQ2UvxL0UnVpe0TOUoq6uuEOK5SAJ/oO0Q=; b=qrMNfomxOjrh6NaIRLuuXwwvO3G0FbIkOaCs1DPPNSzns03gzgJYFd9QZzoZLodZKd R5dlMXw2G8z/uqwvgkFYs6w1HqjlBN8mEo9f+pGoPubSC5yBXFIxxmB1TH80nOFFO6wF 7nm3qx2JUevgRdKQXC7IUEItxV0NHTqNrxqrZHCP6yH1WTCD3TBDkDIB26lywLKWlNSA wHMKGJK8b6Ik4qIKdTmcfO+JjGa67sbd2JI1cxp+qQ6jxf9Ifp5J/GHqZw7dyuG9sV2K DHfWXVXf7bLHLoJg0kgt/WHESteO9PP5yU8h3yfhP1ce8weJS7p5LOvC1qs2xT566Auh MSzQ== 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 g20-v6si20444724pgb.239.2018.09.19.02.05.23; Wed, 19 Sep 2018 02:05:40 -0700 (PDT) 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 S1730967AbeISOmJ (ORCPT + 99 others); Wed, 19 Sep 2018 10:42:09 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:46079 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727770AbeISOmJ (ORCPT ); Wed, 19 Sep 2018 10:42:09 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 4DE785ADFD14B; Wed, 19 Sep 2018 17:05:09 +0800 (CST) Received: from localhost (10.202.226.46) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.399.0; Wed, 19 Sep 2018 17:05:03 +0800 Date: Wed, 19 Sep 2018 10:04:49 +0100 From: Jonathan Cameron To: Mike Rapoport CC: , Andrew Morton , "David S. Miller" , Greg Kroah-Hartman , Ingo Molnar , "Michael Ellerman" , Michal Hocko , Paul Burton , Thomas Gleixner , Tony Luck , , , , , , Subject: Re: [RFC PATCH 03/29] mm: remove CONFIG_HAVE_MEMBLOCK Message-ID: <20180919100449.00006df9@huawei.com> In-Reply-To: <1536163184-26356-4-git-send-email-rppt@linux.vnet.ibm.com> References: <1536163184-26356-1-git-send-email-rppt@linux.vnet.ibm.com> <1536163184-26356-4-git-send-email-rppt@linux.vnet.ibm.com> Organization: Huawei X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.226.46] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 5 Sep 2018 18:59:18 +0300 Mike Rapoport wrote: > All architecures use memblock for early memory management. There is no need > for the CONFIG_HAVE_MEMBLOCK configuration option. > > Signed-off-by: Mike Rapoport Hi Mike, A minor editing issue in here that is stopping boot on arm64 platforms with latest version of the mm tree. > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index 76c83c1..bd841bb 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -1115,13 +1115,11 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname, > return 1; > } > > -#ifdef CONFIG_HAVE_MEMBLOCK > #ifndef MIN_MEMBLOCK_ADDR > #define MIN_MEMBLOCK_ADDR __pa(PAGE_OFFSET) > #endif > #ifndef MAX_MEMBLOCK_ADDR > #define MAX_MEMBLOCK_ADDR ((phys_addr_t)~0) > -#endif This isn't the right #endif. It is matching with the #ifndef MAX_MEMBLOCK_ADDR not the intented #ifdef CONFIG_HAVE_MEMBLOCK. Now I haven't chased through the exact reason this is causing my acpi arm64 system not to boot on the basis it is obviously miss-matched anyway and I'm inherently lazy. It's resulting in stubs replacing the following weak functions. early_init_dt_add_memory_arch (this is defined elsewhere for some architectures but not arm) early_init_dt_mark_hotplug_memory_arch (there is only one definition of this in the kernel so it doesn't need to be weak or in the header etc). early_init_dt_reserve_memory_arch (defined on mips but nothing else) Taking out the right endif also lets you drop an #else removing some stub functions further down in here. Nice cleanup in general btw. Thanks, Jonathan > > void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size) > {