Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 177783
b: refs/heads/master
c: c0caac9
h: refs/heads/master
i:
  177781: 93bd9f9
  177779: 052d154
  177775: 7fd0fcf
v: v3
  • Loading branch information
Russell King committed Dec 17, 2009
1 parent cd6da99 commit a8c01e8
Show file tree
Hide file tree
Showing 623 changed files with 24,028 additions and 11,083 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 75e874c698bf7aeed005acd74d0fb13c47124939
refs/heads/master: c0caac93f873cd3402b63246bf94d904afc4f5fd
14 changes: 13 additions & 1 deletion trunk/Documentation/ABI/testing/sysfs-devices-memory
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,19 @@ Description:
Users: hotplug memory remove tools
https://w3.opensource.ibm.com/projects/powerpc-utils/


What: /sys/devices/system/memoryX/nodeY
Date: October 2009
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
When CONFIG_NUMA is enabled, a symbolic link that
points to the corresponding NUMA node directory.

For example, the following symbolic link is created for
memory section 9 on node0:
/sys/devices/system/memory/memory9/node0 -> ../../node/node0


What: /sys/devices/system/node/nodeX/memoryY
Date: September 2008
Contact: Gary Hade <garyhade@us.ibm.com>
Expand All @@ -70,4 +83,3 @@ Description:
memory section directory. For example, the following symbolic
link is created for memory section 9 on node0.
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9

14 changes: 14 additions & 0 deletions trunk/Documentation/ABI/testing/sysfs-devices-system-cpu
Original file line number Diff line number Diff line change
Expand Up @@ -92,6 +92,20 @@ Description: Discover NUMA node a CPU belongs to
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2


What: /sys/devices/system/cpu/cpu#/node
Date: October 2009
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Discover NUMA node a CPU belongs to

When CONFIG_NUMA is enabled, a symbolic link that points
to the corresponding NUMA node directory.

For example, the following symlink is created for cpu42
in NUMA node 2:

/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2


What: /sys/devices/system/cpu/cpu#/topology/core_id
/sys/devices/system/cpu/cpu#/topology/core_siblings
/sys/devices/system/cpu/cpu#/topology/core_siblings_list
Expand Down
60 changes: 55 additions & 5 deletions trunk/Documentation/device-mapper/snapshot.txt
Original file line number Diff line number Diff line change
Expand Up @@ -8,13 +8,19 @@ the block device which are also writable without interfering with the
original content;
*) To create device "forks", i.e. multiple different versions of the
same data stream.
*) To merge a snapshot of a block device back into the snapshot's origin
device.

In the first two cases, dm copies only the chunks of data that get
changed and uses a separate copy-on-write (COW) block device for
storage.

In both cases, dm copies only the chunks of data that get changed and
uses a separate copy-on-write (COW) block device for storage.
For snapshot merge the contents of the COW storage are merged back into
the origin device.


There are two dm targets available: snapshot and snapshot-origin.
There are three dm targets available:
snapshot, snapshot-origin, and snapshot-merge.

*) snapshot-origin <origin>

Expand All @@ -40,8 +46,25 @@ The difference is that for transient snapshots less metadata must be
saved on disk - they can be kept in memory by the kernel.


How this is used by LVM2
========================
* snapshot-merge <origin> <COW device> <persistent> <chunksize>

takes the same table arguments as the snapshot target except it only
works with persistent snapshots. This target assumes the role of the
"snapshot-origin" target and must not be loaded if the "snapshot-origin"
is still present for <origin>.

Creates a merging snapshot that takes control of the changed chunks
stored in the <COW device> of an existing snapshot, through a handover
procedure, and merges these chunks back into the <origin>. Once merging
has started (in the background) the <origin> may be opened and the merge
will continue while I/O is flowing to it. Changes to the <origin> are
deferred until the merging snapshot's corresponding chunk(s) have been
merged. Once merging has started the snapshot device, associated with
the "snapshot" target, will return -EIO when accessed.


How snapshot is used by LVM2
============================
When you create the first LVM2 snapshot of a volume, four dm devices are used:

1) a device containing the original mapping table of the source volume;
Expand Down Expand Up @@ -72,3 +95,30 @@ brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow
brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap
brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base


