dect
/
linux-2.6
Archived
13
0
Fork 0
Code Releases Activity

Merge /pub/scm/linux/kernel/git/torvalds/linux-2.6

This commit is contained in:
Wim Van Sebroeck 2007-05-11 19:03:13 +00:00
parent 0d4804b31f 1f8a6b658a
commit 5c34202b8b
4626 changed files with 237138 additions and 95767 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
CREDITS
View File

@ -380,7 +380,7 @@ S: FutureTV Labs Ltd
S: Brunswick House, 61-69 Newmarket Rd, Cambridge CB5 8EG
S: United Kingdom
N: Thomas Bogendörfer
N: Thomas Bogendörfer
E: tsbogend@alpha.franken.de
D: PCnet32 driver, SONIC driver, JAZZ_ESP driver
D: newport abscon driver, g364 framebuffer driver
@ -400,7 +400,7 @@ W: http://math-www.uni-paderborn.de/~axel/
D: Configuration help text support
D: Linux CD and Support Giveaway List
N: Erik Inge Bolsø
N: Erik Inge Bolsø
E: knan@mo.himolde.no
D: Misc kernel hacks
@ -428,7 +428,7 @@ D: Various fixes (mostly networking)
S: Montreal, Quebec
S: Canada
N: Zoltán Böszörményi
N: Zoltán Böszörményi
E: zboszor@mail.externet.hu
D: MTRR emulation with Cyrix style ARR registers, Athlon MTRR support
@ -661,7 +661,7 @@ N: Kees Cook
E: kees@outflux.net
W: http://outflux.net/
P: 1024D/17063E6D 9FA3 C49C 23C9 D1BC 2E30 1975 1FFF 4BA9 1706 3E6D
D: Minor updates to SCSI code for the Communications type
D: Minor updates to SCSI types, added /proc/pid/maps protection
S: (ask for current address)
S: USA
@ -1029,11 +1029,11 @@ D: Future Domain TMC-16x0 SCSI driver (author)
D: APM driver (early port)
D: DRM drivers (author of several)
N: János Farkas
N: János Farkas
E: chexum@shadow.banki.hu
D: romfs, various (mostly networking) fixes
P: 1024/F81FB2E1 41 B7 E4 E6 3E D4 A6 71 6D 9C F3 9F F2 BF DF 6E
S: Madarász Viktor utca 25
S: Madarász Viktor utca 25
S: 1131 Budapest
S: Hungary
@ -1044,10 +1044,10 @@ D: UDF filesystem
S: (ask for current address)
S: USA
N: Jürgen Fischer
E: fischer@norbit.de (=?iso-8859-1?q?J=FCrgen?= Fischer)
N: Jürgen Fischer
E: fischer@norbit.de
D: Author of Adaptec AHA-152x SCSI driver
S: Schulstraße 18
S: Schulstraße 18
S: 26506 Norden
S: Germany
@ -1113,7 +1113,7 @@ E: fuganti@netbank.com.br
D: random kernel hacker, ZF MachZ Watchdog driver
S: Conectiva S.A.
S: R. Tocantins, 89 - Cristo Rei
S: 80050-430 - Curitiba - Paraná
S: 80050-430 - Curitiba - Paraná
S: Brazil
N: Kumar Gala
@ -1258,12 +1258,12 @@ S: 44 St. Joseph Street, Suite 506
S: Toronto, Ontario, M4Y 2W4
S: Canada
N: Richard Günther
N: Richard Günther
E: rguenth@tat.physik.uni-tuebingen.de
W: http://www.tat.physik.uni-tuebingen.de/~rguenth
P: 2048/2E829319 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
D: binfmt_misc
S: 72074 Tübingen
S: 72074 Tübingen
S: Germany
N: Justin Guyett
@ -1287,7 +1287,7 @@ N: Bruno Haible
E: haible@ma2s2.mathematik.uni-karlsruhe.de
D: SysV FS, shm swapping, memory management fixes
S: 17 rue Danton
S: F - 94270 Le Kremlin-Bicêtre
S: F - 94270 Le Kremlin-Bicêtre
S: France
N: Greg Hankins
@ -1701,7 +1701,7 @@ S: Czech Republic
N: Jakob Kemi
E: jakob.kemi@telia.com
D: V4L W9966 Webcam driver
S: Forsbyvägen 33
S: Forsbyvägen 33
S: 74143 Knivsta
S: Sweden
@ -1745,8 +1745,9 @@ S: D-64295
S: Germany
N: Andi Kleen
E: ak@muc.de
D: network hacker, syncookies
E: andi@firstfloor.org
U: http://www.halobates.de
D: network, x86, NUMA, various hacks
S: Schwalbenstr. 96
S: 85551 Ottobrunn
S: Germany
@ -2064,7 +2065,7 @@ D: misc. kernel hacking and debugging
S: Cambridge, MA 02139
S: USA
N: Martin von Löwis
N: Martin von Löwis
E: loewis@informatik.hu-berlin.de
D: script binary format
D: NTFS driver
@ -2141,7 +2142,7 @@ S: PO BOX 220, HFX. CENTRAL
S: Halifax, Nova Scotia
S: Canada B3J 3C8
N: Kai Mäkisara
N: Kai Mäkisara
E: Kai.Makisara@kolumbus.fi
D: SCSI Tape Driver
@ -2298,8 +2299,8 @@ E: acme@redhat.com
W: http://oops.ghostprotocols.net:81/blog/
P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01
D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
S: 80240-060 - Curitiba - Paraná
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
S: 80240-060 - Curitiba - Paraná
S: Brazil
N: Karsten Merker
@ -2579,10 +2580,9 @@ S: Australia
N: Miguel Ojeda Sandonis
E: maxextreme@gmail.com
D: Author: Auxiliary LCD Controller driver (ks0108)
D: Author: Auxiliary LCD driver (cfag12864b)
D: Author: Auxiliary LCD framebuffer driver (cfag12864bfb)
D: Maintainer: Auxiliary display drivers tree (drivers/auxdisplay/*)
W: http://maxextreme.googlepages.com/
D: Author of the ks0108, cfag12864b and cfag12864bfb auxiliary display drivers.
D: Maintainer of the auxiliary display drivers tree (drivers/auxdisplay/*)
S: C/ Mieses 20, 9-B
S: Valladolid 47009
S: Spain
@ -2785,10 +2785,10 @@ N: Juan Quintela
E: quintela@fi.udc.es
D: Memory Management hacking
S: LFCIA
S: Departamento de Computación
S: Universidade da Coruña
S: Departamento de Computación
S: Universidade da Coruña
S: E-15071
S: A Coruña
S: A Coruña
S: Spain
N: Augusto Cesar Radtke
@ -2939,7 +2939,7 @@ E: aris@cathedrallabs.org
D: Support for EtherExpress 10 ISA (i82595) in eepro driver
D: User level driver support for input
S: R. Jose Serrato, 130 - Santa Candida
S: 82640-320 - Curitiba - Paraná
S: 82640-320 - Curitiba - Paraná
S: Brazil
N: Alessandro Rubini
@ -3345,15 +3345,15 @@ P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE87 CA26 189B 9946 D0FE 7AFB
D: rcutorture maintainer
D: lock annotations, finding and fixing lock bugs
N: Winfried Trümper
N: Winfried Trümper
E: winni@xpilot.org
W: http://www.shop.de/~winni/
D: German HOWTO, Crash-Kurs Linux (German, 100 comprehensive pages)
D: CD-Writing HOWTO, various mini-HOWTOs
D: One-week tutorials on Linux twice a year (free of charge)
D: Linux-Workshop Köln (aka LUG Cologne, Germany), Installfests
D: Linux-Workshop Köln (aka LUG Cologne, Germany), Installfests
S: Tacitusstr. 6
S: D-50968 Köln
S: D-50968 Köln
N: Tsu-Sheng Tsao
E: tsusheng@scf.usc.edu

2
Documentation/ABI/removed/devfs
View File

@ -6,7 +6,7 @@ Description:
races, contains a naming policy within the kernel that is
against the LSB, and can be replaced by using udev.
The files fs/devfs/*, include/linux/devfs_fs*.h were removed,
along with the the assorted devfs function calls throughout the
along with the assorted devfs function calls throughout the
kernel tree.
Users:

17
Documentation/CodingStyle
View File

@ -160,6 +160,21 @@ supply of new-lines on your screen is not a renewable resource (think
25-line terminal screens here), you have more empty lines to put
comments on.
Do not unnecessarily use braces where a single statement will do.
if (condition)
action();
This does not apply if one branch of a conditional statement is a single
statement. Use braces in both branches.
if (condition) {
do_this();
do_that();
} else {
otherwise();
}
3.1: Spaces
Linux kernel style for use of spaces depends (mostly) on
@ -625,7 +640,7 @@ language.
There appears to be a common misperception that gcc has a magic "make me
faster" speedup option called "inline". While the use of inlines can be
appropriate (for example as a means of replacing macros, see Chapter 11), it
appropriate (for example as a means of replacing macros, see Chapter 12), it
very often is not. Abundant use of the inline keyword leads to a much bigger
kernel, which in turn slows the system as a whole down, due to a bigger
icache footprint for the CPU and simply because there is less memory

19
Documentation/DocBook/Makefile
View File

@ -41,8 +41,9 @@ psdocs: $(PS)
PDF := $(patsubst %.xml, %.pdf, $(BOOKS))
pdfdocs: $(PDF)
HTML := $(patsubst %.xml, %.html, $(BOOKS))
HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
htmldocs: $(HTML)
$(call build_main_index)
MAN := $(patsubst %.xml, %.9, $(BOOKS))
mandocs: $(MAN)
@ -132,10 +133,17 @@ quiet_cmd_db2pdf = PDF $@
%.pdf : %.xml
$(call cmd,db2pdf)
main_idx = Documentation/DocBook/index.html
build_main_index = rm -rf $(main_idx) && \
echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
cat $(HTML) >> $(main_idx)
quiet_cmd_db2html = HTML $@
cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
Goto $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
%.html: %.xml
@(which xmlto > /dev/null 2>&1) || \
@ -152,6 +160,7 @@ quiet_cmd_db2man = MAN $@
@(which xmlto > /dev/null 2>&1) || \
(echo "*** You need to install xmlto ***"; \
exit 1)
$(Q)mkdir -p $(obj)/man
$(call cmd,db2man)
@touch $@
@ -212,11 +221,7 @@ clean-files := $(DOCBOOKS) \
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
$(C-procfs-example)
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS))
#man put files in man subdir - traverse down
subdir- := man/
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
# Declare the contents of the .PHONY variable as phony. We keep that
# information in a variable se we can use it in if_changed and friends.

67
Documentation/DocBook/kernel-api.tmpl
View File

@ -84,6 +84,10 @@ X!Iinclude/linux/kobject.h
!Ekernel/rcupdate.c
</sect1>
<sect1><title>Device Resource Management</title>
!Edrivers/base/devres.c
</sect1>
</chapter>
<chapter id="adt">
@ -576,4 +580,67 @@ X!Idrivers/video/console/fonts.c
!Edrivers/input/ff-core.c
!Edrivers/input/ff-memless.c
</chapter>
<chapter id="spi">
<title>Serial Peripheral Interface (SPI)</title>
<para>
SPI is the "Serial Peripheral Interface", widely used with
embedded systems because it is a simple and efficient
interface: basically a multiplexed shift register.
Its three signal wires hold a clock (SCK, often in the range
of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and
a "Master In, Slave Out" (MISO) data line.
SPI is a full duplex protocol; for each bit shifted out the
MOSI line (one per clock) another is shifted in on the MISO line.
Those bits are assembled into words of various sizes on the
way to and from system memory.
An additional chipselect line is usually active-low (nCS);
four signals are normally used for each peripheral, plus
sometimes an interrupt.
</para>
<para>
The SPI bus facilities listed here provide a generalized
interface to declare SPI busses and devices, manage them
according to the standard Linux driver model, and perform
input/output operations.
At this time, only "master" side interfaces are supported,
where Linux talks to SPI peripherals and does not implement
such a peripheral itself.
(Interfaces to support implementing SPI slaves would
necessarily look different.)
</para>
<para>
The programming interface is structured around two kinds of driver,
and two kinds of device.
A "Controller Driver" abstracts the controller hardware, which may
be as simple as a set of GPIO pins or as complex as a pair of FIFOs
connected to dual DMA engines on the other side of the SPI shift
register (maximizing throughput). Such drivers bridge between
whatever bus they sit on (often the platform bus) and SPI, and
expose the SPI side of their device as a
<structname>struct spi_master</structname>.
SPI devices are children of that master, represented as a
<structname>struct spi_device</structname> and manufactured from
<structname>struct spi_board_info</structname> descriptors which
are usually provided by board-specific initialization code.
A <structname>struct spi_driver</structname> is called a
"Protocol Driver", and is bound to a spi_device using normal
driver model calls.
</para>
<para>
The I/O model is a set of queued messages. Protocol drivers
submit one or more <structname>struct spi_message</structname>
objects, which are processed and completed asynchronously.
(There are synchronous wrappers, however.) Messages are
built from one or more <structname>struct spi_transfer</structname>
objects, each of which wraps a full duplex SPI transfer.
A variety of protocol tweaking options are needed, because
different chips adopt very different policies for how they
use the bits transferred with SPI.
</para>
!Iinclude/linux/spi/spi.h
!Fdrivers/spi/spi.c spi_register_board_info
!Edrivers/spi/spi.c
</chapter>
</book>

16
Documentation/DocBook/librs.tmpl
View File

@ -79,12 +79,12 @@
<chapter id="usage">
<title>Usage</title>
<para>
This chapter provides examples how to use the library.
This chapter provides examples of how to use the library.
</para>
<sect1>
<title>Initializing</title>
<para>
The init function init_rs returns a pointer to a
The init function init_rs returns a pointer to an
rs decoder structure, which holds the necessary
information for encoding, decoding and error correction
with the given polynomial. It either uses an existing
@ -98,10 +98,10 @@
static struct rs_control *rs_decoder;
/* Symbolsize is 10 (bits)
* Primitve polynomial is x^10+x^3+1
* Primitive polynomial is x^10+x^3+1
* first consecutive root is 0
* primitve element to generate roots = 1
* generator polinomial degree (number of roots) = 6
* primitive element to generate roots = 1
* generator polynomial degree (number of roots) = 6
*/
rs_decoder = init_rs (10, 0x409, 0, 1, 6);
</programlisting>
@ -116,12 +116,12 @@ rs_decoder = init_rs (10, 0x409, 0, 1, 6);
</para>
<para>
The expanded data can be inverted on the fly by
providing a non zero inversion mask. The expanded data is
providing a non-zero inversion mask. The expanded data is
XOR'ed with the mask. This is used e.g. for FLASH
ECC, where the all 0xFF is inverted to an all 0x00.
The Reed-Solomon code for all 0x00 is all 0x00. The
code is inverted before storing to FLASH so it is 0xFF
too. This prevent's that reading from an erased FLASH
too. This prevents that reading from an erased FLASH
results in ECC errors.
</para>
<para>
@ -273,7 +273,7 @@ free_rs(rs_decoder);
May be used under the terms of the GNU General Public License (GPL)
</programlisting>
<para>
The wrapper functions and interfaces are written by Thomas Gleixner
The wrapper functions and interfaces are written by Thomas Gleixner.
</para>
<para>
Many users have provided bugfixes, improvements and helping hands for testing.

3
Documentation/DocBook/man/Makefile
View File

@ -1,3 +0,0 @@
# Rules are put in Documentation/DocBook
clean-files := *.9.gz *.sgml manpage.links manpage.refs

6
Documentation/MSI-HOWTO.txt
View File

@ -480,8 +480,8 @@ The PCI stack provides 3 possible levels of MSI disabling:
6.1. Disabling MSI on a single device
Under some circumstances, it might be required to disable MSI on a
single device, It may be achived by either not calling pci_enable_msi()
Under some circumstances it might be required to disable MSI on a
single device. This may be achieved by either not calling pci_enable_msi()
or all, or setting the pci_dev->no_msi flag before (most of the time
in a quirk).
@ -492,7 +492,7 @@ being able to route MSI between busses. In this case, MSI have to be
disabled on all devices behind this bridge. It is achieves by setting
the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
subordinate bus. There is no need to set the same flag on bridges that
are below the broken brigde. When pci_enable_msi() is called to enable
are below the broken bridge. When pci_enable_msi() is called to enable
MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
flag in all parent busses of the device.

10
Documentation/SubmitChecklist
View File

@ -73,10 +73,14 @@ kernel patches.
If the new code is substantial, addition of subsystem-specific fault
injection might be appropriate.
22: Newly-added code has been compiled with `gcc -W'. This will generate
lots of noise, but is good for finding bugs like "warning: comparison
between signed and unsigned".
22: Newly-added code has been compiled with `gcc -W' (use "make
EXTRA_CFLAGS=-W"). This will generate lots of noise, but is good for
finding bugs like "warning: comparison between signed and unsigned".
23: Tested after it has been merged into the -mm patchset to make sure
that it still works with all of the other queued patches and various
changes in the VM, VFS, and other subsystems.
24: Avoid whitespace damage such as indenting with spaces or whitespace
at the end of lines. You can test this by feeding the patch to
"git apply --check --whitespace=error-all"

15
Documentation/SubmittingDrivers
View File

@ -87,6 +87,21 @@ Clarity: It helps if anyone can see how to fix the driver. It helps
driver that intentionally obfuscates how the hardware works
it will go in the bitbucket.
PM support: Since Linux is used on many portable and desktop systems, your
driver is likely to be used on such a system and therefore it
should support basic power management by implementing, if
necessary, the .suspend and .resume methods used during the
system-wide suspend and resume transitions. You should verify
that your driver correctly handles the suspend and resume, but
if you are unable to ensure that, please at least define the
.suspend method returning the -ENOSYS ("Function not
implemented") error. You should also try to make sure that your
driver uses as little power as possible when it's not doing
anything. For the driver testing instructions see
Documentation/power/drivers-testing.txt and for a relatively
complete overview of the power management issues related to
drivers see Documentation/power/devices.txt .
Control: In general if there is active maintainance of a driver by
the author then patches will be redirected to them unless
they are totally obvious and without need of checking.

3
Documentation/SubmittingPatches
View File

@ -363,7 +363,8 @@ area or subsystem of the kernel is being patched.
The "summary phrase" in the email's Subject should concisely
describe the patch which that email contains. The "summary
phrase" should not be a filename. Do not use the same "summary
phrase" for every patch in a whole patch series.
phrase" for every patch in a whole patch series (where a "patch
series" is an ordered sequence of multiple, related patches).
Bear in mind that the "summary phrase" of your email becomes
a globally-unique identifier for that patch. It propagates

20
Documentation/accounting/getdelays.c
View File

@ -61,8 +61,6 @@ __u64 stime, utime;
#define MAX_MSG_SIZE 1024
/* Maximum number of cpus expected to be specified in a cpumask */
#define MAX_CPUS 32
/* Maximum length of pathname to log file */
#define MAX_FILENAME 256
struct msgtemplate {
struct nlmsghdr n;
@ -72,6 +70,16 @@ struct msgtemplate {
char cpumask[100+6*MAX_CPUS];
static void usage(void)
{
fprintf(stderr, "getdelays [-dilv] [-w logfile] [-r bufsize] "
"[-m cpumask] [-t tgid] [-p pid]\n");
fprintf(stderr, " -d: print delayacct stats\n");
fprintf(stderr, " -i: print IO accounting (works only with -p)\n");
fprintf(stderr, " -l: listen forever\n");
fprintf(stderr, " -v: debug on\n");
}
/*
* Create a raw netlink socket and bind
*/
@ -221,13 +229,13 @@ int main(int argc, char *argv[])
int count = 0;
int write_file = 0;
int maskset = 0;
char logfile[128];
char *logfile = NULL;
int loop = 0;
struct msgtemplate msg;
while (1) {
c = getopt(argc, argv, "diw:r:m:t:p:v:l");
c = getopt(argc, argv, "diw:r:m:t:p:vl");
if (c < 0)
break;
@ -241,7 +249,7 @@ int main(int argc, char *argv[])
print_io_accounting = 1;
break;
case 'w':
strncpy(logfile, optarg, MAX_FILENAME);
logfile = strdup(optarg);
printf("write to file %s\n", logfile);
write_file = 1;
break;
@ -277,7 +285,7 @@ int main(int argc, char *argv[])
loop = 1;
break;
default:
printf("Unknown option %d\n", c);
usage();
exit(-1);
}
}

2
Documentation/arm/Interrupts
View File

@ -149,7 +149,7 @@ So, what's changed?
3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
4. Direct access to SA1111 INTPOL is depreciated. Use set_irq_type instead.
4. Direct access to SA1111 INTPOL is deprecated. Use set_irq_type instead.
5. A handler is expected to perform any necessary acknowledgement of the
parent IRQ via the correct chip specific function. For instance, if

4
Documentation/arm/Samsung-S3C24XX/H1940.txt
View File

@ -23,7 +23,7 @@ Support
http://handhelds.org/moin/moin.cgi/HpIpaqH1940
Herbert Pötzl pages:
Herbert Pötzl pages:
http://vserver.13thfloor.at/H1940/
@ -32,7 +32,7 @@ Maintainers
-----------
This project is being maintained and developed by a variety
of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl.
of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl.
Thanks to the many others who have also provided support.

6
Documentation/auxdisplay/cfag12864b
View File

@ -78,9 +78,9 @@ Select (17)------------------------------(16) Data / Instruction
Ground (18)---[GND] [+5v]---(19) LED +
Ground (19)---[GND]
Ground (20)---[GND] E A Values:
Ground (21)---[GND] [GND]---[P1]---(18) Vee · R = Resistor = 22 ohm
Ground (22)---[GND] | · P1 = Preset = 10 Kohm
Ground (23)---[GND] ---- S ------( 3) V0 · P2 = Preset = 1 Kohm
Ground (21)---[GND] [GND]---[P1]---(18) Vee - R = Resistor = 22 ohm
Ground (22)---[GND] | - P1 = Preset = 10 Kohm
Ground (23)---[GND] ---- S ------( 3) V0 - P2 = Preset = 1 Kohm
Ground (24)---[GND] | |
Ground (25)---[GND] [GND]---[P2]---[R]---(20) LED -

2
Documentation/binfmt_misc.txt
View File

@ -113,4 +113,4 @@ cause unexpected behaviour and can be a security hazard.
There is a web page about binfmt_misc at
http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html
Richard Günther <rguenth@tat.physik.uni-tuebingen.de>
Richard Günther <rguenth@tat.physik.uni-tuebingen.de>

11
Documentation/blackfin/00-INDEX Normal file
View File

@ -0,0 +1,11 @@
00-INDEX
- This file
cache-lock.txt
- HOWTO for blackfin cache locking.
cachefeatures.txt
- Supported cache features.
Filesystems
- Requirements for mounting the root file system.

169
Documentation/blackfin/Filesystems Normal file
View File

@ -0,0 +1,169 @@
/*
* File: Documentation/blackfin/Filesystems
* Based on:
* Author:
*
* Created:
* Description: This file contains the simple DMA Implementation for Blackfin
*
* Rev: $Id: Filesystems 2384 2006-11-01 04:12:43Z magicyang $
*
* Modified:
* Copyright 2004-2006 Analog Devices Inc.
*
* Bugs: Enter bugs at http://blackfin.uclinux.org/
*
*/
How to mount the root file system in uClinux/Blackfin
-----------------------------------------------------
1 Mounting EXT3 File system.
------------------------
Creating an EXT3 File system for uClinux/Blackfin:
Please follow the steps to form the EXT3 File system and mount the same as root
file system.
a Make an ext3 file system as large as you want the final root file
system.
mkfs.ext3 /dev/ram0 <your-rootfs-size-in-1k-blocks>
b Mount this Empty file system on a free directory as:
mount -t ext3 /dev/ram0 ./test
where ./test is the empty directory.
c Copy your root fs directory that you have so carefully made over.
cp -af /tmp/my_final_rootfs_files/* ./test
(For ex: cp -af uClinux-dist/romfs/* ./test)
d If you have done everything right till now you should be able to see
the required "root" dir's (that's etc, root, bin, lib, sbin...)
e Now unmount the file system
umount ./test
f Create the root file system image.
dd if=/dev/ram0 bs=1k count=<your-rootfs-size-in-1k-blocks> \
> ext3fs.img
Now you have to tell the kernel that will be mounting this file system as
rootfs.
So do a make menuconfig under kernel and select the Ext3 journaling file system
support under File system --> submenu.
2. Mounting EXT2 File system.
-------------------------
By default the ext2 file system image will be created if you invoke make from
the top uClinux-dist directory.
3. Mounting CRAMFS File System
----------------------------
To create a CRAMFS file system image execute the command
mkfs.cramfs ./test cramfs.img
where ./test is the target directory.
4. Mounting ROMFS File System
--------------------------
To create a ROMFS file system image execute the command
genromfs -v -V "ROMdisk" -f romfs.img -d ./test
where ./test is the target directory
5. Mounting the JFFS2 Filesystem
-----------------------------
To create a compressed JFFS filesystem (JFFS2), please execute the command
mkfs.jffs2 -d ./test -o jffs2.img
where ./test is the target directory.
However, please make sure the following is in your kernel config.
/*
* RAM/ROM/Flash chip drivers
*/
#define CONFIG_MTD_CFI 1
#define CONFIG_MTD_ROM 1
/*
* Mapping drivers for chip access
*/
#define CONFIG_MTD_COMPLEX_MAPPINGS 1
#define CONFIG_MTD_BF533 1
#undef CONFIG_MTD_UCLINUX
Through the u-boot boot loader, use the jffs2.img in the corresponding
partition made in linux-2.6.x/drivers/mtd/maps/bf533_flash.c.
NOTE - Currently the Flash driver is available only for EZKIT. Watch out for a
STAMP driver soon.
6. Mounting the NFS File system
-----------------------------
For mounting the NFS please do the following in the kernel config.
In Networking Support --> Networking options --> TCP/IP networking -->
IP: kernel level autoconfiguration
Enable BOOTP Support.
In Kernel hacking --> Compiled-in kernel boot parameter add the following
root=/dev/nfs rw ip=bootp
In File system --> Network File system, Enable
NFS file system support --> NFSv3 client support
Root File system on NFS
in uClibc menuconfig, do the following
In Networking Support
enable Remote Procedure Call (RPC) support
Full RPC Support
On the Host side, ensure that /etc/dhcpd.conf looks something like this
ddns-update-style ad-hoc;
allow bootp;
subnet 10.100.4.0 netmask 255.255.255.0 {
default-lease-time 122209600;
max-lease-time 31557600;
group {
host bf533 {
hardware ethernet 00:CF:52:49:C3:01;
fixed-address 10.100.4.50;
option root-path "/home/nfsmount";
}
}
ensure that /etc/exports looks something like this
/home/nfsmount *(rw,no_root_squash,no_all_squash)
run the following commands as root (may differ depending on your
distribution) :
- service nfs start
- service portmap start
- service dhcpd start
- /usr/sbin/exportfs

48
Documentation/blackfin/cache-lock.txt Normal file
View File

@ -0,0 +1,48 @@
/*
* File: Documentation/blackfin/cache-lock.txt
* Based on:
* Author:
*
* Created:
* Description: This file contains the simple DMA Implementation for Blackfin
*
* Rev: $Id: cache-lock.txt 2384 2006-11-01 04:12:43Z magicyang $
*
* Modified:
* Copyright 2004-2006 Analog Devices Inc.
*
* Bugs: Enter bugs at http://blackfin.uclinux.org/
*
*/
How to lock your code in cache in uClinux/blackfin
--------------------------------------------------
There are only a few steps required to lock your code into the cache.
Currently you can lock the code by Way.
Below are the interface provided for locking the cache.
1. cache_grab_lock(int Ways);
This function grab the lock for locking your code into the cache specified
by Ways.
2. cache_lock(int Ways);
This function should be called after your critical code has been executed.
Once the critical code exits, the code is now loaded into the cache. This
function locks the code into the cache.
So, the example sequence will be:
cache_grab_lock(WAY0_L); /* Grab the lock */
critical_code(); /* Execute the code of interest */
cache_lock(WAY0_L); /* Lock the cache */
Where WAY0_L signifies WAY0 locking.

65
Documentation/blackfin/cachefeatures.txt Normal file
View File

@ -0,0 +1,65 @@
/*
* File: Documentation/blackfin/cachefeatures.txt
* Based on:
* Author:
*
* Created:
* Description: This file contains the simple DMA Implementation for Blackfin
*
* Rev: $Id: cachefeatures.txt 2384 2006-11-01 04:12:43Z magicyang $
*
* Modified:
* Copyright 2004-2006 Analog Devices Inc.
*
* Bugs: Enter bugs at http://blackfin.uclinux.org/
*
*/
- Instruction and Data cache initialization.
icache_init();
dcache_init();
- Instruction and Data cache Invalidation Routines, when flushing the
same is not required.
_icache_invalidate();
_dcache_invalidate();
Also, for invalidating the entire instruction and data cache, the below
routines are provided (another method for invalidation, refer page no 267 and 287 of
ADSP-BF533 Hardware Reference manual)
invalidate_entire_dcache();
invalidate_entire_icache();
-External Flushing of Instruction and data cache routines.
flush_instruction_cache();
flush_data_cache();
- Internal Flushing of Instruction and Data Cache.
icplb_flush();
dcplb_flush();
- Locking the cache.
cache_grab_lock();
cache_lock();
Please refer linux-2.6.x/Documentation/blackfin/cache-lock.txt for how to
lock the cache.
Locking the cache is optional feature.
- Miscellaneous cache functions.
flush_cache_all();
flush_cache_mm();
invalidate_dcache_range();
flush_dcache_range();
flush_dcache_page();
flush_cache_range();
flush_cache_page();
invalidate_dcache_range();
flush_page_to_ram();

8
Documentation/block/ioprio.txt
View File

@ -6,10 +6,10 @@ Intro
-----
With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io
priorities is supported for reads on files. This enables users to io nice
processes or process groups, similar to what has been possible to cpu
scheduling for ages. This document mainly details the current possibilites
with cfq, other io schedulers do not support io priorities so far.
priorities are supported for reads on files. This enables users to io nice
processes or process groups, similar to what has been possible with cpu
scheduling for ages. This document mainly details the current possibilities
with cfq; other io schedulers do not support io priorities thus far.
Scheduling classes
------------------

13
Documentation/cciss.txt
View File

@ -22,14 +22,21 @@ This driver is known to work with the following cards:
* SA E200i
* SA E500
Detecting drive failures:
-------------------------
To get the status of logical volumes and to detect physical drive
failures, you can use the cciss_vol_status program found here:
http://cciss.sourceforge.net/#cciss_utils
Device Naming:
--------------
If nodes are not already created in the /dev/cciss directory, run as root:
# cd /dev
# ./MAKEDEV cciss
Device Naming:
--------------
You need some entries in /dev for the cciss device. The MAKEDEV script
can make device nodes for you automatically. Currently the device setup
is as follows:

2
Documentation/cpu-freq/cpufreq-stats.txt
View File

@ -17,7 +17,7 @@ Contents
1. Introduction
cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
cpufreq-stats is a driver that provides CPU frequency statistics for each CPU.
These statistics are provided in /sysfs as a bunch of read_only interfaces. This
interface (when configured) will appear in a separate directory under cpufreq
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.

9
Documentation/cpu-hotplug.txt
View File

@ -217,14 +217,17 @@ Q: What happens when a CPU is being logically offlined?
A: The following happen, listed in no particular order :-)
- A notification is sent to in-kernel registered modules by sending an event
CPU_DOWN_PREPARE
CPU_DOWN_PREPARE or CPU_DOWN_PREPARE_FROZEN, depending on whether or not the
CPU is being offlined while tasks are frozen due to a suspend operation in
progress
- All process is migrated away from this outgoing CPU to a new CPU
- All interrupts targeted to this CPU is migrated to a new CPU
- timers/bottom half/task lets are also migrated to a new CPU
- Once all services are migrated, kernel calls an arch specific routine
__cpu_disable() to perform arch specific cleanup.
- Once this is successful, an event for successful cleanup is sent by an event
CPU_DEAD.
CPU_DEAD (or CPU_DEAD_FROZEN if tasks are frozen due to a suspend while the
CPU is being offlined).
"It is expected that each service cleans up when the CPU_DOWN_PREPARE
notifier is called, when CPU_DEAD is called its expected there is nothing
@ -242,9 +245,11 @@ A: This is what you would need in your kernel code to receive notifications.
switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
foobar_online_action(cpu);
break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
foobar_dead_action(cpu);
break;
}

6
Documentation/crypto/api-intro.txt
View File

@ -177,7 +177,7 @@ Portions of this API were derived from the following projects:
and;
Nettle (http://www.lysator.liu.se/~nisse/nettle/)
Niels Möller
Niels Möller
Original developers of the crypto algorithms:
@ -200,8 +200,8 @@ SHA1 algorithm contributors:
DES algorithm contributors:
Raimar Falke
Gisle Sælensminde
Niels Möller
Gisle Sælensminde
Niels Möller
Blowfish algorithm contributors:
Herbert Valerio Riedel

26
Documentation/device-mapper/delay.txt Normal file
View File

@ -0,0 +1,26 @@
dm-delay
========
Device-Mapper's "delay" target delays reads and/or writes
and maps them to different devices.
Parameters:
<device> <offset> <delay> [<write_device> <write_offset> <write_delay>]
With separate write parameters, the first set is only used for reads.
Delays are specified in milliseconds.
Example scripts
===============
[[
#!/bin/sh
# Create device delaying rw operation for 500ms
echo "0 `blockdev --getsize $1` delay $1 0 500" | dmsetup create delayed
]]
[[
#!/bin/sh
# Create device delaying only write operation for 500ms and
# splitting reads and writes to different devices $1 $2
echo "0 `blockdev --getsize $1` delay $1 0 0 $2 0 500" | dmsetup create delayed
]]

4
Documentation/dontdiff
View File

@ -55,8 +55,8 @@ aic7*seq.h*
aicasm
aicdb.h*
asm
asm-offsets.*
asm_offsets.*
asm-offsets.h
asm_offsets.h
autoconf.h*
bbootsect
bin2c

2
Documentation/driver-model/devres.txt
View File

@ -182,7 +182,7 @@ For example, you can do something like the following.
...
devres_close_group(dev, my_midlayer_something);
devres_close_group(dev, my_midlayer_create_something);
return 0;
}

4
Documentation/driver-model/platform.txt
View File

@ -16,7 +16,7 @@ host bridges to peripheral buses, and most controllers integrated
into system-on-chip platforms. What they usually have in common
is direct addressing from a CPU bus. Rarely, a platform_device will
be connected through a segment of some other kind of bus; but its
registers will still be directly addressible.
registers will still be directly addressable.
Platform devices are given a name, used in driver binding, and a
list of resources such as addresses and IRQs.
@ -125,7 +125,7 @@ three different ways to find such a match:
usually register later during booting, or by module loading.
- Registering a driver using platform_driver_probe() works just like
using platform_driver_register(), except that the the driver won't
using platform_driver_register(), except that the driver won't
be probed later if another device registers. (Which is OK, since
this interface is only for use with non-hotpluggable devices.)

2
Documentation/dvb/README.dvb-usb
View File

@ -228,5 +228,5 @@ Patches, comments and suggestions are very very welcome.
Ulf Hermenau for helping me out with traditional chinese.
André Smoktun and Christian Frömmel for supporting me with
André Smoktun and Christian Frömmel for supporting me with
hardware and listening to my problems very patiently.

2
Documentation/dvb/contributors.txt
View File

@ -66,7 +66,7 @@ Michael Dreher <michael@5dot1.de>
Andreas 'randy' Weinberger
for the support of the Fujitsu-Siemens Activy budget DVB-S
Kenneth Aafløy <ke-aa@frisurf.no>
Kenneth Aafløy <ke-aa@frisurf.no>
for adding support for Typhoon DVB-S budget card
Ernst Peinlich <e.peinlich@inode.at>

68
Documentation/fb/arkfb.txt Normal file
View File

@ -0,0 +1,68 @@
arkfb - fbdev driver for ARK Logic chips
========================================
Supported Hardware
==================
ARK 2000PV chip
ICS 5342 ramdac
- only BIOS initialized VGA devices supported
- probably not working on big endian
Supported Features
==================
* 4 bpp pseudocolor modes (with 18bit palette, two variants)
* 8 bpp pseudocolor mode (with 18bit palette)
* 16 bpp truecolor modes (RGB 555 and RGB 565)
* 24 bpp truecolor mode (RGB 888)
* 32 bpp truecolor mode (RGB 888)
* text mode (activated by bpp = 0)
* doublescan mode variant (not available in text mode)
* panning in both directions
* suspend/resume support
Text mode is supported even in higher resolutions, but there is limitation to
lower pixclocks (i got maximum about 70 MHz, it is dependent on specific
hardware). This limitation is not enforced by driver. Text mode supports 8bit
wide fonts only (hardware limitation) and 16bit tall fonts (driver
limitation). Unfortunately character attributes (like color) in text mode are
broken for unknown reason, so its usefulness is limited.
There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
with interleaved planes (1 byte interleave), MSB first. Both modes support
8bit wide fonts only (driver limitation).
Suspend/resume works on systems that initialize video card during resume and
if device is active (for example used by fbcon).
Missing Features
================
(alias TODO list)
* secondary (not initialized by BIOS) device support
* big endian support
* DPMS support
* MMIO support
* interlaced mode variant
* support for fontwidths != 8 in 4 bpp modes
* support for fontheight != 16 in text mode
* hardware cursor
* vsync synchronization
* feature connector support
* acceleration support (8514-like 2D)
Known bugs
==========
* character attributes (and cursor) in text mode are broken
--
Ondrej Zajicek <santiago@crfreenet.org>

4
Documentation/fb/aty128fb.txt
View File

@ -54,8 +54,8 @@ Accepted options:
noaccel - do not use acceleration engine. It is default.
accel - use acceleration engine. Not finished.
vmode:x - chooses PowerMacintosh video mode <x>. Depreciated.
cmode:x - chooses PowerMacintosh colour mode <x>. Depreciated.
vmode:x - chooses PowerMacintosh video mode <x>. Deprecated.
cmode:x - chooses PowerMacintosh colour mode <x>. Deprecated.
<XxX@X> - selects startup videomode. See modedb.txt for detailed
explanation. Default is 640x480x8bpp.

75
Documentation/fb/deferred_io.txt Normal file
View File

@ -0,0 +1,75 @@
Deferred IO
-----------
Deferred IO is a way to delay and repurpose IO. It uses host memory as a
buffer and the MMU pagefault as a pretrigger for when to perform the device
IO. The following example may be a useful explaination of how one such setup
works:
- userspace app like Xfbdev mmaps framebuffer
- deferred IO and driver sets up nopage and page_mkwrite handlers
- userspace app tries to write to mmaped vaddress
- we get pagefault and reach nopage handler
- nopage handler finds and returns physical page
- we get page_mkwrite where we add this page to a list
- schedule a workqueue task to be run after a delay
- app continues writing to that page with no additional cost. this is
the key benefit.
- the workqueue task comes in and mkcleans the pages on the list, then
completes the work associated with updating the framebuffer. this is
the real work talking to the device.
- app tries to write to the address (that has now been mkcleaned)
- get pagefault and the above sequence occurs again
As can be seen from above, one benefit is roughly to allow bursty framebuffer
writes to occur at minimum cost. Then after some time when hopefully things
have gone quiet, we go and really update the framebuffer which would be
a relatively more expensive operation.
For some types of nonvolatile high latency displays, the desired image is
the final image rather than the intermediate stages which is why it's okay
to not update for each write that is occuring.
It may be the case that this is useful in other scenarios as well. Paul Mundt
has mentioned a case where it is beneficial to use the page count to decide
whether to coalesce and issue SG DMA or to do memory bursts.
Another one may be if one has a device framebuffer that is in an usual format,
say diagonally shifting RGB, this may then be a mechanism for you to allow
apps to pretend to have a normal framebuffer but reswizzle for the device
framebuffer at vsync time based on the touched pagelist.
How to use it: (for applications)
---------------------------------
No changes needed. mmap the framebuffer like normal and just use it.
How to use it: (for fbdev drivers)
----------------------------------
The following example may be helpful.
1. Setup your structure. Eg:
static struct fb_deferred_io hecubafb_defio = {
.delay = HZ,
.deferred_io = hecubafb_dpy_deferred_io,
};
The delay is the minimum delay between when the page_mkwrite trigger occurs
and when the deferred_io callback is called. The deferred_io callback is
explained below.
2. Setup your deferred IO callback. Eg:
static void hecubafb_dpy_deferred_io(struct fb_info *info,
struct list_head *pagelist)
The deferred_io callback is where you would perform all your IO to the display
device. You receive the pagelist which is the list of pages that were written
to during the delay. You must not modify this list. This callback is called
from a workqueue.
3. Call init
info->fbdefio = &hecubafb_defio;
fb_deferred_io_init(info);
4. Call cleanup
fb_deferred_io_cleanup(info);

16
Documentation/fb/framebuffer.txt
View File

@ -215,11 +215,11 @@ vertical retrace time is the sum of the upper margin, the lower margin and the
vsync length.
+----------+---------------------------------------------+----------+-------+
| | ^ | | |
| | ↑ | | |
| | |upper_margin | | |
| | ･ | | |
| | ↓ | | |
+----------###############################################----------+-------+
| # ^ # | |
| # ↑ # | |
| # | # | |
| # | # | |
| # | # | |
@ -238,15 +238,15 @@ vsync length.
| # | # | |
| # | # | |
| # | # | |
| # ･ # | |
| # ↓ # | |
+----------###############################################----------+-------+
| | ^ | | |
| | ↑ | | |
| | |lower_margin | | |
| | ･ | | |
| | ↓ | | |
+----------+---------------------------------------------+----------+-------+
| | ^ | | |
| | ↑ | | |
| | |vsync_len | | |
| | ･ | | |
| | ↓ | | |
+----------+---------------------------------------------+----------+-------+
The frame buffer device expects all horizontal timings in number of dotclocks

2
Documentation/fb/imacfb.txt
View File

@ -17,7 +17,7 @@ How to use it?
==============
Imacfb does not have any kind of autodetection of your machine.
You have to add the fillowing kernel parameters in your elilo.conf:
You have to add the following kernel parameters in your elilo.conf:
Macbook :
video=imacfb:macbook
MacMini :

12
Documentation/fb/s3fb.txt
View File

@ -35,10 +35,12 @@ Supported Features
* suspend/resume support
* DPMS support
Text mode is supported even in higher resolutions, but there is limitation
to lower pixclocks (maximum between 50-60 MHz, depending on specific hardware).
This limitation is not enforced by driver. Text mode supports 8bit wide fonts
only (hardware limitation) and 16bit tall fonts (driver limitation).
Text mode is supported even in higher resolutions, but there is limitation to
lower pixclocks (maximum usually between 50-60 MHz, depending on specific
hardware, i get best results from plain S3 Trio32 card - about 75 MHz). This
limitation is not enforced by driver. Text mode supports 8bit wide fonts only
(hardware limitation) and 16bit tall fonts (driver limitation). Text mode
support is broken on S3 Trio64 V2/DX.
There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
@ -73,6 +75,8 @@ Known bugs
==========
* cursor disable in text mode doesn't work
* text mode broken on S3 Trio64 V2/DX
--
Ondrej Zajicek <santiago@crfreenet.org>

4
Documentation/fb/sstfb.txt
View File

@ -2,9 +2,9 @@
Introduction
This is a frame buffer device driver for 3dfx' Voodoo Graphics
(aka voodoo 1, aka sst1) and Voodoo² (aka Voodoo 2, aka CVG) based
(aka voodoo 1, aka sst1) and Voodoo² (aka Voodoo 2, aka CVG) based
video boards. It's highly experimental code, but is guaranteed to work
on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d²" boards,
on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d²" boards,
and with me "between chair and keyboard". Some people tested other
combinations and it seems that it works.
The main page is located at <http://sstfb.sourceforge.net>, and if

64
Documentation/fb/vt8623fb.txt Normal file
View File

@ -0,0 +1,64 @@
vt8623fb - fbdev driver for graphics core in VIA VT8623 chipset
===============================================================
Supported Hardware
==================
VIA VT8623 [CLE266] chipset and its graphics core
(known as CastleRock or Unichrome)
I tested vt8623fb on VIA EPIA ML-6000
Supported Features
==================
* 4 bpp pseudocolor modes (with 18bit palette, two variants)
* 8 bpp pseudocolor mode (with 18bit palette)
* 16 bpp truecolor mode (RGB 565)
* 32 bpp truecolor mode (RGB 888)
* text mode (activated by bpp = 0)
* doublescan mode variant (not available in text mode)
* panning in both directions
* suspend/resume support
* DPMS support
Text mode is supported even in higher resolutions, but there is limitation to
lower pixclocks (maximum about 100 MHz). This limitation is not enforced by
driver. Text mode supports 8bit wide fonts only (hardware limitation) and
16bit tall fonts (driver limitation).
There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
with interleaved planes (1 byte interleave), MSB first. Both modes support
8bit wide fonts only (driver limitation).
Suspend/resume works on systems that initialize video card during resume and
if device is active (for example used by fbcon).
Missing Features
================
(alias TODO list)
* secondary (not initialized by BIOS) device support
* MMIO support
* interlaced mode variant
* support for fontwidths != 8 in 4 bpp modes
* support for fontheight != 16 in text mode
* hardware cursor
* video overlay support
* vsync synchronization
* acceleration support (8514-like 2D, busmaster transfers)
Known bugs
==========
* cursor disable in text mode doesn't work
--
Ondrej Zajicek <santiago@crfreenet.org>

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

@ -6,6 +6,14 @@ be removed from this file.
---------------------------
What: MXSER
When: December 2007
Why: Old mxser driver is obsoleted by the mxser_new. Give it some time yet
and remove it.
Who: Jiri Slaby <jirislaby@gmail.com>
---------------------------
What: V4L2 VIDIOC_G_MPEGCOMP and VIDIOC_S_MPEGCOMP
When: October 2007
Why: Broken attempt to set MPEG compression parameters. These ioctls are
@ -51,6 +59,15 @@ Who: Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
---------------------------
What: old NCR53C9x driver
When: October 2007
Why: Replaced by the much better esp_scsi driver. Actual low-level
driver can ported over almost trivially.
Who: David Miller <davem@davemloft.net>
Christoph Hellwig <hch@lst.de>
---------------------------
What: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
When: December 2006
Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
@ -117,25 +134,6 @@ Who: Adrian Bunk <bunk@stusta.de>
---------------------------
What: pci_module_init(driver)
When: January 2007
Why: Is replaced by pci_register_driver(pci_driver).
Who: Richard Knutsson <ricknu-0@student.ltu.se> and Greg Kroah-Hartman <gregkh@suse.de>
---------------------------
What: Usage of invalid timevals in setitimer
When: March 2007
Why: POSIX requires to validate timevals in the setitimer call. This
was never done by Linux. The invalid (e.g. negative timevals) were
silently converted to more or less random timeouts and intervals.
Until the removal a per boot limited number of warnings is printed
and the timevals are sanitized.
Who: Thomas Gleixner <tglx@linutronix.de>
---------------------------
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
(temporary transition config option provided until then)
The transition config option will also be removed at the same time.
@ -163,7 +161,7 @@ Who: Greg Kroah-Hartman <gregkh@suse.de>
---------------------------
What: Interrupt only SA_* flags
When: Januar 2007
When: September 2007
Why: The interrupt related SA_* flags are replaced by IRQF_* to move them
out of the signal namespace.
@ -190,18 +188,10 @@ Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: i2c_adapter.dev
i2c_adapter.list
What: i2c_adapter.list
When: July 2007
Why: Superfluous, given i2c_adapter.class_dev:
* The "dev" was a stand-in for the physical device node that legacy
drivers would not have; but now it's almost always present. Any
remaining legacy drivers must upgrade (they now trigger warnings).
* The "list" duplicates class device children.
The delay in removing this is so upgraded lm_sensors and libsensors
can get deployed. (Removal causes minor changes in the sysfs layout,
notably the location of the adapter type name and parenting the i2c
client hardware directly from their controller.)
Why: Superfluous, this list duplicates the one maintained by the driver
core.
Who: Jean Delvare <khali@linux-fr.org>,
David Brownell <dbrownell@users.sourceforge.net>
@ -306,3 +296,35 @@ Why: Code was merged, then submitter immediately disappeared leaving
Who: David S. Miller <davem@davemloft.net>
---------------------------
What: read_dev_chars(), read_conf_data{,_lpm}() (s390 common I/O layer)
When: December 2007
Why: These functions are a leftover from 2.4 times. They have several
problems:
- Duplication of checks that are done in the device driver's
interrupt handler
- common I/O layer can't do device specific error recovery
- device driver can't be notified for conditions happening during
execution of the function
Device drivers should issue the read device characteristics and read
configuration data ccws and do the appropriate error handling
themselves.
Who: Cornelia Huck <cornelia.huck@de.ibm.com>
---------------------------
What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers
When: September 2007
Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific
I2C-over-GPIO drivers.
Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: drivers depending on OSS_OBSOLETE
When: options in 2.6.23, code in 2.6.25
Why: obsolete OSS drivers
Who: Adrian Bunk <bunk@stusta.de>
---------------------------

8
Documentation/filesystems/Locking
View File

@ -15,6 +15,7 @@ prototypes:
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
locking rules:
none have BKL
@ -25,6 +26,7 @@ d_compare: no yes no no
d_delete: yes no yes no
d_release: no no no yes
d_iput: no no no yes
d_dname: no no no no
--------------------------- inode_operations ---------------------------
prototypes:
@ -52,7 +54,7 @@ ata *);
locking rules:
all may block, none have BKL
i_sem(inode)
i_mutex(inode)
lookup: yes
create: yes
link: yes (both)
@ -72,7 +74,7 @@ setxattr: yes
getxattr: no
listxattr: no
removexattr: yes
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_sem on
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
victim.
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
->truncate() is never called directly - it's a callback, not a
@ -459,7 +461,7 @@ doesn't take the BKL.
->read on directories probably must go away - we should just enforce -EISDIR
in sys_read() and friends.
->fsync() has i_sem on inode.
->fsync() has i_mutex on inode.
--------------------------- dquot_operations -------------------------------
prototypes:

2
Documentation/filesystems/hpfs.txt
View File

@ -290,7 +290,7 @@ History
2.07 More fixes for Warp Server. Now it really works
2.08 Creating new files is not so slow on large disks
An attempt to sync deleted file does not generate filesystem error
2.09 Fixed error on extremly fragmented files
2.09 Fixed error on extremely fragmented files
vim: set textwidth=80:

8
Documentation/filesystems/jfs.txt
View File

@ -29,7 +29,13 @@ errors=continue Keep going on a filesystem error.
errors=remount-ro Default. Remount the filesystem read-only on an error.
errors=panic Panic and halt the machine if an error occurs.
Please send bugs, comments, cards and letters to shaggy@austin.ibm.com.
uid=value Override on-disk uid with specified value
gid=value Override on-disk gid with specified value
umask=value Override on-disk umask with specified octal value. For
directories, the execute bit will be set if the corresponding
read bit is set.
Please send bugs, comments, cards and letters to shaggy@linux.vnet.ibm.com.
The JFS mailing list can be subscribed to by using the link labeled
"Mail list Subscribe" at our web page http://jfs.sourceforge.net/

2
Documentation/filesystems/ntfs.txt
View File

@ -349,7 +349,7 @@ end of the line.
Note the "Should sync?" parameter "nosync" means that the two mirrors are
already in sync which will be the case on a clean shutdown of Windows. If the
mirrors are not clean, you can specify the "sync" option instead of "nosync"
and the Device-Mapper driver will then copy the entirey of the "Source Device"
and the Device-Mapper driver will then copy the entirety of the "Source Device"
to the "Target Device" or if you specified multipled target devices to all of
them.

40
Documentation/filesystems/proc.txt
View File

@ -122,21 +122,22 @@ subdirectory has the entries listed in Table 1-1.
Table 1-1: Process specific entries in /proc
..............................................................................
File Content
cmdline Command line arguments
cpu Current and last cpu in which it was executed (2.4)(smp)
cwd Link to the current working directory
environ Values of environment variables
exe Link to the executable of this process
fd Directory, which contains all file descriptors
maps Memory maps to executables and library files (2.4)
mem Memory held by this process
root Link to the root directory of this process
stat Process status
statm Process memory status information
status Process status in human readable form
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
smaps Extension based on maps, presenting the rss size for each mapped file
File Content
clear_refs Clears page referenced bits shown in smaps output
cmdline Command line arguments
cpu Current and last cpu in which it was executed (2.4)(smp)
cwd Link to the current working directory
environ Values of environment variables
exe Link to the executable of this process
fd Directory, which contains all file descriptors
maps Memory maps to executables and library files (2.4)
mem Memory held by this process
root Link to the root directory of this process
stat Process status
statm Process memory status information
status Process status in human readable form
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
smaps Extension based on maps, the rss size for each mapped file
..............................................................................
For example, to get the status information of a process, all you have to do is
@ -228,7 +229,7 @@ Table 1-3: Kernel info in /proc
mounts Mounted filesystems
net Networking info (see text)
partitions Table of partitions known to the system
pci Depreciated info of PCI bus (new way -> /proc/bus/pci/,
pci Deprecated info of PCI bus (new way -> /proc/bus/pci/,
decoupled by lspci (2.4)
rtc Real time clock
scsi SCSI info (see text)
@ -1137,6 +1138,13 @@ determine whether or not they are still functioning properly.
Because the NMI watchdog shares registers with oprofile, by disabling the NMI
watchdog, oprofile may have more registers to utilize.
maps_protect
------------
Enables/Disables the protection of the per-process proc entries "maps" and
"smaps". When enabled, the contents of these files are visible only to
readers that are allowed to ptrace() the given process.
2.4 /proc/sys/vm - The virtual memory subsystem
-----------------------------------------------

2
Documentation/filesystems/relay.txt
View File

@ -351,7 +351,7 @@ If the current buffer is full, i.e. all sub-buffers remain unconsumed,
the callback returns 0 to indicate that the buffer switch should not
occur yet, i.e. until the consumer has had a chance to read the
current set of ready sub-buffers. For the relay_buf_full() function
to make sense, the consumer is reponsible for notifying the relay
to make sense, the consumer is responsible for notifying the relay
interface when sub-buffers have been consumed via
relay_subbufs_consumed(). Any subsequent attempts to write into the
buffer will again invoke the subbuf_start() callback with the same

7
Documentation/filesystems/vfat.txt
View File

@ -57,6 +57,13 @@ nonumtail=<bool> -- When creating 8.3 aliases, normally the alias will
currently exist in the directory, 'longfile.txt' will
be the short alias instead of 'longfi~1.txt'.
usefree -- Use the "free clusters" value stored on FSINFO. It'll
be used to determine number of free clusters without
scanning disk. But it's not used by default, because
recent Windows don't update it correctly in some
case. If you are sure the "free clusters" on FSINFO is
correct, by this option you can avoid scanning disk.
quiet -- Stops printing certain warning messages.
check=s|r|n -- Case sensitivity checking setting.

23
Documentation/filesystems/vfs.txt
View File

@ -827,7 +827,7 @@ This describes how a filesystem can overload the standard dentry
operations. Dentries and the dcache are the domain of the VFS and the
individual filesystem implementations. Device drivers have no business
here. These methods may be set to NULL, as they are either optional or
the VFS uses a default. As of kernel 2.6.13, the following members are
the VFS uses a default. As of kernel 2.6.22, the following members are
defined:
struct dentry_operations {
@ -837,6 +837,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
char *(*d_dname)(struct dentry *, char *, int);
};
d_revalidate: called when the VFS needs to revalidate a dentry. This
@ -859,6 +860,26 @@ struct dentry_operations {
VFS calls iput(). If you define this method, you must call
iput() yourself
d_dname: called when the pathname of a dentry should be generated.
Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
pathname generation. (Instead of doing it when dentry is created,
its done only when the path is needed.). Real filesystems probably
dont want to use it, because their dentries are present in global
dcache hash, so their hash should be an invariant. As no lock is
held, d_dname() should not try to modify the dentry itself, unless
appropriate SMP safety is used. CAUTION : d_path() logic is quite
tricky. The correct way to return for example "Hello" is to put it
at the end of the buffer, and returns a pointer to the first char.
dynamic_dname() helper function is provided to take care of this.
Example :
static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
{
return dynamic_dname(dentry, buffer, buflen, "pipe:[%lu]",
dentry->d_inode->i_ino);
}
Each dentry has a pointer to its parent dentry, as well as a hash list
of child dentries. Child dentries are basically like files in a
directory.

2
Documentation/filesystems/xip.txt
View File

@ -19,7 +19,7 @@ completely. With execute-in-place, read&write type operations are performed
directly from/to the memory backed storage device. For file mappings, the
storage device itself is mapped directly into userspace.
This implementation was initialy written for shared memory segments between
This implementation was initially written for shared memory segments between
different virtual machines on s390 hardware to allow multiple machines to
share the same binaries and libraries.

2
Documentation/fujitsu/frv/gdbstub.txt
View File

@ -126,5 +126,5 @@ GDB stub and the debugger:
Furthermore, the GDB stub will intercept a number of exceptions automatically
if they are caused by kernel execution. It will also intercept BUG() macro
invokation.
invocation.

4
Documentation/gpio.txt
View File

@ -66,7 +66,9 @@ registers; another might implement it by delegating through abstractions
used for several very different kinds of GPIO controller.
That said, if the convention is supported on their platform, drivers should
use it when possible:
use it when possible. Platforms should declare GENERIC_GPIO support in
Kconfig (boolean true), which multi-platform drivers can depend on when
using the include file:
#include <asm/gpio.h>

2
Documentation/hwmon/adm1026
View File

@ -80,7 +80,7 @@ temperature sensor inputs. Both the PWM output and the DAC output can be
used to control fan speed. Usually only one of these two outputs will be
used. Write the minimum PWM or DAC value to the appropriate control
register. Then set the low temperature limit in the tmin values for each
temperature sensor. The range of control is fixed at 20 °C, and the
temperature sensor. The range of control is fixed at 20 °C, and the
largest difference between current and tmin of the temperature sensors sets
the control output. See the datasheet for several example circuits for
controlling fan speed with the PWM and DAC outputs. The fan speed sensors

36
Documentation/hwmon/coretemp Normal file
View File

@ -0,0 +1,36 @@
Kernel driver coretemp
======================
Supported chips:
* All Intel Core family
Prefix: 'coretemp'
CPUID: family 0x6, models 0xe, 0xf
Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide
Author: Rudolf Marek
Description
-----------
This driver permits reading temperature sensor embedded inside Intel Core CPU.
Temperature is measured in degrees Celsius and measurement resolution is
1 degree C. Valid temperatures are from 0 to TjMax degrees C, because
the actual value of temperature register is in fact a delta from TjMax.
Temperature known as TjMax is the maximum junction temperature of processor.
Intel defines this temperature as 85C or 100C. At this temperature, protection
mechanism will perform actions to forcibly cool down the processor. Alarm
may be raised, if the temperature grows enough (more than TjMax) to trigger
the Out-Of-Spec bit. Following table summarizes the exported sysfs files:
temp1_input - Core temperature (in millidegrees Celsius).
temp1_crit - Maximum junction temperature (in millidegrees Celsius).
temp1_crit_alarm - Set when Out-of-spec bit is set, never clears.
Correct CPU operation is no longer guaranteed.
temp1_label - Contains string "Core X", where X is processor
number.
The TjMax temperature is set to 85 degrees C if undocumented model specific
register (UMSR) 0xee has bit 30 set. If not the TjMax is 100 degrees C as
(sometimes) documented in processor datasheet.

2
Documentation/hwmon/gl518sm
View File

@ -13,7 +13,7 @@ Supported chips:
Authors:
Frodo Looijaard <frodol@dds.nl>,
Kyösti Mälkki <kmalkki@cc.hut.fi>
Kyösti Mälkki <kmalkki@cc.hut.fi>
Hong-Gunn Chew <hglinux@gunnet.org>
Jean Delvare <khali@linux-fr.org>

2
Documentation/hwmon/lm83
View File

@ -45,7 +45,7 @@ Unconfirmed motherboards:
The LM82 is confirmed to have been found on most AMD Geode reference
designs and test platforms.
The driver has been successfully tested by Magnus Forsström, who I'd
The driver has been successfully tested by Magnus Forsström, who I'd
like to thank here. More testers will be of course welcome.
The fact that the LM83 is only scarcely used can be easily explained.

53
Documentation/hwmon/max6650 Normal file
View File

@ -0,0 +1,53 @@
Kernel driver max6650
=====================
Supported chips:
* Maxim 6650 / 6651
Prefix: 'max6650'
Addresses scanned: I2C 0x1b, 0x1f, 0x48, 0x4b
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
Authors:
Hans J. Koch <hjk@linutronix.de>
John Morris <john.morris@spirentcom.com>
Claus Gindhart <claus.gindhart@kontron.com>
Description
-----------
This driver implements support for the Maxim 6650/6651
The 2 devices are very similar, but the Maxim 6550 has a reduced feature
set, e.g. only one fan-input, instead of 4 for the 6651.
The driver is not able to distinguish between the 2 devices.
The driver provides the following sensor accesses in sysfs:
fan1_input ro fan tachometer speed in RPM
fan2_input ro "
fan3_input ro "
fan4_input ro "
fan1_target rw desired fan speed in RPM (closed loop mode only)
pwm1_enable rw regulator mode, 0=full on, 1=open loop, 2=closed loop
pwm1 rw relative speed (0-255), 255=max. speed.
Used in open loop mode only.
fan1_div rw sets the speed range the inputs can handle. Legal
values are 1, 2, 4, and 8. Use lower values for
faster fans.
Module parameters
-----------------
If your board has a BIOS that initializes the MAX6650/6651 correctly, you can
simply load your module without parameters. It won't touch the configuration
registers then. If your board BIOS doesn't initialize the chip, or you want
different settings, you can set the following parameters:
voltage_12V: 5=5V fan, 12=12V fan, 0=don't change
prescaler: Possible values are 1,2,4,8,16, or 0 for don't change
clock: The clock frequency in Hz of the chip the driver should assume [254000]
Please have a look at the MAX6650/6651 data sheet and make sure that you fully
understand the meaning of these parameters before you attempt to change them.

2
Documentation/hwmon/sis5595
View File

@ -8,7 +8,7 @@ Supported chips:
Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
Authors:
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Mark D. Studebaker <mdsxyz123@yahoo.com>,
Aurelien Jarno <aurelien@aurel32.net> 2.6 port

11
Documentation/hwmon/smsc47m1
View File

@ -14,6 +14,10 @@ Supported chips:
http://www.smsc.com/main/datasheets/47m14x.pdf
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
http://www.smsc.com/main/datasheets/47m192.pdf
* SMSC LPC47M292
Addresses scanned: none, address read from Super I/O config space
Prefix: 'smsc47m2'
Datasheet: Not public
* SMSC LPC47M997
Addresses scanned: none, address read from Super I/O config space
Prefix: 'smsc47m1'
@ -32,9 +36,10 @@ Description
The Standard Microsystems Corporation (SMSC) 47M1xx Super I/O chips
contain monitoring and PWM control circuitry for two fans.
The 47M15x and 47M192 chips contain a full 'hardware monitoring block'
in addition to the fan monitoring and control. The hardware monitoring
block is not supported by the driver.
The LPC47M15x, LPC47M192 and LPC47M292 chips contain a full 'hardware
monitoring block' in addition to the fan monitoring and control. The
hardware monitoring block is not supported by this driver, use the
smsc47m192 driver for that.
No documentation is available for the 47M997, but it has the same device
ID as the 47M15x and 47M192 chips and seems to be compatible.

7
Documentation/hwmon/smsc47m192
View File

@ -2,12 +2,13 @@ Kernel driver smsc47m192
========================
Supported chips:
* SMSC LPC47M192 and LPC47M997
* SMSC LPC47M192, LPC47M15x, LPC47M292 and LPC47M997
Prefix: 'smsc47m192'
Addresses scanned: I2C 0x2c - 0x2d
Datasheet: The datasheet for LPC47M192 is publicly available from
http://www.smsc.com/
The LPC47M997 is compatible for hardware monitoring.
The LPC47M15x, LPC47M292 and LPC47M997 are compatible for
hardware monitoring.
Author: Hartmut Rick <linux@rick.claranet.de>
Special thanks to Jean Delvare for careful checking
@ -18,7 +19,7 @@ Description
-----------
This driver implements support for the hardware sensor capabilities
of the SMSC LPC47M192 and LPC47M997 Super-I/O chips.
of the SMSC LPC47M192 and compatible Super-I/O chips.
These chips support 3 temperature channels and 8 voltage inputs
as well as CPU voltage VID input.

7
Documentation/hwmon/sysfs-interface
View File

@ -152,6 +152,13 @@ fan[1-*]_div Fan divisor.
Note that this is actually an internal clock divisor, which
affects the measurable speed range, not the read value.
fan[1-*]_target
Desired fan speed
Unit: revolution/min (RPM)
RW
Only makes sense if the chip supports closed-loop fan speed
control based on the measured fan speed.
Also see the Alarms section for status flags associated with fans.

2
Documentation/hwmon/via686a
View File

@ -8,7 +8,7 @@ Supported chips:
Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/)
Authors:
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Mark D. Studebaker <mdsxyz123@yahoo.com>
Bob Dougherty <bobd@stanford.edu>
(Some conversion-factor data were contributed by

2
Documentation/hwmon/w83792d
View File

@ -107,7 +107,7 @@ Known problems:
by CR[0x49h].
- The function of vid and vrm has not been finished, because I'm NOT
very familiar with them. Adding support is welcome.
  - The function of chassis open detection needs more tests.
  - The function of chassis open detection needs more tests.
- If you have ASUS server board and chip was not found: Then you will
need to upgrade to latest (or beta) BIOS. If it does not help please
contact us.

2
Documentation/i2c/busses/i2c-i810
View File

@ -7,7 +7,7 @@ Supported adapters:
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Ralph Metzler <rjkm@thp.uni-koeln.de>,
Mark D. Studebaker <mdsxyz123@yahoo.com>

2
Documentation/i2c/busses/i2c-nforce2
View File

@ -9,6 +9,8 @@ Supported adapters:
* nForce4 MCP-04 10de:0034
* nForce4 MCP51 10de:0264
* nForce4 MCP55 10de:0368
* nForce4 MCP61 10de:03EB
* nForce4 MCP65 10de:0446
Datasheet: not publicly available, but seems to be similar to the
AMD-8111 SMBus 2.0 adapter.

2
Documentation/i2c/busses/i2c-sis96x
View File

@ -60,7 +60,7 @@ Mark D. Studebaker <mdsxyz123@yahoo.com>
- design hints and bug fixes
Alexander Maylsh <amalysh@web.de>
- ditto, plus an important datasheet... almost the one I really wanted
Hans-Günter Lütke Uphues <hg_lu@t-online.de>
Hans-Günter Lütke Uphues <hg_lu@t-online.de>
- patch for SiS735
Robert Zwerus <arzie@dds.nl>
- testing for SiS645DX

2
Documentation/i2c/busses/i2c-via
View File

@ -4,7 +4,7 @@ Supported adapters:
* VIA Technologies, InC. VT82C586B
Datasheet: Publicly available at the VIA website
Author: Kyösti Mälkki <kmalkki@cc.hut.fi>
Author: Kyösti Mälkki <kmalkki@cc.hut.fi>
Description
-----------

2
Documentation/i2c/busses/i2c-viapro
View File

@ -17,7 +17,7 @@ Supported adapters:
Datasheet: available on request and under NDA from VIA
Authors:
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Mark D. Studebaker <mdsxyz123@yahoo.com>,
Jean Delvare <khali@linux-fr.org>

2
Documentation/i2c/i2c-protocol
View File

@ -68,7 +68,7 @@ We have found some I2C devices that needs the following modifications:
Flags I2C_M_IGNORE_NAK
Normally message is interrupted immediately if there is [NA] from the
client. Setting this flag treats any [NA] as [A], and all of
client. Setting this flag treats any [NA] as [A], and all of
message is sent.
These messages may still fail to SCL lo->hi timeout.

18
Documentation/i2c/porting-clients
View File

@ -1,4 +1,4 @@
Revision 6, 2005-11-20
Revision 7, 2007-04-19
Jean Delvare <khali@linux-fr.org>
Greg KH <greg@kroah.com>
@ -20,6 +20,10 @@ yours for best results.
Technical changes:
* [Driver type] Any driver that was relying on i2c-isa has to be
converted to a proper isa, platform or pci driver. This is not
covered by this guide.
* [Includes] Get rid of "version.h" and <linux/i2c-proc.h>.
Includes typically look like that:
#include <linux/module.h>
@ -27,12 +31,10 @@ Technical changes:
#include <linux/slab.h>
#include <linux/jiffies.h>
#include <linux/i2c.h>
#include <linux/i2c-isa.h> /* for ISA drivers */
#include <linux/hwmon.h> /* for hardware monitoring drivers */
#include <linux/hwmon-sysfs.h>
#include <linux/hwmon-vid.h> /* if you need VRM support */
#include <linux/err.h> /* for class registration */
#include <asm/io.h> /* if you have I/O operations */
Please respect this inclusion order. Some extra headers may be
required for a given driver (e.g. "lm75.h").
@ -69,20 +71,16 @@ Technical changes:
sensors mailing list <lm-sensors@lm-sensors.org> by providing a
patch to the Documentation/hwmon/sysfs-interface file.
* [Attach] For I2C drivers, the attach function should make sure
that the adapter's class has I2C_CLASS_HWMON (or whatever class is
suitable for your driver), using the following construct:
* [Attach] The attach function should make sure that the adapter's
class has I2C_CLASS_HWMON (or whatever class is suitable for your
driver), using the following construct:
if (!(adapter->class & I2C_CLASS_HWMON))
return 0;
ISA-only drivers of course don't need this.
Call i2c_probe() instead of i2c_detect().
* [Detect] As mentioned earlier, the flags parameter is gone.
The type_name and client_name strings are replaced by a single
name string, which will be filled with a lowercase, short string.
In i2c-only drivers, drop the i2c_is_isa_adapter check, it's
useless. Same for isa-only drivers, as the test would always be
true. Only hybrid drivers (which are quite rare) still need it.
The labels used for error paths are reduced to the number needed.
It is advised that the labels are given descriptive names such as
exit and exit_free. Don't forget to properly set err before

29
Documentation/i2c/summary
View File

@ -4,17 +4,23 @@ I2C and SMBus
=============
I2C (pronounce: I squared C) is a protocol developed by Philips. It is a
slow two-wire protocol (10-400 kHz), but it suffices for many types of
devices.
slow two-wire protocol (variable speed, up to 400 kHz), with a high speed
extension (3.4 MHz). It provides an inexpensive bus for connecting many
types of devices with infrequent or low bandwidth communications needs.
I2C is widely used with embedded systems. Some systems use variants that
don't meet branding requirements, and so are not advertised as being I2C.
SMBus (System Management Bus) is a subset of the I2C protocol. Many
modern mainboards have a System Management Bus. There are a lot of
devices which can be connected to a SMBus; the most notable are modern
memory chips with EEPROM memories and chips for hardware monitoring.
SMBus (System Management Bus) is based on the I2C protocol, and is mostly
a subset of I2C protocols and signaling. Many I2C devices will work on an
SMBus, but some SMBus protocols add semantics beyond what is required to
achieve I2C branding. Modern PC mainboards rely on SMBus. The most common
devices connected through SMBus are RAM modules configured using I2C EEPROMs,
and hardware monitoring chips.
Because the SMBus is just a special case of the generalized I2C bus, we
can simulate the SMBus protocol on plain I2C busses. The reverse is
regretfully impossible.
Because the SMBus is mostly a subset of the generalized I2C bus, we can
use its protocols on many I2C systems. However, there are systems that don't
meet both SMBus and I2C electrical constraints; and others which can't
implement all the common SMBus protocol semantics or messages.
Terminology
@ -29,6 +35,7 @@ When we talk about I2C, we use the following terms:
An Algorithm driver contains general code that can be used for a whole class
of I2C adapters. Each specific adapter driver depends on one algorithm
driver.
A Driver driver (yes, this sounds ridiculous, sorry) contains the general
code to access some type of device. Each detected device gets its own
data in the Client structure. Usually, Driver and Client are more closely
@ -40,6 +47,10 @@ a separate Adapter and Algorithm driver), and drivers for your I2C devices
in this package. See the lm_sensors project http://www.lm-sensors.nu
for device drivers.
At this time, Linux only operates I2C (or SMBus) in master mode; you can't
use these APIs to make a Linux system behave as a slave/device, either to
speak a custom protocol or to emulate some other device.
Included Bus Drivers
====================

415
Documentation/i2c/writing-clients
View File

@ -1,5 +1,5 @@
This is a small guide for those who want to write kernel drivers for I2C
or SMBus devices.
or SMBus devices, using Linux as the protocol host/master (not slave).
To set up a driver, you need to do several things. Some are optional, and
some things can be done slightly or completely different. Use this as a
@ -29,8 +29,16 @@ static struct i2c_driver foo_driver = {
.driver = {
.name = "foo",
},
/* iff driver uses driver model ("new style") binding model: */
.probe = foo_probe,
.remove = foo_remove,
/* else, driver uses "legacy" binding model: */
.attach_adapter = foo_attach_adapter,
.detach_client = foo_detach_client,
/* these may be used regardless of the driver binding model */
.shutdown = foo_shutdown, /* optional */
.suspend = foo_suspend, /* optional */
.resume = foo_resume, /* optional */
@ -40,7 +48,8 @@ static struct i2c_driver foo_driver = {
The name field is the driver name, and must not contain spaces. It
should match the module name (if the driver can be compiled as a module),
although you can use MODULE_ALIAS (passing "foo" in this example) to add
another name for the module.
another name for the module. If the driver name doesn't match the module
name, the module won't be automatically loaded (hotplug/coldplug).
All other fields are for call-back functions which will be explained
below.
@ -65,16 +74,13 @@ An example structure is below.
struct foo_data {
struct i2c_client client;
struct semaphore lock; /* For ISA access in `sensors' drivers. */
int sysctl_id; /* To keep the /proc directory entry for
`sensors' drivers. */
enum chips type; /* To keep the chips type for `sensors' drivers. */
/* Because the i2c bus is slow, it is often useful to cache the read
information of a chip for some time (for example, 1 or 2 seconds).
It depends of course on the device whether this is really worthwhile
or even sensible. */
struct semaphore update_lock; /* When we are reading lots of information,
struct mutex update_lock; /* When we are reading lots of information,
another process should not update the
below information */
char valid; /* != 0 if the following fields are valid. */
@ -95,8 +101,7 @@ some obscure clients). But we need generic reading and writing routines.
I have found it useful to define foo_read and foo_write function for this.
For some cases, it will be easier to call the i2c functions directly,
but many chips have some kind of register-value idea that can easily
be encapsulated. Also, some chips have both ISA and I2C interfaces, and
it useful to abstract from this (only for `sensors' drivers).
be encapsulated.
The below functions are simple examples, and should not be copied
literally.
@ -119,28 +124,101 @@ literally.
return i2c_smbus_write_word_data(client,reg,value);
}
For sensors code, you may have to cope with ISA registers too. Something
like the below often works. Note the locking!
int foo_read_value(struct i2c_client *client, u8 reg)
{
int res;
if (i2c_is_isa_client(client)) {
down(&(((struct foo_data *) (client->data)) -> lock));
outb_p(reg,client->addr + FOO_ADDR_REG_OFFSET);
res = inb_p(client->addr + FOO_DATA_REG_OFFSET);
up(&(((struct foo_data *) (client->data)) -> lock));
return res;
} else
return i2c_smbus_read_byte_data(client,reg);
}
Writing is done the same way.
Probing and attaching
=====================
The Linux I2C stack was originally written to support access to hardware
monitoring chips on PC motherboards, and thus it embeds some assumptions
that are more appropriate to SMBus (and PCs) than to I2C. One of these
assumptions is that most adapters and devices drivers support the SMBUS_QUICK
protocol to probe device presence. Another is that devices and their drivers
can be sufficiently configured using only such probe primitives.
As Linux and its I2C stack became more widely used in embedded systems
and complex components such as DVB adapters, those assumptions became more
problematic. Drivers for I2C devices that issue interrupts need more (and
different) configuration information, as do drivers handling chip variants
that can't be distinguished by protocol probing, or which need some board
specific information to operate correctly.
Accordingly, the I2C stack now has two models for associating I2C devices
with their drivers: the original "legacy" model, and a newer one that's
fully compatible with the Linux 2.6 driver model. These models do not mix,
since the "legacy" model requires drivers to create "i2c_client" device
objects after SMBus style probing, while the Linux driver model expects
drivers to be given such device objects in their probe() routines.
Standard Driver Model Binding ("New Style")
-------------------------------------------
System infrastructure, typically board-specific initialization code or
boot firmware, reports what I2C devices exist. For example, there may be
a table, in the kernel or from the boot loader, identifying I2C devices
and linking them to board-specific configuration information about IRQs
and other wiring artifacts, chip type, and so on. That could be used to
create i2c_client objects for each I2C device.
I2C device drivers using this binding model work just like any other
kind of driver in Linux: they provide a probe() method to bind to
those devices, and a remove() method to unbind.
static int foo_probe(struct i2c_client *client);
static int foo_remove(struct i2c_client *client);
Remember that the i2c_driver does not create those client handles. The
handle may be used during foo_probe(). If foo_probe() reports success
(zero not a negative status code) it may save the handle and use it until
foo_remove() returns. That binding model is used by most Linux drivers.
Drivers match devices when i2c_client.driver_name and the driver name are
the same; this approach is used in several other busses that don't have
device typing support in the hardware. The driver and module name should
match, so hotplug/coldplug mechanisms will modprobe the driver.
Device Creation (Standard driver model)
---------------------------------------
If you know for a fact that an I2C device is connected to a given I2C bus,
you can instantiate that device by simply filling an i2c_board_info
structure with the device address and driver name, and calling
i2c_new_device(). This will create the device, then the driver core will
take care of finding the right driver and will call its probe() method.
If a driver supports different device types, you can specify the type you
want using the type field. You can also specify an IRQ and platform data
if needed.
Sometimes you know that a device is connected to a given I2C bus, but you
don't know the exact address it uses. This happens on TV adapters for
example, where the same driver supports dozens of slightly different
models, and I2C device addresses change from one model to the next. In
that case, you can use the i2c_new_probed_device() variant, which is
similar to i2c_new_device(), except that it takes an additional list of
possible I2C addresses to probe. A device is created for the first
responsive address in the list. If you expect more than one device to be
present in the address range, simply call i2c_new_probed_device() that
many times.
The call to i2c_new_device() or i2c_new_probed_device() typically happens
in the I2C bus driver. You may want to save the returned i2c_client
reference for later use.
Device Deletion (Standard driver model)
---------------------------------------
Each I2C device which has been created using i2c_new_device() or
i2c_new_probed_device() can be unregistered by calling
i2c_unregister_device(). If you don't call it explicitly, it will be
called automatically before the underlying I2C bus itself is removed, as a
device can't survive its parent in the device driver model.
Legacy Driver Binding Model
---------------------------
Most i2c devices can be present on several i2c addresses; for some this
is determined in hardware (by soldering some chip pins to Vcc or Ground),
for others this can be changed in software (by writing to specific client
@ -157,13 +235,9 @@ detection algorithm.
You do not have to use this parameter interface; but don't try to use
function i2c_probe() if you don't.
NOTE: If you want to write a `sensors' driver, the interface is slightly
different! See below.
Probing classes
---------------
Probing classes (Legacy model)
------------------------------
All parameters are given as lists of unsigned 16-bit integers. Lists are
terminated by I2C_CLIENT_END.
@ -210,8 +284,8 @@ Note that you *have* to call the defined variable `normal_i2c',
without any prefix!
Attaching to an adapter
-----------------------
Attaching to an adapter (Legacy model)
--------------------------------------
Whenever a new adapter is inserted, or for all adapters if the driver is
being registered, the callback attach_adapter() is called. Now is the
@ -237,17 +311,13 @@ them (unless a `force' parameter was used). In addition, addresses that
are already in use (by some other registered client) are skipped.
The detect client function
--------------------------
The detect client function (Legacy model)
-----------------------------------------
The detect client function is called by i2c_probe. The `kind' parameter
contains -1 for a probed detection, 0 for a forced detection, or a positive
number for a forced detection with a chip type forced.
Below, some things are only needed if this is a `sensors' driver. Those
parts are between /* SENSORS ONLY START */ and /* SENSORS ONLY END */
markers.
Returning an error different from -ENODEV in a detect function will cause
the detection to stop: other addresses and adapters won't be scanned.
This should only be done on fatal or internal errors, such as a memory
@ -256,64 +326,20 @@ shortage or i2c_attach_client failing.
For now, you can ignore the `flags' parameter. It is there for future use.
int foo_detect_client(struct i2c_adapter *adapter, int address,
unsigned short flags, int kind)
int kind)
{
int err = 0;
int i;
struct i2c_client *new_client;
struct i2c_client *client;
struct foo_data *data;
const char *client_name = ""; /* For non-`sensors' drivers, put the real
name here! */
const char *name = "";
/* Let's see whether this adapter can support what we need.
Please substitute the things you need here!
For `sensors' drivers, add `! is_isa &&' to the if statement */
Please substitute the things you need here! */
if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
I2C_FUNC_SMBUS_WRITE_BYTE))
goto ERROR0;
/* SENSORS ONLY START */
const char *type_name = "";
int is_isa = i2c_is_isa_adapter(adapter);
/* Do this only if the chip can additionally be found on the ISA bus
(hybrid chip). */
if (is_isa) {
/* Discard immediately if this ISA range is already used */
/* FIXME: never use check_region(), only request_region() */
if (check_region(address,FOO_EXTENT))
goto ERROR0;
/* Probe whether there is anything on this address.
Some example code is below, but you will have to adapt this
for your own driver */
if (kind < 0) /* Only if no force parameter was used */ {
/* We may need long timeouts at least for some chips. */
#define REALLY_SLOW_IO
i = inb_p(address + 1);
if (inb_p(address + 2) != i)
goto ERROR0;
if (inb_p(address + 3) != i)
goto ERROR0;
if (inb_p(address + 7) != i)
goto ERROR0;
#undef REALLY_SLOW_IO
/* Let's just hope nothing breaks here */
i = inb_p(address + 5) & 0x7f;
outb_p(~i & 0x7f,address+5);
if ((inb_p(address + 5) & 0x7f) != (~i & 0x7f)) {
outb_p(i,address+5);
return 0;
}
}
}
/* SENSORS ONLY END */
/* OK. For now, we presume we have a valid client. We now create the
client structure, even though we cannot fill it completely yet.
But it allows us to access several i2c functions safely */
@ -323,13 +349,12 @@ For now, you can ignore the `flags' parameter. It is there for future use.
goto ERROR0;
}
new_client = &data->client;
i2c_set_clientdata(new_client, data);
client = &data->client;
i2c_set_clientdata(client, data);
new_client->addr = address;
new_client->adapter = adapter;
new_client->driver = &foo_driver;
new_client->flags = 0;
client->addr = address;
client->adapter = adapter;
client->driver = &foo_driver;
/* Now, we do the remaining detection. If no `force' parameter is used. */
@ -337,19 +362,17 @@ For now, you can ignore the `flags' parameter. It is there for future use.
parameter was used. */
if (kind < 0) {
/* The below is of course bogus */
if (foo_read(new_client,FOO_REG_GENERIC) != FOO_GENERIC_VALUE)
if (foo_read(client, FOO_REG_GENERIC) != FOO_GENERIC_VALUE)
goto ERROR1;
}
/* SENSORS ONLY START */
/* Next, specific detection. This is especially important for `sensors'
devices. */
/* Determine the chip type. Not needed if a `force_CHIPTYPE' parameter
was used. */
if (kind <= 0) {
i = foo_read(new_client,FOO_REG_CHIPTYPE);
i = foo_read(client, FOO_REG_CHIPTYPE);
if (i == FOO_TYPE_1)
kind = chip1; /* As defined in the enum */
else if (i == FOO_TYPE_2)
@ -363,63 +386,31 @@ For now, you can ignore the `flags' parameter. It is there for future use.
/* Now set the type and chip names */
if (kind == chip1) {
type_name = "chip1"; /* For /proc entry */
client_name = "CHIP 1";
name = "chip1";
} else if (kind == chip2) {
type_name = "chip2"; /* For /proc entry */
client_name = "CHIP 2";
name = "chip2";
}
/* Reserve the ISA region */
if (is_isa)
request_region(address,FOO_EXTENT,type_name);
/* SENSORS ONLY END */
/* Fill in the remaining client fields. */
strcpy(new_client->name,client_name);
/* SENSORS ONLY BEGIN */
strlcpy(client->name, name, I2C_NAME_SIZE);
data->type = kind;
/* SENSORS ONLY END */
data->valid = 0; /* Only if you use this field */
init_MUTEX(&data->update_lock); /* Only if you use this field */
mutex_init(&data->update_lock); /* Only if you use this field */
/* Any other initializations in data must be done here too. */
/* Tell the i2c layer a new client has arrived */
if ((err = i2c_attach_client(new_client)))
goto ERROR3;
/* SENSORS ONLY BEGIN */
/* Register a new directory entry with module sensors. See below for
the `template' structure. */
if ((i = i2c_register_entry(new_client, type_name,
foo_dir_table_template,THIS_MODULE)) < 0) {
err = i;
goto ERROR4;
}
data->sysctl_id = i;
/* SENSORS ONLY END */
/* This function can write default values to the client registers, if
needed. */
foo_init_client(new_client);
foo_init_client(client);
/* Tell the i2c layer a new client has arrived */
if ((err = i2c_attach_client(client)))
goto ERROR1;
return 0;
/* OK, this is not exactly good programming practice, usually. But it is
very code-efficient in this case. */
ERROR4:
i2c_detach_client(new_client);
ERROR3:
ERROR2:
/* SENSORS ONLY START */
if (is_isa)
release_region(address,FOO_EXTENT);
/* SENSORS ONLY END */
ERROR1:
kfree(data);
ERROR0:
@ -427,8 +418,8 @@ For now, you can ignore the `flags' parameter. It is there for future use.
}
Removing the client
===================
Removing the client (Legacy model)
==================================
The detach_client call back function is called when a client should be
removed. It may actually fail, but only when panicking. This code is
@ -436,22 +427,12 @@ much simpler than the attachment code, fortunately!
int foo_detach_client(struct i2c_client *client)
{
int err,i;
/* SENSORS ONLY START */
/* Deregister with the `i2c-proc' module. */
i2c_deregister_entry(((struct lm78_data *)(client->data))->sysctl_id);
/* SENSORS ONLY END */
int err;
/* Try to detach the client from i2c space */
if ((err = i2c_detach_client(client)))
return err;
/* HYBRID SENSORS CHIP ONLY START */
if i2c_is_isa_client(client)
release_region(client->addr,LM78_EXTENT);
/* HYBRID SENSORS CHIP ONLY END */
kfree(i2c_get_clientdata(client));
return 0;
}
@ -464,45 +445,34 @@ When the kernel is booted, or when your foo driver module is inserted,
you have to do some initializing. Fortunately, just attaching (registering)
the driver module is usually enough.
/* Keep track of how far we got in the initialization process. If several
things have to initialized, and we fail halfway, only those things
have to be cleaned up! */
static int __initdata foo_initialized = 0;
static int __init foo_init(void)
{
int res;
printk("foo version %s (%s)\n",FOO_VERSION,FOO_DATE);
if ((res = i2c_add_driver(&foo_driver))) {
printk("foo: Driver registration failed, module not inserted.\n");
foo_cleanup();
return res;
}
foo_initialized ++;
return 0;
}
void foo_cleanup(void)
static void __exit foo_cleanup(void)
{
if (foo_initialized == 1) {
if ((res = i2c_del_driver(&foo_driver))) {
printk("foo: Driver registration failed, module not removed.\n");
return;
}
foo_initialized --;
}
i2c_del_driver(&foo_driver);
}
/* Substitute your own name and email address */
MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
/* a few non-GPL license types are also allowed */
MODULE_LICENSE("GPL");
module_init(foo_init);
module_exit(foo_cleanup);
Note that some functions are marked by `__init', and some data structures
by `__init_data'. Hose functions and structures can be removed after
by `__initdata'. These functions and structures can be removed after
kernel booting (or module loading) is completed.
@ -632,110 +602,7 @@ General purpose routines
Below all general purpose routines are listed, that were not mentioned
before.
/* This call returns a unique low identifier for each registered adapter,
* or -1 if the adapter was not registered.
/* This call returns a unique low identifier for each registered adapter.
*/
extern int i2c_adapter_id(struct i2c_adapter *adap);
The sensors sysctl/proc interface
=================================
This section only applies if you write `sensors' drivers.
Each sensors driver creates a directory in /proc/sys/dev/sensors for each
registered client. The directory is called something like foo-i2c-4-65.
The sensors module helps you to do this as easily as possible.
The template
------------
You will need to define a ctl_table template. This template will automatically
be copied to a newly allocated structure and filled in where necessary when
you call sensors_register_entry.
First, I will give an example definition.
static ctl_table foo_dir_table_template[] = {
{ FOO_SYSCTL_FUNC1, "func1", NULL, 0, 0644, NULL, &i2c_proc_real,
&i2c_sysctl_real,NULL,&foo_func },
{ FOO_SYSCTL_FUNC2, "func2", NULL, 0, 0644, NULL, &i2c_proc_real,
&i2c_sysctl_real,NULL,&foo_func },
{ FOO_SYSCTL_DATA, "data", NULL, 0, 0644, NULL, &i2c_proc_real,
&i2c_sysctl_real,NULL,&foo_data },
{ 0 }
};
In the above example, three entries are defined. They can either be
accessed through the /proc interface, in the /proc/sys/dev/sensors/*
directories, as files named func1, func2 and data, or alternatively
through the sysctl interface, in the appropriate table, with identifiers
FOO_SYSCTL_FUNC1, FOO_SYSCTL_FUNC2 and FOO_SYSCTL_DATA.
The third, sixth and ninth parameters should always be NULL, and the
fourth should always be 0. The fifth is the mode of the /proc file;
0644 is safe, as the file will be owned by root:root.
The seventh and eighth parameters should be &i2c_proc_real and
&i2c_sysctl_real if you want to export lists of reals (scaled
integers). You can also use your own function for them, as usual.
Finally, the last parameter is the call-back to gather the data
(see below) if you use the *_proc_real functions.
Gathering the data
------------------
The call back functions (foo_func and foo_data in the above example)
can be called in several ways; the operation parameter determines
what should be done:
* If operation == SENSORS_PROC_REAL_INFO, you must return the
magnitude (scaling) in nrels_mag;
* If operation == SENSORS_PROC_REAL_READ, you must read information
from the chip and return it in results. The number of integers
to display should be put in nrels_mag;
* If operation == SENSORS_PROC_REAL_WRITE, you must write the
supplied information to the chip. nrels_mag will contain the number
of integers, results the integers themselves.
The *_proc_real functions will display the elements as reals for the
/proc interface. If you set the magnitude to 2, and supply 345 for
SENSORS_PROC_REAL_READ, it would display 3.45; and if the user would
write 45.6 to the /proc file, it would be returned as 4560 for
SENSORS_PROC_REAL_WRITE. A magnitude may even be negative!
An example function:
/* FOO_FROM_REG and FOO_TO_REG translate between scaled values and
register values. Note the use of the read cache. */
void foo_in(struct i2c_client *client, int operation, int ctl_name,
int *nrels_mag, long *results)
{
struct foo_data *data = client->data;
int nr = ctl_name - FOO_SYSCTL_FUNC1; /* reduce to 0 upwards */
if (operation == SENSORS_PROC_REAL_INFO)
*nrels_mag = 2;
else if (operation == SENSORS_PROC_REAL_READ) {
/* Update the readings cache (if necessary) */
foo_update_client(client);
/* Get the readings from the cache */
results[0] = FOO_FROM_REG(data->foo_func_base[nr]);
results[1] = FOO_FROM_REG(data->foo_func_more[nr]);
results[2] = FOO_FROM_REG(data->foo_func_readonly[nr]);
*nrels_mag = 2;
} else if (operation == SENSORS_PROC_REAL_WRITE) {
if (*nrels_mag >= 1) {
/* Update the cache */
data->foo_base[nr] = FOO_TO_REG(results[0]);
/* Update the chip */
foo_write_value(client,FOO_REG_FUNC_BASE(nr),data->foo_base[nr]);
}
if (*nrels_mag >= 2) {
/* Update the cache */
data->foo_more[nr] = FOO_TO_REG(results[1]);
/* Update the chip */
foo_write_value(client,FOO_REG_FUNC_MORE(nr),data->foo_more[nr]);
}
}
}

4
Documentation/i2o/README
View File

@ -30,13 +30,13 @@ Juha Sievanen, University of Helsinki Finland
Bug fixes
Core code extensions
Auvo Häkkinen, University of Helsinki Finland
Auvo Häkkinen, University of Helsinki Finland
LAN OSM code
/Proc interface to LAN class
Bug fixes
Core code extensions
Taneli Vähäkangas, University of Helsinki Finland
Taneli Vähäkangas, University of Helsinki Finland
Fixes to i2o_config
CREDITS

122
Documentation/i386/boot.txt
View File

@ -2,7 +2,7 @@
----------------------------
H. Peter Anvin <hpa@zytor.com>
Last update 2007-01-26
Last update 2007-05-07
On the i386 platform, the Linux kernel uses a rather complicated boot
convention. This has evolved partially due to historical aspects, as
@ -11,7 +11,7 @@ bootable image, the complicated PC memory model and due to changed
expectations in the PC industry caused by the effective demise of
real-mode DOS as a mainstream operating system.
Currently, four versions of the Linux/i386 boot protocol exist.
Currently, the following versions of the Linux/i386 boot protocol exist.
Old kernels: zImage/Image support only. Some very early kernels
may not even support a command line.
@ -35,9 +35,13 @@ Protocol 2.03: (Kernel 2.4.18-pre1) Explicitly makes the highest possible
initrd address available to the bootloader.
Protocol 2.04: (Kernel 2.6.14) Extend the syssize field to four bytes.
Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable.
Introduce relocatable_kernel and kernel_alignment fields.
Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of
the boot command line
**** MEMORY LAYOUT
@ -133,6 +137,8 @@ Offset Proto Name Meaning
022C/4 2.03+ initrd_addr_max Highest legal initrd address
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
0235/3 N/A pad2 Unused
0238/4 2.06+ cmdline_size Maximum size of the kernel command line
(1) For backwards compatibility, if the setup_sects field contains 0, the
real value is 4.
@ -177,9 +183,9 @@ filled out, however:
a version number. Otherwise, enter 0xFF here.
Assigned boot loader ids:
0 LILO
0 LILO (0x00 reserved for pre-2.00 bootloader)
1 Loadlin
2 bootsect-loader
2 bootsect-loader (0x20, all other values reserved)
3 SYSLINUX
4 EtherBoot
5 ELILO
@ -204,6 +210,9 @@ filled out, however:
additional data (such as the kernel command line) moved in
addition to the real-mode kernel itself.
The unit is bytes starting with the beginning of the boot
sector.
ramdisk_image, ramdisk_size:
If your boot loader has loaded an initial ramdisk (initrd),
set ramdisk_image to the 32-bit pointer to the ramdisk data
@ -233,6 +242,12 @@ filled out, however:
if your ramdisk is exactly 131072 bytes long and this field is
0x37FFFFFF, you can start your ramdisk at 0x37FE0000.)
cmdline_size:
The maximum size of the command line without the terminating
zero. This means that the command line can contain at most
cmdline_size characters. With protocol version 2.05 and
earlier, the maximum size was 255.
**** THE KERNEL COMMAND LINE
@ -241,11 +256,10 @@ loader to communicate with the kernel. Some of its options are also
relevant to the boot loader itself, see "special command line options"
below.
The kernel command line is a null-terminated string currently up to
255 characters long, plus the final null. A string that is too long
will be automatically truncated by the kernel, a boot loader may allow
a longer command line to be passed to permit future kernels to extend
this limit.
The kernel command line is a null-terminated string. The maximum
length can be retrieved from the field cmdline_size. Before protocol
version 2.06, the maximum was 255 characters. A string that is too
long will be automatically truncated by the kernel.
If the boot protocol version is 2.02 or later, the address of the
kernel command line is given by the header field cmd_line_ptr (see
@ -267,14 +281,54 @@ command line is entered using the following protocol:
field.
**** MEMORY LAYOUT OF THE REAL-MODE CODE
The real-mode code requires a stack/heap to be set up, as well as
memory allocated for the kernel command line. This needs to be done
in the real-mode accessible memory in bottom megabyte.
It should be noted that modern machines often have a sizable Extended
BIOS Data Area (EBDA). As a result, it is advisable to use as little
of the low megabyte as possible.
Unfortunately, under the following circumstances the 0x90000 memory
segment has to be used:
- When loading a zImage kernel ((loadflags & 0x01) == 0).
- When loading a 2.01 or earlier boot protocol kernel.
-> For the 2.00 and 2.01 boot protocols, the real-mode code
can be loaded at another address, but it is internally
relocated to 0x90000. For the "old" protocol, the
real-mode code must be loaded at 0x90000.
When loading at 0x90000, avoid using memory above 0x9a000.
For boot protocol 2.02 or higher, the command line does not have to be
located in the same 64K segment as the real-mode setup code; it is
thus permitted to give the stack/heap the full 64K segment and locate
the command line above it.
The kernel command line should not be located below the real-mode
code, nor should it be located in high memory.
**** SAMPLE BOOT CONFIGURATION
As a sample configuration, assume the following layout of the real
mode segment (this is a typical, and recommended layout):
mode segment:
0x0000-0x7FFF Real mode kernel
0x8000-0x8FFF Stack and heap
0x9000-0x90FF Kernel command line
When loading below 0x90000, use the entire segment:
0x0000-0x7fff Real mode kernel
0x8000-0xdfff Stack and heap
0xe000-0xffff Kernel command line
When loading at 0x90000 OR the protocol version is 2.01 or earlier:
0x0000-0x7fff Real mode kernel
0x8000-0x97ff Stack and heap
0x9800-0x9fff Kernel command line
Such a boot loader should enter the following fields in the header:
@ -290,22 +344,33 @@ Such a boot loader should enter the following fields in the header:
ramdisk_image = <initrd_address>;
ramdisk_size = <initrd_size>;
}
if ( protocol >= 0x0202 && loadflags & 0x01 )
heap_end = 0xe000;
else
heap_end = 0x9800;
if ( protocol >= 0x0201 ) {
heap_end_ptr = 0x9000 - 0x200;
heap_end_ptr = heap_end - 0x200;
loadflags |= 0x80; /* CAN_USE_HEAP */
}
if ( protocol >= 0x0202 ) {
cmd_line_ptr = base_ptr + 0x9000;
cmd_line_ptr = base_ptr + heap_end;
strcpy(cmd_line_ptr, cmdline);
} else {
cmd_line_magic = 0xA33F;
cmd_line_offset = 0x9000;
setup_move_size = 0x9100;
cmd_line_offset = heap_end;
setup_move_size = heap_end + strlen(cmdline)+1;
strcpy(base_ptr+cmd_line_offset, cmdline);
}
} else {
/* Very old kernel */
heap_end = 0x9800;
cmd_line_magic = 0xA33F;
cmd_line_offset = 0x9000;
cmd_line_offset = heap_end;
/* A very old kernel MUST have its real-mode code
loaded at 0x90000 */
@ -313,12 +378,11 @@ Such a boot loader should enter the following fields in the header:
if ( base_ptr != 0x90000 ) {
/* Copy the real-mode kernel */
memcpy(0x90000, base_ptr, (setup_sects+1)*512);
/* Copy the command line */
memcpy(0x99000, base_ptr+0x9000, 256);
base_ptr = 0x90000; /* Relocated */
}
strcpy(0x90000+cmd_line_offset, cmdline);
/* It is recommended to clear memory up to the 32K mark */
memset(0x90000 + (setup_sects+1)*512, 0,
(64-(setup_sects+1))*512);
@ -364,10 +428,11 @@ conflict with actual kernel options now or in the future.
line is parsed.
mem=<size>
<size> is an integer in C notation optionally followed by K, M
or G (meaning << 10, << 20 or << 30). This specifies the end
of memory to the kernel. This affects the possible placement
of an initrd, since an initrd should be placed near end of
<size> is an integer in C notation optionally followed by
(case insensitive) K, M, G, T, P or E (meaning << 10, << 20,
<< 30, << 40, << 50 or << 60). This specifies the end of
memory to the kernel. This affects the possible placement of
an initrd, since an initrd should be placed near end of
memory. Note that this is an option to *both* the kernel and
the bootloader!
@ -417,7 +482,7 @@ In our example from above, we would do:
/* Set up the real-mode kernel stack */
_SS = seg;
_SP = 0x9000; /* Load SP immediately after loading SS! */
_SP = heap_end;
_DS = _ES = _FS = _GS = seg;
jmp_far(seg+0x20, 0); /* Run the kernel */
@ -449,8 +514,9 @@ IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
code32_start:
A 32-bit flat-mode routine *jumped* to immediately after the
transition to protected mode, but before the kernel is
uncompressed. No segments, except CS, are set up; you should
set them up to KERNEL_DS (0x18) yourself.
uncompressed. No segments, except CS, are guaranteed to be
set up (current kernels do, but older ones do not); you should
set them up to BOOT_DS (0x18) yourself.
After completing your hook, you should jump to the address
that was in this field before your boot loader overwrote it.

247
Documentation/ia64/aliasing-test.c Normal file
View File

@ -0,0 +1,247 @@
/*
* Exercise /dev/mem mmap cases that have been troublesome in the past
*
* (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
* Bjorn Helgaas <bjorn.helgaas@hp.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <dirent.h>
#include <fcntl.h>
#include <fnmatch.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
int sum;
int map_mem(char *path, off_t offset, size_t length, int touch)
{
int fd, rc;
void *addr;
int *c;
fd = open(path, O_RDWR);
if (fd == -1) {
perror(path);
return -1;
}
addr = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);
if (addr == MAP_FAILED)
return 1;
if (touch) {
c = (int *) addr;
while (c < (int *) (offset + length))
sum += *c++;
}
rc = munmap(addr, length);
if (rc == -1) {
perror("munmap");
return -1;
}
close(fd);
return 0;
}
int scan_sysfs(char *path, char *file, off_t offset, size_t length, int touch)
{
struct dirent **namelist;
char *name, *path2;
int i, n, r, rc, result = 0;
struct stat buf;
n = scandir(path, &namelist, 0, alphasort);
if (n < 0) {
perror("scandir");
return -1;
}
for (i = 0; i < n; i++) {
name = namelist[i]->d_name;
if (fnmatch(".", name, 0) == 0)
goto skip;
if (fnmatch("..", name, 0) == 0)
goto skip;
path2 = malloc(strlen(path) + strlen(name) + 3);
strcpy(path2, path);
strcat(path2, "/");
strcat(path2, name);
if (fnmatch(file, name, 0) == 0) {
rc = map_mem(path2, offset, length, touch);
if (rc == 0)
fprintf(stderr, "PASS: %s 0x%lx-0x%lx is %s\n", path2, offset, offset + length, touch ? "readable" : "mappable");
else if (rc > 0)
fprintf(stderr, "PASS: %s 0x%lx-0x%lx not mappable\n", path2, offset, offset + length);
else {
fprintf(stderr, "FAIL: %s 0x%lx-0x%lx not accessible\n", path2, offset, offset + length);
return rc;
}
} else {
r = lstat(path2, &buf);
if (r == 0 && S_ISDIR(buf.st_mode)) {
rc = scan_sysfs(path2, file, offset, length, touch);
if (rc < 0)
return rc;
}
}
result |= rc;
free(path2);
skip:
free(namelist[i]);
}
free(namelist);
return rc;
}
char buf[1024];
int read_rom(char *path)
{
int fd, rc;
size_t size = 0;
fd = open(path, O_RDWR);
if (fd == -1) {
perror(path);
return -1;
}
rc = write(fd, "1", 2);
if (rc <= 0) {
perror("write");
return -1;
}
do {
rc = read(fd, buf, sizeof(buf));
if (rc > 0)
size += rc;
} while (rc > 0);
close(fd);
return size;
}
int scan_rom(char *path, char *file)
{
struct dirent **namelist;
char *name, *path2;
int i, n, r, rc, result = 0;
struct stat buf;
n = scandir(path, &namelist, 0, alphasort);
if (n < 0) {
perror("scandir");
return -1;
}
for (i = 0; i < n; i++) {
name = namelist[i]->d_name;
if (fnmatch(".", name, 0) == 0)
goto skip;
if (fnmatch("..", name, 0) == 0)
goto skip;
path2 = malloc(strlen(path) + strlen(name) + 3);
strcpy(path2, path);
strcat(path2, "/");
strcat(path2, name);
if (fnmatch(file, name, 0) == 0) {
rc = read_rom(path2);
/*
* It's OK if the ROM is unreadable. Maybe there
* is no ROM, or some other error ocurred. The
* important thing is that no MCA happened.
*/
if (rc > 0)
fprintf(stderr, "PASS: %s read %ld bytes\n", path2, rc);
else {
fprintf(stderr, "PASS: %s not readable\n", path2);
return rc;
}
} else {
r = lstat(path2, &buf);
if (r == 0 && S_ISDIR(buf.st_mode)) {
rc = scan_rom(path2, file);
if (rc < 0)
return rc;
}
}
result |= rc;
free(path2);
skip:
free(namelist[i]);
}
free(namelist);
return rc;
}
main()
{
int rc;
if (map_mem("/dev/mem", 0, 0xA0000, 1) == 0)
fprintf(stderr, "PASS: /dev/mem 0x0-0xa0000 is readable\n");
else
fprintf(stderr, "FAIL: /dev/mem 0x0-0xa0000 not accessible\n");
/*
* It's not safe to blindly read the VGA frame buffer. If you know
* how to poke the card the right way, it should respond, but it's
* not safe in general. Many machines, e.g., Intel chipsets, cover
* up a non-responding card by just returning -1, but others will
* report the failure as a machine check.
*/
if (map_mem("/dev/mem", 0xA0000, 0x20000, 0) == 0)
fprintf(stderr, "PASS: /dev/mem 0xa0000-0xc0000 is mappable\n");
else
fprintf(stderr, "FAIL: /dev/mem 0xa0000-0xc0000 not accessible\n");
if (map_mem("/dev/mem", 0xC0000, 0x40000, 1) == 0)
fprintf(stderr, "PASS: /dev/mem 0xc0000-0x100000 is readable\n");
else
fprintf(stderr, "FAIL: /dev/mem 0xc0000-0x100000 not accessible\n");
/*
* Often you can map all the individual pieces above (0-0xA0000,
* 0xA0000-0xC0000, and 0xC0000-0x100000), but can't map the whole
* thing at once. This is because the individual pieces use different
* attributes, and there's no single attribute supported over the
* whole region.
*/
rc = map_mem("/dev/mem", 0, 1024*1024, 0);
if (rc == 0)
fprintf(stderr, "PASS: /dev/mem 0x0-0x100000 is mappable\n");
else if (rc > 0)
fprintf(stderr, "PASS: /dev/mem 0x0-0x100000 not mappable\n");
else
fprintf(stderr, "FAIL: /dev/mem 0x0-0x100000 not accessible\n");
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0, 0xA0000, 1);
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0xA0000, 0x20000, 0);
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0xC0000, 0x40000, 1);
scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0, 1024*1024, 0);
scan_rom("/sys/devices", "rom");
}

