aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wimax
Commit message (Collapse)AuthorAgeFilesLines
* imwc3200: move iwmc3200 SDIO ids to sdio_ids.hTomas Winkler2009-07-261-7/+5
| | | | | | | | 1. add intel's sdio vendor id to sdio_ids.h 2. move iwmc3200 sdio devices' ids to sdio_ids.h Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem.GeunSik Lim2009-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/" directory name to mount debugfs filesystem for ftrace according to ./Documentation/tracers/ftrace.txt file. And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is existed in kernel source like ftrace, DRM, Wireless, Documentation, Network[sky2]files to mount debugfs filesystem. debugfs means debug filesystem for debugging easy to use by greg kroah hartman. "/sys/kernel/debug/" name is suitable as directory name of debugfs filesystem. - debugfs related reference: http://lwn.net/Articles/334546/ Fix inconsistency of directory name to mount debugfs filesystem. * From Steven Rostedt - find_debugfs() and tracing_files() in this patch. Signed-off-by: GeunSik Lim <geunsik.lim@samsung.com> Acked-by : Inaky Perez-Gonzalez <inaky@linux.intel.com> Reviewed-by : Steven Rostedt <rostedt@goodmis.org> Reviewed-by : James Smart <james.smart@emulex.com> CC: Jiri Kosina <trivial@kernel.org> CC: David Airlie <airlied@linux.ie> CC: Peter Osterlund <petero2@telia.com> CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com> CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> CC: Masami Hiramatsu <mhiramat@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* wimax: fix gcc warnings in sh4 when calling BUG()Inaky Perez-Gonzalez2009-06-112-2/+6
| | | | | | | | | | SH4's BUG() seems to confuse the compiler as it is considered to return; thus, some functions would trigger usage of uninitialized variables or non-void functions returning void. Work around by initializing/returning. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: use -EL3RST to indicate device reset instead of -ERESTARTSYSCindy H Kao2009-06-112-3/+3
| | | | | | | | | | | | | | | | | | | | When the i2400m device resets, the driver code will force some functions to return a -ERESTARTSYS error code, which can is used by the caller to determine which recovery actions to take. However, in certain situations the only thing that can be done is to bubble up said error code to user space, for handling. However, -ERESTARSYS was a poor choice, as it is supposed to be used by the kernel only. As such, replace -ERESTARTSYS with -EL3RST; as well, in i2400m_msg_to_dev(), when the device is in boot mode (following a recent reset), return -EL3RST instead of -ENODEV (meaning the device is in bootrom mode after a reset, not that the device was disconnected, and thus, normal commands cannot be executed). Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
* wimax/i2400m: when bootstrap fails, reinitialize the bootromCindy H Kao2009-06-111-1/+1
| | | | | | | | | | | | When a device reset happens during firmware load [in i2400m_dev_bootstrap()], __i2400m_dev_start() will retry a number of times. However, for those retries to be able to accomplish anything, the device's bootrom has to be reinitialized. Thus, on the retry path, pass the I2400M_MAC_REINIT to the firmware load code. Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
* wimax/i2400m/sdio: Move all the RX code to a unified, IRQ based receive routineInaky Perez-Gonzalez2009-06-114-80/+101
| | | | | | | | | | | | | | | The current SDIO code was working in polling mode for boot-mode (firmware load) mode. This was causing issues on some hardware. Moved all the RX code to use a unified IRQ handler that based on the type of data the device is sending can discriminate and decide which is the right destination. As well, all the reads from the device are made to be at least the block size (256); the driver will ignore the rest when not needed. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: don't reset device when bootrom init retries are exceededInaky Perez-Gonzalez2009-06-111-2/+1
| | | | | | | | | | | | | | | | | | | | When i2400m_bootrom_init() fails to put the device into a state of being ready to accept firmware, the driver was currently trying to reset it if it failed to do so. This is not too useful; as part of trying to put the device in the right state a few resets have already been tried. At this point, things are probably fried out and an extra reset might do more harm than good (for example causing reseting of other functions in the same composite device). So it is left up to the callers to determine the error path to take (at the end this is always i2400m_setup(), who depending on how many retries are left, might give up on the device). From a fix by Cindy H. Kao. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m/sdio: Add device specific poke table.Dirk Brandewie2009-06-111-0/+9
| | | | | | Add a poke table for the SDIO device (as it is different than USB). Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
* wimax/i2400m: move boot time poke table out of common driverDirk Brandewie2009-06-112-32/+41
| | | | | | | | | | | | | This change moves the table of "pokes" performed on the device at boot time to the bus specific portion of the driver. Different models of the i2400m device supported by this driver require different poke tables, thus having a single table that works for all is impossible. For that, the table is moved to the bus-specific driver, who can decide which table to use based on the specifics of the device and point the generic driver to it. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
* wimax/i2400m: Allow bus-specific driver to specify retry countInaky Perez-Gonzalez2009-06-115-2/+20
| | | | | | | | | | | | | | | The code that sets up the i2400m (firmware load and general driver setup after it) includes a couple of retry loops. The SDIO device sometimes can get in more complicated corners than the USB one (due to its interaction with other SDIO functions), that require trying a few more times. To solve that, without having a failing USB device taking longer to be considered dead, allow the retry counts to be specified by the bus-specific driver, which the general driver takes as a parameter. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: if a device reboot happens during probe, handle itInaky Perez-Gonzalez2009-06-113-0/+5
| | | | | | | | | | | When a device reboot happens when we are under probe, with init_mutex taken, make sure we can recover. Have dev_reset_handle set boot mode and i2400m_msg_to_dev() will see it and fail gracefully instead of timing out. Found and diagnosed by Cindy H. Kao. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: fix oops when the TX FIFO fills up due to a missing checkInaky Perez-Gonzalez2009-06-111-0/+2
| | | | | | | | | | When the TX FIFO filled up and i2400m_tx_new() failed to allocate a new TX message header, a missing check for said condition was causing a kernel oops when trying to dereference a NULL i2400m->tx_msg pointer. Found and diagnosed by Cindy H. Kao. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: don't reset device on i2400m_dev_shutdown()Inaky Perez-Gonzalez2009-06-111-5/+5
| | | | | | | | | | | | | | | | | | | | | i2400m_dev_shutdown() tried to reset the device to put it in a known state before shutting down. But that turned out to be pointless. We reach this case in two paths: 1 - when the device resets, to clean up state 2 - when the driver is unloaded, for the same however, in both cases it is pointless; in (1) the device is already reset, why do it again? in (2) we can't -- the USB stack, for example, doesn't allow communicating with the device when the driver is being unbound and if the device is disconnected, the device is gone already. So just remove it. Leave the function as a placeholder for future cleanups that will be done from data allocated by the driver during device operation. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: fix panic due to missed corner cases on tail_room calculationInaky Perez-Gonzalez2009-06-111-2/+56
| | | | | | | | | | | | | | | | | | | | | | | | i2400m_tx_skip_tail() needs to handle the special case of being called when the tail room that is left over in the FIFO is zero. This happens when a TX message header was opened at the very end of the FIFO (without payloads). The i2400m_tx_close() code already marked said TX message (header) to be skipped and this function should be doing nothing. It is called anyway because it is part of a common "corner case" path handling which takes care of more cases than only this one. The tail room computation was also improved to take care of the case when tx_in is at the end of the buffer boundary; tail_room has to be modded (%) to the buffer size. To do that in a single well-documented place, __i2400m_tx_tail_room() is introduced and used. Treat i2400m->tx_in == 0 as a corner case and handle it accordingly. Found and diagnosed by Cindy H. Kao. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: fix panic/warnings caused by missed check on empty TX messageInaky Perez-Gonzalez2009-06-111-1/+9
| | | | | | | | | | | | | | In some situations, when a new TX message header is started, there might be no space for data payloads. In this case the message is left with zero payloads and the i2400m_tx_close() function has just to mark it as "to skip". If it tries to go ahead it will overwrite things because there is no space to add padding as defined by the bus-specific layer. This can cause buffer overruns and in some stress cases, panics. Found and diagnosed by Cindy H. Kao. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: rename misleading I2400M_PL_PAD to I2400M_PL_ALIGNInaky Perez-Gonzalez2009-06-113-5/+5
| | | | | | | The constant is being use as an alignment factor, not as a padding factor; made reading/reviewing the code quite confusing. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m/sdio: Implement I2400M_RT_BUS reset typeDirk Brandewie2009-06-112-3/+19
| | | | | | | | | This reset type causes the WiMAX function to be disabled and re-enabled, which will force the WiMAX device to reset and enter boot mode. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
* wimax/i2400m: Change d_printf() level for secure boot messagesDirk Brandewie2009-06-111-2/+2
| | | | | | | Changing debug level of print out to support validation engineers getting the messages they need. Signed-off-by: <dirk.j.brandewie@intel.com>
* wimax/i2400m: i2400m_schedule_work() doesn't need i2400m->work_queueInaky Perez-Gonzalez2009-06-111-1/+0
| | | | | | | By mistake, the BUG_ON() check was left in there and it will fail when called if i2400m->work_queue is still not setup. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: i2400m's work queue should be initialized before RX supportInaky Perez-Gonzalez2009-06-111-7/+14
| | | | | | | | RX support is the only user of the work-queue, to process reports/notifications from the device. Thus, it needs the work queue to be initialized first. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: don't call netif_start_queue() in _tx_msg_sent()Inaky Perez-Gonzalez2009-06-111-1/+0
| | | | | | | | | | | | | | | | | | Reported and fixed by Cindy H Kao. When the device is stopped __i2400m_dev_stop() stops the network queue. However, when this is done in the middle of heavy network operation, when the bus-specific subdriver is still wrapping up and it reports a sent TX transaction with _tx_msg_sent() right after the device was stopped, the queue was being started again, which was causing a stream of oopsen and finally a panic. In any case, said call has no place there. It's a left over from an early implementation that was discarded later on. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: introduce module parameter to disable entering power saveInaky Perez-Gonzalez2009-06-113-2/+18
| | | | | | | | | | | | | | | The i2400m driver waits for the device to report being ready for entering power save before asking it to do so. This module parameter allows control of said operation; if disabled, the driver won't ask the device to enter power save mode. This is useful in setups where power saving is not so important or when the overhead imposed by network reentry after power save is not acceptable; by combining this with parameter 'idle_mode_disabled', the driver will always maintain both the connection and the device in active state. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: usb: fix device reset on autosuspend while not yet idleInaky Perez-Gonzalez2009-05-281-5/+30
| | | | | | | | | | | | | | | | | | | When the i2400m is connected to a network, the host interface (USB) cannot be suspended. For that to happen, the device has to have negotiated with the basestation to put the link on IDLE state. If the host tries to put the device in standby while it is connected but not idle, the device resets, as the driver should not do that. To avoid triggering that, when the USB susbsytem requires the driver to autosuspend the device, the driver checks if the device is not yet idle. If it is not, the request is requested (will be retried again later on after the autosuspend timeout). At some point the device will enter idle and the request will succeed (unless of course, there is network traffic, but at that point, there is no idle neither in the link or the host interface). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: sdio: set the block size before enabling the functionInaky Perez-Gonzalez2009-05-281-9/+9
| | | | | | | | | From a fix by Cindy H Kao: Block size has to be set before sending IOE enable because the firmware reads the block size register before it reads IOE register. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: remove redundant readiness checks from i2400m_report_tlv_*()Inaky Perez-Gonzalez2009-05-282-7/+2
| | | | | | | | | | | | | | | Functions i2400m_report_tlv*() are only called from i2400m_report_hook(), called in a workqueue by i2400m_report_hook_work(). The scheduler checks for device readiness before scheduling. Added an extra check for readiness in i2400m_report_hook_work(), which makes all the checks down the line redundant. Obviously the device state could change in the middle, but error handling would take care of that. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: factor out 'state report's TLV handling to a functionInaky Perez-Gonzalez2009-05-281-39/+50
| | | | | | | i2400m_report_state_hook() is going to get messier as we add handling code. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: allow kernel commands to device to be logged tooInaky Perez-Gonzalez2009-05-282-10/+5
| | | | | | | | | | | | | | By running 'echo 1 > /sys/kernel/debug/wimax:wmxX/i2400m/trace_msg_from_user', the driver will echo to user space all the commands being sent to the device from user space, along with the responses. However, this only helps with the commands being sent from user space; with this patch, the trace hook is moved to i2400m_msg_to_dev(), which is the single access point for running commands to the device (both by user space and the kernel driver). This allows better debugging by having a complete stream of commands/acks and reports. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: trace commands sent from user space on the "echo" pipeInaky Perez-Gonzalez2009-05-282-3/+13
| | | | | | | | | | | | | When commands are sent from user space, trace both the command sent and the answer received over the "echo" pipe instead of over the "trace" pipe when command tracing is enabled. As well, when the device sends a reports/indications, send it over the "echo" pipe. The "trace" pipe is used by the device to send firmware traces; gets confusing. Another named pipe makes it easier to split debug information. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: generate fake source MAC address with random_ether_addr()Inaky Perez-Gonzalez2009-05-283-1/+10
| | | | | | | | | | | | | | | | The WiMAX i2400m driver needs to generate a fake source MAC address to fake an ethernet header (for destination, the card's MAC is used). This is the source of the packet, which is the basestation it came from. The basestation's mac address is not usable for this, as it uses its own namespace and it is not always available. Currently the fake source MAC address was being set to all zeros, which was causing trouble with bridging. Use random_ether_addr() to generate a proper one that creates no trouble. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax/i2400m: fix device crash: fix optimization in _roq_queue_update_wsInaky Perez-Gonzalez2009-05-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | When the i2400m receives data and the device indicates there has to be reordering, we keep an sliding window implementation to sort the packets before sending them to the network stack. One of the "operations" that the device indicates is "queue a packet and update the window start". When the queue is empty, this is equivalent to "deliver the packet and update the window start". That case was optimized in i2400m_roq_queue_update_ws() so that we would not pointlessly queue and dequeue a packet. However, when the optimization was active, it wasn't updating the window start. That caused the reorder management code to get confused later on with what seemed to be wrong reorder requests from the device. Thus the fix implemented is to do the right thing and update the window start in both cases, when the queue is empty (and the optimization is done) and when not. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* wimax: fix i2400m printk formatsRandy Dunlap2009-03-111-2/+2
| | | | | | | | | | | Fix printk format warnings: drivers/net/wimax/i2400m/netdev.c:523: warning: format '%zu' expects type 'size_t', but argument 7 has type 'unsigned int' drivers/net/wimax/i2400m/netdev.c:548: warning: format '%zu' expects type 'size_t', but argument 7 has type 'unsigned int' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax/i2400m: implement RX reorder supportInaky Perez-Gonzalez2009-03-024-26/+695
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the device to give the driver RX data with reorder information. When that is done, the device will indicate the driver if a packet has to be held in a (sorted) queue. It will also tell the driver when held packets have to be released to the OS. This is done to improve the WiMAX-protocol level retransmission support when missing frames are detected. The code docs provide details about the implementation. In general, this just hooks into the RX path in rx.c; if a packet with the reorder bit in the RX header is detected, the reorder information in the header is extracted and one of the four main reorder operations are executed. In one case (queue) no packet will be delivered to the networking stack, just queued, whereas in the others (reset, update_ws and queue_update_ws), queued packet might be delivered depending on the window start for the specific queue. The modifications to files other than rx.c are: - control.c: during device initialization, enable reordering support if the rx_reorder_disabled module parameter is not enabled - driver.c: expose a rx_reorder_disable module parameter and call i2400m_rx_setup/release() to initialize/shutdown RX reorder support. - i2400m.h: introduce members in 'struct i2400m' needed for implementing reorder support. - linux/i2400m.h: introduce TLVs, commands and constant definitions related to RX reorder Last but not least, the rx reorder code includes an small circular log where the last N reorder operations are recorded to be displayed in case of inconsistency. Otherwise diagnosing issues would be almost impossible. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax: replace uses of __constant_{endian}Harvey Harrison2009-03-021-4/+6
| | | | | | | | | | Base versions handle constant folding now. Edited by Inaky to fix conflicts due to changes in netdev.c Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax/i2400m: support extended data RX protocol (no need to reallocate skbs)Inaky Perez-Gonzalez2009-03-024-33/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Newer i2400m firmwares (>= v1.4) extend the data RX protocol so that each packet has a 16 byte header. This header is mainly used to implement host reordeing (which is addressed in later commits). However, this header also allows us to overwrite it (once data has been extracted) with an Ethernet header and deliver to the networking stack without having to reallocate the skb (as it happened in fw <= v1.3) to make room for it. - control.c: indicate the device [dev_initialize()] that the driver wants to use the extended data RX protocol. Also involves adding the definition of the needed data types in include/linux/wimax/i2400m.h. - rx.c: handle the new payload type for the extended RX data protocol. Prepares the skb for delivery to netdev.c:i2400m_net_erx(). - netdev.c: Introduce i2400m_net_erx() that adds the fake ethernet address to a prepared skb and delivers it to the networking stack. - cleanup: in most instances in rx.c, the variable 'single' was renamed to 'single_last' for it better conveys its meaning. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers2009-03-022-2/+2
| | | | | | | | | Cc: inaky.perez-gonzalez@intel.com Cc: linux-wimax@intel.com Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax/i2400m: allow control of the base-station idle mode timeoutInaky Perez-Gonzalez2009-03-026-8/+211
| | | | | | | | | | | | | | | | | | | | | | For power saving reasons, WiMAX links can be put in idle mode while connected after a certain time of the link not being used for tx or rx. In this mode, the device pages the base-station regularly and when data is ready to be transmitted, the link is revived. This patch allows the user to control the time the device has to be idle before it decides to go to idle mode from a sysfs interace. It also updates the initialization code to acknowledge the module variable 'idle_mode_disabled' when the firmware is a newer version (upcoming 1.4 vs 2.6.29's v1.3). The method for setting the idle mode timeout in the older firmwares is much more limited and can be only done at initialization time. Thus, the sysfs file will return -ENOSYS on older ones. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax/i2400m: firmware_check() encodes the firmware version in ↵Inaky Perez-Gonzalez2009-03-023-5/+16
| | | | | | | | | | | | | | | | | | | i2400m->fw_version Upcoming modifications will need to test for the running firmware version before activating a feature or not. This is helpful to implement backward compatibility with older firmware versions. Modify i2400m_firmware_check() to encode in i2400m->fw_version the major and minor version numbers of the firmware interface. As well, move the call to be done as the very first operation once we have communication with the device during probe() [in __i2400m_dev_start()]. This is needed so any operation that is executed afterwards can determine which fw version it is talking to. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax/i2400m: drop support for deprecated major fw interface, add for new minorInaky Perez-Gonzalez2009-03-021-9/+5
| | | | | | | | | | | | | | | Firmware interface version 8.x.x has long been deprecated and is no longer supported (nor available, as it is a preproduction firmware), so it can be safely dropped. Add support for firmware interface v9.2.x (current is 9.1.x). Firmware version 9.2.x is backwards compatible with 9.1.x; new features are enabled if switches are pressed to turn them on. Forthcoming commits to the driver will start pressing those switches when the firmware interface supports it. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax/i2400m: add the ability to fallback to other firmware files if the ↵Inaky Perez-Gonzalez2009-03-024-35/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | default is not there In order to support backwards compatibility with older firmwares when a driver is updated by a new kernel release, the i2400m bus drivers can declare a list of firmware files they can work with (in general these will be each a different version). The firmware loader will try them in sequence until one loads. Thus, if a user doesn't have the latest and greatest firmware that a newly installed kernel would require, the driver would fall back to the firmware from a previous release. To support this, the i2400m->bus_fw_name is changed to be a NULL terminated array firmware file names (and renamed to bus_fw_names) and we add a new entry (i2400m->fw_name) that points to the name of the firmware being currently used. All code that needs to print the firmware file name uses i2400m->fw_name instead of the old i2400m->bus_fw_name. The code in i2400m_dev_bootstrap() that loads the firmware is changed with an iterator over the firmware file name list that tries to load each form user space, using the first one that succeeds in request_firmware() (and thus stopping the iteration). The USB and SDIO bus drivers are updated to take advantage of this and reflect which firmwares they support. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i2400m: remove some pointless conditionals before kfree_skb()Wei Yongjun2009-02-261-2/+1
| | | | | | | Remove some pointless conditionals before kfree_skb(). Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller2009-02-241-1/+1
|\
| * wimax/i2400m: driver loads firmware v1.4 instead of v1.3Inaky Perez-Gonzalez2009-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a one liner change to have the driver use by default the v1.4 of the i2400m firmware instead of v1.3. The v1.4 version of the firmware has been submitted to David Woodhouse for inclusion in the linux-firmware tree and it is already available at http://linuxwimax.org/Download. The reason for this change is that the 1.3 release of the user space software and firmware has a few issues that will make it difficult to use with currently deployed commercial networks such as Xohm and Clearwire. As well, the new 1.4 release of the user space software (which matches the 1.4 firmware) has intermitent issues with the 1.3 firmware. The 1.4 release in http://linuxwimax.org/Download has been widely deployed and tested with the codebase in 2.6.29-rc, the 1.4 firmware and the 1.4 user space components. We understand it is quite late in the rc process for such a change, but would like to ask for the change to be taken into consideration. Alternatively, a user could always force feed a 1.4 firmware into a driver that doesn't have this modification by: $ cd /lib/firmware $ mv i2400m-fw-usb-1.3.sbcf i2400m-fw-usb-1.3.real.sbcf $ ln -sf i2400m-fw-usb-1.4.sbc i2400m-fw-usb-1.3.sbcf Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | wimax: replace uses of __constant_{endian}Harvey Harrison2009-02-015-31/+31
| | | | | | | | | | | | | | | | Base versions handle constant folding now. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'master' of ↵David S. Miller2009-01-302-14/+16
|\ \ | |/ | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/e1000/e1000_main.c
| * wimax: fix build issue when debugfs is disabledInaky Perez-Gonzalez2009-01-292-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As reported by Toralf Förster and Randy Dunlap. - http://linuxwimax.org/pipermail/wimax/2009-January/000460.html - http://lkml.org/lkml/2009/1/29/279 The definitions needed for the wimax stack and i2400m driver debug infrastructure was, by mistake, compiled depending on CONFIG_DEBUG_FS (by them being placed in the debugfs.c files); thus the build broke in 2.6.29-rc3 when debugging was enabled (CONFIG_WIMAX_DEBUG) and DEBUG_FS was disabled. These definitions are always needed if debug is enabled at compile time (independently of DEBUG_FS being or not enabled), so moving them to a file that is always compiled fixes the issue. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | wimax/i2400m: convert to net_device_opsInaky Perez-Gonzalez2009-01-211-5/+9
|/ | | | | Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* wimax/i2400m: error paths that need to free an skb should use kfree_skb()Inaky Perez-Gonzalez2009-01-192-4/+7
| | | | | | | | | | | | | | | | | | Roel Kluin reported a bug in two error paths where skbs were wrongly being freed using kfree(). He provided a fix where it was replaced to kfree_skb(), as it should be. However, in i2400mu_rx(), the error path was missing returning an indication of the failure. Changed to reset rx_skb to NULL and return it to the caller, i2400mu_rxd(). It will be treated as a transient error and just ignore the packet. Depending on the buffering conditions inside the device, the data packet might be dropped or the device will signal the host again for data-ready-to-read and the host will retry. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i2400m/usb: wrap USB power saving in #ifdef CONFIG_PMInaky Perez-Gonzalez2009-01-081-0/+6
| | | | | | | | | | | | Current code was assuming PM was always enabled, which is not correct. Code which accesses members in the struct usb_device that are dependant on CONFIG_PM must be protected the same. Reported by Randy Dunlap from a build error in the linux-next tree on 07/01/2009. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* i2400m: Makefile and KconfigInaky Perez-Gonzalez2009-01-074-0/+100
| | | | | | | | Integrate the i2400m driver into the kernel's build and Kconfig. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* i2400m/SDIO: TX and RX path backendsInaky Perez-Gonzalez2009-01-072-0/+408
| | | | | | | | | | | | | | | | | | | Implements the backend so that the generic driver can TX/RX to/from the SDIO device. For RX, when data is ready the SDIO IRQ is fired and that will allocate an skb, put all the data there and then pass it to the generic driver RX code for processing and delivery. TX, when kicked by the generic driver, will schedule work on a driver-specific workqueue that pulls data from the TX FIFO and sends it to the device until it drains it. Thread contexts are needed as SDIO functions are blocking. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>