In fact, using msleep() here triggers scheduling when the kernel has been built with CONFIG_PREEMPT, which in turn causes the kernel to complain about scheduling when being atomic. The delay itself is basically a hack to allow the rb564 daughter board (FIXME: right?) to be detected correctly. Maybe there is some real fix for this issue, but sadly I can't test as I don't have any hardware requiring this delay. Signed-off-by: Phil Sutter <n0-1@xxxxxxxxxxx> --- arch/mips/pci/ops-rc32434.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/mips/pci/ops-rc32434.c b/arch/mips/pci/ops-rc32434.c index d1f8fa2..0999e91 100644 --- a/arch/mips/pci/ops-rc32434.c +++ b/arch/mips/pci/ops-rc32434.c @@ -118,7 +118,7 @@ retry: if (delay > 4) return 0; delay *= 2; - msleep(delay); + mdelay(delay); goto retry; } } -- 1.5.6.4
