Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 7c7758f9 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (123 commits)
  wimax/i2400m: add CREDITS and MAINTAINERS entries
  wimax: export linux/wimax.h and linux/wimax/i2400m.h with headers_install
  i2400m: Makefile and Kconfig
  i2400m/SDIO: TX and RX path backends
  i2400m/SDIO: firmware upload backend
  i2400m/SDIO: probe/disconnect, dev init/shutdown and reset backends
  i2400m/SDIO: header for the SDIO subdriver
  i2400m/USB: TX and RX path backends
  i2400m/USB: firmware upload backend
  i2400m/USB: probe/disconnect, dev init/shutdown and reset backends
  i2400m/USB: header for the USB bus driver
  i2400m: debugfs controls
  i2400m: various functions for device management
  i2400m: RX and TX data/control paths
  i2400m: firmware loading and bootrom initialization
  i2400m: linkage to the networking stack
  i2400m: Generic probe/disconnect, reset and message passing
  i2400m: host/device procotol and core driver definitions
  i2400m: documentation and instructions for usage
  wimax: Makefile, Kconfig and docbook linkage for the stack
  ...
parents 67acd8b4 8a70da82

CREDITS

+17 −0
Original line number Diff line number Diff line
@@ -464,6 +464,11 @@ S: 1200 Goldenrod Dr. 
S: Nampa, Idaho 83686

S: USA



N: Dirk J. Brandewie

E: dirk.j.brandewie@intel.com

E: linux-wimax@intel.com

D: Intel Wireless WiMAX Connection 2400 SDIO driver



N: Derrick J. Brashear

E: shadow@dementia.org

W: http://www.dementia.org/~shadow
@@ -2119,6 +2124,11 @@ N: H.J. Lu 
E: hjl@gnu.ai.mit.edu

D: GCC + libraries hacker



N: Yanir Lubetkin

E: yanirx.lubatkin@intel.com

E: linux-wimax@intel.com

D: Intel Wireless WiMAX Connection 2400 driver



N: Michal Ludvig

E: michal@logix.cz

E: michal.ludvig@asterisk.co.nz
@@ -2693,6 +2703,13 @@ S: RR #5, 497 Pole Line Road 
S: Thunder Bay, Ontario

S: CANADA P7C 5M9



N: Inaky Perez-Gonzalez

E: inaky.perez-gonzalez@intel.com

E: linux-wimax@intel.com

E: inakypg@yahoo.com

D: WiMAX stack

D: Intel Wireless WiMAX Connection 2400 driver



N: Yuri Per

E: yuri@pts.mipt.ru

D: Some smbfs fixes

Documentation/DocBook/networking.tmpl

+8 −0
Original line number Diff line number Diff line
@@ -74,6 +74,14 @@ 
!Enet/sunrpc/rpcb_clnt.c

!Enet/sunrpc/clnt.c

     </sect1>

     <sect1><title>WiMAX</title>

!Enet/wimax/op-msg.c

!Enet/wimax/op-reset.c

!Enet/wimax/op-rfkill.c

!Enet/wimax/stack.c

!Iinclude/net/wimax.h

!Iinclude/linux/wimax.h

     </sect1>

  </chapter>



  <chapter id="netdev">

Documentation/kernel-parameters.txt

+36 −0
Original line number Diff line number Diff line
@@ -91,6 +91,7 @@ parameter is applicable: 
	SUSPEND	System suspend states are enabled.

	FTRACE	Function tracing enabled.

	TS	Appropriate touchscreen support is enabled.

	UMS	USB Mass Storage support is enabled.

	USB	USB support is enabled.

	USBHID	USB Human Interface Device support is enabled.

	V4L	Video For Linux support is enabled.
