Messages in this thread | | | Date | Mon, 19 Oct 2009 10:16:06 +0100 | From | "Jan Beulich" <> | Subject | Re: [RFC Patch] use MTRR for write combining if PAT is not available |
| |
>>> Thomas Schlichter <thomas.schlichter@web.de> 17.10.09 21:48 >>> >Patches 0001-0003 introduce functionality/changes to the MTRR and sysfs >subsystems. Patch 0004 is the main patch which sets up the MTRR entries when >pci memory regions are mmapped. The Patches 0005-0006 also change ioremap() >and set_mempry_wc() to set up MTRR entries. These two are completely optional, >especially and there is currently no way to automatically remove MTRR entries >set up with them. > >What do you think about these patches?
Functionality-wise this looks fine to me; whether the core sysfs changes are acceptable I can't judge, though.
However, I would recommend folding the last two arguments of mtrr_add_unaligned(), i.e. use mtrr_usage != NULL as the increment argument passed to mtrr_add().
And patches 5 and 6 would apparently not build right now, as they're failing to pass the new 5th argument to mtrr_add_unaligned().
Also, why do you add x86-specific code to drivers/pci-sysfs.c when the function called there (pci_mmap_page_range()) already is arch-specific? Moving your addition there would also allow covering the related (legacy?) procfs based functionality... pci_release() could also become arch-specific, with a fall-back definition to NULL.
Additionally, I would suggest making those code portions depend on CONFIG_X86_MTRR rather than CONFIG_X86, so that you don't needlessly (try to) allocate the mtrr_usage vector.
Jan
| |