[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1392884759@web.de>
Date: Mon, 19 Oct 2009 16:47:10 +0200
From: Thomas Schlichter <thomas.schlichter@....de>
To: Jan Beulich <JBeulich@...ell.com>
Cc: Arjan van de Ven <arjan@...ux.intel.com>,
dri-devel@...ts.sourceforge.net,
Robert Hancock <hancockrwd@...il.com>,
Henrique de Moraes Holschuh <hmh@....eng.br>,
"H. Peter Anvin" <hpa@...or.com>, jbarnes@...tuousgeek.org,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Suresh Siddha <suresh.b.siddha@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Thomas Hellstrom <thellstrom@...are.com>,
Tejun Heo <tj@...nel.org>,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
x86@...nel.org, Yinghai Lu <yinghai@...nel.org>
Subject: Re: [RFC Patch] use MTRR for write combining if PAT is not available
Jan Beulich wrote:
> >>> Thomas Schlichter <thomas.schlichter@....de> 17.10.09 21:48 >>>
> >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.
OK, who can? Or shall I simply ask get_maintainer.pl again?
> 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().
Good idea, I will do so this evening...
> 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().
*Grml* you are of course right. But I am not sure if these both patches
are a goot idea at all.
> 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.
You are right, I should do that...
> 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.
Good idea, I will do so.
Thank you very much for your feedback, I'll hopefully come up with an
even better version tonight...
Kind regards,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists