[PATCH] toshiba: Use ioremap_cached

[PATCH] toshiba: Use ioremap_cached

[Alan Cox]

The switch of ioremap to default to uncached doesn't break this driver
but it does needlessly slow it down as BIOS space is cachable and this
driver is quite happy scanning cached ROM space.

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.25-mm1/drivers/char/toshiba.c linux-2.6.25-mm1/drivers/char/toshiba.c
--- linux.vanilla-2.6.25-mm1/drivers/char/toshiba.c	2008-04-28 11:36:48.000000000 +0100
+++ linux-2.6.25-mm1/drivers/char/toshiba.c	2008-04-28 11:51:54.000000000 +0100
@@ -426,7 +426,7 @@
 	int i,major,minor,day,year,month,flag;
 	unsigned char signature[7] = { 0x54,0x4f,0x53,0x48,0x49,0x42,0x41 };
 	SMMRegisters regs;
-	void __iomem *bios = ioremap(0xf0000, 0x10000);
+	void __iomem *bios = ioremap_cache(0xf0000, 0x10000);
 
 	if (!bios)
 		return -ENOMEM;

Re: [PATCH] toshiba: Use ioremap_cached

[Ingo Molnar]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> The switch of ioremap to default to uncached doesn't break this driver
> but it does needlessly slow it down as BIOS space is cachable and this
> driver is quite happy scanning cached ROM space.
> 
> Signed-off-by: Alan Cox <alan@redhat.com>

Acked-by: Ingo Molnar <mingo@elte.hu>

i suspect this shouldnt go via x86.git but i've queued it up to track 
it. Is there an active maintainer for this file?

	Ingo

Re: [PATCH] toshiba: Use ioremap_cached

[Andrew Morton]

On Tue, 29 Apr 2008 16:15:59 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > The switch of ioremap to default to uncached doesn't break this driver
> > but it does needlessly slow it down as BIOS space is cachable and this
> > driver is quite happy scanning cached ROM space.
> > 
> > Signed-off-by: Alan Cox <alan@redhat.com>
> 
> Acked-by: Ingo Molnar <mingo@elte.hu>
> 
> i suspect this shouldnt go via x86.git but i've queued it up to track 
> it.

Please don't "queue things up to track them".  Just queue them up to merge
them, or don't queue them at all.

Because if you queue it up then I will not.  If you later for some reason
unqueue it then volia, it is lost.  We should aim to avoid having multiple
copies of a patch sitting around the place.

I shall not merge this patch - it is yours.

> Is there an active maintainer for this file?

drivers/char/*?  Very rarely maintained.  git-whatchanged tells the story
on this one: no.

Re: [PATCH] toshiba: Use ioremap_cached

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > Acked-by: Ingo Molnar <mingo@elte.hu>
> > 
> > i suspect this shouldnt go via x86.git but i've queued it up to 
> > track it.
> 
> Please don't "queue things up to track them".  Just queue them up to 
> merge them, or don't queue them at all.
> 
> Because if you queue it up then I will not.  If you later for some 
> reason unqueue it then volia, it is lost.  We should aim to avoid 
> having multiple copies of a patch sitting around the place.

but ... i dont just unqueue 'for some reason and then volia'. If we did 
that we'd be losing patches left and right. Every patch we unqueue 
happens in a very predictable protocol that should avoid patches getting 
lost.

( basically we only remove any patch when they are broken but even then
  there's a clear notification. Even a NAK or other fatal review 
  feedback does not actually remove a patch in the typical case when the 
  patch otherwise has practical use, and update is hoped for and the 
  patch does not break things - it just freezes the patch at the "must 
  not go upstream yet" end of the queue. )

if we lose any patches then let us know so we can improve the protocol.

> I shall not merge this patch - it is yours.
> 
> > Is there an active maintainer for this file?
> 
> drivers/char/*?  Very rarely maintained.  git-whatchanged tells the 
> story on this one: no.

ok, we'll push it upstream via x86.git after some test period.

	Ingo

Re: [PATCH] toshiba: Use ioremap_cached

[Andrew Morton]

On Tue, 29 Apr 2008 17:23:12 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > > Acked-by: Ingo Molnar <mingo@elte.hu>
> > > 
> > > i suspect this shouldnt go via x86.git but i've queued it up to 
> > > track it.
> > 
> > Please don't "queue things up to track them".  Just queue them up to 
> > merge them, or don't queue them at all.
> > 
> > Because if you queue it up then I will not.  If you later for some 
> > reason unqueue it then volia, it is lost.  We should aim to avoid 
> > having multiple copies of a patch sitting around the place.
> 
> but ... i dont just unqueue 'for some reason and then volia'. If we did 
> that we'd be losing patches left and right. Every patch we unqueue 
> happens in a very predictable protocol that should avoid patches getting 
> lost.
> 
> ( basically we only remove any patch when they are broken but even then
>   there's a clear notification. Even a NAK or other fatal review 
>   feedback does not actually remove a patch in the typical case when the 
>   patch otherwise has practical use, and update is hoped for and the 
>   patch does not break things - it just freezes the patch at the "must 
>   not go upstream yet" end of the queue. )
> 
> if we lose any patches then let us know so we can improve the protocol.

OK, in that case please don't say "i've queued it up to track it"!

Stick to the unambiguous, non-akpm-scary "applied" :)