How snapshot-merge is used by LVM2
==================================
A merging snapshot assumes the role of the "snapshot-origin" while
merging. As such the "snapshot-origin" is replaced with
"snapshot-merge". The "-real" device is not changed and the "-cow"
device is renamed to <origin name>-cow to aid LVM2's cleanup of the
merging snapshot after it completes. The "snapshot" that hands over its
COW device to the "snapshot-merge" is deactivated (unless using lvchange
--refresh); but if it is left active it will simply return I/O errors.

A snapshot will merge into its origin with the following command:

lvconvert --merge volumeGroup/snap

we'll now have this situation:

# dmsetup table|grep volumeGroup

volumeGroup-base-real: 0 2097152 linear 8:19 384
volumeGroup-base-cow: 0 204800 linear 8:19 2097536
volumeGroup-base: 0 2097152 snapshot-merge 254:11 254:12 P 16

# ls -lL /dev/mapper/volumeGroup-*
brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real
brw------- 1 root root 254, 12 29 ago 18:16 /dev/mapper/volumeGroup-base-cow
brw------- 1 root root 254, 10 29 ago 18:16 /dev/mapper/volumeGroup-base
9 changes: 0 additions & 9 deletions trunk/Documentation/feature-removal-schedule.txt
Original file line number Diff line number Diff line change
Expand Up @@ -291,15 +291,6 @@ Who: Michael Buesch <mb@bu3sch.de>

---------------------------

What: print_fn_descriptor_symbol()
When: October 2009
Why: The %pF vsprintf format provides the same functionality in a
simpler way. print_fn_descriptor_symbol() is deprecated but
still present to give out-of-tree modules time to change.
Who: Bjorn Helgaas <bjorn.helgaas@hp.com>

---------------------------

What: /sys/o2cb symlink
When: January 2010
Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
Expand Down
9 changes: 9 additions & 0 deletions trunk/Documentation/filesystems/proc.txt
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,7 @@ Table of Contents
3.3 /proc/<pid>/io - Display the IO accounting fields
3.4 /proc/<pid>/coredump_filter - Core dump filtering settings
3.5 /proc/<pid>/mountinfo - Information about mounts
3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm


------------------------------------------------------------------------------
Expand Down Expand Up @@ -1409,3 +1410,11 @@ For more information on mount propagation see:

Documentation/filesystems/sharedsubtree.txt


3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm
--------------------------------------------------------
These files provide a method to access a tasks comm value. It also allows for
a task to set its own or one of its thread siblings comm value. The comm value
is limited in size compared to the cmdline value, so writing anything longer
then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
comm value.
55 changes: 38 additions & 17 deletions trunk/Documentation/hwmon/lis3lv02d
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,8 @@ Kernel driver lis3lv02d

Supported chips:

* STMicroelectronics LIS3LV02DL and LIS3LV02DQ
* STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
* STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)

Authors:
Yan Burman <burman.yan@gmail.com>
Expand All @@ -13,32 +14,52 @@ Authors:
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 (for now the HP 2133, nc6420,
nc2510, nc8510, nc84x0, nw9440 and nx9420) 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.
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)"
calibrate - read: values (x, y, z) that are used as the base for input
class device operation.
write: forces the base to be recalibrated with the current
position.
rate - reports the sampling rate of the accelerometer device in HZ
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.
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).
read (or 255 if number of interrupts would not fit). See the hpfall.c
file for an example on using the device.


Axes orientation
Expand All @@ -55,7 +76,7 @@ the accelerometer are converted into a "standard" organisation of the axes
* 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 authors to add it to the database. When reporting a new
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.

Expand Down
10 changes: 8 additions & 2 deletions trunk/Documentation/hwmon/w83627ehf
Original file line number Diff line number Diff line change
Expand Up @@ -81,8 +81,14 @@ pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range:
0 (stop) to 255 (full)

pwm[1-4]_enable - this file controls mode of fan/temperature control:
* 1 Manual Mode, write to pwm file any value 0-255 (full speed)
* 2 Thermal Cruise
* 1 Manual mode, write to pwm file any value 0-255 (full speed)
* 2 "Thermal Cruise" mode
* 3 "Fan Speed Cruise" mode
* 4 "Smart Fan III" mode

