diff options
Diffstat (limited to 'Documentation')
43 files changed, 1527 insertions, 407 deletions
diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore new file mode 100644 index 000000000000..f1fb2a004264 --- /dev/null +++ b/Documentation/ABI/testing/pstore @@ -0,0 +1,35 @@ +Where: /dev/pstore/... +Date: January 2011 +Kernel Version: 2.6.38 +Contact: tony.luck@intel.com +Description: Generic interface to platform dependent persistent storage. + + Platforms that provide a mechanism to preserve some data + across system reboots can register with this driver to + provide a generic interface to show records captured in + the dying moments. In the case of a panic the last part + of the console log is captured, but other interesting + data can also be saved. + + # mount -t pstore - /dev/pstore + + $ ls -l /dev/pstore + total 0 + -r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1 + + Different users of this interface will result in different + filename prefixes. Currently two are defined: + + "dmesg" - saved console log + "mce" - architecture dependent data from fatal h/w error + + Once the information in a file has been read, removing + the file will signal to the underlying persistent storage + device that it can reclaim the space for later re-use. + + $ rm /dev/pstore/dmesg-erst-1 + + The expectation is that all files in /dev/pstore + will be saved elsewhere and erased from persistent store + soon after boot to free up space ready for the next + catastrophe. diff --git a/Documentation/ABI/testing/sysfs-driver-hid b/Documentation/ABI/testing/sysfs-driver-hid new file mode 100644 index 000000000000..b6490e14fe83 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid @@ -0,0 +1,10 @@ +What: For USB devices : /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/report_descriptor + For BT devices : /sys/class/bluetooth/hci<addr>/<hid-bus>:<vendor-id>:<product-id>.<num>/report_descriptor + Symlink : /sys/class/hidraw/hidraw<num>/device/report_descriptor +Date: Jan 2011 +KernelVersion: 2.0.39 +Contact: Alan Ott <alan@signal11.us> +Description: When read, this file returns the device's raw binary HID + report descriptor. + This file cannot be written. +Users: HIDAPI library (http://www.signal11.us/oss/hidapi) diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo b/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo new file mode 100644 index 000000000000..55e281b0071a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo @@ -0,0 +1,53 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/actual_profile +Date: Januar 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 1-5. + When read, this attribute returns the number of the actual + profile which is also the profile that's active on device startup. + When written this attribute activates the selected profile + immediately. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/button +Date: Januar 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The keyboard can store short macros with consist of 1 button with + several modifier keys internally. + When written, this file lets one set the sequence for a specific + button for a specific profile. Button and profile numbers are + included in written data. The data has to be 24 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/info +Date: Januar 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns some info about the device like the + installed firmware version. + The size of the data is 8 bytes in size. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/key_mask +Date: Januar 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The keyboard lets the user deactivate 5 certain keys like the + windows and application keys, to protect the user from the outcome + of accidentally pressing them. + The integer value of this attribute has bits 0-4 set depending + on the state of the corresponding key. + When read, this file returns the current state of the buttons. + When written, the given buttons are activated/deactivated + immediately. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/mode_key +Date: Januar 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The keyboard has a condensed layout without num-lock key. + Instead it uses a mode-key which activates a gaming mode where + the assignment of the number block changes. + The integer value of this attribute ranges from 0 (OFF) to 1 (ON). + When read, this file returns the actual state of the key. + When written, the key is activated/deactivated immediately. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone index 698b8081c473..b4c4f158ab9c 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone @@ -16,12 +16,14 @@ Description: It is possible to switch the dpi setting of the mouse with the 6 3200 This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/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. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/firmware_version Date: March 2010 @@ -32,6 +34,7 @@ Description: When read, this file returns the raw integer version number of the 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. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/profile[1-5] Date: March 2010 @@ -47,6 +50,7 @@ Description: The mouse can store 5 profiles which can be switched by the The mouse will reject invalid data, whereas the profile number stored in the profile doesn't need to fit the number of the store. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/settings Date: March 2010 @@ -57,6 +61,7 @@ Description: When read, this file returns the settings stored in the mouse. 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. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/startup_profile Date: March 2010 @@ -66,6 +71,7 @@ Description: The integer value of this attribute ranges from 1 to 5. 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. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/tcu Date: March 2010 @@ -77,6 +83,7 @@ Description: The mouse has a "Tracking Control Unit" which lets the user 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. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/weight Date: March 2010 @@ -96,3 +103,4 @@ Description: The mouse can be equipped with one of four supplied weights 4 20g This file is readonly. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus index 0f9f30eb1742..00efced73969 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus @@ -4,6 +4,7 @@ Contact: Stefan Achatz <erazor_de@users.sourceforge.net> Description: When read, this file returns the number of the actual profile in range 0-4. This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version Date: October 2010 @@ -14,6 +15,7 @@ Description: When read, this file returns the raw integer version number of the number the decimal point has to be shifted 2 positions to the left. E.g. a returned value of 121 means 1.21 This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro Date: October 2010 @@ -24,6 +26,7 @@ Description: The mouse can store a macro with max 500 key/button strokes button for a specific profile. Button and profile numbers are included in written data. The data has to be 2082 bytes long. This file is writeonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_buttons Date: August 2010 @@ -37,6 +40,7 @@ Description: The mouse can store 5 profiles which can be switched by the Which profile to write is determined by the profile number contained in the data. This file is writeonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons Date: August 2010 @@ -47,6 +51,7 @@ Description: The mouse can store 5 profiles which can be switched by the When read, these files return the respective profile buttons. The returned data is 77 bytes in size. This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings Date: October 2010 @@ -61,6 +66,7 @@ Description: The mouse can store 5 profiles which can be switched by the Which profile to write is determined by the profile number contained in the data. This file is writeonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings Date: August 2010 @@ -72,6 +78,7 @@ Description: The mouse can store 5 profiles which can be switched by the When read, these files return the respective profile settings. The returned data is 43 bytes in size. This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor Date: October 2010 @@ -80,6 +87,7 @@ Description: The mouse has a tracking- and a distance-control-unit. These can be activated/deactivated and the lift-off distance can be set. The data has to be 6 bytes long. This file is writeonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile Date: October 2010 @@ -89,6 +97,7 @@ Description: The integer value of this attribute ranges from 0-4. 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. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu Date: October 2010 @@ -97,6 +106,7 @@ Description: When written a calibration process for the tracking control unit can be initiated/cancelled. The data has to be 3 bytes long. This file is writeonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image Date: October 2010 @@ -106,3 +116,4 @@ Description: When read the mouse returns a 30x30 pixel image of the calibration process initiated with tcu. The returned data is 1028 bytes in size. This file is readonly. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus new file mode 100644 index 000000000000..fdfa16f8189b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus @@ -0,0 +1,100 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi +Date: January 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 1-4. + When read, this attribute returns the number of the active + cpi level. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_profile +Date: January 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 0-4. + When read, this attribute returns the number of the active + profile. + When written, the mouse activates this profile immediately. + The profile that's active when powered down is the same that's + active when the mouse is powered on. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x +Date: January 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 1-10. + When read, this attribute returns the number of the actual + sensitivity in x direction. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y +Date: January 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The integer value of this attribute ranges from 1-10. + When read, this attribute returns the number of the actual + sensitivity in y direction. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version +Date: January 2011 +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 121 means 1.21 + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_buttons +Date: January 2011 +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 is split in settings and buttons. + profile_buttons holds informations about button layout. + When written, this file lets one write the respective profile + buttons back to the mouse. The data has to be 23 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons +Date: January 2011 +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 is split in settings and buttons. + profile_buttons holds informations about button layout. + When read, these files return the respective profile buttons. + The returned data is 23 bytes in size. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_settings +Date: January 2011 +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 is split in settings and buttons. + profile_settings holds informations like resolution, sensitivity + and light effects. + When written, this file lets one write the respective profile + settings back to the mouse. The data has to be 16 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings +Date: January 2011 +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 is split in settings and buttons. + profile_settings holds informations like resolution, sensitivity + and light effects. + When read, these files return the respective profile settings. + The returned data is 16 bytes in size. + This file is readonly. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra index 1c37b823f142..5fab71af3c46 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra @@ -13,6 +13,7 @@ Description: It is possible to switch the cpi setting of the mouse with the 4 1600 This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile Date: August 2010 @@ -20,6 +21,7 @@ Contact: Stefan Achatz <erazor_de@users.sourceforge.net> Description: When read, this file returns the number of the actual profile in range 0-4. This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version Date: August 2010 @@ -30,6 +32,7 @@ Description: When read, this file returns the raw integer version number of the 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. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings Date: August 2010 @@ -44,6 +47,7 @@ Description: The mouse can store 5 profiles which can be switched by the Which profile to write is determined by the profile number contained in the data. This file is writeonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings Date: August 2010 @@ -55,6 +59,7 @@ Description: The mouse can store 5 profiles which can be switched by the When read, these files return the respective profile settings. The returned data is 13 bytes in size. This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons Date: August 2010 @@ -68,6 +73,7 @@ Description: The mouse can store 5 profiles which can be switched by the Which profile to write is determined by the profile number contained in the data. This file is writeonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons Date: August 2010 @@ -78,6 +84,7 @@ Description: The mouse can store 5 profiles which can be switched by the When read, these files return the respective profile buttons. The returned data is 19 bytes in size. This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile Date: August 2010 @@ -86,6 +93,7 @@ Description: The integer value of this attribute ranges from 0-4. When read, this attribute returns the number of the profile that's active when the mouse is powered on. This file is readonly. +Users: http://roccat.sourceforge.net What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings Date: August 2010 @@ -96,3 +104,4 @@ Description: When read, this file returns the settings stored in the mouse. When written, this file lets write settings back to the mouse. The data has to be 3 bytes long. The mouse will reject invalid data. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-fs-ext4 b/Documentation/ABI/testing/sysfs-fs-ext4 index 5fb709997d96..f22ac0872ae8 100644 --- a/Documentation/ABI/testing/sysfs-fs-ext4 +++ b/Documentation/ABI/testing/sysfs-fs-ext4 @@ -48,7 +48,7 @@ Description: will have its blocks allocated out of its own unique preallocation pool. -What: /sys/fs/ext4/<disk>/inode_readahead +What: /sys/fs/ext4/<disk>/inode_readahead_blks Date: March 2008 Contact: "Theodore Ts'o" <tytso@mit.edu> Description: @@ -85,7 +85,14 @@ Date: June 2008 Contact: "Theodore Ts'o" <tytso@mit.edu> Description: Tuning parameter which (if non-zero) controls the goal - inode used by the inode allocator in p0reference to - all other allocation hueristics. This is intended for + inode used by the inode allocator in preference to + all other allocation heuristics. This is intended for debugging use only, and should be 0 on production systems. + +What: /sys/fs/ext4/<disk>/max_writeback_mb_bump +Date: September 2009 +Contact: "Theodore Ts'o" <tytso@mit.edu> +Description: + The maximum number of megabytes the writeback code will + try to write out before move on to another inode. diff --git a/Documentation/ABI/testing/sysfs-fs-pstore b/Documentation/ABI/testing/sysfs-fs-pstore new file mode 100644 index 000000000000..8e659d854805 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-fs-pstore @@ -0,0 +1,7 @@ +What: /sys/fs/pstore/kmsg_bytes +Date: January 2011 +Kernel Version: 2.6.38 +Contact: "Tony Luck" <tony.luck@intel.com> +Description: + Controls amount of console log that will be saved + to persistent store on oops/panic. diff --git a/Documentation/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl index 5e87ad58c0b5..f51f28531b8d 100644 --- a/Documentation/DocBook/filesystems.tmpl +++ b/Documentation/DocBook/filesystems.tmpl @@ -82,6 +82,11 @@ </sect1> </chapter> + <chapter id="fs_events"> + <title>Events based on file descriptors</title> +!Efs/eventfd.c + </chapter> + <chapter id="sysfs"> <title>The Filesystem for Exporting Kernel Objects</title> !Efs/sysfs/file.c diff --git a/Documentation/arm/SH-Mobile/Makefile b/Documentation/arm/SH-Mobile/Makefile new file mode 100644 index 000000000000..8771d832cf8c --- /dev/null +++ b/Documentation/arm/SH-Mobile/Makefile @@ -0,0 +1,8 @@ +BIN := vrl4 + +.PHONY: all +all: $(BIN) + +.PHONY: clean +clean: + rm -f *.o $(BIN) diff --git a/Documentation/arm/SH-Mobile/vrl4.c b/Documentation/arm/SH-Mobile/vrl4.c new file mode 100644 index 000000000000..e8a191358ad2 --- /dev/null +++ b/Documentation/arm/SH-Mobile/vrl4.c @@ -0,0 +1,169 @@ +/* + * vrl4 format generator + * + * Copyright (C) 2010 Simon Horman + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + */ + +/* + * usage: vrl4 < zImage > out + * dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1 + * + * Reads a zImage from stdin and writes a vrl4 image to stdout. + * In practice this means writing a padded vrl4 header to stdout followed + * by the zImage. + * + * The padding places the zImage at ALIGN bytes into the output. + * The vrl4 uses ALIGN + START_BASE as the start_address. + * This is where the mask ROM will jump to after verifying the header. + * + * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN. + * That is, the mask ROM will load the padded header (ALIGN bytes) + * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image, + * whichever is smaller. + * + * The zImage is not modified in any way. + */ + +#define _BSD_SOURCE +#include <endian.h> +#include <unistd.h> +#include <stdint.h> +#include <stdio.h> +#include <errno.h> + +struct hdr { + uint32_t magic1; + uint32_t reserved1; + uint32_t magic2; + uint32_t reserved2; + uint16_t copy_size; + uint16_t boot_options; + uint32_t reserved3; + uint32_t start_address; + uint32_t reserved4; + uint32_t reserved5; + char reserved6[308]; +}; + +#define DECLARE_HDR(h) \ + struct hdr (h) = { \ + .magic1 = htole32(0xea000000), \ + .reserved1 = htole32(0x56), \ + .magic2 = htole32(0xe59ff008), \ + .reserved3 = htole16(0x1) } + +/* Align to 512 bytes, the MMCIF sector size */ +#define ALIGN_BITS 9 +#define ALIGN (1 << ALIGN_BITS) + +#define START_BASE 0xe55b0000 + +/* + * With an alignment of 512 the header uses the first sector. + * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM. + * So there are 127 sectors left for the boot programme. But in practice + * Only a small portion of a zImage is needed, 16 sectors should be more + * than enough. + * + * Note that this sets how much of the zImage is copied by the mask ROM. + * The entire zImage is present after the header and is loaded + * by the code in the boot program (which is the first portion of the zImage). + */ +#define MAX_BOOT_PROG_LEN (16 * 512) + +#define ROUND_UP(x) ((x + ALIGN - 1) & ~(ALIGN - 1)) + +ssize_t do_read(int fd, void *buf, size_t count) +{ + size_t offset = 0; + ssize_t l; + + while (offset < count) { + l = read(fd, buf + offset, count - offset); + if (!l) + break; + if (l < 0) { + if (errno == EAGAIN || errno == EWOULDBLOCK) + continue; + perror("read"); + return -1; + } + offset += l; + } + + return offset; +} + +ssize_t do_write(int fd, const void *buf, size_t count) +{ + size_t offset = 0; + ssize_t l; + + while (offset < count) { + l = write(fd, buf + offset, count - offset); + if (l < 0) { + if (errno == EAGAIN || errno == EWOULDBLOCK) + continue; + perror("write"); + return -1; + } + offset += l; + } + + return offset; +} + +ssize_t write_zero(int fd, size_t len) +{ + size_t i = len; + + while (i--) { + const char x = 0; + if (do_write(fd, &x, 1) < 0) + return -1; + } + + return len; +} + +int main(void) +{ + DECLARE_HDR(hdr); + char boot_program[MAX_BOOT_PROG_LEN]; + size_t aligned_hdr_len, alligned_prog_len; + ssize_t prog_len; + + prog_len = do_read(0, boot_program, sizeof(boot_program)); + if (prog_len <= 0) + return -1; + + aligned_hdr_len = ROUND_UP(sizeof(hdr)); + hdr.start_address = htole32(START_BASE + aligned_hdr_len); + alligned_prog_len = ROUND_UP(prog_len); + hdr.copy_size = htole16(aligned_hdr_len + alligned_prog_len); + + if (do_write(1, &hdr, sizeof(hdr)) < 0) + return -1; + if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0) + return -1; + + if (do_write(1, boot_program, prog_len) < 0) + return 1; + + /* Write out the rest of the kernel */ + while (1) { + prog_len = do_read(0, boot_program, sizeof(boot_program)); + if (prog_len < 0) + return 1; + if (prog_len == 0) + break; + if (do_write(1, boot_program, prog_len) < 0) + return 1; + } + + return 0; +} diff --git a/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt b/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt new file mode 100644 index 000000000000..efff8ae2713d --- /dev/null +++ b/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt @@ -0,0 +1,29 @@ +ROM-able zImage boot from MMC +----------------------------- + +An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and +SuperH Mobile ARM will to boot directly from the MMCIF hardware block. + +This is achieved by the mask ROM loading the first portion of the image into +MERAM and then jumping to it. This portion contains loader code which +copies the entire image to SDRAM and jumps to it. From there the zImage +boot code proceeds as normal, uncompressing the image into its final +location and then jumping to it. + +This code has been tested on an AP4EB board using the developer 1A eMMC +boot mode which is configured using the following jumper settings. +The board used for testing required a patched mask ROM in order for +this mode to function. + + 8 7 6 5 4 3 2 1 + x|x|x|x|x| |x| +S4 -+-+-+-+-+-+-+- + | | | | |x| |x on + +The zImage must be written to the MMC card at sector 1 (512 bytes) in +vrl4 format. A utility vrl4 is supplied to accomplish this. + +e.g. + vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1 + +A dual-voltage MMC 4.0 card was used for testing. diff --git a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen deleted file mode 100644 index dc460f055647..000000000000 --- a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen +++ /dev/null @@ -1,61 +0,0 @@ -README on the ADC/Touchscreen Controller -======================================== - -The LH79524 and LH7A404 include a built-in Analog to Digital -controller (ADC) that is used to process input from a touchscreen. -The driver only implements a four-wire touch panel protocol. - -The touchscreen driver is maintenance free except for the pen-down or -touch threshold. Some resistive displays and board combinations may -require tuning of this threshold. The driver exposes some of its -internal state in the sys filesystem. If the kernel is configured -with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a -directory - - /sys/devices/platform/adc-lh7.0 - -containing these files. - - -r--r--r-- 1 root root 4096 Jan 1 00:00 samples - -rw-r--r-- 1 root root 4096 Jan 1 00:00 threshold - -r--r--r-- 1 root root 4096 Jan 1 00:00 threshold_range - -The threshold is the current touch threshold. It defaults to 750 on -most targets. - - # cat threshold - 750 - -The threshold_range contains the range of valid values for the -threshold. Values outside of this range will be silently ignored. - - # cat threshold_range - 0 1023 - -To change the threshold, write a value to the threshold file. - - # echo 500 > threshold - # cat threshold - 500 - -The samples file contains the most recently sampled values from the -ADC. There are 12. Below are typical of the last sampled values when -the pen has been released. The first two and last two samples are for -detecting whether or not the pen is down. The third through sixth are -X coordinate samples. The seventh through tenth are Y coordinate -samples. - - # cat samples - 1023 1023 0 0 0 0 530 529 530 529 1023 1023 - -To determine a reasonable threshold, press on the touch panel with an -appropriate stylus and read the values from samples. - - # cat samples - 1023 676 92 103 101 102 855 919 922 922 1023 679 - -The first and eleventh samples are discarded. Thus, the important -values are the second and twelfth which are used to determine if the -pen is down. When both are below the threshold, the driver registers -that the pen is down. When either is above the threshold, it -registers then pen is up. diff --git a/Documentation/arm/Sharp-LH/CompactFlash b/Documentation/arm/Sharp-LH/CompactFlash deleted file mode 100644 index 8616d877df9e..000000000000 --- a/Documentation/arm/Sharp-LH/CompactFlash +++ /dev/null @@ -1,32 +0,0 @@ -README on the Compact Flash for Card Engines -============================================ - -There are three challenges in supporting the CF interface of the Card -Engines. First, every IO operation must be followed with IO to -another memory region. Second, the slot is wired for one-to-one -address mapping *and* it is wired for 16 bit access only. Second, the -interrupt request line from the CF device isn't wired. - -The IOBARRIER issue is covered in README.IOBARRIER. This isn't an -onerous problem. Enough said here. - -The addressing issue is solved in the -arch/arm/mach-lh7a40x/ide-lpd7a40x.c file with some awkward -work-arounds. We implement a special SELECT_DRIVE routine that is -called before the IDE driver performs its own SELECT_DRIVE. Our code -recognizes that the SELECT register cannot be modified without also -writing a command. It send an IDLE_IMMEDIATE command on selecting a -drive. The function also prevents drive select to the slave drive -since there can be only one. The awkward part is that the IDE driver, -even though we have a select procedure, also attempts to change the -drive by writing directly the SELECT register. This attempt is -explicitly blocked by the OUTB function--not pretty, but effective. - -The lack of interrupts is a more serious problem. Even though the CF -card is fast when compared to a normal IDE device, we don't know that -the CF is really flash. A user could use one of the very small hard -drives being shipped with a CF interface. The IDE code includes a -check for interfaces that lack an IRQ. In these cases, submitting a -command to the IDE controller is followed by a call to poll for -completion. If the device isn't immediately ready, it schedules a -timer to poll again later. diff --git a/Documentation/arm/Sharp-LH/IOBarrier b/Documentation/arm/Sharp-LH/IOBarrier deleted file mode 100644 index 2e953e228f4d..000000000000 --- a/Documentation/arm/Sharp-LH/IOBarrier +++ /dev/null @@ -1,45 +0,0 @@ -README on the IOBARRIER for CardEngine IO -========================================= - -Due to an unfortunate oversight when the Card Engines were designed, -the signals that control access to some peripherals, most notably the -SMC91C9111 ethernet controller, are not properly handled. - -The symptom is that some back to back IO with the peripheral returns -unreliable data. With the SMC chip, you'll see errors about the bank -register being 'screwed'. - -The cause is that the AEN signal to the SMC chip does not transition -for every memory access. It is driven through the CPLD from the CS7 -line of the CPU's static memory controller which is optimized to -eliminate unnecessary transitions. Yet, the SMC requires a transition -for every write access. The Sharp website has more information about -the effect this power-conserving feature has on peripheral -interfacing. - -The solution is to follow every write access to the SMC chip with an -access to another memory region that will force the CPU to release the -chip select line. It is important to guarantee that this access -forces the CPU off-chip. We map a page of SDRAM as if it were an -uncacheable IO device and read from it after every SMC IO write -operation. - - SMC IO - BARRIER IO - -Only this sequence is important. It does not matter that there is no -BARRIER IO before the access to the SMC chip because the AEN latch -only needs occurs after the SMC IO write cycle. The routines that -implement this work-around make an additional concession which is to -disable interrupts during the IO sequence. Other hardware devices -(the LogicPD CPLD) have registers in the same physical memory -region as the SMC chip. An interrupt might allow an access to one of -those registers while SMC IO is being performed. - -You might be tempted to think that we have to access another device -attached to the static memory controller, but the empirical evidence -indicates that this is not so. Mapping 0x00000000 (flash) and -0xc0000000 (SDRAM) appear to have the same effect. Using SDRAM seems -to be faster. Choosing to access an undecoded memory region is not -desirable as there is no way to know how that chip select will be used -in the future. diff --git a/Documentation/arm/Sharp-LH/KEV7A400 b/Documentation/arm/Sharp-LH/KEV7A400 deleted file mode 100644 index be32b14cd535..000000000000 --- a/Documentation/arm/Sharp-LH/KEV7A400 +++ /dev/null @@ -1,8 +0,0 @@ -README on Implementing Linux for Sharp's KEV7a400 -================================================= - -This product has been discontinued by Sharp. For the time being, the -partially implemented code remains in the kernel. At some point in -the future, either the code will be finished or it will be removed -completely. This depends primarily on how many of the development -boards are in the field. diff --git a/Documentation/arm/Sharp-LH/LCDPanels b/Documentation/arm/Sharp-LH/LCDPanels deleted file mode 100644 index fb1b21c2f2f4..000000000000 --- a/Documentation/arm/Sharp-LH/LCDPanels +++ /dev/null @@ -1,59 +0,0 @@ -README on the LCD Panels -======================== - -Configuration options for several LCD panels, available from Logic PD, -are included in the kernel source. This README will help you -understand the configuration data and give you some guidance for -adding support for other panels if you wish. - - -lcd-panels.h ------------- - -There is no way, at present, to detect which panel is attached to the -system at runtime. Thus the kernel configuration is static. The file -arch/arm/mach-ld7a40x/lcd-panels.h (or similar) defines all of the -panel specific parameters. - -It should be possible for this data to be shared among several device -families. The current layout may be insufficiently general, but it is -amenable to improvement. - - -PIXEL_CLOCK ------------ - -The panel data sheets will give a range of acceptable pixel clocks. -The fundamental LCDCLK input frequency is divided down by a PCD -constant in field '.tim2'. It may happen that it is impossible to set -the pixel clock within this range. A clock which is too slow will -tend to flicker. For the highest quality image, set the clock as high -as possible. - - -MARGINS -------- - -These values may be difficult to glean from the panel data sheet. In -the case of the Sharp panels, the upper margin is explicitly called -out as a specific number of lines from the top of the frame. The -other values may not matter as much as the panels tend to -automatically center the image. - - -Sync Sense ----------- - -The sense of the hsync and vsync pulses may be called out in the data -sheet. On one panel, the sense of these pulses determine the height -of the visible region on the panel. Most of the Sharp panels use -negative sense sync pulses set by the TIM2_IHS and TIM2_IVS bits in -'.tim2'. - - -Pel Layout ----------- - -The Sharp color TFT panels are all configured for 16 bit direct color -modes. The amba-lcd driver sets the pel mode to 565 for 5 bits of -each red and blue and 6 bits of green. diff --git a/Documentation/arm/Sharp-LH/LPD7A400 b/Documentation/arm/Sharp-LH/LPD7A400 deleted file mode 100644 index 3275b453bfdf..000000000000 --- a/Documentation/arm/Sharp-LH/LPD7A400 +++ /dev/null @@ -1,15 +0,0 @@ -README on Implementing Linux for the Logic PD LPD7A400-10 -========================================================= - -- CPLD memory mapping - - The board designers chose to use high address lines for controlling - access to the CPLD registers. It turns out to be a big waste - because we're using an MMU and must map IO space into virtual - memory. The result is that we have to make a mapping for every - register. - -- Serial Console - - It may be OK not to use the serial console option if the user passes - the console device name to the kernel. This deserves some exploration. diff --git a/Documentation/arm/Sharp-LH/LPD7A40X b/Documentation/arm/Sharp-LH/LPD7A40X deleted file mode 100644 index 8c29a27e208f..000000000000 --- a/Documentation/arm/Sharp-LH/LPD7A40X +++ /dev/null @@ -1,16 +0,0 @@ -README on Implementing Linux for the Logic PD LPD7A40X-10 -========================================================= - -- CPLD memory mapping - - The board designers chose to use high address lines for controlling - access to the CPLD registers. It turns out to be a big waste - because we're using an MMU and must map IO space into virtual - memory. The result is that we have to make a mapping for every - register. - -- Serial Console - - It may be OK not to use the serial console option if the user passes - the console device name to the kernel. This deserves some exploration. - diff --git a/Documentation/arm/Sharp-LH/SDRAM b/Documentation/arm/Sharp-LH/SDRAM deleted file mode 100644 index 93ddc23c2faa..000000000000 --- a/Documentation/arm/Sharp-LH/SDRAM +++ /dev/null @@ -1,51 +0,0 @@ -README on the SDRAM Controller for the LH7a40X -============================================== - -The standard configuration for the SDRAM controller generates a sparse -memory array. The precise layout is determined by the SDRAM chips. A -default kernel configuration assembles the discontiguous memory -regions into separate memory nodes via the NUMA (Non-Uniform Memory -Architecture) facilities. In this default configuration, the kernel -is forgiving about the precise layout. As long as it is given an -accurate picture of available memory by the bootloader the kernel will -execute correctly. - -The SDRC supports a mode where some of the chip select lines are -swapped in order to make SDRAM look like a synchronous ROM. Setting -this bit means that the RAM will present as a contiguous array. Some -programmers prefer this to the discontiguous layout. Be aware that -may be a penalty for this feature where some some configurations of -memory are significantly reduced; i.e. 64MiB of RAM appears as only 32 -MiB. - -There are a couple of configuration options to override the default -behavior. When the SROMLL bit is set and memory appears as a -contiguous array, there is no reason to support NUMA. -CONFIG_LH7A40X_CONTIGMEM disables NUMA support. When physical memory -is discontiguous, the memory tables are organized such that there are -two banks per nodes with a small gap between them. This layout wastes -some kernel memory for page tables representing non-existent memory. -CONFIG_LH7A40X_ONE_BANK_PER_NODE optimizes the node tables such that -there are no gaps. These options control the low level organization -of the memory management tables in ways that may prevent the kernel -from booting or may cause the kernel to allocated excessively large -page tables. Be warned. Only change these options if you know what -you are doing. The default behavior is a reasonable compromise that -will suit all users. - --- - -A typical 32MiB system with the default configuration options will -find physical memory managed as follows. - - node 0: 0xc0000000 4MiB - 0xc1000000 4MiB - node 1: 0xc4000000 4MiB - 0xc5000000 4MiB - node 2: 0xc8000000 4MiB - 0xc9000000 4MiB - node 3: 0xcc000000 4MiB - 0xcd000000 4MiB - -Setting CONFIG_LH7A40X_ONE_BANK_PER_NODE will put each bank into a -separate node. diff --git a/Documentation/arm/Sharp-LH/VectoredInterruptController b/Documentation/arm/Sharp-LH/VectoredInterruptController deleted file mode 100644 index 23047e9861ee..000000000000 --- a/Documentation/arm/Sharp-LH/VectoredInterruptController +++ /dev/null @@ -1,80 +0,0 @@ -README on the Vectored Interrupt Controller of the LH7A404 -========================================================== - -The 404 revision of the LH7A40X series comes with two vectored -interrupts controllers. While the kernel does use some of the -features of these devices, it is far from the purpose for which they -were designed. - -When this README was written, the implementation of the VICs was in -flux. It is possible that some details, especially with priorities, -will change. - -The VIC support code is inspired by routines written by Sharp. - - -Priority Control ----------------- - -The significant reason for using the VIC's vectoring is to control -interrupt priorities. There are two tables in -arch/arm/mach-lh7a40x/irq-lh7a404.c that look something like this. - - static unsigned char irq_pri_vic1[] = { IRQ_GPIO3INTR, }; - static unsigned char irq_pri_vic2[] = { - IRQ_T3UI, IRQ_GPIO7INTR, - IRQ_UART1INTR, IRQ_UART2INTR, IRQ_UART3INTR, }; - -The initialization code reads these tables and inserts a vector -address and enable for each indicated IRQ. Vectored interrupts have -higher priority than non-vectored interrupts. So, on VIC1, -IRQ_GPIO3INTR will be served before any other non-FIQ interrupt. Due -to the way that the vectoring works, IRQ_T3UI is the next highest -priority followed by the other vectored interrupts on VIC2. After -that, the non-vectored interrupts are scanned in VIC1 then in VIC2. - - -ISR ---- - -The interrupt service routine macro get_irqnr() in -arch/arm/kernel/entry-armv.S scans the VICs for the next active -interrupt. The vectoring makes this code somewhat larger than it was -before using vectoring (refer to the LH7A400 implementation). In the -case where an interrupt is vectored, the implementation will tend to -be faster than the non-vectored version. However, the worst-case path -is longer. - -It is worth noting that at present, there is no need to read -VIC2_VECTADDR because the register appears to be shared between the -controllers. The code is written such that if this changes, it ought -to still work properly. - - -Vector Addresses ----------------- - -The proper use of the vectoring hardware would jump to the ISR -specified by the vectoring address. Linux isn't structured to take -advantage of this feature, though it might be possible to change -things to support it. - -In this implementation, the vectoring address is used to speed the -search for the active IRQ. The address is coded such that the lowest -6 bits store the IRQ number for vectored interrupts. These numbers -correspond to the bits in the interrupt status registers. IRQ zero is -the lowest interrupt bit in VIC1. IRQ 32 is the lowest interrupt bit -in VIC2. Because zero is a valid IRQ number and because we cannot -detect whether or not there is a valid vectoring address if that -address is zero, the eigth bit (0x100) is set for vectored interrupts. -The address for IRQ 0x18 (VIC2) is 0x118. Only the ninth bit is set -for the default handler on VIC1 and only the tenth bit is set for the -default handler on VIC2. - -In other words. - - 0x000 - no active interrupt - 0x1ii - vectored interrupt 0xii - 0x2xx - unvectored interrupt on VIC1 (xx is don't care) - 0x4xx - unvectored interrupt on VIC2 (xx is don't care) - diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index b3f35e5f9c95..b840ec3c875d 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -619,3 +619,12 @@ Why: The original implementation of memsw feature enabled by Who: Michal Hocko <mhocko@suse.cz> ---------------------------- + +What: i2c_driver.attach_adapter + i2c_driver.detach_adapter +When: September 2011 +Why: These legacy callbacks should no longer be used as i2c-core offers + a variety of preferable alternative ways to instantiate I2C devices. +Who: Jean Delvare <khali@linux-fr.org> + +---------------------------- diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 6ab9442d7eeb..6b050464a90d 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -367,12 +367,47 @@ init_itable=n The lazy itable init code will wait n times the minimizes the impact on the systme performance while file system's inode table is being initialized. -discard Controls whether ext4 should issue discard/TRIM +discard Controls whether ext4 should issue discard/TRIM nodiscard(*) commands to the underlying block device when blocks are freed. This is useful for SSD devices and sparse/thinly-provisioned LUNs, but it is off by default until sufficient testing has been done. +nouid32 Disables 32-bit UIDs and GIDs. This is for + interoperability with older kernels which only + store and expect 16-bit values. + +resize Allows to resize filesystem to the end of the last + existing block group, further resize has to be done + with resize2fs either online, or offline. It can be + used only with conjunction with remount. + +block_validity This options allows to enables/disables the in-kernel +noblock_validity facility for tracking filesystem metadata blocks + within internal data structures. This allows multi- + block allocator and other routines to quickly locate + extents which might overlap with filesystem metadata + blocks. This option is intended for debugging + purposes and since it negatively affects the + performance, it is off by default. + +dioread_lock Controls whether or not ext4 should use the DIO read +dioread_nolock locking. If the dioread_nolock option is specified + ext4 will allocate uninitialized extent before buffer + write and convert the extent to initialized after IO + completes. This approach allows ext4 code to avoid + using inode mutex, which improves scalability on high + speed storages. However this does not work with nobh + option and the mount will fail. Nor does it work with + data journaling and dioread_nolock option will be + ignored with kernel warning. Note that dioread_nolock + code path is only used for extent-based files. + Because of the restrictions this options comprises + it is off by default (e.g. dioread_lock). + +i_version Enable 64-bit inode version support. This option is + off by default. + Data Mode ========= There are 3 different data modes: @@ -400,6 +435,176 @@ needs to be read from and written to disk at the same time where it outperforms all others modes. Currently ext4 does not have delayed allocation support if this data journalling mode is selected. +/proc entries +============= + +Information about mounted ext4 file systems can be found in +/proc/fs/ext4. Each mounted filesystem will have a directory in +/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or +/proc/fs/ext4/dm-0). The files in each per-device directory are shown +in table below. + +Files in /proc/fs/ext4/<devname> +.............................................................................. + File Content + mb_groups details of multiblock allocator buddy cache of free blocks +.............................................................................. + +/sys entries +============ + +Information about mounted ext4 file systems can be found in +/sys/fs/ext4. Each mounted filesystem will have a directory in +/sys/fs/ext4 based on its device name (i.e., /sys/fs/ext4/hdc or +/sys/fs/ext4/dm-0). The files in each per-device directory are shown +in table below. + +Files in /sys/fs/ext4/<devname> +(see also Documentation/ABI/testing/sysfs-fs-ext4) +.............................................................................. + File Content + + delayed_allocation_blocks This file is read-only and shows the number of + blocks that are dirty in the page cache, but + which do not have their location in the + filesystem allocated yet. + + inode_goal Tuning parameter which (if non-zero) controls + the goal inode used by the inode allocator in + preference to all other allocation heuristics. + This is intended for debugging use only, and + should be 0 on production systems. + + inode_readahead_blks Tuning parameter which controls the maximum + number of inode table blocks that ext4's inode + table readahead algorithm will pre-read into + the buffer cache + + lifetime_write_kbytes This file is read-only and shows the number of + kilobytes of data that have been written to this + filesystem since it was created. + + max_writeback_mb_bump The maximum number of megabytes the writeback + code will try to write out before move on to + another inode. + + mb_group_prealloc The multiblock allocator will round up allocation + requests to a multiple of this tuning parameter if + the stripe size is not set in the ext4 superblock + + mb_max_to_scan The maximum number of extents the multiblock + allocator will search to find the best extent + + mb_min_to_scan The minimum number of extents the multiblock + allocator will search to find the best extent + + mb_order2_req Tuning parameter which controls the minimum size + for requests (as a power of 2) where the buddy + cache is used + + mb_stats Controls whether the multiblock allocator should + collect statistics, which are shown during the + unmount. 1 means to collect statistics, 0 means + not to collect statistics + + mb_stream_req Files which have fewer blocks than this tunable + parameter will have their blocks allocated out + of a block group specific preallocation pool, so + that small files are packed closely together. + Each large file will have its blocks allocated + out of its own unique preallocation pool. + + session_write_kbytes This file is read-only and shows the number of + kilobytes of data that have been written to this + filesystem since it was mounted. +.............................................................................. + +Ioctls +====== + +There is some Ext4 specific functionality which can be accessed by applications +through the system call interfaces. The list of all Ext4 specific ioctls are +shown in the table below. + +Table of Ext4 specific ioctls +.............................................................................. + Ioctl Description + EXT4_IOC_GETFLAGS Get additional attributes associated with inode. + The ioctl argument is an integer bitfield, with + bit values described in ext4.h. This ioctl is an + alias for FS_IOC_GETFLAGS. + + EXT4_IOC_SETFLAGS Set additional attributes associated with inode. + The ioctl argument is an integer bitfield, with + bit values described in ext4.h. This ioctl is an + alias for FS_IOC_SETFLAGS. + + EXT4_IOC_GETVERSION + EXT4_IOC_GETVERSION_OLD + Get the inode i_generation number stored for + each inode. The i_generation number is normally + changed only when new inode is created and it is + particularly useful for network filesystems. The + '_OLD' version of this ioctl is an alias for + FS_IOC_GETVERSION. + + EXT4_IOC_SETVERSION + EXT4_IOC_SETVERSION_OLD + Set the inode i_generation number stored for + each inode. The '_OLD' version of this ioctl + is an alias for FS_IOC_SETVERSION. + + EXT4_IOC_GROUP_EXTEND This ioctl has the same purpose as the resize + mount option. It allows to resize filesystem + to the end of the last existing block group, + further resize has to be done with resize2fs, + either online, or offline. The argument points + to the unsigned logn number representing the + filesystem new block count. + + EXT4_IOC_MOVE_EXT Move the block extents from orig_fd (the one + this ioctl is pointing to) to the donor_fd (the + one specified in move_extent structure passed + as an argument to this ioctl). Then, exchange + inode metadata between orig_fd and donor_fd. + This is especially useful for online + defragmentation, because the allocator has the + opportunity to allocate moved blocks better, + ideally into one contiguous extent. + + EXT4_IOC_GROUP_ADD Add a new group descriptor to an existing or + new group descriptor block. The new group + descriptor is described by ext4_new_group_input + structure, which is passed as an argument to + this ioctl. This is especially useful in + conjunction with EXT4_IOC_GROUP_EXTEND, + which allows online resize of the filesystem + to the end of the last existing block group. + Those two ioctls combined is used in userspace + online resize tool (e.g. resize2fs). + + EXT4_IOC_MIGRATE This ioctl operates on the filesystem itself. + It converts (migrates) ext3 indirect block mapped + inode to ext4 extent mapped inode by walking + through indirect block mapping of the original + inode and converting contiguous block ranges + into ext4 extents of the temporary inode. Then, + inodes are swapped. This ioctl might help, when + migrating from ext3 to ext4 filesystem, however + suggestion is to create fresh ext4 filesystem + and copy data from the backup. Note, that + filesystem has to support extents for this ioctl + to work. + + EXT4_IOC_ALLOC_DA_BLKS Force all of the delay allocated blocks to be + allocated to preserve application-expected ext3 + behaviour. Note that this will also start + triggering a write of the data blocks, but this + behaviour may change in the future as it is + not necessary and has been done this way only + for sake of simplicity. +.............................................................................. + References ========== diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 index 0e76ef12e4c6..a22ecf48f255 100644 --- a/Documentation/hwmon/jc42 +++ b/Documentation/hwmon/jc42 @@ -51,7 +51,8 @@ Supported chips: * JEDEC JC 42.4 compliant temperature sensor chips Prefix: 'jc42' Addresses scanned: I2C 0x18 - 0x1f - Datasheet: - + Datasheet: + http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf Author: Guenter Roeck <guenter.roeck@ericsson.com> @@ -60,7 +61,11 @@ Author: Description ----------- -This driver implements support for JEDEC JC 42.4 compliant temperature sensors. +This driver implements support for JEDEC JC 42.4 compliant temperature sensors, +which are used on many DDR3 memory modules for mobile devices and servers. Some +systems use the sensor to prevent memory overheating by automatically throttling +the memory controller. + The driver auto-detects the chips listed above, but can be manually instantiated to support other JC 42.4 compliant chips. @@ -81,15 +86,19 @@ limits. The chip supports only a single register to configure the hysteresis, which applies to all limits. This register can be written by writing into temp1_crit_hyst. Other hysteresis attributes are read-only. +If the BIOS has configured the sensor for automatic temperature management, it +is likely that it has locked the registers, i.e., that the temperature limits +cannot be changed. + Sysfs entries ------------- temp1_input Temperature (RO) -temp1_min Minimum temperature (RW) -temp1_max Maximum temperature (RW) -temp1_crit Critical high temperature (RW) +temp1_min Minimum temperature (RO or RW) +temp1_max Maximum temperature (RO or RW) +temp1_crit Critical high temperature (RO or RW) -temp1_crit_hyst Critical hysteresis temperature (RW) +temp1_crit_hyst Critical hysteresis temperature (RO or RW) temp1_max_hyst Maximum hysteresis temperature (RO) temp1_min_alarm Temperature low alarm diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index 6526eee525a6..d2b56a4fd1f5 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp @@ -9,6 +9,8 @@ Supported chips: Socket S1G3: Athlon II, Sempron, Turion II * AMD Family 11h processors: Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) +* AMD Family 12h processors: "Llano" +* AMD Family 14h processors: "Brazos" (C/E/G-Series) Prefix: 'k10temp' Addresses scanned: PCI space @@ -17,10 +19,14 @@ Supported chips: http://support.amd.com/us/Processor_TechDocs/31116.pdf BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors: http://support.amd.com/us/Processor_TechDocs/41256.pdf + BIOS and Kernel Developer's Guide (BKDG) for AMD Family 14h Models 00h-0Fh Processors: + http://support.amd.com/us/Processor_TechDocs/43170.pdf Revision Guide for AMD Family 10h Processors: http://support.amd.com/us/Processor_TechDocs/41322.pdf Revision Guide for AMD Family 11h Processors: http://support.amd.com/us/Processor_TechDocs/41788.pdf + Revision Guide for AMD Family 14h Models 00h-0Fh Processors: + http://support.amd.com/us/Processor_TechDocs/47534.pdf AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks: http://support.amd.com/us/Processor_TechDocs/43373.pdf AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet: @@ -34,7 +40,7 @@ Description ----------- This driver permits reading of the internal temperature sensor of AMD -Family 10h and 11h processors. +Family 10h/11h/12h/14h processors. All these processors have a sensor, but on those for Socket F or AM2+, the sensor may return inconsistent values (erratum 319). The driver diff --git a/Documentation/hwmon/lineage-pem b/Documentation/hwmon/lineage-pem new file mode 100644 index 000000000000..2ba5ed126858 --- /dev/null +++ b/Documentation/hwmon/lineage-pem @@ -0,0 +1,77 @@ +Kernel driver lineage-pem +========================= + +Supported devices: + * Lineage Compact Power Line Power Entry Modules + Prefix: 'lineage-pem' + Addresses scanned: - + Documentation: + http://www.lineagepower.com/oem/pdf/CPLI2C.pdf + +Author: Guenter Roeck <guenter.roeck@ericsson.com> + + +Description +----------- + +This driver supports various Lineage Compact Power Line DC/DC and AC/DC +converters such as CP1800, CP2000AC, CP2000DC, CP2100DC, and others. + +Lineage CPL power entry modules are nominally PMBus compliant. However, most +standard PMBus commands are not supported. Specifically, all hardware monitoring +and status reporting commands are non-standard. For this reason, a standard +PMBus driver can not be used. + + +Usage Notes +----------- + +This driver does not probe for Lineage CPL devices, since there is no register +which can be safely used to identify the chip. You will have to instantiate +the devices explicitly. + +Example: the following will load the driver for a Lineage PEM at address 0x40 +on I2C bus #1: +$ modprobe lineage-pem +$ echo lineage-pem 0x40 > /sys/bus/i2c/devices/i2c-1/new_device + +All Lineage CPL power entry modules have a built-in I2C bus master selector +(PCA9541). To ensure device access, this driver should only be used as client +driver to the pca9541 I2C master selector driver. + + +Sysfs entries +------------- + +All Lineage CPL devices report output voltage and device temperature as well as +alarms for output voltage, temperature, input voltage, input current, input power, +and fan status. + +Input voltage, input current, input power, and fan speed measurement is only +supported on newer devices. The driver detects if those attributes are supported, +and only creates respective sysfs entries if they are. + +in1_input Output voltage (mV) +in1_min_alarm Output undervoltage alarm +in1_max_alarm Output overvoltage alarm +in1_crit Output voltage critical alarm + +in2_input Input voltage (mV, optional) +in2_alarm Input voltage alarm + +curr1_input Input current (mA, optional) +curr1_alarm Input overcurrent alarm + +power1_input Input power (uW, optional) +power1_alarm Input power alarm + +fan1_input Fan 1 speed (rpm, optional) +fan2_input Fan 2 speed (rpm, optional) +fan3_input Fan 3 speed (rpm, optional) + +temp1_input +temp1_max +temp1_crit +temp1_alarm +temp1_crit_alarm +temp1_fault diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75 index 8e6356fe05d7..a1790401fdde 100644 --- a/Documentation/hwmon/lm75 +++ b/Documentation/hwmon/lm75 @@ -7,6 +7,11 @@ Supported chips: Addresses scanned: I2C 0x48 - 0x4f Datasheet: Publicly available at the National Semiconductor website http://www.national.com/ + * National Semiconductor LM75A + Prefix: 'lm75a' + Addresses scanned: I2C 0x48 - 0x4f + Datasheet: Publicly available at the National Semiconductor website + http://www.national.com/ * Dallas Semiconductor DS75 Prefix: 'lm75' Addresses scanned: I2C 0x48 - 0x4f diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85 index 239258a63c81..7c49feaa79d2 100644 --- a/Documentation/hwmon/lm85 +++ b/Documentation/hwmon/lm85 @@ -26,6 +26,14 @@ Supported chips: Prefix: 'emc6d102' Addresses scanned: I2C 0x2c, 0x2d, 0x2e Datasheet: http://www.smsc.com/main/catalog/emc6d102.html + * SMSC EMC6D103 + Prefix: 'emc6d103' + Addresses scanned: I2C 0x2c, 0x2d, 0x2e + Datasheet: http://www.smsc.com/main/catalog/emc6d103.html + * SMSC EMC6D103S + Prefix: 'emc6d103s' + Addresses scanned: I2C 0x2c, 0x2d, 0x2e + Datasheet: http://www.smsc.com/main/catalog/emc6d103s.html Authors: Philip Pokorny <ppokorny@penguincomputing.com>, @@ -122,9 +130,11 @@ to be register compatible. The EMC6D100 offers all the features of the EMC6D101 plus additional voltage monitoring and system control features. Unfortunately it is not possible to distinguish between the package versions on register level so these additional voltage inputs may read -zero. The EMC6D102 features addtional ADC bits thus extending precision +zero. EMC6D102 and EMC6D103 feature additional ADC bits thus extending precision of voltage and temperature channels. +SMSC EMC6D103S is similar to EMC6D103, but does not support pwm#_auto_pwm_minctl +and temp#_auto_temp_off. Hardware Configurations ----------------------- diff --git a/Documentation/hwmon/max6639 b/Documentation/hwmon/max6639 new file mode 100644 index 000000000000..dc49f8be7167 --- /dev/null +++ b/Documentation/hwmon/max6639 @@ -0,0 +1,49 @@ +Kernel driver max6639 +===================== + +Supported chips: + * Maxim MAX6639 + Prefix: 'max6639' + Addresses scanned: I2C 0x2c, 0x2e, 0x2f + Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6639.pdf + +Authors: + He Changqing <hechangqing@semptian.com> + Roland Stigge <stigge@antcom.de> + +Description +----------- + +This driver implements support for the Maxim MAX6639. This chip is a 2-channel +temperature monitor with dual PWM fan speed controller. It can monitor its own +temperature and one external diode-connected transistor or two external +diode-connected transistors. + +The following device attributes are implemented via sysfs: + +Attribute R/W Contents +---------------------------------------------------------------------------- +temp1_input R Temperature channel 1 input (0..150 C) +temp2_input R Temperature channel 2 input (0..150 C) +temp1_fault R Temperature channel 1 diode fault +temp2_fault R Temperature channel 2 diode fault +temp1_max RW Set THERM temperature for input 1 + (in C, see datasheet) +temp2_max RW Set THERM temperature for input 2 +temp1_crit RW Set ALERT temperature for input 1 +temp2_crit RW Set ALERT temperature for input 2 +temp1_emergency RW Set OT temperature for input 1 + (in C, see datasheet) +temp2_emergency RW Set OT temperature for input 2 +pwm1 RW Fan 1 target duty cycle (0..255) +pwm2 RW Fan 2 target duty cycle (0..255) +fan1_input R TACH1 fan tachometer input (in RPM) +fan2_input R TACH2 fan tachometer input (in RPM) +fan1_fault R Fan 1 fault +fan2_fault R Fan 2 fault +temp1_max_alarm R Alarm on THERM temperature on channel 1 +temp2_max_alarm R Alarm on THERM temperature on channel 2 +temp1_crit_alarm R Alarm on ALERT temperature on channel 1 +temp2_crit_alarm R Alarm on ALERT temperature on channel 2 +temp1_emergency_alarm R Alarm on OT temperature on channel 1 +temp2_emergency_alarm R Alarm on OT temperature on channel 2 diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus new file mode 100644 index 000000000000..f2d42e8bdf48 --- /dev/null +++ b/Documentation/hwmon/pmbus @@ -0,0 +1,215 @@ +Kernel driver pmbus +==================== + +Supported chips: + * Ericsson BMR45X series + DC/DC Converter + Prefixes: 'bmr450', 'bmr451', 'bmr453', 'bmr454' + Addresses scanned: - + Datasheet: + http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146395 + * Linear Technology LTC2978 + Octal PMBus Power Supply Monitor and Controller + Prefix: 'ltc2978' + Addresses scanned: - + Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf + * Maxim MAX16064 + Quad Power-Supply Controller + Prefix: 'max16064' + Addresses scanned: - + Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf + * Maxim MAX34440 + PMBus 6-Channel Power-Supply Manager + Prefixes: 'max34440' + Addresses scanned: - + Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf + * Maxim MAX34441 + PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller + Prefixes: 'max34441' + Addresses scanned: - + Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf + * Maxim MAX8688 + Digital Power-Supply Controller/Monitor + Prefix: 'max8688' + Addresses scanned: - + Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf + * Generic PMBus devices + Prefix: 'pmbus' + Addresses scanned: - + Datasheet: n.a. + +Author: Guenter Roeck <guenter.roeck@ericsson.com> + + +Description +----------- + +This driver supports hardware montoring for various PMBus compliant devices. +It supports voltage, current, power, and temperature sensors as supported +by the device. + +Each monitored channel has its own high and low limits, plus a critical +limit. + +Fan support will be added in a later version of this driver. + + +Usage Notes +----------- + +This driver does not probe for PMBus devices, since there is no register +which can be safely used to identify the chip (The MFG_ID register is not +supported by all chips), and since there is no well defined address range for +PMBus devices. You will have to instantiate the devices explicitly. + +Example: the following will load the driver for an LTC2978 at address 0x60 +on I2C bus #1: +$ modprobe pmbus +$ echo ltc2978 0x60 > /sys/bus/i2c/devices/i2c-1/new_device + + +Platform data support +--------------------- + +Support for additional PMBus chips can be added by defining chip parameters in +a new chip specific driver file. For example, (untested) code to add support for +Emerson DS1200 power modules might look as follows. + +static struct pmbus_driver_info ds1200_info = { + .pages = 1, + /* Note: All other sensors are in linear mode */ + .direct[PSC_VOLTAGE_OUT] = true, + .direct[PSC_TEMPERATURE] = true, + .direct[PSC_CURRENT_OUT] = true, + .m[PSC_VOLTAGE_IN] = 1, + .b[PSC_VOLTAGE_IN] = 0, + .R[PSC_VOLTAGE_IN] = 3, + .m[PSC_VOLTAGE_OUT] = 1, + .b[PSC_VOLTAGE_OUT] = 0, + .R[PSC_VOLTAGE_OUT] = 3, + .m[PSC_TEMPERATURE] = 1, + .b[PSC_TEMPERATURE] = 0, + .R[PSC_TEMPERATURE] = 3, + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_STATUS_INPUT + | PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT + | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT + | PMBUS_HAVE_PIN | PMBUS_HAVE_POUT + | PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP + | PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12, +}; + +static int ds1200_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + return pmbus_do_probe(client, id, &ds1200_info); +} + +static int ds1200_remove(struct i2c_client *client) +{ + return pmbus_do_remove(client); +} + +static const struct i2c_device_id ds1200_id[] = { + {"ds1200", 0}, + {} +}; + +MODULE_DEVICE_TABLE(i2c, ds1200_id); + +/* This is the driver that will be inserted */ +static struct i2c_driver ds1200_driver = { + .driver = { + .name = "ds1200", + }, + .probe = ds1200_probe, + .remove = ds1200_remove, + .id_table = ds1200_id, +}; + +static int __init ds1200_init(void) +{ + return i2c_add_driver(&ds1200_driver); +} + +static void __exit ds1200_exit(void) +{ + i2c_del_driver(&ds1200_driver); +} + + +Sysfs entries +------------- + +When probing the chip, the driver identifies which PMBus registers are +supported, and determines available sensors from this information. +Attribute files only exist if respective sensors are suported by the chip. +Labels are provided to inform the user about the sensor associated with +a given sysfs entry. + +The following attributes are supported. Limits are read-write; all other +attributes are read-only. + +inX_input Measured voltage. From READ_VIN or READ_VOUT register. +inX_min Minumum Voltage. + From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register. +inX_max Maximum voltage. + From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register. +inX_lcrit Critical minumum Voltage. + From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register. +inX_crit Critical maximum voltage. + From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register. +inX_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. +inX_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. +inX_lcrit_alarm Voltage critical low alarm. + From VOLTAGE_UV_FAULT status. +inX_crit_alarm Voltage critical high alarm. + From VOLTAGE_OV_FAULT status. +inX_label "vin", "vcap", or "voutY" + +currX_input Measured current. From READ_IIN or READ_IOUT register. +currX_max Maximum current. + From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register. +currX_lcrit Critical minumum output current. + From IOUT_UC_FAULT_LIMIT register. +currX_crit Critical maximum current. + From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register. +currX_alarm Current high alarm. + From IIN_OC_WARNING or IOUT_OC_WARNING status. +currX_lcrit_alarm Output current critical low alarm. + From IOUT_UC_FAULT status. +currX_crit_alarm Current critical high alarm. + From IIN_OC_FAULT or IOUT_OC_FAULT status. +currX_label "iin" or "vinY" + +powerX_input Measured power. From READ_PIN or READ_POUT register. +powerX_cap Output power cap. From POUT_MAX register. +powerX_max Power limit. From PIN_OP_WARN_LIMIT or + POUT_OP_WARN_LIMIT register. +powerX_crit Critical output power limit. + From POUT_OP_FAULT_LIMIT register. +powerX_alarm Power high alarm. + From PIN_OP_WARNING or POUT_OP_WARNING status. +powerX_crit_alarm Output power critical high alarm. + From POUT_OP_FAULT status. +powerX_label "pin" or "poutY" + +tempX_input Measured tempererature. + From READ_TEMPERATURE_X register. +tempX_min Mimimum tempererature. From UT_WARN_LIMIT register. +tempX_max Maximum tempererature. From OT_WARN_LIMIT register. +tempX_lcrit Critical low tempererature. + From UT_FAULT_LIMIT register. +tempX_crit Critical high tempererature. + From OT_FAULT_LIMIT register. +tempX_min_alarm Chip temperature low alarm. Set by comparing + READ_TEMPERATURE_X with UT_WARN_LIMIT if + TEMP_UT_WARNING status is set. +tempX_max_alarm Chip temperature high alarm. Set by comparing + READ_TEMPERATURE_X with OT_WARN_LIMIT if + TEMP_OT_WARNING status is set. +tempX_lcrit_alarm Chip temperature critical low alarm. Set by comparing + READ_TEMPERATURE_X with UT_FAULT_LIMIT if + TEMP_UT_FAULT status is set. +tempX_crit_alarm Chip temperature critical high alarm. Set by comparing + READ_TEMPERATURE_X with OT_FAULT_LIMIT if + TEMP_OT_FAULT status is set. diff --git a/Documentation/hwmon/w83795 b/Documentation/hwmon/w83795 new file mode 100644 index 000000000000..9f160371f463 --- /dev/null +++ b/Documentation/hwmon/w83795 @@ -0,0 +1,127 @@ +Kernel driver w83795 +==================== + +Supported chips: + * Winbond/Nuvoton W83795G + Prefix: 'w83795g' + Addresses scanned: I2C 0x2c - 0x2f + Datasheet: Available for download on nuvoton.com + * Winbond/Nuvoton W83795ADG + Prefix: 'w83795adg' + Addresses scanned: I2C 0x2c - 0x2f + Datasheet: Available for download on nuvoton.com + +Authors: + Wei Song (Nuvoton) + Jean Delvare <khali@linux-fr.org> + + +Pin mapping +----------- + +Here is a summary of the pin mapping for the W83795G and W83795ADG. +This can be useful to convert data provided by board manufacturers +into working libsensors configuration statements. + + W83795G | + Pin | Name | Register | Sysfs attribute +------------------------------------------------------------------ + 13 | VSEN1 (VCORE1) | 10h | in0 + 14 | VSEN2 (VCORE2) | 11h | in1 + 15 | VSEN3 (VCORE3) | 12h | in2 + 16 | VSEN4 | 13h | in3 + 17 | VSEN5 | 14h | in4 + 18 | VSEN6 | 15h | in5 + 19 | VSEN7 | 16h | in6 + 20 | VSEN8 | 17h | in7 + 21 | VSEN9 | 18h | in8 + 22 | VSEN10 | 19h | in9 + 23 | VSEN11 | 1Ah | in10 + 28 | VTT | 1Bh | in11 + 24 | 3VDD | 1Ch | in12 + 25 | 3VSB | 1Dh | in13 + 26 | VBAT | 1Eh | in14 + 3 | VSEN12/TR5 | 1Fh | in15/temp5 + 4 | VSEN13/TR5 | 20h | in16/temp6 + 5/ 6 | VDSEN14/TR1/TD1 | 21h | in17/temp1 + 7/ 8 | VDSEN15/TR2/TD2 | 22h | in18/temp2 + 9/ 10 | VDSEN16/TR3/TD3 | 23h | in19/temp3 + 11/ 12 | VDSEN17/TR4/TD4 | 24h | in20/temp4 + 40 | FANIN1 | 2Eh | fan1 + 42 | FANIN2 | 2Fh | fan2 + 44 | FANIN3 | 30h | fan3 + 46 | FANIN4 | 31h | fan4 + 48 | FANIN5 | 32h | fan5 + 50 | FANIN6 | 33h | fan6 + 52 | FANIN7 | 34h | fan7 + 54 | FANIN8 | 35h | fan8 + 57 | FANIN9 | 36h | fan9 + 58 | FANIN10 | 37h | fan10 + 59 | FANIN11 | 38h | fan11 + 60 | FANIN12 | 39h | fan12 + 31 | FANIN13 | 3Ah | fan13 + 35 | FANIN14 | 3Bh | fan14 + 41 | FANCTL1 | 10h (bank 2) | pwm1 + 43 | FANCTL2 | 11h (bank 2) | pwm2 + 45 | FANCTL3 | 12h (bank 2) | pwm3 + 47 | FANCTL4 | 13h (bank 2) | pwm4 + 49 | FANCTL5 | 14h (bank 2) | pwm5 + 51 | FANCTL6 | 15h (bank 2) | pwm6 + 53 | FANCTL7 | 16h (bank 2) | pwm7 + 55 | FANCTL8 | 17h (bank 2) | pwm8 + 29/ 30 | PECI/TSI (DTS1) | 26h | temp7 + 29/ 30 | PECI/TSI (DTS2) | 27h | temp8 + 29/ 30 | PECI/TSI (DTS3) | 28h | temp9 + 29/ 30 | PECI/TSI (DTS4) | 29h | temp10 + 29/ 30 | PECI/TSI (DTS5) | 2Ah | temp11 + 29/ 30 | PECI/TSI (DTS6) | 2Bh | temp12 + 29/ 30 | PECI/TSI (DTS7) | 2Ch | temp13 + 29/ 30 | PECI/TSI (DTS8) | 2Dh | temp14 + 27 | CASEOPEN# | 46h | intrusion0 + + W83795ADG | + Pin | Name | Register | Sysfs attribute +------------------------------------------------------------------ + 10 | VSEN1 (VCORE1) | 10h | in0 + 11 | VSEN2 (VCORE2) | 11h | in1 + 12 | VSEN3 (VCORE3) | 12h | in2 + 13 | VSEN4 | 13h | in3 + 14 | VSEN5 | 14h | in4 + 15 | VSEN6 | 15h | in5 + 16 | VSEN7 | 16h | in6 + 17 | VSEN8 | 17h | in7 + 22 | VTT | 1Bh | in11 + 18 | 3VDD | 1Ch | in12 + 19 | 3VSB | 1Dh | in13 + 20 | VBAT | 1Eh | in14 + 48 | VSEN12/TR5 | 1Fh | in15/temp5 + 1 | VSEN13/TR5 | 20h | in16/temp6 + 2/ 3 | VDSEN14/TR1/TD1 | 21h | in17/temp1 + 4/ 5 | VDSEN15/TR2/TD2 | 22h | in18/temp2 + 6/ 7 | VDSEN16/TR3/TD3 | 23h | in19/temp3 + 8/ 9 | VDSEN17/TR4/TD4 | 24h | in20/temp4 + 32 | FANIN1 | 2Eh | fan1 + 34 | FANIN2 | 2Fh | fan2 + 36 | FANIN3 | 30h | fan3 + 37 | FANIN4 | 31h | fan4 + 38 | FANIN5 | 32h | fan5 + 39 | FANIN6 | 33h | fan6 + 40 | FANIN7 | 34h | fan7 + 41 | FANIN8 | 35h | fan8 + 43 | FANIN9 | 36h | fan9 + 44 | FANIN10 | 37h | fan10 + 45 | FANIN11 | 38h | fan11 + 46 | FANIN12 | 39h | fan12 + 24 | FANIN13 | 3Ah | fan13 + 28 | FANIN14 | 3Bh | fan14 + 33 | FANCTL1 | 10h (bank 2) | pwm1 + 35 | FANCTL2 | 11h (bank 2) | pwm2 + 23 | PECI (DTS1) | 26h | temp7 + 23 | PECI (DTS2) | 27h | temp8 + 23 | PECI (DTS3) | 28h | temp9 + 23 | PECI (DTS4) | 29h | temp10 + 23 | PECI (DTS5) | 2Ah | temp11 + 23 | PECI (DTS6) | 2Bh | temp12 + 23 | PECI (DTS7) | 2Ch | temp13 + 23 | PECI (DTS8) | 2Dh | temp14 + 21 | CASEOPEN# | 46h | intrusion0 diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt new file mode 100644 index 000000000000..7dcd1a4e726c --- /dev/null +++ b/Documentation/hwspinlock.txt @@ -0,0 +1,293 @@ +Hardware Spinlock Framework + +1. Introduction + +Hardware spinlock modules provide hardware assistance for synchronization +and mutual exclusion between heterogeneous processors and those not operating +under a single, shared operating system. + +For example, OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP, +each of which is running a different Operating System (the master, A9, +is usually running Linux and the slave processors, the M3 and the DSP, +are running some flavor of RTOS). + +A generic hwspinlock framework allows platform-independent drivers to use +the hwspinlock device in order to access data structures that are shared +between remote processors, that otherwise have no alternative mechanism +to accomplish synchronization and mutual exclusion operations. + +This is necessary, for example, for Inter-processor communications: +on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the +remote M3 and/or C64x+ slave processors (by an IPC subsystem called Syslink). + +To achieve fast message-based communications, a minimal kernel support +is needed to deliver messages arriving from a remote processor to the +appropriate user process. + +This communication is based on simple data structures that is shared between +the remote processors, and access to it is synchronized using the hwspinlock +module (remote processor directly places new messages in this shared data +structure). + +A common hwspinlock interface makes it possible to have generic, platform- +independent, drivers. + +2. User API + + struct hwspinlock *hwspin_lock_request(void); + - dynamically assign an hwspinlock and return its address, or NULL + in case an unused hwspinlock isn't available. Users of this + API will usually want to communicate the lock's id to the remote core + before it can be used to achieve synchronization. + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + struct hwspinlock *hwspin_lock_request_specific(unsigned int id); + - assign a specific hwspinlock id and return its address, or NULL + if that hwspinlock is already in use. Usually board code will + be calling this function in order to reserve specific hwspinlock + ids for predefined purposes. + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + int hwspin_lock_free(struct hwspinlock *hwlock); + - free a previously-assigned hwspinlock; returns 0 on success, or an + appropriate error code on failure (e.g. -EINVAL if the hwspinlock + is already free). + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned int timeout); + - lock a previously-assigned hwspinlock with a timeout limit (specified in + msecs). If the hwspinlock is already taken, the function will busy loop + waiting for it to be released, but give up when the timeout elapses. + Upon a successful return from this function, preemption is disabled so + the caller must not sleep, and is advised to release the hwspinlock as + soon as possible, in order to minimize remote cores polling on the + hardware interconnect. + Returns 0 when successful and an appropriate error code otherwise (most + notably -ETIMEDOUT if the hwspinlock is still busy after timeout msecs). + The function will never sleep. + + int hwspin_lock_timeout_irq(struct hwspinlock *hwlock, unsigned int timeout); + - lock a previously-assigned hwspinlock with a timeout limit (specified in + msecs). If the hwspinlock is already taken, the function will busy loop + waiting for it to be released, but give up when the timeout elapses. + Upon a successful return from this function, preemption and the local + interrupts are disabled, so the caller must not sleep, and is advised to + release the hwspinlock as soon as possible. + Returns 0 when successful and an appropriate error code otherwise (most + notably -ETIMEDOUT if the hwspinlock is still busy after timeout msecs). + The function will never sleep. + + int hwspin_lock_timeout_irqsave(struct hwspinlock *hwlock, unsigned int to, + unsigned long *flags); + - lock a previously-assigned hwspinlock with a timeout limit (specified in + msecs). If the hwspinlock is already taken, the function will busy loop + waiting for it to be released, but give up when the timeout elapses. + Upon a successful return from this function, preemption is disabled, + local interrupts are disabled and their previous state is saved at the + given flags placeholder. The caller must not sleep, and is advised to + release the hwspinlock as soon as possible. + Returns 0 when successful and an appropriate error code otherwise (most + notably -ETIMEDOUT if the hwspinlock is still busy after timeout msecs). + The function will never sleep. + + int hwspin_trylock(struct hwspinlock *hwlock); + - attempt to lock a previously-assigned hwspinlock, but immediately fail if + it is already taken. + Upon a successful return from this function, preemption is disabled so + caller must not sleep, and is advised to release the hwspinlock as soon as + possible, in order to minimize remote cores polling on the hardware + interconnect. + Returns 0 on success and an appropriate error code otherwise (most + notably -EBUSY if the hwspinlock was already taken). + The function will never sleep. + + int hwspin_trylock_irq(struct hwspinlock *hwlock); + - attempt to lock a previously-assigned hwspinlock, but immediately fail if + it is already taken. + Upon a successful return from this function, preemption and the local + interrupts are disabled so caller must not sleep, and is advised to + release the hwspinlock as soon as possible. + Returns 0 on success and an appropriate error code otherwise (most + notably -EBUSY if the hwspinlock was already taken). + The function will never sleep. + + int hwspin_trylock_irqsave(struct hwspinlock *hwlock, unsigned long *flags); + - attempt to lock a previously-assigned hwspinlock, but immediately fail if + it is already taken. + Upon a successful return from this function, preemption is disabled, + the local interrupts are disabled and their previous state is saved + at the given flags placeholder. The caller must not sleep, and is advised + to release the hwspinlock as soon as possible. + Returns 0 on success and an appropriate error code otherwise (most + notably -EBUSY if the hwspinlock was already taken). + The function will never sleep. + + void hwspin_unlock(struct hwspinlock *hwlock); + - unlock a previously-locked hwspinlock. Always succeed, and can be called + from any context (the function never sleeps). Note: code should _never_ + unlock an hwspinlock which is already unlocked (there is no protection + against this). + + void hwspin_unlock_irq(struct hwspinlock *hwlock); + - unlock a previously-locked hwspinlock and enable local interrupts. + The caller should _never_ unlock an hwspinlock which is already unlocked. + Doing so is considered a bug (there is no protection against this). + Upon a successful return from this function, preemption and local + interrupts are enabled. This function will never sleep. + + void + hwspin_unlock_irqrestore(struct hwspinlock *hwlock, unsigned long *flags); + - unlock a previously-locked hwspinlock. + The caller should _never_ unlock an hwspinlock which is already unlocked. + Doing so is considered a bug (there is no protection against this). + Upon a successful return from this function, preemption is reenabled, + and the state of the local interrupts is restored to the state saved at + the given flags. This function will never sleep. + + int hwspin_lock_get_id(struct hwspinlock *hwlock); + - retrieve id number of a given hwspinlock. This is needed when an + hwspinlock is dynamically assigned: before it can be used to achieve + mutual exclusion with a remote cpu, the id number should be communicated + to the remote task with which we want to synchronize. + Returns the hwspinlock id number, or -EINVAL if hwlock is null. + +3. Typical usage + +#include <linux/hwspinlock.h> +#include <linux/err.h> + +int hwspinlock_example1(void) +{ + struct hwspinlock *hwlock; + int ret; + + /* dynamically assign a hwspinlock */ + hwlock = hwspin_lock_request(); + if (!hwlock) + ... + + id = hwspin_lock_get_id(hwlock); + /* probably need to communicate id to a remote processor now */ + + /* take the lock, spin for 1 sec if it's already taken */ + ret = hwspin_lock_timeout(hwlock, 1000); + if (ret) + ... + + /* + * we took the lock, do our thing now, but do NOT sleep + */ + + /* release the lock */ + hwspin_unlock(hwlock); + + /* free the lock */ + ret = hwspin_lock_free(hwlock); + if (ret) + ... + + return ret; +} + +int hwspinlock_example2(void) +{ + struct hwspinlock *hwlock; + int ret; + + /* + * assign a specific hwspinlock id - this should be called early + * by board init code. + */ + hwlock = hwspin_lock_request_specific(PREDEFINED_LOCK_ID); + if (!hwlock) + ... + + /* try to take it, but don't spin on it */ + ret = hwspin_trylock(hwlock); + if (!ret) { + pr_info("lock is already taken\n"); + return -EBUSY; + } + + /* + * we took the lock, do our thing now, but do NOT sleep + */ + + /* release the lock */ + hwspin_unlock(hwlock); + + /* free the lock */ + ret = hwspin_lock_free(hwlock); + if (ret) + ... + + return ret; +} + + +4. API for implementors + + int hwspin_lock_register(struct hwspinlock *hwlock); + - to be called from the underlying platform-specific implementation, in + order to register a new hwspinlock instance. Can be called from an atomic + context (this function will not sleep) but not from within interrupt + context. Returns 0 on success, or appropriate error code on failure. + + struct hwspinlock *hwspin_lock_unregister(unsigned int id); + - to be called from the underlying vendor-specific implementation, in order + to unregister an existing (and unused) hwspinlock instance. + Can be called from an atomic context (will not sleep) but not from + within interrupt context. + Returns the address of hwspinlock on success, or NULL on error (e.g. + if the hwspinlock is sill in use). + +5. struct hwspinlock + +This struct represents an hwspinlock instance. It is registered by the +underlying hwspinlock implementation using the hwspin_lock_register() API. + +/** + * struct hwspinlock - vendor-specific hwspinlock implementation + * + * @dev: underlying device, will be used with runtime PM api + * @ops: vendor-specific hwspinlock handlers + * @id: a global, unique, system-wide, index of the lock. + * @lock: initialized and used by hwspinlock core + * @owner: underlying implementation module, used to maintain module ref count + */ +struct hwspinlock { + struct device *dev; + const struct hwspinlock_ops *ops; + int id; + spinlock_t lock; + struct module *owner; +}; + +The underlying implementation is responsible to assign the dev, ops, id and +owner members. The lock member, OTOH, is initialized and used by the hwspinlock +core. + +6. Implementation callbacks + +There are three possible callbacks defined in 'struct hwspinlock_ops': + +struct hwspinlock_ops { + int (*trylock)(struct hwspinlock *lock); + void (*unlock)(struct hwspinlock *lock); + void (*relax)(struct hwspinlock *lock); +}; + +The first two callbacks are mandatory: + +The ->trylock() callback should make a single attempt to take the lock, and +return 0 on failure and 1 on success. This callback may _not_ sleep. + +The ->unlock() callback releases the lock. It always succeed, and it, too, +may _not_ sleep. + +The ->relax() callback is optional. It is called by hwspinlock core while +spinning on a lock, and can be used by the underlying implementation to force +a delay between two successive invocations of ->trylock(). It may _not_ sleep. diff --git a/Documentation/i2c/busses/i2c-diolan-u2c b/Documentation/i2c/busses/i2c-diolan-u2c new file mode 100644 index 000000000000..30fe4bb9a069 --- /dev/null +++ b/Documentation/i2c/busses/i2c-diolan-u2c @@ -0,0 +1,26 @@ +Kernel driver i2c-diolan-u2c + +Supported adapters: + * Diolan U2C-12 I2C-USB adapter + Documentation: + http://www.diolan.com/i2c/u2c12.html + +Author: Guenter Roeck <guenter.roeck@ericsson.com> + +Description +----------- + +This is the driver for the Diolan U2C-12 USB-I2C adapter. + +The Diolan U2C-12 I2C-USB Adapter provides a low cost solution to connect +a computer to I2C slave devices using a USB interface. It also supports +connectivity to SPI devices. + +This driver only supports the I2C interface of U2C-12. The driver does not use +interrupts. + + +Module parameters +----------------- + +* frequency: I2C bus frequency diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices index 87da405a8597..9edb75d8c9b9 100644 --- a/Documentation/i2c/instantiating-devices +++ b/Documentation/i2c/instantiating-devices @@ -100,7 +100,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev) (...) i2c_adap = i2c_get_adapter(2); memset(&i2c_info, 0, sizeof(struct i2c_board_info)); - strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE); + strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE); isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info, normal_i2c, NULL); i2c_put_adapter(i2c_adap); diff --git a/Documentation/i2c/upgrading-clients b/Documentation/i2c/upgrading-clients index 9a45f9bb6a25..d6991625c407 100644 --- a/Documentation/i2c/upgrading-clients +++ b/Documentation/i2c/upgrading-clients @@ -61,7 +61,7 @@ static int example_attach(struct i2c_adapter *adap, int addr, int kind) return 0; } -static int __devexit example_detach(struct i2c_client *client) +static int example_detach(struct i2c_client *client) { struct example_state *state = i2c_get_clientdata(client); @@ -81,7 +81,7 @@ static struct i2c_driver example_driver = { .name = "example", }, .attach_adapter = example_attach_adapter, - .detach_client = __devexit_p(example_detach), + .detach_client = example_detach, .suspend = example_suspend, .resume = example_resume, }; @@ -93,7 +93,7 @@ Updating the client The new style binding model will check against a list of supported devices and their associated address supplied by the code registering the busses. This means that the driver .attach_adapter and -.detach_adapter methods can be removed, along with the addr_data, +.detach_client methods can be removed, along with the addr_data, as follows: - static struct i2c_driver example_driver; @@ -110,14 +110,14 @@ as follows: static struct i2c_driver example_driver = { - .attach_adapter = example_attach_adapter, -- .detach_client = __devexit_p(example_detach), +- .detach_client = example_detach, } Add the probe and remove methods to the i2c_driver, as so: static struct i2c_driver example_driver = { + .probe = example_probe, -+ .remove = __devexit_p(example_remove), ++ .remove = example_remove, } Change the example_attach method to accept the new parameters @@ -199,8 +199,8 @@ to delete the i2c_detach_client call. It is possible that you can also remove the ret variable as it is not not needed for any of the core functions. -- static int __devexit example_detach(struct i2c_client *client) -+ static int __devexit example_remove(struct i2c_client *client) +- static int example_detach(struct i2c_client *client) ++ static int example_remove(struct i2c_client *client) { struct example_state *state = i2c_get_clientdata(client); @@ -253,7 +253,7 @@ static int example_probe(struct i2c_client *client, return 0; } -static int __devexit example_remove(struct i2c_client *client) +static int example_remove(struct i2c_client *client) { struct example_state *state = i2c_get_clientdata(client); @@ -275,7 +275,7 @@ static struct i2c_driver example_driver = { }, .id_table = example_idtable, .probe = example_probe, - .remove = __devexit_p(example_remove), + .remove = example_remove, .suspend = example_suspend, .resume = example_resume, }; diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index ac293e955308..e68543f767d5 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -133,6 +133,7 @@ Code Seq#(hex) Include File Comments 'H' C0-DF net/bluetooth/hidp/hidp.h conflict! 'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict! 'H' C0-DF net/bluetooth/bnep/bnep.h conflict! +'H' F1 linux/hid-roccat.h <mailto:erazor_de@users.sourceforge.net> 'I' all linux/isdn.h conflict! 'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict! 'I' 40-4F linux/mISDNif.h conflict! diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 89835a4766a6..f4a04c0c7edc 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -144,6 +144,11 @@ a fixed number of characters. This limit depends on the architecture and is between 256 and 4096 characters. It is defined in the file ./include/asm/setup.h as COMMAND_LINE_SIZE. +Finally, the [KMG] suffix is commonly described after a number of kernel +parameter values. These 'K', 'M', and 'G' letters represent the _binary_ +multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30 +bytes respectively. Such letter suffixes can also be entirely omitted. + acpi= [HW,ACPI,X86] Advanced Configuration and Power Interface @@ -545,16 +550,20 @@ and is between 256 and 4096 characters. It is defined in the file Format: <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] - crashkernel=nn[KMG]@ss[KMG] - [KNL] Reserve a chunk of physical memory to - hold a kernel to switch to with kexec on panic. + crashkernel=size[KMG][@offset[KMG]] + [KNL] Using kexec, Linux can switch to a 'crash kernel' + upon panic. This parameter reserves the physical + memory region [offset, offset + size] for that kernel + image. If '@offset' is omitted, then a suitable offset + is selected automatically. Check + Documentation/kdump/kdump.txt for further details. crashkernel=range1:size1[,range2:size2,...][@offset] [KNL] Same as above, but depends on the memory in the running system. The syntax of range is start-[end] where start and end are both a memory unit (amount[KMG]). See also - Documentation/kdump/kdump.txt for a example. + Documentation/kdump/kdump.txt for an example. cs89x0_dma= [HW,NET] Format: <dma> @@ -1262,10 +1271,9 @@ and is between 256 and 4096 characters. It is defined in the file 6 (KERN_INFO) informational 7 (KERN_DEBUG) debug-level messages - log_buf_len=n Sets the size of the printk ring buffer, in bytes. - Format: { n | nk | nM } - n must be a power of two. The default size - is set in the kernel config file. + log_buf_len=n[KMG] Sets the size of the printk ring buffer, + in bytes. n must be a power of two. The default + size is set in the kernel config file. logo.nologo [FB] Disables display of the built-in Linux logo. This may be used to provide more screen space for diff --git a/Documentation/hwmon/hpfall.c b/Documentation/laptops/hpfall.c index a4a8fc5d05d4..a4a8fc5d05d4 100644 --- a/Documentation/hwmon/hpfall.c +++ b/Documentation/laptops/hpfall.c diff --git a/Documentation/hwmon/lis3lv02d b/Documentation/misc-devices/lis3lv02d index 06534f25e643..f1a4ec840f86 100644 --- a/Documentation/hwmon/lis3lv02d +++ b/Documentation/misc-devices/lis3lv02d @@ -17,8 +17,8 @@ Description This driver provides support for the accelerometer found in various HP laptops sporting the feature officially called "HP Mobile Data Protection System 3D" or "HP 3D DriveGuard". It detects automatically laptops with this sensor. Known -models (full list can be found in drivers/hwmon/hp_accel.c) will have their -axis automatically oriented on standard way (eg: you can directly play +models (full list can be found in drivers/platform/x86/hp_accel.c) will have +their axis automatically oriented on standard way (eg: you can directly play neverball). The accelerometer data is readable via /sys/devices/platform/lis3lv02d. Reported values are scaled to mg values (1/1000th of earth gravity). diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index fe5c099b8fc8..4edd78dfb362 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -40,8 +40,6 @@ decnet.txt - info on using the DECnet networking layer in Linux. depca.txt - the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver -dgrs.txt - - the Digi International RightSwitch SE-X Ethernet driver dmfe.txt - info on the Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver. e100.txt @@ -50,8 +48,6 @@ e1000.txt - info on Intel's E1000 line of gigabit ethernet boards eql.txt - serial IP load balancing -ethertap.txt - - the Ethertap user space packet reception and transmission driver ewrk3.txt - the Digital EtherWORKS 3 DE203/4/5 Ethernet driver filter.txt @@ -104,8 +100,6 @@ tuntap.txt - TUN/TAP device driver, allowing user space Rx/Tx of packets. vortex.txt - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. -wavelan.txt - - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver x25.txt - general info on X.25 development. x25-iface.txt diff --git a/Documentation/networking/Makefile b/Documentation/networking/Makefile index 5aba7a33aeeb..24c308dd3fd1 100644 --- a/Documentation/networking/Makefile +++ b/Documentation/networking/Makefile @@ -4,6 +4,8 @@ obj- := dummy.o # List of programs to build hostprogs-y := ifenslave +HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include + # Tell kbuild to always build the programs always := $(hostprogs-y) diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt index 996a27d9b8db..01c513fac40e 100644 --- a/Documentation/workqueue.txt +++ b/Documentation/workqueue.txt @@ -190,9 +190,9 @@ resources, scheduled and executed. * Long running CPU intensive workloads which can be better managed by the system scheduler. - WQ_FREEZEABLE + WQ_FREEZABLE - A freezeable wq participates in the freeze phase of the system + A freezable wq participates in the freeze phase of the system suspend operations. Work items on the wq are drained and no new work item starts execution until thawed. |