From: Robert Richter <rric@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>,
Borislav Petkov <bp@alien8.de>,
Daniel J Blueman <daniel@numascale.com>,
Andreas Herrmann <herrmann.der.user@googlemail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Borislav Petkov <bp@suse.de>,
Myron Stowe <myron.stowe@redhat.com>
Subject: Re: [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h
Date: Fri, 23 May 2014 17:05:18 +0200 [thread overview]
Message-ID: <20140523150518.GW27560@rric.localhost> (raw)
In-Reply-To: <CAErSpo5t+u+AYS5m6wo+AG7uXEkseUcmK9d-FF+SwpkcEWnkqA@mail.gmail.com>
On 23.05.14 07:01:41, Bjorn Helgaas wrote:
> [I guess I've been using the wrong term here. I think "ECS" just
> refers to the extended config space itself, and I should have been
> saying "IO ECS" or "EnableCf8ExtCfg".]
>
> My understanding was that if we don't enable IO ECS and we don't have
> MCFG, we will not be able to access extended config space. The system
> can certainly boot without extended config space, but some drivers may
> not work correctly, so it would be a regression from the user point of
> view.
No, I got you right. If we disable IO ECS there is no fallback if MCFG
fails... and this may cause a regression then.
I might be completely wrong here, but as I remember IO ECS only
affects access to cpu devices (bus 0, slot 0x18-0x1f). Thus, esp. PCIe
extended config space access works since a different host controller
handles this. So only cpu devices would see a regression and thus cpu
bringup code. I don't think ECS (either MCFG or IO ECS) is needed
anymore for cpu bringup (this is true for IBS, but I don't know of
other cpu features requiring ECS, though family 16h might introduced
new ones).
IMHO device drivers are not affected and wont get broken.
-Robert
next prev parent reply other threads:[~2014-05-23 15:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-08 16:44 [PATCH V4 0/4] x86/pci Fix numa_node info for AMD hostbridge and misc clean up suravee.suthikulpanit
2014-05-08 16:44 ` [PATCH V4 1/4] x86/PCI: Fix PCI root numa_node info on AMD family15h suravee.suthikulpanit
2014-05-08 16:44 ` [PATCH V4 2/4] x86/PCI: Clean up and mark early_root_info_init as deprecated suravee.suthikulpanit
2014-05-08 16:44 ` [PATCH V4 3/4] ACPI/PCI: Warn if we have to "guess" host bridge node information suravee.suthikulpanit
2014-05-08 16:44 ` [PATCH V4 4/4] X86/PCI: Remove unnecessary 'quirk_amd_nb_node' suravee.suthikulpanit
2014-05-14 5:54 ` [PATCH V4 0/4] x86/pci Fix numa_node info for AMD hostbridge and misc clean up Suravee Suthikulpanit
2014-05-14 13:11 ` Bjorn Helgaas
2014-05-21 23:17 ` [PATCH V5 " Bjorn Helgaas
2014-05-21 23:18 ` [PATCH V5 1/4] x86/PCI: Warn if we have to "guess" host bridge node information Bjorn Helgaas
2014-05-21 23:18 ` [PATCH V5 2/4] x86/PCI: Work around AMD Fam15h BIOSes that fail to provide _PXM Bjorn Helgaas
2014-05-21 23:18 ` [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h Bjorn Helgaas
2014-05-21 23:38 ` Borislav Petkov
2014-05-22 17:56 ` Bjorn Helgaas
2014-05-22 19:17 ` Borislav Petkov
2014-05-22 20:20 ` Bjorn Helgaas
2014-05-22 21:00 ` Borislav Petkov
2014-05-22 23:39 ` Suravee Suthikulanit
2014-05-23 2:54 ` Bjorn Helgaas
2014-05-23 11:56 ` Robert Richter
2014-05-23 13:01 ` Bjorn Helgaas
2014-05-23 15:05 ` Robert Richter [this message]
2014-05-23 21:36 ` Suravee Suthikulanit
2014-05-24 0:31 ` Suravee Suthikulanit
2014-05-28 16:02 ` Bjorn Helgaas
2014-05-21 23:18 ` [PATCH V5 4/4] x86/PCI: Clean up and mark early_root_info_init() as deprecated Bjorn Helgaas
2014-05-23 0:43 ` [PATCH V5 0/4] x86/pci Fix numa_node info for AMD hostbridge and misc clean up Suravee Suthikulanit
2014-05-23 0:49 ` Suravee Suthikulanit
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=20140523150518.GW27560@rric.localhost \
--to=rric@kernel.org \
--cc=Aravind.Gopalakrishnan@amd.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=daniel@numascale.com \
--cc=herrmann.der.user@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=myron.stowe@redhat.com \
--cc=suravee.suthikulpanit@amd.com \
/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.