summaryrefslogtreecommitdiffstats
path: root/drivers/net/wimax/i2400m/i2400m.h
diff options
context:
space:
mode:
authorInaky Perez-Gonzalez <inaky@linux.intel.com>2009-09-17 02:53:57 +0200
committerInaky Perez-Gonzalez <inaky@linux.intel.com>2009-10-19 08:56:06 +0200
commit8f90f3ee83dc54e182d6a7548727cbae4b523e6e (patch)
tree8a81fd0076562a5c6e30a652c63fa25343783dc6 /drivers/net/wimax/i2400m/i2400m.h
parentwimax/i2400m: on device stop, clean up pending wake & TX work (diff)
downloadlinux-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.h30
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 *);