toshiba: Use ioremap_cached
Subsystems (2)
PATCH 1/1 toshiba: Use ioremap_cached
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.
drivers/char/toshiba.c +1 -1
@@ -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 ;
Quoted 5 lines · 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 <[email protected]>
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
Quoted 7 lines · On Tue, 29 Apr 2008 16:15:59 +0200 Ingo Molnar <[email protected]> wrote:
Quoted 4 lines · 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.
Quoted 6 lines
Quoted 1 line
Signed-off-by Alan Cox <[email protected]>Acked-by Ingo Molnar <[email protected]>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.
Quoted 1 line
Is there an active maintainer for this file?
drivers/char/*? Very rarely maintained. git-whatchanged tells the story on this one: no.
Quoted 11 lines · Andrew Morton
Quoted 4 lines
Acked-by Ingo Molnar <[email protected]>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.
Quoted 6 lines
I shall not merge this patch - it is yours.
Quoted 1 line
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
Quoted 20 lines · On Tue, 29 Apr 2008 17:23:12 +0200 Ingo Molnar <[email protected]> wrote:
Quoted 11 lines · Andrew Morton
Quoted 4 lines
Acked-by Ingo Molnar <[email protected]>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.
Quoted 8 lines
( 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" :)