71
Documentation/ia64/aliasing.txt
View File

@ -112,16 +112,6 @@ POTENTIAL ATTRIBUTE ALIASING CASES
The /dev/mem mmap constraints apply.
However, since this is for mapping legacy MMIO space, WB access
does not make sense. This matters on machines without legacy
VGA support: these machines may have WB memory for the entire
first megabyte (or even the entire first granule).
On these machines, we could mmap legacy_mem as WB, which would
be safe in terms of attribute aliasing, but X has no way of
knowing that it is accessing regular memory, not a frame buffer,
so the kernel should fail the mmap rather than doing it with WB.
read/write of /dev/mem
This uses copy_from_user(), which implicitly uses a kernel
@ -138,14 +128,20 @@ POTENTIAL ATTRIBUTE ALIASING CASES
ioremap()
This returns a kernel identity mapping for use inside the
kernel.
This returns a mapping for use inside the kernel.
If the region is in kern_memmap, we should use the attribute
specified there. Otherwise, if the EFI memory map reports that
the entire granule supports WB, we should use that (granules
that are partially reserved or occupied by firmware do not appear
in kern_memmap). Otherwise, we should use a UC mapping.
specified there.
If the EFI memory map reports that the entire granule supports
WB, we should use that (granules that are partially reserved
or occupied by firmware do not appear in kern_memmap).
If the granule contains non-WB memory, but we can cover the
region safely with kernel page table mappings, we can use
ioremap_page_range() as most other architectures do.
Failing all of the above, we have to fall back to a UC mapping.
PAST PROBLEM CASES
@ -158,7 +154,7 @@ PAST PROBLEM CASES
succeed. It may create either WB or UC user mappings, depending
on whether the region is in kern_memmap or the EFI memory map.
mmap of 0x0-0xA0000 /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
See https://bugzilla.novell.com/show_bug.cgi?id=140858.
@ -171,28 +167,25 @@ PAST PROBLEM CASES
so it is safe to use WB mappings.
The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000,
which will use a granule-sized UC mapping covering 0-0xFFFFF. This
granule covers some WB-only memory, but since UC is non-speculative,
the processor will never generate an uncacheable reference to the
WB-only areas unless the driver explicitly touches them.
which uses a granule-sized UC mapping. This granule will cover some
WB-only memory, but since UC is non-speculative, the processor will
never generate an uncacheable reference to the WB-only areas unless
the driver explicitly touches them.
mmap of 0x0-0xFFFFF legacy_mem by "X"
If the EFI memory map reports this entire range as WB, there
is no VGA MMIO hole, and the mmap should fail or be done with
a WB mapping.
If the EFI memory map reports that the entire range supports the
same attributes, we can allow the mmap (and we will prefer WB if
supported, as is the case with HP sx[12]000 machines with VGA
disabled).
There's no easy way for X to determine whether the 0xA0000-0xBFFFF
region is a frame buffer or just memory, so I think it's best to
just fail this mmap request rather than using a WB mapping. As
far as I know, there's no need to map legacy_mem with WB
mappings.
If EFI reports the range as partly WB and partly UC (as on sx[12]000
machines with VGA enabled), we must fail the mmap because there's no
safe attribute to use.
Otherwise, a UC mapping of the entire region is probably safe.
The VGA hole means the region will not be in kern_memmap. The
HP sx1000 chipset doesn't support UC access to the memory surrounding
the VGA hole, but X doesn't need that area anyway and should not
reference it.
If EFI reports some of the range but not all (as on Intel firmware
that doesn't report the VGA frame buffer at all), we should fail the
mmap and force the user to map just the specific region of interest.
mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled
@ -202,6 +195,16 @@ PAST PROBLEM CASES
This is a special case of the previous case, and the mmap should
fail for the same reason as above.
read of /sys/devices/.../rom
For VGA devices, this may cause an ioremap() of 0xC0000. This
used to be done with a UC mapping, because the VGA frame buffer
at 0xA0000 prevents use of a WB granule. The UC mapping causes
an MCA on HP sx[12]000 chipsets.
We should use WB page table mappings to avoid covering the VGA
frame buffer.
NOTES
[1] SDM rev 2.2, vol 2, sec 4.4.1.

1068
Documentation/ia64/err_inject.txt Normal file
View File

File diff suppressed because it is too large Load Diff

4
Documentation/input/atarikbd.txt
View File

@ -179,9 +179,9 @@ reporting mode for joystick 1, with both buttons being logically assigned to
the mouse. After any joystick command, the ikbd assumes that joysticks are
connected to both Joystick0 and Joystick1. Any mouse command (except MOUSE
DISABLE) then causes port 0 to again be scanned as if it were a mouse, and
both buttons are logically connected to it. If a mouse diable command is
both buttons are logically connected to it. If a mouse disable command is
received while port 0 is presumed to be a mouse, the button is logically
assigned to Joystick1 ( until the mouse is reenabled by another mouse command).
assigned to Joystick1 (until the mouse is reenabled by another mouse command).
9. ikbd Command Set

125
Documentation/input/input-programming.txt
View File

@ -1,5 +1,3 @@
$Id: input-programming.txt,v 1.4 2001/05/04 09:47:14 vojtech Exp $
Programming input drivers
~~~~~~~~~~~~~~~~~~~~~~~~~
@ -20,28 +18,51 @@ pressed or released a BUTTON_IRQ happens. The driver could look like:
#include <asm/irq.h>
#include <asm/io.h>
static struct input_dev *button_dev;
static void button_interrupt(int irq, void *dummy, struct pt_regs *fp)
{
input_report_key(&button_dev, BTN_1, inb(BUTTON_PORT) & 1);
input_sync(&button_dev);
input_report_key(button_dev, BTN_1, inb(BUTTON_PORT) & 1);
input_sync(button_dev);
}
static int __init button_init(void)
{
int error;
if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
return -EBUSY;
}
button_dev.evbit[0] = BIT(EV_KEY);
button_dev.keybit[LONG(BTN_0)] = BIT(BTN_0);
input_register_device(&button_dev);
button_dev = input_allocate_device();
if (!button_dev) {
printk(KERN_ERR "button.c: Not enough memory\n");
error = -ENOMEM;
goto err_free_irq;
}
button_dev->evbit[0] = BIT(EV_KEY);
button_dev->keybit[LONG(BTN_0)] = BIT(BTN_0);
error = input_register_device(button_dev);
if (error) {
printk(KERN_ERR "button.c: Failed to register device\n");
goto err_free_dev;
}
return 0;
err_free_dev:
input_free_device(button_dev);
err_free_irq:
free_irq(BUTTON_IRQ, button_interrupt);
return error;
}
static void __exit button_exit(void)
{
input_unregister_device(&button_dev);
input_unregister_device(button_dev);
free_irq(BUTTON_IRQ, button_interrupt);
}
@ -58,17 +79,18 @@ In the _init function, which is called either upon module load or when
booting the kernel, it grabs the required resources (it should also check
for the presence of the device).
Then it sets the input bitfields. This way the device driver tells the other
Then it allocates a new input device structure with input_aloocate_device()
and sets up input bitfields. This way the device driver tells the other
parts of the input systems what it is - what events can be generated or
accepted by this input device. Our example device can only generate EV_KEY type
events, and from those only BTN_0 event code. Thus we only set these two
bits. We could have used
accepted by this input device. Our example device can only generate EV_KEY
type events, and from those only BTN_0 event code. Thus we only set these
two bits. We could have used
set_bit(EV_KEY, button_dev.evbit);
set_bit(BTN_0, button_dev.keybit);
as well, but with more than single bits the first approach tends to be
shorter.
shorter.
Then the example driver registers the input device structure by calling
@ -76,16 +98,15 @@ Then the example driver registers the input device structure by calling
This adds the button_dev structure to linked lists of the input driver and
calls device handler modules _connect functions to tell them a new input
device has appeared. Because the _connect functions may call kmalloc(,
GFP_KERNEL), which can sleep, input_register_device() must not be called
from an interrupt or with a spinlock held.
device has appeared. input_register_device() may sleep and therefore must
not be called from an interrupt or with a spinlock held.
While in use, the only used function of the driver is
button_interrupt()
which upon every interrupt from the button checks its state and reports it
via the
via the
input_report_key()
@ -113,16 +134,10 @@ can use the open and close callback to know when it can stop polling or
release the interrupt and when it must resume polling or grab the interrupt
again. To do that, we would add this to our example driver:
int button_used = 0;
static int button_open(struct input_dev *dev)
{
if (button_used++)
return 0;
if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
button_used--;
return -EBUSY;
}
@ -131,20 +146,21 @@ static int button_open(struct input_dev *dev)
static void button_close(struct input_dev *dev)
{
if (!--button_used)
free_irq(IRQ_AMIGA_VERTB, button_interrupt);
free_irq(IRQ_AMIGA_VERTB, button_interrupt);
}
static int __init button_init(void)
{
...
button_dev.open = button_open;
button_dev.close = button_close;
button_dev->open = button_open;
button_dev->close = button_close;
...
}
Note the button_used variable - we have to track how many times the open
function was called to know when exactly our device stops being used.
Note that input core keeps track of number of users for the device and
makes sure that dev->open() is called only when the first user connects
to the device and that dev->close() is called when the very last user
disconnects. Calls to both callbacks are serialized.
The open() callback should return a 0 in case of success or any nonzero value
in case of failure. The close() callback (which is void) must always succeed.
@ -175,7 +191,7 @@ set the corresponding bits and call the
input_report_rel(struct input_dev *dev, int code, int value)
function. Events are generated only for nonzero value.
function. Events are generated only for nonzero value.
However EV_ABS requires a little special care. Before calling
input_register_device, you have to fill additional fields in the input_dev
@ -187,6 +203,10 @@ the ABS_X axis:
button_dev.absfuzz[ABS_X] = 4;
button_dev.absflat[ABS_X] = 8;
Or, you can just say:
input_set_abs_params(button_dev, ABS_X, 0, 255, 4, 8);
This setting would be appropriate for a joystick X axis, with the minimum of
0, maximum of 255 (which the joystick *must* be able to reach, no problem if
it sometimes reports more, but it must be able to always reach the min and
@ -197,14 +217,7 @@ If you don't need absfuzz and absflat, you can set them to zero, which mean
that the thing is precise and always returns to exactly the center position
(if it has any).
1.4 The void *private field
~~~~~~~~~~~~~~~~~~~~~~~~~~~
This field in the input structure can be used to point to any private data
structures in the input device driver, in case the driver handles more than
one device. You'll need it in the open and close callbacks.
1.5 NBITS(), LONG(), BIT()
1.4 NBITS(), LONG(), BIT()
~~~~~~~~~~~~~~~~~~~~~~~~~~
These three macros from input.h help some bitfield computations:
@ -213,13 +226,9 @@ These three macros from input.h help some bitfield computations:
LONG(x) - returns the index in the array in longs for bit x
BIT(x) - returns the index in a long for bit x
1.6 The number, id* and name fields
1.5 The id* and name fields
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The dev->number is assigned by the input system to the input device when it
is registered. It has no use except for identifying the device to the user
in system messages.
The dev->name should be set before registering the input device by the input
device driver. It's a string like 'Generic button device' containing a
user friendly name of the device.
@ -234,15 +243,25 @@ driver.
The id and name fields can be passed to userland via the evdev interface.
1.7 The keycode, keycodemax, keycodesize fields
1.6 The keycode, keycodemax, keycodesize fields
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These two fields will be used for any input devices that report their data
as scancodes. If not all scancodes can be known by autodetection, they may
need to be set by userland utilities. The keycode array then is an array
used to map from scancodes to input system keycodes. The keycode max will
contain the size of the array and keycodesize the size of each entry in it
(in bytes).
These three fields should be used by input devices that have dense keymaps.
The keycode is an array used to map from scancodes to input system keycodes.
The keycode max should contain the size of the array and keycodesize the
size of each entry in it (in bytes).
Userspace can query and alter current scancode to keycode mappings using
EVIOCGKEYCODE and EVIOCSKEYCODE ioctls on corresponding evdev interface.
When a device has all 3 aforementioned fields filled in, the driver may
rely on kernel's default implementation of setting and querying keycode
mappings.
1.7 dev->getkeycode() and dev->setkeycode()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
getkeycode() and setkeycode() callbacks allow drivers to override default
keycode/keycodesize/keycodemax mapping mechanism provided by input core
and implement sparse keycode maps.
1.8 Key autorepeat
~~~~~~~~~~~~~~~~~~
@ -266,7 +285,7 @@ direction - from the system to the input device driver. If your input device
driver can handle these events, it has to set the respective bits in evbit,
*and* also the callback routine:
button_dev.event = button_event;
button_dev->event = button_event;
int button_event(struct input_dev *dev, unsigned int type, unsigned int code, int value);
{

6
Documentation/input/xpad.txt
View File

@ -65,15 +65,15 @@ of buttons, see section 0.3 - Unknown Controllers
I've tested this with Stepmania, and it works quite well.
0.3 Unkown Controllers
0.3 Unknown Controllers
----------------------
If you have an unkown xbox controller, it should work just fine with
If you have an unknown xbox controller, it should work just fine with
the default settings.
HOWEVER if you have an unknown dance pad not listed below, it will not
work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
PLEASE if you have an unkown controller, email Dom <binary1230@yahoo.com> with
PLEASE, if you have an unknown controller, email Dom <binary1230@yahoo.com> with
a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
whether it is a dance pad or normal controller) so that we can add your pad
to the list of supported devices, ensuring that it will work out of the

3
Documentation/ioctl-number.txt
View File

@ -138,7 +138,8 @@ Code Seq# Include File Comments
'm' 00-1F net/irda/irmod.h conflict!
'n' 00-7F linux/ncp_fs.h
'n' E0-FF video/matrox.h matroxfb
'p' 00-3F linux/mc146818rtc.h
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
'p' 00-3F linux/mc146818rtc.h conflict!
'p' 40-7F linux/nvram.h
'p' 80-9F user-space parport
<mailto:tim@cyberelk.net>

4
Documentation/isdn/CREDITS
View File

@ -2,7 +2,7 @@
I want to thank all who contributed to this project and especially to:
(in alphabetical order)
Thomas Bogendörfer (tsbogend@bigbug.franken.de)
Thomas Bogendörfer (tsbogend@bigbug.franken.de)
Tester, lots of bugfixes and hints.
Alan Cox (alan@redhat.com)
@ -11,7 +11,7 @@ Alan Cox (alan@redhat.com)
Henner Eisen (eis@baty.hanse.de)
For X.25 implementation.
Volker Götz (volker@oops.franken.de)
Volker Götz (volker@oops.franken.de)
For contribution of man-pages, the imontty-tool and a perfect
maintaining of the mailing-list at hub-wue.

2
Documentation/isdn/README
View File

@ -402,7 +402,7 @@ README for the ISDN-subsystem
the script tools/tcltk/isdnmon. You can add actions for line-status
changes. See the comments at the beginning of the script for how to
do that. There are other tty-based tools in the tools-subdirectory
contributed by Michael Knigge (imon), Volker Götz (imontty) and
contributed by Michael Knigge (imon), Volker Götz (imontty) and
Andreas Kool (isdnmon).
l) For initial testing, you can set the verbose-level to 2 (default: 0).

