diff options
Diffstat (limited to 'Documentation')
32 files changed, 1727 insertions, 150 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 06b982affe76..dd10b51b4e65 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -250,6 +250,8 @@ numastat.txt - info on how to read Numa policy hit/miss statistics in sysfs. oops-tracing.txt - how to decode those nasty internal kernel error dump messages. +padata.txt + - An introduction to the "padata" parallel execution API parisc/ - directory with info on using Linux on PA-RISC architecture. parport.txt diff --git a/Documentation/ABI/obsolete/sysfs-bus-usb b/Documentation/ABI/obsolete/sysfs-bus-usb new file mode 100644 index 000000000000..bd096d33fbc7 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-bus-usb @@ -0,0 +1,31 @@ +What: /sys/bus/usb/devices/.../power/level +Date: March 2007 +KernelVersion: 2.6.21 +Contact: Alan Stern <stern@rowland.harvard.edu> +Description: + Each USB device directory will contain a file named + power/level. This file holds a power-level setting for + the device, either "on" or "auto". + + "on" means that the device is not allowed to autosuspend, + although normal suspends for system sleep will still + be honored. "auto" means the device will autosuspend + and autoresume in the usual manner, according to the + capabilities of its driver. + + During normal use, devices should be left in the "auto" + level. The "on" level is meant for administrative uses. + If you want to suspend a device immediately but leave it + free to wake up in response to I/O requests, you should + write "0" to power/autosuspend. + + Device not capable of proper suspend and resume should be + left in the "on" level. Although the USB spec requires + devices to support suspend/resume, many of them do not. + In fact so many don't that by default, the USB core + initializes all non-hub devices in the "on" level. Some + drivers may change this setting when they are bound. + + This file is deprecated and will be removed after 2010. + Use the power/control file instead; it does exactly the + same thing. diff --git a/Documentation/ABI/obsolete/sysfs-class-rfkill b/Documentation/ABI/obsolete/sysfs-class-rfkill new file mode 100644 index 000000000000..4201d5b05515 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-class-rfkill @@ -0,0 +1,29 @@ +rfkill - radio frequency (RF) connector kill switch support + +For details to this subsystem look at Documentation/rfkill.txt. + +What: /sys/class/rfkill/rfkill[0-9]+/state +Date: 09-Jul-2007 +KernelVersion v2.6.22 +Contact: linux-wireless@vger.kernel.org +Description: Current state of the transmitter. + This file is deprecated and sheduled to be removed in 2014, + because its not possible to express the 'soft and hard block' + state of the rfkill driver. +Values: A numeric value. + 0: RFKILL_STATE_SOFT_BLOCKED + transmitter is turned off by software + 1: RFKILL_STATE_UNBLOCKED + transmitter is (potentially) active + 2: RFKILL_STATE_HARD_BLOCKED + transmitter is forced off by something outside of + the driver's control. + +What: /sys/class/rfkill/rfkill[0-9]+/claim +Date: 09-Jul-2007 +KernelVersion v2.6.22 +Contact: linux-wireless@vger.kernel.org +Description: This file is deprecated because there no longer is a way to + claim just control over a single rfkill instance. + This file is scheduled to be removed in 2012. +Values: 0: Kernel handles events diff --git a/Documentation/ABI/stable/sysfs-class-rfkill b/Documentation/ABI/stable/sysfs-class-rfkill new file mode 100644 index 000000000000..097f522c33bb --- /dev/null +++ b/Documentation/ABI/stable/sysfs-class-rfkill @@ -0,0 +1,67 @@ +rfkill - radio frequency (RF) connector kill switch support + +For details to this subsystem look at Documentation/rfkill.txt. + +For the deprecated /sys/class/rfkill/*/state and +/sys/class/rfkill/*/claim knobs of this interface look in +Documentation/ABI/obsolete/sysfs-class-rfkill. + +What: /sys/class/rfkill +Date: 09-Jul-2007 +KernelVersion: v2.6.22 +Contact: linux-wireless@vger.kernel.org, +Description: The rfkill class subsystem folder. + Each registered rfkill driver is represented by an rfkillX + subfolder (X being an integer > 0). + + +What: /sys/class/rfkill/rfkill[0-9]+/name +Date: 09-Jul-2007 +KernelVersion v2.6.22 +Contact: linux-wireless@vger.kernel.org +Description: Name assigned by driver to this key (interface or driver name). +Values: arbitrary string. + + +What: /sys/class/rfkill/rfkill[0-9]+/type +Date: 09-Jul-2007 +KernelVersion v2.6.22 +Contact: linux-wireless@vger.kernel.org +Description: Driver type string ("wlan", "bluetooth", etc). +Values: See include/linux/rfkill.h. + + +What: /sys/class/rfkill/rfkill[0-9]+/persistent +Date: 09-Jul-2007 +KernelVersion v2.6.22 +Contact: linux-wireless@vger.kernel.org +Description: Whether the soft blocked state is initialised from non-volatile + storage at startup. +Values: A numeric value. + 0: false + 1: true + + +What: /sys/class/rfkill/rfkill[0-9]+/hard +Date: 12-March-2010 +KernelVersion v2.6.34 +Contact: linux-wireless@vger.kernel.org +Description: Current hardblock state. This file is read only. +Values: A numeric value. + 0: inactive + The transmitter is (potentially) active. + 1: active + The transmitter is forced off by something outside of + the driver's control. + + +What: /sys/class/rfkill/rfkill[0-9]+/soft +Date: 12-March-2010 +KernelVersion v2.6.34 +Contact: linux-wireless@vger.kernel.org +Description: Current softblock state. This file is read and write. +Values: A numeric value. + 0: inactive + The transmitter is (potentially) active. + 1: active + The transmitter is turned off by software. diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index bcebb9eaedce..294aa864a60a 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -14,34 +14,6 @@ Description: The autosuspend delay for newly-created devices is set to the value of the usbcore.autosuspend module parameter. -What: /sys/bus/usb/devices/.../power/level -Date: March 2007 -KernelVersion: 2.6.21 -Contact: Alan Stern <stern@rowland.harvard.edu> -Description: - Each USB device directory will contain a file named - power/level. This file holds a power-level setting for - the device, either "on" or "auto". - - "on" means that the device is not allowed to autosuspend, - although normal suspends for system sleep will still - be honored. "auto" means the device will autosuspend - and autoresume in the usual manner, according to the - capabilities of its driver. - - During normal use, devices should be left in the "auto" - level. The "on" level is meant for administrative uses. - If you want to suspend a device immediately but leave it - free to wake up in response to I/O requests, you should - write "0" to power/autosuspend. - - Device not capable of proper suspend and resume should be - left in the "on" level. Although the USB spec requires - devices to support suspend/resume, many of them do not. - In fact so many don't that by default, the USB core - initializes all non-hub devices in the "on" level. Some - drivers may change this setting when they are bound. - What: /sys/bus/usb/devices/.../power/persist Date: May 2007 KernelVersion: 2.6.23 diff --git a/Documentation/ABI/testing/sysfs-devices-platform-_UDC_-gadget b/Documentation/ABI/testing/sysfs-devices-platform-_UDC_-gadget new file mode 100644 index 000000000000..34034027b13c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-_UDC_-gadget @@ -0,0 +1,9 @@ +What: /sys/devices/platform/_UDC_/gadget/suspended +Date: April 2010 +Contact: Fabien Chouteau <fabien.chouteau@barco.com> +Description: + Show the suspend state of an USB composite gadget. + 1 -> suspended + 0 -> resumed + + (_UDC_ is the name of the USB Device Controller driver) diff --git a/Documentation/ABI/testing/sysfs-driver-hid-picolcd b/Documentation/ABI/testing/sysfs-driver-hid-picolcd new file mode 100644 index 000000000000..08579e7e1e89 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-picolcd @@ -0,0 +1,43 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/operation_mode +Date: March 2010 +Contact: Bruno Prémont <bonbons@linux-vserver.org> +Description: Make it possible to switch the PicoLCD device between LCD + (firmware) and bootloader (flasher) operation modes. + + Reading: returns list of available modes, the active mode being + enclosed in brackets ('[' and ']') + + Writing: causes operation mode switch. Permitted values are + the non-active mode names listed when read. + + Note: when switching mode the current PicoLCD HID device gets + disconnected and reconnects after above delay (see attribute + operation_mode_delay for its value). + + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/operation_mode_delay +Date: April 2010 +Contact: Bruno Prémont <bonbons@linux-vserver.org> +Description: Delay PicoLCD waits before restarting in new mode when + operation_mode has changed. + + Reading/Writing: It is expressed in ms and permitted range is + 0..30000ms. + + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fb_update_rate +Date: March 2010 +Contact: Bruno Prémont <bonbons@linux-vserver.org> +Description: Make it possible to adjust defio refresh rate. + + Reading: returns list of available refresh rates (expressed in Hz), + the active refresh rate being enclosed in brackets ('[' and ']') + + Writing: accepts new refresh rate expressed in integer Hz + within permitted rates. + + Note: As device can barely do 2 complete refreshes a second + it only makes sense to adjust this value if only one or two + tiles get changed and it's not appropriate to expect the application + to flush it's tiny changes explicitely at higher than default rate. + diff --git a/Documentation/ABI/testing/sysfs-driver-hid-prodikeys b/Documentation/ABI/testing/sysfs-driver-hid-prodikeys new file mode 100644 index 000000000000..05d988c29a83 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-prodikeys @@ -0,0 +1,29 @@ +What: /sys/bus/hid/drivers/prodikeys/.../channel +Date: April 2010 +KernelVersion: 2.6.34 +Contact: Don Prince <dhprince.devel@yahoo.co.uk> +Description: + Allows control (via software) the midi channel to which + that the pc-midi keyboard will output.midi data. + Range: 0..15 + Type: Read/write +What: /sys/bus/hid/drivers/prodikeys/.../sustain +Date: April 2010 +KernelVersion: 2.6.34 +Contact: Don Prince <dhprince.devel@yahoo.co.uk> +Description: + Allows control (via software) the sustain duration of a + note held by the pc-midi driver. + 0 means sustain mode is disabled. + Range: 0..5000 (milliseconds) + Type: Read/write +What: /sys/bus/hid/drivers/prodikeys/.../octave +Date: April 2010 +KernelVersion: 2.6.34 +Contact: Don Prince <dhprince.devel@yahoo.co.uk> +Description: + Controls the octave shift modifier in the pc-midi driver. + The octave can be shifted via software up/down 2 octaves. + 0 means the no ocatve shift. + Range: -2..2 (minus 2 to plus 2) + Type: Read/Write diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone new file mode 100644 index 000000000000..88340a23ce91 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone @@ -0,0 +1,111 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_dpi +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: It is possible to switch the dpi setting of the mouse with the + press of a button. + When read, this file returns the raw number of the actual dpi + setting reported by the mouse. This number has to be further + processed to receive the real dpi value. + + VALUE DPI + 1 800 + 2 1200 + 3 1600 + 4 2000 + 5 2400 + 6 3200 + + This file is readonly. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns the number of the actual profile. + This file is readonly. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns the raw integer version number of the + firmware reported by the mouse. Using the integer value eases + further usage in other programs. To receive the real version + number the decimal point has to be shifted 2 positions to the + left. E.g. a returned value of 138 means 1.38 + This file is readonly. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/kone_driver_version +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns the driver version. + The format of the string is "v<major>.<minor>.<patchlevel>". + This attribute is used by the userland tools to find the sysfs- + paths of installed kone-mice and determine the capabilites of + the driver. Versions of this driver for old kernels replace + usbhid instead of generic-usb. The way to scan for this file + has been chosen to provide a consistent way for all supported + kernel versions. + This file is readonly. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5] +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile holds informations like button + mappings, sensitivity, the colors of the 5 leds and light + effects. + When read, these files return the respective profile. The + returned data is 975 bytes in size. + When written, this file lets one write the respective profile + data back to the mouse. The data has to be 975 bytes long. + The mouse will reject invalid data, whereas the profile number + stored in the profile doesn't need to fit the number of the + store. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns the settings stored in the mouse. + The size of the data is 36 bytes and holds information like the + startup_profile, tcu state and calibration_data. + When written, this file lets write settings back to the mouse. + The data has to be 36 bytes long. The mouse will reject invalid + data. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 1 to 5. + When read, this attribute returns the number of the profile + that's active when the mouse is powered on. + When written, this file sets the number of the startup profile + and the mouse activates this profile immediately. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/tcu +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The mouse has a "Tracking Control Unit" which lets the user + calibrate the laser power to fit the mousepad surface. + When read, this file returns the current state of the TCU, + where 0 means off and 1 means on. + Writing 0 in this file will switch the TCU off. + Writing 1 in this file will start the calibration which takes + around 6 seconds to complete and activates the TCU. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/weight +Date: March 2010 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The mouse can be equipped with one of four supplied weights + ranging from 5 to 20 grams which are recognized by the mouse + and its value can be read out. When read, this file returns the + raw value returned by the mouse which eases further processing + in other software. + The values map to the weights as follows: + + VALUE WEIGHT + 0 none + 1 5g + 2 10g + 3 15g + 4 20g + + This file is readonly. diff --git a/Documentation/ABI/testing/sysfs-wacom b/Documentation/ABI/testing/sysfs-wacom new file mode 100644 index 000000000000..1517976e25c4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-wacom @@ -0,0 +1,10 @@ +What: /sys/class/hidraw/hidraw*/device/speed +Date: April 2010 +Kernel Version: 2.6.35 +Contact: linux-bluetooth@vger.kernel.org +Description: + The /sys/class/hidraw/hidraw*/device/speed file controls + reporting speed of wacom bluetooth tablet. Reading from + this file returns 1 if tablet reports in high speed mode + or 0 otherwise. Writing to this file one of these values + switches reporting speed. diff --git a/Documentation/Changes b/Documentation/Changes index f08b313cd235..eca9f6e6fbe6 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -49,7 +49,7 @@ o oprofile 0.9 # oprofiled --version o udev 081 # udevinfo -V o grub 0.93 # grub --version o mcelog 0.6 -o iptables 1.4.1 # iptables -V +o iptables 1.4.2 # iptables -V Kernel compilation diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl index eeff19ca831b..bd97a13fa5ae 100644 --- a/Documentation/DocBook/writing_usb_driver.tmpl +++ b/Documentation/DocBook/writing_usb_driver.tmpl @@ -342,7 +342,7 @@ static inline void skel_delete (struct usb_skel *dev) { kfree (dev->bulk_in_buffer); if (dev->bulk_out_buffer != NULL) - usb_buffer_free (dev->udev, dev->bulk_out_size, + usb_free_coherent (dev->udev, dev->bulk_out_size, dev->bulk_out_buffer, dev->write_urb->transfer_dma); usb_free_urb (dev->write_urb); diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index e7965f4a385a..a86152ae2f6f 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -241,16 +241,6 @@ Who: Thomas Gleixner <tglx@linutronix.de> --------------------------- -What (Why): - - xt_recent: the old ipt_recent proc dir - (superseded by /proc/net/xt_recent) - -When: January 2009 or Linux 2.7.0, whichever comes first -Why: Superseded by newer revisions or modules -Who: Jan Engelhardt <jengelh@computergmbh.de> - ---------------------------- - What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib When: February 2010 Why: All callers should use explicit gpio_request()/gpio_free(). @@ -520,6 +510,24 @@ Who: Hans de Goede <hdegoede@redhat.com> ---------------------------- +What: sysfs-class-rfkill state file +When: Feb 2014 +Files: net/rfkill/core.c +Why: Documented as obsolete since Feb 2010. This file is limited to 3 + states while the rfkill drivers can have 4 states. +Who: anybody or Florian Mickler <florian@mickler.org> + +---------------------------- + +What: sysfs-class-rfkill claim file +When: Feb 2012 +Files: net/rfkill/core.c +Why: It is not possible to claim an rfkill driver since 2007. This is + Documented as obsolete since Feb 2010. +Who: anybody or Florian Mickler <florian@mickler.org> + +---------------------------- + What: capifs When: February 2011 Files: drivers/isdn/capi/capifs.* @@ -579,6 +587,35 @@ Who: Len Brown <len.brown@intel.com> ---------------------------- +What: iwlwifi 50XX module parameters +When: 2.6.40 +Why: The "..50" modules parameters were used to configure 5000 series and + up devices; different set of module parameters also available for 4965 + with same functionalities. Consolidate both set into single place + in drivers/net/wireless/iwlwifi/iwl-agn.c + +Who: Wey-Yi Guy <wey-yi.w.guy@intel.com> + +---------------------------- + +What: iwl4965 alias support +When: 2.6.40 +Why: Internal alias support has been present in module-init-tools for some + time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed + with no impact. + +Who: Wey-Yi Guy <wey-yi.w.guy@intel.com> + +--------------------------- + +What: xt_NOTRACK +Files: net/netfilter/xt_NOTRACK.c +When: April 2011 +Why: Superseded by xt_CT +Who: Netfilter developer team <netfilter-devel@vger.kernel.org> + +--------------------------- + What: video4linux /dev/vtx teletext API support When: 2.6.35 Files: drivers/media/video/saa5246a.c drivers/media/video/saa5249.c diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 867c5b50cb42..272f80d5f966 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -59,8 +59,19 @@ commit=nrsec (*) Ext3 can be told to sync all its data and metadata Setting it to very large values will improve performance. -barrier=1 This enables/disables barriers. barrier=0 disables - it, barrier=1 enables it. +barrier=<0(*)|1> This enables/disables the use of write barriers in +barrier the jbd code. barrier=0 disables, barrier=1 enables. +nobarrier (*) This also requires an IO stack which can support + barriers, and if jbd gets an error on a barrier + write, it will disable again with a warning. + Write barriers enforce proper on-disk ordering + of journal commits, making volatile disk write caches + safe to use, at some performance penalty. If + your disks are battery-backed in one way or another, + disabling barriers may safely improve performance. + The mount options "barrier" and "nobarrier" can + also be used to enable or disable barriers, for + consistency with other ext3 mount options. orlov (*) This enables the new Orlov block allocator. It is enabled by default. diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt index 5e3ab8f3beff..0b59c0200912 100644 --- a/Documentation/filesystems/gfs2.txt +++ b/Documentation/filesystems/gfs2.txt @@ -1,7 +1,7 @@ Global File System ------------------ -http://sources.redhat.com/cluster/ +http://sources.redhat.com/cluster/wiki/ GFS is a cluster file system. It allows a cluster of computers to simultaneously use a block device that is shared between them (with FC, @@ -36,11 +36,11 @@ GFS2 is not on-disk compatible with previous versions of GFS, but it is pretty close. The following man pages can be found at the URL above: - fsck.gfs2 to repair a filesystem - gfs2_grow to expand a filesystem online - gfs2_jadd to add journals to a filesystem online - gfs2_tool to manipulate, examine and tune a filesystem + fsck.gfs2 to repair a filesystem + gfs2_grow to expand a filesystem online + gfs2_jadd to add journals to a filesystem online + gfs2_tool to manipulate, examine and tune a filesystem gfs2_quota to examine and change quota values in a filesystem gfs2_convert to convert a gfs filesystem to gfs2 in-place mount.gfs2 to help mount(8) mount a filesystem - mkfs.gfs2 to make a filesystem + mkfs.gfs2 to make a filesystem diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index cf6d0d85ca82..d3e7673995eb 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt @@ -50,8 +50,8 @@ NILFS2 supports the following mount options: (*) == default nobarrier Disables barriers. -errors=continue(*) Keep going on a filesystem error. -errors=remount-ro Remount the filesystem read-only on an error. +errors=continue Keep going on a filesystem error. +errors=remount-ro(*) Remount the filesystem read-only on an error. errors=panic Panic and halt the machine if an error occurs. cp=n Specify the checkpoint-number of the snapshot to be mounted. Checkpoints and snapshots are listed by lscp diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt index c58b9f5ba002..1f7ae144f6d8 100644 --- a/Documentation/filesystems/ocfs2.txt +++ b/Documentation/filesystems/ocfs2.txt @@ -80,3 +80,10 @@ user_xattr (*) Enables Extended User Attributes. nouser_xattr Disables Extended User Attributes. acl Enables POSIX Access Control Lists support. noacl (*) Disables POSIX Access Control Lists support. +resv_level=2 (*) Set how agressive allocation reservations will be. + Valid values are between 0 (reservations off) to 8 + (maximum space for reservations). +dir_resv_level= (*) By default, directory reservations will scale with file + reservations - users should rarely need to change this + value. If allocation reservations are turned off, this + option will have no effect. diff --git a/Documentation/filesystems/sysfs-tagging.txt b/Documentation/filesystems/sysfs-tagging.txt new file mode 100644 index 000000000000..caaaf1266d8f --- /dev/null +++ b/Documentation/filesystems/sysfs-tagging.txt @@ -0,0 +1,42 @@ +Sysfs tagging +------------- + +(Taken almost verbatim from Eric Biederman's netns tagging patch +commit msg) + +The problem. Network devices show up in sysfs and with the network +namespace active multiple devices with the same name can show up in +the same directory, ouch! + +To avoid that problem and allow existing applications in network +namespaces to see the same interface that is currently presented in +sysfs, sysfs now has tagging directory support. + +By using the network namespace pointers as tags to separate out the +the sysfs directory entries we ensure that we don't have conflicts +in the directories and applications only see a limited set of +the network devices. + +Each sysfs directory entry may be tagged with zero or one +namespaces. A sysfs_dirent is augmented with a void *s_ns. If a +directory entry is tagged, then sysfs_dirent->s_flags will have a +flag between KOBJ_NS_TYPE_NONE and KOBJ_NS_TYPES, and s_ns will +point to the namespace to which it belongs. + +Each sysfs superblock's sysfs_super_info contains an array void +*ns[KOBJ_NS_TYPES]. When a a task in a tagging namespace +kobj_nstype first mounts sysfs, a new superblock is created. It +will be differentiated from other sysfs mounts by having its +s_fs_info->ns[kobj_nstype] set to the new namespace. Note that +through bind mounting and mounts propagation, a task can easily view +the contents of other namespaces' sysfs mounts. Therefore, when a +namespace exits, it will call kobj_ns_exit() to invalidate any +sysfs_dirent->s_ns pointers pointing to it. + +Users of this interface: +- define a type in the kobj_ns_type enumeration. +- call kobj_ns_type_register() with its kobj_ns_type_operations which has + - current_ns() which returns current's namespace + - netlink_ns() which returns a socket's namespace + - initial_ns() which returns the initial namesapce +- call kobj_ns_exit() when an individual tag is no longer valid diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index e1bb5b261693..e307914a3eda 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -27,7 +27,13 @@ Authors: Module Parameters ----------------- -None. +* disable_features (bit vector) +Disable selected features normally supported by the device. This makes it +possible to work around possible driver or hardware bugs if the feature in +question doesn't work as intended for whatever reason. Bit values: + 1 disable SMBus PEC + 2 disable the block buffer + 8 disable the I2C block read functionality Description diff --git a/Documentation/networking/caif/Linux-CAIF.txt b/Documentation/networking/caif/Linux-CAIF.txt new file mode 100644 index 000000000000..7fe7a9a33a4f --- /dev/null +++ b/Documentation/networking/caif/Linux-CAIF.txt @@ -0,0 +1,212 @@ +Linux CAIF +=========== +copyright (C) ST-Ericsson AB 2010 +Author: Sjur Brendeland/ sjur.brandeland@stericsson.com +License terms: GNU General Public License (GPL) version 2 + + +Introduction +------------ +CAIF is a MUX protocol used by ST-Ericsson cellular modems for +communication between Modem and host. The host processes can open virtual AT +channels, initiate GPRS Data connections, Video channels and Utility Channels. +The Utility Channels are general purpose pipes between modem and host. + +ST-Ericsson modems support a number of transports between modem +and host. Currently, UART and Loopback are available for Linux. + + +Architecture: +------------ +The implementation of CAIF is divided into: +* CAIF Socket Layer, Kernel API, and Net Device. +* CAIF Core Protocol Implementation +* CAIF Link Layer, implemented as NET devices. + + + RTNL + ! + ! +------+ +------+ +------+ + ! +------+! +------+! +------+! + ! ! Sock !! !Kernel!! ! Net !! + ! ! API !+ ! API !+ ! Dev !+ <- CAIF Client APIs + ! +------+ +------! +------+ + ! ! ! ! + ! +----------!----------+ + ! +------+ <- CAIF Protocol Implementation + +-------> ! CAIF ! + ! Core ! + +------+ + +--------!--------+ + ! ! + +------+ +-----+ + ! ! ! TTY ! <- Link Layer (Net Devices) + +------+ +-----+ + + +Using the Kernel API +---------------------- +The Kernel API is used for accessing CAIF channels from the +kernel. +The user of the API has to implement two callbacks for receive +and control. +The receive callback gives a CAIF packet as a SKB. The control +callback will +notify of channel initialization complete, and flow-on/flow- +off. + + + struct caif_device caif_dev = { + .caif_config = { + .name = "MYDEV" + .type = CAIF_CHTY_AT + } + .receive_cb = my_receive, + .control_cb = my_control, + }; + caif_add_device(&caif_dev); + caif_transmit(&caif_dev, skb); + +See the caif_kernel.h for details about the CAIF kernel API. + + +I M P L E M E N T A T I O N +=========================== +=========================== + +CAIF Core Protocol Layer +========================================= + +CAIF Core layer implements the CAIF protocol as defined by ST-Ericsson. +It implements the CAIF protocol stack in a layered approach, where +each layer described in the specification is implemented as a separate layer. +The architecture is inspired by the design patterns "Protocol Layer" and +"Protocol Packet". + +== CAIF structure == +The Core CAIF implementation contains: + - Simple implementation of CAIF. + - Layered architecture (a la Streams), each layer in the CAIF + specification is implemented in a separate c-file. + - Clients must implement PHY layer to access physical HW + with receive and transmit functions. + - Clients must call configuration function to add PHY layer. + - Clients must implement CAIF layer to consume/produce + CAIF payload with receive and transmit functions. + - Clients must call configuration function to add and connect the + Client layer. + - When receiving / transmitting CAIF Packets (cfpkt), ownership is passed + to the called function (except for framing layers' receive functions + or if a transmit function returns an error, in which case the caller + must free the packet). + +Layered Architecture +-------------------- +The CAIF protocol can be divided into two parts: Support functions and Protocol +Implementation. The support functions include: + + - CFPKT CAIF Packet. Implementation of CAIF Protocol Packet. The + CAIF Packet has functions for creating, destroying and adding content + and for adding/extracting header and trailers to protocol packets. + + - CFLST CAIF list implementation. + + - CFGLUE CAIF Glue. Contains OS Specifics, such as memory + allocation, endianness, etc. + +The CAIF Protocol implementation contains: + + - CFCNFG CAIF Configuration layer. Configures the CAIF Protocol + Stack and provides a Client interface for adding Link-Layer and + Driver interfaces on top of the CAIF Stack. + + - CFCTRL CAIF Control layer. Encodes and Decodes control messages + such as enumeration and channel setup. Also matches request and + response messages. + + - CFSERVL General CAIF Service Layer functionality; handles flow + control and remote shutdown requests. + + - CFVEI CAIF VEI layer. Handles CAIF AT Channels on VEI (Virtual + External Interface). This layer encodes/decodes VEI frames. + + - CFDGML CAIF Datagram layer. Handles CAIF Datagram layer (IP + traffic), encodes/decodes Datagram frames. + + - CFMUX CAIF Mux layer. Handles multiplexing between multiple + physical bearers and multiple channels such as VEI, Datagram, etc. + The MUX keeps track of the existing CAIF Channels and + Physical Instances and selects the apropriate instance based + on Channel-Id and Physical-ID. + + - CFFRML CAIF Framing layer. Handles Framing i.e. Frame length + and frame checksum. + + - CFSERL CAIF Serial layer. Handles concatenation/split of frames + into CAIF Frames with correct length. + + + + +---------+ + | Config | + | CFCNFG | + +---------+ + ! + +---------+ +---------+ +---------+ + | AT | | Control | | Datagram| + | CFVEIL | | CFCTRL | | CFDGML | + +---------+ +---------+ +---------+ + \_____________!______________/ + ! + +---------+ + | MUX | + | | + +---------+ + _____!_____ + / \ + +---------+ +---------+ + | CFFRML | | CFFRML | + | Framing | | Framing | + +---------+ +---------+ + ! ! + +---------+ +---------+ + | | | Serial | + | | | CFSERL | + +---------+ +---------+ + + +In this layered approach the following "rules" apply. + - All layers embed the same structure "struct cflayer" + - A layer does not depend on any other layer's private data. + - Layers are stacked by setting the pointers + layer->up , layer->dn + - In order to send data upwards, each layer should do + layer->up->receive(layer->up, packet); + - In order to send data downwards, each layer should do + layer->dn->transmit(layer->dn, packet); + + +Linux Driver Implementation +=========================== + +Linux GPRS Net Device and CAIF socket are implemented on top of the +CAIF Core protocol. The Net device and CAIF socket have an instance of +'struct cflayer', just like the CAIF Core protocol stack. +Net device and Socket implement the 'receive()' function defined by +'struct cflayer', just like the rest of the CAIF stack. In this way, transmit and +receive of packets is handled as by the rest of the layers: the 'dn->transmit()' +function is called in order to transmit data. + +The layer on top of the CAIF Core implementation is +sometimes referred to as the "Client layer". + + +Configuration of Link Layer +--------------------------- +The Link Layer is implemented as Linux net devices (struct net_device). +Payload handling and registration is done using standard Linux mechanisms. + +The CAIF Protocol relies on a loss-less link layer without implementing +retransmission. This implies that packet drops must not happen. +Therefore a flow-control mechanism is implemented where the physical +interface can initiate flow stop for all CAIF Channels. diff --git a/Documentation/networking/caif/README b/Documentation/networking/caif/README new file mode 100644 index 000000000000..757ccfaa1385 --- /dev/null +++ b/Documentation/networking/caif/README @@ -0,0 +1,109 @@ +Copyright (C) ST-Ericsson AB 2010 +Author: Sjur Brendeland/ sjur.brandeland@stericsson.com +License terms: GNU General Public License (GPL) version 2 +--------------------------------------------------------- + +=== Start === +If you have compiled CAIF for modules do: + +$modprobe crc_ccitt +$modprobe caif +$modprobe caif_socket +$modprobe chnl_net + + +=== Preparing the setup with a STE modem === + +If you are working on integration of CAIF you should make sure +that the kernel is built with module support. + +There are some things that need to be tweaked to get the host TTY correctly +set up to talk to the modem. +Since the CAIF stack is running in the kernel and we want to use the existing +TTY, we are installing our physical serial driver as a line discipline above +the TTY device. + +To achieve this we need to install the N_CAIF ldisc from user space. +The benefit is that we can hook up to any TTY. + +The use of Start-of-frame-extension (STX) must also be set as +module parameter "ser_use_stx". + +Normally Frame Checksum is always used on UART, but this is also provided as a +module parameter "ser_use_fcs". + +$ modprobe caif_serial ser_ttyname=/dev/ttyS0 ser_use_stx=yes +$ ifconfig caif_ttyS0 up + +PLEASE NOTE: There is a limitation in Android shell. + It only accepts one argument to insmod/modprobe! + +=== Trouble shooting === + +There are debugfs parameters provided for serial communication. +/sys/kernel/debug/caif_serial/<tty-name>/ + +* ser_state: Prints the bit-mask status where + - 0x02 means SENDING, this is a transient state. + - 0x10 means FLOW_OFF_SENT, i.e. the previous frame has not been sent + and is blocking further send operation. Flow OFF has been propagated + to all CAIF Channels using this TTY. + +* tty_status: Prints the bit-mask tty status information + - 0x01 - tty->warned is on. + - 0x02 - tty->low_latency is on. + - 0x04 - tty->packed is on. + - 0x08 - tty->flow_stopped is on. + - 0x10 - tty->hw_stopped is on. + - 0x20 - tty->stopped is on. + +* last_tx_msg: Binary blob Prints the last transmitted frame. + This can be printed with + $od --format=x1 /sys/kernel/debug/caif_serial/<tty>/last_rx_msg. + The first two tx messages sent look like this. Note: The initial + byte 02 is start of frame extension (STX) used for re-syncing + upon errors. + + - Enumeration: + 0000000 02 05 00 00 03 01 d2 02 + | | | | | | + STX(1) | | | | + Length(2)| | | + Control Channel(1) + Command:Enumeration(1) + Link-ID(1) + Checksum(2) + - Channel Setup: + 0000000 02 07 00 00 00 21 a1 00 48 df + | | | | | | | | + STX(1) | | | | | | + Length(2)| | | | | + Control Channel(1) + Command:Channel Setup(1) + Channel Type(1) + Priority and Link-ID(1) + Endpoint(1) + Checksum(2) + +* last_rx_msg: Prints the last transmitted frame. + The RX messages for LinkSetup look almost identical but they have the + bit 0x20 set in the command bit, and Channel Setup has added one byte + before Checksum containing Channel ID. + NOTE: Several CAIF Messages might be concatenated. The maximum debug + buffer size is 128 bytes. + +== Error Scenarios: +- last_tx_msg contains channel setup message and last_rx_msg is empty -> + The host seems to be able to send over the UART, at least the CAIF ldisc get + notified that sending is completed. + +- last_tx_msg contains enumeration message and last_rx_msg is empty -> + The host is not able to send the message from UART, the tty has not been + able to complete the transmit operation. + +- if /sys/kernel/debug/caif_serial/<tty>/tty_status is non-zero there + might be problems transmitting over UART. + E.g. host and modem wiring is not correct you will typically see + tty_status = 0x10 (hw_stopped) and ser_state = 0x10 (FLOW_OFF_SENT). + You will probably see the enumeration message in last_tx_message + and empty last_rx_message. diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 8b72c88ba213..d0536b5a4e01 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -588,6 +588,37 @@ ip_local_port_range - 2 INTEGERS (i.e. by default) range 1024-4999 is enough to issue up to 2000 connections per second to systems supporting timestamps. +ip_local_reserved_ports - list of comma separated ranges + Specify the ports which are reserved for known third-party + applications. These ports will not be used by automatic port + assignments (e.g. when calling connect() or bind() with port + number 0). Explicit port allocation behavior is unchanged. + + The format used for both input and output is a comma separated + list of ranges (e.g. "1,2-4,10-10" for ports 1, 2, 3, 4 and + 10). Writing to the file will clear all previously reserved + ports and update the current list with the one given in the + input. + + Note that ip_local_port_range and ip_local_reserved_ports + settings are independent and both are considered by the kernel + when determining which ports are available for automatic port + assignments. + + You can reserve ports which are not in the current + ip_local_port_range, e.g.: + + $ cat /proc/sys/net/ipv4/ip_local_port_range + 32000 61000 + $ cat /proc/sys/net/ipv4/ip_local_reserved_ports + 8080,9148 + + although this is redundant. However such a setting is useful + if later the port range is changed to a value that will + include the reserved ports. + + Default: Empty + ip_nonlocal_bind - BOOLEAN If set, allows processes to bind() to non-local IP addresses, which can be quite useful - but may break some applications. diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt index 63214b280e00..e7bf3979facb 100644 --- a/Documentation/networking/l2tp.txt +++ b/Documentation/networking/l2tp.txt @@ -1,44 +1,95 @@ -This brief document describes how to use the kernel's PPPoL2TP driver -to provide L2TP functionality. L2TP is a protocol that tunnels one or -more PPP sessions over a UDP tunnel. It is commonly used for VPNs +This document describes how to use the kernel's L2TP drivers to +provide L2TP functionality. L2TP is a protocol that tunnels one or +more sessions over an IP tunnel. It is commonly used for VPNs (L2TP/IPSec) and by ISPs to tunnel subscriber PPP sessions over an IP -network infrastructure. +network infrastructure. With L2TPv3, it is also useful as a Layer-2 +tunneling infrastructure. + +Features +======== + +L2TPv2 (PPP over L2TP (UDP tunnels)). +L2TPv3 ethernet pseudowires. +L2TPv3 PPP pseudowires. +L2TPv3 IP encapsulation. +Netlink sockets for L2TPv3 configuration management. + +History +======= + +The original pppol2tp driver was introduced in 2.6.23 and provided +L2TPv2 functionality (rfc2661). L2TPv2 is used to tunnel one or more PPP +sessions over a UDP tunnel. + +L2TPv3 (rfc3931) changes the protocol to allow different frame types +to be passed over an L2TP tunnel by moving the PPP-specific parts of +the protocol out of the core L2TP packet headers. Each frame type is +known as a pseudowire type. Ethernet, PPP, HDLC, Frame Relay and ATM +pseudowires for L2TP are defined in separate RFC standards. Another +change for L2TPv3 is that it can be carried directly over IP with no +UDP header (UDP is optional). It is also possible to create static +unmanaged L2TPv3 tunnels manually without a control protocol +(userspace daemon) to manage them. + +To support L2TPv3, the original pppol2tp driver was split up to +separate the L2TP and PPP functionality. Existing L2TPv2 userspace +apps should be unaffected as the original pppol2tp sockets API is +retained. L2TPv3, however, uses netlink to manage L2TPv3 tunnels and +sessions. Design ====== -The PPPoL2TP driver, drivers/net/pppol2tp.c, provides a mechanism by -which PPP frames carried through an L2TP session are passed through -the kernel's PPP subsystem. The standard PPP daemon, pppd, handles all -PPP interaction with the peer. PPP network interfaces are created for -each local PPP endpoint. - -The L2TP protocol http://www.faqs.org/rfcs/rfc2661.html defines L2TP -control and data frames. L2TP control frames carry messages between -L2TP clients/servers and are used to setup / teardown tunnels and -sessions. An L2TP client or server is implemented in userspace and -will use a regular UDP socket per tunnel. L2TP data frames carry PPP -frames, which may be PPP control or PPP data. The kernel's PPP +The L2TP protocol separates control and data frames. The L2TP kernel +drivers handle only L2TP data frames; control frames are always +handled by userspace. L2TP control frames carry messages between L2TP +clients/servers and are used to setup / teardown tunnels and +sessions. An L2TP client or server is implemented in userspace. + +Each L2TP tunnel is implemented using a UDP or L2TPIP socket; L2TPIP +provides L2TPv3 IP encapsulation (no UDP) and is implemented using a +new l2tpip socket family. The tunnel socket is typically created by +userspace, though for unmanaged L2TPv3 tunnels, the socket can also be +created by the kernel. Each L2TP session (pseudowire) gets a network +interface instance. In the case of PPP, these interfaces are created +indirectly by pppd using a pppol2tp socket. In the case of ethernet, +the netdevice is created upon a netlink request to create an L2TPv3 +ethernet pseudowire. + +For PPP, the PPPoL2TP driver, net/l2tp/l2tp_ppp.c, provides a +mechanism by which PPP frames carried through an L2TP session are +passed through the kernel's PPP subsystem. The standard PPP daemon, +pppd, handles all PPP interaction with the peer. PPP network +interfaces are created for each local PPP endpoint. The kernel's PPP subsystem arranges for PPP control frames to be delivered to pppd, while data frames are forwarded as usual. +For ethernet, the L2TPETH driver, net/l2tp/l2tp_eth.c, implements a +netdevice driver, managing virtual ethernet devices, one per +pseudowire. These interfaces can be managed using standard Linux tools +such as "ip" and "ifconfig". If only IP frames are passed over the +tunnel, the interface can be given an IP addresses of itself and its +peer. If non-IP frames are to be passed over the tunnel, the interface +can be added to a bridge using brctl. All L2TP datapath protocol +functions are handled by the L2TP core driver. + Each tunnel and session within a tunnel is assigned a unique tunnel_id and session_id. These ids are carried in the L2TP header of every -control and data packet. The pppol2tp driver uses them to lookup -internal tunnel and/or session contexts. Zero tunnel / session ids are -treated specially - zero ids are never assigned to tunnels or sessions -in the network. In the driver, the tunnel context keeps a pointer to -the tunnel UDP socket. The session context keeps a pointer to the -PPPoL2TP socket, as well as other data that lets the driver interface -to the kernel PPP subsystem. - -Note that the pppol2tp kernel driver handles only L2TP data frames; -L2TP control frames are simply passed up to userspace in the UDP -tunnel socket. The kernel handles all datapath aspects of the -protocol, including data packet resequencing (if enabled). - -There are a number of requirements on the userspace L2TP daemon in -order to use the pppol2tp driver. +control and data packet. (Actually, in L2TPv3, the tunnel_id isn't +present in data frames - it is inferred from the IP connection on +which the packet was received.) The L2TP driver uses the ids to lookup +internal tunnel and/or session contexts to determine how to handle the +packet. Zero tunnel / session ids are treated specially - zero ids are +never assigned to tunnels or sessions in the network. In the driver, +the tunnel context keeps a reference to the tunnel UDP or L2TPIP +socket. The session context holds data that lets the driver interface +to the kernel's network frame type subsystems, i.e. PPP, ethernet. + +Userspace Programming +===================== + +For L2TPv2, there are a number of requirements on the userspace L2TP +daemon in order to use the pppol2tp driver. 1. Use a UDP socket per tunnel. @@ -86,6 +137,35 @@ In addition to the standard PPP ioctls, a PPPIOCGL2TPSTATS is provided to retrieve tunnel and session statistics from the kernel using the PPPoX socket of the appropriate tunnel or session. +For L2TPv3, userspace must use the netlink API defined in +include/linux/l2tp.h to manage tunnel and session contexts. The +general procedure to create a new L2TP tunnel with one session is:- + +1. Open a GENL socket using L2TP_GENL_NAME for configuring the kernel + using netlink. + +2. Create a UDP or L2TPIP socket for the tunnel. + +3. Create a new L2TP tunnel using a L2TP_CMD_TUNNEL_CREATE + request. Set attributes according to desired tunnel parameters, + referencing the UDP or L2TPIP socket created in the previous step. + +4. Create a new L2TP session in the tunnel using a + L2TP_CMD_SESSION_CREATE request. + +The tunnel and all of its sessions are closed when the tunnel socket +is closed. The netlink API may also be used to delete sessions and +tunnels. Configuration and status info may be set or read using netlink. + +The L2TP driver also supports static (unmanaged) L2TPv3 tunnels. These +are where there is no L2TP control message exchange with the peer to +setup the tunnel; the tunnel is configured manually at each end of the +tunnel. There is no need for an L2TP userspace application in this +case -- the tunnel socket is created by the kernel and configured +using parameters sent in the L2TP_CMD_TUNNEL_CREATE netlink +request. The "ip" utility of iproute2 has commands for managing static +L2TPv3 tunnels; do "ip l2tp help" for more information. + Debugging ========= @@ -102,6 +182,69 @@ PPPOL2TP_MSG_CONTROL userspace - kernel interface PPPOL2TP_MSG_SEQ sequence numbers handling PPPOL2TP_MSG_DATA data packets +If enabled, files under a l2tp debugfs directory can be used to dump +kernel state about L2TP tunnels and sessions. To access it, the +debugfs filesystem must first be mounted. + +# mount -t debugfs debugfs /debug + +Files under the l2tp directory can then be accessed. + +# cat /debug/l2tp/tunnels + +The debugfs files should not be used by applications to obtain L2TP +state information because the file format is subject to change. It is +implemented to provide extra debug information to help diagnose +problems.) Users should use the netlink API. + +/proc/net/pppol2tp is also provided for backwards compaibility with +the original pppol2tp driver. It lists information about L2TPv2 +tunnels and sessions only. Its use is discouraged. + +Unmanaged L2TPv3 Tunnels +======================== + +Some commercial L2TP products support unmanaged L2TPv3 ethernet +tunnels, where there is no L2TP control protocol; tunnels are +configured at each side manually. New commands are available in +iproute2's ip utility to support this. + +To create an L2TPv3 ethernet pseudowire between local host 192.168.1.1 +and peer 192.168.1.2, using IP addresses 10.5.1.1 and 10.5.1.2 for the +tunnel endpoints:- + +# modprobe l2tp_eth +# modprobe l2tp_netlink + +# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \ + udp_dport 5000 encap udp local 192.168.1.1 remote 192.168.1.2 +# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1 +# ifconfig -a +# ip addr add 10.5.1.2/32 peer 10.5.1.1/32 dev l2tpeth0 +# ifconfig l2tpeth0 up + +Choose IP addresses to be the address of a local IP interface and that +of the remote system. The IP addresses of the l2tpeth0 interface can be +anything suitable. + +Repeat the above at the peer, with ports, tunnel/session ids and IP +addresses reversed. The tunnel and session IDs can be any non-zero +32-bit number, but the values must be reversed at the peer. + +Host 1 Host2 +udp_sport=5000 udp_sport=5001 +udp_dport=5001 udp_dport=5000 +tunnel_id=42 tunnel_id=45 +peer_tunnel_id=45 peer_tunnel_id=42 +session_id=128 session_id=5196755 +peer_session_id=5196755 peer_session_id=128 + +When done at both ends of the tunnel, it should be possible to send +data over the network. e.g. + +# ping 10.5.1.1 + + Sample Userspace Code ===================== @@ -158,12 +301,48 @@ Sample Userspace Code } return 0; +Internal Implementation +======================= + +The driver keeps a struct l2tp_tunnel context per L2TP tunnel and a +struct l2tp_session context for each session. The l2tp_tunnel is +always associated with a UDP or L2TP/IP socket and keeps a list of +sessions in the tunnel. The l2tp_session context keeps kernel state +about the session. It has private data which is used for data specific +to the session type. With L2TPv2, the session always carried PPP +traffic. With L2TPv3, the session can also carry ethernet frames +(ethernet pseudowire) or other data types such as ATM, HDLC or Frame +Relay. + +When a tunnel is first opened, the reference count on the socket is +increased using sock_hold(). This ensures that the kernel socket +cannot be removed while L2TP's data structures reference it. + +Some L2TP sessions also have a socket (PPP pseudowires) while others +do not (ethernet pseudowires). We can't use the socket reference count +as the reference count for session contexts. The L2TP implementation +therefore has its own internal reference counts on the session +contexts. + +To Do +===== + +Add L2TP tunnel switching support. This would route tunneled traffic +from one L2TP tunnel into another. Specified in +http://tools.ietf.org/html/draft-ietf-l2tpext-tunnel-switching-08 + +Add L2TPv3 VLAN pseudowire support. + +Add L2TPv3 IP pseudowire support. + +Add L2TPv3 ATM pseudowire support. + Miscellaneous -============ +============= -The PPPoL2TP driver was developed as part of the OpenL2TP project by +The L2TP drivers were developed as part of the OpenL2TP project by Katalix Systems Ltd. OpenL2TP is a full-featured L2TP client / server, designed from the ground up to have the L2TP datapath in the kernel. The project also implemented the pppol2tp plugin for pppd which allows pppd to use the kernel driver. Details can be found at -http://openl2tp.sourceforge.net. +http://www.openl2tp.org. diff --git a/Documentation/networking/x25-iface.txt b/Documentation/networking/x25-iface.txt index 975cc87ebdd1..78f662ee0622 100644 --- a/Documentation/networking/x25-iface.txt +++ b/Documentation/networking/x25-iface.txt @@ -20,23 +20,23 @@ the rest of the skbuff, if any more information does exist. Packet Layer to Device Driver ----------------------------- -First Byte = 0x00 +First Byte = 0x00 (X25_IFACE_DATA) This indicates that the rest of the skbuff contains data to be transmitted over the LAPB link. The LAPB link should already exist before any data is passed down. -First Byte = 0x01 +First Byte = 0x01 (X25_IFACE_CONNECT) Establish the LAPB link. If the link is already established then the connect confirmation message should be returned as soon as possible. -First Byte = 0x02 +First Byte = 0x02 (X25_IFACE_DISCONNECT) Terminate the LAPB link. If it is already disconnected then the disconnect confirmation message should be returned as soon as possible. -First Byte = 0x03 +First Byte = 0x03 (X25_IFACE_PARAMS) LAPB parameters. To be defined. @@ -44,22 +44,22 @@ LAPB parameters. To be defined. Device Driver to Packet Layer ----------------------------- -First Byte = 0x00 +First Byte = 0x00 (X25_IFACE_DATA) This indicates that the rest of the skbuff contains data that has been received over the LAPB link. -First Byte = 0x01 +First Byte = 0x01 (X25_IFACE_CONNECT) LAPB link has been established. The same message is used for both a LAPB link connect_confirmation and a connect_indication. -First Byte = 0x02 +First Byte = 0x02 (X25_IFACE_DISCONNECT) LAPB link has been terminated. This same message is used for both a LAPB link disconnect_confirmation and a disconnect_indication. -First Byte = 0x03 +First Byte = 0x03 (X25_IFACE_PARAMS) LAPB parameters. To be defined. diff --git a/Documentation/padata.txt b/Documentation/padata.txt new file mode 100644 index 000000000000..269d7d0d8335 --- /dev/null +++ b/Documentation/padata.txt @@ -0,0 +1,107 @@ +The padata parallel execution mechanism +Last updated for 2.6.34 + +Padata is a mechanism by which the kernel can farm work out to be done in +parallel on multiple CPUs while retaining the ordering of tasks. It was +developed for use with the IPsec code, which needs to be able to perform +encryption and decryption on large numbers of packets without reordering +those packets. The crypto developers made a point of writing padata in a +sufficiently general fashion that it could be put to other uses as well. + +The first step in using padata is to set up a padata_instance structure for +overall control of how tasks are to be run: + + #include <linux/padata.h> + + struct padata_instance *padata_alloc(const struct cpumask *cpumask, + struct workqueue_struct *wq); + +The cpumask describes which processors will be used to execute work +submitted to this instance. The workqueue wq is where the work will +actually be done; it should be a multithreaded queue, naturally. + +There are functions for enabling and disabling the instance: + + void padata_start(struct padata_instance *pinst); + void padata_stop(struct padata_instance *pinst); + +These functions literally do nothing beyond setting or clearing the +"padata_start() was called" flag; if that flag is not set, other functions +will refuse to work. + +The list of CPUs to be used can be adjusted with these functions: + + int padata_set_cpumask(struct padata_instance *pinst, + cpumask_var_t cpumask); + int padata_add_cpu(struct padata_instance *pinst, int cpu); + int padata_remove_cpu(struct padata_instance *pinst, int cpu); + +Changing the CPU mask has the look of an expensive operation, though, so it +probably should not be done with great frequency. + +Actually submitting work to the padata instance requires the creation of a +padata_priv structure: + + struct padata_priv { + /* Other stuff here... */ + void (*parallel)(struct padata_priv *padata); + void (*serial)(struct padata_priv *padata); + }; + +This structure will almost certainly be embedded within some larger +structure specific to the work to be done. Most its fields are private to +padata, but the structure should be zeroed at initialization time, and the +parallel() and serial() functions should be provided. Those functions will +be called in the process of getting the work done as we will see +momentarily. + +The submission of work is done with: + + int padata_do_parallel(struct padata_instance *pinst, + struct padata_priv *padata, int cb_cpu); + +The pinst and padata structures must be set up as described above; cb_cpu +specifies which CPU will be used for the final callback when the work is +done; it must be in the current instance's CPU mask. The return value from +padata_do_parallel() is a little strange; zero is an error return +indicating that the caller forgot the padata_start() formalities. -EBUSY +means that somebody, somewhere else is messing with the instance's CPU +mask, while -EINVAL is a complaint about cb_cpu not being in that CPU mask. +If all goes well, this function will return -EINPROGRESS, indicating that +the work is in progress. + +Each task submitted to padata_do_parallel() will, in turn, be passed to +exactly one call to the above-mentioned parallel() function, on one CPU, so +true parallelism is achieved by submitting multiple tasks. Despite the +fact that the workqueue is used to make these calls, parallel() is run with +software interrupts disabled and thus cannot sleep. The parallel() +function gets the padata_priv structure pointer as its lone parameter; +information about the actual work to be done is probably obtained by using +container_of() to find the enclosing structure. + +Note that parallel() has no return value; the padata subsystem assumes that +parallel() will take responsibility for the task from this point. The work +need not be completed during this call, but, if parallel() leaves work +outstanding, it should be prepared to be called again with a new job before +the previous one completes. When a task does complete, parallel() (or +whatever function actually finishes the job) should inform padata of the +fact with a call to: + + void padata_do_serial(struct padata_priv *padata); + +At some point in the future, padata_do_serial() will trigger a call to the +serial() function in the padata_priv structure. That call will happen on +the CPU requested in the initial call to padata_do_parallel(); it, too, is +done through the workqueue, but with local software interrupts disabled. +Note that this call may be deferred for a while since the padata code takes +pains to ensure that tasks are completed in the order in which they were +submitted. + +The one remaining function in the padata API should be called to clean up +when a padata instance is no longer needed: + + void padata_free(struct padata_instance *pinst); + +This function will busy-wait while any remaining tasks are completed, so it +might be best not to call it while there is work outstanding. Shutting +down the workqueue, if necessary, should be done separately. diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index b4860509c319..83668e5dd17f 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt @@ -99,37 +99,15 @@ system. Also, it is possible to switch all rfkill drivers (or all drivers of a specified type) into a state which also updates the default state for hotplugged devices. -After an application opens /dev/rfkill, it can read the current state of -all devices, and afterwards can poll the descriptor for hotplug or state -change events. - -Applications must ignore operations (the "op" field) they do not handle, -this allows the API to be extended in the future. - -Additionally, each rfkill device is registered in sysfs and there has the -following attributes: - - name: Name assigned by driver to this key (interface or driver name). - type: Driver type string ("wlan", "bluetooth", etc). - persistent: Whether the soft blocked state is initialised from - non-volatile storage at startup. - state: Current state of the transmitter - 0: RFKILL_STATE_SOFT_BLOCKED - transmitter is turned off by software - 1: RFKILL_STATE_UNBLOCKED - transmitter is (potentially) active - 2: RFKILL_STATE_HARD_BLOCKED - transmitter is forced off by something outside of - the driver's control. - This file is deprecated because it can only properly show - three of the four possible states, soft-and-hard-blocked is - missing. - claim: 0: Kernel handles events - This file is deprecated because there no longer is a way to - claim just control over a single rfkill instance. - -rfkill devices also issue uevents (with an action of "change"), with the -following environment variables set: +After an application opens /dev/rfkill, it can read the current state of all +devices. Changes can be either obtained by either polling the descriptor for +hotplug or state change events or by listening for uevents emitted by the +rfkill core framework. + +Additionally, each rfkill device is registered in sysfs and emits uevents. + +rfkill devices issue uevents (with an action of "change"), with the following +environment variables set: RFKILL_NAME RFKILL_STATE @@ -137,3 +115,7 @@ RFKILL_TYPE The contents of these variables corresponds to the "name", "state" and "type" sysfs files explained above. + + +For further details consult Documentation/ABI/stable/dev-rfkill and +Documentation/ABI/stable/sysfs-class-rfkill. diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index df38ef046f8d..cbd05ffc606b 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -84,6 +84,16 @@ netdev_max_backlog Maximum number of packets, queued on the INPUT side, when the interface receives packets faster than kernel can process them. +netdev_tstamp_prequeue +---------------------- + +If set to 0, RX packet timestamps can be sampled after RPS processing, when +the target CPU processes packets. It might give some delay on timestamps, but +permit to distribute the load on several cpus. + +If set to 1 (default), timestamps are sampled as soon as possible, before +queueing. + optmem_max ---------- diff --git a/Documentation/usb/bulk-streams.txt b/Documentation/usb/bulk-streams.txt new file mode 100644 index 000000000000..ffc02021863e --- /dev/null +++ b/Documentation/usb/bulk-streams.txt @@ -0,0 +1,78 @@ +Background +========== + +Bulk endpoint streams were added in the USB 3.0 specification. Streams allow a +device driver to overload a bulk endpoint so that multiple transfers can be +queued at once. + +Streams are defined in sections 4.4.6.4 and 8.12.1.4 of the Universal Serial Bus +3.0 specification at http://www.usb.org/developers/docs/ The USB Attached SCSI +Protocol, which uses streams to queue multiple SCSI commands, can be found on +the T10 website (http://t10.org/). + + +Device-side implications +======================== + +Once a buffer has been queued to a stream ring, the device is notified (through +an out-of-band mechanism on another endpoint) that data is ready for that stream +ID. The device then tells the host which "stream" it wants to start. The host +can also initiate a transfer on a stream without the device asking, but the +device can refuse that transfer. Devices can switch between streams at any +time. + + +Driver implications +=================== + +int usb_alloc_streams(struct usb_interface *interface, + struct usb_host_endpoint **eps, unsigned int num_eps, + unsigned int num_streams, gfp_t mem_flags); + +Device drivers will call this API to request that the host controller driver +allocate memory so the driver can use up to num_streams stream IDs. They must +pass an array of usb_host_endpoints that need to be setup with similar stream +IDs. This is to ensure that a UASP driver will be able to use the same stream +ID for the bulk IN and OUT endpoints used in a Bi-directional command sequence. + +The return value is an error condition (if one of the endpoints doesn't support +streams, or the xHCI driver ran out of memory), or the number of streams the +host controller allocated for this endpoint. The xHCI host controller hardware +declares how many stream IDs it can support, and each bulk endpoint on a +SuperSpeed device will say how many stream IDs it can handle. Therefore, +drivers should be able to deal with being allocated less stream IDs than they +requested. + +Do NOT call this function if you have URBs enqueued for any of the endpoints +passed in as arguments. Do not call this function to request less than two +streams. + +Drivers will only be allowed to call this API once for the same endpoint +without calling usb_free_streams(). This is a simplification for the xHCI host +controller driver, and may change in the future. + + +Picking new Stream IDs to use +============================ + +Stream ID 0 is reserved, and should not be used to communicate with devices. If +usb_alloc_streams() returns with a value of N, you may use streams 1 though N. +To queue an URB for a specific stream, set the urb->stream_id value. If the +endpoint does not support streams, an error will be returned. + +Note that new API to choose the next stream ID will have to be added if the xHCI +driver supports secondary stream IDs. + + +Clean up +======== + +If a driver wishes to stop using streams to communicate with the device, it +should call + +void usb_free_streams(struct usb_interface *interface, + struct usb_host_endpoint **eps, unsigned int num_eps, + gfp_t mem_flags); + +All stream IDs will be deallocated when the driver releases the interface, to +ensure that drivers that don't support streams will be able to use the endpoint. diff --git a/Documentation/usb/dma.txt b/Documentation/usb/dma.txt index cfdcd16e3abf..84ef865237db 100644 --- a/Documentation/usb/dma.txt +++ b/Documentation/usb/dma.txt @@ -16,11 +16,11 @@ OR: they can now be DMA-aware. manage dma mappings for existing dma-ready buffers (see below). - URBs have an additional "transfer_dma" field, as well as a transfer_flags - bit saying if it's valid. (Control requests also have "setup_dma" and a - corresponding transfer_flags bit.) + bit saying if it's valid. (Control requests also have "setup_dma", but + drivers must not use it.) -- "usbcore" will map those DMA addresses, if a DMA-aware driver didn't do - it first and set URB_NO_TRANSFER_DMA_MAP or URB_NO_SETUP_DMA_MAP. HCDs +- "usbcore" will map this DMA address, if a DMA-aware driver didn't do + it first and set URB_NO_TRANSFER_DMA_MAP. HCDs don't manage dma mappings for URBs. - There's a new "generic DMA API", parts of which are usable by USB device @@ -43,22 +43,16 @@ and effects like cache-trashing can impose subtle penalties. kind of addresses to store in urb->transfer_buffer and urb->transfer_dma. You'd also set URB_NO_TRANSFER_DMA_MAP in urb->transfer_flags: - void *usb_buffer_alloc (struct usb_device *dev, size_t size, + void *usb_alloc_coherent (struct usb_device *dev, size_t size, int mem_flags, dma_addr_t *dma); - void usb_buffer_free (struct usb_device *dev, size_t size, + void usb_free_coherent (struct usb_device *dev, size_t size, void *addr, dma_addr_t dma); Most drivers should *NOT* be using these primitives; they don't need to use this type of memory ("dma-coherent"), and memory returned from kmalloc() will work just fine. - For control transfers you can use the buffer primitives or not for each - of the transfer buffer and setup buffer independently. Set the flag bits - URB_NO_TRANSFER_DMA_MAP and URB_NO_SETUP_DMA_MAP to indicate which - buffers you have prepared. For non-control transfers URB_NO_SETUP_DMA_MAP - is ignored. - The memory buffer returned is "dma-coherent"; sometimes you might need to force a consistent memory access ordering by using memory barriers. It's not using a streaming DMA mapping, so it's good for small transfers on @@ -130,8 +124,8 @@ of Documentation/PCI/PCI-DMA-mapping.txt, titled "What memory is DMA-able?") void usb_buffer_unmap (struct urb *urb); The calls manage urb->transfer_dma for you, and set URB_NO_TRANSFER_DMA_MAP - so that usbcore won't map or unmap the buffer. The same goes for - urb->setup_dma and URB_NO_SETUP_DMA_MAP for control requests. + so that usbcore won't map or unmap the buffer. They cannot be used for + setup_packet buffers in control requests. Note that several of those interfaces are currently commented out, since they don't have current users. See the source code. Other than the dmasync diff --git a/Documentation/usb/gadget_hid.txt b/Documentation/usb/gadget_hid.txt new file mode 100644 index 000000000000..f4a51f567427 --- /dev/null +++ b/Documentation/usb/gadget_hid.txt @@ -0,0 +1,445 @@ + + Linux USB HID gadget driver + +Introduction + + The HID Gadget driver provides emulation of USB Human Interface + Devices (HID). The basic HID handling is done in the kernel, + and HID reports can be sent/received through I/O on the + /dev/hidgX character devices. + + For more details about HID, see the developer page on + http://www.usb.org/developers/hidpage/ + +Configuration + + g_hid is a platform driver, so to use it you need to add + struct platform_device(s) to your platform code defining the + HID function descriptors you want to use - E.G. something + like: + +#include <linux/platform_device.h> +#include <linux/usb/g_hid.h> + +/* hid descriptor for a keyboard */ +static struct hidg_func_descriptor my_hid_data = { + .subclass = 0, /* No subclass */ + .protocol = 1, /* Keyboard */ + .report_length = 8, + .report_desc_length = 63, + .report_desc = { + 0x05, 0x01, /* USAGE_PAGE (Generic Desktop) */ + 0x09, 0x06, /* USAGE (Keyboard) */ + 0xa1, 0x01, /* COLLECTION (Application) */ + 0x05, 0x07, /* USAGE_PAGE (Keyboard) */ + 0x19, 0xe0, /* USAGE_MINIMUM (Keyboard LeftControl) */ + 0x29, 0xe7, /* USAGE_MAXIMUM (Keyboard Right GUI) */ + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ + 0x25, 0x01, /* LOGICAL_MAXIMUM (1) */ + 0x75, 0x01, /* REPORT_SIZE (1) */ + 0x95, 0x08, /* REPORT_COUNT (8) */ + 0x81, 0x02, /* INPUT (Data,Var,Abs) */ + 0x95, 0x01, /* REPORT_COUNT (1) */ + 0x75, 0x08, /* REPORT_SIZE (8) */ + 0x81, 0x03, /* INPUT (Cnst,Var,Abs) */ + 0x95, 0x05, /* REPORT_COUNT (5) */ + 0x75, 0x01, /* REPORT_SIZE (1) */ + 0x05, 0x08, /* USAGE_PAGE (LEDs) */ + 0x19, 0x01, /* USAGE_MINIMUM (Num Lock) */ + 0x29, 0x05, /* USAGE_MAXIMUM (Kana) */ + 0x91, 0x02, /* OUTPUT (Data,Var,Abs) */ + 0x95, 0x01, /* REPORT_COUNT (1) */ + 0x75, 0x03, /* REPORT_SIZE (3) */ + 0x91, 0x03, /* OUTPUT (Cnst,Var,Abs) */ + 0x95, 0x06, /* REPORT_COUNT (6) */ + 0x75, 0x08, /* REPORT_SIZE (8) */ + 0x15, 0x00, /* LOGICAL_MINIMUM (0) */ + 0x25, 0x65, /* LOGICAL_MAXIMUM (101) */ + 0x05, 0x07, /* USAGE_PAGE (Keyboard) */ + 0x19, 0x00, /* USAGE_MINIMUM (Reserved) */ + 0x29, 0x65, /* USAGE_MAXIMUM (Keyboard Application) */ + 0x81, 0x00, /* INPUT (Data,Ary,Abs) */ + 0xc0 /* END_COLLECTION */ + } +}; + +static struct platform_device my_hid = { + .name = "hidg", + .id = 0, + .num_resources = 0, + .resource = 0, + .dev.platform_data = &my_hid_data, +}; + + You can add as many HID functions as you want, only limited by + the amount of interrupt endpoints your gadget driver supports. + +Send and receive HID reports + + HID reports can be sent/received using read/write on the + /dev/hidgX character devices. See below for an example program + to do this. + + hid_gadget_test is a small interactive program to test the HID + gadget driver. To use, point it at a hidg device and set the + device type (keyboard / mouse / joystick) - E.G.: + + # hid_gadget_test /dev/hidg0 keyboard + + You are now in the prompt of hid_gadget_test. You can type any + combination of options and values. Available options and + values are listed at program start. In keyboard mode you can + send up to six values. + + For example type: g i s t r --left-shift + + Hit return and the corresponding report will be sent by the + HID gadget. + + Another interesting example is the caps lock test. Type + -–caps-lock and hit return. A report is then sent by the + gadget and you should receive the host answer, corresponding + to the caps lock LED status. + + --caps-lock + recv report:2 + + With this command: + + # hid_gadget_test /dev/hidg1 mouse + + You can test the mouse emulation. Values are two signed numbers. + + +Sample code + +/* hid_gadget_test */ + +#include <pthread.h> +#include <string.h> +#include <stdio.h> +#include <ctype.h> +#include <fcntl.h> +#include <errno.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +#define BUF_LEN 512 + +struct options { + const char *opt; + unsigned char val; +}; + +static struct options kmod[] = { + {.opt = "--left-ctrl", .val = 0x01}, + {.opt = "--right-ctrl", .val = 0x10}, + {.opt = "--left-shift", .val = 0x02}, + {.opt = "--right-shift", .val = 0x20}, + {.opt = "--left-alt", .val = 0x04}, + {.opt = "--right-alt", .val = 0x40}, + {.opt = "--left-meta", .val = 0x08}, + {.opt = "--right-meta", .val = 0x80}, + {.opt = NULL} +}; + +static struct options kval[] = { + {.opt = "--return", .val = 0x28}, + {.opt = "--esc", .val = 0x29}, + {.opt = "--bckspc", .val = 0x2a}, + {.opt = "--tab", .val = 0x2b}, + {.opt = "--spacebar", .val = 0x2c}, + {.opt = "--caps-lock", .val = 0x39}, + {.opt = "--f1", .val = 0x3a}, + {.opt = "--f2", .val = 0x3b}, + {.opt = "--f3", .val = 0x3c}, + {.opt = "--f4", .val = 0x3d}, + {.opt = "--f5", .val = 0x3e}, + {.opt = "--f6", .val = 0x3f}, + {.opt = "--f7", .val = 0x40}, + {.opt = "--f8", .val = 0x41}, + {.opt = "--f9", .val = 0x42}, + {.opt = "--f10", .val = 0x43}, + {.opt = "--f11", .val = 0x44}, + {.opt = "--f12", .val = 0x45}, + {.opt = "--insert", .val = 0x49}, + {.opt = "--home", .val = 0x4a}, + {.opt = "--pageup", .val = 0x4b}, + {.opt = "--del", .val = 0x4c}, + {.opt = "--end", .val = 0x4d}, + {.opt = "--pagedown", .val = 0x4e}, + {.opt = "--right", .val = 0x4f}, + {.opt = "--left", .val = 0x50}, + {.opt = "--down", .val = 0x51}, + {.opt = "--kp-enter", .val = 0x58}, + {.opt = "--up", .val = 0x52}, + {.opt = "--num-lock", .val = 0x53}, + {.opt = NULL} +}; + +int keyboard_fill_report(char report[8], char buf[BUF_LEN], int *hold) +{ + char *tok = strtok(buf, " "); + int key = 0; + int i = 0; + + for (; tok != NULL; tok = strtok(NULL, " ")) { + + if (strcmp(tok, "--quit") == 0) + return -1; + + if (strcmp(tok, "--hold") == 0) { + *hold = 1; + continue; + } + + if (key < 6) { + for (i = 0; kval[i].opt != NULL; i++) + if (strcmp(tok, kval[i].opt) == 0) { + report[2 + key++] = kval[i].val; + break; + } + if (kval[i].opt != NULL) + continue; + } + + if (key < 6) + if (islower(tok[0])) { + report[2 + key++] = (tok[0] - ('a' - 0x04)); + continue; + } + + for (i = 0; kmod[i].opt != NULL; i++) + if (strcmp(tok, kmod[i].opt) == 0) { + report[0] = report[0] | kmod[i].val; + break; + } + if (kmod[i].opt != NULL) + continue; + + if (key < 6) + fprintf(stderr, "unknown option: %s\n", tok); + } + return 8; +} + +static struct options mmod[] = { + {.opt = "--b1", .val = 0x01}, + {.opt = "--b2", .val = 0x02}, + {.opt = "--b3", .val = 0x04}, + {.opt = NULL} +}; + +int mouse_fill_report(char report[8], char buf[BUF_LEN], int *hold) +{ + char *tok = strtok(buf, " "); + int mvt = 0; + int i = 0; + for (; tok != NULL; tok = strtok(NULL, " ")) { + + if (strcmp(tok, "--quit") == 0) + return -1; + + if (strcmp(tok, "--hold") == 0) { + *hold = 1; + continue; + } + + for (i = 0; mmod[i].opt != NULL; i++) + if (strcmp(tok, mmod[i].opt) == 0) { + report[0] = report[0] | mmod[i].val; + break; + } + if (mmod[i].opt != NULL) + continue; + + if (!(tok[0] == '-' && tok[1] == '-') && mvt < 2) { + errno = 0; + report[1 + mvt++] = (char)strtol(tok, NULL, 0); + if (errno != 0) { + fprintf(stderr, "Bad value:'%s'\n", tok); + report[1 + mvt--] = 0; + } + continue; + } + + fprintf(stderr, "unknown option: %s\n", tok); + } + return 3; +} + +static struct options jmod[] = { + {.opt = "--b1", .val = 0x10}, + {.opt = "--b2", .val = 0x20}, + {.opt = "--b3", .val = 0x40}, + {.opt = "--b4", .val = 0x80}, + {.opt = "--hat1", .val = 0x00}, + {.opt = "--hat2", .val = 0x01}, + {.opt = "--hat3", .val = 0x02}, + {.opt = "--hat4", .val = 0x03}, + {.opt = "--hatneutral", .val = 0x04}, + {.opt = NULL} +}; + +int joystick_fill_report(char report[8], char buf[BUF_LEN], int *hold) +{ + char *tok = strtok(buf, " "); + int mvt = 0; + int i = 0; + + *hold = 1; + + /* set default hat position: neutral */ + report[3] = 0x04; + + for (; tok != NULL; tok = strtok(NULL, " ")) { + + if (strcmp(tok, "--quit") == 0) + return -1; + + for (i = 0; jmod[i].opt != NULL; i++) + if (strcmp(tok, jmod[i].opt) == 0) { + report[3] = (report[3] & 0xF0) | jmod[i].val; + break; + } + if (jmod[i].opt != NULL) + continue; + + if (!(tok[0] == '-' && tok[1] == '-') && mvt < 3) { + errno = 0; + report[mvt++] = (char)strtol(tok, NULL, 0); + if (errno != 0) { + fprintf(stderr, "Bad value:'%s'\n", tok); + report[mvt--] = 0; + } + continue; + } + + fprintf(stderr, "unknown option: %s\n", tok); + } + return 4; +} + +void print_options(char c) +{ + int i = 0; + + if (c == 'k') { + printf(" keyboard options:\n" + " --hold\n"); + for (i = 0; kmod[i].opt != NULL; i++) + printf("\t\t%s\n", kmod[i].opt); + printf("\n keyboard values:\n" + " [a-z] or\n"); + for (i = 0; kval[i].opt != NULL; i++) + printf("\t\t%-8s%s", kval[i].opt, i % 2 ? "\n" : ""); + printf("\n"); + } else if (c == 'm') { + printf(" mouse options:\n" + " --hold\n"); + for (i = 0; mmod[i].opt != NULL; i++) + printf("\t\t%s\n", mmod[i].opt); + printf("\n mouse values:\n" + " Two signed numbers\n" + "--quit to close\n"); + } else { + printf(" joystick options:\n"); + for (i = 0; jmod[i].opt != NULL; i++) + printf("\t\t%s\n", jmod[i].opt); + printf("\n joystick values:\n" + " three signed numbers\n" + "--quit to close\n"); + } +} + +int main(int argc, const char *argv[]) +{ + const char *filename = NULL; + int fd = 0; + char buf[BUF_LEN]; + int cmd_len; + char report[8]; + int to_send = 8; + int hold = 0; + fd_set rfds; + int retval, i; + + if (argc < 3) { + fprintf(stderr, "Usage: %s devname mouse|keyboard|joystick\n", + argv[0]); + return 1; + } + + if (argv[2][0] != 'k' && argv[2][0] != 'm' && argv[2][0] != 'j') + return 2; + + filename = argv[1]; + + if ((fd = open(filename, O_RDWR, 0666)) == -1) { + perror(filename); + return 3; + } + + print_options(argv[2][0]); + + while (42) { + + FD_ZERO(&rfds); + FD_SET(STDIN_FILENO, &rfds); + FD_SET(fd, &rfds); + + retval = select(fd + 1, &rfds, NULL, NULL, NULL); + if (retval == -1 && errno == EINTR) + continue; + if (retval < 0) { + perror("select()"); + return 4; + } + + if (FD_ISSET(fd, &rfds)) { + cmd_len = read(fd, buf, BUF_LEN - 1); + printf("recv report:"); + for (i = 0; i < cmd_len; i++) + printf(" %02x", buf[i]); + printf("\n"); + } + + if (FD_ISSET(STDIN_FILENO, &rfds)) { + memset(report, 0x0, sizeof(report)); + cmd_len = read(STDIN_FILENO, buf, BUF_LEN - 1); + + if (cmd_len == 0) + break; + + buf[cmd_len - 1] = '\0'; + hold = 0; + + memset(report, 0x0, sizeof(report)); + if (argv[2][0] == 'k') + to_send = keyboard_fill_report(report, buf, &hold); + else if (argv[2][0] == 'm') + to_send = mouse_fill_report(report, buf, &hold); + else + to_send = joystick_fill_report(report, buf, &hold); + + if (to_send == -1) + break; + + if (write(fd, report, to_send) != to_send) { + perror(filename); + return 5; + } + if (!hold) { + memset(report, 0x0, sizeof(report)); + if (write(fd, report, to_send) != to_send) { + perror(filename); + return 6; + } + } + } + } + + close(fd); + return 0; +} diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt index 2790ad48cfc2..b29d8e56cf28 100644 --- a/Documentation/usb/power-management.txt +++ b/Documentation/usb/power-management.txt @@ -107,7 +107,9 @@ allowed to issue dynamic suspends. The user interface for controlling dynamic PM is located in the power/ subdirectory of each USB device's sysfs directory, that is, in /sys/bus/usb/devices/.../power/ where "..." is the device's ID. The -relevant attribute files are: wakeup, level, and autosuspend. +relevant attribute files are: wakeup, control, and autosuspend. +(There may also be a file named "level"; this file was deprecated +as of the 2.6.35 kernel and replaced by the "control" file.) power/wakeup @@ -120,7 +122,7 @@ relevant attribute files are: wakeup, level, and autosuspend. while the device is suspended, the change won't take effect until the following suspend.) - power/level + power/control This file contains one of two words: "on" or "auto". You can write those words to the file to change the @@ -148,14 +150,15 @@ relevant attribute files are: wakeup, level, and autosuspend. never to autosuspend. You can write a number to the file to change the autosuspend idle-delay time. -Writing "-1" to power/autosuspend and writing "on" to power/level do +Writing "-1" to power/autosuspend and writing "on" to power/control do essentially the same thing -- they both prevent the device from being autosuspended. Yes, this is a redundancy in the API. (In 2.6.21 writing "0" to power/autosuspend would prevent the device from being autosuspended; the behavior was changed in 2.6.22. The power/autosuspend attribute did not exist prior to 2.6.21, and the -power/level attribute did not exist prior to 2.6.22.) +power/level attribute did not exist prior to 2.6.22. power/control +was added in 2.6.34.) Changing the default idle-delay time @@ -212,7 +215,7 @@ among printers and scanners, but plenty of other types of device have the same deficiency. For this reason, by default the kernel disables autosuspend (the -power/level attribute is initialized to "on") for all devices other +power/control attribute is initialized to "on") for all devices other than hubs. Hubs, at least, appear to be reasonably well-behaved in this regard. @@ -373,7 +376,7 @@ usb_autopm_put_interface() in its close or release routine. But other patterns are possible. The autosuspend attempts mentioned above will often fail for one -reason or another. For example, the power/level attribute might be +reason or another. For example, the power/control attribute might be set to "on", or another interface in the same device might not be idle. This is perfectly normal. If the reason for failure was that the device hasn't been idle for long enough, a timer is scheduled to @@ -394,12 +397,12 @@ Drivers can enable autosuspend for their devices by calling in their probe() routine, if they know that the device is capable of suspending and resuming correctly. This is exactly equivalent to -writing "auto" to the device's power/level attribute. Likewise, +writing "auto" to the device's power/control attribute. Likewise, drivers can disable autosuspend by calling usb_disable_autosuspend(struct usb_device *udev); -This is exactly the same as writing "on" to the power/level attribute. +This is exactly the same as writing "on" to the power/control attribute. Sometimes a driver needs to make sure that remote wakeup is enabled during autosuspend. For example, there's not much point diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index ff2c1ff57ba2..f4d214510259 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -194,6 +194,10 @@ FTDI Single Port Serial Driver This is a single port DB-25 serial adapter. + Devices supported include: + -TripNav TN-200 USB GPS + -Navis Engineering Bureau CH-4711 USB GPS + For any questions or problems with this driver, please contact Bill Ryder. @@ -216,7 +220,7 @@ Cypress M8 CY4601 Family Serial Driver Devices supported: - -DeLorme's USB Earthmate (SiRF Star II lp arch) + -DeLorme's USB Earthmate GPS (SiRF Star II lp arch) -Cypress HID->COM RS232 adapter Note: Cypress Semiconductor claims no affiliation with the @@ -392,9 +396,10 @@ REINER SCT cyberJack pinpad/e-com USB chipcard reader Prolific PL2303 Driver This driver supports any device that has the PL2303 chip from Prolific - in it. This includes a number of single port USB to serial - converters and USB GPS devices. Devices from Aten (the UC-232) and - IO-Data work with this driver, as does the DCU-11 mobile-phone cable. + in it. This includes a number of single port USB to serial converters, + more than 70% of USB GPS devices (in 2010), and some USB UPSes. Devices + from Aten (the UC-232) and IO-Data work with this driver, as does + the DCU-11 mobile-phone cable. For any questions or problems with this driver, please contact Greg Kroah-Hartman at greg@kroah.com @@ -435,6 +440,22 @@ Winchiphead CH341 Driver For any questions or problems with this driver, please contact frank@kingswood-consulting.co.uk. +Moschip MCS7720, MCS7715 driver + + These chips are present in devices sold by various manufacturers, such as Syba + and Cables Unlimited. There may be others. The 7720 provides two serial + ports, and the 7715 provides one serial and one standard PC parallel port. + Support for the 7715's parallel port is enabled by a separate option, which + will not appear unless parallel port support is first enabled at the top-level + of the Device Drivers config menu. Currently only compatibility mode is + supported on the parallel port (no ECP/EPP). + + TODO: + - Implement ECP/EPP modes for the parallel port. + - Baud rates higher than 115200 are currently broken. + - Devices with a single serial port based on the Moschip MCS7703 may work + with this driver with a simple addition to the usb_device_id table. I + don't have one of these devices, so I can't say for sure. Generic Serial driver |