@@ -2383,6 +2384,41 @@ and is between 256 and 4096 characters. It is defined in the file 
	usbhid.mousepoll=

			[USBHID] The interval which mice are to be polled at.



	usb-storage.delay_use=

			[UMS] The delay in seconds before a new device is

			scanned for Logical Units (default 5).



	usb-storage.quirks=

			[UMS] A list of quirks entries to supplement or

			override the built-in unusual_devs list.  List

			entries are separated by commas.  Each entry has

			the form VID:PID:Flags where VID and PID are Vendor

			and Product ID values (4-digit hex numbers) and

			Flags is a set of characters, each corresponding

			to a common usb-storage quirk flag as follows:

				a = SANE_SENSE (collect more than 18 bytes

					of sense data);

				c = FIX_CAPACITY (decrease the reported

					device capacity by one sector);

				h = CAPACITY_HEURISTICS (decrease the

					reported device capacity by one

					sector if the number is odd);

				i = IGNORE_DEVICE (don't bind to this

					device);

				l = NOT_LOCKABLE (don't try to lock and

					unlock ejectable media);

				m = MAX_SECTORS_64 (don't transfer more

					than 64 sectors = 32 KB at a time);

				o = CAPACITY_OK (accept the capacity

					reported by the device);

				r = IGNORE_RESIDUE (the device reports

					bogus residue values);

				s = SINGLE_LUN (the device has only one

					Logical Unit);

				w = NO_WP_DETECT (don't test whether the

					medium is write-protected).

			Example: quirks=0419:aaf5:rl,0421:0433:rc



	add_efi_memmap	[EFI; x86-32,X86-64] Include EFI memory map in

			kernel's map of available physical RAM.

Documentation/usb/power-management.txt

+17 −5
Original line number Diff line number Diff line
@@ -313,11 +313,13 @@ three of the methods listed above. In addition, a driver indicates 
that it supports autosuspend by setting the .supports_autosuspend flag

in its usb_driver structure.  It is then responsible for informing the

USB core whenever one of its interfaces becomes busy or idle.  The

driver does so by calling these three functions:

driver does so by calling these five functions:



	int  usb_autopm_get_interface(struct usb_interface *intf);

	void usb_autopm_put_interface(struct usb_interface *intf);

	int  usb_autopm_set_interface(struct usb_interface *intf);

	int  usb_autopm_get_interface_async(struct usb_interface *intf);

	void usb_autopm_put_interface_async(struct usb_interface *intf);



The functions work by maintaining a counter in the usb_interface

structure.  When intf->pm_usage_count is > 0 then the interface is
@@ -330,10 +332,12 @@ associated with the device itself rather than any of its interfaces. 
This field is used only by the USB core.)



The driver owns intf->pm_usage_count; it can modify the value however

and whenever it likes.  A nice aspect of the usb_autopm_* routines is

that the changes they make are protected by the usb_device structure's

PM mutex (udev->pm_mutex); however drivers may change pm_usage_count

without holding the mutex.

and whenever it likes.  A nice aspect of the non-async usb_autopm_*

routines is that the changes they make are protected by the usb_device

structure's PM mutex (udev->pm_mutex); however drivers may change

pm_usage_count without holding the mutex.  Drivers using the async

routines are responsible for their own synchronization and mutual

exclusion.



	usb_autopm_get_interface() increments pm_usage_count and

	attempts an autoresume if the new value is > 0 and the
@@ -348,6 +352,14 @@ without holding the mutex. 
	is suspended, and it attempts an autosuspend if the value is

	<= 0 and the device isn't suspended.



	usb_autopm_get_interface_async() and

	usb_autopm_put_interface_async() do almost the same things as

	their non-async counterparts.  The differences are: they do

	not acquire the PM mutex, and they use a workqueue to do their

	jobs.  As a result they can be called in an atomic context,

	such as an URB's completion handler, but when they return the

	device will not generally not yet be in the desired state.



There also are a couple of utility routines drivers can use:



	usb_autopm_enable() sets pm_usage_cnt to 0 and then calls

Documentation/wimax/README.i2400m

0 → 100644
+260 −0
Original line number Diff line number Diff line 


   Driver for the Intel Wireless Wimax Connection 2400m



   (C) 2008 Intel Corporation < linux-wimax@intel.com >



   This provides a driver for the Intel Wireless WiMAX Connection 2400m

   and a basic Linux kernel WiMAX stack.



1. Requirements



     * Linux installation with Linux kernel 2.6.22 or newer (if building

       from a separate tree)

     * Intel i2400m Echo Peak or Baxter Peak; this includes the Intel

       Wireless WiMAX/WiFi Link 5x50 series.

     * build tools:

          + Linux kernel development package for the target kernel; to

            build against your currently running kernel, you need to have

            the kernel development package corresponding to the running

            image installed (usually if your kernel is named

            linux-VERSION, the development package is called

            linux-dev-VERSION or linux-headers-VERSION).

          + GNU C Compiler, make



