On Mon, 7 Apr 2014, Stephen N Chivers wrote:
It looks like a toolchain problem, I added plenty of printks to the path leading to the first access to the chip and the fault went away.
If you can suppress the printk output (by setting console log level perhaps) and still avoid the crash, then I'd replace the printk with (a suitable) udelay. If that still avoids the crash, I'd say it's timing related. But I'd still compare the disassembly of the working driver code and that of the bad code. OTOH, if the crash only disappears when printk actually sends some I/O to the console then it could be that the hardware isn't configured properly. Of course, I'm only guessing here. Sorry I can't be of more help. -- -- 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
