armbian/linux
0
0
Fork 0
mirror of https://github.com/armbian/linux.git synced 2026-01-06 10:13:00 -08:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master'

Browse Source
This commit is contained in:
Steven Whitehouse
2006-04-21 12:52:36 -04:00
parent c63e31c2cc f4ffaa452e
commit a748422ee4
1121 changed files with 22788 additions and 56322 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
CREDITS
View File

@@ -3382,7 +3382,7 @@ S: Germany
N: Geert Uytterhoeven
E: geert@linux-m68k.org
W: http://home.tvd.be/cr26864/
W: http://users.telenet.be/geertu/
P: 1024/862678A6 C51D 361C 0BD1 4C90 B275 C553 6EEA 11BA 8626 78A6
D: m68k/Amiga and PPC/CHRP Longtrail coordinator
D: Frame buffer device and XF68_FBDev maintainer
@@ -3392,8 +3392,8 @@ D: Amiga Buddha and Catweasel chipset IDE
D: Atari Falcon chipset IDE
D: Amiga Gayle chipset IDE
D: mipsel NEC DDB Vrc-5074
S: Emiel Vlieberghlaan 2A/21
S: B-3010 Kessel-Lo
S: Haterbeekstraat 55B
S: B-3200 Aarschot
S: Belgium
N: Chris Vance

49
Documentation/DMA-API.txt
View File

@@ -33,7 +33,9 @@ pci_alloc_consistent(struct pci_dev *dev, size_t size,
Consistent memory is memory for which a write by either the device or
the processor can immediately be read by the processor or device
without having to worry about caching effects.
without having to worry about caching effects. (You may however need
to make sure to flush the processor's write buffers before telling
devices to read that memory.)
This routine allocates a region of <size> bytes of consistent memory.
it also returns a <dma_handle> which may be cast to an unsigned
@@ -304,12 +306,12 @@ dma address with dma_mapping_error(). A non zero return value means the mapping
could not be created and the driver should take appropriate action (eg
reduce current DMA mapping usage or delay and try again later).
int
dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction direction)
int
pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)
int
dma_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction direction)
int
pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)
Maps a scatter gather list from the block layer.
@@ -327,12 +329,33 @@ critical that the driver do something, in the case of a block driver
aborting the request or even oopsing is better than doing nothing and
corrupting the filesystem.
void
dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries,
enum dma_data_direction direction)
void
pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)
With scatterlists, you use the resulting mapping like this:
int i, count = dma_map_sg(dev, sglist, nents, direction);
struct scatterlist *sg;
for (i = 0, sg = sglist; i < count; i++, sg++) {
hw_address[i] = sg_dma_address(sg);
hw_len[i] = sg_dma_len(sg);
}
where nents is the number of entries in the sglist.
The implementation is free to merge several consecutive sglist entries
into one (e.g. with an IOMMU, or if several pages just happen to be
physically contiguous) and returns the actual number of sg entries it
mapped them to. On failure 0, is returned.
Then you should loop count times (note: this can be less than nents times)
and use sg_dma_address() and sg_dma_len() macros where you previously
accessed sg->address and sg->length as shown above.
void
dma_unmap_sg(struct device *dev, struct scatterlist *sg,
int nhwentries, enum dma_data_direction direction)
void
pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)
unmap the previously mapped scatter/gather list. All the parameters
must be the same as those and passed in to the scatter/gather mapping

26
Documentation/DMA-mapping.txt
View File

