leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'linus' into release

Browse Source 
Conflicts:
	arch/x86/kernel/acpi/sleep.c

Signed-off-by: Len Brown <len.brown@intel.com>
This commit is contained in:
Len Brown 2011-03-23 02:34:54 -04:00
commit 02e2407858
6870 changed files with 628441 additions and 403361 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Documentation/00-INDEX
View File

@ -328,8 +328,6 @@ sysrq.txt
- info on the magic SysRq key.
telephony/
- directory with info on telephony (e.g. voice over IP) support.
time_interpolators.txt
- info on time interpolators.
uml/
- directory with information about User Mode Linux.
unicode.txt
@ -346,8 +344,6 @@ vm/
- directory with info on the Linux vm code.
volatile-considered-harmful.txt
- Why the "volatile" type class should not be used
voyager.txt
- guide to running Linux on the Voyager architecture.
w1/
- directory with documents regarding the 1-wire (w1) subsystem.
watchdog/

20
Documentation/ABI/stable/sysfs-class-backlight
View File

@ -34,3 +34,23 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Maximum brightness for <backlight>.
Users: HAL
What: /sys/class/backlight/<backlight>/type
Date: September 2010
KernelVersion: 2.6.37
Contact: Matthew Garrett <mjg@redhat.com>
Description:
The type of interface controlled by <backlight>.
"firmware": The driver uses a standard firmware interface
"platform": The driver uses a platform-specific interface
"raw": The driver controls hardware registers directly
In the general case, when multiple backlight
interfaces are available for a single device, firmware
control should be preferred to platform control should
be preferred to raw control. Using a firmware
interface reduces the probability of confusion with
the hardware and the OS independently updating the
backlight state. Platform interfaces are mostly a
holdover from pre-standardisation of firmware
interfaces.

75
Documentation/ABI/stable/sysfs-firmware-efi-vars Normal file
View File

@ -0,0 +1,75 @@
What: /sys/firmware/efi/vars
Date: April 2004
Contact: Matt Domsch <Matt_Domsch@dell.com>
Description:
This directory exposes interfaces for interactive with
EFI variables. For more information on EFI variables,
see 'Variable Services' in the UEFI specification
(section 7.2 in specification version 2.3 Errata D).
In summary, EFI variables are named, and are classified
into separate namespaces through the use of a vendor
GUID. They also have an arbitrary binary value
associated with them.
The efivars module enumerates these variables and
creates a separate directory for each one found. Each
directory has a name of the form "<key>-<vendor guid>"
and contains the following files:
attributes: A read-only text file enumerating the
EFI variable flags. Potential values
include:
EFI_VARIABLE_NON_VOLATILE
EFI_VARIABLE_BOOTSERVICE_ACCESS
EFI_VARIABLE_RUNTIME_ACCESS
EFI_VARIABLE_HARDWARE_ERROR_RECORD
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
See the EFI documentation for an
explanation of each of these variables.
data: A read-only binary file that can be read
to attain the value of the EFI variable
guid: The vendor GUID of the variable. This
should always match the GUID in the
variable's name.
raw_var: A binary file that can be read to obtain
a structure that contains everything
there is to know about the variable.
For structure definition see "struct
efi_variable" in the kernel sources.
This file can also be written to in
order to update the value of a variable.
For this to work however, all fields of
the "struct efi_variable" passed must
match byte for byte with the structure
read out of the file, save for the value
portion.
**Note** the efi_variable structure
read/written with this file contains a
'long' type that may change widths
depending on your underlying
architecture.
size: As ASCII representation of the size of
the variable's value.
In addition, two other magic binary files are provided
in the top-level directory and are used for adding and
removing variables:
new_var: Takes a "struct efi_variable" and
instructs the EFI firmware to create a
new variable.
del_var: Takes a "struct efi_variable" and
instructs the EFI firmware to remove any
variable that has a matching vendor GUID
and variable key name.

31
Documentation/ABI/testing/configfs-spear-pcie-gadget Normal file
View File

@ -0,0 +1,31 @@
What: /config/pcie-gadget
Date: Feb 2011
KernelVersion: 2.6.37
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Interface is used to configure selected dual mode PCIe controller
as device and then program its various registers to configure it
as a particular device type.
This interfaces can be used to show spear's PCIe device capability.
Nodes are only visible when configfs is mounted. To mount configfs
in /config directory use:
# mount -t configfs none /config/
For nth PCIe Device Controller
/config/pcie-gadget.n/
link ... used to enable ltssm and read its status.
int_type ...used to configure and read type of supported
interrupt
no_of_msi ... used to configure number of MSI vector needed and
to read no of MSI granted.
inta ... write 1 to assert INTA and 0 to de-assert.
send_msi ... write MSI vector to be sent.
vendor_id ... used to write and read vendor id (hex)
device_id ... used to write and read device id (hex)
bar0_size ... used to write and read bar0_size
bar0_address ... used to write and read bar0 mapped area in hex.
bar0_rw_offset ... used to write and read offset of bar0 where
bar0_data will be written or read.
bar0_data ... used to write and read data at bar0_rw_offset.

41
Documentation/ABI/testing/pstore Normal file
View File

@ -0,0 +1,41 @@
Where: /dev/pstore/...
Date: March 2011
Kernel Version: 2.6.39
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 -o kmsg_bytes=8000 - /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.
The 'kmsg_bytes' mount option changes the target amount of
data saved on each oops/panic. Pstore saves (possibly
multiple) files based on the record size of the underlying
persistent storage until at least this amount is reached.
Default is 10 Kbytes.

31
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -145,9 +145,11 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given name(SMBIOS type 41 string) of the PCI device.
The attribute will be created only if the firmware
has given a name to the PCI device.
given name (SMBIOS type 41 string or ACPI _DSM string) of
the PCI device. The attribute will be created only
if the firmware has given a name to the PCI device.
ACPI _DSM string name will be given priority if the
system firmware provides SMBIOS type 41 string also.
Users:
Userspace applications interested in knowing the
firmware assigned name of the PCI device.
@ -157,12 +159,27 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given instance(SMBIOS type 41 device type instance)
of the PCI device. The attribute will be created
only if the firmware has given a device type instance
to the PCI device.
given instance (SMBIOS type 41 device type instance) of the
PCI device. The attribute will be created only if the firmware
has given an instance number to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
What: /sys/bus/pci/devices/.../acpi_index
Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given instance (ACPI _DSM instance number) of the PCI device.
The attribute will be created only if the firmware has given
an instance number to the PCI device. ACPI _DSM instance number
will be given priority if the system firmware provides SMBIOS
type 41 device type instance also.
Users:
Userspace applications interested in knowing the
firmware assigned instance number of the PCI
device that can help in understanding the firmware
intended order of the PCI device.

2
Documentation/ABI/testing/sysfs-bus-rbd
View File

@ -1,6 +1,6 @@
What: /sys/bus/rbd/
Date: November 2010
Contact: Yehuda Sadeh <yehuda@hq.newdream.net>,
Contact: Yehuda Sadeh <yehuda@newdream.net>,
Sage Weil <sage@newdream.net>
Description:

21
Documentation/ABI/testing/sysfs-devices-mmc Normal file
View File

@ -0,0 +1,21 @@
What: /sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_offset
Date: January 2011
Contact: Chuanxiao Dong <chuanxiao.dong@intel.com>
Description:
Enhanced area is a new feature defined in eMMC4.4 standard.
eMMC4.4 or later card can support such feature. This kind of
area can help to improve the card performance. If the feature
is enabled, this attribute will indicate the start address of
enhanced data area. If not, this attribute will be -EINVAL.
Unit Byte. Format decimal.
What: /sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_size
Date: January 2011
Contact: Chuanxiao Dong <chuanxiao.dong@intel.com>
Description:
Enhanced area is a new feature defined in eMMC4.4 standard.
eMMC4.4 or later card can support such feature. This kind of
area can help to improve the card performance. If the feature
is enabled, this attribute will indicate the size of enhanced
data area. If not, this attribute will be -EINVAL.
Unit KByte. Format decimal.

20
Documentation/ABI/testing/sysfs-devices-power
View File

@ -29,9 +29,8 @@ Description:
"disabled" to it.
For the devices that are not capable of generating system wakeup
events this file contains "\n". In that cases the user space
cannot modify the contents of this file and the device cannot be
enabled to wake up the system.
events this file is not present. In that case the device cannot
be enabled to wake up the system from sleep states.
What: /sys/devices/.../power/control
Date: January 2009
@ -85,7 +84,7 @@ Description:
The /sys/devices/.../wakeup_count attribute contains the number
of signaled wakeup events associated with the device. This
attribute is read-only. If the device is not enabled to wake up
the system from sleep states, this attribute is empty.
the system from sleep states, this attribute is not present.
What: /sys/devices/.../power/wakeup_active_count
Date: September 2010
@ -95,7 +94,7 @@ Description:
number of times the processing of wakeup events associated with
the device was completed (at the kernel level). This attribute
is read-only. If the device is not enabled to wake up the
system from sleep states, this attribute is empty.
system from sleep states, this attribute is not present.
What: /sys/devices/.../power/wakeup_hit_count
Date: September 2010
@ -105,7 +104,8 @@ Description:
number of times the processing of a wakeup event associated with
the device might prevent the system from entering a sleep state.
This attribute is read-only. If the device is not enabled to
wake up the system from sleep states, this attribute is empty.
wake up the system from sleep states, this attribute is not
present.
What: /sys/devices/.../power/wakeup_active
Date: September 2010
@ -115,7 +115,7 @@ Description:
or 0, depending on whether or not a wakeup event associated with
the device is being processed (1). This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
states, this attribute is not present.
What: /sys/devices/.../power/wakeup_total_time_ms
Date: September 2010
@ -125,7 +125,7 @@ Description:
the total time of processing wakeup events associated with the
device, in milliseconds. This attribute is read-only. If the
device is not enabled to wake up the system from sleep states,
this attribute is empty.
this attribute is not present.
What: /sys/devices/.../power/wakeup_max_time_ms
Date: September 2010
@ -135,7 +135,7 @@ Description:
the maximum time of processing a single wakeup event associated
with the device, in milliseconds. This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
states, this attribute is not present.
What: /sys/devices/.../power/wakeup_last_time_ms
Date: September 2010
@ -146,7 +146,7 @@ Description:
signaling the last wakeup event associated with the device, in
milliseconds. This attribute is read-only. If the device is
not enabled to wake up the system from sleep states, this
attribute is empty.
attribute is not present.
What: /sys/devices/.../power/autosuspend_delay_ms
Date: September 2010

10
Documentation/ABI/testing/sysfs-driver-hid Normal file
View File

@ -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)

53
Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo Normal file
View File

@ -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

8
Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
View File

@ -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

11
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
View File

@ -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

100
Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus Normal file
View File

@ -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

9
Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
View File

@ -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

110
Documentation/ABI/testing/sysfs-firmware-dmi Normal file
View File