2. Compilation and installation



2.1. Compilation of the drivers included in the kernel



   Configure the kernel; to enable the WiMAX drivers select Drivers >

   Networking Drivers > WiMAX device support. Enable all of them as

   modules (easier).



   If USB or SDIO are not enabled in the kernel configuration, the options

   to build the i2400m USB or SDIO drivers will not show. Enable said

   subsystems and go back to the WiMAX menu to enable the drivers.



   Compile and install your kernel as usual.



2.2. Compilation of the drivers distributed as an standalone module



   To compile



$ cd source/directory

$ make



   Once built you can load and unload using the provided load.sh script;

   load.sh will load the modules, load.sh u will unload them.



   To install in the default kernel directories (and enable auto loading

   when the device is plugged):



$ make install

$ depmod -a



   If your kernel development files are located in a non standard

   directory or if you want to build for a kernel that is not the

   currently running one, set KDIR to the right location:



$ make KDIR=/path/to/kernel/dev/tree



   For more information, please contact linux-wimax@intel.com.



3. Installing the firmware



   The firmware can be obtained from http://linuxwimax.org or might have

   been supplied with your hardware.



   It has to be installed in the target system:

     *

$ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf



     * NOTE: if your firmware came in an .rpm or .deb file, just install

       it as normal, with the rpm (rpm -i FIRMWARE.rpm) or dpkg

       (dpkg -i FIRMWARE.deb) commands. No further action is needed.

     * BUSTYPE will be usb or sdio, depending on the hardware you have.

       Each hardware type comes with its own firmware and will not work

       with other types.



4. Design



   This package contains two major parts: a WiMAX kernel stack and a

   driver for the Intel i2400m.



   The WiMAX stack is designed to provide for common WiMAX control

   services to current and future WiMAX devices from any vendor; please

   see README.wimax for details.



   The i2400m kernel driver is broken up in two main parts: the bus

   generic driver and the bus-specific drivers. The bus generic driver

   forms the drivercore and contain no knowledge of the actual method we

   use to connect to the device. The bus specific drivers are just the

   glue to connect the bus-generic driver and the device. Currently only

   USB and SDIO are supported. See drivers/net/wimax/i2400m/i2400m.h for

   more information.



   The bus generic driver is logically broken up in two parts: OS-glue and

   hardware-glue. The OS-glue interfaces with Linux. The hardware-glue

   interfaces with the device on using an interface provided by the

   bus-specific driver. The reason for this breakup is to be able to

   easily reuse the hardware-glue to write drivers for other OSes; note

   the hardware glue part is written as a native Linux driver; no

   abstraction layers are used, so to port to another OS, the Linux kernel

   API calls should be replaced with the target OS's.



5. Usage



   To load the driver, follow the instructions in the install section;

   once the driver is loaded, plug in the device (unless it is permanently

   plugged in). The driver will enumerate the device, upload the firmware

   and output messages in the kernel log (dmesg, /var/log/messages or

   /var/log/kern.log) such as:



...

i2400m_usb 5-4:1.0: firmware interface version 8.0.0

i2400m_usb 5-4:1.0: WiMAX interface wmx0 (00:1d:e1:01:94:2c) ready



   At this point the device is ready to work.



   Current versions require the Intel WiMAX Network Service in userspace

   to make things work. See the network service's README for instructions

   on how to scan, connect and disconnect.



5.1. Module parameters



   Module parameters can be set at kernel or module load time or by

   echoing values:



$ echo VALUE > /sys/module/MODULENAME/parameters/PARAMETERNAME



   To make changes permanent, for example, for the i2400m module, you can

   also create a file named /etc/modprobe.d/i2400m containing:



options i2400m idle_mode_disabled=1



   To find which parameters are supported by a module, run:



$ modinfo path/to/module.ko



   During kernel bootup (if the driver is linked in the kernel), specify

   the following to the kernel command line:



i2400m.PARAMETER=VALUE



