mirror of
https://github.com/torvalds/linux.git
synced 2024-11-23 20:51:44 +00:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: Fix typos in drivers/isdn/hisax/isdnl2.c Fix typos in doc and comments BUG_ON conversion for fs/aio.c BUG_ON conversion for drivers/mmc/omap.c BUG_ON conversion for drivers/media/video/pwc/pwc-if.c Fix misc .c/.h comment typos Fix misc Kconfig typos Fix typos in /Documentation : Misc Fix typos in /Documentation : 'U-Z' Fix typos in /Documentation : 'T'' Fix jiffies.h comment tabify MAINTAINERS fix spelling error in include/linux/kernel.h mqueue.h: don't include linux/types.h
This commit is contained in:
commit
1399ff5474
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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:
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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:
|
||||
|
@ -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.
|
||||
|
||||
|
@ -92,7 +92,7 @@ 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
|
||||
@ -1093,7 +1093,7 @@ 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
|
||||
...
|
||||
@ -1456,7 +1456,7 @@ Your cooperation is appreciated.
|
||||
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
|
||||
...
|
||||
@ -1900,7 +1900,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
|
||||
...
|
||||
|
@ -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 {
|
||||
|
@ -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
|
||||
|
@ -62,7 +62,7 @@ res : root device I/O resource
|
||||
bus_base_addr : slot 0 address on this bus
|
||||
slots : max slot number to probe
|
||||
force_probe : Probe even when slot 0 is empty (no EISA mainboard)
|
||||
dma_mask : Default DMA mask. Usualy the bridge device dma_mask.
|
||||
dma_mask : Default DMA mask. Usually the bridge device dma_mask.
|
||||
bus_nr : unique bus id, set by eisa_root_register
|
||||
|
||||
** Driver :
|
||||
|
@ -3,7 +3,7 @@ Mount options for ADFS
|
||||
|
||||
uid=nnn All files in the partition will be owned by
|
||||
user id nnn. Default 0 (root).
|
||||
gid=nnn All files in the partition willbe in group
|
||||
gid=nnn All files in the partition will be in group
|
||||
nnn. Default 0 (root).
|
||||
ownmask=nnn The permission mask for ADFS 'owner' permissions
|
||||
will be nnn. Default 0700.
|
||||
|
@ -209,7 +209,7 @@ will happen for write(2).
|
||||
|
||||
[struct config_group]
|
||||
|
||||
A config_item cannot live in a vaccum. The only way one can be created
|
||||
A config_item cannot live in a vacuum. The only way one can be created
|
||||
is via mkdir(2) on a config_group. This will trigger creation of a
|
||||
child item.
|
||||
|
||||
@ -275,7 +275,7 @@ directory is not empty.
|
||||
|
||||
[struct configfs_subsystem]
|
||||
|
||||
A subsystem must register itself, ususally at module_init time. This
|
||||
A subsystem must register itself, usually at module_init time. This
|
||||
tells configfs to make the subsystem appear in the file tree.
|
||||
|
||||
struct configfs_subsystem {
|
||||
|
@ -111,7 +111,7 @@ For each connection the following files exist within this directory:
|
||||
|
||||
'waiting'
|
||||
|
||||
The number of requests which are waiting to be transfered to
|
||||
The number of requests which are waiting to be transferred to
|
||||
userspace or being processed by the filesystem daemon. If there is
|
||||
no filesystem activity and 'waiting' is non-zero, then the
|
||||
filesystem is hung or deadlocked.
|
||||
@ -136,7 +136,7 @@ following will happen:
|
||||
|
||||
2) If the request is not yet sent to userspace AND the signal is not
|
||||
fatal, then an 'interrupted' flag is set for the request. When
|
||||
the request has been successfully transfered to userspace and
|
||||
the request has been successfully transferred to userspace and
|
||||
this flag is set, an INTERRUPT request is queued.
|
||||
|
||||
3) If the request is already sent to userspace, then an INTERRUPT
|
||||
|
@ -274,7 +274,7 @@ History
|
||||
Fixed race-condition in buffer code - it is in all filesystems in Linux;
|
||||
when reading device (cat /dev/hda) while creating files on it, files
|
||||
could be damaged
|
||||
2.02 Woraround for bug in breada in Linux. breada could cause accesses beyond
|
||||
2.02 Workaround for bug in breada in Linux. breada could cause accesses beyond
|
||||
end of partition
|
||||
2.03 Char, block devices and pipes are correctly created
|
||||
Fixed non-crashing race in unlink (Alexander Viro)
|
||||
|
@ -337,7 +337,7 @@ Finally, for a mirrored volume, i.e. raid level 1, the table would look like
|
||||
this (note all values are in 512-byte sectors):
|
||||
|
||||
--- cut here ---
|
||||
# Ofs Size Raid Log Number Region Should Number Source Start Taget Start
|
||||
# Ofs Size Raid Log Number Region Should Number Source Start Target Start
|
||||
# in of the type type of log size sync? of Device in Device in
|
||||
# vol volume params mirrors Device Device
|
||||
0 2056320 mirror core 2 16 nosync 2 /dev/hda1 0 /dev/hdb1 0
|
||||
@ -599,7 +599,7 @@ Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
|
||||
- Major bug fixes for reading files and volumes in corner cases which
|
||||
were being hit by Windows 2k/XP users.
|
||||
2.1.2:
|
||||
- Major bug fixes aleviating the hangs in statfs experienced by some
|
||||
- Major bug fixes alleviating the hangs in statfs experienced by some
|
||||
users.
|
||||
2.1.1:
|
||||
- Update handling of compressed files so people no longer get the
|
||||
|
@ -30,7 +30,7 @@ Caveats
|
||||
Features which OCFS2 does not support yet:
|
||||
- sparse files
|
||||
- extended attributes
|
||||
- shared writeable mmap
|
||||
- shared writable mmap
|
||||
- loopback is supported, but data written will not
|
||||
be cluster coherent.
|
||||
- quotas
|
||||
|
@ -1220,9 +1220,9 @@ applications are using mlock(), or if you are running with no swap then
|
||||
you probably should increase the lower_zone_protection setting.
|
||||
|
||||
The units of this tunable are fairly vague. It is approximately equal
|
||||
to "megabytes". So setting lower_zone_protection=100 will protect around 100
|
||||
to "megabytes," so setting lower_zone_protection=100 will protect around 100
|
||||
megabytes of the lowmem zone from user allocations. It will also make
|
||||
those 100 megabytes unavaliable for use by applications and by
|
||||
those 100 megabytes unavailable for use by applications and by
|
||||
pagecache, so there is a cost.
|
||||
|
||||
The effects of this tunable may be observed by monitoring
|
||||
@ -1538,10 +1538,10 @@ TCP settings
|
||||
tcp_ecn
|
||||
-------
|
||||
|
||||
This file controls the use of the ECN bit in the IPv4 headers, this is a new
|
||||
This file controls the use of the ECN bit in the IPv4 headers. This is a new
|
||||
feature about Explicit Congestion Notification, but some routers and firewalls
|
||||
block trafic that has this bit set, so it could be necessary to echo 0 to
|
||||
/proc/sys/net/ipv4/tcp_ecn, if you want to talk to this sites. For more info
|
||||
block traffic that has this bit set, so it could be necessary to echo 0 to
|
||||
/proc/sys/net/ipv4/tcp_ecn if you want to talk to these sites. For more info
|
||||
you could read RFC2481.
|
||||
|
||||
tcp_retrans_collapse
|
||||
|
@ -210,7 +210,7 @@ FILES
|
||||
/signal2
|
||||
The two signal notification channels of an SPU. These are read-write
|
||||
files that operate on a 32 bit word. Writing to one of these files
|
||||
triggers an interrupt on the SPU. The value writting to the signal
|
||||
triggers an interrupt on the SPU. The value written to the signal
|
||||
files can be read from the SPU through a channel read or from host user
|
||||
space through the file. After the value has been read by the SPU, it
|
||||
is reset to zero. The possible operations on an open signal1 or sig-
|
||||
|
@ -59,7 +59,7 @@ the following things on the "Kernel Hacking" tab:
|
||||
Then build as usual, download to the board and execute. Note that if
|
||||
"Immediate activation" was selected, then the kernel will wait for GDB to
|
||||
attach. If not, then the kernel will boot immediately and GDB will have to
|
||||
interupt it or wait for an exception to occur if before doing anything with
|
||||
interrupt it or wait for an exception to occur before doing anything with
|
||||
the kernel.
|
||||
|
||||
|
||||
|
@ -156,7 +156,7 @@ with the main kernel in this regard. Hence the debug mode code (gdbstub) is
|
||||
almost completely self-contained. The only external code used is the
|
||||
sprintf family of functions.
|
||||
|
||||
Futhermore, break.S is so complicated because single-step mode does not
|
||||
Furthermore, break.S is so complicated because single-step mode does not
|
||||
switch off on entry to an exception. That means unless manually disabled,
|
||||
single-stepping will blithely go on stepping into things like interrupts.
|
||||
See gdbstub.txt for more information.
|
||||
|
@ -390,5 +390,5 @@ mlord@pobox.com
|
||||
Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current
|
||||
maintainer.
|
||||
|
||||
Wed Aug 20 22:31:29 CEST 2003 updated ide boot uptions to current ide.c
|
||||
Wed Aug 20 22:31:29 CEST 2003 updated ide boot options to current ide.c
|
||||
comments at 2.6.0-test4 time. Maciej Soltysiak <solt@dns.toxicfilms.tv>
|
||||
|
@ -91,8 +91,8 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
|
||||
| 1 | M0HQ | JOY0DAT Horizontal Clock (quadrature) |
|
||||
| 2 | M0V | JOY0DAT Vertical Clock |
|
||||
| 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) |
|
||||
| 4 | M1V | JOY1DAT Horizontall Clock |
|
||||
| 5 | M1VQ | JOY1DAT Horizontall Clock (quadrature) |
|
||||
| 4 | M1V | JOY1DAT Horizontal Clock |
|
||||
| 5 | M1VQ | JOY1DAT Horizontal Clock (quadrature) |
|
||||
| 6 | M1V | JOY1DAT Vertical Clock |
|
||||
| 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) |
|
||||
+--------+----------+-----------------------------------------+
|
||||
|
@ -103,7 +103,7 @@ LEFT=0x74 & RIGHT=0x75).
|
||||
|
||||
5.1 Joystick Event Reporting
|
||||
|
||||
In this mode, the ikbd generates a record whever the joystick position is
|
||||
In this mode, the ikbd generates a record whenever the joystick position is
|
||||
changed (i.e. for each opening or closing of a joystick switch or trigger).
|
||||
|
||||
The joystick event record is two bytes of the form:
|
||||
@ -277,8 +277,8 @@ default to 1 at RESET (or power-up).
|
||||
9.7 SET MOUSE SCALE
|
||||
|
||||
0x0C
|
||||
X ; horizontal mouse ticks per internel X
|
||||
Y ; vertical mouse ticks per internel Y
|
||||
X ; horizontal mouse ticks per internal X
|
||||
Y ; vertical mouse ticks per internal Y
|
||||
|
||||
This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
|
||||
In this mode, the specified number of mouse phase changes ('clicks') must
|
||||
@ -323,7 +323,7 @@ mouse position.
|
||||
0x0F
|
||||
|
||||
This command makes the origin of the Y axis to be at the bottom of the
|
||||
logical coordinate system internel to the ikbd for all relative or absolute
|
||||
logical coordinate system internal to the ikbd for all relative or absolute
|
||||
mouse motion. This causes mouse motion toward the user to be negative in sign
|
||||
and away from the user to be positive.
|
||||
|
||||
@ -597,8 +597,8 @@ mode or FIRE BUTTON MONITORING mode.
|
||||
|
||||
10. SCAN CODES
|
||||
|
||||
The key scan codes return by the ikbd are chosen to simplify the
|
||||
implementaion of GSX.
|
||||
The key scan codes returned by the ikbd are chosen to simplify the
|
||||
implementation of GSX.
|
||||
|
||||
GSX Standard Keyboard Mapping.
|
||||
|
||||
|
@ -134,7 +134,7 @@ Reading /sys/../lineX will return the format string with its current value:
|
||||
888888888888
|
||||
Linux Rocks!
|
||||
|
||||
Writing to /sys/../lineX will set the coresponding LCD line.
|
||||
Writing to /sys/../lineX will set the corresponding LCD line.
|
||||
- Excess characters are ignored.
|
||||
- If less characters are written than allowed, the remaining digits are
|
||||
unchanged.
|
||||
|
@ -735,7 +735,7 @@ CDROM_DISC_STATUS Get disc type, etc.
|
||||
Ok, this is where problems start. The current interface for
|
||||
the CDROM_DISC_STATUS ioctl is flawed. It makes the false
|
||||
assumption that CDs are all CDS_DATA_1 or all CDS_AUDIO, etc.
|
||||
Unfortunatly, while this is often the case, it is also
|
||||
Unfortunately, while this is often the case, it is also
|
||||
very common for CDs to have some tracks with data, and some
|
||||
tracks with audio. Just because I feel like it, I declare
|
||||
the following to be the best way to cope. If the CD has
|
||||
|
@ -227,9 +227,9 @@ more details, with real examples.
|
||||
be included in a library, lib.a.
|
||||
All objects listed with lib-y are combined in a single
|
||||
library for that directory.
|
||||
Objects that are listed in obj-y and additionaly listed in
|
||||
lib-y will not be included in the library, since they will anyway
|
||||
be accessible.
|
||||
Objects that are listed in obj-y and additionally listed in
|
||||
lib-y will not be included in the library, since they will
|
||||
be accessible anyway.
|
||||
For consistency, objects listed in lib-m will be included in lib.a.
|
||||
|
||||
Note that the same kbuild makefile may list files to be built-in
|
||||
@ -535,7 +535,7 @@ Both possibilities are described in the following.
|
||||
Host programs can be made up based on composite objects.
|
||||
The syntax used to define composite objects for host programs is
|
||||
similar to the syntax used for kernel objects.
|
||||
$(<executeable>-objs) lists all objects used to link the final
|
||||
$(<executable>-objs) lists all objects used to link the final
|
||||
executable.
|
||||
|
||||
Example:
|
||||
@ -1022,7 +1022,7 @@ When kbuild executes, the following steps are followed (roughly):
|
||||
In this example, there are two possible targets, requiring different
|
||||
options to the linker. The linker options are specified using the
|
||||
LDFLAGS_$@ syntax - one for each potential target.
|
||||
$(targets) are assinged all potential targets, by which kbuild knows
|
||||
$(targets) are assigned all potential targets, by which kbuild knows
|
||||
the targets and will:
|
||||
1) check for commandline changes
|
||||
2) delete target during make clean
|
||||
|
@ -304,7 +304,7 @@ about the status of the key service:
|
||||
R Revoked
|
||||
D Dead
|
||||
Q Contributes to user's quota
|
||||
U Under contruction by callback to userspace
|
||||
U Under construction by callback to userspace
|
||||
N Negative key
|
||||
|
||||
This file must be enabled at kernel configuration time as it allows anyone
|
||||
|
@ -121,7 +121,7 @@ contains the following options:
|
||||
MAX_AGE:
|
||||
|
||||
Maximum time, in seconds, of hard drive spindown time that you are
|
||||
confortable with. Worst case, it's possible that you could lose this
|
||||
comfortable with. Worst case, it's possible that you could lose this
|
||||
amount of work if your battery fails while you're in laptop mode.
|
||||
|
||||
MINIMUM_BATTERY_MINUTES:
|
||||
@ -235,7 +235,7 @@ It should be installed as /etc/default/laptop-mode on Debian, and as
|
||||
|
||||
--------------------CONFIG FILE BEGIN-------------------------------------------
|
||||
# Maximum time, in seconds, of hard drive spindown time that you are
|
||||
# confortable with. Worst case, it's possible that you could lose this
|
||||
# comfortable with. Worst case, it's possible that you could lose this
|
||||
# amount of work if your battery fails you while in laptop mode.
|
||||
#MAX_AGE=600
|
||||
|
||||
@ -350,7 +350,7 @@ fi
|
||||
# set defaults instead:
|
||||
|
||||
# Maximum time, in seconds, of hard drive spindown time that you are
|
||||
# confortable with. Worst case, it's possible that you could lose this
|
||||
# comfortable with. Worst case, it's possible that you could lose this
|
||||
# amount of work if your battery fails you while in laptop mode.
|
||||
MAX_AGE=${MAX_AGE:-'600'}
|
||||
|
||||
@ -699,7 +699,7 @@ ACPI integration
|
||||
Dax Kelson submitted this so that the ACPI acpid daemon will
|
||||
kick off the laptop_mode script and run hdparm. The part that
|
||||
automatically disables laptop mode when the battery is low was
|
||||
writen by Jan Topinski.
|
||||
written by Jan Topinski.
|
||||
|
||||
-----------------/etc/acpi/events/ac_adapter BEGIN------------------------------
|
||||
event=ac_adapter
|
||||
|
@ -212,7 +212,7 @@ There are some minimal guarantees that may be expected of a CPU:
|
||||
|
||||
STORE *X = c, d = LOAD *X
|
||||
|
||||
(Loads and stores overlap if they are targetted at overlapping pieces of
|
||||
(Loads and stores overlap if they are targeted at overlapping pieces of
|
||||
memory).
|
||||
|
||||
And there are a number of things that _must_ or _must_not_ be assumed:
|
||||
|
@ -95,8 +95,8 @@ There are two types of event register ACK mechanisms.
|
||||
Move all to dev->poll()
|
||||
|
||||
C) Ability to detect new work correctly.
|
||||
NAPI works by shutting down event interrupts when theres work and
|
||||
turning them on when theres none.
|
||||
NAPI works by shutting down event interrupts when there's work and
|
||||
turning them on when there's none.
|
||||
New packets might show up in the small window while interrupts were being
|
||||
re-enabled (refer to appendix 2). A packet might sneak in during the period
|
||||
we are enabling interrupts. We only get to know about such a packet when the
|
||||
@ -114,7 +114,7 @@ Locking rules and environmental guarantees
|
||||
only one CPU can pick the initial interrupt and hence the initial
|
||||
netif_rx_schedule(dev);
|
||||
- The core layer invokes devices to send packets in a round robin format.
|
||||
This implies receive is totaly lockless because of the guarantee only that
|
||||
This implies receive is totally lockless because of the guarantee that only
|
||||
one CPU is executing it.
|
||||
- contention can only be the result of some other CPU accessing the rx
|
||||
ring. This happens only in close() and suspend() (when these methods
|
||||
@ -510,7 +510,7 @@ static int my_poll (struct net_device *dev, int *budget)
|
||||
an interrupt will be generated */
|
||||
goto done;
|
||||
}
|
||||
/* done! at least thats what it looks like ;->
|
||||
/* done! at least that's what it looks like ;->
|
||||
if new packets came in after our last check on status bits
|
||||
they'll be caught by the while check and we go back and clear them
|
||||
since we havent exceeded our quota */
|
||||
@ -535,11 +535,11 @@ done:
|
||||
* 1. it can race with disabling irqs in irq handler (which are done to
|
||||
* schedule polls)
|
||||
* 2. it can race with dis/enabling irqs in other poll threads
|
||||
* 3. if an irq raised after the begining of the outer beginning
|
||||
* loop(marked in the code above), it will be immediately
|
||||
* 3. if an irq raised after the beginning of the outer beginning
|
||||
* loop (marked in the code above), it will be immediately
|
||||
* triggered here.
|
||||
*
|
||||
* Summarizing: the logic may results in some redundant irqs both
|
||||
* Summarizing: the logic may result in some redundant irqs both
|
||||
* due to races in masking and due to too late acking of already
|
||||
* processed irqs. The good news: no events are ever lost.
|
||||
*/
|
||||
@ -601,7 +601,7 @@ a)
|
||||
|
||||
5) dev->close() and dev->suspend() issues
|
||||
==========================================
|
||||
The driver writter neednt worry about this. The top net layer takes
|
||||
The driver writer needn't worry about this; the top net layer takes
|
||||
care of it.
|
||||
|
||||
6) Adding new Stats to /proc
|
||||
@ -622,9 +622,9 @@ FC should be programmed to apply in the case when the system cant pull out
|
||||
packets fast enough i.e send a pause only when you run out of rx buffers.
|
||||
Note FC in itself is a good solution but we have found it to not be
|
||||
much of a commodity feature (both in NICs and switches) and hence falls
|
||||
under the same category as using NIC based mitigation. Also experiments
|
||||
indicate that its much harder to resolve the resource allocation
|
||||
issue (aka lazy receiving that NAPI offers) and hence quantify its usefullness
|
||||
under the same category as using NIC based mitigation. Also, experiments
|
||||
indicate that it's much harder to resolve the resource allocation
|
||||
issue (aka lazy receiving that NAPI offers) and hence quantify its usefulness
|
||||
proved harder. In any case, FC works even better with NAPI but is not
|
||||
necessary.
|
||||
|
||||
@ -678,10 +678,10 @@ routine:
|
||||
CSR5 bit of interest is only the rx status.
|
||||
If you look at the last if statement:
|
||||
you just finished grabbing all the packets from the rx ring .. you check if
|
||||
status bit says theres more packets just in ... it says none; you then
|
||||
status bit says there are more packets just in ... it says none; you then
|
||||
enable rx interrupts again; if a new packet just came in during this check,
|
||||
we are counting that CSR5 will be set in that small window of opportunity
|
||||
and that by re-enabling interrupts, we would actually triger an interrupt
|
||||
and that by re-enabling interrupts, we would actually trigger an interrupt
|
||||
to register the new packet for processing.
|
||||
|
||||
[The above description nay be very verbose, if you have better wording
|
||||
|
@ -248,7 +248,7 @@ c) The driver's hardware probe routine is designed to avoid
|
||||
with device probing. To avoid this behaviour, add one
|
||||
to the `io=' module parameter. This doesn't actually change
|
||||
the I/O address, but it is a flag to tell the driver
|
||||
topartially initialise the hardware before trying to
|
||||
to partially initialise the hardware before trying to
|
||||
identify the card. This could be dangerous if you are
|
||||
not sure that there is a cs89x0 card at the provided address.
|
||||
|
||||
@ -620,8 +620,8 @@ I/O Address Device IRQ Device
|
||||
12 Mouse (PS/2)
|
||||
Memory Address Device 13 Math Coprocessor
|
||||
-------------- --------------------- 14 Hard Disk controller
|
||||
A000-BFFF EGA Graphics Adpater
|
||||
A000-C7FF VGA Graphics Adpater
|
||||
A000-BFFF EGA Graphics Adapter
|
||||
A000-C7FF VGA Graphics Adapter
|
||||
B000-BFFF Mono Graphics Adapter
|
||||
B800-BFFF Color Graphics Adapter
|
||||
E000-FFFF AT BIOS
|
||||
|
@ -81,7 +81,7 @@ Installation
|
||||
1M. The RAM size decides the number of buffers and buffer size. The default
|
||||
size and number of buffers are set as following:
|
||||
|
||||
Totol Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf
|
||||
Total Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf
|
||||
RAM size size size size size cnt cnt
|
||||
-------- ------ ------ ------ ------ ------ ------
|
||||
128K 64K 64K 10K 10K 6 6
|
||||
|
@ -284,7 +284,7 @@ the necessary memory, so normally limits can be reached.
|
||||
-------------------
|
||||
|
||||
If you check the source code you will see that what I draw here as a frame
|
||||
is not only the link level frame. At the begining of each frame there is a
|
||||
is not only the link level frame. At the beginning of each frame there is a
|
||||
header called struct tpacket_hdr used in PACKET_MMAP to hold link level's frame
|
||||
meta information like timestamp. So what we draw here a frame it's really
|
||||
the following (from include/linux/if_packet.h):
|
||||
|
@ -63,8 +63,8 @@ Current:
|
||||
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
|
||||
763292pps 390Mb/sec (390805504bps) errors: 39664
|
||||
|
||||
Confguring threads and devices
|
||||
==============================
|
||||
Configuring threads and devices
|
||||
================================
|
||||
This is done via the /proc interface easiest done via pgset in the scripts
|
||||
|
||||
Examples:
|
||||
@ -116,7 +116,7 @@ Examples:
|
||||
there must be no spaces between the
|
||||
arguments. Leading zeros are required.
|
||||
Do not set the bottom of stack bit,
|
||||
thats done automatically. If you do
|
||||
that's done automatically. If you do
|
||||
set the bottom of stack bit, that
|
||||
indicates that you want to randomly
|
||||
generate that address and the flag
|
||||
|
@ -25,7 +25,7 @@ up into 3 parts because of the length of the line):
|
||||
|
||||
1000 0 54165785 4 cd1e6040 25 4 27 3 -1
|
||||
| | | | | | | | | |--> slow start size threshold,
|
||||
| | | | | | | | | or -1 if the treshold
|
||||
| | | | | | | | | or -1 if the threshold
|
||||
| | | | | | | | | is >= 0xFFFF
|
||||
| | | | | | | | |----> sending congestion window
|
||||
| | | | | | | |-------> (ack.quick<<1)|ack.pingpong
|
||||
|
@ -346,7 +346,7 @@ Possible modes:
|
||||
depending on the load of the system. If the driver detects that the
|
||||
system load is too high, the driver tries to shield the system against
|
||||
too much network load by enabling interrupt moderation. If - at a later
|
||||
time - the CPU utilizaton decreases again (or if the network load is
|
||||
time - the CPU utilization decreases again (or if the network load is
|
||||
negligible) the interrupt moderation will automatically be disabled.
|
||||
|
||||
Interrupt moderation should be used when the driver has to handle one or more
|
||||
|
@ -126,7 +126,7 @@ comx0/boardnum - board number of the SliceCom in the PC (using the 'natural'
|
||||
|
||||
Though the options below are to be set on a single interface, they apply to the
|
||||
whole board. The restriction, to use them on 'UP' interfaces, is because the
|
||||
command sequence below could lead to unpredicable results.
|
||||
command sequence below could lead to unpredictable results.
|
||||
|
||||
# echo 0 >boardnum
|
||||
# echo internal >clock_source
|
||||
|
@ -412,7 +412,7 @@ beta-2.1.4 Jul 2000 o Dynamic interface configuration:
|
||||
|
||||
beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
|
||||
o Added the Multi-Port PPP
|
||||
Updated utilites for the Multi-Port PPP.
|
||||
Updated utilities for the Multi-Port PPP.
|
||||
|
||||
2.1.4 Aut 2000
|
||||
o In X25API:
|
||||
@ -444,13 +444,13 @@ beta1-2.1.5 Nov 15 2000
|
||||
|
||||
o Cpipemon
|
||||
- Added set FT1 commands to the cpipemon. Thus CSU/DSU
|
||||
configuraiton can be performed using cpipemon.
|
||||
configuration can be performed using cpipemon.
|
||||
All systems that cannot run cfgft1 GUI utility should
|
||||
use cpipemon to configure the on board CSU/DSU.
|
||||
|
||||
|
||||
o Keyboard Led Monitor/Debugger
|
||||
- A new utilty /usr/sbin/wpkbdmon uses keyboard leds
|
||||
- A new utility /usr/sbin/wpkbdmon uses keyboard leds
|
||||
to convey operational statistic information of the
|
||||
Sangoma WANPIPE cards.
|
||||
NUM_LOCK = Line State (On=connected, Off=disconnected)
|
||||
@ -464,7 +464,7 @@ beta1-2.1.5 Nov 15 2000
|
||||
- Appropriate number of devices are dynamically loaded
|
||||
based on the number of Sangoma cards found.
|
||||
|
||||
Note: The kernel configuraiton option
|
||||
Note: The kernel configuration option
|
||||
CONFIG_WANPIPE_CARDS has been taken out.
|
||||
|
||||
o Fixed the Frame Relay and Chdlc network interfaces so they are
|
||||
|
@ -184,7 +184,7 @@ static const struct pnp_id pnp_dev_table[] = {
|
||||
Please note that the character 'X' can be used as a wild card in the function
|
||||
portion (last four characters).
|
||||
ex:
|
||||
/* Unkown PnP modems */
|
||||
/* Unknown PnP modems */
|
||||
{ "PNPCXXX", UNKNOWN_DEV },
|
||||
|
||||
Supported PnP card IDs can optionally be defined.
|
||||
|
@ -153,7 +153,7 @@ Description:
|
||||
events, which is implicit if it doesn't even support it in the first
|
||||
place).
|
||||
|
||||
Note that the PMC Register in the device's PM Capabilties has a bitmask
|
||||
Note that the PMC Register in the device's PM Capabilities has a bitmask
|
||||
of the states it supports generating PME# from. D3hot is bit 3 and
|
||||
D3cold is bit 4. So, while a value of 4 as the state may not seem
|
||||
semantically correct, it is.
|
||||
@ -268,7 +268,7 @@ to wake the system up. (However, it is possible that a device may support
|
||||
some non-standard way of generating a wake event on sleep.)
|
||||
|
||||
Bits 15:11 of the PMC (Power Mgmt Capabilities) Register in a device's
|
||||
PM Capabilties describe what power states the device supports generating a
|
||||
PM Capabilities describe what power states the device supports generating a
|
||||
wake event from:
|
||||
|
||||
+------------------+
|
||||
|
@ -62,7 +62,7 @@ setup via another operating system for it to use. Despite the
|
||||
inconvenience, this method requires minimal work by the kernel, since
|
||||
the firmware will also handle restoring memory contents on resume.
|
||||
|
||||
If the kernel is responsible for persistantly saving state, a mechanism
|
||||
If the kernel is responsible for persistently saving state, a mechanism
|
||||
called 'swsusp' (Swap Suspend) is used to write memory contents to
|
||||
free swap space. swsusp has some restrictive requirements, but should
|
||||
work in most cases. Some, albeit outdated, documentation can be found
|
||||
|
@ -153,7 +153,7 @@ add:
|
||||
|
||||
If the thread is needed for writing the image to storage, you should
|
||||
instead set the PF_NOFREEZE process flag when creating the thread (and
|
||||
be very carefull).
|
||||
be very careful).
|
||||
|
||||
|
||||
Q: What is the difference between "platform", "shutdown" and
|
||||
|
@ -33,13 +33,13 @@
|
||||
- Change version 16 format to always align
|
||||
property data to 4 bytes. Since tokens are
|
||||
already aligned, that means no specific
|
||||
required alignement between property size
|
||||
required alignment between property size
|
||||
and property data. The old style variable
|
||||
alignment would make it impossible to do
|
||||
"simple" insertion of properties using
|
||||
memove (thanks Milton for
|
||||
noticing). Updated kernel patch as well
|
||||
- Correct a few more alignement constraints
|
||||
- Correct a few more alignment constraints
|
||||
- Add a chapter about the device-tree
|
||||
compiler and the textural representation of
|
||||
the tree that can be "compiled" by dtc.
|
||||
@ -854,7 +854,7 @@ address which can extend beyond that limit.
|
||||
console device if any. Typically, if you have serial devices on
|
||||
your board, you may want to put the full path to the one set as
|
||||
the default console in the firmware here, for the kernel to pick
|
||||
it up as it's own default console. If you look at the funciton
|
||||
it up as its own default console. If you look at the function
|
||||
set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
|
||||
that the kernel tries to find out the default console and has
|
||||
knowledge of various types like 8250 serial ports. You may want
|
||||
@ -1124,7 +1124,7 @@ should have the following properties:
|
||||
- interrupt-parent : contains the phandle of the interrupt
|
||||
controller which handles interrupts for this device
|
||||
- interrupts : a list of tuples representing the interrupt
|
||||
number and the interrupt sense and level for each interupt
|
||||
number and the interrupt sense and level for each interrupt
|
||||
for this device.
|
||||
|
||||
This information is used by the kernel to build the interrupt table
|
||||
|
@ -170,7 +170,7 @@ any point:
|
||||
1) the 'head' pointer or an subsequent linked list pointer
|
||||
is not a valid address of a user space word
|
||||
2) the calculated location of the 'lock word' (address plus
|
||||
'offset') is not the valud address of a 32 bit user space
|
||||
'offset') is not the valid address of a 32 bit user space
|
||||
word
|
||||
3) if the list contains more than 1 million (subject to
|
||||
future kernel configuration changes) elements.
|
||||
|
@ -181,7 +181,7 @@ for new threads, without the need of another syscall.]
|
||||
So there is virtually zero overhead for tasks not using robust futexes,
|
||||
and even for robust futex users, there is only one extra syscall per
|
||||
thread lifetime, and the cleanup operation, if it happens, is fast and
|
||||
straightforward. The kernel doesnt have any internal distinction between
|
||||
straightforward. The kernel doesn't have any internal distinction between
|
||||
robust and normal futexes.
|
||||
|
||||
If a futex is found to be held at exit time, the kernel sets the
|
||||
|
@ -75,8 +75,8 @@ name of the respective module is given in square brackets.
|
||||
|
||||
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
|
||||
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
|
||||
- Tripple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
|
||||
- Tripple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
|
||||
- Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
|
||||
- Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
|
||||
|
||||
In order to load, for example, the sha1_z990 module when the sha1 algorithm is
|
||||
requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf.
|
||||
|
@ -127,7 +127,7 @@ The following information is available in this file:
|
||||
- Correct a reference to free'ed memory during controller
|
||||
shutdown.
|
||||
- Reset the bus on an SE->LVD change. This is required
|
||||
to reset our transcievers.
|
||||
to reset our transceivers.
|
||||
|
||||
1.3.5 (March 24th, 2003)
|
||||
- Fix a few register window mode bugs.
|
||||
@ -169,7 +169,7 @@ The following information is available in this file:
|
||||
1.3.0 (January 21st, 2003)
|
||||
- Full regression testing for all U320 products completed.
|
||||
- Added abort and target/lun reset error recovery handler and
|
||||
interrupt coalessing.
|
||||
interrupt coalescing.
|
||||
|
||||
1.2.0 (November 14th, 2002)
|
||||
- Added support for Domain Validation
|
||||
|
@ -256,7 +256,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
|
||||
En/Disable High Byte LVD Termination
|
||||
|
||||
The upper 2 bits that deal with LVD termination only apply to Ultra2
|
||||
controllers. Futhermore, due to the current Ultra2 controller
|
||||
controllers. Furthermore, due to the current Ultra2 controller
|
||||
designs, these bits are tied together such that setting either bit
|
||||
enables both low and high byte LVD termination. It is not possible
|
||||
to only set high or low byte LVD termination in this manner. This is
|
||||
@ -436,7 +436,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
|
||||
the commas to periods, insmod won't interpret this as more than one
|
||||
string and write junk into our binary image. I consider it a bug in
|
||||
the insmod program that even if you wrap your string in quotes (quotes
|
||||
that pass the shell mind you and that insmod sees) it still treates
|
||||
that pass the shell mind you and that insmod sees) it still treats
|
||||
a comma inside of those quotes as starting a new variable, resulting
|
||||
in memory scribbles if you don't switch the commas to periods.
|
||||
|
||||
|
@ -461,7 +461,7 @@
|
||||
This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which
|
||||
allows data to be written from the system to the device. It is a
|
||||
necessary step to be allowed to set blocksize of SCSI-tape-drives and
|
||||
the tape-speed, whithout confusing the SCSI-Subsystem.
|
||||
the tape-speed, without confusing the SCSI-Subsystem.
|
||||
2) The recognition of a tape is included in the check_devices routine.
|
||||
This is done by checking for TYPE_TAPE, that is already defined in
|
||||
the kernel-scsi-environment. The markup of a tape is done in the
|
||||
@ -710,8 +710,8 @@
|
||||
of troubles with some controllers and after I wanted to apply some
|
||||
extensions, it jumped out in the same situation, on my w/cache, as like
|
||||
on D. Weinehalls' Model 56, having integrated SCSI. This gave me the
|
||||
descissive hint to move the code-part out and declare it global. Now,
|
||||
it seems to work by far much better an more stable. Let us see, what
|
||||
decisive hint to move the code-part out and declare it global. Now
|
||||
it seems to work far better and more stable. Let us see what
|
||||
the world thinks of it...
|
||||
3) By the way, only Sony DAT-drives seem to show density code 0x13. A
|
||||
test with a HP drive gave right results, so the problem is vendor-
|
||||
@ -822,10 +822,10 @@
|
||||
A long period of collecting bugreports from all corners of the world
|
||||
now lead to the following corrections to the code:
|
||||
1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
|
||||
was, that it is possible to disbale Fast-SCSI for the external bus.
|
||||
The feature-control command, where this crash appeared regularly tried
|
||||
was that it is possible to disable Fast-SCSI for the external bus.
|
||||
The feature-control command, where this crash appeared regularly, tried
|
||||
to set the maximum speed of 10MHz synchronous transfer speed and that
|
||||
reports a COMMAND ERROR, if external bus Fast-SCSI is disabled. Now,
|
||||
reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now,
|
||||
the feature-command probes down from maximum speed until the adapter
|
||||
stops to complain, which is at the same time the maximum possible
|
||||
speed selected in the reference program. So, F/W external can run at
|
||||
@ -920,7 +920,7 @@
|
||||
completed in such a way, that they are now completely conform to the
|
||||
demands in the technical description of IBM. Main candidates were the
|
||||
DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
|
||||
be tranferred by bypassing the internal command buffer of the adapter
|
||||
be transferred by bypassing the internal command buffer of the adapter
|
||||
or else the response can be a random result. GET_POS_INFO would be more
|
||||
safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
|
||||
is not allowed by the technical references of IBM. (Sorry, folks, the
|
||||
|
@ -24,7 +24,7 @@ UPDATE NEWS: version 1.32 - 28 Mar 98
|
||||
UPDATE NEWS: version 1.31 - 6 Jul 97
|
||||
|
||||
Fixed a bug that caused incorrect SCSI status bytes to be
|
||||
returned from commands sent to LUN's greater than 0. This
|
||||
returned from commands sent to LUNs greater than 0. This
|
||||
means that CDROM changers work now! Fixed a bug in the
|
||||
handling of command-line arguments when loaded as a module.
|
||||
Also put all the header data in in2000.h where it belongs.
|
||||
|
@ -393,7 +393,7 @@ struct sas_task {
|
||||
task_proto -- _one_ of enum sas_proto
|
||||
scatter -- pointer to scatter gather list array
|
||||
num_scatter -- number of elements in scatter
|
||||
total_xfer_len -- total number of bytes expected to be transfered
|
||||
total_xfer_len -- total number of bytes expected to be transferred
|
||||
data_dir -- PCI_DMA_...
|
||||
task_done -- callback when the task has finished execution
|
||||
};
|
||||
|
@ -115,7 +115,7 @@ SCSI standard documentations are available at SYMBIOS ftp server:
|
||||
|
||||
ftp://ftp.symbios.com/
|
||||
|
||||
Usefull SCSI tools written by Eric Youngdale are available at tsx-11:
|
||||
Useful SCSI tools written by Eric Youngdale are available at tsx-11:
|
||||
|
||||
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsiinfo-X.Y.tar.gz
|
||||
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz
|
||||
|
@ -88,7 +88,7 @@ If the module finds the changer, it prints some messages about the
|
||||
device [ try "dmesg" if you don't see anything ] and should show up in
|
||||
/proc/devices. If not.... some changers use ID ? / LUN 0 for the
|
||||
device and ID ? / LUN 1 for the robot mechanism. But Linux does *not*
|
||||
look for LUN's other than 0 as default, becauce there are to many
|
||||
look for LUNs other than 0 as default, because there are too many
|
||||
broken devices. So you can try:
|
||||
|
||||
1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
|
||||
@ -107,7 +107,7 @@ because the kernel will translate the error codes into human-readable
|
||||
strings then.
|
||||
|
||||
You can display these messages with the dmesg command (or check the
|
||||
logfiles). If you email me some question becauce of a problem with the
|
||||
logfiles). If you email me some question because of a problem with the
|
||||
driver, please include these messages.
|
||||
|
||||
|
||||
|
@ -75,7 +75,7 @@ with the command.
|
||||
|
||||
- otherwise
|
||||
scsi_eh_scmd_add(scmd, 0) is invoked for the command. See
|
||||
[1-3] for details of this funciton.
|
||||
[1-3] for details of this function.
|
||||
|
||||
|
||||
[1-2-2] Completing a scmd w/ timeout
|
||||
|
@ -261,7 +261,7 @@ pairs are separated with a comma (no spaces allowed). A colon can be
|
||||
used instead of the equal mark. The definition is prepended by the
|
||||
string st=. Here is an example:
|
||||
|
||||
st=buffer_kbs:64,write_threhold_kbs:60
|
||||
st=buffer_kbs:64,write_threshold_kbs:60
|
||||
|
||||
The following syntax used by the old kernel versions is also supported:
|
||||
|
||||
|
@ -609,7 +609,7 @@ appropriate mailing lists or news-groups. Send me a copy in order to
|
||||
be sure I will receive it. Obviously, a bug in the driver code is
|
||||
possible.
|
||||
|
||||
My cyrrent email address: Gerard Roudier <groudier@free.fr>
|
||||
My current email address: Gerard Roudier <groudier@free.fr>
|
||||
|
||||
Allowing disconnections is important if you use several devices on
|
||||
your SCSI bus but often causes problems with buggy devices.
|
||||
|
@ -942,13 +942,13 @@ replicas continue to be exactly same.
|
||||
->mnt_slave
|
||||
->mnt_master
|
||||
|
||||
->mnt_share links togather all the mount to/from which this vfsmount
|
||||
->mnt_share links together all the mount to/from which this vfsmount
|
||||
send/receives propagation events.
|
||||
|
||||
->mnt_slave_list links all the mounts to which this vfsmount propagates
|
||||
to.
|
||||
|
||||
->mnt_slave links togather all the slaves that its master vfsmount
|
||||
->mnt_slave links together all the slaves that its master vfsmount
|
||||
propagates to.
|
||||
|
||||
->mnt_master points to the master vfsmount from which this vfsmount
|
||||
|
@ -955,7 +955,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
||||
dmx6fire, dsp24, dsp24_value, dsp24_71, ez8,
|
||||
phase88, mediastation
|
||||
omni - Omni I/O support for MidiMan M-Audio Delta44/66
|
||||
cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever)
|
||||
cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transceiver)
|
||||
in msec resolution, default value is 500 (0.5 sec)
|
||||
|
||||
This module supports multiple cards and autoprobe. Note: The consumer part
|
||||
|
@ -6,7 +6,7 @@ This is based on SB-Live-mixer.txt.
|
||||
|
||||
The EMU10K2 chips have a DSP part which can be programmed to support
|
||||
various ways of sample processing, which is described here.
|
||||
(This acticle does not deal with the overall functionality of the
|
||||
(This article does not deal with the overall functionality of the
|
||||
EMU10K2 chips. See the manuals section for further details.)
|
||||
|
||||
The ALSA driver programs this portion of chip by default code
|
||||
|
@ -5,7 +5,7 @@
|
||||
|
||||
The EMU10K1 chips have a DSP part which can be programmed to support
|
||||
various ways of sample processing, which is described here.
|
||||
(This acticle does not deal with the overall functionality of the
|
||||
(This article does not deal with the overall functionality of the
|
||||
EMU10K1 chips. See the manuals section for further details.)
|
||||
|
||||
The ALSA driver programs this portion of chip by default code
|
||||
|
@ -50,7 +50,7 @@ Review cycle:
|
||||
Contact the kernel security team for more details on this procedure.
|
||||
|
||||
|
||||
Review committe:
|
||||
Review committee:
|
||||
|
||||
- This is made up of a number of kernel developers who have volunteered for
|
||||
this task, and a few that haven't.
|
||||
|
@ -146,7 +146,7 @@ or otherwise protected/tainted binaries. The modes are
|
||||
readable by root only. This allows the end user to remove
|
||||
such a dump but not access it directly. For security reasons
|
||||
core dumps in this mode will not overwrite one another or
|
||||
other files. This mode is appropriate when adminstrators are
|
||||
other files. This mode is appropriate when administrators are
|
||||
attempting to debug problems in a normal environment.
|
||||
|
||||
==============================================================
|
||||
|
@ -129,7 +129,7 @@ the high water marks for each per cpu page list.
|
||||
|
||||
zone_reclaim_mode:
|
||||
|
||||
Zone_reclaim_mode allows to set more or less agressive approaches to
|
||||
Zone_reclaim_mode allows someone to set more or less aggressive approaches to
|
||||
reclaim memory when a zone runs out of memory. If it is set to zero then no
|
||||
zone reclaim occurs. Allocations will be satisfied from other zones / nodes
|
||||
in the system.
|
||||
|
@ -1477,7 +1477,7 @@
|
||||
|
||||
|
||||
|
||||
Making it world-writeable looks bad, but it seems not to be
|
||||
Making it world-writable looks bad, but it seems not to be
|
||||
exploitable as a security hole. However, it does allow anyone to cre-
|
||||
ate useless tap devices (useless because they can't configure them),
|
||||
which is a DOS attack. A somewhat more secure alternative would to be
|
||||
|
@ -8,7 +8,7 @@ interfaces, but have similar sorts of communication needs. The two big
|
||||
examples for this are power devices (especially uninterruptable power
|
||||
supplies) and monitor control on higher end monitors.
|
||||
|
||||
To support these disparite requirements, the Linux USB system provides
|
||||
To support these disparate requirements, the Linux USB system provides
|
||||
HID events to two separate interfaces:
|
||||
* the input subsystem, which converts HID events into normal input
|
||||
device interfaces (such as keyboard, mouse and joystick) and a
|
||||
|
@ -24,10 +24,10 @@ are in no way responsible for any damage that may occur, no matter how
|
||||
inconsequential.
|
||||
|
||||
It seems that the Rio has a problem when sending .mp3 with low batteries.
|
||||
I suggest when the batteries are low and want to transfer stuff that you
|
||||
I suggest when the batteries are low and you want to transfer stuff that you
|
||||
replace it with a fresh one. In my case, what happened is I lost two 16kb
|
||||
blocks (they are no longer usable to store information to it). But I don't
|
||||
know if thats normal or not. It could simply be a problem with the flash
|
||||
know if that's normal or not; it could simply be a problem with the flash
|
||||
memory.
|
||||
|
||||
In an extreme case, I left my Rio playing overnight and the batteries wore
|
||||
|
@ -175,7 +175,7 @@ Keyspan USA-series Serial Adapters
|
||||
|
||||
Current status:
|
||||
The USA-18X, USA-28X, USA-19, USA-19W and USA-49W are supported and
|
||||
have been pretty throughly tested at various baud rates with 8-N-1
|
||||
have been pretty thoroughly tested at various baud rates with 8-N-1
|
||||
character settings. Other character lengths and parity setups are
|
||||
presently untested.
|
||||
|
||||
@ -253,7 +253,7 @@ Cypress M8 CY4601 Family Serial Driver
|
||||
together without hacking the adapter to set the line high.
|
||||
|
||||
The driver is smp safe. Performance with the driver is rather low when using
|
||||
it for transfering files. This is being worked on, but I would be willing to
|
||||
it for transferring files. This is being worked on, but I would be willing to
|
||||
accept patches. An urb queue or packet buffer would likely fit the bill here.
|
||||
|
||||
If you have any questions, problems, patches, feature requests, etc. you can
|
||||
@ -297,7 +297,7 @@ Belkin USB Serial Adapter F5U103
|
||||
Parity N,E,O,M,S
|
||||
Handshake None, Software (XON/XOFF), Hardware (CTSRTS,CTSDTR)*
|
||||
Break Set and clear
|
||||
Line contrl Input/Output query and control **
|
||||
Line control Input/Output query and control **
|
||||
|
||||
* Hardware input flow control is only enabled for firmware
|
||||
levels above 2.06. Read source code comments describing Belkin
|
||||
@ -309,7 +309,7 @@ Belkin USB Serial Adapter F5U103
|
||||
automatic hardware flow control.
|
||||
|
||||
TO DO List:
|
||||
-- Add true modem contol line query capability. Currently tracks the
|
||||
-- Add true modem control line query capability. Currently tracks the
|
||||
states reported by the interrupt and the states requested.
|
||||
-- Add error reporting back to application for UART error conditions.
|
||||
-- Add support for flush ioctls.
|
||||
|
@ -214,7 +214,7 @@ returned value is the temperature in degrees fahrenheit.
|
||||
|
||||
Finally the SETOPTIONS ioctl can be used to control some aspects of
|
||||
the cards operation; right now the pcwd driver is the only one
|
||||
supporting thiss ioctl.
|
||||
supporting this ioctl.
|
||||
|
||||
int options = 0;
|
||||
ioctl(fd, WDIOC_SETOPTIONS, options);
|
||||
|
144
MAINTAINERS
144
MAINTAINERS
@ -155,16 +155,16 @@ L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
9P FILE SYSTEM
|
||||
P: Eric Van Hensbergen
|
||||
M: ericvh@gmail.com
|
||||
P: Ron Minnich
|
||||
M: rminnich@lanl.gov
|
||||
P: Latchesar Ionkov
|
||||
M: lucho@ionkov.net
|
||||
L: v9fs-developer@lists.sourceforge.net
|
||||
W: http://v9fs.sf.net
|
||||
T: git kernel.org:/pub/scm/linux/kernel/ericvh/v9fs.git
|
||||
S: Maintained
|
||||
P: Eric Van Hensbergen
|
||||
M: ericvh@gmail.com
|
||||
P: Ron Minnich
|
||||
M: rminnich@lanl.gov
|
||||
P: Latchesar Ionkov
|
||||
M: lucho@ionkov.net
|
||||
L: v9fs-developer@lists.sourceforge.net
|
||||
W: http://v9fs.sf.net
|
||||
T: git kernel.org:/pub/scm/linux/kernel/ericvh/v9fs.git
|
||||
S: Maintained
|
||||
|
||||
A2232 SERIAL BOARD DRIVER
|
||||
P: Enver Haase
|
||||
@ -290,8 +290,8 @@ M: ink@jurassic.park.msu.ru
|
||||
S: Maintained for 2.4; PCI support for 2.6.
|
||||
|
||||
AMD GEODE PROCESSOR/CHIPSET SUPPORT
|
||||
P: Jordan Crouse
|
||||
M: info-linux@geode.amd.com
|
||||
P: Jordan Crouse
|
||||
M: info-linux@geode.amd.com
|
||||
L: info-linux@geode.amd.com
|
||||
W: http://www.amd.com/us-en/ConnectivitySolutions/TechnicalResources/0,,50_2334_2452_11363,00.html
|
||||
S: Supported
|
||||
@ -601,13 +601,13 @@ M: maxk@qualcomm.com
|
||||
S: Maintained
|
||||
|
||||
BONDING DRIVER
|
||||
P: Chad Tindel
|
||||
M: ctindel@users.sourceforge.net
|
||||
P: Jay Vosburgh
|
||||
M: fubar@us.ibm.com
|
||||
L: bonding-devel@lists.sourceforge.net
|
||||
W: http://sourceforge.net/projects/bonding/
|
||||
S: Supported
|
||||
P: Chad Tindel
|
||||
M: ctindel@users.sourceforge.net
|
||||
P: Jay Vosburgh
|
||||
M: fubar@us.ibm.com
|
||||
L: bonding-devel@lists.sourceforge.net
|
||||
W: http://sourceforge.net/projects/bonding/
|
||||
S: Supported
|
||||
|
||||
BROADBAND PROCESSOR ARCHITECTURE
|
||||
P: Arnd Bergmann
|
||||
@ -744,8 +744,8 @@ W: http://www.bullopensource.org/cpuset/
|
||||
S: Supported
|
||||
|
||||
CRAMFS FILESYSTEM
|
||||
W: http://sourceforge.net/projects/cramfs/
|
||||
S: Orphan
|
||||
W: http://sourceforge.net/projects/cramfs/
|
||||
S: Orphan
|
||||
|
||||
CRIS PORT
|
||||
P: Mikael Starvik
|
||||
@ -1054,11 +1054,11 @@ W: http://sourceforge.net/projects/emu10k1/
|
||||
S: Maintained
|
||||
|
||||
EMULEX LPFC FC SCSI DRIVER
|
||||
P: James Smart
|
||||
M: james.smart@emulex.com
|
||||
L: linux-scsi@vger.kernel.org
|
||||
W: http://sourceforge.net/projects/lpfcxxxx
|
||||
S: Supported
|
||||
P: James Smart
|
||||
M: james.smart@emulex.com
|
||||
L: linux-scsi@vger.kernel.org
|
||||
W: http://sourceforge.net/projects/lpfcxxxx
|
||||
S: Supported
|
||||
|
||||
EPSON 1355 FRAMEBUFFER DRIVER
|
||||
P: Christopher Hoover
|
||||
@ -1495,16 +1495,16 @@ L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
INTEL FRAMEBUFFER DRIVER (excluding 810 and 815)
|
||||
P: Sylvain Meyer
|
||||
M: sylvain.meyer@worldonline.fr
|
||||
L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
P: Sylvain Meyer
|
||||
M: sylvain.meyer@worldonline.fr
|
||||
L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
INTEL 810/815 FRAMEBUFFER DRIVER
|
||||
P: Antonino Daplas
|
||||
M: adaplas@pol.net
|
||||
L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
P: Antonino Daplas
|
||||
M: adaplas@pol.net
|
||||
L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
INTEL APIC/IOAPIC, LOWLEVEL X86 SMP SUPPORT
|
||||
P: Ingo Molnar
|
||||
@ -1830,11 +1830,11 @@ L: linuxppc-embedded@ozlabs.org
|
||||
S: Maintained
|
||||
|
||||
LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX
|
||||
P: Kumar Gala
|
||||
M: galak@kernel.crashing.org
|
||||
W: http://www.penguinppc.org/
|
||||
L: linuxppc-embedded@ozlabs.org
|
||||
S: Maintained
|
||||
P: Kumar Gala
|
||||
M: galak@kernel.crashing.org
|
||||
W: http://www.penguinppc.org/
|
||||
L: linuxppc-embedded@ozlabs.org
|
||||
S: Maintained
|
||||
|
||||
LINUX FOR POWERPC PA SEMI PWRFICIENT
|
||||
P: Olof Johansson
|
||||
@ -1933,10 +1933,10 @@ W: http://www.syskonnect.com
|
||||
S: Supported
|
||||
|
||||
MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
|
||||
P: Michael Kerrisk
|
||||
M: mtk-manpages@gmx.net
|
||||
W: ftp://ftp.kernel.org/pub/linux/docs/manpages
|
||||
S: Maintained
|
||||
P: Michael Kerrisk
|
||||
M: mtk-manpages@gmx.net
|
||||
W: ftp://ftp.kernel.org/pub/linux/docs/manpages
|
||||
S: Maintained
|
||||
|
||||
MARVELL MV643XX ETHERNET DRIVER
|
||||
P: Dale Farnsworth
|
||||
@ -1953,11 +1953,11 @@ L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
MEGARAID SCSI DRIVERS
|
||||
P: Neela Syam Kolli
|
||||
M: Neela.Kolli@engenio.com
|
||||
S: linux-scsi@vger.kernel.org
|
||||
W: http://megaraid.lsilogic.com
|
||||
S: Maintained
|
||||
P: Neela Syam Kolli
|
||||
M: Neela.Kolli@engenio.com
|
||||
S: linux-scsi@vger.kernel.org
|
||||
W: http://megaraid.lsilogic.com
|
||||
S: Maintained
|
||||
|
||||
MEMORY MANAGEMENT
|
||||
L: linux-mm@kvack.org
|
||||
@ -2186,10 +2186,10 @@ T: git kernel.org:/pub/scm/linux/kernel/git/aia21/ntfs-2.6.git
|
||||
S: Maintained
|
||||
|
||||
NVIDIA (rivafb and nvidiafb) FRAMEBUFFER DRIVER
|
||||
P: Antonino Daplas
|
||||
M: adaplas@pol.net
|
||||
L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
P: Antonino Daplas
|
||||
M: adaplas@pol.net
|
||||
L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
OPENCORES I2C BUS DRIVER
|
||||
P: Peter Korsgaard
|
||||
@ -2539,10 +2539,10 @@ RISCOM8 DRIVER
|
||||
S: Orphan
|
||||
|
||||
S3 SAVAGE FRAMEBUFFER DRIVER
|
||||
P: Antonino Daplas
|
||||
M: adaplas@pol.net
|
||||
L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
P: Antonino Daplas
|
||||
M: adaplas@pol.net
|
||||
L: linux-fbdev-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
S390
|
||||
P: Martin Schwidefsky
|
||||
@ -2623,10 +2623,10 @@ L: linux-scsi@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
SCTP PROTOCOL
|
||||
P: Sridhar Samudrala
|
||||
M: sri@us.ibm.com
|
||||
L: lksctp-developers@lists.sourceforge.net
|
||||
S: Supported
|
||||
P: Sridhar Samudrala
|
||||
M: sri@us.ibm.com
|
||||
L: lksctp-developers@lists.sourceforge.net
|
||||
S: Supported
|
||||
|
||||
SCx200 CPU SUPPORT
|
||||
P: Jim Cromie
|
||||
@ -2794,9 +2794,9 @@ L: tpmdd-devel@lists.sourceforge.net
|
||||
S: Maintained
|
||||
|
||||
Telecom Clock Driver for MCPL0010
|
||||
P: Mark Gross
|
||||
M: mark.gross@intel.com
|
||||
S: Supported
|
||||
P: Mark Gross
|
||||
M: mark.gross@intel.com
|
||||
S: Supported
|
||||
|
||||
TENSILICA XTENSA PORT (xtensa):
|
||||
P: Chris Zankel
|
||||
@ -2943,9 +2943,9 @@ L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
TI PARALLEL LINK CABLE DRIVER
|
||||
P: Romain Lievin
|
||||
M: roms@lpg.ticalc.org
|
||||
S: Maintained
|
||||
P: Romain Lievin
|
||||
M: roms@lpg.ticalc.org
|
||||
S: Maintained
|
||||
|
||||
TIPC NETWORK LAYER
|
||||
P: Per Liden
|
||||
@ -2995,12 +2995,12 @@ L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
TRIVIAL PATCHES
|
||||
P: Adrian Bunk
|
||||
M: trivial@kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
W: http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/bunk/trivial.git
|
||||
S: Maintained
|
||||
P: Adrian Bunk
|
||||
M: trivial@kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
W: http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/bunk/trivial.git
|
||||
S: Maintained
|
||||
|
||||
TMS380 TOKEN-RING NETWORK DRIVER
|
||||
P: Adam Fritzler
|
||||
|
@ -133,7 +133,7 @@ config IXP4XX_INDIRECT_PCI
|
||||
into the kernel and we can use the standard read[bwl]/write[bwl]
|
||||
macros. This is the preferred method due to speed but it
|
||||
limits the system to just 64MB of PCI memory. This can be
|
||||
problamatic if using video cards and other memory-heavy devices.
|
||||
problematic if using video cards and other memory-heavy devices.
|
||||
|
||||
2) If > 64MB of memory space is required, the IXP4xx can be
|
||||
configured to use indirect registers to access PCI This allows
|
||||
|
@ -8,7 +8,7 @@ config MACH_KEV7A400
|
||||
help
|
||||
Say Y here if you are using the Sharp KEV7A400 development
|
||||
board. This hardware is discontinued, so I'd be very
|
||||
suprised if you wanted this option.
|
||||
surprised if you wanted this option.
|
||||
|
||||
config MACH_LPD7A400
|
||||
bool "LPD7A400 Card Engine"
|
||||
|
@ -91,7 +91,7 @@ config SMDK2440_CPU2442
|
||||
config MACH_S3C2413
|
||||
bool
|
||||
help
|
||||
Internal node for S3C2413 verison of SMDK2413, so that
|
||||
Internal node for S3C2413 version of SMDK2413, so that
|
||||
machine_is_s3c2413() will work when MACH_SMDK2413 is
|
||||
selected
|
||||
|
||||
|
@ -197,7 +197,7 @@ config CPU_ARM940T
|
||||
select CPU_CP15_MPU
|
||||
help
|
||||
ARM940T is a member of the ARM9TDMI family of general-
|
||||
purpose microprocessors with MPU and seperate 4KB
|
||||
purpose microprocessors with MPU and separate 4KB
|
||||
instruction and 4KB data cases, each with a 4-word line
|
||||
length.
|
||||
|
||||
|
@ -323,7 +323,7 @@ config ETRAX_DEF_R_WAITSTATES
|
||||
depends on ETRAX_ARCH_V10
|
||||
default "95a6"
|
||||
help
|
||||
Waitstates for SRAM, Flash and peripherials (not DRAM). 95f8 is a
|
||||
Waitstates for SRAM, Flash and peripherals (not DRAM). 95f8 is a
|
||||
good choice for most Axis products...
|
||||
|
||||
config ETRAX_DEF_R_BUS_CONFIG
|
||||
|
@ -839,7 +839,7 @@ config ETRAX_DS1302_TRICKLE_CHARGE
|
||||
default "0"
|
||||
help
|
||||
This controls the initial value of the trickle charge register.
|
||||
0 = disabled (use this if you are unsure or have a non rechargable battery)
|
||||
0 = disabled (use this if you are unsure or have a non rechargeable battery)
|
||||
Otherwise the following values can be OR:ed together to control the
|
||||
charge current:
|
||||
1 = 2kohm, 2 = 4kohm, 3 = 4kohm
|
||||
|
@ -1,7 +1,7 @@
|
||||
/*!*****************************************************************************
|
||||
*!
|
||||
*! Implements an interface for i2c compatible eeproms to run under linux.
|
||||
*! Supports 2k, 8k(?) and 16k. Uses adaptive timing adjustents by
|
||||
*! Implements an interface for i2c compatible eeproms to run under Linux.
|
||||
*! Supports 2k, 8k(?) and 16k. Uses adaptive timing adjustments by
|
||||
*! Johan.Adolfsson@axis.com
|
||||
*!
|
||||
*! Probing results:
|
||||
@ -51,7 +51,7 @@
|
||||
*! Revision 1.8 2001/06/15 13:24:29 jonashg
|
||||
*! * Added verification of pointers from userspace in read and write.
|
||||
*! * Made busy counter volatile.
|
||||
*! * Added define for inital write delay.
|
||||
*! * Added define for initial write delay.
|
||||
*! * Removed warnings by using loff_t instead of unsigned long.
|
||||
*!
|
||||
*! Revision 1.7 2001/06/14 15:26:54 jonashg
|
||||
|
@ -47,7 +47,7 @@
|
||||
*! Update Port B register and shadow even when running with hardware support
|
||||
*! to avoid glitches when reading bits
|
||||
*! Never set direction to out in i2c_inbyte
|
||||
*! Removed incorrect clock togling at end of i2c_inbyte
|
||||
*! Removed incorrect clock toggling at end of i2c_inbyte
|
||||
*!
|
||||
*! Revision 1.8 2002/08/13 06:31:53 starvik
|
||||
*! Made SDA and SCL line configurable
|
||||
|
@ -33,7 +33,7 @@
|
||||
*!
|
||||
*! Revision 1.2 2002/11/19 14:35:24 starvik
|
||||
*! Changes from linux 2.4
|
||||
*! Changed struct initializer syntax to the currently prefered notation
|
||||
*! Changed struct initializer syntax to the currently preferred notation
|
||||
*!
|
||||
*! Revision 1.1 2001/12/17 13:59:27 bjornw
|
||||
*! Initial revision
|
||||
|
@ -88,7 +88,7 @@ config ETRAX_SERIAL_PORT0_DMA7_IN
|
||||
help
|
||||
Enables the DMA7 input channel for ser0 (ttyS0).
|
||||
If you do not enable DMA, an interrupt for each character will be
|
||||
used when receiveing data.
|
||||
used when receiving data.
|
||||
Normally you want to use DMA, unless you use the DMA channel for
|
||||
something else.
|
||||
|
||||
@ -157,7 +157,7 @@ config ETRAX_SERIAL_PORT1_DMA5_IN
|
||||
help
|
||||
Enables the DMA5 input channel for ser1 (ttyS1).
|
||||
If you do not enable DMA, an interrupt for each character will be
|
||||
used when receiveing data.
|
||||
used when receiving data.
|
||||
Normally you want this on, unless you use the DMA channel for
|
||||
something else.
|
||||
|
||||
@ -228,7 +228,7 @@ config ETRAX_SERIAL_PORT2_DMA3_IN
|
||||
help
|
||||
Enables the DMA3 input channel for ser2 (ttyS2).
|
||||
If you do not enable DMA, an interrupt for each character will be
|
||||
used when receiveing data.
|
||||
used when receiving data.
|
||||
Normally you want to use DMA, unless you use the DMA channel for
|
||||
something else.
|
||||
|
||||
@ -297,7 +297,7 @@ config ETRAX_SERIAL_PORT3_DMA9_IN
|
||||
help
|
||||
Enables the DMA9 input channel for ser3 (ttyS3).
|
||||
If you do not enable DMA, an interrupt for each character will be
|
||||
used when receiveing data.
|
||||
used when receiving data.
|
||||
Normally you want to use DMA, unless you use the DMA channel for
|
||||
something else.
|
||||
|
||||
|
@ -75,7 +75,7 @@
|
||||
** If a device prefetches beyond the end of a valid pdir entry, it will cause
|
||||
** a hard failure, ie. MCA. Version 3.0 and later of the zx1 LBA should
|
||||
** disconnect on 4k boundaries and prevent such issues. If the device is
|
||||
** particularly agressive, this option will keep the entire pdir valid such
|
||||
** particularly aggressive, this option will keep the entire pdir valid such
|
||||
** that prefetching will hit a valid address. This could severely impact
|
||||
** error containment, and is therefore off by default. The page that is
|
||||
** used for spill-over is poisoned, so that should help debugging somewhat.
|
||||
@ -258,10 +258,10 @@ static u64 prefetch_spill_page;
|
||||
|
||||
/*
|
||||
** DMA_CHUNK_SIZE is used by the SCSI mid-layer to break up
|
||||
** (or rather not merge) DMA's into managable chunks.
|
||||
** (or rather not merge) DMAs into manageable chunks.
|
||||
** On parisc, this is more of the software/tuning constraint
|
||||
** rather than the HW. I/O MMU allocation alogorithms can be
|
||||
** faster with smaller size is (to some degree).
|
||||
** rather than the HW. I/O MMU allocation algorithms can be
|
||||
** faster with smaller sizes (to some degree).
|
||||
*/
|
||||
#define DMA_CHUNK_SIZE (BITS_PER_LONG*iovp_size)
|
||||
|
||||
|
@ -565,7 +565,7 @@ config ROMVEC
|
||||
depends on ROM
|
||||
help
|
||||
This is almost always the same as the base of the ROM. Since on all
|
||||
68000 type varients the vectors are at the base of the boot device
|
||||
68000 type variants the vectors are at the base of the boot device
|
||||
on system startup.
|
||||
|
||||
config ROMVECSIZE
|
||||
@ -574,7 +574,7 @@ config ROMVECSIZE
|
||||
depends on ROM
|
||||
help
|
||||
Define the size of the vector region in ROM. For most 68000
|
||||
varients this would be 0x400 bytes in size. Set to 0 if you do
|
||||
variants this would be 0x400 bytes in size. Set to 0 if you do
|
||||
not want a vector region at the start of the ROM.
|
||||
|
||||
config ROMSTART
|
||||
|
@ -865,7 +865,7 @@ config MIPS_DISABLE_OBSOLETE_IDE
|
||||
bool
|
||||
|
||||
#
|
||||
# Endianess selection. Suffiently obscure so many users don't know what to
|
||||
# Endianess selection. Sufficiently obscure so many users don't know what to
|
||||
# answer,so we try hard to limit the available choices. Also the use of a
|
||||
# choice statement should be more obvious to the user.
|
||||
#
|
||||
@ -874,7 +874,7 @@ choice
|
||||
help
|
||||
Some MIPS machines can be configured for either little or big endian
|
||||
byte order. These modes require different kernels and a different
|
||||
Linux distribution. In general there is one prefered byteorder for a
|
||||
Linux distribution. In general there is one preferred byteorder for a
|
||||
particular system but some systems are just as commonly used in the
|
||||
one or the other endianess.
|
||||
|
||||
|
@ -425,7 +425,7 @@ config PPC_MAPLE
|
||||
default n
|
||||
help
|
||||
This option enables support for the Maple 970FX Evaluation Board.
|
||||
For more informations, refer to <http://www.970eval.com>
|
||||
For more information, refer to <http://www.970eval.com>
|
||||
|
||||
config PPC_PASEMI
|
||||
depends on PPC_MULTIPLATFORM && PPC64
|
||||
|
@ -21,7 +21,7 @@ config MPC834x_SYS
|
||||
Be aware that PCI buses can only function when SYS board is plugged
|
||||
into the PIB (Platform IO Board) board from Freescale which provide
|
||||
3 PCI slots. The PIBs PCI initialization is the bootloader's
|
||||
responsiblilty.
|
||||
responsibility.
|
||||
|
||||
config MPC834x_ITX
|
||||
bool "Freescale MPC834x ITX"
|
||||
@ -30,7 +30,7 @@ config MPC834x_ITX
|
||||
This option enables support for the MPC 834x ITX evaluation board.
|
||||
|
||||
Be aware that PCI initialization is the bootloader's
|
||||
responsiblilty.
|
||||
responsibility.
|
||||
|
||||
config MPC8360E_PB
|
||||
bool "Freescale MPC8360E PB"
|
||||
|
@ -724,7 +724,7 @@ config MPC834x_SYS
|
||||
Be aware that PCI buses can only function when SYS board is plugged
|
||||
into the PIB (Platform IO Board) board from Freescale which provide
|
||||
3 PCI slots. The PIBs PCI initialization is the bootloader's
|
||||
responsiblilty.
|
||||
responsibility.
|
||||
|
||||
config EV64360
|
||||
bool "Marvell-EV64360BP"
|
||||
|
@ -217,7 +217,7 @@ config SH_SHMIN
|
||||
bool "SHMIN"
|
||||
select CPU_SUBTYPE_SH7706
|
||||
help
|
||||
Select SHMIN if configureing for the SHMIN board
|
||||
Select SHMIN if configuring for the SHMIN board.
|
||||
|
||||
config SH_UNKNOWN
|
||||
bool "BareCPU"
|
||||
|
@ -383,7 +383,7 @@ void show_excp_regs(char *from, int trapnr, int signr, struct pt_regs *regs)
|
||||
/* ======================================================================= */
|
||||
|
||||
/*
|
||||
** Depending on <base> scan the MMU, Data or Instrction side
|
||||
** Depending on <base> scan the MMU, Data or Instruction side
|
||||
** looking for a valid mapping matching Eaddr & asid.
|
||||
** Return -1 if not found or the TLB id entry otherwise.
|
||||
** Note: it works only for 4k pages!
|
||||
|
@ -212,8 +212,8 @@ config SPARC_LED
|
||||
tristate "Sun4m LED driver"
|
||||
help
|
||||
This driver toggles the front-panel LED on sun4m systems
|
||||
in a user-specifyable manner. It's state can be probed
|
||||
by reading /proc/led and it's blinking mode can be changed
|
||||
in a user-specifiable manner. Its state can be probed
|
||||
by reading /proc/led and its blinking mode can be changed
|
||||
via writes to /proc/led
|
||||
|
||||
source "fs/Kconfig.binfmt"
|
||||
|
@ -120,7 +120,7 @@ static int winch_thread(void *arg)
|
||||
/* These are synchronization calls between various UML threads on the
|
||||
* host - since they are not different kernel threads, we cannot use
|
||||
* kernel semaphores. We don't use SysV semaphores because they are
|
||||
* persistant. */
|
||||
* persistent. */
|
||||
count = os_read_file(pipe_fd, &c, sizeof(c));
|
||||
if(count != sizeof(c))
|
||||
printk("winch_thread : failed to read synchronization byte, "
|
||||
|
@ -305,7 +305,7 @@ static void clear_lockup (struct atm_vcc *vcc, IADEV *dev) {
|
||||
** | R | NZ | 5-bit exponent | 9-bit mantissa |
|
||||
** +----+----+------------------+-------------------------------+
|
||||
**
|
||||
** R = reserverd (written as 0)
|
||||
** R = reserved (written as 0)
|
||||
** NZ = 0 if 0 cells/sec; 1 otherwise
|
||||
**
|
||||
** if NZ = 1, rate = 1.mmmmmmmmm x 2^(eeeee) cells/sec
|
||||
|
@ -994,7 +994,7 @@ config HPET
|
||||
help
|
||||
If you say Y here, you will have a miscdevice named "/dev/hpet/". Each
|
||||
open selects one of the timers supported by the HPET. The timers are
|
||||
non-periodioc and/or periodic.
|
||||
non-periodic and/or periodic.
|
||||
|
||||
config HPET_RTC_IRQ
|
||||
bool "HPET Control RTC IRQ" if !HPET_EMULATE_RTC
|
||||
|
@ -922,7 +922,7 @@ int RIOUnUse(unsigned long iPortP, struct CmdBlk *CmdBlkP)
|
||||
**
|
||||
** Packet is an actual packet structure to be filled in with the packet
|
||||
** information associated with the command. You need to fill in everything,
|
||||
** as the command processore doesn't process the command packet in any way.
|
||||
** as the command processor doesn't process the command packet in any way.
|
||||
**
|
||||
** The PreFuncP is called before the packet is enqueued on the host rup.
|
||||
** PreFuncP is called as (*PreFuncP)(PreArg, CmdBlkP);. PreFuncP must
|
||||
|
@ -222,7 +222,7 @@ int RIOBoardTest(unsigned long paddr, void __iomem *caddr, unsigned char type, i
|
||||
** which value will be written into memory.
|
||||
** Call with op set to zero means that the RAM will not be read and checked
|
||||
** before it is written.
|
||||
** Call with op not zero, and the RAM will be read and compated with val[op-1]
|
||||
** Call with op not zero and the RAM will be read and compared with val[op-1]
|
||||
** to check that the data from the previous phase was retained.
|
||||
*/
|
||||
|
||||
|
@ -87,8 +87,8 @@ static char *_rioparam_c_sccs_ = "@(#)rioparam.c 1.3";
|
||||
** command bit set onto the port. The command bit is in the len field,
|
||||
** and gets ORed in with the actual byte count.
|
||||
**
|
||||
** When you send a packet with the command bit set, then the first
|
||||
** data byte ( data[0] ) is interpretted as the command to execute.
|
||||
** When you send a packet with the command bit set the first
|
||||
** data byte (data[0]) is interpreted as the command to execute.
|
||||
** It also governs what data structure overlay should accompany the packet.
|
||||
** Commands are defined in cirrus/cirrus.h
|
||||
**
|
||||
@ -103,7 +103,7 @@ static char *_rioparam_c_sccs_ = "@(#)rioparam.c 1.3";
|
||||
**
|
||||
** Most commands do not use the remaining bytes in the data array. The
|
||||
** exceptions are OPEN MOPEN and CONFIG. (NB. As with the SI CONFIG and
|
||||
** OPEN are currently analagous). With these three commands the following
|
||||
** OPEN are currently analogous). With these three commands the following
|
||||
** 11 data bytes are all used to pass config information such as baud rate etc.
|
||||
** The fields are also defined in cirrus.h. Some contain straightforward
|
||||
** information such as the transmit XON character. Two contain the transmit and
|
||||
|
@ -1635,7 +1635,7 @@ static int idefloppy_begin_format(ide_drive_t *drive, int __user *arg)
|
||||
/*
|
||||
** Get ATAPI_FORMAT_UNIT progress indication.
|
||||
**
|
||||
** Userland gives a pointer to an int. The int is set to a progresss
|
||||
** Userland gives a pointer to an int. The int is set to a progress
|
||||
** indicator 0-65536, with 65536=100%.
|
||||
**
|
||||
** If the drive does not support format progress indication, we just check
|
||||
|
@ -464,7 +464,7 @@ int diva_4bri_init_card(diva_os_xdi_adapter_t * a)
|
||||
|
||||
/*
|
||||
** Cleanup function will be called for master adapter only
|
||||
** this is garanteed by design: cleanup callback is set
|
||||
** this is guaranteed by design: cleanup callback is set
|
||||
** by master adapter only
|
||||
*/
|
||||
static int diva_4bri_cleanup_adapter(diva_os_xdi_adapter_t * a)
|
||||
|
@ -16,7 +16,7 @@
|
||||
|
||||
/*
|
||||
* include Genero generated HFC-4S/8S header file hfc48scu.h
|
||||
* for comlete register description. This will define _HFC48SCU_H_
|
||||
* for complete register description. This will define _HFC48SCU_H_
|
||||
* to prevent redefinitions
|
||||
*/
|
||||
|
||||
|
@ -1442,7 +1442,7 @@ l2_tei_remove(struct FsmInst *fi, int event, void *arg)
|
||||
}
|
||||
|
||||
static void
|
||||
l2_st14_persistant_da(struct FsmInst *fi, int event, void *arg)
|
||||
l2_st14_persistent_da(struct FsmInst *fi, int event, void *arg)
|
||||
{
|
||||
struct PStack *st = fi->userdata;
|
||||
|
||||
@ -1453,7 +1453,7 @@ l2_st14_persistant_da(struct FsmInst *fi, int event, void *arg)
|
||||
}
|
||||
|
||||
static void
|
||||
l2_st5_persistant_da(struct FsmInst *fi, int event, void *arg)
|
||||
l2_st5_persistent_da(struct FsmInst *fi, int event, void *arg)
|
||||
{
|
||||
struct PStack *st = fi->userdata;
|
||||
|
||||
@ -1466,7 +1466,7 @@ l2_st5_persistant_da(struct FsmInst *fi, int event, void *arg)
|
||||
}
|
||||
|
||||
static void
|
||||
l2_st6_persistant_da(struct FsmInst *fi, int event, void *arg)
|
||||
l2_st6_persistent_da(struct FsmInst *fi, int event, void *arg)
|
||||
{
|
||||
struct PStack *st = fi->userdata;
|
||||
|
||||
@ -1477,7 +1477,7 @@ l2_st6_persistant_da(struct FsmInst *fi, int event, void *arg)
|
||||
}
|
||||
|
||||
static void
|
||||
l2_persistant_da(struct FsmInst *fi, int event, void *arg)
|
||||
l2_persistent_da(struct FsmInst *fi, int event, void *arg)
|
||||
{
|
||||
struct PStack *st = fi->userdata;
|
||||
|
||||
@ -1612,14 +1612,14 @@ static struct FsmNode L2FnList[] __initdata =
|
||||
{ST_L2_6, EV_L2_FRAME_ERROR, l2_frame_error},
|
||||
{ST_L2_7, EV_L2_FRAME_ERROR, l2_frame_error_reest},
|
||||
{ST_L2_8, EV_L2_FRAME_ERROR, l2_frame_error_reest},
|
||||
{ST_L2_1, EV_L1_DEACTIVATE, l2_st14_persistant_da},
|
||||
{ST_L2_1, EV_L1_DEACTIVATE, l2_st14_persistent_da},
|
||||
{ST_L2_2, EV_L1_DEACTIVATE, l2_st24_tei_remove},
|
||||
{ST_L2_3, EV_L1_DEACTIVATE, l2_st3_tei_remove},
|
||||
{ST_L2_4, EV_L1_DEACTIVATE, l2_st14_persistant_da},
|
||||
{ST_L2_5, EV_L1_DEACTIVATE, l2_st5_persistant_da},
|
||||
{ST_L2_6, EV_L1_DEACTIVATE, l2_st6_persistant_da},
|
||||
{ST_L2_7, EV_L1_DEACTIVATE, l2_persistant_da},
|
||||
{ST_L2_8, EV_L1_DEACTIVATE, l2_persistant_da},
|
||||
{ST_L2_4, EV_L1_DEACTIVATE, l2_st14_persistent_da},
|
||||
{ST_L2_5, EV_L1_DEACTIVATE, l2_st5_persistent_da},
|
||||
{ST_L2_6, EV_L1_DEACTIVATE, l2_st6_persistent_da},
|
||||
{ST_L2_7, EV_L1_DEACTIVATE, l2_persistent_da},
|
||||
{ST_L2_8, EV_L1_DEACTIVATE, l2_persistent_da},
|
||||
};
|
||||
|
||||
#define L2_FN_COUNT (sizeof(L2FnList)/sizeof(struct FsmNode))
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user