Hi Geert,
I haven't seen that weird behaviour in quite some time - we discussed
changing the arch_initcall to some later priority at that time but I
never got around to trying that. No change to mappings in head.S
either as far as I could see.
Was there any rearrangement of MM init relative to arch init since?
Cheers,
Michael
On Tue, Apr 10, 2018 at 12:54 AM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
Hi Finn,
On Sun, Apr 1, 2018 at 3:41 AM, Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> wrote:
For reasons I don't understand, calling ioremap() then iounmap() on
the SWIM MMIO region causes a hang on 68030 (but not on 68040).
Michael Schmitz also notices strange things with ioremap() on '030.
There's no need to call ioremap() for the SWIM address range, as it lies
within the usual IO device region at 0x5000 0000, which is already mapped.
by head.S, right?
--- a/drivers/block/swim.c
+++ b/drivers/block/swim.c
@@ -911,7 +911,7 @@ static int swim_probe(struct platform_device *dev)
goto out;
}
- swim_base = ioremap(res->start, resource_size(res));
+ swim_base = (struct swim __iomem *)res->start;
I guess you need a __force to please sparse?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
