Re: [PATCH] Change pci_raw_ops to pci_raw_read/write

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/