diff options
author | Inaky Perez-Gonzalez <inaky@linux.intel.com> | 2009-09-17 02:53:57 +0200 |
---|---|---|
committer | Inaky Perez-Gonzalez <inaky@linux.intel.com> | 2009-10-19 08:56:06 +0200 |
commit | 8f90f3ee83dc54e182d6a7548727cbae4b523e6e (patch) | |
tree | 8a81fd0076562a5c6e30a652c63fa25343783dc6 /drivers/net/wimax/i2400m/i2400m.h | |
parent | wimax/i2400m: on device stop, clean up pending wake & TX work (diff) | |
download | linux-8f90f3ee83dc54e182d6a7548727cbae4b523e6e.tar.xz linux-8f90f3ee83dc54e182d6a7548727cbae4b523e6e.zip |
wimax/i2400m: cleanup initialization/destruction flow
Currently the i2400m driver was starting in a weird way: registering a
network device, setting the device up and then registering a WiMAX
device.
This is an historic artifact, and was causing issues, a some early
reports the device sends were getting lost by issue of the wimax_dev
not being registered.
Fix said situation by doing the wimax device registration in
i2400m_setup() after network device registration and before starting
thed device.
As well, removed spurious setting of the state to UNINITIALIZED;
i2400m.dev_start() does that already.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Diffstat (limited to 'drivers/net/wimax/i2400m/i2400m.h')
-rw-r--r-- | drivers/net/wimax/i2400m/i2400m.h | 30 |
1 files changed, 21 insertions, 9 deletions
diff --git a/drivers/net/wimax/i2400m/i2400m.h b/drivers/net/wimax/i2400m/i2400m.h index 303eb78bce32..2b9c400810b5 100644 --- a/drivers/net/wimax/i2400m/i2400m.h +++ b/drivers/net/wimax/i2400m/i2400m.h @@ -117,16 +117,28 @@ * well as i2400m->wimax_dev.net_dev and call i2400m_setup(). The * i2400m driver will only register with the WiMAX and network stacks; * the only access done to the device is to read the MAC address so we - * can register a network device. This calls i2400m_dev_start() to - * load firmware, setup communication with the device and configure it - * for operation. + * can register a network device. * - * At this point, control and data communications are possible. + * The high-level call flow is: + * + * bus_probe() + * i2400m_setup() + * boot rom initialization / read mac addr + * network / WiMAX stacks registration + * i2400m_dev_start() + * i2400m->bus_dev_start() + * i2400m_dev_initialize() + * + * The reverse applies for a disconnect() call: * - * On disconnect/driver unload, the bus-specific disconnect function - * calls i2400m_release() to undo i2400m_setup(). i2400m_dev_stop() - * shuts the firmware down and releases resources uses to communicate - * with the device. + * bus_disconnect() + * i2400m_release() + * i2400m_dev_stop() + * i2400m_dev_shutdown() + * i2400m->bus_dev_stop() + * network / WiMAX stack unregistration + * + * At this point, control and data communications are possible. * * While the device is up, it might reset. The bus-specific driver has * to catch that situation and call i2400m_dev_reset_handle() to deal @@ -706,7 +718,7 @@ static inline int i2400m_debugfs_add(struct i2400m *i2400m) static inline void i2400m_debugfs_rm(struct i2400m *i2400m) {} #endif -/* Called by _dev_start()/_dev_stop() to initialize the device itself */ +/* Initialize/shutdown the device */ extern int i2400m_dev_initialize(struct i2400m *); extern void i2400m_dev_shutdown(struct i2400m *); |