summaryrefslogtreecommitdiff
path: root/drivers/net/wimax
AgeCommit message (Collapse)Author
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-08Merge branch 'for-next' into for-linusJiri Kosina
Conflicts: Documentation/filesystems/proc.txt arch/arm/mach-u300/include/mach/debug-macro.S drivers/net/qlge/qlge_ethtool.c drivers/net/qlge/qlge_main.c drivers/net/typhoon.c
2010-02-09tree-wide: Assorted spelling fixesDaniel Mack
In particular, several occurances of funny versions of 'success', 'unknown', 'therefore', 'acknowledge', 'argument', 'achieve', 'address', 'beginning', 'desirable', 'separate' and 'necessary' are fixed. Signed-off-by: Daniel Mack <daniel@caiaq.de> Cc: Joe Perches <joe@perches.com> Cc: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-01-28Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
2010-01-21wimax/i2400m: Add support for more i6x50 SKUsInaky Perez-Gonzalez
The Intel WiMax Wireless Link 6050 can show under more than one USB ID. Add support for all, introducing a generic flag (i2400mu->i6050) that denotes a 6x50 based device. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2010-01-07drivers/net/wimax/i2400m/driver.c: use %pM to show MAC addresshartleys
Use the %pM kernel extension to display the MAC address. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07drivers/net/wimax/i2400m/fw.c: use %pM to show MAC addresshartleys
Use the %pM kernel extension to display the MAC address. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-12-11USB: remove the auto_pm flagAlan Stern
This patch (as1302) removes the auto_pm flag from struct usb_device. The flag's only purpose was to distinguish between autosuspends and external suspends, but that information is now available in the pm_message_t argument passed to suspend methods. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-09Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (42 commits) tree-wide: fix misspelling of "definition" in comments reiserfs: fix misspelling of "journaled" doc: Fix a typo in slub.txt. inotify: remove superfluous return code check hdlc: spelling fix in find_pvc() comment doc: fix regulator docs cut-and-pasteism mtd: Fix comment in Kconfig doc: Fix IRQ chip docs tree-wide: fix assorted typos all over the place drivers/ata/libata-sff.c: comment spelling fixes fix typos/grammos in Documentation/edac.txt sysctl: add missing comments fs/debugfs/inode.c: fix comment typos sgivwfb: Make use of ARRAY_SIZE. sky2: fix sky2_link_down copy/paste comment error tree-wide: fix typos "couter" -> "counter" tree-wide: fix typos "offest" -> "offset" fix kerneldoc for set_irq_msi() spidev: fix double "of of" in comment comment typo fix: sybsystem -> subsystem ...
2009-12-04tree-wide: fix assorted typos all over the placeAndré Goddard Rosa
That is "success", "unknown", "through", "performance", "[re|un]mapping" , "access", "default", "reasonable", "[con]currently", "temperature" , "channel", "[un]used", "application", "example","hierarchy", "therefore" , "[over|under]flow", "contiguous", "threshold", "enough" and others. Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-11-06Merge branch 'linux-2.6.33.y' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax
2009-11-03wimax/i2400m: fix inverted value in i2400ms_bus_setup()Inaky Perez-Gonzalez
Fix inverted setting of 'retries'; when we are in the probe() path, we should retry to enable the function only once; otherwise until it times out. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: fix SDIO debugfs dentry nameInaky Perez-Gonzalez
The SDIO specific debugfs dentry was being misnamed "i2400m-usb" instead of "i2400m-sdio". Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: fix bad assignment of return value in i2400mu_tx_bulk_outInaky Perez-Gonzalez
The function was always setting the return value to the amount of bytes transferred, overwriting the error code in error paths. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: handle USB stallsInaky Perez-Gonzalez
When the device stalls, clear it and retry; if it keeps failing too often, reset the device. This specially happens when running on virtual machines; the real hardware doesn't seem to trip on stalls too much, except for a few reports in the mailing list (still to be confirmed this is the cause, although it seems likely. NOTE: it is not clear if the URB has to be resubmitted fully or start only at the offset of the first transaction sent. Can't find documentation to clarify one end or the other. Tests that just resubmit the whole URB seemed to work in my environment. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: don't retry SDIO enable in probe() pathsInaky Perez-Gonzalez
The iwmc3200 has a quirk where retrying SDIO enable during the probe() path causes bad interactions with the TOP function controller that causes a reset storm. The workaround is simply not to retry an SDIO enable in said path (and still do in the reset / reinitialization paths). The driver does so by checking i2400ms->debugfs_dentry to see if it has been initialized; if not, it is in the probe() path. Document said fact in i2400ms->debugfs_entry. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: correctly identify all iwmc3200-based SKUsInaky Perez-Gonzalez
Different paths of the i2400m SDIO driver need to take care of a few SKU-specific quirks. For the ones that are common to to all the iwmc3200 based devices, introduce i2400ms->iwmc3200 [set in i2400ms_probe()], so it doesn't have to check against the list of iwmc3200 SKU IDs on each quirk site. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: Fix USB timeout specifications (to ms from HZ)Inaky Perez-Gonzalez
The USB code was incorrectly specifiying timeouts to be in jiffies vs msecs. On top of that, lower it to 200ms, as 1s is really too long (doesn't allow the watchdog to trip a reset if the device timesout too often). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: fix device getting stuck in IDLE modeInaky Perez-Gonzalez
The i2400m, when conected, will negotiate with the WiMAX basestation to put the link in IDLE mode when it is not being used. Upon RX/TX traffic, the link has to be restablished and that might require some crypto handshakes and maybe a DHCP renew. This process might take up to 20 (!) seconds and in some cases we were seeing network watchdog warnings that weren't needed. So the network watchdog timeout is updated to be slightly above that 20s threshold. As well, the driver itself will double check if the device is stuck in IDLE mode -- if that happens, the device will be reset (in this case the queue is also woken up to remove bogus--once the device is reset--warnings). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: introduce i2400m_reset(), stopping TX and carrierInaky Perez-Gonzalez
Currently the i2400m driver was resetting by just calling i2400m->bus_reset(). However, this was missing stopping the TX queue and downing the carrier. This was causing, for the corner case of the driver reseting a device that refuses to go out of idle mode, that a few packets would be queued and more than one reset would go through, making the recovery a wee bit messy. To avoid introducing the same cleanup in all the bus-specific driver, introduced a i2400m_reset() function that takes care of house cleaning and then calling the bus-level reset implementation. The bulk of the changes in all files are just to rename the call from i2400m->bus_reset() to i2400m_reset(). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03wimax/i2400m: implement passive mode as a module optionInaky Perez-Gonzalez
Some versions of the user space Intel WiMAX daemon need to have full control over the device initialization sequence. By setting the module option i2400.passive_mode to 1, the driver defers all device configuration and initialization to user space. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19i2400m-sdio: select IWMC3200TOP in KconfigTomas Winkler
i2400m-sdio requires iwmc3200top for its operation Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-10-19wimax/i2400m: SDIO: fix oops on reset when TXing on uninitialized dataInaky Perez-Gonzalez
Currently the SDIO part of the TX resources were initialized/released with bus_dev_{start,stop}. The generic code's TX subsystem is destroyed afterwards, so there is a window from the bus-TX destruction to the generic-TX destruction where the generic-TX code might call into bus-TX to do transactions. The SDIO code cannot really cope with this (whereas in USB, how it is laid out, it correctly ignores it). In any case, it made no sense for the SDIO TX code to be in i2400m->bus_dev_start/stop(), so moved to i2400m->bus_setup/release(), which also takes care of the oops. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: make i2400m->bus_dev_{stop,start}() optionalInaky Perez-Gonzalez
In coming commits, the i2400m SDIO driver will not use i2400m->bus_dev_stop(). Thus changed to check before calling, as an empty stub has more overhead than a call to check if the function pointer is non-NULL. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: fix oops caused by race condition when exiting USB kthreadsInaky Perez-Gonzalez
Current i2400m USB code had to threads (one for processing RX, one for TX). When calling i2400m_{tx,rx}_release(), it would crash if the thread had exited already due to an error. So changed the code to have the thread fill in/out i2400mu->{tx,rx}_kthread under a spinlock; then the _release() function will call kthread_stop() only if {rx,tx}_kthread is still set. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: Let device's status reports change the device stateInaky Perez-Gonzalez
Currently __i2400m_dev_start was forcing, after uploading firmware and doing a few checks to WIMAX_ST_UNINITIALIZED. This can be overriding state changes that the device might have caused by sending reports; thus it makes more sense to remove it and let the device update the status on its own by sending reports. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: fix oops in TX when tearing down the deviceInaky Perez-Gonzalez
All the entry points into the TX module should check if the device has been torn down. Otherwise, when the device resets or shuts down, there are windows when a call to i2400m_tx*() will oops the system. For that, make i2400m_tx_release() set i2400m->tx_buf to NULL under the tx_lock. Then, any entry point [i2400m_tx(), _tx_msg_sent(), _tx_msg_get()] will check for i2400m->tx_buf to be NULL and exit gracefully. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: queue device's report until the driver is ready for themInaky Perez-Gonzalez
The i2400m might start sending reports to the driver before it is done setting up all the infrastructure needed for handling them. Currently we were just dropping them when the driver wasn't ready and that is bad in certain situations, as the sync between the driver's idea of the device's state and the device's state dissapears. This changes that by implementing a queue for handling reports. Incoming reports are appended to it and a workstruct is woken to process the list of queued reports. When the device is not yet ready to handle them, the workstruct is not woken, but at soon as the device becomes ready again, the queue is processed. As a consequence of this, i2400m_queue_work() is no longer used, and thus removed. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: move i2400m_init() out of i2400m.hInaky Perez-Gonzalez
Upcoming changes will have to add things to this function that expose more internals, which would mean more forward declarators. Frankly, it doesn't need to be an inline, so moved to driver.c, where the declarations will be taken from the header file. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: fix deadlock: don't do BUS reset under i2400m->init_mutexInaky Perez-Gonzalez
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 <inaky@linux.intel.com>
2009-10-19wimax/i2400m: when stopping the device, cancel any pending messageInaky Perez-Gonzalez
The stop procedure for the device must make sure that any task that is waiting on a message is properly cancelled. This was being taken care of only by the __i2400m_dev_reset_handle() path and the rest was working by chance because the waits have a timeout. Fixed by adding a proper cancellation in __i2400m_dev_stop(). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: change the bcf_len to exclude the extended header sizeCindy H Kao
The actual fw->size may not equal to the bcf size indicated in the bcf header if the extended bcf debug header is added in the tail. To reflect the actual fw size that will be downloaded to the device, it is now retrived from from the size field indicated in the bcf header. All of the headers (if there are extended headers) should indicate same value for the size field since only one set of firmware chunks is downloaded Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
2009-10-19wimax/i2400m: use JUMP cmd for last FW chunk indicationCindy H Kao
Both secure and non-secure boot must set the JUMP command in the bootmode header as the last FW chunk, so we change to use the JUMP command to decide if the FW chunk download is completed. Since we tend to use one single FW to support both secure and non-secure boot for most of the time, I2400M_BRH_SIGNED_JUMP is actually found even for non-secure boot. But in case the FW does come with I2400M_BRH_JUMP, we check for both of them in i2400m_dnload_bcf(). Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: fix race condition with tcpdump et alInaky Perez-Gonzalez
tcpdump and friends were not being able to decode packets sent via WiMAX; they had a zero ethernet type, even when the stack was properly sending them to the device with the right type. It happens that the driver was overwriting the (fake) ethernet header for creating the hardware header and that was bitting the cloning used by tcpdump (et al) to look into the packets. Use pkskb_expand_head() [method copied from the e1000 driver] to fix. Thanks to Herbert Xu and Andi Kleen for helping to diagnose and pointing to the right fix. Cc: Herbert Xu <gondor.apana.org.au> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: reduce verbosity of debug messages in boot modeInaky Perez-Gonzalez
Missed a debug message that was being constantly printed as a dev_err(); became annoying. Demote it to a debug message. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: Implement pre/post reset support in the USB driverInaky Perez-Gonzalez
The USB stack can callback a driver is about to be reset by an external entity and right after it, so the driver can save state and then restore it. This commit implements said support; it is implemented actually in the core, bus-generic driver [i2400m_{pre,post}_reset()] and used by the bus-specific drivers. This way the SDIO driver can also use it once said support is brought to the SDIO stack. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: do bootmode buffer management in i2400m_setup/release()Inaky Perez-Gonzalez
After the introduction of i2400m->bus_setup/release, there is no more race condition where the bootmode buffers are needed before i2400m_setup() is called. Before, the SDIO driver would setup RX before calling i2400m_setup() and thus need those buffers; now RX setup is done in i2400m->bus_setup(), which is called by i2400m_setup(). Thus, all the bootmode buffer management can now be done completely inside i2400m_setup()/i2400m_release(), removing complexity from the bus-specific drivers. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: introduce i2400m->bus_setup/releaseInaky Perez-Gonzalez
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>
2009-10-19wimax/i2400m: clarify and fix i2400m->{ready,updown}Inaky Perez-Gonzalez
The i2400m driver uses two different bits to distinguish how much the driver is up. i2400m->ready is used to denote that the infrastructure to communicate with the device is up and running. i2400m->updown is used to indicate if 'ready' and the device is up and running, ready to take control and data traffic. However, all this was pretty dirty and not clear, with many open spots where race conditions were present. This commit cleans up the situation by: - documenting the usage of both bits - setting them only in specific, well controlled places (i2400m_dev_start, i2400m_dev_stop) - ensuring the i2400m workqueue can't get in the middle of the setting by flushing it when i2400m->ready is set to zero. This allows the report hook not having to check again for the bit to be set [rx.c:i2400m_report_hook_work()]. - using i2400m->updown to determine if the device is up and running instead of the wimax state in i2400m_dev_reset_handle(). - not loosing missed messages sent by the hardware before i2400m->ready is set. In rx.c, whatever the device sends can be sent to user space over the message pipes as soon as the wimax device is registered, so don't wait for i2400m->ready to be set. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: cleanup initialization/destruction flowInaky Perez-Gonzalez
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>
2009-10-19wimax/i2400m: on device stop, clean up pending wake & TX workInaky Perez-Gonzalez
When the i2400m device needs to wake up an idle WiMAX connection, it schedules a workqueue job to do it. Currently, only when the network stack called the _stop() method this work struct was being cancelled. This has to be done every time the device is stopped. So add a call in i2400m_dev_stop() to take care of such cleanup, which is now wrapped in i2400m_net_wake_stop(). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: don't overwrite error codes when failing to load firmwareInaky Perez-Gonzalez
Make sure that i2400m_dev_bootstrap() doesn't overwrite the last known error code with -ENOENT; when a firmware fails to load, we want to know the cause and not a generic error code. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: implement .reset_resume in USB subdriverInaky Perez-Gonzalez
Current driver didn't implement the .reset_resume method. The i2400m normally always reset on a comeback from system standby/hibernation. This requires previously applied commits to cache the firmware image file. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: cache firmware on system suspendInaky Perez-Gonzalez
In preparation for a reset_resume implementation, have the firmware image be cached in memory when the system goes to suspend and released when out. This is needed in case the device resets during suspend; the driver can't load firmware until resume is completed or bad deadlocks happen. The modus operandi for this was copied from the Orinoco USB driver. The caching is done with a kobject to avoid race conditions when releasing it. The fw loader path is altered only to first check for a cached image before trying to load from disk. A Power Management event notifier is register to call i2400m_fw_cache() or i2400m_fw_uncache() which take care of the actual cache management. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: add reason argument to i2400m_dev_reset_handle()Inaky Perez-Gonzalez
In preparation for reset_resume support, in which the same code path is going to be used, add a diagnostic message to dev_reset_handle() that can be used to distinguish how the device got there. This uses the new payload argument added to i2400m_schedule_work() by the previous commit. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: clean up & add a payload argument to i2400m_schedule_work()Inaky Perez-Gonzalez
Forthcoming commits use having a payload argument added to i2400m_schedule_work(), which then becomes nearly identical to i2400m_queue_work(). This patch thus cleans up both's implementation, making it share common helpers and adding the payload argument to i2400m_schedule_work(). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i6x50: add Intel WiFi/WiMAX Link 6050 Series supportDirk Brandewie
Add support for the WiMAX device in the Intel WiFi/WiMAX Link 6050 Series; this involves: - adding the device ID to bind to and an endpoint mapping for the driver to use. - at probe() time, some things are set depending on the device id: + the list of firmware names to try + mapping of endpoints Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/iwmc3200: add new sdio device ID to support iwmc3200 2.5GHz skuCindy H Kao
Different sdio device IDs are designated to support different intel wimax silicon sku. The new macro SDIO_DEVICE_ID_IWMC3200_WIMAX_2G5(0x1407) is added to support iwmc3200 2.5GHz sku. The existing SDIO_DEVICE_ID_IWMC3200_WIMAX(0x1402) is for iwmc3200 general sku. Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: on firmware upload, select BCF header that matches device's ↵Inaky Perez-Gonzalez
request Devices based on the i2400m emit a "barker" (32 bit unsigned) when they boot. This barker is used to select, in the firmware file image, which header should be used to process the rest of the file. This commit implements said support, completing the series started by previous commits. We modify the i2400m_fw_dnload() firmware loading path by adding a call to i2400m_bcf_hdr_find() [new function], in which the right BCF header [as listed in i2400m->fw_hdrs by i2400m_fw_check()] is located. Then this header is fed to i2400m_dnload_init() and i2400m_dnload_finalize(). The changes to i2400m_dnload_finalize() are smaller than they look; they add the bcf_hdr argument and use that instead of bcf. Likewise in i2400m_dnload_init(). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19wimax/i2400m: support extended firmware formatInaky Perez-Gonzalez
The SBCF firmware format has been extended to support extra headers after the main payload. These extra headers are used to sign the firmware code with more than one certificate. This eases up distributing single code images that work in more than one SKU of the device. The changes to support this feature will be spread in a series of commits. This one just adds the support to parse the extra headers and store them in i2400m->fw_hdrs. Coming changes to the loader code will use that to determine which header to upload to the device. The i2400m_fw_check() function now iterates over all the headers and for each, calls i2400m_fw_hdr_check(), which does some basic checks on each header. It then stores the headers for the bootloader code to use. The i2400m_dev_bootstrap() function has been modified to cleanup i2400m->fw_hdrs when done. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>