4
Documentation/isdn/README.icn
View File

@ -3,8 +3,8 @@ $Id: README.icn,v 1.7 2000/08/06 09:22:51 armin Exp $
You can get the ICN-ISDN-card from:
Thinking Objects Software GmbH
Versbacher Röthe 159
97078 Würzburg
Versbacher Röthe 159
97078 Würzburg
Tel: +49 931 2877950
Fax: +49 931 2877951

2
Documentation/java.txt
View File

@ -390,7 +390,7 @@ the execution bit, then just do
originally by Brian A. Lantz, brian@lantz.com
heavily edited for binfmt_misc by Richard Günther
heavily edited for binfmt_misc by Richard Günther
new scripts by Colin J. Watson <cjw44@cam.ac.uk>
added executable Jar file support by Kurt Huwig <kurt@iku-netz.de>

2
Documentation/kbuild/modules.txt
View File

@ -249,7 +249,7 @@ following files:
--> filename: Makefile
KERNELDIR := /lib/modules/`uname -r`/build
all::
$(MAKE) -C $KERNELDIR M=`pwd` $@
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
# Module specific targets
genbin:

2
Documentation/kernel-docs.txt
View File

@ -236,7 +236,7 @@
* Title: "Design and Implementation of the Second Extended
Filesystem"
Author: Rémy Card, Theodore Ts'o, Stephen Tweedie.
Author: Rémy Card, Theodore Ts'o, Stephen Tweedie.
URL: http://web.mit.edu/tytso/www/linux/ext2intro.html
Keywords: ext2, linux fs history, inode, directory, link, devices,
VFS, physical structure, performance, benchmarks, ext2fs library,

