Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp4859667ima; Tue, 5 Feb 2019 02:29:14 -0800 (PST) X-Google-Smtp-Source: AHgI3IbZaThvTfG4gmNR0niA94TmsuwxLKpJ4SFx9OqkikDh2dhI+BbHSn90jPeE+BicWfdSPDdZ X-Received: by 2002:a63:ea15:: with SMTP id c21mr3651049pgi.361.1549362554885; Tue, 05 Feb 2019 02:29:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549362554; cv=none; d=google.com; s=arc-20160816; b=CIcDMUY7BER7tEj/c5pQmnv7HPa7j57PGi41+tzsXCnyWYh1zUxclGsjvzCR0yRDev KHn3HFliEmiT9DQMJuvzhdTah4XjBbfKydjKwzDfOLHGfVynj2i6iuSDahskAzyOq62P T3ksTGyWUO1rY4+kvyGsq8VLnn+kaBk3GGjHyiKYI//a+1hc0nVvLlai/+Pb7N+tadyL dvLHcL+6HBerJigM4YnPZ0VUncq1bR17RKEKNca9+TOovDFPmr+pOMes5Kp7gSCgE2qL pVGWp7ZwMDQQznN95ieucYnKM/OfxjrwDhYQ/XXg/MC5QAL1Ih2Fxh+ziekjQNxiojQi THTw== 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 :message-id:date:references:in-reply-to:subject:cc:to:from; bh=1kO9ES4cVeZgzufD2I1tdoFSgqVV9QRs4gze3eIIlHM=; b=cQjZ87Vdr9EQuwaLZduBGG1iBldXTAg3PyW19bOkvvs0vMm3O3VeRwkFWDQxUT6WnE lG19EtG0rwlOLh/kMPyq8OrKWcLSXanqf3R2VPYUQgLfhYBj++kqNanTuhOfXWXe2WvZ zEpr3a57h1jy816YPKP9xasL23IvplEp28JCrUtSoO+XOIFGvdea4/ZR3TDZvRUv0BI9 6Oh25prq8AdkTFWtTEAwxPUCUJh9YNdklo5PlWaV54VB0zeNvjNhf+2Q7vIZjQflUsgc EZQipaozztGxfGhwBsOQo2h1tt6xjR2gxpMUrAuylMHNq1hhBnkJh1iO1wkIFLPBAkhm rn4Q== 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 i9si2924215plb.35.2019.02.05.02.28.59; Tue, 05 Feb 2019 02:29:14 -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 S1728879AbfBEKEH convert rfc822-to-8bit (ORCPT + 99 others); Tue, 5 Feb 2019 05:04:07 -0500 Received: from ozlabs.org ([203.11.71.1]:59119 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726334AbfBEKEH (ORCPT ); Tue, 5 Feb 2019 05:04:07 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43v0Xj1NPfz9sMl; Tue, 5 Feb 2019 21:04:05 +1100 (AEDT) From: Michael Ellerman To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2] powerpc: drop page_is_ram() and walk_system_ram_range() In-Reply-To: <248f8aa2-10c2-2728-6f94-a56816a989e1@c-s.fr> References: <875ztzonqd.fsf@concordia.ellerman.id.au> <248f8aa2-10c2-2728-6f94-a56816a989e1@c-s.fr> Date: Tue, 05 Feb 2019 21:04:03 +1100 Message-ID: <87tvhimu0c.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: > Le 04/02/2019 à 11:24, Michael Ellerman a écrit : >> Christophe Leroy writes: >> >>> Since commit c40dd2f76644 ("powerpc: Add System RAM to /proc/iomem") >>> it is possible to use the generic walk_system_ram_range() and >>> the generic page_is_ram(). >>> >>> To enable the use of walk_system_ram_range() by the IBM EHEA >>> ethernet driver, the generic function has to be exported. >> >> I'm not sure if we have a policy on that, but I suspect we'd rather not >> add a new export on all arches unless we need to. Especially seeing as >> the only user is the EHEA code which is heavily in maintenance mode. > > If you take the exemple of function walk_iomem_res_desc(), that's > similar. It is only used by x86 it seems and exported for nvdimm/e820 > driver only. > > See commit d76401ade0bb6ab0a7 ("libnvdimm, e820: Register all pmem > resources") OK. Which begs the question whether we need both exported. It looks like you could probably use walk_iomem_res_desc() with the right flags to do the same thing as walk_system_ram_range(). >> I'll put the export in powerpc code and make sure that builds. > > I thought there was a rule that EXPORT_SYMBOL has to immediately follow > the function it exports. At least checkpatch checks for that. Yeah that is a rule. But rules are made to be broken :) I'll merge it for now with the export in powerpc code, if we want to we can do a separate patch to move that export into generic code and get acks for that. cheers