@@ -58,11 +58,15 @@ translating each of those pages back to a kernel address using
something like __va(). [ EDIT: Update this when we integrate
Gerd Knorr's generic code which does this. ]
This rule also means that you may not use kernel image addresses
(ie. items in the kernel's data/text/bss segment, or your driver's)
nor may you use kernel stack addresses for DMA. Both of these items
might be mapped somewhere entirely different than the rest of physical
memory.
This rule also means that you may use neither kernel image addresses
(items in data/text/bss segments), nor module image addresses, nor
stack addresses for DMA. These could all be mapped somewhere entirely
different than the rest of physical memory. Even if those classes of
memory could physically work with DMA, you'd need to ensure the I/O
buffers were cacheline-aligned. Without that, you'd see cacheline
sharing problems (data corruption) on CPUs with DMA-incoherent caches.
(The CPU could write to one word, DMA would write to a different one
in the same cache line, and one of them could be overwritten.)
Also, this means that you cannot take the return of a kmap()
call and DMA to/from that. This is similar to vmalloc().
@@ -194,7 +198,7 @@ document for how to handle this case.
Finally, if your device can only drive the low 24-bits of
address during PCI bus mastering you might do something like:
if (pci_set_dma_mask(pdev, 0x00ffffff)) {
if (pci_set_dma_mask(pdev, DMA_24BIT_MASK)) {
printk(KERN_WARNING
"mydev: 24-bit DMA addressing not available.\n");
goto ignore_this_device;
@@ -212,7 +216,7 @@ functions (for example a sound card provides playback and record
functions) and the various different functions have _different_
DMA addressing limitations, you may wish to probe each mask and
only provide the functionality which the machine can handle. It
is important that the last call to pci_set_dma_mask() be for the
is important that the last call to pci_set_dma_mask() be for the
most specific mask.
Here is pseudo-code showing how this might be done:
@@ -284,6 +288,11 @@ There are two types of DMA mappings:
in order to get correct behavior on all platforms.
Also, on some platforms your driver may need to flush CPU write
buffers in much the same way as it needs to flush write buffers
found in PCI bridges (such as by reading a register's value
after writing it).
- Streaming DMA mappings which are usually mapped for one DMA transfer,
unmapped right after it (unless you use pci_dma_sync_* below) and for which
hardware can optimize for sequential accesses.
@@ -303,6 +312,9 @@ There are two types of DMA mappings:
Neither type of DMA mapping has alignment restrictions that come
from PCI, although some devices may have such restrictions.
Also, systems with caches that aren't DMA-coherent will work better
when the underlying buffers don't share cache lines with other data.
Using Consistent DMA mappings.

2
Documentation/DocBook/libata.tmpl
View File

@@ -705,7 +705,7 @@ and other resources, etc.
<sect1><title>ata_scsi_error()</title>
<para>
ata_scsi_error() is the current hostt->eh_strategy_handler()
ata_scsi_error() is the current transportt->eh_strategy_handler()
for libata. As discussed above, this will be entered in two
cases - timeout and ATAPI error completion. This function
calls low level libata driver's eng_timeout() callback, the

22
Documentation/block/switching-sched.txt Normal file
View File

@@ -0,0 +1,22 @@
As of the Linux 2.6.10 kernel, it is now possible to change the
IO scheduler for a given block device on the fly (thus making it possible,
for instance, to set the CFQ scheduler for the system default, but
set a specific device to use the anticipatory or noop schedulers - which
can improve that device's throughput).
To set a specific scheduler, simply do this:
echo SCHEDNAME > /sys/block/DEV/queue/scheduler
where SCHEDNAME is the name of a defined IO scheduler, and DEV is the
device name (hda, hdb, sga, or whatever you happen to have).
The list of defined schedulers can be found by simply doing
a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
will be displayed, with the currently selected scheduler in brackets:
# cat /sys/block/hda/queue/scheduler
noop anticipatory deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [anticipatory] deadline cfq

2
Documentation/cpu-freq/index.txt
View File

@@ -53,4 +53,4 @@ the CPUFreq Mailing list:
* http://lists.linux.org.uk/mailman/listinfo/cpufreq
Clock and voltage scaling for the SA-1100:
* http://www.lart.tudelft.nl/projects/scaling
* http://www.lartmaker.nl/projects/scaling

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

@@ -25,8 +25,9 @@ Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: drivers depending on OBSOLETE_OSS_DRIVER
When: January 2006
What: drivers that were depending on OBSOLETE_OSS_DRIVER
(config options already removed)
When: before 2.6.19
Why: OSS drivers with ALSA replacements
Who: Adrian Bunk <bunk@stusta.de>
@@ -71,14 +72,6 @@ Who: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
---------------------------
What: remove EXPORT_SYMBOL(panic_timeout)
When: April 2006
Files: kernel/panic.c
Why: No modular usage in the kernel.
Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: remove EXPORT_SYMBOL(insert_resource)
When: April 2006
Files: kernel/resource.c

12
Documentation/filesystems/vfs.txt
View File

@@ -694,7 +694,7 @@ struct file_operations
----------------------
This describes how the VFS can manipulate an open file. As of kernel
2.6.13, the following members are defined:
2.6.17, the following members are defined:
struct file_operations {
loff_t (*llseek) (struct file *, loff_t, int);
@@ -723,6 +723,10 @@ struct file_operations {
int (*check_flags)(int);
int (*dir_notify)(struct file *filp, unsigned long arg);
int (*flock) (struct file *, int, struct file_lock *);
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned
int);
ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned
int);
};
Again, all methods are called without any locks being held, unless
@@ -790,6 +794,12 @@ otherwise noted.
flock: called by the flock(2) system call
splice_write: called by the VFS to splice data from a pipe to a file. This
method is used by the splice(2) system call
splice_read: called by the VFS to splice data from file to a pipe. This
method is used by the splice(2) system call
Note that the file operations are implemented by the specific
filesystem in which the inode resides. When opening a device node
(character or block special) most filesystems will call special

16
Documentation/i2c/busses/i2c-parport
View File

@@ -12,18 +12,22 @@ meant as a replacement for the older, individual drivers:
teletext adapters)
It currently supports the following devices:
* Philips adapter
* home brew teletext adapter
* Velleman K8000 adapter
* ELV adapter
* Analog Devices evaluation boards (ADM1025, ADM1030, ADM1031, ADM1032)
* Barco LPT->DVI (K5800236) adapter
* (type=0) Philips adapter
* (type=1) home brew teletext adapter
* (type=2) Velleman K8000 adapter
* (type=3) ELV adapter
* (type=4) Analog Devices ADM1032 evaluation board
* (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031
* (type=6) Barco LPT->DVI (K5800236) adapter
These devices use different pinout configurations, so you have to tell
the driver what you have, using the type module parameter. There is no
way to autodetect the devices. Support for different pinout configurations
can be easily added when needed.
Earlier kernels defaulted to type=0 (Philips). But now, if the type
parameter is missing, the driver will simply fail to initialize.
Building your own adapter
-------------------------

286
Documentation/isdn/README.gigaset Normal file
View File

@@ -0,0 +1,286 @@
GigaSet 307x Device Driver
==========================
1. Requirements
------------
1.1. Hardware
--------
This release supports the connection of the Gigaset 307x/417x family of
ISDN DECT bases via Gigaset M101 Data, Gigaset M105 Data or direct USB
connection. The following devices are reported to be compatible:
307x/417x:
Gigaset SX255isdn
Gigaset SX353isdn
Sinus 45 [AB] isdn (Deutsche Telekom)
Sinus 721X/XA
Vox Chicago 390 ISDN (KPN Telecom)
M101:
Sinus 45 Data 1 (Telekom)
M105:
Gigaset USB Adapter DECT
Sinus 45 Data 2 (Telekom)
Sinus 721 data
Chicago 390 USB (KPN)
See also http://www.erbze.info/sinus_gigaset.htm and
http://gigaset307x.sourceforge.net/
We had also reports from users of Gigaset M105 who could use the drivers
with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.4.)
If you have another device that works with our driver, please let us know.
For example, Gigaset SX205isdn/Sinus 721 X SE and Gigaset SX303isdn bases
are just versions without answering machine of models known to work, so
they should work just as well; but so far we are lacking positive reports
on these.
Chances of getting an USB device to work are good if the output of
lsusb
at the command line contains one of the following:
ID 0681:0001
ID 0681:0002
ID 0681:0009
ID 0681:0021
ID 0681:0022
1.2. Software
--------
The driver works with ISDN4linux and so can be used with any software
which is able to use ISDN4linux for ISDN connections (voice or data).
CAPI4Linux support is planned but not yet available.
There are some user space tools available at
http://sourceforge.net/projects/gigaset307x/
which provide access to additional device specific functions like SMS,
phonebook or call journal.
2. How to use the driver
---------------------
2.1. Modules
-------
To get the device working, you have to load the proper kernel module. You
can do this using
modprobe modulename
where modulename is usb_gigaset (M105) or bas_gigaset (direct USB
connection to the base).
2.2. Device nodes for user space programs
------------------------------------
The device can be accessed from user space (eg. by the user space tools
mentioned in 1.2.) through the device nodes:
- /dev/ttyGU0 for M105 (USB data boxes)
- /dev/ttyGB0 for the base driver (direct USB connection)
You can also select a "default device" which is used by the frontends when
no device node is given as parameter, by creating a symlink /dev/ttyG to
one of them, eg.:
ln -s /dev/ttyGB0 /dev/ttyG
2.3. ISDN4linux
----------
This is the "normal" mode of operation. After loading the module you can
set up the ISDN system just as you'd do with any ISDN card.
Your distribution should provide some configuration utility.
If not, you can use some HOWTOs like
http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html
If this doesn't work, because you have some recent device like SX100 where
debug output (see section 3.2.) shows something like this when dialing
CMD Received: ERROR
Available Params: 0
Connection State: 0, Response: -1
gigaset_process_response: resp_code -1 in ConState 0 !
Timeout occurred
you might need to use unimodem mode:
2.4. Unimodem mode
-------------
This is needed for some devices [e.g. SX100] as they have problems with
the "normal" commands.
If you have installed the command line tool gigacontr, you can enter
unimodem mode using
gigacontr --mode unimodem
You can switch back using
gigacontr --mode isdn
You can also load the driver using e.g.
modprobe usb_gigaset startmode=0
to prevent the driver from starting in "isdn4linux mode".
In this mode the device works like a modem connected to a serial port
(the /dev/ttyGU0, ... mentioned above) which understands the commands
ATZ init, reset
=> OK or ERROR
ATD
ATDT dial
=> OK, CONNECT,
BUSY,
NO DIAL TONE,
NO CARRIER,
NO ANSWER
<pause>+++<pause> change to command mode when connected
ATH hangup
You can use some configuration tool of your distribution to configure this
"modem" or configure pppd/wvdial manually. There are some example ppp
configuration files and chat scripts in the gigaset-VERSION/ppp directory.
Please note that the USB drivers are not able to change the state of the
control lines (the M105 driver can be configured to use some undocumented
control requests, if you really need the control lines, though). This means
you must use "Stupid Mode" if you are using wvdial or you should use the
nocrtscts option of pppd.
You must also assure that the ppp_async module is loaded with the parameter
flag_time=0. You can do this e.g. by adding a line like
options ppp_async flag_time=0
to /etc/modprobe.conf. If your distribution has some local module
configuration file like /etc/modprobe.conf.local,
using that should be preferred.
2.5. Call-ID (CID) mode
------------------
Call-IDs are numbers used to tag commands to, and responses from, the
Gigaset base in order to support the simultaneous handling of multiple
ISDN calls. Their use can be enabled ("CID mode") or disabled ("Unimodem
mode"). Without Call-IDs (in Unimodem mode), only a very limited set of
functions is available. It allows outgoing data connections only, but
does not signal incoming calls or other base events.
DECT cordless data devices (M10x) permanently occupy the cordless
connection to the base while Call-IDs are activated. As the Gigaset
bases only support one DECT data connection at a time, this prevents
other DECT cordless data devices from accessing the base.
During active operation, the driver switches to the necessary mode
automatically. However, for the reasons above, the mode chosen when
the device is not in use (idle) can be selected by the user.
- If you want to receive incoming calls, you can use the default
settings (CID mode).
- If you have several DECT data devices (M10x) which you want to use
in turn, select Unimodem mode by passing the parameter "cidmode=0" to
the driver ("modprobe usb_gigaset cidmode=0" or modprobe.conf).
If you want both of these at once, you are out of luck.
You can also use /sys/module/<name>/parameters/cidmode for changing
the CID mode setting (<name> is usb_gigaset or bas_gigaset).
3. Troubleshooting
---------------
3.1. Solutions to frequently reported problems
-----------------------------------------
Problem:
You have a slow provider and isdn4linux gives up dialing too early.
Solution:
Load the isdn module using the dialtimeout option. You can do this e.g.
by adding a line like
options isdn dialtimeout=15
to /etc/modprobe.conf. If your distribution has some local module
configuration file like /etc/modprobe.conf.local,
using that should be preferred.
Problem:
Your isdn script aborts with a message about isdnlog.
Solution:
Try deactivating (or commenting out) isdnlog. This driver does not
support it.
Problem:
You have two or more DECT data adapters (M101/M105) and only the
first one you turn on works.
Solution:
Select Unimodem mode for all DECT data adapters. (see section 2.4.)
3.2. Telling the driver to provide more information
----------------------------------------------
Building the driver with the "Gigaset debugging" kernel configuration
option (CONFIG_GIGASET_DEBUG) gives it the ability to produce additional
information useful for debugging.
You can control the amount of debugging information the driver produces by
writing an appropriate value to /sys/module/gigaset/parameters/debug, e.g.
echo 0 > /sys/module/gigaset/parameters/debug
switches off debugging output completely,
echo 0x10a020 > /sys/module/gigaset/parameters/debug
enables the standard set of debugging output messages. These values are
bit patterns where every bit controls a certain type of debugging output.
See the constants DEBUG_* in the source file gigaset.h for details.
The initial value can be set using the debug parameter when loading the
module "gigaset", e.g. by adding a line
options gigaset debug=0
to /etc/modprobe.conf, ...
Generated debugging information can be found
- as output of the command
dmesg
- in system log files written by your syslog daemon, usually
in /var/log/, e.g. /var/log/messages.
3.3. Reporting problems and bugs
---------------------------
If you can't solve problems with the driver on your own, feel free to
use one of the forums, bug trackers, or mailing lists on
http://sourceforge.net/projects/gigaset307x
or write an electronic mail to the maintainers.
Try to provide as much information as possible, such as
- distribution
- kernel version (uname -r)
- gcc version (gcc --version)
- hardware architecture (uname -m, ...)
- type and firmware version of your device (base and wireless module,
if any)
- output of "lsusb -v" (if using an USB device)
- error messages
- relevant system log messages (it would help if you activate debug
output as described in 3.2.)
For help with general configuration problems not specific to our driver,
such as isdn4linux and network configuration issues, please refer to the
appropriate forums and newsgroups.
3.4. Reporting problem solutions
---------------------------
If you solved a problem with our drivers, wrote startup scripts for your
distribution, ... feel free to contact us (using one of the places
mentioned in 3.3.). We'd like to add scripts, hints, documentation
to the driver and/or the project web page.
4. Links, other software
---------------------
- Sourceforge project developing this driver and associated tools
http://sourceforge.net/projects/gigaset307x
- Yahoo! Group on the Siemens Gigaset family of devices
http://de.groups.yahoo.com/group/Siemens-Gigaset
- Siemens Gigaset/T-Sinus compatibility table
http://www.erbze.info/sinus_gigaset.htm
5. Credits
-------
Thanks to
Karsten Keil
for his help with isdn4linux
Deti Fliegl
for his base driver code
Dennis Dietrich
for his kernel 2.6 patches
Andreas Rummel
for his work and logs to get unimodem mode working
Andreas Degert
for his logs and patches to get cx 100 working
Dietrich Feist
for his generous donation of one M105 and two M101 cordless adapters
Christoph Schweers
for his generous donation of a M34 device
and all the other people who sent logs and other information.

2
Documentation/kbuild/modules.txt
View File

@@ -44,7 +44,7 @@ What is covered within this file is mainly information to authors
of modules. The author of an external modules should supply
a makefile that hides most of the complexity so one only has to type
'make' to build the module. A complete example will be present in
chapter ¤. Creating a kbuild file for an external module".
chapter 4, "Creating a kbuild file for an external module".
=== 2. How to build external modules

10
Documentation/laptop-mode.txt
View File

@@ -919,11 +919,11 @@ int main(int argc, char **argv)
int settle_time = 60;
/* Parse the simple command-line */
if (ac == 2)
disk = av[1];
else if (ac == 4) {
settle_time = atoi(av[2]);
disk = av[3];
if (argc == 2)
disk = argv[1];
else if (argc == 4) {
settle_time = atoi(argv[2]);
disk = argv[3];
} else
usage();

68
Documentation/memory-barriers.txt
View File

@@ -610,6 +610,7 @@ loads. Consider the following sequence of events:
CPU 1 CPU 2
======================= =======================
{ B = 7; X = 9; Y = 8; C = &Y }
STORE A = 1
STORE B = 2
<write barrier>
@@ -651,7 +652,20 @@ In the above example, CPU 2 perceives that B is 7, despite the load of *C
(which would be B) coming after the the LOAD of C.
If, however, a data dependency barrier were to be placed between the load of C
and the load of *C (ie: B) on CPU 2, then the following will occur:
and the load of *C (ie: B) on CPU 2:
CPU 1 CPU 2
======================= =======================
{ B = 7; X = 9; Y = 8; C = &Y }
STORE A = 1
STORE B = 2
<write barrier>
STORE C = &B LOAD X
STORE D = 4 LOAD C (gets &B)
<data dependency barrier>
LOAD *C (reads B)
then the following will occur:
+-------+ : : : :
| | +------+ +-------+
@@ -829,8 +843,8 @@ There are some more advanced barrier functions:
(*) smp_mb__after_atomic_inc();
These are for use with atomic add, subtract, increment and decrement
functions, especially when used for reference counting. These functions
do not imply memory barriers.
functions that don't return a value, especially when used for reference
counting. These functions do not imply memory barriers.
As an example, consider a piece of code that marks an object as being dead
and then decrements the object's reference count:
@@ -1263,15 +1277,17 @@ else.
ATOMIC OPERATIONS
-----------------
Though they are technically interprocessor interaction considerations, atomic
operations are noted specially as they do _not_ generally imply memory
barriers. The possible offenders include:
Whilst they are technically interprocessor interaction considerations, atomic
operations are noted specially as some of them imply full memory barriers and
some don't, but they're very heavily relied on as a group throughout the
kernel.
Any atomic operation that modifies some state in memory and returns information
about the state (old or new) implies an SMP-conditional general memory barrier
(smp_mb()) on each side of the actual operation. These include:
xchg();
cmpxchg();
test_and_set_bit();
test_and_clear_bit();
test_and_change_bit();
atomic_cmpxchg();
atomic_inc_return();
atomic_dec_return();
@@ -1282,21 +1298,31 @@ barriers. The possible offenders include:
atomic_sub_and_test();
atomic_add_negative();
atomic_add_unless();
test_and_set_bit();
test_and_clear_bit();
test_and_change_bit();
These may be used for such things as implementing LOCK operations or controlling
the lifetime of objects by decreasing their reference counts. In such cases
they need preceding memory barriers.
These are used for such things as implementing LOCK-class and UNLOCK-class
operations and adjusting reference counters towards object destruction, and as
such the implicit memory barrier effects are necessary.
The following may also be possible offenders as they may be used as UNLOCK
operations.
The following operation are potential problems as they do _not_ imply memory
barriers, but might be used for implementing such things as UNLOCK-class
operations:
atomic_set();
set_bit();
clear_bit();
change_bit();
atomic_set();
With these the appropriate explicit memory barrier should be used if necessary
(smp_mb__before_clear_bit() for instance).
The following are a little tricky:
The following also do _not_ imply memory barriers, and so may require explicit
memory barriers under some circumstances (smp_mb__before_atomic_dec() for
instance)):
atomic_add();
atomic_sub();
@@ -1317,10 +1343,12 @@ specific order.
Basically, each usage case has to be carefully considered as to whether memory
barriers are needed or not. The simplest rule is probably: if the atomic
operation is protected by a lock, then it does not require a barrier unless
there's another operation within the critical section with respect to which an
ordering must be maintained.
barriers are needed or not.
[!] Note that special memory barrier primitives are available for these
situations because on some CPUs the atomic instructions used imply full memory
barriers, and so barrier instructions are superfluous in conjunction with them,
and in such cases the special barrier primitives will be no-ops.
See Documentation/atomic_ops.txt for more information.

23
Documentation/mtrr.txt
View File

@@ -138,19 +138,29 @@ Reading MTRRs from a C program using ioctl()'s:
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <errno.h>
#define MTRR_NEED_STRINGS
#include <asm/mtrr.h>
#define TRUE 1
#define FALSE 0
#define ERRSTRING strerror (errno)
static char *mtrr_strings[MTRR_NUM_TYPES] =
{
"uncachable", /* 0 */
"write-combining", /* 1 */
"?", /* 2 */
"?", /* 3 */
"write-through", /* 4 */
"write-protect", /* 5 */
"write-back", /* 6 */
};
int main ()
{
@@ -232,13 +242,22 @@ Creating MTRRs from a C programme using ioctl()'s:
#include <fcntl.h>
#include <sys/ioctl.h>
#include <errno.h>
#define MTRR_NEED_STRINGS
#include <asm/mtrr.h>
#define TRUE 1
#define FALSE 0
#define ERRSTRING strerror (errno)
static char *mtrr_strings[MTRR_NUM_TYPES] =
{
"uncachable", /* 0 */
"write-combining", /* 1 */
"?", /* 2 */
"?", /* 3 */
"write-through", /* 4 */
"write-protect", /* 5 */
"write-back", /* 6 */
};
int main (int argc, char **argv)
{

166
Documentation/networking/xfrm_sync.txt Normal file
View File

@@ -0,0 +1,166 @@
The sync patches work is based on initial patches from
Krisztian <hidden@balabit.hu> and others and additional patches
from Jamal <hadi@cyberus.ca>.
The end goal for syncing is to be able to insert attributes + generate
events so that the an SA can be safely moved from one machine to another
for HA purposes.
The idea is to synchronize the SA so that the takeover machine can do
the processing of the SA as accurate as possible if it has access to it.
We already have the ability to generate SA add/del/upd events.
These patches add ability to sync and have accurate lifetime byte (to
ensure proper decay of SAs) and replay counters to avoid replay attacks
with as minimal loss at failover time.
This way a backup stays as closely uptodate as an active member.
Because the above items change for every packet the SA receives,
it is possible for a lot of the events to be generated.
For this reason, we also add a nagle-like algorithm to restrict
the events. i.e we are going to set thresholds to say "let me
know if the replay sequence threshold is reached or 10 secs have passed"
These thresholds are set system-wide via sysctls or can be updated
per SA.
The identified items that need to be synchronized are:
- the lifetime byte counter
note that: lifetime time limit is not important if you assume the failover
machine is known ahead of time since the decay of the time countdown
is not driven by packet arrival.
- the replay sequence for both inbound and outbound
1) Message Structure
----------------------
nlmsghdr:aevent_id:optional-TLVs.
The netlink message types are:
XFRM_MSG_NEWAE and XFRM_MSG_GETAE.
A XFRM_MSG_GETAE does not have TLVs.
A XFRM_MSG_NEWAE will have at least two TLVs (as is
discussed further below).
aevent_id structure looks like:
struct xfrm_aevent_id {
struct xfrm_usersa_id sa_id;
__u32 flags;
};
xfrm_usersa_id in this message layout identifies the SA.
flags are used to indicate different things. The possible
flags are:
XFRM_AE_RTHR=1, /* replay threshold*/
XFRM_AE_RVAL=2, /* replay value */
XFRM_AE_LVAL=4, /* lifetime value */
XFRM_AE_ETHR=8, /* expiry timer threshold */
XFRM_AE_CR=16, /* Event cause is replay update */
XFRM_AE_CE=32, /* Event cause is timer expiry */
XFRM_AE_CU=64, /* Event cause is policy update */
How these flags are used is dependent on the direction of the
message (kernel<->user) as well the cause (config, query or event).
This is described below in the different messages.
The pid will be set appropriately in netlink to recognize direction
(0 to the kernel and pid = processid that created the event
when going from kernel to user space)
A program needs to subscribe to multicast group XFRMNLGRP_AEVENTS
to get notified of these events.
2) TLVS reflect the different parameters:
-----------------------------------------
a) byte value (XFRMA_LTIME_VAL)
This TLV carries the running/current counter for byte lifetime since
last event.
b)replay value (XFRMA_REPLAY_VAL)
This TLV carries the running/current counter for replay sequence since
last event.
c)replay threshold (XFRMA_REPLAY_THRESH)
This TLV carries the threshold being used by the kernel to trigger events
when the replay sequence is exceeded.
d) expiry timer (XFRMA_ETIMER_THRESH)
This is a timer value in milliseconds which is used as the nagle
value to rate limit the events.
3) Default configurations for the parameters:
----------------------------------------------
By default these events should be turned off unless there is
at least one listener registered to listen to the multicast
group XFRMNLGRP_AEVENTS.
Programs installing SAs will need to specify the two thresholds, however,
in order to not change existing applications such as racoon
we also provide default threshold values for these different parameters
in case they are not specified.
the two sysctls/proc entries are:
a) /proc/sys/net/core/sysctl_xfrm_aevent_etime
used to provide default values for the XFRMA_ETIMER_THRESH in incremental
units of time of 100ms. The default is 10 (1 second)
b) /proc/sys/net/core/sysctl_xfrm_aevent_rseqth
used to provide default values for XFRMA_REPLAY_THRESH parameter
in incremental packet count. The default is two packets.
4) Message types
----------------
a) XFRM_MSG_GETAE issued by user-->kernel.
XFRM_MSG_GETAE does not carry any TLVs.
The response is a XFRM_MSG_NEWAE which is formatted based on what
XFRM_MSG_GETAE queried for.
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
*if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved
*if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved
b) XFRM_MSG_NEWAE is issued by either user space to configure
or kernel to announce events or respond to a XFRM_MSG_GETAE.
i) user --> kernel to configure a specific SA.
any of the values or threshold parameters can be updated by passing the
appropriate TLV.
A response is issued back to the sender in user space to indicate success
or failure.
In the case of success, additionally an event with
XFRM_MSG_NEWAE is also issued to any listeners as described in iii).
ii) kernel->user direction as a response to XFRM_MSG_GETAE
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
The threshold TLVs will be included if explicitly requested in
the XFRM_MSG_GETAE message.
iii) kernel->user to report as event if someone sets any values or
thresholds for an SA using XFRM_MSG_NEWAE (as described in #i above).
In such a case XFRM_AE_CU flag is set to inform the user that
the change happened as a result of an update.
The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
iv) kernel->user to report event when replay threshold or a timeout
is exceeded.
In such a case either XFRM_AE_CR (replay exceeded) or XFRM_AE_CE (timeout
happened) is set to inform the user what happened.
Note the two flags are mutually exclusive.
The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
Exceptions to threshold settings
--------------------------------
If you have an SA that is getting hit by traffic in bursts such that
there is a period where the timer threshold expires with no packets
seen, then an odd behavior is seen as follows:
The first packet arrival after a timer expiry will trigger a timeout
aevent; i.e we dont wait for a timeout period or a packet threshold
to be reached. This is done for simplicity and efficiency reasons.
-JHS