@ -0,0 +1,110 @@
What: /sys/firmware/dmi/
Date: February 2011
Contact: Mike Waychison <mikew@google.com>
Description:
Many machines' firmware (x86 and ia64) export DMI /
SMBIOS tables to the operating system. Getting at this
information is often valuable to userland, especially in
cases where there are OEM extensions used.
The kernel itself does not rely on the majority of the
information in these tables being correct. It equally
cannot ensure that the data as exported to userland is
without error either.
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as 'handle' that is
supposed to be unique amongst all entries.
Some entries are required by the specification, but many
others are optional. In general though, users should
never expect to find a specific entry type on their
system unless they know for certain what their firmware
is doing. Machine to machine will vary.
Multiple entries of the same type are allowed. In order
to handle these duplicate entry types, each entry is
assigned by the operating system an 'instance', which is
derived from an entry type's ordinal position. That is
to say, if there are 'N' multiple entries with the same type
'T' in the DMI tables (adjacent or spread apart, it
doesn't matter), they will be represented in sysfs as
entries "T-0" through "T-(N-1)":
Example entry directories:
/sys/firmware/dmi/entries/17-0
/sys/firmware/dmi/entries/17-1
/sys/firmware/dmi/entries/17-2
/sys/firmware/dmi/entries/17-3
...
Instance numbers are used in lieu of the firmware
assigned entry handles as the kernel itself makes no
guarantees that handles as exported are unique, and
there are likely firmware images that get this wrong in
the wild.
Each DMI entry in sysfs has the common header values
exported as attributes:
handle : The 16bit 'handle' that is assigned to this
entry by the firmware. This handle may be
referred to by other entries.
length : The length of the entry, as presented in the
entry itself. Note that this is _not the
total count of bytes associated with the
entry_. This value represents the length of
the "formatted" portion of the entry. This
"formatted" region is sometimes followed by
the "unformatted" region composed of nul
terminated strings, with termination signalled
by a two nul characters in series.
raw : The raw bytes of the entry. This includes the
"formatted" portion of the entry, the
"unformatted" strings portion of the entry,
and the two terminating nul characters.
type : The type of the entry. This value is the same
as found in the directory name. It indicates
how the rest of the entry should be
interpreted.
instance: The instance ordinal of the entry for the
given type. This value is the same as found
in the parent directory name.
position: The position of the entry within the entirety
of the entirety.
=== Entry Specialization ===
Some entry types may have other information available in
sysfs.
--- Type 15 - System Event Log ---
This entry allows the firmware to export a log of
events the system has taken. This information is
typically backed by nvram, but the implementation
details are abstracted by this table. This entries data
is exported in the directory:
/sys/firmware/dmi/entries/15-0/system_event_log
and has the following attributes (documented in the
SMBIOS / DMI specification under "System Event Log (Type 15)":
area_length
header_start_offset
data_start_offset
access_method
status
change_token
access_method_address
header_format
per_log_type_descriptor_length
type_descriptors_supported_count
As well, the kernel exports the binary attribute:
raw_event_log : The raw binary bits of the event log
as described by the DMI entry.

48
Documentation/ABI/testing/sysfs-platform-kim Normal file
View File

@ -0,0 +1,48 @@
What: /sys/devices/platform/kim/dev_name
Date: January 2010
KernelVersion: 2.6.38
Contact: "Pavan Savoy" <pavan_savoy@ti.com>
Description:
Name of the UART device at which the WL128x chip
is connected. example: "/dev/ttyS0".
The device name flows down to architecture specific board
initialization file from the SFI/ATAGS bootloader
firmware. The name exposed is read from the user-space
dameon and opens the device when install is requested.
What: /sys/devices/platform/kim/baud_rate
Date: January 2010
KernelVersion: 2.6.38
Contact: "Pavan Savoy" <pavan_savoy@ti.com>
Description:
The maximum reliable baud-rate the host can support.
Different platforms tend to have different high-speed
UART configurations, so the baud-rate needs to be set
locally and also sent across to the WL128x via a HCI-VS
command. The entry is read and made use by the user-space
daemon when the ldisc install is requested.
What: /sys/devices/platform/kim/flow_cntrl
Date: January 2010
KernelVersion: 2.6.38
Contact: "Pavan Savoy" <pavan_savoy@ti.com>
Description:
The WL128x makes use of flow control mechanism, and this
entry most often should be 1, the host's UART is required
to have the capability of flow-control, or else this
entry can be made use of for exceptions.
What: /sys/devices/platform/kim/install
Date: January 2010
KernelVersion: 2.6.38
Contact: "Pavan Savoy" <pavan_savoy@ti.com>
Description:
When one of the protocols Bluetooth, FM or GPS wants to make
use of the shared UART transport, it registers to the shared
transport driver, which will signal the user-space for opening,
configuring baud and install line discipline via this sysfs
entry. This entry would be polled upon by the user-space
daemon managing the UART, and is notified about the change
by the sysfs_notify. The value would be '1' when UART needs
to be opened/ldisc installed, and would be '0' when UART
is no more required and needs to be closed.

8
Documentation/Changes
View File

@ -35,7 +35,7 @@ o util-linux 2.10o # fdformat --version
o module-init-tools 0.9.10 # depmod -V
o e2fsprogs 1.41.4 # e2fsck -V
o jfsutils 1.1.3 # fsck.jfs -V
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
o reiserfsprogs 3.6.3 # reiserfsck -V
o xfsprogs 2.6.0 # xfs_db -V
o squashfs-tools 4.0 # mksquashfs -version
o btrfs-progs 0.18 # btrfsck
@ -46,9 +46,9 @@ o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
o nfs-utils 1.0.5 # showmount --version
o procps 3.2.0 # ps --version
o oprofile 0.9 # oprofiled --version
o udev 081 # udevinfo -V
o grub 0.93 # grub --version
o mcelog 0.6
o udev 081 # udevd --version
o grub 0.93 # grub --version || grub-install --version
o mcelog 0.6 # mcelog --version
o iptables 1.4.2 # iptables -V

12
Documentation/CodingStyle
View File

@ -168,6 +168,13 @@ Do not unnecessarily use braces where a single statement will do.
if (condition)
action();
and
if (condition)
do_this();
else
do_that();
This does not apply if one branch of a conditional statement is a single
statement. Use braces in both branches.
@ -659,7 +666,7 @@ There are a number of driver model diagnostic macros in <linux/device.h>
which you should use to make sure messages are matched to the right device
and driver, and are tagged with the right level: dev_err(), dev_warn(),
dev_info(), and so forth. For messages that aren't associated with a
particular device, <linux/kernel.h> defines pr_debug() and pr_info().
particular device, <linux/printk.h> defines pr_debug() and pr_info().
Coming up with good debugging messages can be quite a challenge; and once
you have them, they can be a huge help for remote troubleshooting. Such
@ -819,6 +826,3 @@ language C, URL: http://www.open-std.org/JTC1/SC22/WG14/
Kernel CodingStyle, by greg@kroah.com at OLS 2002:
http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
--
Last updated on 2007-July-13.

31
Documentation/RCU/whatisRCU.txt
View File

@ -849,6 +849,37 @@ All: lockdep-checked RCU-protected pointer access
See the comment headers in the source code (or the docbook generated
from them) for more information.
However, given that there are no fewer than four families of RCU APIs
in the Linux kernel, how do you choose which one to use? The following
list can be helpful:
a. Will readers need to block? If so, you need SRCU.
b. What about the -rt patchset? If readers would need to block
in an non-rt kernel, you need SRCU. If readers would block
in a -rt kernel, but not in a non-rt kernel, SRCU is not
necessary.
c. Do you need to treat NMI handlers, hardirq handlers,
and code segments with preemption disabled (whether
via preempt_disable(), local_irq_save(), local_bh_disable(),
or some other mechanism) as if they were explicit RCU readers?
If so, you need RCU-sched.
d. Do you need RCU grace periods to complete even in the face
of softirq monopolization of one or more of the CPUs? For
example, is your code subject to network-based denial-of-service
attacks? If so, you need RCU-bh.
e. Is your workload too update-intensive for normal use of
RCU, but inappropriate for other synchronization mechanisms?
If so, consider SLAB_DESTROY_BY_RCU. But please be careful!
f. Otherwise, use RCU.
Of course, this all assumes that you have determined that RCU is in fact
the right tool for your job.
8. ANSWERS TO QUICK QUIZZES

8
Documentation/arm/SH-Mobile/Makefile Normal file
View File

@ -0,0 +1,8 @@
BIN := vrl4
.PHONY: all
all: $(BIN)
.PHONY: clean
clean:
rm -f *.o $(BIN)

169
Documentation/arm/SH-Mobile/vrl4.c Normal file
View File

@ -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;
}

29
Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt Normal file
View File

@ -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.

61
Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen
View File

@ -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.

32
Documentation/arm/Sharp-LH/CompactFlash
View File

@ -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.

45
Documentation/arm/Sharp-LH/IOBarrier
View File

@ -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.

8
Documentation/arm/Sharp-LH/KEV7A400
View File

@ -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.

59
Documentation/arm/Sharp-LH/LCDPanels
View File

@ -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.

15
Documentation/arm/Sharp-LH/LPD7A400
View File

@ -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.

16
Documentation/arm/Sharp-LH/LPD7A40X
View File

@ -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.

51
Documentation/arm/Sharp-LH/SDRAM
View File

@ -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.

80
Documentation/arm/Sharp-LH/VectoredInterruptController
View File

@ -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)

12
Documentation/cgroups/cgroups.txt
View File

@ -349,6 +349,10 @@ To mount a cgroup hierarchy with all available subsystems, type:
The "xxx" is not interpreted by the cgroup code, but will appear in
/proc/mounts so may be any useful identifying string that you like.
Note: Some subsystems do not work without some user input first. For instance,
if cpusets are enabled the user will have to populate the cpus and mems files
for each new cgroup created before that group can be used.
To mount a cgroup hierarchy with just the cpuset and memory
subsystems, type:
# mount -t cgroup -o cpuset,memory hier1 /dev/cgroup
@ -426,6 +430,14 @@ You can attach the current shell task by echoing 0:
# echo 0 > tasks
Note: Since every task is always a member of exactly one cgroup in each
mounted hierarchy, to remove a task from its current cgroup you must
move it into a new cgroup (possibly the root cgroup) by writing to the
new cgroup's tasks file.
Note: If the ns cgroup is active, moving a process to another cgroup can
fail.
2.3 Mounting hierarchies by name
--------------------------------

17
Documentation/cgroups/cpusets.txt
View File

@ -693,7 +693,7 @@ There are ways to query or modify cpusets:
- via the C library libcgroup.
(http://sourceforge.net/projects/libcg/)
- via the python application cset.
(http://developer.novell.com/wiki/index.php/Cpuset)
(http://code.google.com/p/cpuset/)
The sched_setaffinity calls can also be done at the shell prompt using
SGI's runon or Robert Love's taskset. The mbind and set_mempolicy
@ -725,13 +725,14 @@ Now you want to do something with this cpuset.
In this directory you can find several files:
# ls
cpuset.cpu_exclusive cpuset.memory_spread_slab
cpuset.cpus cpuset.mems
cpuset.mem_exclusive cpuset.sched_load_balance
cpuset.mem_hardwall cpuset.sched_relax_domain_level
cpuset.memory_migrate notify_on_release
cpuset.memory_pressure tasks
cpuset.memory_spread_page
cgroup.clone_children cpuset.memory_pressure
cgroup.event_control cpuset.memory_spread_page
cgroup.procs cpuset.memory_spread_slab
cpuset.cpu_exclusive cpuset.mems
cpuset.cpus cpuset.sched_load_balance
cpuset.mem_exclusive cpuset.sched_relax_domain_level
cpuset.mem_hardwall notify_on_release
cpuset.memory_migrate tasks
Reading them will give you information about the state of this cpuset:
the CPUs and Memory Nodes it can use, the processes that are using

5
Documentation/cgroups/memory.txt
View File

@ -485,8 +485,9 @@ The feature can be disabled by
# echo 0 > memory.use_hierarchy
NOTE1: Enabling/disabling will fail if the cgroup already has other
cgroups created below it.
NOTE1: Enabling/disabling will fail if either the cgroup already has other
cgroups created below it, or if the parent cgroup has use_hierarchy
enabled.
NOTE2: When panic_on_oom is set to "2", the whole system will panic in
case of an OOM event in any cgroup.

11
Documentation/cpu-freq/governors.txt
View File

@ -158,6 +158,17 @@ intensive calculation on your laptop that you do not care how long it
takes to complete as you can 'nice' it and prevent it from taking part
in the deciding process of whether to increase your CPU frequency.
sampling_down_factor: this parameter controls the rate at which the
kernel makes a decision on when to decrease the frequency while running
at top speed. When set to 1 (the default) decisions to reevaluate load
are made at the same interval regardless of current clock speed. But
when set to greater than 1 (e.g. 100) it acts as a multiplier for the
scheduling interval for reevaluating load when the CPU is at its top
speed due to high load. This improves performance by reducing the overhead
of load evaluation and helping the CPU stay at its top speed when truly
busy, rather than shifting back and forth in speed. This tunable has no
effect on behavior at lower speeds/lower CPU loads.
2.5 Conservative
----------------

2
Documentation/device-mapper/dm-crypt.txt
View File

@ -41,7 +41,7 @@ Example scripts
===============
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
encryption with dm-crypt using the 'cryptsetup' utility, see
http://clemens.endorphin.org/cryptography
http://code.google.com/p/cryptsetup/
[[
#!/bin/sh

10
Documentation/devicetree/00-INDEX Normal file
View File

@ -0,0 +1,10 @@
Documentation for device trees, a data structure by which bootloaders pass
hardware layout to Linux in a device-independent manner, simplifying hardware
probing. This subsystem is maintained by Grant Likely
<grant.likely@secretlab.ca> and has a mailing list at
https://lists.ozlabs.org/listinfo/devicetree-discuss
00-INDEX
- this file
booting-without-of.txt
- Booting Linux without Open Firmware, describes history and format of device trees.

73
Documentation/devicetree/bindings/hwmon/ads1015.txt Normal file
View File

@ -0,0 +1,73 @@
ADS1015 (I2C)
This device is a 12-bit A-D converter with 4 inputs.
The inputs can be used single ended or in certain differential combinations.
For configuration all possible combinations are mapped to 8 channels:
0: Voltage over AIN0 and AIN1.
1: Voltage over AIN0 and AIN3.
2: Voltage over AIN1 and AIN3.
3: Voltage over AIN2 and AIN3.
4: Voltage over AIN0 and GND.
5: Voltage over AIN1 and GND.
6: Voltage over AIN2 and GND.
7: Voltage over AIN3 and GND.
Each channel can be configured individually:
- pga is the programmable gain amplifier (values are full scale)
0: +/- 6.144 V
1: +/- 4.096 V
2: +/- 2.048 V (default)
3: +/- 1.024 V
4: +/- 0.512 V
5: +/- 0.256 V
- data_rate in samples per second
0: 128
1: 250
2: 490
3: 920
4: 1600 (default)
5: 2400
6: 3300
1) The /ads1015 node
Required properties:
- compatible : must be "ti,ads1015"
- reg : I2C bus address of the device
- #address-cells : must be <1>
- #size-cells : must be <0>
The node contains child nodes for each channel that the platform uses.
Example ADS1015 node:
ads1015@49 {
compatible = "ti,ads1015";
reg = <0x49>;
#address-cells = <1>;
#size-cells = <0>;
[ child node definitions... ]
}
2) channel nodes
Required properties:
- reg : the channel number
Optional properties:
- ti,gain : the programmable gain amplifier setting
- ti,datarate : the converter data rate
Example ADS1015 channel node:
channel@4 {
reg = <4>;
ti,gain = <3>;
ti,datarate = <5>;
};

93
Documentation/devicetree/bindings/i2c/ce4100-i2c.txt Normal file
View File

@ -0,0 +1,93 @@
CE4100 I2C
----------
CE4100 has one PCI device which is described as the I2C-Controller. This
PCI device has three PCI-bars, each bar contains a complete I2C
controller. So we have a total of three independent I2C-Controllers
which share only an interrupt line.
The driver is probed via the PCI-ID and is gathering the information of
attached devices from the devices tree.
Grant Likely recommended to use the ranges property to map the PCI-Bar
number to its physical address and to use this to find the child nodes
of the specific I2C controller. This were his exact words:
Here's where the magic happens. Each entry in
ranges describes how the parent pci address space
(middle group of 3) is translated to the local
address space (first group of 2) and the size of
each range (last cell). In this particular case,
the first cell of the local address is chosen to be
1:1 mapped to the BARs, and the second is the
offset from be base of the BAR (which would be
non-zero if you had 2 or more devices mapped off
the same BAR)
ranges allows the address mapping to be described
in a way that the OS can interpret without
requiring custom device driver code.
This is an example which is used on FalconFalls:
------------------------------------------------
i2c-controller@b,2 {
#address-cells = <2>;
#size-cells = <1>;
compatible = "pci8086,2e68.2",
"pci8086,2e68",
"pciclass,ff0000",
"pciclass,ff00";
reg = <0x15a00 0x0 0x0 0x0 0x0>;
interrupts = <16 1>;
/* as described by Grant, the first number in the group of
* three is the bar number followed by the 64bit bar address
* followed by size of the mapping. The bar address
* requires also a valid translation in parents ranges
* property.
*/
ranges = <0 0 0x02000000 0 0xdffe0500 0x100
1 0 0x02000000 0 0xdffe0600 0x100
2 0 0x02000000 0 0xdffe0700 0x100>;
i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "intel,ce4100-i2c-controller";
/* The first number in the reg property is the
* number of the bar
*/
reg = <0 0 0x100>;
/* This I2C controller has no devices */
};
i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "intel,ce4100-i2c-controller";
reg = <1 0 0x100>;
/* This I2C controller has one gpio controller */
gpio@26 {
#gpio-cells = <2>;
compatible = "ti,pcf8575";
reg = <0x26>;
gpio-controller;
};
};
i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "intel,ce4100-i2c-controller";
reg = <2 0 0x100>;
gpio@26 {
#gpio-cells = <2>;
compatible = "ti,pcf8575";
reg = <0x26>;
gpio-controller;
};
};
};