69
Documentation/kernel-parameters.txt
View File

@ -64,6 +64,7 @@ parameter is applicable:
GENERIC_TIME The generic timeofday code is enabled.
NFS Appropriate NFS support is enabled.
OSS OSS sound support is enabled.
PV_OPS A paravirtualized kernel
PARIDE The ParIDE subsystem is enabled.
PARISC The PA-RISC architecture is enabled.
PCI PCI bus support is enabled.
@ -495,6 +496,30 @@ and is between 256 and 4096 characters. It is defined in the file
Format: <area>[,<node>]
See also Documentation/networking/decnet.txt.
default_blu= [VT]
Format: <blue0>,<blue1>,<blue2>,...,<blue15>
Change the default blue palette of the console.
This is a 16-member array composed of values
ranging from 0-255.
default_grn= [VT]
Format: <green0>,<green1>,<green2>,...,<green15>
Change the default green palette of the console.
This is a 16-member array composed of values
ranging from 0-255.
default_red= [VT]
Format: <red0>,<red1>,<red2>,...,<red15>
Change the default red palette of the console.
This is a 16-member array composed of values
ranging from 0-255.
default_utf8= [VT]
Format=<0|1>
Set system-wide default UTF-8 mode for all tty's.
Default is 0 and by setting to 1, it enables UTF-8
mode for all newly opened or allocated terminals.
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
@ -695,8 +720,15 @@ and is between 256 and 4096 characters. It is defined in the file
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
See Documentation/ide.txt.
idle= [HW]
Format: idle=poll or idle=halt
idle= [X86]
Format: idle=poll or idle=mwait
Poll forces a polling idle loop that can slightly improves the performance
of waking up a idle CPU, but will use a lot of power and make the system
run hot. Not recommended.
idle=mwait. On systems which support MONITOR/MWAIT but the kernel chose
to not use it because it doesn't save as much power as a normal idle
loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same
as idle=poll.
ignore_loglevel [KNL]
Ignore loglevel setting - this will print /all/
@ -722,14 +754,6 @@ and is between 256 and 4096 characters. It is defined in the file
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
Format: <irq>
combined_mode= [HW] control which driver uses IDE ports in combined
mode: legacy IDE driver, libata, or both
(in the libata case, libata.atapi_enabled=1 may be
useful as well). Note that using the ide or libata
options may affect your device naming (e.g. by
changing hdc to sdb).
Format: combined (default), ide, or libata
inttest= [IA64]
io7= [HW] IO7 for Marvel based alpha systems
@ -808,6 +832,11 @@ and is between 256 and 4096 characters. It is defined in the file
lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip
Format: addr:<io>,irq:<irq>
legacy_serial.force [HW,IA-32,X86-64]
Probe for COM ports at legacy addresses even
if PNPBIOS or ACPI should describe them. This
is for working around firmware defects.
llsc*= [IA64] See function print_params() in
arch/ia64/sn/kernel/llsc4.c.
@ -1157,6 +1186,11 @@ and is between 256 and 4096 characters. It is defined in the file
nomce [IA-32] Machine Check Exception
noreplace-paravirt [IA-32,PV_OPS] Don't patch paravirt_ops
noreplace-smp [IA-32,SMP] Don't replace SMP instructions
with UP alternatives
noresidual [PPC] Don't use residual data on PReP machines.
noresume [SWSUSP] Disables resume and restores original swap
@ -1562,6 +1596,20 @@ and is between 256 and 4096 characters. It is defined in the file
smart2= [HW]
Format: <io1>[,<io2>[,...,<io8>]]
smp-alt-once [IA-32,SMP] On a hotplug CPU system, only
attempt to substitute SMP alternatives once at boot.
smsc-ircc2.nopnp [HW] Don't use PNP to discover SMC devices
smsc-ircc2.ircc_cfg= [HW] Device configuration I/O port
smsc-ircc2.ircc_sir= [HW] SIR base I/O port
smsc-ircc2.ircc_fir= [HW] FIR base I/O port
smsc-ircc2.ircc_irq= [HW] IRQ line
smsc-ircc2.ircc_dma= [HW] DMA channel
smsc-ircc2.ircc_transceiver= [HW] Transceiver type:
0: Toshiba Satellite 1800 (GP data pin select)
1: Fast pin select (default)
2: ATC IRMode
snd-ad1816a= [HW,ALSA]
snd-ad1848= [HW,ALSA]
@ -1820,6 +1868,7 @@ and is between 256 and 4096 characters. It is defined in the file
[USBHID] The interval which mice are to be polled at.
vdso= [IA-32,SH]
vdso=2: enable compat VDSO (default with COMPAT_VDSO)
vdso=1: enable VDSO (default)
vdso=0: disable VDSO mapping

