ukui/kernel
0
0
Fork 0
mirror of https://github.com/ukui/kernel.git synced 2026-03-09 10:07:04 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'for-2.6.33' into for-2.6.34

Browse Source
This commit is contained in:
Mark Brown
2010-01-25 14:52:48 +00:00
parent 84549d239a 40aa7030e5
commit f1487fcbe4
1246 changed files with 31063 additions and 11397 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@@ -37,6 +37,7 @@ modules.builtin
tags
TAGS
vmlinux
vmlinuz
System.map
Module.markers
Module.symvers

12
Documentation/DocBook/mtdnand.tmpl
View File

@@ -174,7 +174,7 @@
</para>
<programlisting>
static struct mtd_info *board_mtd;
static unsigned long baseaddr;
static void __iomem *baseaddr;
</programlisting>
<para>
Static example
@@ -182,7 +182,7 @@ static unsigned long baseaddr;
<programlisting>
static struct mtd_info board_mtd;
static struct nand_chip board_chip;
static unsigned long baseaddr;
static void __iomem *baseaddr;
</programlisting>
</sect1>
<sect1 id="Partition_defines">
@@ -283,8 +283,8 @@ int __init board_init (void)
}
/* map physical address */
baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
if(!baseaddr){
baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
if (!baseaddr) {
printk("Ioremap to access NAND chip failed\n");
err = -EIO;
goto out_mtd;
@@ -316,7 +316,7 @@ int __init board_init (void)
goto out;
out_ior:
iounmap((void *)baseaddr);
iounmap(baseaddr);
out_mtd:
kfree (board_mtd);
out:
@@ -341,7 +341,7 @@ static void __exit board_cleanup (void)
nand_release (board_mtd);
/* unmap physical address */
iounmap((void *)baseaddr);
iounmap(baseaddr);
/* Free the MTD device structure */
kfree (board_mtd);

2
Documentation/IO-mapping.txt
View File

@@ -157,7 +157,7 @@ For such memory, you can do things like
* access only the 640k-1MB area, so anything else
* has to be remapped.
*/
char * baseptr = ioremap(0xFC000000, 1024*1024);
void __iomem *baseptr = ioremap(0xFC000000, 1024*1024);
/* write a 'A' to the offset 10 of the area */
writeb('A',baseptr+10);

0
Documentation/DMA-mapping.txt → Documentation/PCI/PCI-DMA-mapping.txt
View File

2
Documentation/block/00-INDEX
View File

@@ -1,7 +1,5 @@
00-INDEX
- This file
as-iosched.txt
- Anticipatory IO scheduler
barrier.txt
- I/O Barriers
biodoc.txt

172
Documentation/block/as-iosched.txt
View File

@@ -1,172 +0,0 @@
Anticipatory IO scheduler
-------------------------
Nick Piggin <piggin@cyberone.com.au> 13 Sep 2003
Attention! Database servers, especially those using "TCQ" disks should
investigate performance with the 'deadline' IO scheduler. Any system with high
disk performance requirements should do so, in fact.
If you see unusual performance characteristics of your disk systems, or you
see big performance regressions versus the deadline scheduler, please email
me. Database users don't bother unless you're willing to test a lot of patches
from me ;) its a known issue.
Also, users with hardware RAID controllers, doing striping, may find
highly variable performance results with using the as-iosched. The
as-iosched anticipatory implementation is based on the notion that a disk
device has only one physical seeking head. A striped RAID controller
actually has a head for each physical device in the logical RAID device.
However, setting the antic_expire (see tunable parameters below) produces
very similar behavior to the deadline IO scheduler.
Selecting IO schedulers
-----------------------
Refer to Documentation/block/switching-sched.txt for information on
selecting an io scheduler on a per-device basis.
Anticipatory IO scheduler Policies
----------------------------------
The as-iosched implementation implements several layers of policies
to determine when an IO request is dispatched to the disk controller.
Here are the policies outlined, in order of application.
1. one-way Elevator algorithm.
The elevator algorithm is similar to that used in deadline scheduler, with
the addition that it allows limited backward movement of the elevator
(i.e. seeks backwards). A seek backwards can occur when choosing between
two IO requests where one is behind the elevator's current position, and
the other is in front of the elevator's position. If the seek distance to
the request in back of the elevator is less than half the seek distance to
the request in front of the elevator, then the request in back can be chosen.
Backward seeks are also limited to a maximum of MAXBACK (1024*1024) sectors.
This favors forward movement of the elevator, while allowing opportunistic
"short" backward seeks.
2. FIFO expiration times for reads and for writes.
This is again very similar to the deadline IO scheduler. The expiration
times for requests on these lists is tunable using the parameters read_expire
and write_expire discussed below. When a read or a write expires in this way,
the IO scheduler will interrupt its current elevator sweep or read anticipation
to service the expired request.
3. Read and write request batching
A batch is a collection of read requests or a collection of write
requests. The as scheduler alternates dispatching read and write batches
to the driver. In the case a read batch, the scheduler submits read
requests to the driver as long as there are read requests to submit, and
the read batch time limit has not been exceeded (read_batch_expire).
The read batch time limit begins counting down only when there are
competing write requests pending.
In the case of a write batch, the scheduler submits write requests to
the driver as long as there are write requests available, and the
write batch time limit has not been exceeded (write_batch_expire).
However, the length of write batches will be gradually shortened
when read batches frequently exceed their time limit.
When changing between batch types, the scheduler waits for all requests
from the previous batch to complete before scheduling requests for the
next batch.
The read and write fifo expiration times described in policy 2 above
are checked only when in scheduling IO of a batch for the corresponding
(read/write) type. So for example, the read FIFO timeout values are
tested only during read batches. Likewise, the write FIFO timeout
values are tested only during write batches. For this reason,
it is generally not recommended for the read batch time
to be longer than the write expiration time, nor for the write batch
time to exceed the read expiration time (see tunable parameters below).
When the IO scheduler changes from a read to a write batch,
it begins the elevator from the request that is on the head of the
write expiration FIFO. Likewise, when changing from a write batch to
a read batch, scheduler begins the elevator from the first entry
on the read expiration FIFO.
4. Read anticipation.
Read anticipation occurs only when scheduling a read batch.
This implementation of read anticipation allows only one read request
to be dispatched to the disk controller at a time. In
contrast, many write requests may be dispatched to the disk controller
at a time during a write batch. It is this characteristic that can make
the anticipatory scheduler perform anomalously with controllers supporting
TCQ, or with hardware striped RAID devices. Setting the antic_expire
queue parameter (see below) to zero disables this behavior, and the
anticipatory scheduler behaves essentially like the deadline scheduler.
When read anticipation is enabled (antic_expire is not zero), reads
are dispatched to the disk controller one at a time.
At the end of each read request, the IO scheduler examines its next
candidate read request from its sorted read list. If that next request
is from the same process as the request that just completed,
or if the next request in the queue is "very close" to the
just completed request, it is dispatched immediately. Otherwise,
statistics (average think time, average seek distance) on the process
that submitted the just completed request are examined. If it seems
likely that that process will submit another request soon, and that
request is likely to be near the just completed request, then the IO
scheduler will stop dispatching more read requests for up to (antic_expire)
milliseconds, hoping that process will submit a new request near the one
that just completed. If such a request is made, then it is dispatched
immediately. If the antic_expire wait time expires, then the IO scheduler
will dispatch the next read request from the sorted read queue.
To decide whether an anticipatory wait is worthwhile, the scheduler
maintains statistics for each process that can be used to compute
mean "think time" (the time between read requests), and mean seek
distance for that process. One observation is that these statistics
are associated with each process, but those statistics are not associated
with a specific IO device. So for example, if a process is doing IO
on several file systems on separate devices, the statistics will be
a combination of IO behavior from all those devices.
Tuning the anticipatory IO scheduler
------------------------------------
When using 'as', the anticipatory IO scheduler there are 5 parameters under
/sys/block/*/queue/iosched/. All are units of milliseconds.
The parameters are:
* read_expire
Controls how long until a read request becomes "expired". It also controls the
interval between which expired requests are served, so set to 50, a request
might take anywhere < 100ms to be serviced _if_ it is the next on the
expired list. Obviously request expiration strategies won't make the disk
go faster. The result basically equates to the timeslice a single reader
gets in the presence of other IO. 100*((seek time / read_expire) + 1) is
very roughly the % streaming read efficiency your disk should get with
multiple readers.
* read_batch_expire
Controls how much time a batch of reads is given before pending writes are
served. A higher value is more efficient. This might be set below read_expire
if writes are to be given higher priority than reads, but reads are to be
as efficient as possible when there are no writes. Generally though, it
should be some multiple of read_expire.
* write_expire, and
* write_batch_expire are equivalent to the above, for writes.
* antic_expire
Controls the maximum amount of time we can anticipate a good read (one
with a short seek distance from the most recently completed request) before
giving up. Many other factors may cause anticipation to be stopped early,
or some processes will not be "anticipated" at all. Should be a bit higher
for big seek time devices though not a linear correspondence - most
processes have only a few ms thinktime.
In addition to the tunables above there is a read-only file named est_time
which, when read, will show:
- The probability of a task exiting without a cooperating task
submitting an anticipated IO.
- The current mean think time.
- The seek distance used to determine if an incoming IO is better.

2
Documentation/block/biodoc.txt
View File

@@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address
do not have a corresponding kernel virtual address space mapping) and
low-memory pages.
Note: Please refer to Documentation/DMA-mapping.txt for a discussion
Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
for 64 bit PCI.

49
Documentation/feature-removal-schedule.txt
View File

@@ -493,3 +493,52 @@ Why: These two features use non-standard interfaces. There are the
Who: Corentin Chary <corentin.chary@gmail.com>
----------------------------
What: usbvideo quickcam_messenger driver
When: 2.6.35
Files: drivers/media/video/usbvideo/quickcam_messenger.[ch]
Why: obsolete v4l1 driver replaced by gspca_stv06xx
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: ov511 v4l1 driver
When: 2.6.35
Files: drivers/media/video/ov511.[ch]
Why: obsolete v4l1 driver replaced by gspca_ov519
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: w9968cf v4l1 driver
When: 2.6.35
Files: drivers/media/video/w9968cf*.[ch]
Why: obsolete v4l1 driver replaced by gspca_ov519
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: ovcamchip sensor framework
When: 2.6.35
Files: drivers/media/video/ovcamchip/*
Why: Only used by obsoleted v4l1 drivers
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: stv680 v4l1 driver
When: 2.6.35
Files: drivers/media/video/stv680.[ch]
Why: obsolete v4l1 driver replaced by gspca_stv0680
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: zc0301 v4l driver
When: 2.6.35
Files: drivers/media/video/zc0301/*
Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only
supports 2 USB-ID's (because it only supports a limited set of
sensors) wich are also supported by the gspca_zc3xx driver
(which supports 53 USB-ID's in total)
Who: Hans de Goede <hdegoede@redhat.com>

2
Documentation/filesystems/ext4.txt
View File

@@ -196,7 +196,7 @@ nobarrier This also requires an IO stack which can support
also be used to enable or disable barriers, for
consistency with other ext4 mount options.
inode_readahead=n This tuning parameter controls the maximum
inode_readahead_blks=n This tuning parameter controls the maximum
number of inode table blocks that ext4's inode
table readahead algorithm will pre-read into
the buffer cache. The default value is 32 blocks.

2
Documentation/filesystems/nilfs2.txt
View File

@@ -28,7 +28,7 @@ described in the man pages included in the package.
Project web page: http://www.nilfs.org/en/
Download page: http://www.nilfs.org/en/download.html
Git tree web page: http://www.nilfs.org/git/
NILFS mailing lists: http://www.nilfs.org/mailman/listinfo/users
List info: http://vger.kernel.org/vger-lists.html#linux-nilfs
Caveats
=======

2
Documentation/filesystems/proc.txt
View File

@@ -177,7 +177,6 @@ read the file /proc/PID/status:
CapBnd: ffffffffffffffff
voluntary_ctxt_switches: 0
nonvoluntary_ctxt_switches: 1
Stack usage: 12 kB
This shows you nearly the same information you would get if you viewed it with
the ps command. In fact, ps uses the proc file system to obtain its
@@ -231,7 +230,6 @@ Table 1-2: Contents of the statm files (as of 2.6.30-rc7)
Mems_allowed_list Same as previous, but in "list format"
voluntary_ctxt_switches number of voluntary context switches
nonvoluntary_ctxt_switches number of non voluntary context switches
Stack usage: stack usage high water mark (round up to page size)
..............................................................................
Table 1-3: Contents of the statm files (as of 2.6.8-rc3)

102
Documentation/hwmon/amc6821 Normal file
View File

@@ -0,0 +1,102 @@
Kernel driver amc6821
=====================
Supported chips:
Texas Instruments AMC6821
Prefix: 'amc6821'
Addresses scanned: 0x18, 0x19, 0x1a, 0x2c, 0x2d, 0x2e, 0x4c, 0x4d, 0x4e
Datasheet: http://focus.ti.com/docs/prod/folders/print/amc6821.html
Authors:
Tomaz Mertelj <tomaz.mertelj@guest.arnes.si>
Description
-----------
This driver implements support for the Texas Instruments amc6821 chip.
The chip has one on-chip and one remote temperature sensor and one pwm fan
regulator.
The pwm can be controlled either from software or automatically.
The driver provides the following sensor accesses in sysfs:
temp1_input ro on-chip temperature
temp1_min rw "
temp1_max rw "
temp1_crit rw "
temp1_min_alarm ro "
temp1_max_alarm ro "
temp1_crit_alarm ro "
temp2_input ro remote temperature
temp2_min rw "
temp2_max rw "
temp2_crit rw "
temp2_min_alarm ro "
temp2_max_alarm ro "
temp2_crit_alarm ro "
temp2_fault ro "
fan1_input ro tachometer speed
fan1_min rw "
fan1_max rw "
fan1_fault ro "
fan1_div rw Fan divisor can be either 2 or 4.
pwm1 rw pwm1
pwm1_enable rw regulator mode, 1=open loop, 2=fan controlled
by remote temperature, 3=fan controlled by
combination of the on-chip temperature and
remote-sensor temperature,
pwm1_auto_channels_temp ro 1 if pwm_enable==2, 3 if pwm_enable==3
pwm1_auto_point1_pwm ro Hardwired to 0, shared for both
temperature channels.
pwm1_auto_point2_pwm rw This value is shared for both temperature
channels.
pwm1_auto_point3_pwm rw Hardwired to 255, shared for both
temperature channels.
temp1_auto_point1_temp ro Hardwired to temp2_auto_point1_temp
which is rw. Below this temperature fan stops.
temp1_auto_point2_temp rw The low-temperature limit of the proportional
range. Below this temperature
pwm1 = pwm1_auto_point2_pwm. It can go from
0 degree C to 124 degree C in steps of
4 degree C. Read it out after writing to get
the actual value.
temp1_auto_point3_temp rw Above this temperature fan runs at maximum
speed. It can go from temp1_auto_point2_temp.
It can only have certain discrete values
which depend on temp1_auto_point2_temp and
pwm1_auto_point2_pwm. Read it out after
writing to get the actual value.
temp2_auto_point1_temp rw Must be between 0 degree C and 63 degree C and
it defines the passive cooling temperature.
Below this temperature the fan stops in
the closed loop mode.
temp2_auto_point2_temp rw The low-temperature limit of the proportional
range. Below this temperature
pwm1 = pwm1_auto_point2_pwm. It can go from
0 degree C to 124 degree C in steps
of 4 degree C.
temp2_auto_point3_temp rw Above this temperature fan runs at maximum
speed. It can only have certain discrete
values which depend on temp2_auto_point2_temp
and pwm1_auto_point2_pwm. Read it out after
writing to get actual value.
Module parameters
-----------------
If your board has a BIOS that initializes the amc6821 correctly, you should
load the module with: init=0.
If your board BIOS doesn't initialize the chip, or you want
different settings, you can set the following parameters:
init=1,
pwminv: 0 default pwm output, 1 inverts pwm output.

17
Documentation/hwmon/k10temp
View File

@@ -3,8 +3,8 @@ Kernel driver k10temp
Supported chips:
* AMD Family 10h processors:
Socket F: Quad-Core/Six-Core/Embedded Opteron
Socket AM2+: Opteron, Phenom (II) X3/X4
Socket F: Quad-Core/Six-Core/Embedded Opteron (but see below)
Socket AM2+: Quad-Core Opteron, Phenom (II) X3/X4, Athlon X2 (but see below)
Socket AM3: Quad-Core Opteron, Athlon/Phenom II X2/X3/X4, Sempron II
Socket S1G3: Athlon II, Sempron, Turion II
* AMD Family 11h processors:
@@ -36,10 +36,15 @@ Description
This driver permits reading of the internal temperature sensor of AMD
Family 10h and 11h processors.
All these processors have a sensor, but on older revisions of Family 10h
processors, the sensor may return inconsistent values (erratum 319). The
driver will refuse to load on these revisions unless you specify the
"force=1" module parameter.
All these processors have a sensor, but on those for Socket F or AM2+,
the sensor may return inconsistent values (erratum 319). The driver
will refuse to load on these revisions unless you specify the "force=1"
module parameter.
Due to technical reasons, the driver can detect only the mainboard's
socket type, not the processor's actual capabilities. Therefore, if you
are using an AM3 processor on an AM2+ mainboard, you can safely use the
"force=1" parameter.
There is one temperature measurement value, available as temp1_input in
sysfs. It is measured in degrees Celsius with a resolution of 1/8th degree.

203
Documentation/ioctl/ioctl-number.txt
View File

@@ -56,10 +56,11 @@ Following this convention is good because:
(5) When following the convention, the driver code can use generic
code to copy the parameters between user and kernel space.
This table lists ioctls visible from user land for Linux/i386. It contains
most drivers up to 2.3.14, but I know I am missing some.
This table lists ioctls visible from user land for Linux/x86. It contains
most drivers up to 2.6.31, but I know I am missing some. There has been
no attempt to list non-X86 architectures or ioctls from drivers/staging/.
Code Seq# Include File Comments
Code Seq#(hex) Include File Comments
========================================================
0x00 00-1F linux/fs.h conflict!
0x00 00-1F scsi/scsi_ioctl.h conflict!
@@ -69,119 +70,228 @@ Code Seq# Include File Comments
0x03 all linux/hdreg.h
0x04 D2-DC linux/umsdos_fs.h Dead since 2.6.11, but don't reuse these.
0x06 all linux/lp.h
0x09 all linux/md.h
0x09 all linux/raid/md_u.h
0x10 00-0F drivers/char/s390/vmcp.h
0x12 all linux/fs.h
linux/blkpg.h
0x1b all InfiniBand Subsystem <http://www.openib.org/>
0x20 all drivers/cdrom/cm206.h
0x22 all scsi/sg.h
'#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem
'$' 00-0F linux/perf_counter.h, linux/perf_event.h
'1' 00-1F <linux/timepps.h> PPS kit from Ulrich Windl
<ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/>
'2' 01-04 linux/i2o.h
'3' 00-0F drivers/s390/char/raw3270.h conflict!
'3' 00-1F linux/suspend_ioctls.h conflict!
and kernel/power/user.c
'8' all SNP8023 advanced NIC card
<mailto:mcr@solidum.com>
'A' 00-1F linux/apm_bios.h
'@' 00-0F linux/radeonfb.h conflict!
'@' 00-0F drivers/video/aty/aty128fb.c conflict!
'A' 00-1F linux/apm_bios.h conflict!
'A' 00-0F linux/agpgart.h conflict!
and drivers/char/agp/compat_ioctl.h
'A' 00-7F sound/asound.h conflict!
'B' 00-1F linux/cciss_ioctl.h conflict!
'B' 00-0F include/linux/pmu.h conflict!
'B' C0-FF advanced bbus
<mailto:maassen@uni-freiburg.de>
'C' all linux/soundcard.h
'C' all linux/soundcard.h conflict!
'C' 01-2F linux/capi.h conflict!
'C' F0-FF drivers/net/wan/cosa.h conflict!
'D' all arch/s390/include/asm/dasd.h
'E' all linux/input.h
'F' all linux/fb.h
'H' all linux/hiddev.h
'I' all linux/isdn.h
'D' 40-5F drivers/scsi/dpt/dtpi_ioctl.h
'D' 05 drivers/scsi/pmcraid.h
'E' all linux/input.h conflict!
'E' 00-0F xen/evtchn.h conflict!
'F' all linux/fb.h conflict!
'F' 01-02 drivers/scsi/pmcraid.h conflict!
'F' 20 drivers/video/fsl-diu-fb.h conflict!
'F' 20 drivers/video/intelfb/intelfb.h conflict!
'F' 20 linux/ivtvfb.h conflict!
'F' 20 linux/matroxfb.h conflict!
'F' 20 drivers/video/aty/atyfb_base.c conflict!
'F' 00-0F video/da8xx-fb.h conflict!
'F' 80-8F linux/arcfb.h conflict!
'F' DD video/sstfb.h conflict!
'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict!
'G' 00-0F linux/gigaset_dev.h conflict!
'H' 00-7F linux/hiddev.h conflict!
'H' 00-0F linux/hidraw.h conflict!
'H' 00-0F sound/asound.h conflict!
'H' 20-40 sound/asound_fm.h conflict!
'H' 80-8F sound/sfnt_info.h conflict!
'H' 10-8F sound/emu10k1.h conflict!
'H' 10-1F sound/sb16_csp.h conflict!
'H' 10-1F sound/hda_hwdep.h conflict!
'H' 40-4F sound/hdspm.h conflict!
'H' 40-4F sound/hdsp.h conflict!
'H' 90 sound/usb/usx2y/usb_stream.h
'H' C0-F0 net/bluetooth/hci.h conflict!
'H' C0-DF net/bluetooth/hidp/hidp.h conflict!
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!
'H' C0-DF net/bluetooth/bnep/bnep.h conflict!
'I' all linux/isdn.h conflict!
'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict!
'I' 40-4F linux/mISDNif.h conflict!
'J' 00-1F drivers/scsi/gdth_ioctl.h
'K' all linux/kd.h
'L' 00-1F linux/loop.h
'L' 20-2F driver/usb/misc/vstusb.h
'L' 00-1F linux/loop.h conflict!
'L' 10-1F drivers/scsi/mpt2sas/mpt2sas_ctl.h conflict!
'L' 20-2F linux/usb/vstusb.h
'L' E0-FF linux/ppdd.h encrypted disk device driver
<http://linux01.gwdg.de/~alatham/ppdd.html>
'M' all linux/soundcard.h
'M' all linux/soundcard.h conflict!
'M' 01-16 mtd/mtd-abi.h conflict!
and drivers/mtd/mtdchar.c
'M' 01-03 drivers/scsi/megaraid/megaraid_sas.h
'M' 00-0F drivers/video/fsl-diu-fb.h conflict!
'N' 00-1F drivers/usb/scanner.h
'O' 00-02 include/mtd/ubi-user.h UBI
'P' all linux/soundcard.h
'O' 00-06 mtd/ubi-user.h UBI
'P' all linux/soundcard.h conflict!
'P' 60-6F sound/sscape_ioctl.h conflict!
'P' 00-0F drivers/usb/class/usblp.c conflict!
'Q' all linux/soundcard.h
'R' 00-1F linux/random.h
'R' 00-1F linux/random.h conflict!
'R' 01 linux/rfkill.h conflict!
'R' 01-0F media/rds.h conflict!
'R' C0-DF net/bluetooth/rfcomm.h
'S' all linux/cdrom.h conflict!
'S' 80-81 scsi/scsi_ioctl.h conflict!
'S' 82-FF scsi/scsi.h conflict!
'S' 00-7F sound/asequencer.h conflict!
'T' all linux/soundcard.h conflict!
'T' 00-AF sound/asound.h conflict!
'T' all arch/x86/include/asm/ioctls.h conflict!
'U' 00-EF linux/drivers/usb/usb.h
'V' all linux/vt.h
'T' C0-DF linux/if_tun.h conflict!
'U' all sound/asound.h conflict!
'U' 00-0F drivers/media/video/uvc/uvcvideo.h conflict!
'U' 00-CF linux/uinput.h conflict!
'U' 00-EF linux/usbdevice_fs.h
'U' C0-CF drivers/bluetooth/hci_uart.h
'V' all linux/vt.h conflict!
'V' all linux/videodev2.h conflict!
'V' C0 linux/ivtvfb.h conflict!
'V' C0 linux/ivtv.h conflict!
'V' C0 media/davinci/vpfe_capture.h conflict!
'V' C0 media/si4713.h conflict!
'V' C0-CF drivers/media/video/mxb.h conflict!
'W' 00-1F linux/watchdog.h conflict!
'W' 00-1F linux/wanrouter.h conflict!
'X' all linux/xfs_fs.h
'W' 00-3F sound/asound.h conflict!
'X' all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
and include/linux/falloc.h
and linux/fs.h
'X' all fs/ocfs2/ocfs_fs.h conflict!
'X' 01 linux/pktcdvd.h conflict!
'Y' all linux/cyclades.h
'[' 00-07 linux/usb/usbtmc.h USB Test and Measurement Devices
'Z' 14-15 drivers/message/fusion/mptctl.h
'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices
<mailto:gregkh@suse.de>
'a' all ATM on linux
'a' all linux/atm*.h, linux/sonet.h ATM on linux
<http://lrcwww.epfl.ch/linux-atm/magic.html>
'b' 00-FF bit3 vme host bridge
'b' 00-FF conflict! bit3 vme host bridge
<mailto:natalia@nikhefk.nikhef.nl>
'b' 00-0F media/bt819.h conflict!
'c' all linux/cm4000_cs.h conflict!
'c' 00-7F linux/comstats.h conflict!
'c' 00-7F linux/coda.h conflict!
'c' 80-9F arch/s390/include/asm/chsc.h
'c' A0-AF arch/x86/include/asm/msr.h
'c' 00-1F linux/chio.h conflict!
'c' 80-9F arch/s390/include/asm/chsc.h conflict!
'c' A0-AF arch/x86/include/asm/msr.h conflict!
'd' 00-FF linux/char/drm/drm/h conflict!
'd' 02-40 pcmcia/ds.h conflict!
'd' 10-3F drivers/media/video/dabusb.h conflict!
'd' C0-CF drivers/media/video/saa7191.h conflict!
'd' F0-FF linux/digi1.h
'e' all linux/digi1.h conflict!
'e' 00-1F net/irda/irtty.h conflict!
'f' 00-1F linux/ext2_fs.h
'h' 00-7F Charon filesystem
'e' 00-1F drivers/net/irda/irtty-sir.h conflict!
'f' 00-1F linux/ext2_fs.h conflict!
'f' 00-1F linux/ext3_fs.h conflict!
'f' 00-0F fs/jfs/jfs_dinode.h conflict!
'f' 00-0F fs/ext4/ext4.h conflict!
'f' 00-0F linux/fs.h conflict!
'f' 00-0F fs/ocfs2/ocfs2_fs.h conflict!
'g' 00-0F linux/usb/gadgetfs.h
'g' 20-2F linux/usb/g_printer.h
'h' 00-7F conflict! Charon filesystem
<mailto:zapman@interlan.net>
'i' 00-3F linux/i2o.h
'h' 00-1F linux/hpet.h conflict!
'i' 00-3F linux/i2o-dev.h conflict!
'i' 0B-1F linux/ipmi.h conflict!
'i' 80-8F linux/i8k.h
'j' 00-3F linux/joystick.h
'k' 00-0F linux/spi/spidev.h conflict!
'k' 00-05 video/kyro.h conflict!
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
<http://mikonos.dia.unisa.it/tcfs>
'l' 40-7F linux/udf_fs_i.h in development:
<http://sourceforge.net/projects/linux-udf/>
'm' 00-09 linux/mmtimer.h
'm' 00-09 linux/mmtimer.h conflict!
'm' all linux/mtio.h conflict!
'm' all linux/soundcard.h conflict!
'm' all linux/synclink.h conflict!
'm' 00-19 drivers/message/fusion/mptctl.h conflict!
'm' 00 drivers/scsi/megaraid/megaraid_ioctl.h conflict!
'm' 00-1F net/irda/irmod.h conflict!
'n' 00-7F linux/ncp_fs.h
'n' 00-7F linux/ncp_fs.h and fs/ncpfs/ioctl.c
'n' 80-8F linux/nilfs2_fs.h NILFS2
'n' E0-FF video/matrox.h matroxfb
'n' E0-FF linux/matroxfb.h matroxfb
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
'o' 00-03 include/mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
'o' 40-41 include/mtd/ubi-user.h UBI
'o' 01-A1 include/linux/dvb/*.h DVB
'o' 00-03 mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
'o' 40-41 mtd/ubi-user.h UBI
'o' 01-A1 linux/dvb/*.h DVB
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
'p' 00-1F linux/rtc.h conflict!
'p' 00-3F linux/mc146818rtc.h conflict!
'p' 40-7F linux/nvram.h
'p' 80-9F user-space parport
'p' 80-9F linux/ppdev.h user-space parport
<mailto:tim@cyberelk.net>
'p' a1-a4 linux/pps.h LinuxPPS
'p' A1-A4 linux/pps.h LinuxPPS
<mailto:giometti@linux.it>
'q' 00-1F linux/serio.h
'q' 80-FF Internet PhoneJACK, Internet LineJACK
<http://www.quicknet.net>
'r' 00-1F linux/msdos_fs.h
'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK
linux/ixjuser.h <http://www.quicknet.net>
'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c
's' all linux/cdk.h
't' 00-7F linux/if_ppp.h
't' 80-8F linux/isdn_ppp.h
't' 90 linux/toshiba.h
'u' 00-1F linux/smb_fs.h
'v' 00-1F linux/ext2_fs.h conflict!
'v' all linux/videodev.h conflict!
'v' 00-1F linux/ext2_fs.h conflict!
'v' 00-1F linux/fs.h conflict!
'v' 00-0F linux/sonypi.h conflict!
'v' C0-CF drivers/media/video/ov511.h conflict!
'v' C0-DF media/pwc-ioctl.h conflict!
'v' C0-FF linux/meye.h conflict!
'v' C0-CF drivers/media/video/zoran/zoran.h conflict!
'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict!
'w' all CERN SCI driver
'y' 00-1F packet based user level communications
<mailto:zapman@interlan.net>
'z' 00-3F CAN bus card
'z' 00-3F CAN bus card conflict!
<mailto:hdstich@connectu.ulm.circular.de>
'z' 40-7F CAN bus card
'z' 40-7F CAN bus card conflict!
<mailto:oe@port.de>
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
0x80 00-1F linux/fb.h
0x81 00-1F linux/videotext.h
0x88 00-3F media/ovcamchip.h
0x89 00-06 arch/x86/include/asm/sockios.h
0x89 0B-DF linux/sockios.h
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
0x89 E0-EF linux/dn.h PROTOPRIVATE range
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
0x8B all linux/wireless.h
0x8C 00-3F WiNRADiO driver
<http://www.proximity.com.au/~brian/winradio/>
0x90 00 drivers/cdrom/sbpcd.h
0x92 00-0F drivers/usb/mon/mon_bin.c
0x93 60-7F linux/auto_fs.h
0x94 all fs/btrfs/ioctl.h
0x99 00-0F 537-Addinboard driver
<mailto:buk@buks.ipn.de>
0xA0 all linux/sdp/sdp.h Industrial Device Project
@@ -192,17 +302,22 @@ Code Seq# Include File Comments
0xAB 00-1F linux/nbd.h
0xAC 00-1F linux/raw.h
0xAD 00 Netfilter device in development:
<mailto:rusty@rustcorp.com.au>
<mailto:rusty@rustcorp.com.au>
0xAE all linux/kvm.h Kernel-based Virtual Machine
<mailto:kvm@vger.kernel.org>
0xB0 all RATIO devices in development:
<mailto:vgo@ratio.de>
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
0xC0 00-0F linux/usb/iowarrior.h
0xCB 00-1F CBM serial IEC bus in development:
<mailto:michael.klein@puffin.lb.shuttle.de>
0xCD 01 linux/reiserfs_fs.h
0xCF 02 fs/cifs/ioctl.c
0xDB 00-0F drivers/char/mwave/mwavepub.h
0xDD 00-3F ZFCP device driver see drivers/s390/scsi/
<mailto:aherrman@de.ibm.com>
0xF3 00-3F video/sisfb.h sisfb (in development)
0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development)
<mailto:thomas@winischhofer.net>
0xF4 00-1F video/mbxfb.h mbxfb
<mailto:raph@8d.com>
0xFD all linux/dm-ioctl.h

12
Documentation/kernel-doc-nano-HOWTO.txt
View File

@@ -214,11 +214,13 @@ The format of the block comment is like this:
* (section header: (section description)? )*
(*)?*/
The short function description ***cannot be multiline***, but the other
descriptions can be (and they can contain blank lines). If you continue
that initial short description onto a second line, that second line will
appear further down at the beginning of the description section, which is
almost certainly not what you had in mind.
All "description" text can span multiple lines, although the
function_name & its short description are traditionally on a single line.
Description text may also contain blank lines (i.e., lines that contain
only a "*").
"section header:" names must be unique per function (or struct,
union, typedef, enum).
Avoid putting a spurious blank line after the function name, or else the
description will be repeated!

5
Documentation/kernel-parameters.txt
View File

@@ -240,7 +240,7 @@ and is between 256 and 4096 characters. It is defined in the file
acpi_sleep= [HW,ACPI] Sleep options
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
old_ordering, s4_nonvs }
old_ordering, s4_nonvs, sci_force_enable }
See Documentation/power/video.txt for information on
s3_bios and s3_mode.
s3_beep is for debugging; it makes the PC's speaker beep
@@ -253,6 +253,9 @@ and is between 256 and 4096 characters. It is defined in the file
of _PTS is used by default).
s4_nonvs prevents the kernel from saving/restoring the
ACPI NVS memory during hibernation.
sci_force_enable causes the kernel to set SCI_EN directly
on resume from S1/S3 (which is against the ACPI spec,
but some broken systems don't work without it).
acpi_use_timer_override [HW,ACPI]
Use timer override. For some broken Nvidia NF5 boards

10
Documentation/kvm/api.txt
View File

@@ -685,7 +685,7 @@ struct kvm_vcpu_events {
__u8 pad;
} nmi;
__u32 sipi_vector;
__u32 flags; /* must be zero */
__u32 flags;
};
4.30 KVM_SET_VCPU_EVENTS
@@ -701,6 +701,14 @@ vcpu.
See KVM_GET_VCPU_EVENTS for the data structure.
Fields that may be modified asynchronously by running VCPUs can be excluded
from the update. These fields are nmi.pending and sipi_vector. Keep the
corresponding bits in the flags field cleared to suppress overwriting the
current in-kernel state. The bits are:
KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel
KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector
5. The kvm_run structure