9
Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt
View File

@ -7,8 +7,13 @@ Required properties:
- voltage-ranges : two cells are required, first cell specifies minimum
slot voltage (mV), second cell specifies maximum slot voltage (mV).
Several ranges could be specified.
- gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO,
Optional properties:
- gpios : may specify GPIOs in this order: Card-Detect GPIO,
Write-Protect GPIO.
- interrupts : the interrupt of a card detect interrupt.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
Example:
@ -20,4 +25,6 @@ Example:
&qe_pio_d 15 0>;
voltage-ranges = <3300 3300>;
spi-max-frequency = <50000000>;
interrupts = <42>;
interrupt-parent = <&PIC>;
};

98
Documentation/devicetree/bindings/open-pic.txt Normal file
View File

@ -0,0 +1,98 @@
* Open PIC Binding
This binding specifies what properties must be available in the device tree
representation of an Open PIC compliant interrupt controller. This binding is
based on the binding defined for Open PIC in [1] and is a superset of that
binding.
Required properties:
NOTE: Many of these descriptions were paraphrased here from [1] to aid
readability.
- compatible: Specifies the compatibility list for the PIC. The type
shall be <string> and the value shall include "open-pic".
- reg: Specifies the base physical address(s) and size(s) of this
PIC's addressable register space. The type shall be <prop-encoded-array>.
- interrupt-controller: The presence of this property identifies the node
as an Open PIC. No property value shall be defined.
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 2.
- #address-cells: Specifies the number of cells needed to encode an
address. The type shall be <u32> and the value shall be 0. As such,
'interrupt-map' nodes do not have to specify a parent unit address.
Optional properties:
- pic-no-reset: The presence of this property indicates that the PIC
shall not be reset during runtime initialization. No property value shall
be defined. The presence of this property also mandates that any
initialization related to interrupt sources shall be limited to sources
explicitly referenced in the device tree.
* Interrupt Specifier Definition
Interrupt specifiers consists of 2 cells encoded as
follows:
- <1st-cell>: The interrupt-number that identifies the interrupt source.
- <2nd-cell>: The level-sense information, encoded as follows:
0 = low-to-high edge triggered
1 = active low level-sensitive
2 = active high level-sensitive
3 = high-to-low edge triggered
* Examples
Example 1:
/*
* An Open PIC interrupt controller
*/
mpic: pic@40000 {
// This is an interrupt controller node.
interrupt-controller;
// No address cells so that 'interrupt-map' nodes which reference
// this Open PIC node do not need a parent address specifier.
#address-cells = <0>;
// Two cells to encode interrupt sources.
#interrupt-cells = <2>;
// Offset address of 0x40000 and size of 0x40000.
reg = <0x40000 0x40000>;
// Compatible with Open PIC.
compatible = "open-pic";
// The PIC shall not be reset.
pic-no-reset;
};
Example 2:
/*
* An interrupt generating device that is wired to an Open PIC.
*/
serial0: serial@4500 {
// Interrupt source '42' that is active high level-sensitive.
// Note that there are only two cells as specified in the interrupt
// parent's '#interrupt-cells' property.
interrupts = <42 2>;
// The interrupt controller that this device is wired to.
interrupt-parent = <&mpic>;
};
* References
[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform
Requirements (ePAPR), Version 1.0, July 2008.
(http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf)

20
Documentation/devicetree/bindings/powerpc/fsl/cache_sram.txt Normal file
View File

@ -0,0 +1,20 @@
* Freescale PQ3 and QorIQ based Cache SRAM
Freescale's mpc85xx and some QorIQ platforms provide an
option of configuring a part of (or full) cache memory
as SRAM. This cache SRAM representation in the device
tree should be done as under:-
Required properties:
- compatible : should be "fsl,p2020-cache-sram"
- fsl,cache-sram-ctlr-handle : points to the L2 controller
- reg : offset and length of the cache-sram.
Example:
cache-sram@fff00000 {
fsl,cache-sram-ctlr-handle = <&L2>;
reg = <0 0xfff00000 0 0x10000>;
compatible = "fsl,p2020-cache-sram";
};

241
Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
View File

@ -1,42 +1,211 @@
* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores
=====================================================================
Freescale MPIC Interrupt Controller Node
Copyright (C) 2010,2011 Freescale Semiconductor Inc.
=====================================================================
The OpenPIC specification does not specify which interrupt source has to
become which interrupt number. This is up to the software implementation
of the interrupt controller. The only requirement is that every
interrupt source has to have an unique interrupt number / vector number.
To accomplish this the current implementation assigns the number zero to
the first source, the number one to the second source and so on until
all interrupt sources have their unique number.
Usually the assigned vector number equals the interrupt number mentioned
in the documentation for a given core / CPU. This is however not true
for the e500 cores (MPC85XX CPUs) where the documentation distinguishes
between internal and external interrupt sources and starts counting at
zero for both of them.
The Freescale MPIC interrupt controller is found on all PowerQUICC
and QorIQ processors and is compatible with the Open PIC. The
notable difference from Open PIC binding is the addition of 2
additional cells in the interrupt specifier defining interrupt type
information.
So what to write for external interrupt source X or internal interrupt
source Y into the device tree? Here is an example:
PROPERTIES
The memory map for the interrupt controller in the MPC8544[0] shows,
that the first interrupt source starts at 0x5_0000 (PIC Register Address
Map-Interrupt Source Configuration Registers). This source becomes the
number zero therefore:
External interrupt 0 = interrupt number 0
External interrupt 1 = interrupt number 1
External interrupt 2 = interrupt number 2
...
Every interrupt number allocates 0x20 bytes register space. So to get
its number it is sufficient to shift the lower 16bits to right by five.
So for the external interrupt 10 we have:
0x0140 >> 5 = 10
- compatible
Usage: required
Value type: <string>
Definition: Shall include "fsl,mpic". Freescale MPIC
controllers compatible with this binding have Block
Revision Registers BRR1 and BRR2 at offset 0x0 and
0x10 in the MPIC.
After the external sources, the internal sources follow. The in core I2C
controller on the MPC8544 for instance has the internal source number
27. Oo obtain its interrupt number we take the lower 16bits of its memory
address (0x5_0560) and shift it right:
0x0560 >> 5 = 43
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical
offset and length of the device's registers within the
CCSR address space.
Therefore the I2C device node for the MPC8544 CPU has to have the
interrupt number 43 specified in the device tree.
- interrupt-controller
Usage: required
Value type: <empty>
Definition: Specifies that this node is an interrupt
controller
[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual
MPC8544ERM Rev. 1 10/2007
- #interrupt-cells
Usage: required
Value type: <u32>
Definition: Shall be 2 or 4. A value of 2 means that interrupt
specifiers do not contain the interrupt-type or type-specific
information cells.
- #address-cells
Usage: required
Value type: <u32>
Definition: Shall be 0.
- pic-no-reset
Usage: optional
Value type: <empty>
Definition: The presence of this property specifies that the
MPIC must not be reset by the client program, and that
the boot program has initialized all interrupt source
configuration registers to a sane state-- masked or
directed at other cores. This ensures that the client
program will not receive interrupts for sources not belonging
to the client. The presence of this property also mandates
that any initialization related to interrupt sources shall
be limited to sources explicitly referenced in the device tree.
INTERRUPT SPECIFIER DEFINITION
Interrupt specifiers consists of 4 cells encoded as
follows:
<1st-cell> interrupt-number
Identifies the interrupt source. The meaning
depends on the type of interrupt.
Note: If the interrupt-type cell is undefined
(i.e. #interrupt-cells = 2), this cell
should be interpreted the same as for
interrupt-type 0-- i.e. an external or
normal SoC device interrupt.
<2nd-cell> level-sense information, encoded as follows:
0 = low-to-high edge triggered
1 = active low level-sensitive
2 = active high level-sensitive
3 = high-to-low edge triggered
<3rd-cell> interrupt-type
The following types are supported:
0 = external or normal SoC device interrupt
The interrupt-number cell contains
the SoC device interrupt number. The
type-specific cell is undefined. The
interrupt-number is derived from the
MPIC a block of registers referred to as
the "Interrupt Source Configuration Registers".
Each source has 32-bytes of registers
(vector/priority and destination) in this
region. So interrupt 0 is at offset 0x0,
interrupt 1 is at offset 0x20, and so on.
1 = error interrupt
The interrupt-number cell contains
the SoC device interrupt number for
the error interrupt. The type-specific
cell identifies the specific error
interrupt number.
2 = MPIC inter-processor interrupt (IPI)
The interrupt-number cell identifies
the MPIC IPI number. The type-specific
cell is undefined.
3 = MPIC timer interrupt
The interrupt-number cell identifies
the MPIC timer number. The type-specific
cell is undefined.
<4th-cell> type-specific information
The type-specific cell is encoded as follows:
- For interrupt-type 1 (error interrupt),
the type-specific cell contains the
bit number of the error interrupt in the
Error Interrupt Summary Register.
EXAMPLE 1
/*
* mpic interrupt controller with 4 cells per specifier
*/
mpic: pic@40000 {
compatible = "fsl,mpic";
interrupt-controller;
#interrupt-cells = <4>;
#address-cells = <0>;
reg = <0x40000 0x40000>;
};
EXAMPLE 2
/*
* The MPC8544 I2C controller node has an internal
* interrupt number of 27. As per the reference manual
* this corresponds to interrupt source configuration
* registers at 0x5_0560.
*
* The interrupt source configuration registers begin
* at 0x5_0000.
*
* To compute the interrupt specifier interrupt number
*
* 0x560 >> 5 = 43
*
* The interrupt source configuration registers begin
* at 0x5_0000, and so the i2c vector/priority registers
* are at 0x5_0560.
*/
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
};
EXAMPLE 3
/*
* Definition of a node defining the 4
* MPIC IPI interrupts. Note the interrupt
* type of 2.
*/
ipi@410a0 {
compatible = "fsl,mpic-ipi";
reg = <0x40040 0x10>;
interrupts = <0 0 2 0
1 0 2 0
2 0 2 0
3 0 2 0>;
};
EXAMPLE 4
/*
* Definition of a node defining the MPIC
* global timers. Note the interrupt
* type of 3.
*/
timer0: timer@41100 {
compatible = "fsl,mpic-global-timer";
reg = <0x41100 0x100>;
interrupts = <0 0 3 0
1 0 3 0
2 0 3 0
3 0 3 0>;
};
EXAMPLE 5
/*
* Definition of an error interrupt (interupt type 1).
* SoC interrupt number is 16 and the specific error
* interrupt bit in the error interrupt summary register
* is 23.
*/
memory-controller@8000 {
compatible = "fsl,p4080-memory-controller";
reg = <0x8000 0x1000>;
interrupts = <16 2 1 23>;
};

9
Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
View File

@ -5,14 +5,21 @@ Required properties:
first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
the parent type.
- reg : should contain the address and the length of the shared message
interrupt register set.
- msi-available-ranges: use <start count> style section to define which
msi interrupt can be used in the 256 msi interrupts. This property is
optional, without this, all the 256 MSI interrupts can be used.
Each available range must begin and end on a multiple of 32 (i.e.
no splitting an individual MSI register or the associated PIC interrupt).
- interrupts : each one of the interrupts here is one entry per 32 MSIs,
and routed to the host interrupt controller. the interrupts should
be set as edge sensitive.
be set as edge sensitive. If msi-available-ranges is present, only
the interrupts that correspond to available ranges shall be present.
- interrupt-parent: the phandle for the interrupt controller
that services interrupts for this device. for 83xx cpu, the interrupts
are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed

28
Documentation/devicetree/bindings/rtc/rtc-cmos.txt Normal file
View File

@ -0,0 +1,28 @@
Motorola mc146818 compatible RTC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Required properties:
- compatible : "motorola,mc146818"
- reg : should contain registers location and length.
Optional properties:
- interrupts : should contain interrupt.
- interrupt-parent : interrupt source phandle.
- ctrl-reg : Contains the initial value of the control register also
called "Register B".
- freq-reg : Contains the initial value of the frequency register also
called "Regsiter A".
"Register A" and "B" are usually initialized by the firmware (BIOS for
instance). If this is not done, it can be performed by the driver.
ISA Example:
rtc@70 {
compatible = "motorola,mc146818";
interrupts = <8 3>;
interrupt-parent = <&ioapic1>;
ctrl-reg = <2>;
freq-reg = <0x26>;
reg = <1 0x70 2>;
};

4
Documentation/devicetree/bindings/serial/altera_jtaguart.txt Normal file
View File

@ -0,0 +1,4 @@
Altera JTAG UART
Required properties:
- compatible : should be "ALTR,juart-1.0"

7
Documentation/devicetree/bindings/serial/altera_uart.txt Normal file
View File

@ -0,0 +1,7 @@
Altera UART
Required properties:
- compatible : should be "ALTR,uart-1.0"
Optional properties:
- clock-frequency : frequency of the clock input to the UART

4
Documentation/devicetree/bindings/serio/altera_ps2.txt Normal file
View File

@ -0,0 +1,4 @@
Altera UP PS/2 controller
Required properties:
- compatible : should be "ALTR,ps2-1.0".

4
Documentation/devicetree/bindings/spi/spi_altera.txt Normal file
View File

@ -0,0 +1,4 @@
Altera SPI
Required properties:
- compatible : should be "ALTR,spi-1.0".

12
Documentation/devicetree/bindings/spi/spi_oc_tiny.txt Normal file
View File

@ -0,0 +1,12 @@
OpenCores tiny SPI
Required properties:
- compatible : should be "opencores,tiny-spi-rtlsvn2".
- gpios : should specify GPIOs used for chipselect.
Optional properties:
- clock-frequency : input clock frequency to the core.
- baud-width: width, in bits, of the programmable divider used to scale
the input clock to SCLK.
The clock-frequency and baud-width properties are needed only if the divider
is programmable. They are not needed if the divider is fixed.

38
Documentation/devicetree/bindings/x86/ce4100.txt Normal file
View File

@ -0,0 +1,38 @@
CE4100 Device Tree Bindings
---------------------------
The CE4100 SoC uses for in core peripherals the following compatible
format: <vendor>,<chip>-<device>.
Many of the "generic" devices like HPET or IO APIC have the ce4100
name in their compatible property because they first appeared in this
SoC.
The CPU node
------------
cpu@0 {
device_type = "cpu";
compatible = "intel,ce4100";
reg = <0>;
lapic = <&lapic0>;
};
The reg property describes the CPU number. The lapic property points to
the local APIC timer.
The SoC node
------------
This node describes the in-core peripherals. Required property:
compatible = "intel,ce4100-cp";
The PCI node
------------
This node describes the PCI bus on the SoC. Its property should be
compatible = "intel,ce4100-pci", "pci";
If the OS is using the IO-APIC for interrupt routing then the reported
interrupt numbers for devices is no longer true. In order to obtain the
correct interrupt number, the child node which represents the device has
to contain the interrupt property. Besides the interrupt property it has
to contain at least the reg property containing the PCI bus address and
compatible property according to "PCI Bus Binding Revision 2.1".

26
Documentation/devicetree/bindings/x86/interrupt.txt Normal file
View File

@ -0,0 +1,26 @@
Interrupt chips
---------------
* Intel I/O Advanced Programmable Interrupt Controller (IO APIC)
Required properties:
--------------------
compatible = "intel,ce4100-ioapic";
#interrupt-cells = <2>;
Device's interrupt property:
interrupts = <P S>;
The first number (P) represents the interrupt pin which is wired to the
IO APIC. The second number (S) represents the sense of interrupt which
should be configured and can be one of:
0 - Edge Rising
1 - Level Low
2 - Level High
3 - Edge Falling
* Local APIC
Required property:
compatible = "intel,ce4100-lapic";

6
Documentation/devicetree/bindings/x86/timer.txt Normal file
View File

@ -0,0 +1,6 @@
Timers
------
* High Precision Event Timer (HPET)
Required property:
compatible = "intel,ce4100-hpet";

20
Documentation/devicetree/booting-without-of.txt
View File

@ -13,6 +13,7 @@ Table of Contents
I - Introduction
1) Entry point for arch/powerpc
2) Entry point for arch/x86
II - The DT block format
1) Header
@ -225,6 +226,25 @@ it with special cases.
cannot support both configurations with Book E and configurations
with classic Powerpc architectures.
2) Entry point for arch/x86
-------------------------------
There is one single 32bit entry point to the kernel at code32_start,
the decompressor (the real mode entry point goes to the same 32bit
entry point once it switched into protected mode). That entry point
supports one calling convention which is documented in
Documentation/x86/boot.txt
The physical pointer to the device-tree block (defined in chapter II)
is passed via setup_data which requires at least boot protocol 2.09.
The type filed is defined as
#define SETUP_DTB 2
This device-tree is used as an extension to the "boot page". As such it
does not parse / consider data which is already covered by the boot
page. This includes memory size, reserved ranges, command line arguments
or initrd address. It simply holds information which can not be retrieved
otherwise like interrupt routing or a list of devices behind an I2C bus.
II - The DT block format
========================

