From: Christoph Hellwig <hch@infradead•org>
To: Oliver O'Halloran <oohall@gmail•com>
Cc: linux-kernel@vger•kernel.org, sfr@canb•auug.org.au,
devicetree@vger•kernel.org, linux-nvdimm@lists•01.org,
sparclinux@vger•kernel.org, linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA
Date: Mon, 9 Apr 2018 10:49:18 -0700 [thread overview]
Message-ID: <20180409174918.GA4629@infradead.org> (raw)
In-Reply-To: <20180409074604.17671-1-oohall@gmail.com>
On Mon, Apr 09, 2018 at 05:46:04PM +1000, 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.
>
> This patch remedies the problem by introducing the ARCH_HAS_OWN_OF_NUMA
> Kconfig option which is selected if an architecture provides an
> implementation of of_node_to_nid(). If a platform does not use it's own,
> or the generic OF_NUMA, then always use the inline fallback in of.h so
> we don't need to futz around with exports.
I'd rather have a specific kconfig symbol for the 'generic'
implementation, especially given that it doesn't appear to be all
that generic.
next prev parent reply other threads:[~2018-04-09 17:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 7:46 [PATCH] drivers/of: Introduce ARCH_HAS_OWN_OF_NUMA Oliver O'Halloran
2018-04-09 17:49 ` Christoph Hellwig [this message]
2018-04-09 20:52 ` Rob Herring
2018-04-09 21:05 ` Dan Williams
2018-04-10 1:02 ` Rob Herring
2018-04-10 2:29 ` Dan Williams
2018-04-16 16:47 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180409174918.GA4629@infradead.org \
--to=hch@infradead$(echo .)org \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-nvdimm@lists$(echo .)01.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=oohall@gmail$(echo .)com \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=sparclinux@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox