Re: [PATCH v3] fusion: remove dead MTRR code

From: Luis R. Rodriguez
Date: Fri May 29 2015 - 16:23:58 EST


On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
> <mcgrof@xxxxxxxxxxxxxxxx> wrote:
>> From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx>
>>
>> If and when this gets enabled the driver could should split
>> up IO memory space properly and that is quite a bit of work.
>> Just remove the uncommented dead MTRR code then.
>>
>> There are a few motivations for this:
>>
>> a) Take advantage of PAT when available
>>
>> b) Help bury MTRR code away, MTRR is architecture specific and on
>> x86 its replaced by PAT
>>
>> c) Help with the goal of eventually using _PAGE_CACHE_UC over
>> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
>> de33c442e titled "x86 PAT: fix performance drop for glx,
>> use UC minus for ioremap(), ioremap_nocache() and
>> pci_mmap_page_range()")
>
> Hey folks, who's tree should this go through if agreeable?

OK its been over 1 month without any replies on this patch which just
removes commented out code.

All the maintainers below bounce and the only e-mail not bouncing is
for Sreekanth Reddy <sreekanth.reddy@xxxxxxxxxxxxx>, he hasn't been
seen active on linux-next since Jan 12 2015 when he did a driver bump
for mpt2sas to 20.100.00.00.

What's going on folks? And can this patch go in?

diff --git a/MAINTAINERS b/MAINTAINERS
index aca2886..73dbc02 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6205,10 +6205,7 @@ S: Maintained
F: arch/arm/mach-lpc32xx/

LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
-M: Nagalakshmi Nandigama <nagalakshmi.nandigama@xxxxxxxxxxxxx>
-M: Praveen Krishnamoorthy <praveen.krishnamoorthy@xxxxxxxxxxxxx>
M: Sreekanth Reddy <sreekanth.reddy@xxxxxxxxxxxxx>
-M: Abhijit Mahajan <abhijit.mahajan@xxxxxxxxxxxxx>
L: MPT-FusionLinux.pdl@xxxxxxxxxxxxx
L: linux-scsi@xxxxxxxxxxxxxxx
W: http://www.lsilogic.com/support
--
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/