14
Documentation/scsi/scsi_eh.txt
View File

@@ -19,9 +19,9 @@ TABLE OF CONTENTS
[2-1-1] Overview
[2-1-2] Flow of scmds through EH
[2-1-3] Flow of control
[2-2] EH through hostt->eh_strategy_handler()
[2-2-1] Pre hostt->eh_strategy_handler() SCSI midlayer conditions
[2-2-2] Post hostt->eh_strategy_handler() SCSI midlayer conditions
[2-2] EH through transportt->eh_strategy_handler()
[2-2-1] Pre transportt->eh_strategy_handler() SCSI midlayer conditions
[2-2-2] Post transportt->eh_strategy_handler() SCSI midlayer conditions
[2-2-3] Things to consider
@@ -413,9 +413,9 @@ scmd->allowed.
layer of failure of the scmds.
[2-2] EH through hostt->eh_strategy_handler()
[2-2] EH through transportt->eh_strategy_handler()
hostt->eh_strategy_handler() is invoked in the place of
transportt->eh_strategy_handler() is invoked in the place of
scsi_unjam_host() and it is responsible for whole recovery process.
On completion, the handler should have made lower layers forget about
all failed scmds and either ready for new commands or offline. Also,
@@ -424,7 +424,7 @@ SCSI midlayer. IOW, of the steps described in [2-1-2], all steps
except for #1 must be implemented by eh_strategy_handler().
[2-2-1] Pre hostt->eh_strategy_handler() SCSI midlayer conditions
[2-2-1] Pre transportt->eh_strategy_handler() SCSI midlayer conditions
The following conditions are true on entry to the handler.
@@ -437,7 +437,7 @@ except for #1 must be implemented by eh_strategy_handler().
- shost->host_failed == shost->host_busy
[2-2-2] Post hostt->eh_strategy_handler() SCSI midlayer conditions
[2-2-2] Post transportt->eh_strategy_handler() SCSI midlayer conditions
The following conditions must be true on exit from the handler.