12
Documentation/dynamic-debug-howto.txt
View File

@ -205,12 +205,20 @@ of the characters:
The flags are:
f
Include the function name in the printed message
l
Include line number in the printed message
m
Include module name in the printed message
p
Causes a printk() message to be emitted to dmesg
t
Include thread ID in messages not generated from interrupt context
Note the regexp ^[-+=][scp]+$ matches a flags specification.
Note the regexp ^[-+=][flmpt]+$ matches a flags specification.
Note also that there is no convenient syntax to remove all
the flags at once, you need to use "-psc".
the flags at once, you need to use "-flmpt".
Debug messages during boot process

45
Documentation/feature-removal-schedule.txt
View File

@ -35,6 +35,17 @@ Who: Luis R. Rodriguez <lrodriguez@atheros.com>
---------------------------
What: AR9170USB
When: 2.6.40
Why: This driver is deprecated and the firmware is no longer
maintained. The replacement driver "carl9170" has been
around for a while, so the devices are still supported.
Who: Christian Lamparter <chunkeey@googlemail.com>
---------------------------
What: IRQF_SAMPLE_RANDOM
Check: IRQF_SAMPLE_RANDOM
When: July 2009
@ -566,16 +577,6 @@ Who: NeilBrown <neilb@suse.de>
----------------------------
What: i2c_adapter.id
When: June 2011
Why: This field is deprecated. I2C device drivers shouldn't change their
behavior based on the underlying I2C adapter. Instead, the I2C
adapter driver should instantiate the I2C devices and provide the
needed platform-specific information.
Who: Jean Delvare <khali@linux-fr.org>
----------------------------
What: cancel_rearming_delayed_work[queue]()
When: 2.6.39
@ -596,6 +597,13 @@ Who: Jean Delvare <khali@linux-fr.org>
----------------------------
What: xt_connlimit rev 0
When: 2012
Who: Jan Engelhardt <jengelh@medozas.de>
Files: net/netfilter/xt_connlimit.c
----------------------------
What: noswapaccount kernel command line parameter
When: 2.6.40
Why: The original implementation of memsw feature enabled by
@ -611,3 +619,20 @@ Why: The original implementation of memsw feature enabled by
Who: Michal Hocko <mhocko@suse.cz>
----------------------------
What: ipt_addrtype match include file
When: 2012
Why: superseded by xt_addrtype
Who: Florian Westphal <fw@strlen.de>
Files: include/linux/netfilter_ipv4/ipt_addrtype.h
----------------------------
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>
----------------------------

6
Documentation/filesystems/Locking
View File

@ -166,13 +166,11 @@ prototypes:
void (*kill_sb) (struct super_block *);
locking rules:
may block
get_sb yes
mount yes
kill_sb yes
->get_sb() returns error or 0 with locked superblock attached to the vfsmount
(exclusive on ->s_umount).
->mount() returns ERR_PTR or the root dentry.
->mount() returns ERR_PTR or the root dentry; its superblock should be locked
on return.
->kill_sb() takes a write-locked superblock, does all shutdown work on it,
unlocks and drops the reference.

18
Documentation/filesystems/adfs.txt
View File

@ -9,6 +9,9 @@ Mount options for ADFS
will be nnn. Default 0700.
othmask=nnn The permission mask for ADFS 'other' permissions
will be nnn. Default 0077.
ftsuffix=n When ftsuffix=0, no file type suffix will be applied.
When ftsuffix=1, a hexadecimal suffix corresponding to
the RISC OS file type will be added. Default 0.
Mapping of ADFS permissions to Linux permissions
------------------------------------------------
@ -55,3 +58,18 @@ Mapping of ADFS permissions to Linux permissions
You can therefore tailor the permission translation to whatever you
desire the permissions should be under Linux.
RISC OS file type suffix
------------------------
RISC OS file types are stored in bits 19..8 of the file load address.
To enable non-RISC OS systems to be used to store files without losing
file type information, a file naming convention was devised (initially
for use with NFS) such that a hexadecimal suffix of the form ,xyz
denoted the file type: e.g. BasicFile,ffb is a BASIC (0xffb) file. This
naming convention is now also used by RISC OS emulators such as RPCEmu.
Mounting an ADFS disc with option ftsuffix=1 will cause appropriate file
type suffixes to be appended to file names read from a directory. If the
ftsuffix option is zero or omitted, no file type suffixes will be added.

7
Documentation/filesystems/nfs/pnfs.txt
View File

@ -46,3 +46,10 @@ data server cache
file driver devices refer to data servers, which are kept in a module
level cache. Its reference is held over the lifetime of the deviceid
pointing to it.
lseg
----
lseg maintains an extra reference corresponding to the NFS_LSEG_VALID
bit which holds it in the pnfs_layout_hdr's list. When the final lseg
is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED
bit is set, preventing any new lsegs from being added.

7
Documentation/filesystems/porting
View File

@ -394,3 +394,10 @@ file) you must return -EOPNOTSUPP if FALLOC_FL_PUNCH_HOLE is set in mode.
Currently you can only have FALLOC_FL_PUNCH_HOLE with FALLOC_FL_KEEP_SIZE set,
so the i_size should not change when hole punching, even when puching the end of
a file off.
--
[mandatory]
->get_sb() is gone. Switch to use of ->mount(). Typically it's just
a matter of switching from calling get_sb_... to mount_... and changing the
function type. If you were doing it manually, just switch from setting ->mnt_root
to some pointer to returning that pointer. On errors return ERR_PTR(...).

3
Documentation/filesystems/romfs.txt
View File

@ -17,8 +17,7 @@ comparison, an actual rescue disk used up 3202 blocks with ext2, while
with romfs, it needed 3079 blocks.
To create such a file system, you'll need a user program named
genromfs. It is available via anonymous ftp on sunsite.unc.edu and
its mirrors, in the /pub/Linux/system/recovery/ directory.
genromfs. It is available on http://romfs.sourceforge.net/
As the name suggests, romfs could be also used (space-efficiently) on
various read-only media, like (E)EPROM disks if someone will have the

16
Documentation/filesystems/sysfs.txt
View File

