aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/wimax
AgeCommit message (Collapse)Author
2009-02-20wimax/i2400m: driver loads firmware v1.4 instead of v1.3Inaky Perez-Gonzalez
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>
2009-01-29wimax: fix build issue when debugfs is disabledInaky Perez-Gonzalez
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>
2009-01-19wimax/i2400m: error paths that need to free an skb should use kfree_skb()Inaky Perez-Gonzalez
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>
2009-01-08i2400m/usb: wrap USB power saving in #ifdef CONFIG_PMInaky Perez-Gonzalez
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>
2009-01-07i2400m: Makefile and KconfigInaky Perez-Gonzalez
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>
2009-01-07i2400m/SDIO: TX and RX path backendsInaky Perez-Gonzalez
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>
2009-01-07i2400m/SDIO: firmware upload backendInaky Perez-Gonzalez
This implements the backends for the generic driver (i2400m) to be able to load firmware to the SDIO device. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m/SDIO: probe/disconnect, dev init/shutdown and reset backendsInaky Perez-Gonzalez
Implements probe/disconnect for the SDIO device, as well as main backends for the generic driver to control the SDIO device (bus_dev_start(), bus_dev_stop() and bus_reset()). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m/SDIO: header for the SDIO subdriverInaky Perez-Gonzalez
This contains the common function declaration and constants for the SDIO driver for the 2400m Wireless WiMAX Connection and it's debug level settings. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m/USB: TX and RX path backendsInaky Perez-Gonzalez
Implements the backend so that the generic driver can TX/RX to/from the USB device. TX is implemented with a kthread sitting in a never-ending loop that when kicked by the generic driver's TX code will pull data from the TX FIFO and send it to the device until it drains it. Then it goes back sleep, waiting for another kick. RX is implemented in a similar fashion, but reads are kicked in by the device notifying in the interrupt endpoint that data is ready. Device reset notifications are also sent via the notification endpoint. We need a thread contexts to run USB autopm functions (blocking) and to process the received data (can get to be heavy in processing time). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m/USB: firmware upload backendInaky Perez-Gonzalez
This implements the backends for the generic driver (i2400m) to be able to load firmware to the USB device. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m/USB: probe/disconnect, dev init/shutdown and reset backendsInaky Perez-Gonzalez
Implements probe/disconnect for the USB device, as well as main backends for the generic driver to control the USB device (bus_dev_start(), bus_dev_stop() and bus_reset()). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m/USB: header for the USB bus driverInaky Perez-Gonzalez
This contains the common function declaration and constants for the USB driver for the 2400m Wireless WiMAX Connection, as well as it's debug level settings. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m: debugfs controlsInaky Perez-Gonzalez
Expose knobs to control the device (induce reset, power saving, querying tx or rx stats, internal debug information and debug level manipulation). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m: various functions for device managementInaky Perez-Gonzalez
This is a collection of functions used to control the device (plus a few helpers). There are utilities for handling TLV buffers, hooks on the device's reports to act on device changes of state [i2400m_report_hook()], on acks to commands [i2400m_msg_ack_hook()], a helper for sending commands to the device and blocking until a reply arrives [i2400m_msg_to_dev()], a few high level commands for manipulating the device state, powersaving mode and configuration plus the routines to setup the device once communication is established with it [i2400m_dev_initialize()]. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m: RX and TX data/control pathsInaky Perez-Gonzalez
Handling of TX/RX data to/from the i2400m device (IP packets, control and diagnostics). On RX, this parses the received read transaction from the device, breaks it in chunks and passes it to the corresponding subsystems (network and control). Transmission to the device is done through a software FIFO, as data/control frames can be coalesced (while the device is reading the previous tx transaction, others accumulate). A FIFO is used because at the end it is resource-cheaper that scatter/gather over USB. As well, most traffic is going to be download (vs upload). Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m: firmware loading and bootrom initializationInaky Perez-Gonzalez
Implements the firmware loader (using the bus-specific driver's backends for the actual upload). The most critical thing in here is the piece that puts the device in boot-mode from any other (undetermined) state, otherwise, it is just pushing the bytes from the firmware file to the device. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m: linkage to the networking stackInaky Perez-Gonzalez
Implementation of the glue to the network stack so the WiMAX device shows up as an Ethernet device. Initially we shot for implementing a Pure IP device -- however, the world seems to turn around Ethernet devices. Main issues were with the ISC DHCP client and servers (as they don't understand types other than Ethernet and Token Ring). We proceeded to register with IANA the PureIP hw type, so that DHCP requests could declare such. We also created patches to the main ISC DHCP versions to support it. However, until all that permeates into deployments, there is going to be a long time. So we moved back to wrap Ethernet frames around the PureIP device. At the time being this has overhead; we need to reallocate with space for an Ethernet header. The reason is the device-to-host protocol coalesces many network packets into a single message, so we can't introduce Ethernet headers without overwriting valid data from other packets. Coming-soon versions of the firmware have this issue solved. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m: Generic probe/disconnect, reset and message passingInaky Perez-Gonzalez
Implements the generic probe and disconnect functions that will be called by the USB and SDIO driver's probe/disconnect functions. Implements the backends for the WiMAX stack's basic operations: message passing, rfkill control and reset. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07i2400m: host/device procotol and core driver definitionsInaky Perez-Gonzalez
The wimax/i2400m.h defines the structures and constants for the host-device protocols: - boot / firmware upload protocol - general data transport protocol - control protocol It is done in such a way that can also be used verbatim by user space. drivers/net/wimax/i2400m.h defines all the APIs used by the core, bus-generic driver (i2400m) and the bus specific drivers (i2400m-BUSNAME). It also gives a roadmap to the driver implementation. debug-levels.h adds the core driver's debug settings. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>