On Wed, 2015-04-29 at 09:01 -0700, Luis R. Rodriguez wrote: > On Mon, Apr 27, 2015 at 11:38 AM, Doug Ledford <[email protected]> wrote: > > On Mon, 2015-04-27 at 09:46 -0700, Luis R. Rodriguez wrote: > >> On Wed, Apr 22, 2015 at 12:26 PM, Luis R. Rodriguez > >> <[email protected]> wrote: > >> > From: "Luis R. Rodriguez" <[email protected]> > >> > > >> > We are burrying direct access to MTRR code support on > >> > x86 in order to take advantage of PAT. In the future we > >> > also want to make the default behaviour of ioremap_nocache() > >> > to use strong UC, use of mtrr_add() on those systems > >> > would make write-combining void. > >> > > >> > In order to help both enable us to later make strong > >> > UC default and in order to phase out direct MTRR access > >> > code port the driver over to arch_phys_wc_add() and > >> > annotate that the device driver requires systems to > >> > boot with PAT disabled, with the nopat kernel parameter. > >> > > >> > This is a worthy compromise given that the ipath device > >> > driver powers the old HTX bus cards that only work in > >> > AMD systems, while the newer IB/qib device driver > >> > powers all PCI-e cards. The ipath device driver is > >> > obsolete, hardware hard to find and because of this > >> > this its a reasonable compromise to make to require > >> > users of ipath to boot with nopat. > >> > >> Hey folks, I realize its being discussed whether or not to remove the > >> driver entirely from the kernel but in the meantime, is this a > >> reasonable compromise ? > > > > [ trimmed Cc: list to probably the only people that care ] > > > > I would think so. > > OK great, can this be merged then? I am waiting for this patch to help > move forward with deprecating MTRR upstream.
I'm generally OK with picking this up and merging it in. However, it relies on pat_enabled being an exported symbol, and that isn't the case. Are you submitting an additional patch via a different tree to make that symbol exported to modules? > > I think we might as well mark this driver as > > deprecated and put a tentative date on removal while we are at it. > > OK great, that can be done as a separate patch. > > > Mike, any specific input here? I would suggest mark it deprecated with > > a planned removal sometime in late 2015/early 2016. > > I will note that feature-removal file was removed from Linux so if we > want to deprecate something now we just do it. > > Luis > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Doug Ledford <[email protected]> GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