58
Documentation/laptops/thinkpad-acpi.txt
View File

@@ -1092,8 +1092,8 @@ WARNING:
its level up and down at every change.
Volume control
--------------
Volume control (Console Audio control)
--------------------------------------
procfs: /proc/acpi/ibm/volume
ALSA: "ThinkPad Console Audio Control", default ID: "ThinkPadEC"
@@ -1110,9 +1110,53 @@ the desktop environment to just provide on-screen-display feedback.
Software volume control should be done only in the main AC97/HDA
mixer.
This feature allows volume control on ThinkPad models with a digital
volume knob (when available, not all models have it), as well as
mute/unmute control. The available commands are:
About the ThinkPad Console Audio control:
ThinkPads have a built-in amplifier and muting circuit that drives the
console headphone and speakers. This circuit is after the main AC97
or HDA mixer in the audio path, and under exclusive control of the
firmware.
ThinkPads have three special hotkeys to interact with the console
audio control: volume up, volume down and mute.
It is worth noting that the normal way the mute function works (on
ThinkPads that do not have a "mute LED") is:
1. Press mute to mute. It will *always* mute, you can press it as
many times as you want, and the sound will remain mute.
2. Press either volume key to unmute the ThinkPad (it will _not_
change the volume, it will just unmute).
This is a very superior design when compared to the cheap software-only
mute-toggle solution found on normal consumer laptops: you can be
absolutely sure the ThinkPad will not make noise if you press the mute
button, no matter the previous state.
The IBM ThinkPads, and the earlier Lenovo ThinkPads have variable-gain
amplifiers driving the speakers and headphone output, and the firmware
also handles volume control for the headphone and speakers on these
ThinkPads without any help from the operating system (this volume
control stage exists after the main AC97 or HDA mixer in the audio
path).
The newer Lenovo models only have firmware mute control, and depend on
the main HDA mixer to do volume control (which is done by the operating
system). In this case, the volume keys are filtered out for unmute
key press (there are some firmware bugs in this area) and delivered as
normal key presses to the operating system (thinkpad-acpi is not
involved).
The ThinkPad-ACPI volume control:
The preferred way to interact with the Console Audio control is the
ALSA interface.
The legacy procfs interface allows one to read the current state,
and if volume control is enabled, accepts the following commands:
echo up >/proc/acpi/ibm/volume
echo down >/proc/acpi/ibm/volume
@@ -1121,12 +1165,10 @@ mute/unmute control. The available commands are:
echo 'level <level>' >/proc/acpi/ibm/volume
The <level> number range is 0 to 14 although not all of them may be
distinct. The unmute the volume after the mute command, use either the
distinct. To unmute the volume after the mute command, use either the
up or down command (the level command will not unmute the volume), or
the unmute command.
The current volume level and mute state is shown in the file.
You can use the volume_capabilities parameter to tell the driver
whether your thinkpad has volume control or mute-only control:
volume_capabilities=1 for mixers with mute and volume control,