34
Documentation/kprobes.txt
View File

@ -14,6 +14,7 @@ CONTENTS
8. Kprobes Example
9. Jprobes Example
10. Kretprobes Example
Appendix A: The kprobes debugfs interface
1. Concepts: Kprobes, Jprobes, Return Probes
@ -349,9 +350,12 @@ for instrumentation and error reporting.)
If the number of times a function is called does not match the number
of times it returns, registering a return probe on that function may
produce undesirable results. We have the do_exit() case covered.
do_execve() and do_fork() are not an issue. We're unaware of other
specific cases where this could be a problem.
produce undesirable results. In such a case, a line:
kretprobe BUG!: Processing kretprobe d000000000041aa8 @ c00000000004f48c
gets printed. With this information, one will be able to correlate the
exact instance of the kretprobe that caused the problem. We have the
do_exit() case covered. do_execve() and do_fork() are not an issue.
We're unaware of other specific cases where this could be a problem.
If, upon entry to or exit from a function, the CPU is running on
a stack other than that of the current task, registering a return
@ -614,3 +618,27 @@ http://www-106.ibm.com/developerworks/library/l-kprobes.html?ca=dgr-lnxw42Kprobe
http://www.redhat.com/magazine/005mar05/features/kprobes/
http://www-users.cs.umn.edu/~boutcher/kprobes/
http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf (pages 101-115)
Appendix A: The kprobes debugfs interface
With recent kernels (> 2.6.20) the list of registered kprobes is visible
under the /debug/kprobes/ directory (assuming debugfs is mounted at /debug).
/debug/kprobes/list: Lists all registered probes on the system
c015d71a k vfs_read+0x0
c011a316 j do_fork+0x0
c03dedc5 r tcp_v4_rcv+0x0
The first column provides the kernel address where the probe is inserted.
The second column identifies the type of probe (k - kprobe, r - kretprobe
and j - jprobe), while the third column specifies the symbol+offset of
the probe. If the probed function belongs to a module, the module name
is also specified.
/debug/kprobes/enabled: Turn kprobes ON/OFF
Provides a knob to globally turn registered kprobes ON or OFF. By default,
all kprobes are enabled. By echoing "0" to this file, all registered probes
will be disarmed, till such time a "1" is echoed to this file.

