apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

Browse Source 
Conflicts:

	drivers/usb/input/hid.h
This commit is contained in:
Dmitry Torokhov
2006-12-08 01:07:56 -05:00
parent 4bdbd2807d c99767974e
commit bef986502f
4033 changed files with 157164 additions and 79872 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+1
View File
@@ -20,6 +20,7 @@
# Top-level generic files
#
tags
TAGS
vmlinux*
System.map
Module.symvers
CREDITS
+6 -5
View File
@@ -45,7 +45,7 @@ S: Longford, Ireland
S: Sydney, Australia
N: Tigran A. Aivazian
E: tigran@veritas.com
E: tigran@aivazian.fsnet.co.uk
W: http://www.moses.uklinux.net/patches
D: BFS filesystem
D: Intel IA32 CPU microcode update support
@@ -2598,6 +2598,9 @@ S: Ucitelska 1576
S: Prague 8
S: 182 00 Czech Republic
N: Rick Payne
D: RFC2385 Support for TCP
N: Barak A. Pearlmutter
E: bap@cs.unm.edu
W: http://www.cs.unm.edu/~bap/
@@ -3511,14 +3514,12 @@ D: The Linux Support Team Erlangen
N: David Weinehall
E: tao@acc.umu.se
P: 1024D/DC47CA16 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16
W: http://www.acc.umu.se/~tao/
W: http://www.acc.umu.se/~mcalinux/
D: v2.0 kernel maintainer
D: Fixes for the NE/2-driver
D: Miscellaneous MCA-support
D: Cleanup of the Config-files
S: Axtorpsvagen 40:20
S: S-903 37 UMEA
S: Sweden
N: Matt Welsh
E: mdw@metalab.unc.edu
Documentation/00-INDEX
-2
View File
@@ -104,8 +104,6 @@ firmware_class/
- request_firmware() hotplug interface info.
floppy.txt
- notes and driver options for the floppy disk driver.
ftape.txt
- notes about the floppy tape device driver.
hayes-esp.txt
- info on using the Hayes ESP serial driver.
highuid.txt
Documentation/Changes
+1 -1
View File
@@ -201,7 +201,7 @@ udev
----
udev is a userspace application for populating /dev dynamically with
only entries for devices actually present. udev replaces the basic
functionality of devfs, while allowing persistant device naming for
functionality of devfs, while allowing persistent device naming for
devices.
FUSE
Documentation/DMA-API.txt
+7 -7
View File
@@ -77,7 +77,7 @@ To get this part of the dma_ API, you must #include <linux/dmapool.h>
Many drivers need lots of small dma-coherent memory regions for DMA
descriptors or I/O buffers. Rather than allocating in units of a page
or more using dma_alloc_coherent(), you can use DMA pools. These work
much like a kmem_cache_t, except that they use the dma-coherent allocator
much like a struct kmem_cache, except that they use the dma-coherent allocator
not __get_free_pages(). Also, they understand common hardware constraints
for alignment, like queue heads needing to be aligned on N byte boundaries.
@@ -94,7 +94,7 @@ The pool create() routines initialize a pool of dma-coherent buffers
for use with a given device. It must be called in a context which
can sleep.
The "name" is for diagnostics (like a kmem_cache_t name); dev and size
The "name" is for diagnostics (like a struct kmem_cache name); dev and size
are like what you'd pass to dma_alloc_coherent(). The device's hardware
alignment requirement for this type of data is "align" (which is expressed
in bytes, and must be a power of two). If your device has no boundary
@@ -431,10 +431,10 @@ be identical to those passed in (and returned by
dma_alloc_noncoherent()).
int
dma_is_consistent(dma_addr_t dma_handle)
dma_is_consistent(struct device *dev, dma_addr_t dma_handle)
returns true if the memory pointed to by the dma_handle is actually
consistent.
returns true if the device dev is performing consistent DMA on the memory
area pointed to by the dma_handle.
int
dma_get_cache_alignment(void)
@@ -459,7 +459,7 @@ anything like this. You must also be extra careful about accessing
memory you intend to sync partially.
void
dma_cache_sync(void *vaddr, size_t size,
dma_cache_sync(struct device *dev, void *vaddr, size_t size,
enum dma_data_direction direction)
Do a partial sync of memory that was allocated by
@@ -489,7 +489,7 @@ size is the size of the area (must be multiples of PAGE_SIZE).
flags can be or'd together and are
DMA_MEMORY_MAP - request that the memory returned from
dma_alloc_coherent() be directly writeable.
dma_alloc_coherent() be directly writable.
DMA_MEMORY_IO - request that the memory returned from
dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.
Documentation/DMA-ISA-LPC.txt
+1 -1
View File
@@ -110,7 +110,7 @@ lock.
Once the DMA transfer is finished (or timed out) you should disable
the channel again. You should also check get_dma_residue() to make
sure that all data has been transfered.
sure that all data has been transferred.
Example:
Documentation/DocBook/Makefile
+6 -2
View File
@@ -191,8 +191,12 @@ quiet_cmd_fig2png = FIG2PNG $@
# Help targets as used by the top-level makefile
dochelp:
@echo ' Linux kernel internal documentation in different formats:'
@echo ' xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF)'
@echo ' htmldocs (HTML), mandocs (man pages, use installmandocs to install)'
@echo ' htmldocs - HTML'
@echo ' installmandocs - install man pages generated by mandocs'
@echo ' mandocs - man pages'
@echo ' pdfdocs - PDF'
@echo ' psdocs - Postscript'
@echo ' xmldocs - XML DocBook'
###
# Temporary files left by various tools
Documentation/DocBook/kernel-api.tmpl
+29 -3
View File
@@ -418,9 +418,35 @@ X!Edrivers/pnp/system.c
!Idrivers/parport/daisy.c
</chapter>
<chapter id="viddev">
<title>Video4Linux</title>
!Edrivers/media/video/videodev.c
<chapter id="message_devices">
<title>Message-based devices</title>
<sect1><title>Fusion message devices</title>
!Edrivers/message/fusion/mptbase.c
!Idrivers/message/fusion/mptbase.c
!Edrivers/message/fusion/mptscsih.c
!Idrivers/message/fusion/mptscsih.c
!Idrivers/message/fusion/mptctl.c
!Idrivers/message/fusion/mptspi.c
!Idrivers/message/fusion/mptfc.c
!Idrivers/message/fusion/mptlan.c
</sect1>
<sect1><title>I2O message devices</title>
!Iinclude/linux/i2o.h
!Idrivers/message/i2o/core.h
!Edrivers/message/i2o/iop.c
!Idrivers/message/i2o/iop.c
!Idrivers/message/i2o/config-osm.c
!Edrivers/message/i2o/exec-osm.c
!Idrivers/message/i2o/exec-osm.c
!Idrivers/message/i2o/bus-osm.c
!Edrivers/message/i2o/device.c
!Idrivers/message/i2o/device.c
!Idrivers/message/i2o/driver.c
!Idrivers/message/i2o/pci.c
!Idrivers/message/i2o/i2o_block.c
!Idrivers/message/i2o/i2o_scsi.c
!Idrivers/message/i2o/i2o_proc.c
</sect1>
</chapter>
<chapter id="snddev">
Documentation/DocBook/writing_usb_driver.tmpl
-1
View File
@@ -345,7 +345,6 @@ static inline void skel_delete (struct usb_skel *dev)
usb_buffer_free (dev->udev, dev->bulk_out_size,
dev->bulk_out_buffer,
dev->write_urb->transfer_dma);
if (dev->write_urb != NULL)
usb_free_urb (dev->write_urb);
kfree (dev);
}
Documentation/IPMI.txt
+33 -1
View File
@@ -365,6 +365,7 @@ You can change this at module load time (for a module) with:
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...
unload_when_empty=[0|1]
Each of these except si_trydefaults is a list, the first item for the
first interface, second item for the second interface, etc.
@@ -416,6 +417,11 @@ by the driver, but systems with broken interrupts might need an enable,
or users that don't want the daemon (don't need the performance, don't
want the CPU hit) can disable it.
If unload_when_empty is set to 1, the driver will be unloaded if it
doesn't find any interfaces or all the interfaces fail to work. The
default is one. Setting to 0 is useful with the hotmod, but is
obviously only useful for modules.
When compiled into the kernel, the parameters can be specified on the
kernel command line as:
@@ -441,6 +447,25 @@ have high-res timers enabled in the kernel and you don't have
interrupts enabled, the driver will run VERY slowly. Don't blame me,
these interfaces suck.
The driver supports a hot add and remove of interfaces. This way,
interfaces can be added or removed after the kernel is up and running.
This is done using /sys/modules/ipmi_si/hotmod, which is a write-only
parameter. You write a string to this interface. The string has the
format:
<op1>[:op2[:op3...]]
The "op"s are:
add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]]
You can specify more than one interface on the line. The "opt"s are:
rsp=<regspacing>
rsi=<regsize>
rsh=<regshift>
irq=<irq>
ipmb=<ipmb slave addr>
and these have the same meanings as discussed above. Note that you
can also use this on the kernel command line for a more compact format
for specifying an interface. Note that when removing an interface,
only the first three parameters (si type, address type, and address)
are used for the comparison. Any options are ignored for removing.
The SMBus Driver
----------------
@@ -502,7 +527,10 @@ used to control it:
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
preaction=<preaction type> preop=<preop type> start_now=x
nowayout=x
nowayout=x ifnum_to_use=n
ifnum_to_use specifies which interface the watchdog timer should use.
The default is -1, which means to pick the first one registered.
The timeout is the number of seconds to the action, and the pretimeout
is the amount of seconds before the reset that the pre-timeout panic will
@@ -624,5 +652,9 @@ command line. The parameter is also available via the proc filesystem
in /proc/sys/dev/ipmi/poweroff_powercycle. Note that if the system
does not support power cycling, it will always do the power off.
The "ifnum_to_use" parameter specifies which interface the poweroff
code should use. The default is -1, which means to pick the first one
registered.
Note that if you have ACPI enabled, the system will prefer using ACPI to
power off.
Documentation/MSI-HOWTO.txt
+1 -1
View File
@@ -219,7 +219,7 @@ into the field vector of each element contained in a second argument.
Note that the pre-assigned IOAPIC dev->irq is valid only if the device
operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at
using dev->irq by the device driver to request for interrupt service
may result unpredictabe behavior.
may result in unpredictable behavior.
For each MSI-X vector granted, a device driver is responsible for calling
other functions like request_irq(), enable_irq(), etc. to enable
Documentation/accounting/taskstats.txt
+5 -5
View File
@@ -96,9 +96,9 @@ a) TASKSTATS_TYPE_AGGR_PID/TGID : attribute containing no payload but indicates
a pid/tgid will be followed by some stats.
b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose stats
is being returned.
are being returned.
c) TASKSTATS_TYPE_STATS: attribute with a struct taskstsats as payload. The
c) TASKSTATS_TYPE_STATS: attribute with a struct taskstats as payload. The
same structure is used for both per-pid and per-tgid stats.
3. New message sent by kernel whenever a task exits. The payload consists of a
@@ -122,12 +122,12 @@ of atomicity).
However, maintaining per-process, in addition to per-task stats, within the
kernel has space and time overheads. To address this, the taskstats code
accumalates each exiting task's statistics into a process-wide data structure.
When the last task of a process exits, the process level data accumalated also
accumulates each exiting task's statistics into a process-wide data structure.
When the last task of a process exits, the process level data accumulated also
gets sent to userspace (along with the per-task data).
When a user queries to get per-tgid data, the sum of all other live threads in
the group is added up and added to the accumalated total for previously exited
the group is added up and added to the accumulated total for previously exited
threads of the same thread group.
Extending taskstats
Documentation/block/as-iosched.txt
+4 -2
View File
@@ -24,8 +24,10 @@ very similar behavior to the deadline IO scheduler.
Selecting IO schedulers
-----------------------
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
'noop' and 'as' (the default) are also available. IO schedulers are assigned
globally at boot time only presently.
'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are
assigned globally at boot time only presently. It's also possible to change
the IO scheduler for a determined device on the fly, as described in
Documentation/block/switching-sched.txt.
Anticipatory IO scheduler Policies
Documentation/block/biodoc.txt
+5 -5
View File
@@ -183,7 +183,7 @@ it, the pci dma mapping routines and associated data structures have now been
modified to accomplish a direct page -> bus translation, without requiring
a virtual address mapping (unlike the earlier scheme of virtual address
-> bus translation). So this works uniformly for high-memory pages (which
do not have a correponding kernel virtual address space mapping) and
do not have a corresponding kernel virtual address space mapping) and
low-memory pages.
Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA
@@ -391,7 +391,7 @@ forced such requests to be broken up into small chunks before being passed
on to the generic block layer, only to be merged by the i/o scheduler
when the underlying device was capable of handling the i/o in one shot.
Also, using the buffer head as an i/o structure for i/os that didn't originate
from the buffer cache unecessarily added to the weight of the descriptors
from the buffer cache unnecessarily added to the weight of the descriptors
which were generated for each such chunk.
The following were some of the goals and expectations considered in the
@@ -403,14 +403,14 @@ i. Should be appropriate as a descriptor for both raw and buffered i/o -
for raw i/o.
ii. Ability to represent high-memory buffers (which do not have a virtual
address mapping in kernel address space).
iii.Ability to represent large i/os w/o unecessarily breaking them up (i.e
iii.Ability to represent large i/os w/o unnecessarily breaking them up (i.e
greater than PAGE_SIZE chunks in one shot)
iv. At the same time, ability to retain independent identity of i/os from
different sources or i/o units requiring individual completion (e.g. for
latency reasons)
v. Ability to represent an i/o involving multiple physical memory segments
(including non-page aligned page fragments, as specified via readv/writev)
without unecessarily breaking it up, if the underlying device is capable of
without unnecessarily breaking it up, if the underlying device is capable of
handling it.
vi. Preferably should be based on a memory descriptor structure that can be
passed around different types of subsystems or layers, maybe even
@@ -1013,7 +1013,7 @@ Characteristics:
i. Binary tree
AS and deadline i/o schedulers use red black binary trees for disk position
sorting and searching, and a fifo linked list for time-based searching. This
gives good scalability and good availablility of information. Requests are
gives good scalability and good availability of information. Requests are
almost always dispatched in disk sort order, so a cache is kept of the next
request in sort order to prevent binary tree lookups.
Documentation/cpu-freq/cpufreq-nforce2.txt
+2 -2
View File
@@ -1,7 +1,7 @@
The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 plattforms.
The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms.
This works better than on other plattforms, because the FSB of the CPU
This works better than on other platforms, because the FSB of the CPU
can be controlled independently from the PCI/AGP clock.
The module has two options:
Documentation/cpu-hotplug.txt
+2 -2
View File
@@ -54,8 +54,8 @@ additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT
to determine the number of potentially hot-pluggable cpus. The implementation
should only rely on this to count the #of cpus, but *MUST* not rely on the
apicid values in those tables for disabled apics. In the event BIOS doesnt
should only rely on this to count the # of cpus, but *MUST* not rely on the
apicid values in those tables for disabled apics. In the event BIOS doesn't
mark such hot-pluggable cpus as disabled entries, one could use this
parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map.
Documentation/devices.txt
+54 -28
View File
@@ -3,7 +3,7 @@
Maintained by Torben Mathiasen <device@lanana.org>
Last revised: 15 May 2006
Last revised: 29 November 2006
This list is the Linux Device List, the official registry of allocated
device numbers and /dev directory nodes for the Linux operating
@@ -92,8 +92,9 @@ Your cooperation is appreciated.
7 = /dev/full Returns ENOSPC on write
8 = /dev/random Nondeterministic random number gen.
9 = /dev/urandom Faster, less secure random number gen.
10 = /dev/aio Asyncronous I/O notification interface
10 = /dev/aio Asynchronous I/O notification interface
11 = /dev/kmsg Writes to this come out as printk's
1 block RAM disk
0 = /dev/ram0 First RAM disk
1 = /dev/ram1 Second RAM disk
@@ -506,6 +507,7 @@ Your cooperation is appreciated.
33 = /dev/patmgr1 Sequencer patch manager
34 = /dev/midi02 Third MIDI port
50 = /dev/midi03 Fourth MIDI port
14 block BIOS harddrive callback support {2.6}
0 = /dev/dos_hda First BIOS harddrive whole disk
64 = /dev/dos_hdb Second BIOS harddrive whole disk
@@ -527,6 +529,7 @@ Your cooperation is appreciated.
16 char Non-SCSI scanners
0 = /dev/gs4500 Genius 4500 handheld scanner
16 block GoldStar CD-ROM
0 = /dev/gscd GoldStar CD-ROM
@@ -548,6 +551,7 @@ Your cooperation is appreciated.
0 = /dev/ttyC0 First Cyclades port
...
31 = /dev/ttyC31 32nd Cyclades port
19 block "Double" compressed disk
0 = /dev/double0 First compressed disk
...
@@ -563,6 +567,7 @@ Your cooperation is appreciated.
0 = /dev/cub0 Callout device for ttyC0
...
31 = /dev/cub31 Callout device for ttyC31
20 block Hitachi CD-ROM (under development)
0 = /dev/hitcd Hitachi CD-ROM
@@ -639,6 +644,7 @@ Your cooperation is appreciated.
26 char Quanta WinVision frame grabber {2.6}
0 = /dev/wvisfgrab Quanta WinVision frame grabber
26 block Second Matsushita (Panasonic/SoundBlaster) CD-ROM
0 = /dev/sbpcd4 Panasonic CD-ROM controller 1 unit 0
1 = /dev/sbpcd5 Panasonic CD-ROM controller 1 unit 1
@@ -670,6 +676,7 @@ Your cooperation is appreciated.
37 = /dev/nrawqft1 Unit 1, no rewind-on-close, no file marks
38 = /dev/nrawqft2 Unit 2, no rewind-on-close, no file marks
39 = /dev/nrawqft3 Unit 3, no rewind-on-close, no file marks
27 block Third Matsushita (Panasonic/SoundBlaster) CD-ROM
0 = /dev/sbpcd8 Panasonic CD-ROM controller 2 unit 0
1 = /dev/sbpcd9 Panasonic CD-ROM controller 2 unit 1
@@ -681,6 +688,7 @@ Your cooperation is appreciated.
1 = /dev/staliomem1 Second Stallion card I/O memory
2 = /dev/staliomem2 Third Stallion card I/O memory
3 = /dev/staliomem3 Fourth Stallion card I/O memory
28 char Atari SLM ACSI laser printer (68k/Atari)
0 = /dev/slm0 First SLM laser printer
1 = /dev/slm1 Second SLM laser printer
@@ -690,6 +698,7 @@ Your cooperation is appreciated.
1 = /dev/sbpcd13 Panasonic CD-ROM controller 3 unit 1
2 = /dev/sbpcd14 Panasonic CD-ROM controller 3 unit 2
3 = /dev/sbpcd15 Panasonic CD-ROM controller 3 unit 3
28 block ACSI disk (68k/Atari)
0 = /dev/ada First ACSI disk whole disk
16 = /dev/adb Second ACSI disk whole disk
@@ -750,6 +759,7 @@ Your cooperation is appreciated.
31 char MPU-401 MIDI
0 = /dev/mpu401data MPU-401 data port
1 = /dev/mpu401stat MPU-401 status port
31 block ROM/flash memory card
0 = /dev/rom0 First ROM card (rw)
...
@@ -818,6 +828,7 @@ Your cooperation is appreciated.
129 = /dev/smpte1 Second MIDI port, SMPTE timed
130 = /dev/smpte2 Third MIDI port, SMPTE timed
131 = /dev/smpte3 Fourth MIDI port, SMPTE timed
35 block Slow memory ramdisk
0 = /dev/slram Slow memory ramdisk
@@ -828,6 +839,7 @@ Your cooperation is appreciated.
16 = /dev/tap0 First Ethertap device
...
31 = /dev/tap15 16th Ethertap device
36 block MCA ESDI hard disk
0 = /dev/eda First ESDI disk whole disk
64 = /dev/edb Second ESDI disk whole disk
@@ -882,6 +894,7 @@ Your cooperation is appreciated.
40 char Matrox Meteor frame grabber {2.6}
0 = /dev/mmetfgrab Matrox Meteor frame grabber
40 block Syquest EZ135 parallel port removable drive
0 = /dev/eza Parallel EZ135 drive, whole disk
@@ -893,6 +906,7 @@ Your cooperation is appreciated.
41 char Yet Another Micro Monitor
0 = /dev/yamm Yet Another Micro Monitor
41 block MicroSolutions BackPack parallel port CD-ROM
0 = /dev/bpcd BackPack CD-ROM
@@ -901,6 +915,7 @@ Your cooperation is appreciated.
the parallel port ATAPI CD-ROM driver at major number 46.
42 char Demo/sample use
42 block Demo/sample use
This number is intended for use in sample code, as
@@ -918,6 +933,7 @@ Your cooperation is appreciated.
0 = /dev/ttyI0 First virtual modem
...
63 = /dev/ttyI63 64th virtual modem
43 block Network block devices
0 = /dev/nb0 First network block device
1 = /dev/nb1 Second network block device
@@ -934,6 +950,7 @@ Your cooperation is appreciated.
0 = /dev/cui0 Callout device for ttyI0
...
63 = /dev/cui63 Callout device for ttyI63
44 block Flash Translation Layer (FTL) filesystems
0 = /dev/ftla FTL on first Memory Technology Device
16 = /dev/ftlb FTL on second Memory Technology Device
@@ -958,6 +975,7 @@ Your cooperation is appreciated.
191 = /dev/ippp63 64th SyncPPP device
255 = /dev/isdninfo ISDN monitor interface
45 block Parallel port IDE disk devices
0 = /dev/pda First parallel port IDE disk
16 = /dev/pdb Second parallel port IDE disk
@@ -1044,6 +1062,7 @@ Your cooperation is appreciated.
1 = /dev/dcbri1 Second DataComm card
2 = /dev/dcbri2 Third DataComm card
3 = /dev/dcbri3 Fourth DataComm card
52 block Mylex DAC960 PCI RAID controller; fifth controller
0 = /dev/rd/c4d0 First disk, whole disk
8 = /dev/rd/c4d1 Second disk, whole disk
@@ -1093,7 +1112,8 @@ Your cooperation is appreciated.
55 char DSP56001 digital signal processor
0 = /dev/dsp56k First DSP56001
55 block Mylex DAC960 PCI RAID controller; eigth controller
55 block Mylex DAC960 PCI RAID controller; eighth controller
0 = /dev/rd/c7d0 First disk, whole disk
8 = /dev/rd/c7d1 Second disk, whole disk
...
@@ -1130,6 +1150,7 @@ Your cooperation is appreciated.
0 = /dev/cup0 Callout device for ttyP0
1 = /dev/cup1 Callout device for ttyP1
...
58 block Reserved for logical volume manager
59 char sf firewall package
@@ -1149,6 +1170,7 @@ Your cooperation is appreciated.
NAMING CONFLICT -- PROPOSED REVISED NAME /dev/rpda0 etc
60-63 char LOCAL/EXPERIMENTAL USE
60-63 block LOCAL/EXPERIMENTAL USE
Allocated for local/experimental use. For devices not
assigned official numbers, these ranges should be
@@ -1434,7 +1456,6 @@ Your cooperation is appreciated.
DAC960 (see major number 48) except that the limit on
partitions is 15.
78 char PAM Software's multimodem boards
0 = /dev/ttyM0 First PAM modem
1 = /dev/ttyM1 Second PAM modem
@@ -1450,13 +1471,12 @@ Your cooperation is appreciated.
DAC960 (see major number 48) except that the limit on
partitions is 15.
79 char PAM Software's multimodem boards - alternate devices
0 = /dev/cum0 Callout device for ttyM0
1 = /dev/cum1 Callout device for ttyM1
...
79 block Compaq Intelligent Drive Array, eigth controller
79 block Compaq Intelligent Drive Array, eighth controller
0 = /dev/ida/c7d0 First logical drive whole disk
16 = /dev/ida/c7d1 Second logical drive whole disk
...
@@ -1466,7 +1486,6 @@ Your cooperation is appreciated.
DAC960 (see major number 48) except that the limit on
partitions is 15.
80 char Photometrics AT200 CCD camera
0 = /dev/at200 Photometrics AT200 CCD camera
@@ -1900,7 +1919,7 @@ Your cooperation is appreciated.
1 = /dev/av1 Second A/V card
...
111 block Compaq Next Generation Drive Array, eigth controller
111 block Compaq Next Generation Drive Array, eighth controller
0 = /dev/cciss/c7d0 First logical drive, whole disk
16 = /dev/cciss/c7d1 Second logical drive, whole disk
...
@@ -1937,7 +1956,6 @@ Your cooperation is appreciated.
...
113 block IBM iSeries virtual CD-ROM
0 = /dev/iseries/vcda First virtual CD-ROM
1 = /dev/iseries/vcdb Second virtual CD-ROM
...
@@ -2059,11 +2077,12 @@ Your cooperation is appreciated.
...
119 char VMware virtual network control
0 = /dev/vnet0 1st virtual network
1 = /dev/vnet1 2nd virtual network
0 = /dev/vmnet0 1st virtual network
1 = /dev/vmnet1 2nd virtual network
...
120-127 char LOCAL/EXPERIMENTAL USE
120-127 block LOCAL/EXPERIMENTAL USE
Allocated for local/experimental use. For devices not
assigned official numbers, these ranges should be
@@ -2075,7 +2094,6 @@ Your cooperation is appreciated.
nodes; instead they should be accessed through the
/dev/ptmx cloning interface.
128 block SCSI disk devices (128-143)
0 = /dev/sddy 129th SCSI disk whole disk
16 = /dev/sddz 130th SCSI disk whole disk
@@ -2087,7 +2105,6 @@ Your cooperation is appreciated.
disks (see major number 3) except that the limit on
partitions is 15.
129 block SCSI disk devices (144-159)
0 = /dev/sdeo 145th SCSI disk whole disk
16 = /dev/sdep 146th SCSI disk whole disk
@@ -2123,7 +2140,6 @@ Your cooperation is appreciated.
disks (see major number 3) except that the limit on
partitions is 15.
132 block SCSI disk devices (192-207)
0 = /dev/sdgk 193rd SCSI disk whole disk
16 = /dev/sdgl 194th SCSI disk whole disk
@@ -2135,7 +2151,6 @@ Your cooperation is appreciated.
disks (see major number 3) except that the limit on
partitions is 15.
133 block SCSI disk devices (208-223)
0 = /dev/sdha 209th SCSI disk whole disk
16 = /dev/sdhb 210th SCSI disk whole disk
@@ -2147,7 +2162,6 @@ Your cooperation is appreciated.
disks (see major number 3) except that the limit on
partitions is 15.
134 block SCSI disk devices (224-239)
0 = /dev/sdhq 225th SCSI disk whole disk
16 = /dev/sdhr 226th SCSI disk whole disk
@@ -2159,7 +2173,6 @@ Your cooperation is appreciated.
disks (see major number 3) except that the limit on
partitions is 15.
135 block SCSI disk devices (240-255)
0 = /dev/sdig 241st SCSI disk whole disk
16 = /dev/sdih 242nd SCSI disk whole disk
@@ -2171,7 +2184,6 @@ Your cooperation is appreciated.
disks (see major number 3) except that the limit on
partitions is 15.
136-143 char Unix98 PTY slaves
0 = /dev/pts/0 First Unix98 pseudo-TTY
1 = /dev/pts/1 Second Unix98 pesudo-TTY
@@ -2384,6 +2396,7 @@ Your cooperation is appreciated.
...
159 char RESERVED
159 block RESERVED
160 char General Purpose Instrument Bus (GPIB)
@@ -2483,7 +2496,6 @@ Your cooperation is appreciated.
171 char Reserved for IEEE 1394 (Firewire)
172 char Moxa Intellio serial card
0 = /dev/ttyMX0 First Moxa port
1 = /dev/ttyMX1 Second Moxa port
@@ -2543,9 +2555,6 @@ Your cooperation is appreciated.
64 = /dev/usb/rio500 Diamond Rio 500
65 = /dev/usb/usblcd USBLCD Interface (info@usblcd.de)
66 = /dev/usb/cpad0 Synaptics cPad (mouse/LCD)
67 = /dev/usb/adutux0 1st Ontrak ADU device
...
76 = /dev/usb/adutux10 10th Ontrak ADU device
96 = /dev/usb/hiddev0 1st USB HID device
...
111 = /dev/usb/hiddev15 16th USB HID device
@@ -2558,7 +2567,7 @@ Your cooperation is appreciated.
132 = /dev/usb/idmouse ID Mouse (fingerprint scanner) device
133 = /dev/usb/sisusbvga1 First SiSUSB VGA device
...
140 = /dev/usb/sisusbvga8 Eigth SISUSB VGA device
140 = /dev/usb/sisusbvga8 Eighth SISUSB VGA device
144 = /dev/usb/lcd USB LCD device
160 = /dev/usb/legousbtower0 1st USB Legotower device
...
@@ -2795,6 +2804,10 @@ Your cooperation is appreciated.
...
185 = /dev/ttyNX15 Hilscher netX serial port 15
186 = /dev/ttyJ0 JTAG1 DCC protocol based serial port emulation
187 = /dev/ttyUL0 Xilinx uartlite - port 0
...
190 = /dev/ttyUL3 Xilinx uartlite - port 3
191 = /dev/xvc0 Xen virtual console - port 0
205 char Low-density serial ports (alternate device)
0 = /dev/culu0 Callout device for ttyLU0
@@ -2832,7 +2845,6 @@ Your cooperation is appreciated.
82 = /dev/cuvr0 Callout device for ttyVR0
83 = /dev/cuvr1 Callout device for ttyVR1
206 char OnStream SC-x0 tape devices
0 = /dev/osst0 First OnStream SCSI tape, mode 0
1 = /dev/osst1 Second OnStream SCSI tape, mode 0
@@ -2922,7 +2934,6 @@ Your cooperation is appreciated.
...
212 char LinuxTV.org DVB driver subsystem
0 = /dev/dvb/adapter0/video0 first video decoder of first card
1 = /dev/dvb/adapter0/audio0 first audio decoder of first card
2 = /dev/dvb/adapter0/sec0 (obsolete/unused)
@@ -3008,9 +3019,9 @@ Your cooperation is appreciated.
2 = /dev/3270/tub2 Second 3270 terminal
...
229 char IBM iSeries virtual console
0 = /dev/iseries/vtty0 First console port
1 = /dev/iseries/vtty1 Second console port
229 char IBM iSeries/pSeries virtual console
0 = /dev/hvc0 First console port
1 = /dev/hvc1 Second console port
...
230 char IBM iSeries virtual tape
@@ -3083,12 +3094,14 @@ Your cooperation is appreciated.
234-239 UNASSIGNED
240-254 char LOCAL/EXPERIMENTAL USE
240-254 block LOCAL/EXPERIMENTAL USE
Allocated for local/experimental use. For devices not
assigned official numbers, these ranges should be
used in order to avoid conflicting with future assignments.
255 char RESERVED
255 block RESERVED
This major is reserved to assist the expansion to a
@@ -3115,7 +3128,20 @@ Your cooperation is appreciated.
257 char Phoenix Technologies Cryptographic Services Driver
0 = /dev/ptlsec Crypto Services Driver
257 block SSFDC Flash Translation Layer filesystem
0 = /dev/ssfdca First SSFDC layer
8 = /dev/ssfdcb Second SSFDC layer
16 = /dev/ssfdcc Third SSFDC layer
24 = /dev/ssfdcd 4th SSFDC layer
32 = /dev/ssfdce 5th SSFDC layer
40 = /dev/ssfdcf 6th SSFDC layer
48 = /dev/ssfdcg 7th SSFDC layer
56 = /dev/ssfdch 8th SSFDC layer
258 block ROM/Flash read-only translation layer
0 = /dev/blockrom0 First ROM card's translation layer interface
1 = /dev/blockrom1 Second ROM card's translation layer interface
...
**** ADDITIONAL /dev DIRECTORY ENTRIES
Documentation/driver-model/platform.txt
+108 -76
View File
@@ -1,99 +1,131 @@
Platform Devices and Drivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See <linux/platform_device.h> for the driver model interface to the
platform bus: platform_device, and platform_driver. This pseudo-bus
is used to connect devices on busses with minimal infrastructure,
like those used to integrate peripherals on many system-on-chip
processors, or some "legacy" PC interconnects; as opposed to large
formally specified ones like PCI or USB.
Platform devices
~~~~~~~~~~~~~~~~
Platform devices are devices that typically appear as autonomous
entities in the system. This includes legacy port-based devices and
host bridges to peripheral buses.
host bridges to peripheral buses, and most controllers integrated
into system-on-chip platforms. What they usually have in common
is direct addressing from a CPU bus. Rarely, a platform_device will
be connected through a segment of some other kind of bus; but its
registers will still be directly addressible.
Platform devices are given a name, used in driver binding, and a
list of resources such as addresses and IRQs.
struct platform_device {
const char *name;
u32 id;
struct device dev;
u32 num_resources;
struct resource *resource;
};
Platform drivers
~~~~~~~~~~~~~~~~
Drivers for platform devices are typically very simple and
unstructured. Either the device was present at a particular I/O port
and the driver was loaded, or it was not. There was no possibility
of hotplugging or alternative discovery besides probing at a specific
I/O address and expecting a specific response.
Platform drivers follow the standard driver model convention, where
discovery/enumeration is handled outside the drivers, and drivers
provide probe() and remove() methods. They support power management
and shutdown notifications using the standard conventions.
struct platform_driver {
int (*probe)(struct platform_device *);
int (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
int (*suspend_late)(struct platform_device *, pm_message_t state);
int (*resume_early)(struct platform_device *);
int (*resume)(struct platform_device *);
struct device_driver driver;
};
Note that probe() should general verify that the specified device hardware
actually exists; sometimes platform setup code can't be sure. The probing
can use device resources, including clocks, and device platform_data.
Platform drivers register themselves the normal way:
int platform_driver_register(struct platform_driver *drv);
Or, in common situations where the device is known not to be hot-pluggable,
the probe() routine can live in an init section to reduce the driver's
runtime memory footprint:
int platform_driver_probe(struct platform_driver *drv,
int (*probe)(struct platform_device *))
Other Architectures, Modern Firmware, and new Platforms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These devices are not always at the legacy I/O ports. This is true on
other architectures and on some modern architectures. In most cases,
the drivers are modified to discover the devices at other well-known
ports for the given platform. However, the firmware in these systems
does usually know where exactly these devices reside, and in some
cases, it's the only way of discovering them.
Device Enumeration
~~~~~~~~~~~~~~~~~~
As a rule, platform specific (and often board-specific) setup code wil
register platform devices:
int platform_device_register(struct platform_device *pdev);
int platform_add_devices(struct platform_device **pdevs, int ndev);
The general rule is to register only those devices that actually exist,
but in some cases extra devices might be registered. For example, a kernel
might be configured to work with an external network adapter that might not
be populated on all boards, or likewise to work with an integrated controller
that some boards might not hook up to any peripherals.
In some cases, boot firmware will export tables describing the devices
that are populated on a given board. Without such tables, often the
only way for system setup code to set up the correct devices is to build
a kernel for a specific target board. Such board-specific kernels are
common with embedded and custom systems development.
In many cases, the memory and IRQ resources associated with the platform
device are not enough to let the device's driver work. Board setup code
will often provide additional information using the device's platform_data
field to hold additional information.
Embedded systems frequently need one or more clocks for platform devices,
which are normally kept off until they're actively needed (to save power).
System setup also associates those clocks with the device, so that that
calls to clk_get(&pdev->dev, clock_name) return them as needed.
The Platform Bus
~~~~~~~~~~~~~~~~
A platform bus has been created to deal with these issues. First and
foremost, it groups all the legacy devices under a common bus, and
gives them a common parent if they don't already have one.
Device Naming and Driver Binding
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The platform_device.dev.bus_id is the canonical name for the devices.
It's built from two components:
But, besides the organizational benefits, the platform bus can also
accommodate firmware-based enumeration.
* platform_device.name ... which is also used to for driver matching.
* platform_device.id ... the device instance number, or else "-1"
to indicate there's only one.
Device Discovery
~~~~~~~~~~~~~~~~
The platform bus has no concept of probing for devices. Devices
discovery is left up to either the legacy drivers or the
firmware. These entities are expected to notify the platform of
devices that it discovers via the bus's add() callback:
These are catenated, so name/id "serial"/0 indicates bus_id "serial.0", and
"serial/3" indicates bus_id "serial.3"; both would use the platform_driver
named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
and use the platform_driver called "my_rtc".
platform_bus.add(parent,bus_id).
Driver binding is performed automatically by the driver core, invoking
driver probe() after finding a match between device and driver. If the
probe() succeeds, the driver and device are bound as usual. There are
three different ways to find such a match:
- Whenever a device is registered, the drivers for that bus are
checked for matches. Platform devices should be registered very
early during system boot.
Bus IDs
~~~~~~~
Bus IDs are the canonical names for the devices. There is no globally
standard addressing mechanism for legacy devices. In the IA-32 world,
we have Pnp IDs to use, as well as the legacy I/O ports. However,
neither tell what the device really is or have any meaning on other
platforms.
- When a driver is registered using platform_driver_register(), all
unbound devices on that bus are checked for matches. Drivers
usually register later during booting, or by module loading.
Since both PnP IDs and the legacy I/O ports (and other standard I/O
ports for specific devices) have a 1:1 mapping, we map the
platform-specific name or identifier to a generic name (at least
within the scope of the kernel).
For example, a serial driver might find a device at I/O 0x3f8. The
ACPI firmware might also discover a device with PnP ID (_HID)
PNP0501. Both correspond to the same device and should be mapped to the
canonical name 'serial'.
The bus_id field should be a concatenation of the canonical name and
the instance of that type of device. For example, the device at I/O
port 0x3f8 should have a bus_id of "serial0". This places the
responsibility of enumerating devices of a particular type up to the
discovery mechanism. But, they are the entity that should know best
(as opposed to the platform bus driver).
Drivers
~~~~~~~
Drivers for platform devices should have a name that is the same as
the canonical name of the devices they support. This allows the
platform bus driver to do simple matching with the basic data
structures to determine if a driver supports a certain device.
For example, a legacy serial driver should have a name of 'serial' and
register itself with the platform bus.
Driver Binding
~~~~~~~~~~~~~~
Legacy drivers assume they are bound to the device once they start up
and probe an I/O port. Divorcing them from this will be a difficult
process. However, that shouldn't prevent us from implementing
firmware-based enumeration.
The firmware should notify the platform bus about devices before the
legacy drivers have had a chance to load. Once the drivers are loaded,
they driver model core will attempt to bind the driver to any
previously-discovered devices. Once that has happened, it will be free
to discover any other devices it pleases.
- Registering a driver using platform_driver_probe() works just like
using platform_driver_register(), except that the the driver won't
be probed later if another device registers. (Which is OK, since
this interface is only for use with non-hotpluggable devices.)
Documentation/driver-model/porting.txt
+1 -1
View File
@@ -92,7 +92,7 @@ struct device represents a single device. It mainly contains metadata
describing the relationship the device has to other entities.
- Embedd a struct device in the bus-specific device type.
- Embed a struct device in the bus-specific device type.
struct pci_dev {
Documentation/dvb/ci.txt
+2 -2
View File
@@ -71,7 +71,7 @@ eliminating the need for any additional ioctls.
The disadvantage is that the driver/hardware has to manage the rest. For
the application programmer it would be as simple as sending/receiving an
array to/from the CI ioctls as defined in the Linux DVB API. No changes
have been made in the API to accomodate this feature.
have been made in the API to accommodate this feature.
* Why the need for another CI interface ?
@@ -102,7 +102,7 @@ This CI interface follows the CI high level interface, which is not
implemented by most applications. Hence this area is revisited.
This CI interface is quite different in the case that it tries to
accomodate all other CI based devices, that fall into the other categories
accommodate all other CI based devices, that fall into the other categories.
This means that this CI interface handles the EN50221 style tags in the
Application layer only and no session management is taken care of by the

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