diff options
author | Inaky Perez-Gonzalez <inaky@linux.intel.com> | 2009-09-16 18:23:27 -0700 |
---|---|---|
committer | Inaky Perez-Gonzalez <inaky@linux.intel.com> | 2009-10-19 15:56:08 +0900 |
commit | 0856ccf29dfbaf957e4be80dd3eb88d97810b633 (patch) | |
tree | a33cf96b010ce3814747b67eb60743554af2070f /drivers/net/wimax/i2400m/i2400m.h | |
parent | c2315b4ea9ac9c3f8caf03c3511d86fabe4a5fcd (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.h | 27 |
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 *, |