@ -39,10 +39,12 @@ userspace. Top-level directories in sysfs represent the common
ancestors of object hierarchies; i.e. the subsystems the objects
belong to.
Sysfs internally stores the kobject that owns the directory in the
->d_fsdata pointer of the directory's dentry. This allows sysfs to do
reference counting directly on the kobject when the file is opened and
closed.
Sysfs internally stores a pointer to the kobject that implements a
directory in the sysfs_dirent object associated with the directory. In
the past this kobject pointer has been used by sysfs to do reference
counting directly on the kobject whenever the file is opened or closed.
With the current sysfs implementation the kobject reference count is
only modified directly by the function sysfs_schedule_callback().
Attributes
@ -208,9 +210,9 @@ Other notes:
is 4096.
- show() methods should return the number of bytes printed into the
buffer. This is the return value of snprintf().
buffer. This is the return value of scnprintf().
- show() should always use snprintf().
- show() should always use scnprintf().
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
@ -229,7 +231,7 @@ A very simple (and naive) implementation of a device attribute is:
static ssize_t show_name(struct device *dev, struct device_attribute *attr,
char *buf)
{
return snprintf(buf, PAGE_SIZE, "%s\n", dev->name);
return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name);
}
static ssize_t store_name(struct device *dev, struct device_attribute *attr,

4
Documentation/filesystems/ubifs.txt
View File

@ -82,12 +82,12 @@ Mount options
bulk_read read more in one go to take advantage of flash
media that read faster sequentially
no_bulk_read (*) do not bulk-read
no_chk_data_crc skip checking of CRCs on data nodes in order to
no_chk_data_crc (*) skip checking of CRCs on data nodes in order to
improve read performance. Use this option only
if the flash media is highly reliable. The effect
of this option is that corruption of the contents
of a file can go unnoticed.
chk_data_crc (*) do not skip checking CRCs on data nodes
chk_data_crc do not skip checking CRCs on data nodes
compr=none override default compressor and set it to "none"
compr=lzo override default compressor and set it to "lzo"
compr=zlib override default compressor and set it to "zlib"

62
Documentation/filesystems/vfs.txt
View File

@ -95,10 +95,11 @@ functions:
extern int unregister_filesystem(struct file_system_type *);
The passed struct file_system_type describes your filesystem. When a
request is made to mount a device onto a directory in your filespace,
the VFS will call the appropriate get_sb() method for the specific
filesystem. The dentry for the mount point will then be updated to
point to the root inode for the new filesystem.
request is made to mount a filesystem onto a directory in your namespace,
the VFS will call the appropriate mount() method for the specific
filesystem. New vfsmount refering to the tree returned by ->mount()
will be attached to the mountpoint, so that when pathname resolution
reaches the mountpoint it will jump into the root of that vfsmount.
You can see all filesystems that are registered to the kernel in the
file /proc/filesystems.
@ -107,14 +108,14 @@ file /proc/filesystems.
struct file_system_type
-----------------------
This describes the filesystem. As of kernel 2.6.22, the following
This describes the filesystem. As of kernel 2.6.39, the following
members are defined:
struct file_system_type {
const char *name;
int fs_flags;
int (*get_sb) (struct file_system_type *, int,
const char *, void *, struct vfsmount *);
struct dentry (*mount) (struct file_system_type *, int,
const char *, void *);
void (*kill_sb) (struct super_block *);
struct module *owner;
struct file_system_type * next;
@ -128,11 +129,11 @@ struct file_system_type {
fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.)
get_sb: the method to call when a new instance of this
mount: the method to call when a new instance of this
filesystem should be mounted
kill_sb: the method to call when an instance of this filesystem
should be unmounted
should be shut down
owner: for internal VFS use: you should initialize this to THIS_MODULE in
most cases.
@ -141,7 +142,7 @@ struct file_system_type {
s_lock_key, s_umount_key: lockdep-specific
The get_sb() method has the following arguments:
The mount() method has the following arguments:
struct file_system_type *fs_type: describes the filesystem, partly initialized
by the specific filesystem code
@ -153,32 +154,39 @@ The get_sb() method has the following arguments:
void *data: arbitrary mount options, usually comes as an ASCII
string (see "Mount Options" section)
struct vfsmount *mnt: a vfs-internal representation of a mount point
The mount() method must return the root dentry of the tree requested by
caller. An active reference to its superblock must be grabbed and the
superblock must be locked. On failure it should return ERR_PTR(error).
The get_sb() method must determine if the block device specified
in the dev_name and fs_type contains a filesystem of the type the method
supports. If it succeeds in opening the named block device, it initializes a
struct super_block descriptor for the filesystem contained by the block device.
On failure it returns an error.
The arguments match those of mount(2) and their interpretation
depends on filesystem type. E.g. for block filesystems, dev_name is
interpreted as block device name, that device is opened and if it
contains a suitable filesystem image the method creates and initializes
struct super_block accordingly, returning its root dentry to caller.
->mount() may choose to return a subtree of existing filesystem - it
doesn't have to create a new one. The main result from the caller's
point of view is a reference to dentry at the root of (sub)tree to
be attached; creation of new superblock is a common side effect.
The most interesting member of the superblock structure that the
get_sb() method fills in is the "s_op" field. This is a pointer to
mount() method fills in is the "s_op" field. This is a pointer to
a "struct super_operations" which describes the next level of the
filesystem implementation.
Usually, a filesystem uses one of the generic get_sb() implementations
and provides a fill_super() method instead. The generic methods are:
Usually, a filesystem uses one of the generic mount() implementations
and provides a fill_super() callback instead. The generic variants are:
get_sb_bdev: mount a filesystem residing on a block device
mount_bdev: mount a filesystem residing on a block device
get_sb_nodev: mount a filesystem that is not backed by a device
mount_nodev: mount a filesystem that is not backed by a device
get_sb_single: mount a filesystem which shares the instance between
mount_single: mount a filesystem which shares the instance between
all mounts
A fill_super() method implementation has the following arguments:
A fill_super() callback implementation has the following arguments:
struct super_block *sb: the superblock structure. The method fill_super()
struct super_block *sb: the superblock structure. The callback
must initialize this properly.
void *data: arbitrary mount options, usually comes as an ASCII
@ -865,7 +873,7 @@ struct dentry_operations {
void (*d_iput)(struct dentry *, struct inode *);
char *(*d_dname)(struct dentry *, char *, int);
struct vfsmount *(*d_automount)(struct path *);
int (*d_manage)(struct dentry *, bool, bool);
int (*d_manage)(struct dentry *, bool);
};
d_revalidate: called when the VFS needs to revalidate a dentry. This
@ -961,10 +969,6 @@ struct dentry_operations {
mounted on it and not to check the automount flag. Any other error
code will abort pathwalk completely.
If the 'mounting_here' parameter is true, then namespace_sem is being
held by the caller and the function should not initiate any mounts or
unmounts that it will then wait for.
If the 'rcu_walk' parameter is true, then the caller is doing a
pathwalk in RCU-walk mode. Sleeping is not permitted in this mode,
and the caller can be asked to leave it and call again by returing

7
Documentation/filesystems/xfs-delayed-logging-design.txt
View File

@ -791,10 +791,3 @@ mount option. Fundamentally, there is no reason why the log manager would not
be able to swap methods automatically and transparently depending on load
characteristics, but this should not be necessary if delayed logging works as
designed.
Roadmap:
2.6.39 Switch default mount option to use delayed logging
=> should be roughly 12 months after initial merge
=> enough time to shake out remaining problems before next round of
enterprise distro kernel rebases

72
Documentation/hwmon/ads1015 Normal file
View File

@ -0,0 +1,72 @@
Kernel driver ads1015
=====================
Supported chips:
* Texas Instruments ADS1015
Prefix: 'ads1015'
Datasheet: Publicly available at the Texas Instruments website :
http://focus.ti.com/lit/ds/symlink/ads1015.pdf
Authors:
Dirk Eibach, Guntermann & Drunck GmbH <eibach@gdsys.de>
Description
-----------
This driver implements support for the Texas Instruments ADS1015.
This device is a 12-bit A-D converter with 4 inputs.
The inputs can be used single ended or in certain differential combinations.
The inputs can be made available by 8 sysfs input files in0_input - in7_input:
in0: Voltage over AIN0 and AIN1.
in1: Voltage over AIN0 and AIN3.
in2: Voltage over AIN1 and AIN3.
in3: Voltage over AIN2 and AIN3.
in4: Voltage over AIN0 and GND.
in5: Voltage over AIN1 and GND.
in6: Voltage over AIN2 and GND.
in7: Voltage over AIN3 and GND.
Which inputs are available can be configured using platform data or devicetree.
By default all inputs are exported.
Platform Data
-------------
In linux/i2c/ads1015.h platform data is defined, channel_data contains
configuration data for the used input combinations:
- pga is the programmable gain amplifier (values are full scale)
0: +/- 6.144 V
1: +/- 4.096 V
2: +/- 2.048 V
3: +/- 1.024 V
4: +/- 0.512 V
5: +/- 0.256 V
- data_rate in samples per second
0: 128
1: 250
2: 490
3: 920
4: 1600
5: 2400
6: 3300
Example:
struct ads1015_platform_data data = {
.channel_data = {
[2] = { .enabled = true, .pga = 1, .data_rate = 0 },
[4] = { .enabled = true, .pga = 4, .data_rate = 5 },
}
};
In this case only in2_input (FS +/- 4.096 V, 128 SPS) and in4_input
(FS +/- 0.512 V, 2400 SPS) would be created.
Devicetree
----------
Configuration is also possible via devicetree:
Documentation/devicetree/bindings/hwmon/ads1015.txt

16
Documentation/hwmon/f71882fg
View File

@ -10,6 +10,10 @@ Supported chips:
Prefix: 'f71862fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71869F and F71869E
Prefix: 'f71869'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71882FG and F71883FG
Prefix: 'f71882fg'
Addresses scanned: none, address read from Super I/O config space
@ -17,6 +21,10 @@ Supported chips:
* Fintek F71889FG
Prefix: 'f71889fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71889ED
Prefix: 'f71889ed'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Should become available on the Fintek website soon
* Fintek F8000
Prefix: 'f8000'
@ -29,9 +37,9 @@ Author: Hans de Goede <hdegoede@redhat.com>
Description
-----------
Fintek F718xxFG/F8000 Super I/O chips include complete hardware monitoring
capabilities. They can monitor up to 9 voltages (3 for the F8000), 4 fans and
3 temperature sensors.
Fintek F718xx/F8000 Super I/O chips include complete hardware monitoring
capabilities. They can monitor up to 9 voltages, 4 fans and 3 temperature
sensors.
These chips also have fan controlling features, using either DC or PWM, in
three different modes (one manual, two automatic).
@ -99,5 +107,5 @@ Writing an unsupported mode will result in an invalid parameter error.
The fan speed is regulated to keep the temp the fan is mapped to between
temp#_auto_point2_temp and temp#_auto_point3_temp.
Both of the automatic modes require that pwm1 corresponds to fan1, pwm2 to
All of the automatic modes require that pwm1 corresponds to fan1, pwm2 to
fan2 and pwm3 to fan3.

77
Documentation/hwmon/lineage-pem Normal file
View File

@ -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

92
Documentation/hwmon/lis3lv02d
View File

@ -1,92 +0,0 @@
Kernel driver lis3lv02d
=======================
Supported chips:
* STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
* STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
Authors:
Yan Burman <burman.yan@gmail.com>
Eric Piel <eric.piel@tremplin-utc.net>
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
neverball). The accelerometer data is readable via
/sys/devices/platform/lis3lv02d. Reported values are scaled
to mg values (1/1000th of earth gravity).
Sysfs attributes under /sys/devices/platform/lis3lv02d/:
position - 3D position that the accelerometer reports. Format: "(x,y,z)"
rate - read reports the sampling rate of the accelerometer device in HZ.
write changes sampling rate of the accelerometer device.
Only values which are supported by HW are accepted.
selftest - performs selftest for the chip as specified by chip manufacturer.
This driver also provides an absolute input class device, allowing
the laptop to act as a pinball machine-esque joystick. Joystick device can be
calibrated. Joystick device can be in two different modes.
By default output values are scaled between -32768 .. 32767. In joystick raw
mode, joystick and sysfs position entry have the same scale. There can be
small difference due to input system fuzziness feature.
Events are also available as input event device.
Selftest is meant only for hardware diagnostic purposes. It is not meant to be
used during normal operations. Position data is not corrupted during selftest
but interrupt behaviour is not guaranteed to work reliably. In test mode, the
sensing element is internally moved little bit. Selftest measures difference
between normal mode and test mode. Chip specifications tell the acceptance
limit for each type of the chip. Limits are provided via platform data
to allow adjustment of the limits without a change to the actual driver.
Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are
measured difference between modes. Axes are not remapped in selftest mode.
Measurement values are provided to help HW diagnostic applications to make
final decision.
On HP laptops, if the led infrastructure is activated, support for a led
indicating disk protection will be provided as /sys/class/leds/hp::hddprotect.
Another feature of the driver is misc device called "freefall" that
acts similar to /dev/rtc and reacts on free-fall interrupts received
from the device. It supports blocking operations, poll/select and
fasync operation modes. You must read 1 bytes from the device. The
result is number of free-fall interrupts since the last successful
read (or 255 if number of interrupts would not fit). See the hpfall.c
file for an example on using the device.
Axes orientation
----------------
For better compatibility between the various laptops. The values reported by
the accelerometer are converted into a "standard" organisation of the axes
(aka "can play neverball out of the box"):
* When the laptop is horizontal the position reported is about 0 for X and Y
and a positive value for Z
* If the left side is elevated, X increases (becomes positive)
* If the front side (where the touchpad is) is elevated, Y decreases
(becomes negative)
* If the laptop is put upside-down, Z becomes negative
If your laptop model is not recognized (cf "dmesg"), you can send an
email to the maintainer to add it to the database. When reporting a new
laptop, please include the output of "dmidecode" plus the value of
/sys/devices/platform/lis3lv02d/position in these four cases.
Q&A
---
Q: How do I safely simulate freefall? I have an HP "portable
workstation" which has about 3.5kg and a plastic case, so letting it
fall to the ground is out of question...
A: The sensor is pretty sensitive, so your hands can do it. Lift it
into free space, follow the fall with your hands for like 10
centimeters. That should be enough to trigger the detection.

5
Documentation/hwmon/lm75
View File

@ -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

12
Documentation/hwmon/lm85
View File

@ -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
-----------------------

47
Documentation/hwmon/ltc4151 Normal file
View File

@ -0,0 +1,47 @@
Kernel driver ltc4151
=====================
Supported chips:
* Linear Technology LTC4151
Prefix: 'ltc4151'
Addresses scanned: -
Datasheet:
http://www.linear.com/docs/Datasheet/4151fc.pdf
Author: Per Dalen <per.dalen@appeartv.com>
Description
-----------
The LTC4151 is a High Voltage I2C Current and Voltage Monitor.
Usage Notes
-----------
This driver does not probe for LTC4151 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 an LTC4151 at address 0x6f
on I2C bus #0:
# modprobe ltc4151
# echo ltc4151 0x6f > /sys/bus/i2c/devices/i2c-0/new_device
Sysfs entries
-------------
Voltage readings provided by this driver are reported as obtained from the ADIN
and VIN registers.
Current reading provided by this driver is reported as obtained from the Current
Sense register. The reported value assumes that a 1 mOhm sense resistor is
installed.
in1_input VDIN voltage (mV)
in2_input ADIN voltage (mV)
curr1_input SENSE current (mA)

49
Documentation/hwmon/max6639 Normal file
View File

@ -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

215
Documentation/hwmon/pmbus Normal file
View File

@ -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.

22
Documentation/hwmon/sch5627 Normal file
View File

@ -0,0 +1,22 @@
Kernel driver sch5627
=====================
Supported chips:
* SMSC SCH5627
Prefix: 'sch5627'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Application Note available upon request
Author: Hans de Goede <hdegoede@redhat.com>
Description
-----------
SMSC SCH5627 Super I/O chips include complete hardware monitoring
capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures.
The hardware monitoring part of the SMSC SCH5627 is accessed by talking
through an embedded microcontroller. An application note describing the
protocol for communicating with the microcontroller is available upon
request. Please mail me if you want a copy.

11
Documentation/hwmon/sysfs-interface
View File

@ -187,6 +187,17 @@ fan[1-*]_div Fan divisor.
Note that this is actually an internal clock divisor, which
affects the measurable speed range, not the read value.
fan[1-*]_pulses Number of tachometer pulses per fan revolution.
Integer value, typically between 1 and 4.
RW
This value is a characteristic of the fan connected to the
device's input, so it has to be set in accordance with the fan
model.
Should only be created if the chip has a register to configure
the number of pulses. In the absence of such a register (and
thus attribute) the value assumed by all devices is 2 pulses
per fan revolution.
fan[1-*]_target
Desired fan speed
Unit: revolution/min (RPM)

58
Documentation/hwmon/w83627ehf
View File

@ -5,13 +5,11 @@ Supported chips:
* Winbond W83627EHF/EHG (ISA access ONLY)
Prefix: 'w83627ehf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet:
http://www.nuvoton.com.tw/NR/rdonlyres/A6A258F0-F0C9-4F97-81C0-C4D29E7E943E/0/W83627EHF.pdf
Datasheet: not available
* Winbond W83627DHG
Prefix: 'w83627dhg'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet:
http://www.nuvoton.com.tw/NR/rdonlyres/7885623D-A487-4CF9-A47F-30C5F73D6FE6/0/W83627DHG.pdf
Datasheet: not available
* Winbond W83627DHG-P
Prefix: 'w83627dhg'
Addresses scanned: ISA address retrieved from Super I/O registers
@ -24,6 +22,14 @@ Supported chips:
Prefix: 'w83667hg'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
* Nuvoton NCT6775F/W83667HG-I
Prefix: 'nct6775'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
* Nuvoton NCT6776F
Prefix: 'nct6776'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
Authors:
Jean Delvare <khali@linux-fr.org>
@ -36,19 +42,28 @@ Description
-----------
This driver implements support for the Winbond W83627EHF, W83627EHG,
W83627DHG, W83627DHG-P, W83667HG and W83667HG-B super I/O chips.
We will refer to them collectively as Winbond chips.
W83627DHG, W83627DHG-P, W83667HG, W83667HG-B, W83667HG-I (NCT6775F),
and NCT6776F super I/O chips. We will refer to them collectively as
Winbond chips.
The chips implement three temperature sensors, five fan rotation
speed sensors, ten analog voltage sensors (only nine for the 627DHG), one
VID (6 pins for the 627EHF/EHG, 8 pins for the 627DHG and 667HG), alarms
with beep warnings (control unimplemented), and some automatic fan
regulation strategies (plus manual fan control mode).
The chips implement three temperature sensors (up to four for 667HG-B, and nine
for NCT6775F and NCT6776F), five fan rotation speed sensors, ten analog voltage
sensors (only nine for the 627DHG), one VID (6 pins for the 627EHF/EHG, 8 pins
for the 627DHG and 667HG), alarms with beep warnings (control unimplemented),
and some automatic fan regulation strategies (plus manual fan control mode).
The temperature sensor sources on W82677HG-B, NCT6775F, and NCT6776F are
configurable. temp4 and higher attributes are only reported if its temperature
source differs from the temperature sources of the already reported temperature
sensors. The configured source for each of the temperature sensors is provided
in tempX_label.
Temperatures are measured in degrees Celsius and measurement resolution is 1
degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
the temperature gets higher than high limit; it stays on until the temperature
falls below the hysteresis value.
degC for temp1 and and 0.5 degC for temp2 and temp3. For temp4 and higher,
resolution is 1 degC for W83667HG-B and 0.0 degC for NCT6775F and NCT6776F.
An alarm is triggered when the temperature gets higher than high limit;
it stays on until the temperature falls below the hysteresis value.
Alarms are only supported for temp1, temp2, and temp3.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
@ -80,7 +95,8 @@ prog -> pwm4 (not on 667HG and 667HG-B; the programmable setting is not
name - this is a standard hwmon device entry. For the W83627EHF and W83627EHG,
it is set to "w83627ehf", for the W83627DHG it is set to "w83627dhg",
and for the W83667HG it is set to "w83667hg".
for the W83667HG and W83667HG-B it is set to "w83667hg", for NCT6775F it
is set to "nct6775", and for NCT6776F it is set to "nct6776".
pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range:
0 (stop) to 255 (full)
@ -90,6 +106,18 @@ pwm[1-4]_enable - this file controls mode of fan/temperature control:
* 2 "Thermal Cruise" mode
* 3 "Fan Speed Cruise" mode
* 4 "Smart Fan III" mode
* 5 "Smart Fan IV" mode
SmartFan III mode is not supported on NCT6776F.
SmartFan IV mode is configurable only if it was configured at system
startup, and is only supported for W83677HG-B, NCT6775F, and NCT6776F.
SmartFan IV operational parameters can not be configured at this time,
and the various pwm attributes are not used in SmartFan IV mode.
The attributes can be written to, which is useful if you plan to
configure the system for a different pwm mode. However, the information
returned when reading pwm attributes is unrelated to SmartFan IV
operation.
pwm[1-4]_mode - controls if output is PWM or DC level
* 0 DC output (0 - 12v)

127
Documentation/hwmon/w83795 Normal file
View File

@ -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

293
Documentation/hwspinlock.txt Normal file
View File

@ -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.

26
Documentation/i2c/busses/i2c-diolan-u2c Normal file
View File

@ -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

3
Documentation/i2c/busses/i2c-i801
View File

@ -16,8 +16,9 @@ Supported adapters:
* Intel EP80579 (Tolapai)
* Intel 82801JI (ICH10)
* Intel 5/3400 Series (PCH)
* Intel Cougar Point (PCH)
* Intel 6 Series (PCH)
* Intel Patsburg (PCH)
* Intel DH89xxCC (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller

2
Documentation/i2c/instantiating-devices
View File

@ -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);

18
Documentation/i2c/upgrading-clients
View File

@ -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,
};

1
Documentation/ioctl/ioctl-number.txt
View File

@ -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!

7
Documentation/kbuild/kbuild.txt
View File

@ -146,7 +146,7 @@ INSTALL_MOD_STRIP
INSTALL_MOD_STRIP, if defined, will cause modules to be
stripped after they are installed. If INSTALL_MOD_STRIP is '1', then
the default option --strip-debug will be used. Otherwise,
INSTALL_MOD_STRIP will used as the options to the strip command.
INSTALL_MOD_STRIP value will be used as the options to the strip command.
INSTALL_FW_PATH
--------------------------------------------------
@ -196,3 +196,8 @@ to be included in the databases, separated by blank space. E.g.:
To get all available archs you can also specify all. E.g.:
$ make ALLSOURCE_ARCHS=all tags
KBUILD_ENABLE_EXTRA_GCC_CHECKS
--------------------------------------------------
If enabled over the make command line with "W=1", it turns on additional
gcc -W... options for more extensive build-time checking.

3
Documentation/kbuild/makefiles.txt
View File

@ -1325,7 +1325,8 @@ The top Makefile exports the following variables:
If this variable is specified, will cause modules to be stripped
after they are installed. If INSTALL_MOD_STRIP is '1', then the
default option --strip-debug will be used. Otherwise,
INSTALL_MOD_STRIP will used as the option(s) to the strip command.
INSTALL_MOD_STRIP value will be used as the option(s) to the strip
command.
=== 9 Makefile language

32
Documentation/kernel-parameters.txt
View File

@ -626,6 +626,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
disable= [IPV6]
See Documentation/networking/ipv6.txt.
disable_ddw [PPC/PSERIES]
Disable Dynamic DMA Window support. Use this if
to workaround buggy firmware.
disable_ipv6= [IPV6]
See Documentation/networking/ipv6.txt.
@ -868,6 +872,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
If specified, z/VM IUCV HVC accepts connections
from listed z/VM user IDs only.
keep_bootcon [KNL]
Do not unregister boot console at start. This is only
useful for debugging when something happens in the window
between unregistering the boot console and initializing
the real console.
i2c_bus= [HW] Override the default board specific I2C bus speed
or register an additional I2C bus that is not
registered from board initialization code.
@ -1580,16 +1590,25 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
of returning the full 64-bit number.
The default is to return 64-bit inode numbers.
nfs.nfs4_disable_idmapping=
[NFSv4] When set, this option disables the NFSv4
idmapper on the client, but only if the mount
is using the 'sec=sys' security flavour. This may
make migration from legacy NFSv2/v3 systems easier
provided that the server has the appropriate support.
The default is to always enable NFSv4 idmapping.
nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take
when a NMI is triggered.
Format: [state][,regs][,debounce][,die]
nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels
Format: [panic,][num]
Format: [panic,][nopanic,][num]
Valid num: 0
0 - turn nmi_watchdog off
When panic is specified, panic when an NMI watchdog
timeout occurs.
timeout occurs (or 'nopanic' to override the opposite
default).
This is useful when you use a panic=... timeout and
need the box quickly up again.
@ -1813,6 +1832,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
perfmon on Intel CPUs instead of the
CPU specific event set.
oops=panic Always panic on oopses. Default is to just kill the process,
but there is a small probability of deadlocking the machine.
This will also cause panics on machine check exceptions.
Useful together with panic=30 to trigger a reboot.
OSS [HW,OSS]
See Documentation/sound/oss/oss-parameters.txt
@ -2444,6 +2468,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
<deci-seconds>: poll all this frequency
0: no polling (default)
threadirqs [KNL]
Force threading of all interrupt handlers except those
marked explicitely IRQF_NO_THREAD.
topology= [S390]
Format: {off | on}
Specify if the kernel should make use of the cpu

9
Documentation/keys-request-key.txt
View File

@ -127,14 +127,15 @@ This is because process A's keyrings can't simply be attached to
of them, and (b) it requires the same UID/GID/Groups all the way through.
======================
NEGATIVE INSTANTIATION
======================
====================================
NEGATIVE INSTANTIATION AND REJECTION
====================================
Rather than instantiating a key, it is possible for the possessor of an
authorisation key to negatively instantiate a key that's under construction.
This is a short duration placeholder that causes any attempt at re-requesting
the key whilst it exists to fail with error ENOKEY.
the key whilst it exists to fail with error ENOKEY if negated or the specified
error if rejected.
This is provided to prevent excessive repeated spawning of /sbin/request-key
processes for a key that will never be obtainable.

28
Documentation/keys.txt
View File

@ -637,6 +637,9 @@ The keyctl syscall functions are:
long keyctl(KEYCTL_INSTANTIATE, key_serial_t key,
const void *payload, size_t plen,
key_serial_t keyring);
long keyctl(KEYCTL_INSTANTIATE_IOV, key_serial_t key,
const struct iovec *payload_iov, unsigned ioc,
key_serial_t keyring);
If the kernel calls back to userspace to complete the instantiation of a
key, userspace should use this call to supply data for the key before the
@ -652,11 +655,16 @@ The keyctl syscall functions are:
The payload and plen arguments describe the payload data as for add_key().
The payload_iov and ioc arguments describe the payload data in an iovec
array instead of a single buffer.
(*) Negatively instantiate a partially constructed key.
long keyctl(KEYCTL_NEGATE, key_serial_t key,
unsigned timeout, key_serial_t keyring);
long keyctl(KEYCTL_REJECT, key_serial_t key,
unsigned timeout, unsigned error, key_serial_t keyring);
If the kernel calls back to userspace to complete the instantiation of a
key, userspace should use this call mark the key as negative before the
@ -669,6 +677,10 @@ The keyctl syscall functions are:
that keyring, however all the constraints applying in KEYCTL_LINK apply in
this case too.
If the key is rejected, future searches for it will return the specified
error code until the rejected key expires. Negating the key is the same
as rejecting the key with ENOKEY as the error code.
(*) Set the default request-key destination keyring.
@ -1062,6 +1074,13 @@ The structure has a number of fields, some of which are mandatory:
viable.
(*) int (*vet_description)(const char *description);
This optional method is called to vet a key description. If the key type
doesn't approve of the key description, it may return an error, otherwise
it should return 0.
(*) int (*instantiate)(struct key *key, const void *data, size_t datalen);
This method is called to attach a payload to a key during construction.
@ -1231,10 +1250,11 @@ hand the request off to (perhaps a path held in placed in another key by, for
example, the KDE desktop manager).
The program (or whatever it calls) should finish construction of the key by
calling KEYCTL_INSTANTIATE, which also permits it to cache the key in one of
the keyrings (probably the session ring) before returning. Alternatively, the
key can be marked as negative with KEYCTL_NEGATE; this also permits the key to
be cached in one of the keyrings.
calling KEYCTL_INSTANTIATE or KEYCTL_INSTANTIATE_IOV, which also permits it to
cache the key in one of the keyrings (probably the session ring) before
returning. Alternatively, the key can be marked as negative with KEYCTL_NEGATE
or KEYCTL_REJECT; this also permits the key to be cached in one of the
keyrings.
If it returns with the key remaining in the unconstructed state, the key will
be marked as being negative, it will be added to the session keyring, and an

2
Documentation/kref.txt
View File

@ -156,7 +156,7 @@ static struct my_data *get_entry()
struct my_data *entry = NULL;
mutex_lock(&mutex);
if (!list_empty(&q)) {
entry = container_of(q.next, struct my_q_entry, link);
entry = container_of(q.next, struct my_data, link);
kref_get(&entry->refcount);
}
mutex_unlock(&mutex);

96
Documentation/kvm/api.txt
View File

@ -166,7 +166,7 @@ Returns: 0 on success, -1 on error
This ioctl is obsolete and has been removed.
4.6 KVM_CREATE_VCPU
4.7 KVM_CREATE_VCPU
Capability: basic
Architectures: all
@ -177,7 +177,7 @@ Returns: vcpu fd on success, -1 on error
This API adds a vcpu to a virtual machine. The vcpu id is a small integer
in the range [0, max_vcpus).
4.7 KVM_GET_DIRTY_LOG (vm ioctl)
4.8 KVM_GET_DIRTY_LOG (vm ioctl)
Capability: basic
Architectures: x86
@ -200,7 +200,7 @@ since the last call to this ioctl. Bit 0 is the first page in the
memory slot. Ensure the entire structure is cleared to avoid padding
issues.
4.8 KVM_SET_MEMORY_ALIAS
4.9 KVM_SET_MEMORY_ALIAS
Capability: basic
Architectures: x86
@ -210,7 +210,7 @@ Returns: 0 (success), -1 (error)
This ioctl is obsolete and has been removed.
4.9 KVM_RUN
4.10 KVM_RUN
Capability: basic
Architectures: all
@ -226,7 +226,7 @@ obtained by mmap()ing the vcpu fd at offset 0, with the size given by
KVM_GET_VCPU_MMAP_SIZE. The parameter block is formatted as a 'struct
kvm_run' (see below).
4.10 KVM_GET_REGS
4.11 KVM_GET_REGS
Capability: basic
Architectures: all
@ -246,7 +246,7 @@ struct kvm_regs {
__u64 rip, rflags;
};
4.11 KVM_SET_REGS
4.12 KVM_SET_REGS
Capability: basic
Architectures: all
@ -258,7 +258,7 @@ Writes the general purpose registers into the vcpu.
See KVM_GET_REGS for the data structure.
4.12 KVM_GET_SREGS
4.13 KVM_GET_SREGS
Capability: basic
Architectures: x86
@ -283,7 +283,7 @@ interrupt_bitmap is a bitmap of pending external interrupts. At most
one bit may be set. This interrupt has been acknowledged by the APIC
but not yet injected into the cpu core.
4.13 KVM_SET_SREGS
4.14 KVM_SET_SREGS
Capability: basic
Architectures: x86
@ -294,7 +294,7 @@ Returns: 0 on success, -1 on error
Writes special registers into the vcpu. See KVM_GET_SREGS for the
data structures.
4.14 KVM_TRANSLATE
4.15 KVM_TRANSLATE
Capability: basic
Architectures: x86
@ -317,7 +317,7 @@ struct kvm_translation {
__u8 pad[5];
};
4.15 KVM_INTERRUPT
4.16 KVM_INTERRUPT
Capability: basic
Architectures: x86, ppc
@ -365,7 +365,7 @@ c) KVM_INTERRUPT_SET_LEVEL
Note that any value for 'irq' other than the ones stated above is invalid
and incurs unexpected behavior.
4.16 KVM_DEBUG_GUEST
4.17 KVM_DEBUG_GUEST
Capability: basic
Architectures: none
@ -375,7 +375,7 @@ Returns: -1 on error
Support for this has been removed. Use KVM_SET_GUEST_DEBUG instead.
4.17 KVM_GET_MSRS
4.18 KVM_GET_MSRS
Capability: basic
Architectures: x86
@ -403,7 +403,7 @@ Application code should set the 'nmsrs' member (which indicates the
size of the entries array) and the 'index' member of each array entry.
kvm will fill in the 'data' member.
4.18 KVM_SET_MSRS
4.19 KVM_SET_MSRS
Capability: basic
Architectures: x86
@ -418,7 +418,7 @@ Application code should set the 'nmsrs' member (which indicates the
size of the entries array), and the 'index' and 'data' members of each
array entry.
4.19 KVM_SET_CPUID
4.20 KVM_SET_CPUID
Capability: basic
Architectures: x86
@ -446,7 +446,7 @@ struct kvm_cpuid {
struct kvm_cpuid_entry entries[0];
};
4.20 KVM_SET_SIGNAL_MASK
4.21 KVM_SET_SIGNAL_MASK
Capability: basic
Architectures: x86
@ -468,7 +468,7 @@ struct kvm_signal_mask {
__u8 sigset[0];
};
4.21 KVM_GET_FPU
4.22 KVM_GET_FPU
Capability: basic
Architectures: x86
@ -493,7 +493,7 @@ struct kvm_fpu {
__u32 pad2;
};
4.22 KVM_SET_FPU
4.23 KVM_SET_FPU
Capability: basic
Architectures: x86
@ -518,7 +518,7 @@ struct kvm_fpu {
__u32 pad2;
};
4.23 KVM_CREATE_IRQCHIP
4.24 KVM_CREATE_IRQCHIP
Capability: KVM_CAP_IRQCHIP
Architectures: x86, ia64
@ -531,7 +531,7 @@ ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
only go to the IOAPIC. On ia64, a IOSAPIC is created.
4.24 KVM_IRQ_LINE
4.25 KVM_IRQ_LINE
Capability: KVM_CAP_IRQCHIP
Architectures: x86, ia64
@ -552,7 +552,7 @@ struct kvm_irq_level {
__u32 level; /* 0 or 1 */
};
4.25 KVM_GET_IRQCHIP
4.26 KVM_GET_IRQCHIP
Capability: KVM_CAP_IRQCHIP
Architectures: x86, ia64
@ -573,7 +573,7 @@ struct kvm_irqchip {
} chip;
};
4.26 KVM_SET_IRQCHIP
4.27 KVM_SET_IRQCHIP
Capability: KVM_CAP_IRQCHIP
Architectures: x86, ia64
@ -594,7 +594,7 @@ struct kvm_irqchip {
} chip;
};
4.27 KVM_XEN_HVM_CONFIG
4.28 KVM_XEN_HVM_CONFIG
Capability: KVM_CAP_XEN_HVM
Architectures: x86
@ -618,7 +618,7 @@ struct kvm_xen_hvm_config {
__u8 pad2[30];
};
4.27 KVM_GET_CLOCK
4.29 KVM_GET_CLOCK
Capability: KVM_CAP_ADJUST_CLOCK
Architectures: x86
@ -636,7 +636,7 @@ struct kvm_clock_data {
__u32 pad[9];
};
4.28 KVM_SET_CLOCK
4.30 KVM_SET_CLOCK
Capability: KVM_CAP_ADJUST_CLOCK
Architectures: x86
@ -654,7 +654,7 @@ struct kvm_clock_data {
__u32 pad[9];
};
4.29 KVM_GET_VCPU_EVENTS
4.31 KVM_GET_VCPU_EVENTS
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
@ -693,7 +693,7 @@ struct kvm_vcpu_events {
KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that
interrupt.shadow contains a valid state. Otherwise, this field is undefined.
4.30 KVM_SET_VCPU_EVENTS
4.32 KVM_SET_VCPU_EVENTS
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
@ -719,7 +719,7 @@ If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in
the flags field to signal that interrupt.shadow contains a valid state and
shall be written into the VCPU.
4.32 KVM_GET_DEBUGREGS
4.33 KVM_GET_DEBUGREGS
Capability: KVM_CAP_DEBUGREGS
Architectures: x86
@ -737,7 +737,7 @@ struct kvm_debugregs {
__u64 reserved[9];
};
4.33 KVM_SET_DEBUGREGS
4.34 KVM_SET_DEBUGREGS
Capability: KVM_CAP_DEBUGREGS
Architectures: x86
@ -750,7 +750,7 @@ Writes debug registers into the vcpu.
See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
yet and must be cleared on entry.
4.34 KVM_SET_USER_MEMORY_REGION
4.35 KVM_SET_USER_MEMORY_REGION
Capability: KVM_CAP_USER_MEM
Architectures: all
@ -796,7 +796,7 @@ It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl.
The KVM_SET_MEMORY_REGION does not allow fine grained control over memory
allocation and is deprecated.
4.35 KVM_SET_TSS_ADDR
4.36 KVM_SET_TSS_ADDR
Capability: KVM_CAP_SET_TSS_ADDR
Architectures: x86
@ -814,7 +814,7 @@ This ioctl is required on Intel-based hosts. This is needed on Intel hardware
because of a quirk in the virtualization implementation (see the internals
documentation when it pops into existence).
4.36 KVM_ENABLE_CAP
4.37 KVM_ENABLE_CAP
Capability: KVM_CAP_ENABLE_CAP
Architectures: ppc
@ -849,7 +849,7 @@ function properly, this is the place to put them.
__u8 pad[64];
};
4.37 KVM_GET_MP_STATE
4.38 KVM_GET_MP_STATE
Capability: KVM_CAP_MP_STATE
Architectures: x86, ia64
@ -879,7 +879,7 @@ Possible values are:
This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel
irqchip, the multiprocessing state must be maintained by userspace.
4.38 KVM_SET_MP_STATE
4.39 KVM_SET_MP_STATE
Capability: KVM_CAP_MP_STATE
Architectures: x86, ia64
@ -893,7 +893,7 @@ arguments.
This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel
irqchip, the multiprocessing state must be maintained by userspace.
4.39 KVM_SET_IDENTITY_MAP_ADDR
4.40 KVM_SET_IDENTITY_MAP_ADDR
Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR
Architectures: x86
@ -911,7 +911,7 @@ This ioctl is required on Intel-based hosts. This is needed on Intel hardware
because of a quirk in the virtualization implementation (see the internals
documentation when it pops into existence).
4.40 KVM_SET_BOOT_CPU_ID
4.41 KVM_SET_BOOT_CPU_ID
Capability: KVM_CAP_SET_BOOT_CPU_ID
Architectures: x86, ia64
@ -923,7 +923,7 @@ Define which vcpu is the Bootstrap Processor (BSP). Values are the same
as the vcpu id in KVM_CREATE_VCPU. If this ioctl is not called, the default
is vcpu 0.
4.41 KVM_GET_XSAVE
4.42 KVM_GET_XSAVE
Capability: KVM_CAP_XSAVE
Architectures: x86
@ -937,7 +937,7 @@ struct kvm_xsave {
This ioctl would copy current vcpu's xsave struct to the userspace.
4.42 KVM_SET_XSAVE
4.43 KVM_SET_XSAVE
Capability: KVM_CAP_XSAVE
Architectures: x86
@ -951,7 +951,7 @@ struct kvm_xsave {
This ioctl would copy userspace's xsave struct to the kernel.
4.43 KVM_GET_XCRS
4.44 KVM_GET_XCRS
Capability: KVM_CAP_XCRS
Architectures: x86
@ -974,7 +974,7 @@ struct kvm_xcrs {
This ioctl would copy current vcpu's xcrs to the userspace.
4.44 KVM_SET_XCRS
4.45 KVM_SET_XCRS
Capability: KVM_CAP_XCRS
Architectures: x86
@ -997,7 +997,7 @@ struct kvm_xcrs {
This ioctl would set vcpu's xcr to the value userspace specified.
4.45 KVM_GET_SUPPORTED_CPUID
4.46 KVM_GET_SUPPORTED_CPUID
Capability: KVM_CAP_EXT_CPUID
Architectures: x86
@ -1062,7 +1062,7 @@ emulate them efficiently. The fields in each entry are defined as follows:
eax, ebx, ecx, edx: the values returned by the cpuid instruction for
this function/index combination
4.46 KVM_PPC_GET_PVINFO
4.47 KVM_PPC_GET_PVINFO
Capability: KVM_CAP_PPC_GET_PVINFO
Architectures: ppc
@ -1085,7 +1085,7 @@ of 4 instructions that make up a hypercall.
If any additional field gets added to this structure later on, a bit for that
additional piece of information will be set in the flags bitmap.
4.47 KVM_ASSIGN_PCI_DEVICE
4.48 KVM_ASSIGN_PCI_DEVICE
Capability: KVM_CAP_DEVICE_ASSIGNMENT
Architectures: x86 ia64
@ -1113,7 +1113,7 @@ following flags are specified:
/* Depends on KVM_CAP_IOMMU */
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
4.48 KVM_DEASSIGN_PCI_DEVICE
4.49 KVM_DEASSIGN_PCI_DEVICE
Capability: KVM_CAP_DEVICE_DEASSIGNMENT
Architectures: x86 ia64
@ -1126,7 +1126,7 @@ Ends PCI device assignment, releasing all associated resources.
See KVM_CAP_DEVICE_ASSIGNMENT for the data structure. Only assigned_dev_id is
used in kvm_assigned_pci_dev to identify the device.
4.49 KVM_ASSIGN_DEV_IRQ
4.50 KVM_ASSIGN_DEV_IRQ
Capability: KVM_CAP_ASSIGN_DEV_IRQ
Architectures: x86 ia64
@ -1164,7 +1164,7 @@ The following flags are defined:
It is not valid to specify multiple types per host or guest IRQ. However, the
IRQ type of host and guest can differ or can even be null.
4.50 KVM_DEASSIGN_DEV_IRQ
4.51 KVM_DEASSIGN_DEV_IRQ
Capability: KVM_CAP_ASSIGN_DEV_IRQ
Architectures: x86 ia64
@ -1178,7 +1178,7 @@ See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified
by assigned_dev_id, flags must correspond to the IRQ type specified on
KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed.
4.51 KVM_SET_GSI_ROUTING
4.52 KVM_SET_GSI_ROUTING
Capability: KVM_CAP_IRQ_ROUTING
Architectures: x86 ia64
@ -1226,7 +1226,7 @@ struct kvm_irq_routing_msi {
__u32 pad;
};
4.52 KVM_ASSIGN_SET_MSIX_NR
4.53 KVM_ASSIGN_SET_MSIX_NR
Capability: KVM_CAP_DEVICE_MSIX
Architectures: x86 ia64
@ -1245,7 +1245,7 @@ struct kvm_assigned_msix_nr {
#define KVM_MAX_MSIX_PER_DEV 256
4.53 KVM_ASSIGN_SET_MSIX_ENTRY
4.54 KVM_ASSIGN_SET_MSIX_ENTRY
Capability: KVM_CAP_DEVICE_MSIX
Architectures: x86 ia64

25
Documentation/kvm/locking.txt Normal file
View File

@ -0,0 +1,25 @@
KVM Lock Overview
=================
1. Acquisition Orders
---------------------
(to be written)
2. Reference
------------
Name: kvm_lock
Type: raw_spinlock
Arch: any
Protects: - vm_list
- hardware virtualization enable/disable
Comment: 'raw' because hardware enabling/disabling must be atomic /wrt
migration.
Name: kvm_arch::tsc_write_lock
Type: raw_spinlock
Arch: x86
Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset}
- tsc offset in vmcb
Comment: 'raw' because updating the tsc offsets must not be preempted.

0
Documentation/hwmon/hpfall.c → Documentation/laptops/hpfall.c
View File

58
Documentation/memory-barriers.txt
View File

@ -21,6 +21,7 @@ Contents:
- SMP barrier pairing.
- Examples of memory barrier sequences.
- Read memory barriers vs load speculation.
- Transitivity
(*) Explicit kernel barriers.
@ -959,6 +960,63 @@ the speculation will be cancelled and the value reloaded:
retrieved : : +-------+
TRANSITIVITY
------------
Transitivity is a deeply intuitive notion about ordering that is not
always provided by real computer systems. The following example
demonstrates transitivity (also called "cumulativity"):
CPU 1 CPU 2 CPU 3
======================= ======================= =======================
{ X = 0, Y = 0 }
STORE X=1 LOAD X STORE Y=1
<general barrier> <general barrier>
LOAD Y LOAD X
Suppose that CPU 2's load from X returns 1 and its load from Y returns 0.
This indicates that CPU 2's load from X in some sense follows CPU 1's
store to X and that CPU 2's load from Y in some sense preceded CPU 3's
store to Y. The question is then "Can CPU 3's load from X return 0?"
Because CPU 2's load from X in some sense came after CPU 1's store, it
is natural to expect that CPU 3's load from X must therefore return 1.
This expectation is an example of transitivity: if a load executing on
CPU A follows a load from the same variable executing on CPU B, then
CPU A's load must either return the same value that CPU B's load did,
or must return some later value.
In the Linux kernel, use of general memory barriers guarantees
transitivity. Therefore, in the above example, if CPU 2's load from X
returns 1 and its load from Y returns 0, then CPU 3's load from X must
also return 1.
However, transitivity is -not- guaranteed for read or write barriers.
For example, suppose that CPU 2's general barrier in the above example
is changed to a read barrier as shown below:
CPU 1 CPU 2 CPU 3
======================= ======================= =======================
{ X = 0, Y = 0 }
STORE X=1 LOAD X STORE Y=1
<read barrier> <general barrier>
LOAD Y LOAD X
This substitution destroys transitivity: in this example, it is perfectly
legal for CPU 2's load from X to return 1, its load from Y to return 0,
and CPU 3's load from X to return 0.
The key point is that although CPU 2's read barrier orders its pair
of loads, it does not guarantee to order CPU 1's store. Therefore, if
this example runs on a system where CPUs 1 and 2 share a store buffer
or a level of cache, CPU 2 might have early access to CPU 1's writes.
General barriers are therefore required to ensure that all CPUs agree
on the combined order of CPU 1's and CPU 2's accesses.
To reiterate, if your code requires transitivity, use general barriers
throughout.
========================
EXPLICIT KERNEL BARRIERS
========================

47
Documentation/memory-hotplug.txt
View File

@ -126,36 +126,51 @@ config options.
--------------------------------
4 sysfs files for memory hotplug
--------------------------------
All sections have their device information under /sys/devices/system/memory as
All sections have their device information in sysfs. Each section is part of
a memory block under /sys/devices/system/memory as
/sys/devices/system/memory/memoryXXX
(XXX is section id.)
(XXX is the section id.)
Now, XXX is defined as start_address_of_section / section_size.
Now, XXX is defined as (start_address_of_section / section_size) of the first
section contained in the memory block. The files 'phys_index' and
'end_phys_index' under each directory report the beginning and end section id's
for the memory block covered by the sysfs directory. It is expected that all
memory sections in this range are present and no memory holes exist in the
range. Currently there is no way to determine if there is a memory hole, but
the existence of one should not affect the hotplug capabilities of the memory
block.
For example, assume 1GiB section size. A device for a memory starting at
0x100000000 is /sys/device/system/memory/memory4
(0x100000000 / 1Gib = 4)
This device covers address range [0x100000000 ... 0x140000000)
Under each section, you can see 4 files.
Under each section, you can see 4 or 5 files, the end_phys_index file being
a recent addition and not present on older kernels.
/sys/devices/system/memory/memoryXXX/phys_index
/sys/devices/system/memory/memoryXXX/start_phys_index
/sys/devices/system/memory/memoryXXX/end_phys_index
/sys/devices/system/memory/memoryXXX/phys_device
/sys/devices/system/memory/memoryXXX/state
/sys/devices/system/memory/memoryXXX/removable
'phys_index' : read-only and contains section id, same as XXX.
'state' : read-write
at read: contains online/offline state of memory.
at write: user can specify "online", "offline" command
'phys_device': read-only: designed to show the name of physical memory device.
This is not well implemented now.
'removable' : read-only: contains an integer value indicating
whether the memory section is removable or not
removable. A value of 1 indicates that the memory
section is removable and a value of 0 indicates that
it is not removable.
'phys_index' : read-only and contains section id of the first section
in the memory block, same as XXX.
'end_phys_index' : read-only and contains section id of the last section
in the memory block.
'state' : read-write
at read: contains online/offline state of memory.
at write: user can specify "online", "offline" command
which will be performed on al sections in the block.
'phys_device' : read-only: designed to show the name of physical memory
device. This is not well implemented now.
'removable' : read-only: contains an integer value indicating
whether the memory block is removable or not
removable. A value of 1 indicates that the memory
block is removable and a value of 0 indicates that
it is not removable. A memory block is removable only if
every section in the block is removable.
NOTE:
These directories/files appear after physical memory hotplug phase.

92
Documentation/misc-devices/lis3lv02d Normal file
View File

@ -0,0 +1,92 @@
Kernel driver lis3lv02d
=======================
Supported chips:
* STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
* STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
Authors:
Yan Burman <burman.yan@gmail.com>
Eric Piel <eric.piel@tremplin-utc.net>
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/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).
Sysfs attributes under /sys/devices/platform/lis3lv02d/:
position - 3D position that the accelerometer reports. Format: "(x,y,z)"
rate - read reports the sampling rate of the accelerometer device in HZ.
write changes sampling rate of the accelerometer device.
Only values which are supported by HW are accepted.
selftest - performs selftest for the chip as specified by chip manufacturer.
This driver also provides an absolute input class device, allowing
the laptop to act as a pinball machine-esque joystick. Joystick device can be
calibrated. Joystick device can be in two different modes.
By default output values are scaled between -32768 .. 32767. In joystick raw
mode, joystick and sysfs position entry have the same scale. There can be
small difference due to input system fuzziness feature.
Events are also available as input event device.
Selftest is meant only for hardware diagnostic purposes. It is not meant to be
used during normal operations. Position data is not corrupted during selftest
but interrupt behaviour is not guaranteed to work reliably. In test mode, the
sensing element is internally moved little bit. Selftest measures difference
between normal mode and test mode. Chip specifications tell the acceptance
limit for each type of the chip. Limits are provided via platform data
to allow adjustment of the limits without a change to the actual driver.
Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are
measured difference between modes. Axes are not remapped in selftest mode.
Measurement values are provided to help HW diagnostic applications to make
final decision.
On HP laptops, if the led infrastructure is activated, support for a led
indicating disk protection will be provided as /sys/class/leds/hp::hddprotect.
Another feature of the driver is misc device called "freefall" that
acts similar to /dev/rtc and reacts on free-fall interrupts received
from the device. It supports blocking operations, poll/select and
fasync operation modes. You must read 1 bytes from the device. The
result is number of free-fall interrupts since the last successful
read (or 255 if number of interrupts would not fit). See the hpfall.c
file for an example on using the device.
Axes orientation
----------------
For better compatibility between the various laptops. The values reported by
the accelerometer are converted into a "standard" organisation of the axes
(aka "can play neverball out of the box"):
* When the laptop is horizontal the position reported is about 0 for X and Y
and a positive value for Z
* If the left side is elevated, X increases (becomes positive)
* If the front side (where the touchpad is) is elevated, Y decreases
(becomes negative)
* If the laptop is put upside-down, Z becomes negative
If your laptop model is not recognized (cf "dmesg"), you can send an
email to the maintainer to add it to the database. When reporting a new
laptop, please include the output of "dmidecode" plus the value of
/sys/devices/platform/lis3lv02d/position in these four cases.
Q&A
---
Q: How do I safely simulate freefall? I have an HP "portable
workstation" which has about 3.5kg and a plastic case, so letting it
fall to the ground is out of question...
A: The sensor is pretty sensitive, so your hands can do it. Lift it
into free space, follow the fall with your hands for like 10
centimeters. That should be enough to trigger the detection.

130
Documentation/misc-devices/spear-pcie-gadget.txt Normal file
View File

@ -0,0 +1,130 @@
Spear PCIe Gadget Driver:
Author
=============
Pratyush Anand (pratyush.anand@st.com)
Location
============
driver/misc/spear13xx_pcie_gadget.c
Supported Chip:
===================
SPEAr1300
SPEAr1310
Menuconfig option:
==========================
Device Drivers
Misc devices
PCIe gadget support for SPEAr13XX platform
purpose
===========
This driver has several nodes which can be read/written by configfs interface.
Its main purpose is to configure selected dual mode PCIe controller as device
and then program its various registers to configure it as a particular device
type. This driver can be used to show spear's PCIe device capability.
Description of different nodes:
=================================
read behavior of nodes:
------------------------------
link :gives ltssm status.
int_type :type of supported interrupt
no_of_msi :zero if MSI is not enabled by host. A positive value is the
number of MSI vector granted.
vendor_id :returns programmed vendor id (hex)
device_id :returns programmed device id(hex)
bar0_size: :returns size of bar0 in hex.
bar0_address :returns address of bar0 mapped area in hex.
bar0_rw_offset :returns offset of bar0 for which bar0_data will return value.
bar0_data :returns data at bar0_rw_offset.
write behavior of nodes:
------------------------------
link :write UP to enable ltsmm DOWN to disable
int_type :write interrupt type to be configured and (int_type could be
INTA, MSI or NO_INT). Select MSI only when you have programmed
no_of_msi node.
no_of_msi :number of MSI vector needed.
inta :write 1 to assert INTA and 0 to de-assert.
send_msi :write MSI vector to be sent.
vendor_id :write vendor id(hex) to be programmed.
device_id :write device id(hex) to be programmed.
bar0_size :write size of bar0 in hex. default bar0 size is 1000 (hex)
bytes.
bar0_address :write address of bar0 mapped area in hex. (default mapping of
bar0 is SYSRAM1(E0800000). Always program bar size before bar
address. Kernel might modify bar size and address for alignment, so
read back bar size and address after writing to cross check.
bar0_rw_offset :write offset of bar0 for which bar0_data will write value.
bar0_data :write data to be written at bar0_rw_offset.
Node programming example
===========================
Program all PCIe registers in such a way that when this device is connected
to the PCIe host, then host sees this device as 1MB RAM.
#mount -t configfs none /Config
For nth PCIe Device Controller
# cd /config/pcie_gadget.n/
Now you have all the nodes in this directory.
program vendor id as 0x104a
# echo 104A >> vendor_id
program device id as 0xCD80
# echo CD80 >> device_id
program BAR0 size as 1MB
# echo 100000 >> bar0_size
check for programmed bar0 size
# cat bar0_size
Program BAR0 Address as DDR (0x2100000). This is the physical address of
memory, which is to be made visible to PCIe host. Similarly any other peripheral
can also be made visible to PCIe host. E.g., if you program base address of UART
as BAR0 address then when this device will be connected to a host, it will be
visible as UART.
# echo 2100000 >> bar0_address
program interrupt type : INTA
# echo INTA >> int_type
go for link up now.
# echo UP >> link
It will have to be insured that, once link up is done on gadget, then only host
is initialized and start to search PCIe devices on its port.
/*wait till link is up*/
# cat link
wait till it returns UP.
To assert INTA
# echo 1 >> inta
To de-assert INTA
# echo 0 >> inta
if MSI is to be used as interrupt, program no of msi vector needed (say4)
# echo 4 >> no_of_msi
select MSI as interrupt type
# echo MSI >> int_type
go for link up now
# echo UP >> link
wait till link is up
# cat link
An application can repetitively read this node till link is found UP. It can
sleep between two read.
wait till msi is enabled
# cat no_of_msi
Should return 4 (number of requested MSI vector)
to send msi vector 2
# echo 2 >> send_msi
#cd -

16
Documentation/networking/batman-adv.txt
View File

@ -1,4 +1,4 @@
[state: 21-11-2010]
[state: 27-01-2011]
BATMAN-ADV
----------
@ -67,15 +67,16 @@ All mesh wide settings can be found in batman's own interface
folder:
# ls /sys/class/net/bat0/mesh/
# aggregated_ogms bonding fragmentation orig_interval
# vis_mode
# aggregated_ogms gw_bandwidth hop_penalty
# bonding gw_mode orig_interval
# fragmentation gw_sel_class vis_mode
There is a special folder for debugging informations:
# ls /sys/kernel/debug/batman_adv/bat0/
# originators socket transtable_global transtable_local
# vis_data
# gateways socket transtable_global vis_data
# originators softif_neigh transtable_local
Some of the files contain all sort of status information regard-
@ -230,9 +231,8 @@ CONTACT
Please send us comments, experiences, questions, anything :)
IRC: #batman on irc.freenode.org
Mailing-list: b.a.t.m.a.n@b.a.t.m.a.n@lists.open-mesh.org
(optional subscription at
https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n)
Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription
at https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n)
You can also contact the Authors:

26
Documentation/networking/bonding.txt
View File

@ -2558,18 +2558,15 @@ enslaved.
16. Resources and Links
=======================
The latest version of the bonding driver can be found in the latest
The latest version of the bonding driver can be found in the latest
version of the linux kernel, found on http://kernel.org
The latest version of this document can be found in either the latest
kernel source (named Documentation/networking/bonding.txt), or on the
bonding sourceforge site:
The latest version of this document can be found in the latest kernel
source (named Documentation/networking/bonding.txt).
http://www.sourceforge.net/projects/bonding
Discussions regarding the bonding driver take place primarily on the
bonding-devel mailing list, hosted at sourceforge.net. If you have
questions or problems, post them to the list. The list address is:
Discussions regarding the usage of the bonding driver take place on the
bonding-devel mailing list, hosted at sourceforge.net. If you have questions or
problems, post them to the list. The list address is:
bonding-devel@lists.sourceforge.net
@ -2578,6 +2575,17 @@ be found at:
https://lists.sourceforge.net/lists/listinfo/bonding-devel
Discussions regarding the developpement of the bonding driver take place
on the main Linux network mailing list, hosted at vger.kernel.org. The list
address is:
netdev@vger.kernel.org
The administrative interface (to subscribe or unsubscribe) can
be found at:
http://vger.kernel.org/vger-lists.html#netdev
Donald Becker's Ethernet Drivers and diag programs may be found at :
- http://web.archive.org/web/*/http://www.scyld.com/network/

Some files were not shown because too many files have changed in this diff Show More