summaryrefslogtreecommitdiffstats
path: root/drivers/net/wimax/i2400m/i2400m.h
diff options
context:
space:
mode:
authorInaky Perez-Gonzalez <inaky@linux.intel.com>2009-09-16 18:23:27 -0700
committerInaky Perez-Gonzalez <inaky@linux.intel.com>2009-10-19 15:56:08 +0900
commit0856ccf29dfbaf957e4be80dd3eb88d97810b633 (patch)
treea33cf96b010ce3814747b67eb60743554af2070f /drivers/net/wimax/i2400m/i2400m.h
parentc2315b4ea9ac9c3f8caf03c3511d86fabe4a5fcd (diff)
wimax/i2400m: introduce i2400m->bus_setup/release
The SDIO subdriver of the i2400m requires certain steps to be done before we do any acces to the device, even for doing firmware upload. This lead to a few ugly hacks, which basically involve doing those steps in probe() before calling i2400m_setup() and undoing them in disconnect() after claling i2400m_release(); but then, much of those steps have to be repeated when resetting the device, suspending, etc (in upcoming pre/post reset support). Thus, a new pair of optional, bus-specific calls i2400m->bus_{setup/release} are introduced. These are used to setup basic infrastructure needed to load firmware onto the device. This commit also updates the SDIO subdriver to use said calls. 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.h27
1 files changed, 27 insertions, 0 deletions
diff --git a/drivers/net/wimax/i2400m/i2400m.h b/drivers/net/wimax/i2400m/i2400m.h
index fbc156db5bf..407d0972f2f 100644
--- a/drivers/net/wimax/i2400m/i2400m.h
+++ b/drivers/net/wimax/i2400m/i2400m.h
@@ -123,6 +123,7 @@
*
* bus_probe()
* i2400m_setup()
+ * i2400m->bus_setup()
* boot rom initialization / read mac addr
* network / WiMAX stacks registration
* i2400m_dev_start()
@@ -137,6 +138,7 @@
* i2400m_dev_shutdown()
* i2400m->bus_dev_stop()
* network / WiMAX stack unregistration
+ * i2400m->bus_release()
*
* At this point, control and data communications are possible.
*
@@ -214,12 +216,35 @@ struct i2400m_barker_db;
* Members marked with [fill] must be filled out/initialized before
* calling i2400m_setup().
*
+ * Note the @bus_setup/@bus_release, @bus_dev_start/@bus_dev_release
+ * call pairs are very much doing almost the same, and depending on
+ * the underlying bus, some stuff has to be put in one or the
+ * other. The idea of setup/release is that they setup the minimal
+ * amount needed for loading firmware, where us dev_start/stop setup
+ * the rest needed to do full data/control traffic.
+ *
* @bus_tx_block_size: [fill] SDIO imposes a 256 block size, USB 16,
* so we have a tx_blk_size variable that the bus layer sets to
* tell the engine how much of that we need.
*
* @bus_pl_size_max: [fill] Maximum payload size.
*
+ * @bus_setup: [optional fill] Function called by the bus-generic code
+ * [i2400m_setup()] to setup the basic bus-specific communications
+ * to the the device needed to load firmware. See LIFE CYCLE above.
+ *
+ * NOTE: Doesn't need to upload the firmware, as that is taken
+ * care of by the bus-generic code.
+ *
+ * @bus_release: [optional fill] Function called by the bus-generic
+ * code [i2400m_release()] to shutdown the basic bus-specific
+ * communications to the the device needed to load firmware. See
+ * LIFE CYCLE above.
+ *
+ * This function does not need to reset the device, just tear down
+ * all the host resources created to handle communication with
+ * the device.
+ *
* @bus_dev_start: [fill] Function called by the bus-generic code
* [i2400m_dev_start()] to setup the bus-specific communications
* to the the device. See LIFE CYCLE above.
@@ -490,8 +515,10 @@ struct i2400m {
size_t bus_pl_size_max;
unsigned bus_bm_retries;
+ int (*bus_setup)(struct i2400m *);
int (*bus_dev_start)(struct i2400m *);
void (*bus_dev_stop)(struct i2400m *);
+ void (*bus_release)(struct i2400m *);
void (*bus_tx_kick)(struct i2400m *);
int (*bus_reset)(struct i2400m *, enum i2400m_reset_type);
ssize_t (*bus_bm_cmd_send)(struct i2400m *,