From b9ee95010bee6c0e17d18bc9d9c0cfab6e8cb73a Mon Sep 17 00:00:00 2001 From: Inaky Perez-Gonzalez Date: Wed, 7 Oct 2009 12:34:13 +0900 Subject: wimax/i2400m: fix deadlock: don't do BUS reset under i2400m->init_mutex Since the addition of the pre/post reset handlers, it became clear that we cannot do a I2400M-RT-BUS type reset while holding the init_mutex, as in the case of USB, it will deadlock when trying to call i2400m_pre_reset(). Thus, the following changes: - clarify the fact that calling bus_reset() w/ I2400M_RT_BUS while holding init_mutex is a no-no. - i2400m_dev_reset_handle() will do a BUS reset to recover a gone device after unlocking init_mutex. - in the USB reset implementation, when cold and warm reset fails, fallback to QUEUING a usb reset, not executing a USB reset, so it happens from another context and does not deadlock. Signed-off-by: Inaky Perez-Gonzalez --- drivers/net/wimax/i2400m/i2400m.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/net/wimax/i2400m/i2400m.h') diff --git a/drivers/net/wimax/i2400m/i2400m.h b/drivers/net/wimax/i2400m/i2400m.h index 8fc8a0ca512..f5ed7d5cee4 100644 --- a/drivers/net/wimax/i2400m/i2400m.h +++ b/drivers/net/wimax/i2400m/i2400m.h @@ -281,6 +281,9 @@ struct i2400m_barker_db; * process, so it cannot rely on common infrastructure being laid * out. * + * IMPORTANT: don't call reset on RT_BUS with i2400m->init_mutex + * held, as the .pre/.post reset handlers will deadlock. + * * @bus_bm_retries: [fill] How many times shall a firmware upload / * device initialization be retried? Different models of the same * device might need different values, hence it is set by the -- cgit v1.2.3