Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp222503pxk; Sun, 30 Aug 2020 00:27:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjg+LES3XMJYfLQMYr7nvni0bxlcxeiu40xMAEmeH+VMRP8sSj8uiQ/+O9atd9LCUWrbI7 X-Received: by 2002:a17:906:b156:: with SMTP id bt22mr6517392ejb.481.1598772445815; Sun, 30 Aug 2020 00:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598772445; cv=none; d=google.com; s=arc-20160816; b=uCKbHV1TeEZecnTQvvZt/+FE/DX9yOw30PVb1f2OCJ1O4JjfHSPI5rRAlVSGHZHxZw YQUtrq4cc6tABNShZpiQHsEHDHkNEwDPPi8btp5FVFVINgp//NG/tZW3I8bgT2BtKSoh 5H72zm1rHMHjWTjvWyxgLonj8GZaoC9BDTFAAn1uLkpCfTsa9yMGs3Ft8ylb0P9Htsx+ Q+p9SjaLxe4yZ+s0MUWbMh22QYhe/Secd2UJzs1MAesvqCWBsAEvT4TIipc/BV8wVygE zBnaZgyIhHVvysMjO2chwBm23GziJXBhIt1GqrwPtUiwM7MnUhK48X1LO9mt3Q+NKL7p a1kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=4opMeD0irkmL+H/7a2xU8cjZEUDcxPJmk8YZgecU11U=; b=l7NP54EXQQ8vawym7KJYI7mfg7hcFmWyHTcndPA09W0Z4Oi/Ccpo5A1iA5uEvcp+cI kj35d2UaO1PLOpgdOjDSbCy1cVnCZOFyIHHWc3IagLszc0H25fCF92khJs6IatsPix02 Ho5AtBrQrWZyRYjemUIwDOe6voC9Ag7GaQKx0dODXmn7X2jjDYSkMEztiycGAa1chS54 ooEvNloeq+bYy1tSCiw2nGoh/JAcvYUcVBdHtHcgzgnnWuE1qm+4dCzannCXCv1tozfy 2oASr+XXqCEUe1DFDFhxFzQs9KkLDVps9nSVN7dzvk7Kfgn2sC30BYUZoHX642i1KXvE Gh0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@atishpatra.org header.s=google header.b=ev41B5EF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i7si3651730ejo.667.2020.08.30.00.27.03; Sun, 30 Aug 2020 00:27:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@atishpatra.org header.s=google header.b=ev41B5EF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726501AbgH3HWk (ORCPT + 99 others); Sun, 30 Aug 2020 03:22:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726459AbgH3HWh (ORCPT ); Sun, 30 Aug 2020 03:22:37 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3CBBC061236 for ; Sun, 30 Aug 2020 00:22:36 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id z9so2603659wmk.1 for ; Sun, 30 Aug 2020 00:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atishpatra.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4opMeD0irkmL+H/7a2xU8cjZEUDcxPJmk8YZgecU11U=; b=ev41B5EFXjL0HxofoOjttHQ6QGEn6veUb6kOs0Ns242BN1OiMhySf9H/hh07Qnpbkg MMpLIVSS65ZDgDHIx7PElFL0cBpwbRgELXBC7jdMB0bsznVUrSRYgX1ja2svjiYa/Pf/ oxnXESGpn2lQhS8u6tRI8ir0+iNweFG5aY838= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4opMeD0irkmL+H/7a2xU8cjZEUDcxPJmk8YZgecU11U=; b=rM6H1mWx3cEpm2Fd1PwmO7zDfHpq4xwkSubHDGBkyuTMplJq0gpTWvg0dIJAocMVhY O7nDpaviVtFahLNhkaxyCl5GRgyevfzRH6zrJxp3dN2HT7mJYZi9UP/zLMMxOQEOZwRy ycJQ9PWngcbIlvN8nm2ysOm697S3IACcl9sDGYIhudJmWn1onHXL3cYmbjhpRMbIDmgC xqWnuAtOhvpX6yBzD7N3nVTtj+yKqfbDYtDY+jt9Ab4TcaWsPr/fmAZ4COkTCh1IBuMk mezKe+lTTIVJCzAHvyvNFLSEB0c9P9jFfZZSROThyTFgMukreFVaMtAL8nvzzr/xZrav Lo4Q== X-Gm-Message-State: AOAM531DF+4kA5ERF4dJyeKnNiv5puLTKaKy9phdVTswCodZK9Vc4Gym QzXZJkUDv69XlqR6SyHOFHRKx9jrY8i7Ug99rQ9o X-Received: by 2002:a05:600c:230f:: with SMTP id 15mr5945544wmo.186.1598772155263; Sun, 30 Aug 2020 00:22:35 -0700 (PDT) MIME-Version: 1.0 References: <20200830025438.GA9624@bjorn-Precision-5520> In-Reply-To: <20200830025438.GA9624@bjorn-Precision-5520> From: Atish Patra Date: Sun, 30 Aug 2020 00:22:24 -0700 Message-ID: Subject: Re: [RFC/RFT PATCH 3/6] arm64, numa: Move pcibus_to_node definition to generic numa code To: Bjorn Helgaas Cc: Jonathan Cameron , "Rafael J. Wysocki" , Catalin Marinas , Atish Patra , Zong Li , linux-riscv , Will Deacon , linux-arch@vger.kernel.org, Rob Herring , Lorenzo Pieralisi , Ganapatrao Kulkarni , Steven Price , linux-pci@vger.kernel.org, Greentime Hu , Albert Ou , Arnd Bergmann , Anshuman Khandual , Paul Walmsley , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" , Nick Hu , Greg Kroah-Hartman , Anup Patel , "linux-kernel@vger.kernel.org List" , Palmer Dabbelt , Andrew Morton , Mike Rapoport Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 29, 2020 at 7:54 PM Bjorn Helgaas wrote: > > On Fri, Aug 28, 2020 at 06:11:50PM -0700, Atish Patra wrote: > > On Fri, Aug 28, 2020 at 9:15 AM Bjorn Helgaas wrote: > > > On Fri, Aug 28, 2020 at 10:48:30AM +0100, Jonathan Cameron wrote: > > > > On Fri, 14 Aug 2020 14:47:22 -0700 > > > > Atish Patra wrote: > > > > > > > > > pcibus_to_node is used only when numa is enabled and does not depend > > > > > on ISA. Thus, it can be moved the generic numa implementation. > > > > > > > > > > Signed-off-by: Atish Patra > > > > > > > > From a more general unification point of view, there seem to > > > > be two ways architectures implement this. > > > > Either > > > > > > > > bus->sysdata.node > > > > > > > > Or as here. > > > > There are weird other options, but let us ignore those :) > > > > > > > > That is going to take a bit of unwinding should we > > > > want to take this unification further and perhaps we want to think > > > > about doing this in pci generic code rather than here? > > > > > > > > Perhaps this is one we are better keeping architecture specific for > > > > now? > > > > > > > > +CC Bjorn and Linux-pci > > > > > > > > > > > > > --- > > > > > arch/arm64/kernel/pci.c | 10 ---------- > > > > > drivers/base/arch_numa.c | 11 +++++++++++ > > > > > 2 files changed, 11 insertions(+), 10 deletions(-) > > > > > > > > > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c > > > > > index 1006ed2d7c60..07c122946c11 100644 > > > > > --- a/arch/arm64/kernel/pci.c > > > > > +++ b/arch/arm64/kernel/pci.c > > > > > @@ -54,16 +54,6 @@ int raw_pci_write(unsigned int domain, unsigned int bus, > > > > > return b->ops->write(b, devfn, reg, len, val); > > > > > } > > > > > > > > > > -#ifdef CONFIG_NUMA > > > > > - > > > > > -int pcibus_to_node(struct pci_bus *bus) > > > > > -{ > > > > > - return dev_to_node(&bus->dev); > > > > > -} > > > > > -EXPORT_SYMBOL(pcibus_to_node); > > > > > - > > > > > -#endif > > > > > - > > > > > #ifdef CONFIG_ACPI > > > > > > > > > > struct acpi_pci_generic_root_info { > > > > > diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c > > > > > index 83341c807240..4ab1b20a615d 100644 > > > > > --- a/drivers/base/arch_numa.c > > > > > +++ b/drivers/base/arch_numa.c > > > > > @@ -11,6 +11,7 @@ > > > > > #include > > > > > #include > > > > > #include > > > > > +#include > > > > > #include > > > > > > > > > > #ifdef CONFIG_ARM64 > > > > > @@ -60,6 +61,16 @@ EXPORT_SYMBOL(cpumask_of_node); > > > > > > > > > > #endif > > > > > > > > > > +#ifdef CONFIG_PCI > > > > > + > > > > > +int pcibus_to_node(struct pci_bus *bus) > > > > > +{ > > > > > + return dev_to_node(&bus->dev); > > > > > +} > > > > > +EXPORT_SYMBOL(pcibus_to_node); > > > > > + > > > > > +#endif > > > > > > I certainly agree that this should not be arch-specific, but I'm not > > > really in favor of adding this PCI gunk in drivers/base. > > > > > > I think we can do better (eventually) by getting rid of > > > pcibus_to_node() completely. It's not used very much except by > > > cpumask_of_pcibus(), which itself is hardly used at all. > > > > > I am a bit confused here. A quick grep suggested that pcibus_to_node() > > is also called from generic pci probe, > > controller and few drivers(block, infiniband) as well. Maybe I am > > missing something here ? > > I didn't say it was *only* used by cpumask_of_pcibus(). 13 of the 29 > calls are from cpumask_of_pcibus(). > Ahh okay. Sorry I misunderstood that. > As you point out, there are a few drivers that use it. They typically > have a pci_dev, so they do the equivalent of pcibus_to_node(pdev->bus). > That seems silly; they should just do dev_to_node(&pdev->dev) instead. > That covers the use case for ARM64. There are other arch implementations as well which retrieve node information from sysdata which seems to be type casted to different structures on different arch. What should be done for those ? > I looked at this once, and it seems like there might have been a > wrinkle like the pdev->dev node not being set correctly or something. > If that's the case, I think it should be fixed. > > > We can move the pcibus_to_node to arch specific code for now if that's > > what is preferred. > > Now I'm the one who's confused :) Most arches, including arm64, > already have arch-specific implementations of pcibus_to_node(). I > didn't look at the rest of the series to see if there's a reason you > need to move pcibus_to_node() from arch/arm64/kernel/pci.c to > drivers//base/arch_numa.c. If you don't need to, I would just leave > it where it is. > The reason I moved it from arch/arm64/kernel/pci.c to drivers//base/arch_numa.c. so that we don't have to define it for RISC-V. But it's just a single line function and we can define it in RISC-V as well. I will try that in v2. > > > > > static void numa_update_cpu(unsigned int cpu, bool remove) > > > > > { > > > > > int nid = cpu_to_node(cpu); -- Regards, Atish