2
Documentation/kref.txt
View File

@ -67,7 +67,7 @@ void more_data_handling(void *cb_data)
.
. do stuff with data here
.
kref_put(data, data_release);
kref_put(&data->refcount, data_release);
}
int my_data_handler(void)

2
Documentation/laptop-mode.txt
View File

@ -33,7 +33,7 @@ or anything. Simply install all the files included in this document, and
laptop mode will automatically be started when you're on battery. For
your convenience, a tarball containing an installer can be downloaded at:
http://www.xs4all.nl/~bsamwel/laptop_mode/tools/
http://www.samwel.tk/laptop_mode/laptop_mode/
To configure laptop mode, you need to edit the configuration file, which is
located in /etc/default/laptop-mode on Debian-based systems, or in

2
Documentation/m68k/README.buddha
View File

@ -204,7 +204,7 @@ always shows a "no IRQ here" on the Buddha, and accesses to
the third IDE port are going into data's Nirwana on the
Buddha.
Jens Schönfeld february 19th, 1997
Jens Schönfeld february 19th, 1997
updated may 27th, 1997
eMail: sysop@nostlgic.tng.oche.de

2
Documentation/magic-number.txt
View File

@ -129,7 +129,7 @@ SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
GDA_MAGIC 0x58464552 gda include/asm-mips64/sn/gda.h
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h
EEPROM_MAGIC_VALUE 0X5ab478d2 lanai_dev drivers/atm/lanai.c
EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c
HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h
EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h
PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h

