From patchwork Mon Apr 16 16:47:45 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rob Herring X-Patchwork-Id: 10343483 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CE096601D7 for ; Mon, 16 Apr 2018 16:48:09 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BDAFB286C2 for ; Mon, 16 Apr 2018 16:48:09 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B2255286FB; Mon, 16 Apr 2018 16:48:09 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 5589D286C2 for ; Mon, 16 Apr 2018 16:48:08 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id DE46E2263DD98; Mon, 16 Apr 2018 09:48:08 -0700 (PDT) X-Original-To: linux-nvdimm@lists.01.org Delivered-To: linux-nvdimm@lists.01.org Received-SPF: None (no SPF record) identity=mailfrom; client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=robh@kernel.org; receiver=linux-nvdimm@lists.01.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 249972263DD64 for ; Mon, 16 Apr 2018 09:48:07 -0700 (PDT) Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com [209.85.216.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C4CFD21837 for ; Mon, 16 Apr 2018 16:48:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4CFD21837 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh@kernel.org Received: by mail-qt0-f180.google.com with SMTP id a25so9721929qtm.1 for ; Mon, 16 Apr 2018 09:48:06 -0700 (PDT) X-Gm-Message-State: ALQs6tAvHmF8vZFm9aWI7Artkv22NuruCD7WiIYolyPisPy/XiBUayHT g9+UTcMevZul2uiGZ2ESY0QDtqhHiMtkyS59LQ== X-Google-Smtp-Source: AIpwx49GSjcJES6cBZpzMLyn1X0yTj/Dtf5zShAr1xLRTk6i8/QEkUizY+hiFpT911+pAbeKXc+2bjtDGmsUo8byIxg= X-Received: by 10.237.56.2 with SMTP id j2mr5071603qte.205.1523897285984; Mon, 16 Apr 2018 09:48:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.163.228 with HTTP; Mon, 16 Apr 2018 09:47:45 -0700 (PDT) In-Reply-To: References: <20180409074604.17671-1-oohall@gmail.com> From: Rob Herring Date: Mon, 16 Apr 2018 11:47:45 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA To: Dan Williams X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stephen Rothwell , linux-nvdimm , "linux-kernel@vger.kernel.org" , Device Tree , sparclinux@vger.kernel.org, linuxppc-dev Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Apr 9, 2018 at 4:05 PM, Dan Williams wrote: > On Mon, Apr 9, 2018 at 1:52 PM, Rob Herring wrote: >> On Mon, Apr 9, 2018 at 2:46 AM, Oliver O'Halloran wrote: >>> Some OF platforms (pseries and some SPARC systems) has their own >>> implementations of NUMA affinity detection rather than using the generic >>> OF_NUMA driver, which mainly exists for arm64. For other platforms one >>> of two fallbacks provided by the base OF driver are used depending on >>> CONFIG_NUMA. >>> >>> In the CONFIG_NUMA=n case the fallback is an inline function in of.h. >>> In the =y case the fallback is a real function which is defined as a >>> weak symbol so that it may be overwritten by the architecture if desired. >>> >>> The problem with this arrangement is that the real implementations all >>> export of_node_to_nid(). Unfortunately it's not possible to export the >>> fallback since it would clash with the non-weak version. As a result >>> we get build failures when: >>> >>> a) CONFIG_NUMA=y && CONFIG_OF=y, and >>> b) The platform doesn't implement of_node_to_nid(), and >>> c) A module uses of_node_to_nid() >>> >>> Given b) will be true for most platforms this is fairly easy to hit >>> and has been observed on ia64 and x86. >> >> How specifically do we hit this? The only module I see using >> of_node_to_nid in mainline is Cell EDAC driver. > > The of_pmem driver is using it currently pending for a 4.17 pull > request. Stephen hit the compile failure in -next. I took a look at this. The correct fix here is to use dev_to_node() instead: And we should remove the exported symbol. I'll send a proper patch. Rob diff --git a/drivers/nvdimm/of_pmem.c b/drivers/nvdimm/of_pmem.c index 85013bad35de..0a701837dfc0 100644 --- a/drivers/nvdimm/of_pmem.c +++ b/drivers/nvdimm/of_pmem.c @@ -67,7 +67,7 @@ static int of_pmem_region_probe(struct platform_device *pdev) */ memset(&ndr_desc, 0, sizeof(ndr_desc)); ndr_desc.attr_groups = region_attr_groups; - ndr_desc.numa_node = of_node_to_nid(np); + ndr_desc.numa_node = dev_to_node(&pdev->dev); ndr_desc.res = &pdev->resource[i]; ndr_desc.of_node = np; set_bit(ND_REGION_PAGEMAP, &ndr_desc.flags);