Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 232033
b: refs/heads/master
c: 4843456
h: refs/heads/master
i:
  232031: ed895c0
v: v3
  • Loading branch information
Linus Torvalds committed Jan 21, 2011
1 parent fea25f4 commit 9030548
Show file tree
Hide file tree
Showing 3,131 changed files with 131,538 additions and 33,421 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: f00c9e44ad1a9660fe8cd3ca15b6cd9497172eab
refs/heads/master: 4843456c5c341eb57f80f9224362a22665d14107
4 changes: 2 additions & 2 deletions trunk/CREDITS
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2811,8 +2811,8 @@ D: CDROM driver "sonycd535" (Sony CDU-535/531)
N: Stelian Pop
E: stelian@popies.net
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
D: sonypi, meye drivers, mct_u232 usb serial hacks
S: Paris, France
D: random kernel hacks
S: Paimpont, France

N: Pete Popov
E: pete_popov@yahoo.com
Expand Down
4 changes: 4 additions & 0 deletions trunk/Documentation/ABI/stable/thermal-notification
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
What: A notification mechanism for thermal related events
Description:
This interface enables notification for thermal related events.
The notification is in the form of a netlink event.
9 changes: 9 additions & 0 deletions trunk/Documentation/ABI/testing/sysfs-class-led
View file
Original file line number Diff line number Diff line change
Expand Up @@ -26,3 +26,12 @@ Description:
scheduler is chosen. Trigger specific parameters can appear in
/sys/class/leds/<led> once a given trigger is selected.

What: /sys/class/leds/<led>/inverted
Date: January 2011
KernelVersion: 2.6.38
Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Invert the LED on/off state. This parameter is specific to
gpio and backlight triggers. In case of the backlight trigger,
it is usefull when driving a LED which is intended to indicate
a device in a standby like state.
21 changes: 17 additions & 4 deletions trunk/Documentation/DocBook/80211.tmpl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -268,10 +268,6 @@
!Finclude/net/mac80211.h ieee80211_ops
!Finclude/net/mac80211.h ieee80211_alloc_hw
!Finclude/net/mac80211.h ieee80211_register_hw
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_unregister_hw
!Finclude/net/mac80211.h ieee80211_free_hw
</chapter>
Expand Down Expand Up @@ -382,6 +378,23 @@
</para>
</partintro>

<chapter id="led-support">
<title>LED support</title>
<para>
Mac80211 supports various ways of blinking LEDs. Wherever possible,
device LEDs should be exposed as LED class devices and hooked up to
the appropriate trigger, which will then be triggered appropriately
by mac80211.
</para>
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_tpt_blink
!Finclude/net/mac80211.h ieee80211_tpt_led_trigger_flags
!Finclude/net/mac80211.h ieee80211_create_tpt_led_trigger
</chapter>

<chapter id="hardware-crypto-offload">
<title>Hardware crypto acceleration</title>
!Pinclude/net/mac80211.h Hardware crypto acceleration
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/DocBook/mtdnand.tmpl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -250,7 +250,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
<title>Device ready function</title>
<para>
If the hardware interface has the ready busy pin of the NAND chip connected to a
GPIO or other accesible I/O pin, this function is used to read back the state of the
GPIO or other accessible I/O pin, this function is used to read back the state of the
pin. The function has no arguments and should return 0, if the device is busy (R/B pin
is low) and 1, if the device is ready (R/B pin is high).
If the hardware interface does not give access to the ready busy pin, then
Expand Down
27 changes: 27 additions & 0 deletions trunk/Documentation/IPMI.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -533,6 +533,33 @@ completion during sending a panic event.
Other Pieces
------------

Get the detailed info related with the IPMI device
--------------------------------------------------

Some users need more detailed information about a device, like where
the address came from or the raw base device for the IPMI interface.
You can use the IPMI smi_watcher to catch the IPMI interfaces as they
come or go, and to grab the information, you can use the function
ipmi_get_smi_info(), which returns the following structure:

struct ipmi_smi_info {
enum ipmi_addr_src addr_src;
struct device *dev;
union {
struct {
void *acpi_handle;
} acpi_info;
} addr_info;
};

Currently special info for only for SI_ACPI address sources is
returned. Others may be added as necessary.

Note that the dev pointer is included in the above structure, and
assuming ipmi_smi_get_info returns success, you must call put_device
on the dev pointer.


Watchdog
--------

Expand Down
122 changes: 122 additions & 0 deletions trunk/Documentation/acpi/apei/output_format.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,122 @@
APEI output format
~~~~~~~~~~~~~~~~~~