72
Documentation/md.txt
View File

@ -178,6 +178,21 @@ All md devices contain:
The size should be at least PAGE_SIZE (4k) and should be a power
of 2. This can only be set while assembling an array
layout
The "layout" for the array for the particular level. This is
simply a number that is interpretted differently by different
levels. It can be written while assembling an array.
reshape_position
This is either "none" or a sector number within the devices of
the array where "reshape" is up to. If this is set, the three
attributes mentioned above (raid_disks, chunk_size, layout) can
potentially have 2 values, an old and a new value. If these
values differ, reading the attribute returns
new (old)
and writing will effect the 'new' value, leaving the 'old'
unchanged.
component_size
For arrays with data redundancy (i.e. not raid0, linear, faulty,
multipath), all components must be the same size - or at least
@ -193,11 +208,6 @@ All md devices contain:
1.2 (newer format in varying locations) or "none" indicating that
the kernel isn't managing metadata at all.
layout
The "layout" for the array for the particular level. This is
simply a number that is interpretted differently by different
levels. It can be written while assembling an array.
resync_start
The point at which resync should start. If no resync is needed,
this will be a very large number. At array creation it will
@ -259,29 +269,6 @@ All md devices contain:
like active, but no writes have been seen for a while (safe_mode_delay).
sync_speed_min
sync_speed_max
This are similar to /proc/sys/dev/raid/speed_limit_{min,max}
however they only apply to the particular array.
If no value has been written to these, of if the word 'system'
is written, then the system-wide value is used. If a value,
in kibibytes-per-second is written, then it is used.
When the files are read, they show the currently active value
followed by "(local)" or "(system)" depending on whether it is
a locally set or system-wide value.
sync_completed
This shows the number of sectors that have been completed of
whatever the current sync_action is, followed by the number of
sectors in total that could need to be processed. The two
numbers are separated by a '/' thus effectively showing one
value, a fraction of the process that is complete.
sync_speed
This shows the current actual speed, in K/sec, of the current
sync_action. It is averaged over the last 30 seconds.
As component devices are added to an md array, they appear in the 'md'
directory as new directories named
dev-XXX
@ -412,6 +399,35 @@ also have
Note that the numbers are 'bit' numbers, not 'block' numbers.
They should be scaled by the bitmap_chunksize.
sync_speed_min
sync_speed_max
This are similar to /proc/sys/dev/raid/speed_limit_{min,max}
however they only apply to the particular array.
If no value has been written to these, of if the word 'system'
is written, then the system-wide value is used. If a value,
in kibibytes-per-second is written, then it is used.
When the files are read, they show the currently active value
followed by "(local)" or "(system)" depending on whether it is
a locally set or system-wide value.
sync_completed
This shows the number of sectors that have been completed of
whatever the current sync_action is, followed by the number of
sectors in total that could need to be processed. The two
numbers are separated by a '/' thus effectively showing one
value, a fraction of the process that is complete.
sync_speed
This shows the current actual speed, in K/sec, of the current
sync_action. It is averaged over the last 30 seconds.
suspend_lo
suspend_hi
The two values, given as numbers of sectors, indicate a range
within the array where IO will be blocked. This is currently
only supported for raid4/5/6.
Each active md device may also have attributes specific to the
personality module that manages it.
These are specific to the implementation of the module and could

