linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <andi@firstfloor.org>,
	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>
Subject: Re: [PATCH 3/4] x86, pci: Add interface to force mmconfig
Date: Tue, 14 Mar 2017 10:02:55 -0700	[thread overview]
Message-ID: <20170314170255.GH32070@tassilo.jf.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1703141713010.3619@nanos>

> > Or define some quirk table just for this purpose?
> 
> Nope. It's about identifying the bus.

PCI just has no good way to identify busses.

> 
> The bus which contains the uncore devices:
> 
>  The Uncore devices reside on CPUBUSNO(1), which is the PCI bus assigned
>  for the processor socket. The bus number is derived from the max bus range
>  setting and the processor socket number.

I have had bad experiences with hard coding topology like this. These
things tend to be very configurable by BIOS.

> 
> So there should be a way to detect that and it would be appreciated if you
> could talk to your hardware folks what's the programmatic way to figure it
> out. 

There's likely some hidden register somewhere. But then it would be

check model number
look for hidden register
configure these busses

and it will likely change often.

Frankly I fail to see how such a thing is better than just using
the device ID. Perhaps the driver is not the right place for it,
but the ID seems to be.

The other option is to simply make it unconditional. That would
be even simpler, but it is a bit more risky. Hmm, I suppose may
be worth trying to find out what Windows uses. If they get away
with MMCONFIG everywhere we should be too.

Or the third option would be to move the ops pointer into the 
PCI device, so it's a per device setting. If people are ok with that
I can look into it.

> Maybe there is information in ACPI as well.

I don't think ACPI has any concept of "internal SOC busses"

-Andi

  reply	other threads:[~2017-03-14 17:03 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
2017-03-14 15:41     ` Andi Kleen
2017-03-14 16:40       ` Thomas Gleixner
2017-03-14 17:02         ` Andi Kleen [this message]
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=20170314170255.GH32070@tassilo.jf.intel.com \
    --to=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=tglx@linutronix.de \
    --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).