linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: bhelgaas@google.com, x86@kernel.org, linux-pci@vger.kernel.org,
	eranian@google.com, Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 3/4] x86, pci: Add interface to force mmconfig
Date: Tue, 14 Mar 2017 14:55:30 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1703141407090.3619@nanos> (raw)
In-Reply-To: <20170302232104.10136-3-andi@firstfloor.org>

On Thu, 2 Mar 2017, Andi Kleen wrote:
> +struct pci_ops pci_mmconfig_ops = {
> +	.read = pci_mmconfig_read,
> +	.write = pci_mmconfig_write,
> +};
> +
> +/* Force all config accesses to go through mmconfig. */
> +int pci_bus_force_mmconfig(struct pci_bus *bus)
> +{
> +	if (!raw_pci_ext_ops)
> +		return -1;

We have error defines. That aside, the weak version of this returns 0,
i.e. success, but here you return fail. Consistency is overrated, right?

> +	bus->ops = &pci_mmconfig_ops;

What guarantees that raw_pci_ext_ops == pci_mmcfg? Nothing as far as I can
tell. So that function name is nonsensical. It does not force anything.

And the way how this function is used is a horrible hack. It's called from
a random driver at some random point in time.

The proper solution is to identify the bus at the point where the bus is
discovered and switch it to mmconfig if possible.

Thanks,

	tglx

  reply	other threads:[~2017-03-14 13:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-02 23:21 [PATCH 1/4] pci: Allow lockless access path to PCI mmconfig Andi Kleen
2017-03-02 23:21 ` [PATCH 2/4] pci: Add generic pci_bus_force_mmconfig interface Andi Kleen
2017-03-14 17:34   ` H. Peter Anvin
2017-03-02 23:21 ` [PATCH 3/4] x86, pci: Add interface to force mmconfig Andi Kleen
2017-03-14 13:55   ` Thomas Gleixner [this message]
2017-03-14 15:41     ` Andi Kleen
2017-03-14 16:40       ` Thomas Gleixner
2017-03-14 17:02         ` Andi Kleen
2017-03-14 17:56           ` Thomas Gleixner
2017-03-14 19:47             ` Bjorn Helgaas
2017-03-15  2:24               ` Andi Kleen
2017-03-15  2:55                 ` Bjorn Helgaas
2017-03-15 10:00                   ` Thomas Gleixner
2017-03-15 14:09                     ` Bjorn Helgaas
2017-03-16  0:02                     ` Andi Kleen
2017-03-16 22:45                       ` Thomas Gleixner
2017-03-02 23:21 ` [PATCH 4/4] perf/x86/intel/uncore: Enable forced mmconfig for Intel uncore Andi Kleen
2017-03-14 13:06 ` [PATCH 1/4] pci: Allow lockless access path to PCI mmconfig Thomas Gleixner
2017-03-14 17:28 ` H. Peter Anvin

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=alpine.DEB.2.20.1703141407090.3619@nanos \
    --to=tglx@linutronix.de \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=bhelgaas@google.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=peterz@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).