5.1.1. i2400m: idle_mode_disabled



   The i2400m module supports a parameter to disable idle mode. This

   parameter, once set, will take effect only when the device is

   reinitialized by the driver (eg: following a reset or a reconnect).



5.2. Debug operations: debugfs entries



   The driver will register debugfs entries that allow the user to tweak

   debug settings. There are three main container directories where

   entries are placed, which correspond to the three blocks a i2400m WiMAX

   driver has:

     * /sys/kernel/debug/wimax:DEVNAME/ for the generic WiMAX stack

       controls

     * /sys/kernel/debug/wimax:DEVNAME/i2400m for the i2400m generic

       driver controls

     * /sys/kernel/debug/wimax:DEVNAME/i2400m-usb (or -sdio) for the

       bus-specific i2400m-usb or i2400m-sdio controls).



   Of course, if debugfs is mounted in a directory other than

   /sys/kernel/debug, those paths will change.



5.2.1. Increasing debug output



   The files named *dl_* indicate knobs for controlling the debug output

   of different submodules:

     *

# find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\*

/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_tx

/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_rx

/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_notif

/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_fw

/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_usb

/sys/kernel/debug/wimax:wmx0/i2400m/dl_tx

/sys/kernel/debug/wimax:wmx0/i2400m/dl_rx

/sys/kernel/debug/wimax:wmx0/i2400m/dl_rfkill

/sys/kernel/debug/wimax:wmx0/i2400m/dl_netdev

/sys/kernel/debug/wimax:wmx0/i2400m/dl_fw

/sys/kernel/debug/wimax:wmx0/i2400m/dl_debugfs

/sys/kernel/debug/wimax:wmx0/i2400m/dl_driver

/sys/kernel/debug/wimax:wmx0/i2400m/dl_control

/sys/kernel/debug/wimax:wmx0/wimax_dl_stack

/sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill

/sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset

/sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg

/sys/kernel/debug/wimax:wmx0/wimax_dl_id_table

/sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs



   By reading the file you can obtain the current value of said debug

   level; by writing to it, you can set it.



   To increase the debug level of, for example, the i2400m's generic TX

   engine, just write:



$ echo 3 > /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx



   Increasing numbers yield increasing debug information; for details of

   what is printed and the available levels, check the source. The code

   uses 0 for disabled and increasing values until 8.



5.2.2. RX and TX statistics



   The i2400m/rx_stats and i2400m/tx_stats provide statistics about the

   data reception/delivery from the device:



$ cat /sys/kernel/debug/wimax:wmx0/i2400m/rx_stats

45 1 3 34 3104 48 480



   The numbers reported are

     * packets/RX-buffer: total, min, max

     * RX-buffers: total RX buffers received, accumulated RX buffer size

       in bytes, min size received, max size received



   Thus, to find the average buffer size received, divide accumulated

   RX-buffer / total RX-buffers.



   To clear the statistics back to 0, write anything to the rx_stats file:



$ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m_rx_stats



   Likewise for TX.



   Note the packets this debug file refers to are not network packet, but

   packets in the sense of the device-specific protocol for communication

   to the host. See drivers/net/wimax/i2400m/tx.c.



5.2.3. Tracing messages received from user space



   To echo messages received from user space into the trace pipe that the

   i2400m driver creates, set the debug file i2400m/trace_msg_from_user to

   1:

     *

$ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m/trace_msg_from_user



5.2.4. Performing a device reset



   By writing a 0, a 1 or a 2 to the file

   /sys/kernel/debug/wimax:wmx0/reset, the driver performs a warm (without

   disconnecting from the bus), cold (disconnecting from the bus) or bus

   (bus specific) reset on the device.



5.2.5. Asking the device to enter power saving mode



   By writing any value to the /sys/kernel/debug/wimax:wmx0 file, the

   device will attempt to enter power saving mode.



6. Troubleshooting



6.1. Driver complains about 'i2400m-fw-usb-1.2.sbcf: request failed'



   If upon connecting the device, the following is output in the kernel

   log:



i2400m_usb 5-4:1.0: fw i2400m-fw-usb-1.3.sbcf: request failed: -2



   This means that the driver cannot locate the firmware file named

   /lib/firmware/i2400m-fw-usb-1.2.sbcf. Check that the file is present in

   the right location.