12
Documentation/networking/3c509.txt
View File

@@ -48,11 +48,11 @@ for LILO parameters for doing this:
This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and
transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts
with other card types when overriding the I/O address. When the driver is
loaded as a module, only the IRQ and transceiver setting may be overridden.
For example, setting two cards to 10base2/IRQ10 and AUI/IRQ11 is done by using
the xcvr and irq module options:
loaded as a module, only the IRQ may be overridden. For example,
setting two cards to IRQ10 and IRQ11 is done by using the irq module
option:
options 3c509 xcvr=3,1 irq=10,11
options 3c509 irq=10,11
(2) Full-duplex mode
@@ -77,6 +77,8 @@ operation.
itself full-duplex capable. This is almost certainly one of two things: a full-
duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on
another system that's connected directly to the 3c509B via a crossover cable.
Full-duplex mode can be enabled using 'ethtool'.
/////Extremely important caution concerning full-duplex mode/////
Understand that the 3c509B's hardware's full-duplex support is much more
@@ -113,6 +115,8 @@ This insured that merely upgrading the driver from an earlier version would
never automatically enable full-duplex mode in an existing installation;
it must always be explicitly enabled via one of these code in order to be
activated.
The transceiver type can be changed using 'ethtool'.
(4a) Interpretation of error messages and common problems

2
Documentation/sound/alsa/Procfile.txt
View File

@@ -95,7 +95,7 @@ card*/pcm*/xrun_debug
It takes an integer value, can be changed by writing to this
file, such as
# cat 5 > /proc/asound/card0/pcm0p/xrun_debug
# echo 5 > /proc/asound/card0/pcm0p/xrun_debug
The value consists of the following bit flags:
bit 0 = Enable XRUN/jiffies debug messages

Some files were not shown because too many files have changed in this diff Show More