APEI uses printk as hardware error reporting interface, the output
format is as follow.

<error record> :=
APEI generic hardware error status
severity: <integer>, <severity string>
section: <integer>, severity: <integer>, <severity string>
flags: <integer>
<section flags strings>
fru_id: <uuid string>
fru_text: <string>
section_type: <section type string>
<section data>

<severity string>* := recoverable | fatal | corrected | info

<section flags strings># :=
[primary][, containment warning][, reset][, threshold exceeded]\
[, resource not accessible][, latent error]

<section type string> := generic processor error | memory error | \
PCIe error | unknown, <uuid string>

<section data> :=
<generic processor section data> | <memory section data> | \
<pcie section data> | <null>

<generic processor section data> :=
[processor_type: <integer>, <proc type string>]
[processor_isa: <integer>, <proc isa string>]
[error_type: <integer>
<proc error type strings>]
[operation: <integer>, <proc operation string>]
[flags: <integer>
<proc flags strings>]
[level: <integer>]
[version_info: <integer>]
[processor_id: <integer>]
[target_address: <integer>]
[requestor_id: <integer>]
[responder_id: <integer>]
[IP: <integer>]

<proc type string>* := IA32/X64 | IA64

<proc isa string>* := IA32 | IA64 | X64

<processor error type strings># :=
[cache error][, TLB error][, bus error][, micro-architectural error]

<proc operation string>* := unknown or generic | data read | data write | \
instruction execution

<proc flags strings># :=
[restartable][, precise IP][, overflow][, corrected]

<memory section data> :=
[error_status: <integer>]
[physical_address: <integer>]
[physical_address_mask: <integer>]
[node: <integer>]
[card: <integer>]
[module: <integer>]
[bank: <integer>]
[device: <integer>]
[row: <integer>]
[column: <integer>]
[bit_position: <integer>]
[requestor_id: <integer>]
[responder_id: <integer>]
[target_id: <integer>]
[error_type: <integer>, <mem error type string>]

<mem error type string>* :=
unknown | no error | single-bit ECC | multi-bit ECC | \
single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \
target abort | parity error | watchdog timeout | invalid address | \
mirror Broken | memory sparing | scrub corrected error | \
scrub uncorrected error

<pcie section data> :=
[port_type: <integer>, <pcie port type string>]
[version: <integer>.<integer>]
[command: <integer>, status: <integer>]
[device_id: <integer>:<integer>:<integer>.<integer>
slot: <integer>
secondary_bus: <integer>
vendor_id: <integer>, device_id: <integer>
class_code: <integer>]
[serial number: <integer>, <integer>]
[bridge: secondary_status: <integer>, control: <integer>]

<pcie port type string>* := PCIe end point | legacy PCI end point | \
unknown | unknown | root port | upstream switch port | \
downstream switch port | PCIe to PCI/PCI-X bridge | \
PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \
root complex event collector

Where, [] designate corresponding content is optional

All <field string> description with * has the following format:

field: <integer>, <field string>

Where value of <integer> should be the position of "string" in <field
string> description. Otherwise, <field string> will be "unknown".

All <field strings> description with # has the following format:

field: <integer>
<field strings>

Where each string in <fields strings> corresponding to one set bit of
<integer>. The bit position is the position of "string" in <field
strings> description.

For more detailed explanation of every field, please refer to UEFI
specification version 2.3 or later, section Appendix N: Common
Platform Error Record.
27 changes: 27 additions & 0 deletions trunk/Documentation/cgroups/blkio-controller.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -89,6 +89,33 @@ Throttling/Upper Limit policy

Limits for writes can be put using blkio.write_bps_device file.

Hierarchical Cgroups
====================
- Currently none of the IO control policy supports hierarhical groups. But
cgroup interface does allow creation of hierarhical cgroups and internally
IO policies treat them as flat hierarchy.

So this patch will allow creation of cgroup hierarhcy but at the backend
everything will be treated as flat. So if somebody created a hierarchy like
as follows.

root
/ \
test1 test2
|
test3

CFQ and throttling will practically treat all groups at same level.

pivot
/ | \ \
root test1 test2 test3

Down the line we can implement hierarchical accounting/control support
and also introduce a new cgroup file "use_hierarchy" which will control
whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
This is how memory controller also has implemented the things.

Various user visible config options
===================================
CONFIG_BLK_CGROUP
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/cgroups/cgroup_event_listener.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -91,7 +91,7 @@ int main(int argc, char **argv)

