lkml.org 
[lkml]   [2008]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Change pci_raw_ops to pci_raw_read/write

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > please check some updated patches in -mm that could be affected.
> > hope it could save you some time
> >
> > x86-validate-against-acpi-motherboard-resources.patch
> > x86-clear-pci_mmcfg_virt-when-mmcfg-get-rejected.patch
> > x86-mmconf-enable-mcfg-early.patch
> > x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron-v3.patch
>
> I have unhappy feelings here - the patches seem to be churning a bit
> and when I last sent them to Greg and Ingo they received no apparent
> response.

i actually carried them for a while and
validate-against-acpi-motherboard-resources.patch got a fair bit of test
time with positive results. So it has a clear ACK from me.

It's something that looks appealing:

| This path adds validation of the MMCONFIG table against the ACPI
| reserved motherboard resources. If the MMCONFIG table is found to be
| reserved in ACPI, we don't bother checking the E820 table. The PCI
| Express firmware spec apparently tells BIOS developers that
| reservation in ACPI is required and E820 reservation is optional, so
| checking against ACPI first makes sense. Many BIOSes don't reserve
| the MMCONFIG region in E820 even though it is perfectly functional,
| the existing check needlessly disables MMCONFIG in these cases.

anything that isolates Linux from BIOS messups should be music to our
ears.

i also think the mmconf-enable stuff for Barcelona stuff from Yinghai,
albeit not particularly pretty, is probably good too for similar
reasons. It makes the kernel boot with noacpi which is a good sign IMO.

I have testsystems that simply do not boot with ACPI turned off - and i
have a testsystem that locks up hard if it takes an NMI in certain ACPI
AML sequences ... Just Because.

So i'd ACK them just on general principle - earlier versions of the
patches were carried in x86.git and caused no particular problems.

but ... then we got complaints from you that stuff collides and that
such patches should be carried in your or Greg's tree, so we dropped
them. And there was another 100 KLOC of x86 code to worry about ;-)

So i'd suggest to send those patches upstream, they are system enablers
and they are at fundamental enough places to be apparent if they cause
any breakage i think.

Ingo


\
 
 \ /
  Last update: 2008-02-11 23:43    [W:0.171 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site