diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/feature-removal-schedule.txt | 9 | ||||
| -rw-r--r-- | Documentation/hwmon/f71805f | 105 | ||||
| -rw-r--r-- | Documentation/hwmon/it87 | 2 | ||||
| -rw-r--r-- | Documentation/hwmon/sysfs-interface | 18 | ||||
| -rw-r--r-- | Documentation/i2c/busses/i2c-sis96x (renamed from Documentation/i2c/busses/i2c-sis69x) | 4 | ||||
| -rw-r--r-- | Documentation/unshare.txt | 295 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.cx88 | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.saa7134 | 6 |
8 files changed, 433 insertions, 8 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 4d4897c8ef963..b730d765b525b 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -162,3 +162,12 @@ What: pci_module_init(driver) When: January 2007 Why: Is replaced by pci_register_driver(pci_driver). Who: Richard Knutsson <ricknu-0@student.ltu.se> and Greg Kroah-Hartman <gregkh@suse.de> + +--------------------------- + +What: I2C interface of the it87 driver +When: January 2007 +Why: The ISA interface is faster and should be always available. The I2C + probing is also known to cause trouble in at least one case (see + bug #5889.) +Who: Jean Delvare <khali@linux-fr.org> diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f new file mode 100644 index 0000000000000..28c5b7d1eb90f --- /dev/null +++ b/Documentation/hwmon/f71805f @@ -0,0 +1,105 @@ +Kernel driver f71805f +===================== + +Supported chips: + * Fintek F71805F/FG + Prefix: 'f71805f' + Addresses scanned: none, address read from Super I/O config space + Datasheet: Provided by Fintek on request + +Author: Jean Delvare <khali@linux-fr.org> + +Thanks to Denis Kieft from Barracuda Networks for the donation of a +test system (custom Jetway K8M8MS motherboard, with CPU and RAM) and +for providing initial documentation. + +Thanks to Kris Chen from Fintek for answering technical questions and +providing additional documentation. + +Thanks to Chris Lin from Jetway for providing wiring schematics and +anwsering technical questions. + + +Description +----------- + +The Fintek F71805F/FG Super I/O chip includes complete hardware monitoring +capabilities. It can monitor up to 9 voltages (counting its own power +source), 3 fans and 3 temperature sensors. + +This chip also has fan controlling features, using either DC or PWM, in +three different modes (one manual, two automatic). The driver doesn't +support these features yet. + +The driver assumes that no more than one chip is present, which seems +reasonable. + + +Voltage Monitoring +------------------ + +Voltages are sampled by an 8-bit ADC with a LSB of 8 mV. The supported +range is thus from 0 to 2.040 V. Voltage values outside of this range +need external resistors. An exception is in0, which is used to monitor +the chip's own power source (+3.3V), and is divided internally by a +factor 2. + +The two LSB of the voltage limit registers are not used (always 0), so +you can only set the limits in steps of 32 mV (before scaling). + +The wirings and resistor values suggested by Fintek are as follow: + + pin expected + name use R1 R2 divider raw val. + +in0 VCC VCC3.3V int. int. 2.00 1.65 V +in1 VIN1 VTT1.2V 10K - 1.00 1.20 V +in2 VIN2 VRAM 100K 100K 2.00 ~1.25 V (1) +in3 VIN3 VCHIPSET 47K 100K 1.47 2.24 V (2) +in4 VIN4 VCC5V 200K 47K 5.25 0.95 V +in5 VIN5 +12V 200K 20K 11.00 1.05 V +in6 VIN6 VCC1.5V 10K - 1.00 1.50 V +in7 VIN7 VCORE 10K - 1.00 ~1.40 V (1) +in8 VIN8 VSB5V 200K 47K 1.00 0.95 V + +(1) Depends on your hardware setup. +(2) Obviously not correct, swapping R1 and R2 would make more sense. + +These values can be used as hints at best, as motherboard manufacturers +are free to use a completely different setup. As a matter of fact, the +Jetway K8M8MS uses a significantly different setup. You will have to +find out documentation about your own motherboard, and edit sensors.conf +accordingly. + +Each voltage measured has associated low and high limits, each of which +triggers an alarm when crossed. + + +Fan Monitoring +-------------- + +Fan rotation speeds are reported as 12-bit values from a gated clock +signal. Speeds down to 366 RPM can be measured. There is no theoretical +high limit, but values over 6000 RPM seem to cause problem. The effective +resolution is much lower than you would expect, the step between different +register values being 10 rather than 1. + +The chip assumes 2 pulse-per-revolution fans. + +An alarm is triggered if the rotation speed drops below a programmable +limit or is too low to be measured. + + +Temperature Monitoring +---------------------- + +Temperatures are reported in degrees Celsius. Each temperature measured +has a high limit, those crossing triggers an alarm. There is an associated +hysteresis value, below which the temperature has to drop before the +alarm is cleared. + +All temperature channels are external, there is no embedded temperature +sensor. Each channel can be used for connecting either a thermal diode +or a thermistor. The driver reports the currently selected mode, but +doesn't allow changing it. In theory, the BIOS should have configured +everything properly. diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 7f42e441c6450..9555be1ed9994 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -9,7 +9,7 @@ Supported chips: http://www.ite.com.tw/ * IT8712F Prefix: 'it8712' - Addresses scanned: I2C 0x28 - 0x2f + Addresses scanned: I2C 0x2d from Super I/O config space (8 I/O ports) Datasheet: Publicly available at the ITE website http://www.ite.com.tw/ diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 764cdc5480e79..a0d0ab24288e6 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -179,11 +179,12 @@ temp[1-*]_auto_point[1-*]_temp_hyst **************** temp[1-3]_type Sensor type selection. - Integers 1, 2, 3 or thermistor Beta value (3435) + Integers 1 to 4 or thermistor Beta value (typically 3435) Read/Write. 1: PII/Celeron Diode 2: 3904 transistor 3: thermal diode + 4: thermistor (default/unknown Beta) Not all types are supported by all chips temp[1-4]_max Temperature max value. @@ -261,6 +262,21 @@ alarms Alarm bitmask. of individual bits. Bits are defined in kernel/include/sensors.h. +alarms_in Alarm bitmask relative to in (voltage) channels + Read only + A '1' bit means an alarm, LSB corresponds to in0 and so on + Prefered to 'alarms' for newer chips + +alarms_fan Alarm bitmask relative to fan channels + Read only + A '1' bit means an alarm, LSB corresponds to fan1 and so on + Prefered to 'alarms' for newer chips + +alarms_temp Alarm bitmask relative to temp (temperature) channels + Read only + A '1' bit means an alarm, LSB corresponds to temp1 and so on + Prefered to 'alarms' for newer chips + beep_enable Beep/interrupt enable 0 to disable. 1 to enable. diff --git a/Documentation/i2c/busses/i2c-sis69x b/Documentation/i2c/busses/i2c-sis96x index b88953dfd5802..00a009b977e92 100644 --- a/Documentation/i2c/busses/i2c-sis69x +++ b/Documentation/i2c/busses/i2c-sis96x @@ -7,7 +7,7 @@ Supported adapters: Any combination of these host bridges: 645, 645DX (aka 646), 648, 650, 651, 655, 735, 745, 746 and these south bridges: - 961, 962, 963(L) + 961, 962, 963(L) Author: Mark M. Hoffman <mhoffman@lightlink.com> @@ -29,7 +29,7 @@ The command "lspci" as root should produce something like these lines: or perhaps this... -00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645 +00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645 00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961 00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016 diff --git a/Documentation/unshare.txt b/Documentation/unshare.txt new file mode 100644 index 0000000000000..90a5e9e5bef1d --- /dev/null +++ b/Documentation/unshare.txt @@ -0,0 +1,295 @@ + +unshare system call: +-------------------- +This document describes the new system call, unshare. The document +provides an overview of the feature, why it is needed, how it can +be used, its interface specification, design, implementation and +how it can be tested. + +Change Log: +----------- +version 0.1 Initial document, Janak Desai (janak@us.ibm.com), Jan 11, 2006 + +Contents: +--------- + 1) Overview + 2) Benefits + 3) Cost + 4) Requirements + 5) Functional Specification + 6) High Level Design + 7) Low Level Design + 8) Test Specification + 9) Future Work + +1) Overview +----------- +Most legacy operating system kernels support an abstraction of threads +as multiple execution contexts within a process. These kernels provide +special resources and mechanisms to maintain these "threads". The Linux +kernel, in a clever and simple manner, does not make distinction +between processes and "threads". The kernel allows processes to share +resources and thus they can achieve legacy "threads" behavior without +requiring additional data structures and mechanisms in the kernel. The +power of implementing threads in this manner comes not only from +its simplicity but also from allowing application programmers to work +outside the confinement of all-or-nothing shared resources of legacy +threads. On Linux, at the time of thread creation using the clone system +call, applications can selectively choose which resources to share +between threads. + +unshare system call adds a primitive to the Linux thread model that +allows threads to selectively 'unshare' any resources that were being +shared at the time of their creation. unshare was conceptualized by +Al Viro in the August of 2000, on the Linux-Kernel mailing list, as part +of the discussion on POSIX threads on Linux. unshare augments the +usefulness of Linux threads for applications that would like to control +shared resources without creating a new process. unshare is a natural +addition to the set of available primitives on Linux that implement +the concept of process/thread as a virtual machine. + +2) Benefits +----------- +unshare would be useful to large application frameworks such as PAM +where creating a new process to control sharing/unsharing of process +resources is not possible. Since namespaces are shared by default +when creating a new process using fork or clone, unshare can benefit +even non-threaded applications if they have a need to disassociate +from default shared namespace. The following lists two use-cases +where unshare can be used. + +2.1 Per-security context namespaces +----------------------------------- +unshare can be used to implement polyinstantiated directories using +the kernel's per-process namespace mechanism. Polyinstantiated directories, +such as per-user and/or per-security context instance of /tmp, /var/tmp or +per-security context instance of a user's home directory, isolate user +processes when working with these directories. Using unshare, a PAM +module can easily setup a private namespace for a user at login. +Polyinstantiated directories are required for Common Criteria certification +with Labeled System Protection Profile, however, with the availability +of shared-tree feature in the Linux kernel, even regular Linux systems +can benefit from setting up private namespaces at login and +polyinstantiating /tmp, /var/tmp and other directories deemed +appropriate by system administrators. + +2.2 unsharing of virtual memory and/or open files +------------------------------------------------- +Consider a client/server application where the server is processing +client requests by creating processes that share resources such as +virtual memory and open files. Without unshare, the server has to +decide what needs to be shared at the time of creating the process +which services the request. unshare allows the server an ability to +disassociate parts of the context during the servicing of the +request. For large and complex middleware application frameworks, this +ability to unshare after the process was created can be very +useful. + +3) Cost +------- +In order to not duplicate code and to handle the fact that unshare +works on an active task (as opposed to clone/fork working on a newly +allocated inactive task) unshare had to make minor reorganizational +changes to copy_* functions utilized by clone/fork system call. +There is a cost associated with altering existing, well tested and +stable code to implement a new feature that may not get exercised +extensively in the beginning. However, with proper design and code +review of the changes and creation of an unshare test for the LTP +the benefits of this new feature can exceed its cost. + +4) Requirements +--------------- +unshare reverses sharing that was done using clone(2) system call, +so unshare should have a similar interface as clone(2). That is, +since flags in clone(int flags, void *stack) specifies what should +be shared, similar flags in unshare(int flags) should specify +what should be unshared. Unfortunately, this may appear to invert +the meaning of the flags from the way they are used in clone(2). +However, there was no easy solution that was less confusing and that +allowed incremental context unsharing in future without an ABI change. + +unshare interface should accommodate possible future addition of +new context flags without requiring a rebuild of old applications. +If and when new context flags are added, unshare design should allow +incremental unsharing of those resources on an as needed basis. + +5) Functional Specification +--------------------------- +NAME + unshare - disassociate parts of the process execution context + +SYNOPSIS + #include <sched.h> + + int unshare(int flags); + +DESCRIPTION + unshare allows a process to disassociate parts of its execution + context that are currently being shared with other processes. Part + of execution context, such as the namespace, is shared by default + when a new process is created using fork(2), while other parts, + such as the virtual memory, open file descriptors, etc, may be + shared by explicit request to share them when creating a process + using clone(2). + + The main use of unshare is to allow a process to control its + shared execution context without creating a new process. + + The flags argument specifies one or bitwise-or'ed of several of + the following constants. + + CLONE_FS + If CLONE_FS is set, file system information of the caller + is disassociated from the shared file system information. + + CLONE_FILES + If CLONE_FILES is set, the file descriptor table of the + caller is disassociated from the shared file descriptor + table. + + CLONE_NEWNS + If CLONE_NEWNS is set, the namespace of the caller is + disassociated from the shared namespace. + + CLONE_VM + If CLONE_VM is set, the virtual memory of the caller is + disassociated from the shared virtual memory. + +RETURN VALUE + On success, zero returned. On failure, -1 is returned and errno is + +ERRORS + EPERM CLONE_NEWNS was specified by a non-root process (process + without CAP_SYS_ADMIN). + + ENOMEM Cannot allocate sufficient memory to copy parts of caller's + context that need to be unshared. + + EINVAL Invalid flag was specified as an argument. + +CONFORMING TO + The unshare() call is Linux-specific and should not be used + in programs intended to be portable. + +SEE ALSO + clone(2), fork(2) + +6) High Level Design +-------------------- +Depending on the flags argument, the unshare system call allocates +appropriate process context structures, populates it with values from +the current shared version, associates newly duplicated structures +with the current task structure and releases corresponding shared +versions. Helper functions of clone (copy_*) could not be used +directly by unshare because of the following two reasons. + 1) clone operates on a newly allocated not-yet-active task + structure, where as unshare operates on the current active + task. Therefore unshare has to take appropriate task_lock() + before associating newly duplicated context structures + 2) unshare has to allocate and duplicate all context structures + that are being unshared, before associating them with the + current task and releasing older shared structures. Failure + do so will create race conditions and/or oops when trying + to backout due to an error. Consider the case of unsharing + both virtual memory and namespace. After successfully unsharing + vm, if the system call encounters an error while allocating + new namespace structure, the error return code will have to + reverse the unsharing of vm. As part of the reversal the + system call will have to go back to older, shared, vm + structure, which may not exist anymore. + +Therefore code from copy_* functions that allocated and duplicated +current context structure was moved into new dup_* functions. Now, +copy_* functions call dup_* functions to allocate and duplicate +appropriate context structures and then associate them with the +task structure that is being constructed. unshare system call on +the other hand performs the following: + 1) Check flags to force missing, but implied, flags + 2) For each context structure, call the corresponding unshare + helper function to allocate and duplicate a new context + structure, if the appropriate bit is set in the flags argument. + 3) If there is no error in allocation and duplication and there + are new context structures then lock the current task structure, + associate new context structures with the current task structure, + and release the lock on the current task structure. + 4) Appropriately release older, shared, context structures. + +7) Low Level Design +------------------- +Implementation of unshare can be grouped in the following 4 different +items: + a) Reorganization of existing copy_* functions + b) unshare system call service function + c) unshare helper functions for each different process context + d) Registration of system call number for different architectures + + 7.1) Reorganization of copy_* functions + Each copy function such as copy_mm, copy_namespace, copy_files, + etc, had roughly two components. The first component allocated + and duplicated the appropriate structure and the second component + linked it to the task structure passed in as an argument to the copy + function. The first component was split into its own function. + These dup_* functions allocated and duplicated the appropriate + context structure. The reorganized copy_* functions invoked + their corresponding dup_* functions and then linked the newly + duplicated structures to the task structure with which the + copy function was called. + + 7.2) unshare system call service function + * Check flags + Force implied flags. If CLONE_THREAD is set force CLONE_VM. + If CLONE_VM is set, force CLONE_SIGHAND. If CLONE_SIGHAND is + set and signals are also being shared, force CLONE_THREAD. If + CLONE_NEWNS is set, force CLONE_FS. + * For each context flag, invoke the corresponding unshare_* + helper routine with flags passed into the system call and a + reference to pointer pointing the new unshared structure + * If any new structures are created by unshare_* helper + functions, take the task_lock() on the current task, + modify appropriate context pointers, and release the + task lock. + * For all newly unshared structures, release the corresponding + older, shared, structures. + + 7.3) unshare_* helper functions + For unshare_* helpers corresponding to CLONE_SYSVSEM, CLONE_SIGHAND, + and CLONE_THREAD, return -EINVAL since they are not implemented yet. + For others, check the flag value to see if the unsharing is + required for that structure. If it is, invoke the corresponding + dup_* function to allocate and duplicate the structure and return + a pointer to it. + + 7.4) Appropriately modify architecture specific code to register the + the new system call. + +8) Test Specification +--------------------- +The test for unshare should test the following: + 1) Valid flags: Test to check that clone flags for signal and + signal handlers, for which unsharing is not implemented + yet, return -EINVAL. + 2) Missing/implied flags: Test to make sure that if unsharing + namespace without specifying unsharing of filesystem, correctly + unshares both namespace and filesystem information. + 3) For each of the four (namespace, filesystem, files and vm) + supported unsharing, verify that the system call correctly + unshares the appropriate structure. Verify that unsharing + them individually as well as in combination with each + other works as expected. + 4) Concurrent execution: Use shared memory segments and futex on + an address in the shm segment to synchronize execution of + about 10 threads. Have a couple of threads execute execve, + a couple _exit and the rest unshare with different combination + of flags. Verify that unsharing is performed as expected and + that there are no oops or hangs. + +9) Future Work +-------------- +The current implementation of unshare does not allow unsharing of +signals and signal handlers. Signals are complex to begin with and +to unshare signals and/or signal handlers of a currently running +process is even more complex. If in the future there is a specific +need to allow unsharing of signals and/or signal handlers, it can +be incrementally added to unshare without affecting legacy +applications using unshare. + diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 56e194f1a0b06..8bea3fbd05482 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 @@ -42,4 +42,4 @@ 41 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profile) [0070:9800,0070:9802] 42 -> digitalnow DNTV Live! DVB-T Pro [1822:0025] 43 -> KWorld/VStream XPert DVB-T with cx22702 [17de:08a1] - 44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50] + 44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50,18ac:db54] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index cb3a59bbeb172..8a352597830ff 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -1,7 +1,7 @@ 0 -> UNKNOWN/GENERIC 1 -> Proteus Pro [philips reference design] [1131:2001,1131:2001] 2 -> LifeView FlyVIDEO3000 [5168:0138,4e42:0138] - 3 -> LifeView FlyVIDEO2000 [5168:0138] + 3 -> LifeView/Typhoon FlyVIDEO2000 [5168:0138,4e42:0138] 4 -> EMPRESS [1131:6752] 5 -> SKNet Monster TV [1131:4e85] 6 -> Tevion MD 9717 @@ -53,12 +53,12 @@ 52 -> AverMedia AverTV/305 [1461:2108] 53 -> ASUS TV-FM 7135 [1043:4845] 54 -> LifeView FlyTV Platinum FM [5168:0214,1489:0214] - 55 -> LifeView FlyDVB-T DUO [5168:0502,5168:0306] + 55 -> LifeView FlyDVB-T DUO [5168:0306] 56 -> Avermedia AVerTV 307 [1461:a70a] 57 -> Avermedia AVerTV GO 007 FM [1461:f31f] 58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0351,1421:0370,1421:1370] 59 -> Kworld/Tevion V-Stream Xpert TV PVR7134 - 60 -> Typhoon DVB-T Duo Digital/Analog Cardbus [4e42:0502] + 60 -> LifeView/Typhoon FlyDVB-T Duo Cardbus [5168:0502,4e42:0502] 61 -> Philips TOUGH DVB-T reference design [1131:2004] 62 -> Compro VideoMate TV Gold+II 63 -> Kworld Xpert TV PVR7134 |