diff options
Diffstat (limited to 'Documentation')
31 files changed, 364 insertions, 494 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 30b327a116e..042073f656e 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -183,8 +183,6 @@ i386/ - directory with info about Linux on Intel 32 bit architecture. ia64/ - directory with info about Linux on Intel 64 bit architecture. -ide.txt - - important info for users of ATA devices (IDE/EIDE disks and CD-ROMS). infiniband/ - directory with documents concerning Linux InfiniBand support. initrd.txt diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index f31601e8bd8..dc0f30c3e57 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -361,12 +361,14 @@ X!Edrivers/pnp/system.c <chapter id="blkdev"> <title>Block Devices</title> !Eblock/blk-core.c +!Iblock/blk-core.c !Eblock/blk-map.c !Iblock/blk-sysfs.c !Eblock/blk-settings.c !Eblock/blk-exec.c !Eblock/blk-barrier.c !Eblock/blk-tag.c +!Iblock/blk-tag.c </chapter> <chapter id="chrdev"> diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index f20c10c2858..4ef24501045 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -186,7 +186,8 @@ If the atomic value v is not equal to u, this function adds a to v, and returns non zero. If v is equal to u then it returns zero. This is done as an atomic operation. -atomic_add_unless requires explicit memory barriers around the operation. +atomic_add_unless requires explicit memory barriers around the operation +unless it fails (returns 0). atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0) diff --git a/Documentation/cdrom/ide-cd b/Documentation/cdrom/ide-cd index 29721bfcde1..91c0dcc6fa5 100644 --- a/Documentation/cdrom/ide-cd +++ b/Documentation/cdrom/ide-cd @@ -45,7 +45,7 @@ This driver provides the following features: --------------- 0. The ide-cd relies on the ide disk driver. See - Documentation/ide.txt for up-to-date information on the ide + Documentation/ide/ide.txt for up-to-date information on the ide driver. 1. Make sure that the ide and ide-cd drivers are compiled into the @@ -64,7 +64,7 @@ This driver provides the following features: Depending on what type of IDE interface you have, you may need to specify additional configuration options. See - Documentation/ide.txt. + Documentation/ide/ide.txt. 2. You should also ensure that the iso9660 filesystem is either compiled into the kernel or available as a loadable module. You @@ -84,7 +84,7 @@ This driver provides the following features: on the primary IDE interface are called `hda' and `hdb', respectively. The drives on the secondary interface are called `hdc' and `hdd'. (Interfaces at other locations get other letters - in the third position; see Documentation/ide.txt.) + in the third position; see Documentation/ide/ide.txt.) If you want your CDROM drive to be found automatically by the driver, you should make sure your IDE interface uses either the @@ -93,7 +93,7 @@ This driver provides the following features: be jumpered as `master'. (If for some reason you cannot configure your system in this manner, you can probably still use the driver. You may have to pass extra configuration information to the kernel - when you boot, however. See Documentation/ide.txt for more + when you boot, however. See Documentation/ide/ide.txt for more information.) 4. Boot the system. If the drive is recognized, you should see a @@ -201,7 +201,7 @@ TEST This section discusses some common problems encountered when trying to use the driver, and some possible solutions. Note that if you are experiencing problems, you should probably also review -Documentation/ide.txt for current information about the underlying +Documentation/ide/ide.txt for current information about the underlying IDE support code. Some of these items apply only to earlier versions of the driver, but are mentioned here for completeness. @@ -211,7 +211,7 @@ from the driver. a. Drive is not detected during booting. - Review the configuration instructions above and in - Documentation/ide.txt, and check how your hardware is + Documentation/ide/ide.txt, and check how your hardware is configured. - If your drive is the only device on an IDE interface, it should @@ -219,7 +219,7 @@ a. Drive is not detected during booting. - If your IDE interface is not at the standard addresses of 0x170 or 0x1f0, you'll need to explicitly inform the driver using a - lilo option. See Documentation/ide.txt. (This feature was + lilo option. See Documentation/ide/ide.txt. (This feature was added around kernel version 1.3.30.) - If the autoprobing is not finding your drive, you can tell the @@ -245,7 +245,7 @@ a. Drive is not detected during booting. Support for some interfaces needing extra initialization is provided in later 1.3.x kernels. You may need to turn on additional kernel configuration options to get them to work; - see Documentation/ide.txt. + see Documentation/ide/ide.txt. Even if support is not available for your interface, you may be able to get it to work with the following procedure. First boot @@ -299,7 +299,7 @@ c. System hangups. be worked around by specifying the `serialize' option when booting. Recent kernels should be able to detect the need for this automatically in most cases, but the detection is not - foolproof. See Documentation/ide.txt for more information + foolproof. See Documentation/ide/ide.txt for more information about the `serialize' option and the CMD640B. - Note that many MS-DOS CDROM drivers will work with such buggy diff --git a/Documentation/cgroups.txt b/Documentation/cgroups.txt index 42d7c4cb39c..31d12e21ff8 100644 --- a/Documentation/cgroups.txt +++ b/Documentation/cgroups.txt @@ -28,7 +28,7 @@ CONTENTS: 4. Questions 1. Control Groups -========== +================= 1.1 What are cgroups ? ---------------------- @@ -143,10 +143,10 @@ proliferation of such cgroups. Also lets say that the administrator would like to give enhanced network access temporarily to a student's browser (since it is night and the user -wants to do online gaming :) OR give one of the students simulation +wants to do online gaming :)) OR give one of the students simulation apps enhanced CPU power, -With ability to write pids directly to resource classes, its just a +With ability to write pids directly to resource classes, it's just a matter of : # echo pid > /mnt/network/<new_class>/tasks @@ -227,10 +227,13 @@ Each cgroup is represented by a directory in the cgroup file system containing the following files describing that cgroup: - tasks: list of tasks (by pid) attached to that cgroup - - notify_on_release flag: run /sbin/cgroup_release_agent on exit? + - releasable flag: cgroup currently removeable? + - notify_on_release flag: run the release agent on exit? + - release_agent: the path to use for release notifications (this file + exists in the top cgroup only) Other subsystems such as cpusets may add additional files in each -cgroup dir +cgroup dir. New cgroups are created using the mkdir system call or shell command. The properties of a cgroup, such as its flags, are @@ -257,7 +260,7 @@ performance. To allow access from a cgroup to the css_sets (and hence tasks) that comprise it, a set of cg_cgroup_link objects form a lattice; each cg_cgroup_link is linked into a list of cg_cgroup_links for -a single cgroup on its cont_link_list field, and a list of +a single cgroup on its cgrp_link_list field, and a list of cg_cgroup_links for a single css_set on its cg_link_list. Thus the set of tasks in a cgroup can be listed by iterating over @@ -271,9 +274,6 @@ for cgroups, with a minimum of additional kernel code. 1.4 What does notify_on_release do ? ------------------------------------ -*** notify_on_release is disabled in the current patch set. It will be -*** reactivated in a future patch in a less-intrusive manner - If the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup @@ -360,8 +360,8 @@ Now you want to do something with this cgroup. In this directory you can find several files: # ls -notify_on_release release_agent tasks -(plus whatever files are added by the attached subsystems) +notify_on_release releasable tasks +(plus whatever files added by the attached subsystems) Now attach your shell to this cgroup: # /bin/echo $$ > tasks @@ -404,19 +404,13 @@ with a subsystem id which will be assigned by the cgroup system. Other fields in the cgroup_subsys object include: - subsys_id: a unique array index for the subsystem, indicating which - entry in cgroup->subsys[] this subsystem should be - managing. Initialized by cgroup_register_subsys(); prior to this - it should be initialized to -1 + entry in cgroup->subsys[] this subsystem should be managing. -- hierarchy: an index indicating which hierarchy, if any, this - subsystem is currently attached to. If this is -1, then the - subsystem is not attached to any hierarchy, and all tasks should be - considered to be members of the subsystem's top_cgroup. It should - be initialized to -1. +- name: should be initialized to a unique subsystem name. Should be + no longer than MAX_CGROUP_TYPE_NAMELEN. -- name: should be initialized to a unique subsystem name prior to - calling cgroup_register_subsystem. Should be no longer than - MAX_CGROUP_TYPE_NAMELEN +- early_init: indicate if the subsystem needs early initialization + at system boot. Each cgroup object created by the system has an array of pointers, indexed by subsystem id; this pointer is entirely managed by the @@ -434,8 +428,6 @@ situation. See kernel/cgroup.c for more details. Subsystems can take/release the cgroup_mutex via the functions -cgroup_lock()/cgroup_unlock(), and can -take/release the callback_mutex via the functions cgroup_lock()/cgroup_unlock(). Accessing a task's cgroup pointer may be done in the following ways: @@ -444,7 +436,7 @@ Accessing a task's cgroup pointer may be done in the following ways: - inside an rcu_read_lock() section via rcu_dereference() 3.3 Subsystem API --------------------------- +----------------- Each subsystem should: @@ -455,7 +447,8 @@ Each subsystem may export the following methods. The only mandatory methods are create/destroy. Any others that are null are presumed to be successful no-ops. -struct cgroup_subsys_state *create(struct cgroup *cont) +struct cgroup_subsys_state *create(struct cgroup_subsys *ss, + struct cgroup *cgrp) (cgroup_mutex held by caller) Called to create a subsystem state object for a cgroup. The @@ -470,7 +463,7 @@ identified by the passed cgroup object having a NULL parent (since it's the root of the hierarchy) and may be an appropriate place for initialization code. -void destroy(struct cgroup *cont) +void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp) (cgroup_mutex held by caller) The cgroup system is about to destroy the passed cgroup; the subsystem @@ -481,7 +474,14 @@ cgroup->parent is still valid. (Note - can also be called for a newly-created cgroup if an error occurs after this subsystem's create() method has been called for the new cgroup). -int can_attach(struct cgroup_subsys *ss, struct cgroup *cont, +void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp); +(cgroup_mutex held by caller) + +Called before checking the reference count on each subsystem. This may +be useful for subsystems which have some extra references even if +there are not tasks in the cgroup. + +int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, struct task_struct *task) (cgroup_mutex held by caller) @@ -492,8 +492,8 @@ unspecified task can be moved into the cgroup. Note that this isn't called on a fork. If this method returns 0 (success) then this should remain valid while the caller holds cgroup_mutex. -void attach(struct cgroup_subsys *ss, struct cgroup *cont, - struct cgroup *old_cont, struct task_struct *task) +void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, + struct cgroup *old_cgrp, struct task_struct *task) Called after the task has been attached to the cgroup, to allow any post-attachment activity that requires memory allocations or blocking. @@ -505,9 +505,9 @@ registration for all existing tasks. void exit(struct cgroup_subsys *ss, struct task_struct *task) -Called during task exit +Called during task exit. -int populate(struct cgroup_subsys *ss, struct cgroup *cont) +int populate(struct cgroup_subsys *ss, struct cgroup *cgrp) Called after creation of a cgroup to allow a subsystem to populate the cgroup directory with file entries. The subsystem should make @@ -516,7 +516,7 @@ include/linux/cgroup.h for details). Note that although this method can return an error code, the error code is currently not always handled well. -void post_clone(struct cgroup_subsys *ss, struct cgroup *cont) +void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) Called at the end of cgroup_clone() to do any paramater initialization which might be required before a task could attach. For diff --git a/Documentation/controllers/memory.txt b/Documentation/controllers/memory.txt index b5bbea92a61..866b9cd9a95 100644 --- a/Documentation/controllers/memory.txt +++ b/Documentation/controllers/memory.txt @@ -1,4 +1,8 @@ -Memory Controller +Memory Resource Controller + +NOTE: The Memory Resource Controller has been generically been referred +to as the memory controller in this document. Do not confuse memory controller +used here with the memory controller that is used in hardware. Salient features @@ -152,7 +156,7 @@ The memory controller uses the following hierarchy a. Enable CONFIG_CGROUPS b. Enable CONFIG_RESOURCE_COUNTERS -c. Enable CONFIG_CGROUP_MEM_CONT +c. Enable CONFIG_CGROUP_MEM_RES_CTLR 1. Prepare the cgroups # mkdir -p /cgroups @@ -164,20 +168,20 @@ c. Enable CONFIG_CGROUP_MEM_CONT Since now we're in the 0 cgroup, We can alter the memory limit: -# echo -n 4M > /cgroups/0/memory.limit_in_bytes +# echo 4M > /cgroups/0/memory.limit_in_bytes NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo, mega or gigabytes. # cat /cgroups/0/memory.limit_in_bytes -4194304 Bytes +4194304 NOTE: The interface has now changed to display the usage in bytes instead of pages We can check the usage: # cat /cgroups/0/memory.usage_in_bytes -1216512 Bytes +1216512 A successful write to this file does not guarantee a successful set of this limit to the value written into the file. This can be due to a @@ -185,9 +189,9 @@ number of factors, such as rounding up to page boundaries or the total availability of memory on the system. The user is required to re-read this file after a write to guarantee the value committed by the kernel. -# echo -n 1 > memory.limit_in_bytes +# echo 1 > memory.limit_in_bytes # cat memory.limit_in_bytes -4096 Bytes +4096 The memory.failcnt field gives the number of times that the cgroup limit was exceeded. @@ -197,7 +201,7 @@ caches, RSS and Active pages/Inactive pages are shown. The memory.force_empty gives an interface to drop *all* charges by force. -# echo -n 1 > memory.force_empty +# echo 1 > memory.force_empty will drop all charges in cgroup. Currently, this is maintained for test. @@ -233,13 +237,6 @@ cgroup might have some charge associated with it, even though all tasks have migrated away from it. Such charges are automatically dropped at rmdir() if there are no tasks. -4.4 Choosing what to account -- Page Cache (unmapped) vs RSS (mapped)? - -The type of memory accounted by the cgroup can be limited to just -mapped pages by writing "1" to memory.control_type field - -echo -n 1 > memory.control_type - 5. TODO 1. Add support for accounting huge pages (as a separate controller) @@ -262,18 +259,19 @@ References 3. Emelianov, Pavel. Resource controllers based on process cgroups http://lkml.org/lkml/2007/3/6/198 4. Emelianov, Pavel. RSS controller based on process cgroups (v2) - http://lkml.org/lkml/2007/4/9/74 + http://lkml.org/lkml/2007/4/9/78 5. Emelianov, Pavel. RSS controller based on process cgroups (v3) http://lkml.org/lkml/2007/5/30/244 6. Menage, Paul. Control Groups v10, http://lwn.net/Articles/236032/ 7. Vaidyanathan, Srinivasan, Control Groups: Pagecache accounting and control subsystem (v3), http://lwn.net/Articles/235534/ -8. Singh, Balbir. RSS controller V2 test results (lmbench), +8. Singh, Balbir. RSS controller v2 test results (lmbench), http://lkml.org/lkml/2007/5/17/232 -9. Singh, Balbir. RSS controller V2 AIM9 results +9. Singh, Balbir. RSS controller v2 AIM9 results http://lkml.org/lkml/2007/5/18/1 -10. Singh, Balbir. Memory controller v6 results, +10. Singh, Balbir. Memory controller v6 test results, http://lkml.org/lkml/2007/8/19/36 -11. Singh, Balbir. Memory controller v6, http://lkml.org/lkml/2007/8/17/69 +11. Singh, Balbir. Memory controller introduction (v6), + http://lkml.org/lkml/2007/8/17/69 12. Corbet, Jonathan, Controlling memory use in cgroups, http://lwn.net/Articles/243795/ diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 43db6fe1281..ad2bb3b3acc 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt @@ -209,7 +209,7 @@ and name space for cpusets, with a minimum of additional kernel code. The cpus and mems files in the root (top_cpuset) cpuset are read-only. The cpus file automatically tracks the value of cpu_online_map using a CPU hotplug notifier, and the mems file -automatically tracks the value of node_states[N_MEMORY]--i.e., +automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e., nodes with memory--using the cpuset_track_online_nodes() hook. diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt index de4804e8b39..c360d4e91b4 100644 --- a/Documentation/debugging-via-ohci1394.txt +++ b/Documentation/debugging-via-ohci1394.txt @@ -36,14 +36,15 @@ available (notebooks) or too slow for extensive debug information (like ACPI). Drivers ------- -The OHCI-1394 drivers in drivers/firewire and drivers/ieee1394 initialize -the OHCI-1394 controllers to a working state and can be used to enable -physical DMA. By default you only have to load the driver, and physical -DMA access will be granted to all remote nodes, but it can be turned off -when using the ohci1394 driver. - -Because these drivers depend on the PCI enumeration to be completed, an -initialization routine which can runs pretty early (long before console_init(), +The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers +to a working state and enables physical DMA by default for all remote nodes. +This can be turned off by ohci1394's module parameter phys_dma=0. + +The alternative firewire-ohci driver in drivers/firewire uses filtered physical +DMA, hence is not yet suitable for remote debugging. + +Because ohci1394 depends on the PCI enumeration to be completed, an +initialization routine which runs pretty early (long before console_init() which makes the printk buffer appear on the console can be called) was written. To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu: diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 4d3aa519ead..c1d1fd0c299 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -172,6 +172,16 @@ Who: Len Brown <len.brown@intel.com> --------------------------- +What: ide-tape driver +When: July 2008 +Files: drivers/ide/ide-tape.c +Why: This driver might not have any users anymore and maintaining it for no + reason is an effort no one wants to make. +Who: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>, Borislav Petkov + <petkovbb@googlemail.com> + +--------------------------- + What: libata spindown skipping and warning When: Dec 2008 Why: Some halt(8) implementations synchronize caches for and spin @@ -306,3 +316,15 @@ Why: Largely unmaintained and almost entirely unused. File system is largely pointless as without a lot of work only the most trivial of Solaris binaries can work with the emulation code. Who: David S. Miller <davem@davemloft.net> + +--------------------------- + +What: init_mm export +When: 2.6.26 +Why: Not used in-tree. The current out-of-tree users used it to + work around problems in the CPA code which should be resolved + by now. One usecase was described to provide verification code + of the CPA operation. That's a good idea in general, but such + code / infrastructure should be in the kernel and not in some + out-of-tree driver. +Who: Thomas Gleixner <tglx@linutronix.de> diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index 8da724e2a0f..54630095aa3 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -2,6 +2,9 @@ GPIO Interfaces This provides an overview of GPIO access conventions on Linux. +These calls use the gpio_* naming prefix. No other calls should use that +prefix, or the related __gpio_* prefix. + What is a GPIO? =============== @@ -69,11 +72,13 @@ in this document, but drivers acting as clients to the GPIO interface must not care how it's implemented.) That said, if the convention is supported on their platform, drivers should -use it when possible. Platforms should declare GENERIC_GPIO support in -Kconfig (boolean true), which multi-platform drivers can depend on when -using the include file: +use it when possible. Platforms must declare GENERIC_GPIO support in their +Kconfig (boolean true), and provide an <asm/gpio.h> file. Drivers that can't +work without standard GPIO calls should have Kconfig entries which depend +on GENERIC_GPIO. The GPIO calls are available, either as "real code" or as +optimized-away stubs, when drivers use the include file: - #include <asm/gpio.h> + #include <linux/gpio.h> If you stick to this convention then it'll be easier for other developers to see what your code is doing, and help maintain it. @@ -316,6 +321,9 @@ pulldowns integrated on some platforms. Not all platforms support them, or support them in the same way; and any given board might use external pullups (or pulldowns) so that the on-chip ones should not be used. (When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.) +Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a +platform-specific issue, as are models like (not) having a one-to-one +correspondence between configurable pins and GPIOs. There are other system-specific mechanisms that are not specified here, like the aforementioned options for input de-glitching and wire-OR output. diff --git a/Documentation/hwmon/adt7473 b/Documentation/hwmon/adt7473 new file mode 100644 index 00000000000..22d8b19046a --- /dev/null +++ b/Documentation/hwmon/adt7473 @@ -0,0 +1,79 @@ +Kernel driver adt7473 +====================== + +Supported chips: + * Analog Devices ADT7473 + Prefix: 'adt7473' + Addresses scanned: I2C 0x2C, 0x2D, 0x2E + Datasheet: Publicly available at the Analog Devices website + +Author: Darrick J. Wong + +Description +----------- + +This driver implements support for the Analog Devices ADT7473 chip family. + +The LM85 uses the 2-wire interface compatible with the SMBUS 2.0 +specification. Using an analog to digital converter it measures three (3) +temperatures and two (2) voltages. It has three (3) 16-bit counters for +measuring fan speed. There are three (3) PWM outputs that can be used +to control fan speed. + +A sophisticated control system for the PWM outputs is designed into the +LM85 that allows fan speed to be adjusted automatically based on any of the +three temperature sensors. Each PWM output is individually adjustable and +programmable. Once configured, the ADT7473 will adjust the PWM outputs in +response to the measured temperatures without further host intervention. +This feature can also be disabled for manual control of the PWM's. + +Each of the measured inputs (voltage, temperature, fan speed) has +corresponding high/low limit values. The ADT7473 will signal an ALARM if +any measured value exceeds either limit. + +The ADT7473 samples all inputs continuously. The driver will not read +the registers more often than once every other second. Further, +configuration data is only read once per minute. + +Special Features +---------------- + +The ADT7473 have a 10-bit ADC and can therefore measure temperatures +with 0.25 degC resolution. Temperature readings can be configured either +for twos complement format or "Offset 64" format, wherein 63 is subtracted +from the raw value to get the temperature value. + +The Analog Devices datasheet is very detailed and describes a procedure for +determining an optimal configuration for the automatic PWM control. + +Hardware Configurations +----------------------- + +The ADT7473 chips have an optional SMBALERT output that can be used to +signal the chipset in case a limit is exceeded or the temperature sensors +fail. Individual sensor interrupts can be masked so they won't trigger +SMBALERT. The SMBALERT output if configured replaces the PWM2 function. + +Configuration Notes +------------------- + +Besides standard interfaces driver adds the following: + +* PWM Control + +* pwm#_auto_point1_pwm and pwm#_auto_point1_temp and +* pwm#_auto_point2_pwm and pwm#_auto_point2_temp - + +point1: Set the pwm speed at a lower temperature bound. +point2: Set the pwm speed at a higher temperature bound. + +The ADT7473 will scale the pwm between the lower and higher pwm speed when +the temperature is between the two temperature boundaries. PWM values range +from 0 (off) to 255 (full speed). + +Notes +----- + +The NVIDIA binary driver presents an ADT7473 chip via an on-card i2c bus. +Unfortunately, they fail to set the i2c adapter class, so this driver may +fail to find the chip until the nvidia driver is patched. diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index 170bf862437..dbbe6c7025b 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -4,9 +4,10 @@ Kernel driver coretemp Supported chips: * All Intel Core family Prefix: 'coretemp' - CPUID: family 0x6, models 0xe, 0xf, 0x16 + CPUID: family 0x6, models 0xe, 0xf, 0x16, 0x17 Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide + http://softwarecommunity.intel.com/Wiki/Mobility/720.htm Author: Rudolf Marek @@ -25,7 +26,8 @@ may be raised, if the temperature grows enough (more than TjMax) to trigger the Out-Of-Spec bit. Following table summarizes the exported sysfs files: temp1_input - Core temperature (in millidegrees Celsius). -temp1_crit - Maximum junction temperature (in millidegrees Celsius). +temp1_max - All cooling devices should be turned on (on Core2). +temp1_crit - Maximum junction temperature (in millidegrees Celsius). temp1_crit_alarm - Set when Out-of-spec bit is set, never clears. Correct CPU operation is no longer guaranteed. temp1_label - Contains string "Core X", where X is processor diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 3bd95836015..c31e0291e16 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -12,8 +12,9 @@ Supported adapters: * Intel 82801G (ICH7) * Intel 631xESB/632xESB (ESB2) * Intel 82801H (ICH8) - * Intel ICH9 + * Intel 82801I (ICH9) * Intel Tolapai + * Intel ICH10 Datasheets: Publicly available at the Intel website Authors: diff --git a/Documentation/ide/00-INDEX b/Documentation/ide/00-INDEX new file mode 100644 index 00000000000..d6b778842b7 --- /dev/null +++ b/Documentation/ide/00-INDEX @@ -0,0 +1,12 @@ |