54
Documentation/mips/pci/pci.README
View File

@ -1,54 +0,0 @@
Pete Popov, ppopov@pacbell.net
07/11/2001
This README briefly explains how to use the pci and pci_auto
code in arch/mips/kernel. The code was ported from PowerPC and
modified slightly. It has been tested pretty well on PPC on some
rather complex systems with multiple bridges and devices behind
each bridge. However, at the time this README was written, the
mips port was tested only on boards with a single pci bus and
no P2P bridges. It's very possible that on boards with P2P
bridges some modifications have to be made. The code will
evolve, no doubt, but currently every single mips board
is doing its own pcibios thing and it has become a big
mess. This generic pci code is meant to clean up the mips
pci mess and make it easier to add pci support to new boards.
inside the define for your board in arch/mips/config.in.
For example, the Galileo EV96100 board looks like this:
if [ "$CONFIG_MIPS_EV96100" = "y" ]; then
define_bool CONFIG_PCI y
define_bool CONFIG_MIPS_GT96100 y
define_bool CONFIG_NEW_PCI y
define_bool CONFIG_SWAP_IO_SPACE y
fi
Next, if you want to use the arch/mips/kernel/pci code, which has the
pcibios_init() function, add
define_bool CONFIG_NEW_PCI y
inside the define for your board. Again, the EV96100 example above
show NEW_PCI turned on.
Now you need to add your files to hook in your pci configuration
cycles. Usually you'll need only a couple of files named something
like pci_fixups.c and pci_ops.c. You can copy the templates
provided and fill in the code.
The file pci_ops.c should contain the pci configuration cycles routines.
It also has the mips_pci_channels[] array which contains the descriptors
of each pci controller.
The file pci_fixups.c contains a few routines to do interrupt fixups,
resources fixups, and, if needed, pci bios fixups.
Usually you'll put your pci_fixups.c file in your board specific directory,
since the functions in that file are board specific. The functions in
pci_ops.c, on the other hand, are usually pci controller specific so that
file could be shared among a few different boards using the same
pci controller.

2
Documentation/netlabel/introduction.txt
View File

@ -30,7 +30,7 @@ The communication layer exists to allow NetLabel configuration and monitoring
from user space. The NetLabel communication layer uses a message based
protocol built on top of the Generic NETLINK transport mechanism. The exact
formatting of these NetLabel messages as well as the Generic NETLINK family
names can be found in the the 'net/netlabel/' directory as comments in the
names can be found in the 'net/netlabel/' directory as comments in the
header files as well as in 'include/net/netlabel.h'.
* Security Module API

2
Documentation/networking/6pack.txt
View File

@ -1,6 +1,6 @@
This is the 6pack-mini-HOWTO, written by
Andreas Könsgen DG3KQ
Andreas Könsgen DG3KQ
Internet: ajk@iehk.rwth-aachen.de
AMPR-net: dg3kq@db0pra.ampr.org
AX.25: dg3kq@db0ach.#nrw.deu.eu

2
Documentation/networking/NAPI_HOWTO.txt
View File

@ -160,7 +160,7 @@ on current cpu. This primitive is called by dev->poll(), when
it completes its work. The device cannot be out of poll list at this
call, if it is then clearly it is a BUG(). You'll know ;->
All these above nethods are used below. So keep reading for clarity.
All of the above methods are used below, so keep reading for clarity.
Device driver changes to be made when porting NAPI
==================================================

2
Documentation/networking/packet_mmap.txt
View File

@ -13,7 +13,7 @@ You can find the latest version of this document at
Please send me your comments to
Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
-------------------------------------------------------------------------------
+ Why use PACKET_MMAP

2
Documentation/networking/slicecom.hun
View File

@ -1,7 +1,7 @@
SliceCOM adapter felhasznaloi dokumentacioja - 0.51 verziohoz
Bartók István <bartoki@itc.hu>
Bartók István <bartoki@itc.hu>
Utolso modositas: Wed Aug 29 17:26:58 CEST 2001
-----------------------------------------------------------------

4
Documentation/networking/slicecom.txt
View File

@ -1,9 +1,9 @@
SliceCOM adapter user's documentation - for the 0.51 driver version
Written by Bartók István <bartoki@itc.hu>
Written by Bartók István <bartoki@itc.hu>
English translation: Lakatos György <gyuri@itc.hu>
English translation: Lakatos György <gyuri@itc.hu>
Mon Dec 11 15:28:42 CET 2000
Last modified: Wed Aug 29 17:25:37 CEST 2001

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