if (ret == -1) {
perror("cgroup.event_control "
"is not accessable any more");
"is not accessible any more");
break;
}

Expand Down
8 changes: 4 additions & 4 deletions trunk/Documentation/cgroups/cgroups.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -355,13 +355,13 @@ subsystems, type:

To change the set of subsystems bound to a mounted hierarchy, just
remount with different options:
# mount -o remount,cpuset,ns hier1 /dev/cgroup
# mount -o remount,cpuset,blkio hier1 /dev/cgroup

Now memory is removed from the hierarchy and ns is added.
Now memory is removed from the hierarchy and blkio is added.

Note this will add ns to the hierarchy but won't remove memory or
Note this will add blkio to the hierarchy but won't remove memory or
cpuset, because the new options are appended to the old ones:
# mount -o remount,ns /dev/cgroup
# mount -o remount,blkio /dev/cgroup

To Specify a hierarchy's release_agent:
# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/cgroups/memcg_test.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -398,7 +398,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
written to move_charge_at_immigrate.

9.10 Memory thresholds
Memory controler implements memory thresholds using cgroups notification
Memory controller implements memory thresholds using cgroups notification
API. You can use Documentation/cgroups/cgroup_event_listener.c to test
it.

Expand Down
7 changes: 6 additions & 1 deletion trunk/Documentation/device-mapper/dm-crypt.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ Parameters: <cipher> <key> <iv_offset> <device path> <offset>

<cipher>
Encryption cipher and an optional IV generation mode.
(In format cipher-chainmode-ivopts:ivmode).
(In format cipher[:keycount]-chainmode-ivopts:ivmode).
Examples:
des
aes-cbc-essiv:sha256
Expand All @@ -20,6 +20,11 @@ Parameters: <cipher> <key> <iv_offset> <device path> <offset>
Key used for encryption. It is encoded as a hexadecimal number.
You can only use key sizes that are valid for the selected cipher.

<keycount>
Multi-key compatibility mode. You can define <keycount> keys and
then sectors are encrypted according to their offsets (sector 0 uses key0;
sector 1 uses key1 etc.). <keycount> must be a power of two.

<iv_offset>
The IV offset is a sector count that is added to the sector number
before creating the IV.
Expand Down
70 changes: 70 additions & 0 deletions trunk/Documentation/device-mapper/dm-raid.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
Device-mapper RAID (dm-raid) is a bridge from DM to MD. It
provides a way to use device-mapper interfaces to access the MD RAID
drivers.

As with all device-mapper targets, the nominal public interfaces are the
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
and STATUSTYPE_TABLE). The CTR table looks like the following:

1: <s> <l> raid \
2: <raid_type> <#raid_params> <raid_params> \
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>

Line 1 contains the standard first three arguments to any device-mapper
target - the start, length, and target type fields. The target type in
this case is "raid".

Line 2 contains the arguments that define the particular raid
type/personality/level, the required arguments for that raid type, and
any optional arguments. Possible raid types include: raid4, raid5_la,
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (raid1 is
planned for the future.) The list of required and optional parameters
is the same for all the current raid types. The required parameters are
positional, while the optional parameters are given as key/value pairs.
The possible parameters are as follows:
<chunk_size> Chunk size in sectors.
[[no]sync] Force/Prevent RAID initialization
[rebuild <idx>] Rebuild the drive indicated by the index
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_write_behind <sectors>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size for higher RAIDs

Line 3 contains the list of devices that compose the array in
metadata/data device pairs. If the metadata is stored separately, a '-'
is given for the metadata device position. If a drive has failed or is
missing at creation time, a '-' can be given for both the metadata and
data drives for a given position.

NB. Currently all metadata devices must be specified as '-'.

Examples:
# RAID4 - 4 data drives, 1 parity
# No metadata devices specified to hold superblock/bitmap info
# Chunk size of 1MiB
# (Lines separated for easy reading)
0 1960893648 raid \
raid4 1 2048 \
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81

# RAID4 - 4 data drives, 1 parity (no metadata devices)
# Chunk size of 1MiB, force RAID initialization,
# min recovery rate at 20 kiB/sec/disk
0 1960893648 raid \
raid4 4 2048 min_recovery_rate 20 sync\
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81

Performing a 'dmsetup table' should display the CTR table used to
construct the mapping (with possible reordering of optional
parameters).

Performing a 'dmsetup status' will yield information on the state and
health of the array. The output is as follows:
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>

Line 1 is standard DM output. Line 2 is best shown by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Loading

0 comments on commit 9030548

Please sign in to comment.