19
Documentation/scsi/scsi_mid_low_api.txt
View File

@@ -804,7 +804,6 @@ Summary:
eh_bus_reset_handler - issue SCSI bus reset
eh_device_reset_handler - issue SCSI device reset
eh_host_reset_handler - reset host (host bus adapter)
eh_strategy_handler - driver supplied alternate to scsi_unjam_host()
info - supply information about given host
ioctl - driver can respond to ioctls
proc_info - supports /proc/scsi/{driver_name}/{host_no}
@@ -969,24 +968,6 @@ Details:
int eh_host_reset_handler(struct scsi_cmnd * scp)
/**
* eh_strategy_handler - driver supplied alternate to scsi_unjam_host()
* @shp: host on which error has occurred
*
* Returns TRUE if host unjammed, else FALSE.
*
* Locks: none
*
* Calling context: kernel thread
*
* Notes: Invoked from scsi_eh thread. LLD supplied alternate to
* scsi_unjam_host() found in scsi_error.c
*
* Optionally defined in: LLD
**/
int eh_strategy_handler(struct Scsi_Host * shp)
/**
* info - supply information about given host: driver name plus data
* to distinguish given host

22
Documentation/serial/driver
View File

@@ -3,14 +3,11 @@
--------------------
$Id: driver,v 1.10 2002/07/22 15:27:30 rmk Exp $
This document is meant as a brief overview of some aspects of the new serial
driver. It is not complete, any questions you have should be directed to
<rmk@arm.linux.org.uk>
The reference implementation is contained within serial_amba.c.
The reference implementation is contained within amba_pl011.c.
@@ -31,6 +28,11 @@ The serial core provides a few helper functions. This includes identifing
the correct port structure (via uart_get_console) and decoding command line
arguments (uart_parse_options).
There is also a helper function (uart_write_console) which performs a
character by character write, translating newlines to CRLF sequences.
Driver writers are recommended to use this function rather than implementing
their own version.
Locking
-------
@@ -86,6 +88,7 @@ hardware.
- TIOCM_DTR DTR signal.
- TIOCM_OUT1 OUT1 signal.
- TIOCM_OUT2 OUT2 signal.
- TIOCM_LOOP Set the port into loopback mode.
If the appropriate bit is set, the signal should be driven
active. If the bit is clear, the signal should be driven
inactive.
@@ -141,6 +144,10 @@ hardware.
enable_ms(port)
Enable the modem status interrupts.
This method may be called multiple times. Modem status
interrupts should be disabled when the shutdown method is
called.
Locking: port->lock taken.
Interrupts: locally disabled.
This call must not sleep
@@ -160,6 +167,8 @@ hardware.
state. Enable the port for reception. It should not activate
RTS nor DTR; this will be done via a separate call to set_mctrl.
This method will only be called when the port is initially opened.
Locking: port_sem taken.
Interrupts: globally disabled.
@@ -169,6 +178,11 @@ hardware.
RTS nor DTR; this will have already been done via a separate
call to set_mctrl.
Drivers must not access port->info once this call has completed.
This method will only be called when there are no more users of
this port.
Locking: port_sem taken.
Interrupts: caller dependent.

16
Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
View File

@@ -1123,8 +1123,8 @@
if ((err = pci_enable_device(pci)) < 0)
return err;
/* check PCI availability (28bit DMA) */
if (pci_set_dma_mask(pci, 0x0fffffff) < 0 ||
pci_set_consistent_dma_mask(pci, 0x0fffffff) < 0) {
if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 ||
pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) {
printk(KERN_ERR "error to set 28bit mask DMA\n");
pci_disable_device(pci);
return -ENXIO;
@@ -1216,7 +1216,7 @@
The allocation of PCI resources is done in the
<function>probe()</function> function, and usually an extra
<function>xxx_create()</function> function is written for this
purpose.
purpose.
</para>
<para>
@@ -1225,7 +1225,7 @@
allocating resources. Also, you need to set the proper PCI DMA
mask to limit the accessed i/o range. In some cases, you might
need to call <function>pci_set_master()</function> function,
too.
too.
</para>
<para>
@@ -1236,8 +1236,8 @@
<![CDATA[
if ((err = pci_enable_device(pci)) < 0)
return err;
if (pci_set_dma_mask(pci, 0x0fffffff) < 0 ||
pci_set_consistent_dma_mask(pci, 0x0fffffff) < 0) {
if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 ||
pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) {
printk(KERN_ERR "error to set 28bit mask DMA\n");
pci_disable_device(pci);
return -ENXIO;
@@ -1256,13 +1256,13 @@
functions. Unlike ALSA ver.0.5.x., there are no helpers for
that. And these resources must be released in the destructor
function (see below). Also, on ALSA 0.9.x, you don't need to
allocate (pseudo-)DMA for PCI like ALSA 0.5.x.
allocate (pseudo-)DMA for PCI like ALSA 0.5.x.
</para>
<para>
Now assume that this PCI device has an I/O port with 8 bytes
and an interrupt. Then struct <structname>mychip</structname> will have the
following fields:
following fields:
<informalexample>
<programlisting>

31
Documentation/vm/hugetlbpage.txt
View File

@@ -27,12 +27,21 @@ number of free hugetlb pages at any time. It also displays information about
the configured hugepage size - this is needed for generating the proper
alignment and size of the arguments to the above system calls.
The output of "cat /proc/meminfo" will have output like:
The output of "cat /proc/meminfo" will have lines like:
.....
HugePages_Total: xxx
HugePages_Free: yyy
Hugepagesize: zzz KB
HugePages_Rsvd: www
Hugepagesize: zzz kB
where:
HugePages_Total is the size of the pool of hugepages.
HugePages_Free is the number of hugepages in the pool that are not yet
allocated.
HugePages_Rsvd is short for "reserved," and is the number of hugepages
for which a commitment to allocate from the pool has been made, but no
allocation has yet been made. It's vaguely analogous to overcommit.
/proc/filesystems should also show a filesystem of type "hugetlbfs" configured
in the kernel.
@@ -42,11 +51,11 @@ pages in the kernel. Super user can dynamically request more (or free some
pre-configured) hugepages.
The allocation (or deallocation) of hugetlb pages is possible only if there are
enough physically contiguous free pages in system (freeing of hugepages is
possible only if there are enough hugetlb pages free that can be transfered
possible only if there are enough hugetlb pages free that can be transferred
back to regular memory pool).
Pages that are used as hugetlb pages are reserved inside the kernel and can
not be used for other purposes.
Pages that are used as hugetlb pages are reserved inside the kernel and cannot
be used for other purposes.
Once the kernel with Hugetlb page support is built and running, a user can
use either the mmap system call or shared memory system calls to start using
@@ -60,7 +69,7 @@ Use the following command to dynamically allocate/deallocate hugepages:
This command will try to configure 20 hugepages in the system. The success
or failure of allocation depends on the amount of physically contiguous
memory that is preset in system at this time. System administrators may want
to put this command in one of the local rc init file. This will enable the
to put this command in one of the local rc init files. This will enable the
kernel to request huge pages early in the boot process (when the possibility
of getting physical contiguous pages is still very high).
@@ -78,8 +87,8 @@ the uid and gid of the current process are taken. The mode option sets the
mode of root of file system to value & 0777. This value is given in octal.
By default the value 0755 is picked. The size option sets the maximum value of
memory (huge pages) allowed for that filesystem (/mnt/huge). The size is
rounded down to HPAGE_SIZE. The option nr_inode sets the maximum number of
inodes that /mnt/huge can use. If the size or nr_inode options are not
rounded down to HPAGE_SIZE. The option nr_inodes sets the maximum number of
inodes that /mnt/huge can use. If the size or nr_inodes options are not
provided on command line then no limits are set. For size and nr_inodes
options, you can use [G|g]/[M|m]/[K|k] to represent giga/mega/kilo. For
example, size=2K has the same meaning as size=2048. An example is given at
@@ -88,7 +97,7 @@ the end of this document.
read and write system calls are not supported on files that reside on hugetlb
file systems.
A regular chown, chgrp and chmod commands (with right permissions) could be
Regular chown, chgrp, and chmod commands (with right permissions) could be
used to change the file attributes on hugetlbfs.
Also, it is important to note that no such mount command is required if the
@@ -96,8 +105,8 @@ applications are going to use only shmat/shmget system calls. Users who
wish to use hugetlb page via shared memory segment should be a member of
a supplementary group and system admin needs to configure that gid into
/proc/sys/vm/hugetlb_shm_group. It is possible for same or different
applications to use any combination of mmaps and shm* calls. Though the
mount of filesystem will be required for using mmaps.
applications to use any combination of mmaps and shm* calls, though the
mount of filesystem will be required for using mmap calls.
*******************************************************************

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