On Wed, 15 Mar 2017, Andi Kleen wrote:
> > pci_root_ops is what is finally handed in to pci_scan_root_bus() as ops
> > argument for any bus segment no matter which type it is.
>
> mmconfig is only initialized after PCI is initialized (an ordering
> problem with ACPI).
Wrong. It can be initialized
> pci_root_ops is what is finally handed in to pci_scan_root_bus() as ops
> argument for any bus segment no matter which type it is.
mmconfig is only initialized after PCI is initialized
(an ordering problem with ACPI). So it would require
updating existing busses with likely interesting race
cond
On Wed, Mar 15, 2017 at 11:00:22AM +0100, Thomas Gleixner wrote:
> On Tue, 14 Mar 2017, Bjorn Helgaas wrote:
> > On Tue, Mar 14, 2017 at 07:24:14PM -0700, Andi Kleen wrote:
> > > > I agree that it should be fairly safe to do ECAM/MMCONFIG without
> > > > locking. Can we handle the decision part by
On Tue, 14 Mar 2017, Bjorn Helgaas wrote:
> On Tue, Mar 14, 2017 at 07:24:14PM -0700, Andi Kleen wrote:
> > > I agree that it should be fairly safe to do ECAM/MMCONFIG without
> > > locking. Can we handle the decision part by adding a "lockless" bit
> > > to struct pci_ops? Old ops don't mention
On Tue, Mar 14, 2017 at 07:24:14PM -0700, Andi Kleen wrote:
> > I agree that it should be fairly safe to do ECAM/MMCONFIG without
> > locking. Can we handle the decision part by adding a "lockless" bit
> > to struct pci_ops? Old ops don't mention that bit, so it will be
> > initialized to zero an
> I agree that it should be fairly safe to do ECAM/MMCONFIG without
> locking. Can we handle the decision part by adding a "lockless" bit
> to struct pci_ops? Old ops don't mention that bit, so it will be
> initialized to zero and we'll do locking as today. ECAM/MMCONFIG ops
> can set it and we
On Tue, Mar 14, 2017 at 06:56:26PM +0100, Thomas Gleixner wrote:
> On Tue, 14 Mar 2017, Andi Kleen wrote:
> > 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 the
On Tue, 14 Mar 2017, Andi Kleen wrote:
> 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.
>From the PCIe s
> > 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.
On Tue, 14 Mar 2017, Andi Kleen wrote:
> > 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 poss
> 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.
But how would you know that it is safe?
AFA
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_
From: Andi Kleen
This fills in the pci_bus_force_mmconfig interface that was
added earlier for x86 to allow drivers to optimize config
space accesses. The implementation is straight forward
and uses the existing mmconfig access functions, just forcing
mmconfig access.
Signed-off-by: Andi Kleen
13 matches
Mail list logo
