From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Myron Stowe <myron.stowe@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>,
rjw@rjwysocki.net, lorenzo.pieralisi@arm.com,
linaro-acpi@lists.linaro.org,
linux-pci <linux-pci@vger.kernel.org>,
catalin.marinas@arm.com, x86 <x86@kernel.org>,
will.deacon@arm.com, LKML <linux-kernel@vger.kernel.org>,
Tomasz Nowicki <tomasz.nowicki@linaro.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
hanjun.guo@linaro.org, "H. Peter Anvin" <hpa@zytor.com>,
wangyijing@huawei.com, Liviu.Dudau@arm.com,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 6/6] pci, acpi: Share ACPI PCI config space accessors.
Date: Fri, 21 Nov 2014 13:24:52 +0100 [thread overview]
Message-ID: <3957412.IooRKpIXjW@wuerfel> (raw)
In-Reply-To: <CAL-B5D3MqUa-=bzebo12DbZfczss2-MdGwQ8WKTbFH8H2AENXg@mail.gmail.com>
On Thursday 20 November 2014 21:00:17 Myron Stowe wrote:
> On Thu, Nov 20, 2014 at 3:26 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Wed, Nov 19, 2014 at 05:19:20PM +0100, Arnd Bergmann wrote:
> >> On Wednesday 19 November 2014 17:04:51 Tomasz Nowicki wrote:
> >> > +/*
> >> > + * raw_pci_read/write - ACPI PCI config space accessors.
> >> > + *
> >> > + * ACPI spec defines MMCFG as the way we can access PCI config space,
> >> > + * so let MMCFG be default (__weak).
> >> > + *
> >> > + * If platform needs more fancy stuff, should provides its own implementation.
> >> > + */
> >> > +int __weak raw_pci_read(unsigned int domain, unsigned int bus,
> >> > + unsigned int devfn, int reg, int len, u32 *val)
> >> > +{
> >> > + return pci_mmcfg_read(domain, bus, devfn, reg, len, val);
> >> > +}
> >> > +
> >> > +int __weak raw_pci_write(unsigned int domain, unsigned int bus,
> >> > + unsigned int devfn, int reg, int len, u32 val)
> >> > +{
> >> > + return pci_mmcfg_write(domain, bus, devfn, reg, len, val);
> >> > +}
> >> > +
> >> >
> >>
> >> I think it would be better to avoid __weak functions here, as they tend
> >> to be hard to follow when trying to understand the code.
> >
> > That's interesting. I would have said exactly the opposite -- I think the
> > extra Kconfiggery is harder to follow than weak/strong functions
> >
> > But consistency is better than my personal opinion. Is there a consensus
> > that we should use the Kconfig strategy instead of __weak?
>
> I too find weak/strong functions easier to follow than "Kconfiggery" (nice term
> invention there).
I don't think there is a universal consensus, but the majority of
maintainers seems to avoid them for the same reasons that I think
__weak is problematic.
We have some uses of __weak in the core kernel, but there is
basically none in drivers outside of PCI, and the most common
uses are all providing an empty __weak function that can be
overridden with a function that actually does something, unlike
the code above.
My pragmatic approach so far has been to advocate __weak for
drivers/pci patches but discourage it elsewhere when I review
patches, in order to maintain consistency. I also think it
would be nice to change the way that PCI handles architecture
specific overrides in the process of unifying the host bridge
handling.
I wouldn't use Kconfig symbols in most cases though. My preferred
choice would be to turn a lot of the __weak symbols into function
pointers within a per-hostbridge structure. As an example, we could
replace pcibios_add_device() with a pointer in pci_host_bridge->ops
that gets set by all the architectures and host drivers that currently
override it, and replace the one caller with
if (pci_host_bridge->ops->add_device)
pci_host_bridge->ops->add_device(dev);
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/6] pci, acpi: Share ACPI PCI config space accessors.
Date: Fri, 21 Nov 2014 13:24:52 +0100 [thread overview]
Message-ID: <3957412.IooRKpIXjW@wuerfel> (raw)
In-Reply-To: <CAL-B5D3MqUa-=bzebo12DbZfczss2-MdGwQ8WKTbFH8H2AENXg@mail.gmail.com>
On Thursday 20 November 2014 21:00:17 Myron Stowe wrote:
> On Thu, Nov 20, 2014 at 3:26 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Wed, Nov 19, 2014 at 05:19:20PM +0100, Arnd Bergmann wrote:
> >> On Wednesday 19 November 2014 17:04:51 Tomasz Nowicki wrote:
> >> > +/*
> >> > + * raw_pci_read/write - ACPI PCI config space accessors.
> >> > + *
> >> > + * ACPI spec defines MMCFG as the way we can access PCI config space,
> >> > + * so let MMCFG be default (__weak).
> >> > + *
> >> > + * If platform needs more fancy stuff, should provides its own implementation.
> >> > + */
> >> > +int __weak raw_pci_read(unsigned int domain, unsigned int bus,
> >> > + unsigned int devfn, int reg, int len, u32 *val)
> >> > +{
> >> > + return pci_mmcfg_read(domain, bus, devfn, reg, len, val);
> >> > +}
> >> > +
> >> > +int __weak raw_pci_write(unsigned int domain, unsigned int bus,
> >> > + unsigned int devfn, int reg, int len, u32 val)
> >> > +{
> >> > + return pci_mmcfg_write(domain, bus, devfn, reg, len, val);
> >> > +}
> >> > +
> >> >
> >>
> >> I think it would be better to avoid __weak functions here, as they tend
> >> to be hard to follow when trying to understand the code.
> >
> > That's interesting. I would have said exactly the opposite -- I think the
> > extra Kconfiggery is harder to follow than weak/strong functions
> >
> > But consistency is better than my personal opinion. Is there a consensus
> > that we should use the Kconfig strategy instead of __weak?
>
> I too find weak/strong functions easier to follow than "Kconfiggery" (nice term
> invention there).
I don't think there is a universal consensus, but the majority of
maintainers seems to avoid them for the same reasons that I think
__weak is problematic.
We have some uses of __weak in the core kernel, but there is
basically none in drivers outside of PCI, and the most common
uses are all providing an empty __weak function that can be
overridden with a function that actually does something, unlike
the code above.
My pragmatic approach so far has been to advocate __weak for
drivers/pci patches but discourage it elsewhere when I review
patches, in order to maintain consistency. I also think it
would be nice to change the way that PCI handles architecture
specific overrides in the process of unifying the host bridge
handling.
I wouldn't use Kconfig symbols in most cases though. My preferred
choice would be to turn a lot of the __weak symbols into function
pointers within a per-hostbridge structure. As an example, we could
replace pcibios_add_device() with a pointer in pci_host_bridge->ops
that gets set by all the architectures and host drivers that currently
override it, and replace the one caller with
if (pci_host_bridge->ops->add_device)
pci_host_bridge->ops->add_device(dev);
Arnd
next prev parent reply other threads:[~2014-11-21 12:24 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 16:04 [PATCH 0/6] PCI: MMCONFIG clean up Tomasz Nowicki
2014-11-19 16:04 ` Tomasz Nowicki
2014-11-19 16:04 ` [PATCH 1/6] x86, acpi, pci: Reorder logic of pci_mmconfig_insert() function Tomasz Nowicki
2014-11-19 16:04 ` Tomasz Nowicki
2014-11-19 16:04 ` Tomasz Nowicki
2014-11-19 16:04 ` [PATCH 2/6] x86, acpi, pci: Move arch-agnostic MMCFG code out of arch/x86/ directory Tomasz Nowicki
2014-11-19 16:04 ` Tomasz Nowicki
2014-12-10 23:35 ` Bjorn Helgaas
2014-12-10 23:35 ` Bjorn Helgaas
2014-12-10 23:55 ` Bjorn Helgaas
2014-12-10 23:55 ` Bjorn Helgaas
2014-12-12 14:55 ` [Linaro-acpi] " Arnd Bergmann
2014-12-12 14:55 ` Arnd Bergmann
2014-11-19 16:04 ` [PATCH 3/6] x86, acpi, pci: Move PCI config space accessors Tomasz Nowicki
2014-11-19 16:04 ` Tomasz Nowicki
2014-12-10 23:17 ` Bjorn Helgaas
2014-12-10 23:17 ` Bjorn Helgaas
2015-02-03 9:30 ` Tomasz Nowicki
2015-02-03 9:30 ` Tomasz Nowicki
2015-02-17 13:03 ` Tomasz Nowicki
2015-02-17 13:03 ` Tomasz Nowicki
2015-02-18 18:27 ` Bjorn Helgaas
2015-02-18 18:27 ` Bjorn Helgaas
2015-02-18 19:02 ` Rob Herring
2015-02-18 19:02 ` Rob Herring
2014-11-19 16:04 ` [PATCH 4/6] x86, acpi, pci: mmconfig_{32,64}.c code refactoring - remove code duplication Tomasz Nowicki
2014-11-19 16:04 ` [PATCH 4/6] x86, acpi, pci: mmconfig_{32, 64}.c " Tomasz Nowicki
2014-11-19 16:04 ` [PATCH 5/6] x86, acpi, pci: mmconfig_64.c becomes default implementation for arch agnostic low-level direct PCI config space accessors via MMCONFIG Tomasz Nowicki
2014-11-19 16:04 ` Tomasz Nowicki
2014-11-19 16:04 ` [PATCH 6/6] pci, acpi: Share ACPI PCI config space accessors Tomasz Nowicki
2014-11-19 16:04 ` Tomasz Nowicki
2014-11-19 16:19 ` Arnd Bergmann
2014-11-19 16:19 ` Arnd Bergmann
2014-11-19 16:24 ` Tomasz Nowicki
2014-11-19 16:24 ` Tomasz Nowicki
2014-11-20 22:26 ` Bjorn Helgaas
2014-11-20 22:26 ` Bjorn Helgaas
2014-11-21 4:00 ` Myron Stowe
2014-11-21 4:00 ` Myron Stowe
2014-11-21 12:24 ` Arnd Bergmann [this message]
2014-11-21 12:24 ` Arnd Bergmann
2014-11-21 18:08 ` Bjorn Helgaas
2014-11-21 18:08 ` Bjorn Helgaas
2014-11-24 10:41 ` Arnd Bergmann
2014-11-24 10:41 ` Arnd Bergmann
2014-12-08 7:13 ` Tomasz Nowicki
2014-12-08 7:13 ` Tomasz Nowicki
2014-12-09 21:50 ` Bjorn Helgaas
2014-12-09 21:50 ` Bjorn Helgaas
2014-12-10 6:16 ` Tomasz Nowicki
2014-12-10 6:16 ` Tomasz Nowicki
2015-02-02 20:42 ` [PATCH 0/6] PCI: MMCONFIG clean up Bjorn Helgaas
2015-02-02 20:42 ` Bjorn Helgaas
2015-02-03 7:42 ` Tomasz Nowicki
2015-02-03 7:42 ` Tomasz Nowicki
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=3957412.IooRKpIXjW@wuerfel \
--to=arnd@arndb.de \
--cc=Liviu.Dudau@arm.com \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=hanjun.guo@linaro.org \
--cc=hpa@zytor.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mingo@redhat.com \
--cc=myron.stowe@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=tomasz.nowicki@linaro.org \
--cc=wangyijing@huawei.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.