diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/DocBook/kgdb.tmpl | 20 | ||||
| -rw-r--r-- | Documentation/feature-removal-schedule.txt | 9 | ||||
| -rw-r--r-- | Documentation/hwmon/sysfs-interface | 33 | ||||
| -rw-r--r-- | Documentation/i2c/writing-clients | 18 | ||||
| -rw-r--r-- | Documentation/kernel-parameters.txt | 5 | ||||
| -rw-r--r-- | Documentation/networking/ip-sysctl.txt | 12 | ||||
| -rw-r--r-- | Documentation/networking/s2io.txt | 6 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.au0828 | 2 |
8 files changed, 55 insertions, 50 deletions
diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index 028a8444d95..e8acd1f0345 100644 --- a/Documentation/DocBook/kgdb.tmpl +++ b/Documentation/DocBook/kgdb.tmpl @@ -84,10 +84,9 @@ runs an instance of gdb against the vmlinux file which contains the symbols (not boot image such as bzImage, zImage, uImage...). In gdb the developer specifies the connection parameters and - connects to kgdb. Depending on which kgdb I/O modules exist in - the kernel for a given architecture, it may be possible to debug - the test machine's kernel with the development machine using a - rs232 or ethernet connection. + connects to kgdb. The type of connection a developer makes with + gdb depends on the availability of kgdb I/O modules compiled as + builtin's or kernel modules in the test machine's kernel. </para> </chapter> <chapter id="CompilingAKernel"> @@ -223,7 +222,7 @@ </para> <para> IMPORTANT NOTE: Using this option with kgdb over the console - (kgdboc) or kgdb over ethernet (kgdboe) is not supported. + (kgdboc) is not supported. </para> </sect1> </chapter> @@ -249,18 +248,11 @@ (gdb) target remote /dev/ttyS0 </programlisting> <para> - Example (kgdb to a terminal server): + Example (kgdb to a terminal server on tcp port 2012): </para> <programlisting> % gdb ./vmlinux - (gdb) target remote udp:192.168.2.2:6443 - </programlisting> - <para> - Example (kgdb over ethernet): - </para> - <programlisting> - % gdb ./vmlinux - (gdb) target remote udp:192.168.2.2:6443 + (gdb) target remote 192.168.2.2:2012 </programlisting> <para> Once connected, you can debug a kernel the way you would debug an diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 5b3f31faed5..46ece3fba6f 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -312,3 +312,12 @@ When: 2.6.26 Why: Implementation became generic; users should now include linux/semaphore.h instead. Who: Matthew Wilcox <willy@linux.intel.com> + +--------------------------- + +What: CONFIG_THERMAL_HWMON +When: January 2009 +Why: This option was introduced just to allow older lm-sensors userspace + to keep working over the upgrade to 2.6.26. At the scheduled time of + removal fixed lm-sensors (2.x or 3.x) should be readily available. +Who: Rene Herman <rene.herman@gmail.com> diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index f4a8ebc1ef1..2d845730d4e 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -2,17 +2,12 @@ Naming and data format standards for sysfs files ------------------------------------------------ The libsensors library offers an interface to the raw sensors data -through the sysfs interface. See libsensors documentation and source for -further information. As of writing this document, libsensors -(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating -support for any given chip requires modifying the library's code. -This is because libsensors was written for the procfs interface -older kernel modules were using, which wasn't standardized enough. -Recent versions of libsensors (from lm_sensors 2.8.2 and later) have -support for the sysfs interface, though. - -The new sysfs interface was designed to be as chip-independent as -possible. +through the sysfs interface. Since lm-sensors 3.0.0, libsensors is +completely chip-independent. It assumes that all the kernel drivers +implement the standard sysfs interface described in this document. +This makes adding or updating support for any given chip very easy, as +libsensors, and applications using it, do not need to be modified. +This is a major improvement compared to lm-sensors 2. Note that motherboards vary widely in the connections to sensor chips. There is no standard that ensures, for example, that the second @@ -35,19 +30,17 @@ access this data in a simple and consistent way. That said, such programs will have to implement conversion, labeling and hiding of inputs. For this reason, it is still not recommended to bypass the library. -If you are developing a userspace application please send us feedback on -this standard. - -Note that this standard isn't completely established yet, so it is subject -to changes. If you are writing a new hardware monitoring driver those -features can't seem to fit in this interface, please contact us with your -extension proposal. Keep in mind that backward compatibility must be -preserved. - Each chip gets its own directory in the sysfs /sys/devices tree. To find all sensor chips, it is easier to follow the device symlinks from /sys/class/hwmon/hwmon*. +Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes +in the "physical" device directory. Since lm-sensors 3.0.1, attributes found +in the hwmon "class" device directory are also supported. Complex drivers +(e.g. drivers for multifunction chips) may want to use this possibility to +avoid namespace pollution. The only drawback will be that older versions of +libsensors won't support the driver in question. + All sysfs values are fixed point numbers. There is only one value per file, unlike the older /proc specification. diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index ee75cbace28..d4cd4126d1a 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -25,12 +25,23 @@ routines, and should be zero-initialized except for fields with data you provide. A client structure holds device-specific information like the driver model device node, and its I2C address. +/* iff driver uses driver model ("new style") binding model: */ + +static struct i2c_device_id foo_idtable[] = { + { "foo", my_id_for_foo }, + { "bar", my_id_for_bar }, + { } +}; + +MODULE_DEVICE_TABLE(i2c, foo_idtable); + static struct i2c_driver foo_driver = { .driver = { .name = "foo", }, /* iff driver uses driver model ("new style") binding model: */ + .id_table = foo_ids, .probe = foo_probe, .remove = foo_remove, @@ -173,10 +184,9 @@ handle may be used during foo_probe(). If foo_probe() reports success (zero not a negative status code) it may save the handle and use it until foo_remove() returns. That binding model is used by most Linux drivers. -Drivers match devices when i2c_client.driver_name and the driver name are -the same; this approach is used in several other busses that don't have -device typing support in the hardware. The driver and module name should -match, so hotplug/coldplug mechanisms will modprobe the driver. +The probe function is called when an entry in the id_table name field +matches the device's name. It is passed the entry that was matched so +the driver knows which one in the table matched. Device Creation (Standard driver model) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index e07c432c731..f1e970acad4 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1208,6 +1208,11 @@ and is between 256 and 4096 characters. It is defined in the file mtdparts= [MTD] See drivers/mtd/cmdlinepart.c. + mtdset= [ARM] + ARM/S3C2412 JIVE boot control + + See arch/arm/mach-s3c2412/mach-jive.c + mtouchusb.raw_coordinates= [HW] Make the MicroTouch USB driver use raw coordinates ('y', default) or cooked coordinates ('n') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 17a6e46fbd4..17f1f91af35 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -81,23 +81,23 @@ inet_peer_minttl - INTEGER Minimum time-to-live of entries. Should be enough to cover fragment time-to-live on the reassembling side. This minimum time-to-live is guaranteed if the pool size is less than inet_peer_threshold. - Measured in jiffies(1). + Measured in seconds. inet_peer_maxttl - INTEGER Maximum time-to-live of entries. Unused entries will expire after this period of time if there is no memory pressure on the pool (i.e. when the number of entries in the pool is very small). - Measured in jiffies(1). + Measured in seconds. inet_peer_gc_mintime - INTEGER Minimum interval between garbage collection passes. This interval is in effect under high memory pressure on the pool. - Measured in jiffies(1). + Measured in seconds. inet_peer_gc_maxtime - INTEGER Minimum interval between garbage collection passes. This interval is in effect under low (or absent) memory pressure on the pool. - Measured in jiffies(1). + Measured in seconds. TCP variables: @@ -794,10 +794,6 @@ tag - INTEGER Allows you to write a number, which can be used as required. Default value is 0. -(1) Jiffie: internal timeunit for the kernel. On the i386 1/100s, on the -Alpha 1/1024s. See the HZ define in /usr/include/asm/param.h for the exact -value on your system. - Alexey Kuznetsov. kuznet@ms2.inr.ac.ru diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt index 4bde53e85f3..1e28e2ddb90 100644 --- a/Documentation/networking/s2io.txt +++ b/Documentation/networking/s2io.txt @@ -83,9 +83,9 @@ Valid range: Limited by memory on system Default: 30 e. intr_type -Specifies interrupt type. Possible values 1(INTA), 2(MSI), 3(MSI-X) -Valid range: 1-3 -Default: 1 +Specifies interrupt type. Possible values 0(INTA), 2(MSI-X) +Valid values: 0, 2 +Default: 2 5. Performance suggestions General: diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 index aaae360312e..86d1c8e7b18 100644 --- a/Documentation/video4linux/CARDLIST.au0828 +++ b/Documentation/video4linux/CARDLIST.au0828 @@ -1,4 +1,4 @@ 0 -> Unknown board (au0828) - 1 -> Hauppauge HVR950Q (au0828) [2040:7200] + 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008] 2 -> Hauppauge HVR850 (au0828) [2040:7240] 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] |