pwm[1-4]_mode - controls if output is PWM or DC level
* 0 DC output (0 - 12v)
* 1 PWM output

Thermal Cruise mode
-------------------
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/i2c/writing-clients
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ static struct i2c_driver foo_driver = {
/* if device autodetection is needed: */
.class = I2C_CLASS_SOMETHING,
.detect = foo_detect,
.address_data = &addr_data,
.address_list = normal_i2c,

.shutdown = foo_shutdown, /* optional */
.suspend = foo_suspend, /* optional */
Expand Down
11 changes: 7 additions & 4 deletions trunk/Documentation/memory-hotplug.txt
Original file line number Diff line number Diff line change
Expand Up @@ -160,12 +160,15 @@ Under each section, you can see 4 files.
NOTE:
These directories/files appear after physical memory hotplug phase.

If CONFIG_NUMA is enabled the
/sys/devices/system/memory/memoryXXX memory section
directories can also be accessed via symbolic links located in
the /sys/devices/system/node/node* directories. For example:
If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed
via symbolic links located in the /sys/devices/system/node/node* directories.

For example:
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9

A backlink will also be created:
/sys/devices/system/memory/memory9/node0 -> ../../node/node0

--------------------------------
4. Physical memory hot-add phase
--------------------------------
Expand Down
57 changes: 57 additions & 0 deletions trunk/Documentation/misc-devices/ad525x_dpot.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---------------------------------
AD525x Digital Potentiometers
---------------------------------

The ad525x_dpot driver exports a simple sysfs interface. This allows you to
work with the immediate resistance settings as well as update the saved startup
settings. Access to the factory programmed tolerance is also provided, but
interpretation of this settings is required by the end application according to
the specific part in use.

---------
Files
---------

Each dpot device will have a set of eeprom, rdac, and tolerance files. How
many depends on the actual part you have, as will the range of allowed values.

The eeprom files are used to program the startup value of the device.

The rdac files are used to program the immediate value of the device.

The tolerance files are the read-only factory programmed tolerance settings
and may vary greatly on a part-by-part basis. For exact interpretation of
this field, please consult the datasheet for your part. This is presented
as a hex file for easier parsing.

-----------
Example
-----------

Locate the device in your sysfs tree. This is probably easiest by going into
the common i2c directory and locating the device by the i2c slave address.

# ls /sys/bus/i2c/devices/
0-0022 0-0027 0-002f

So assuming the device in question is on the first i2c bus and has the slave
address of 0x2f, we descend (unrelated sysfs entries have been trimmed).

# ls /sys/bus/i2c/devices/0-002f/
eeprom0 rdac0 tolerance0

You can use simple reads/writes to access these files:

# cd /sys/bus/i2c/devices/0-002f/

# cat eeprom0
0
# echo 10 > eeprom0
# cat eeprom0
10

# cat rdac0
5
# echo 3 > rdac0
# cat rdac0
3
26 changes: 26 additions & 0 deletions trunk/Documentation/nommu-mmap.txt
Original file line number Diff line number Diff line change
Expand Up @@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
granule but will only discard the excess if appropriately configured as
this has an effect on fragmentation.

(*) The memory allocated by a request for an anonymous mapping will normally
be cleared by the kernel before being returned in accordance with the
Linux man pages (ver 2.22 or later).

In the MMU case this can be achieved with reasonable performance as
regions are backed by virtual pages, with the contents only being mapped
to cleared physical pages when a write happens on that specific page
(prior to which, the pages are effectively mapped to the global zero page
from which reads can take place). This spreads out the time it takes to
initialize the contents of a page - depending on the write-usage of the
mapping.

In the no-MMU case, however, anonymous mappings are backed by physical
pages, and the entire map is cleared at allocation time. This can cause
significant delays during a userspace malloc() as the C library does an
anonymous mapping and the kernel then does a memset for the entire map.

However, for memory that isn't required to be precleared - such as that
returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
indicate to the kernel that it shouldn't bother clearing the memory before
returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
to permit this, otherwise the flag will be ignored.

uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
to allocate the brk and stack region.

(*) A list of all the private copy and anonymous mappings on the system is
visible through /proc/maps in no-MMU mode.

Expand Down
Loading

0 comments on commit a8c01e8

Please sign in to comment.