aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/ABI/testing/sysfs-bus-pci43
-rw-r--r--Documentation/ABI/testing/sysfs-firmware-memmap2
-rw-r--r--Documentation/Changes4
-rw-r--r--Documentation/CodingStyle18
-rw-r--r--Documentation/DMA-API.txt2
-rw-r--r--Documentation/DocBook/Makefile2
-rw-r--r--Documentation/DocBook/device-drivers.tmpl418
-rw-r--r--Documentation/DocBook/kernel-api.tmpl377
-rw-r--r--Documentation/DocBook/uio-howto.tmpl88
-rw-r--r--Documentation/IO-mapping.txt4
-rw-r--r--Documentation/PCI/PCIEBUS-HOWTO.txt2
-rw-r--r--Documentation/block/biodoc.txt11
-rw-r--r--Documentation/block/queue-sysfs.txt63
-rw-r--r--Documentation/cgroups/cgroups.txt6
-rw-r--r--Documentation/cgroups/cpusets.txt65
-rw-r--r--Documentation/cgroups/memcg_test.txt24
-rw-r--r--Documentation/connector/cn_test.c6
-rw-r--r--Documentation/cpu-freq/user-guide.txt16
-rw-r--r--Documentation/driver-model/device.txt8
-rw-r--r--Documentation/dvb/README.flexcop205
-rw-r--r--Documentation/dvb/technisat.txt34
-rw-r--r--Documentation/filesystems/nfs-rdma.txt4
-rw-r--r--Documentation/filesystems/proc.txt28
-rw-r--r--Documentation/filesystems/sysfs-pci.txt13
-rw-r--r--Documentation/filesystems/sysfs.txt50
-rw-r--r--Documentation/filesystems/ubifs.txt7
-rw-r--r--Documentation/hwmon/hpfall.c101
-rw-r--r--Documentation/hwmon/lis3lv02d8
-rw-r--r--Documentation/ja_JP/stable_kernel_rules.txt15
-rw-r--r--Documentation/kbuild/kbuild.txt29
-rw-r--r--Documentation/kernel-doc-nano-HOWTO.txt7
-rw-r--r--Documentation/kernel-parameters.txt21
-rw-r--r--Documentation/laptops/thinkpad-acpi.txt25
-rw-r--r--Documentation/lguest/Makefile2
-rw-r--r--Documentation/networking/alias.txt25
-rw-r--r--Documentation/networking/netconsole.txt3
-rw-r--r--Documentation/powerpc/dts-bindings/fsl/mpc5200.txt180
-rw-r--r--Documentation/powerpc/mpc52xx-device-tree-bindings.txt277
-rw-r--r--Documentation/scsi/cxgb3i.txt11
-rw-r--r--Documentation/sound/alsa/HD-Audio-Models.txt1
-rw-r--r--Documentation/tracers/mmiotrace.txt6
-rw-r--r--Documentation/usb/dma.txt11
-rw-r--r--Documentation/video4linux/v4lgrab.c25
43 files changed, 1187 insertions, 1060 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index ceddcff4082a..e638e15a8895 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -1,3 +1,46 @@
1What: /sys/bus/pci/drivers/.../bind
2Date: December 2003
3Contact: linux-pci@vger.kernel.org
4Description:
5 Writing a device location to this file will cause
6 the driver to attempt to bind to the device found at
7 this location. This is useful for overriding default
8 bindings. The format for the location is: DDDD:BB:DD.F.
9 That is Domain:Bus:Device.Function and is the same as
10 found in /sys/bus/pci/devices/. For example:
11 # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind
12 (Note: kernels before 2.6.28 may require echo -n).
13
14What: /sys/bus/pci/drivers/.../unbind
15Date: December 2003
16Contact: linux-pci@vger.kernel.org
17Description:
18 Writing a device location to this file will cause the
19 driver to attempt to unbind from the device found at
20 this location. This may be useful when overriding default
21 bindings. The format for the location is: DDDD:BB:DD.F.
22 That is Domain:Bus:Device.Function and is the same as
23 found in /sys/bus/pci/devices/. For example:
24 # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
25 (Note: kernels before 2.6.28 may require echo -n).
26
27What: /sys/bus/pci/drivers/.../new_id
28Date: December 2003
29Contact: linux-pci@vger.kernel.org
30Description:
31 Writing a device ID to this file will attempt to
32 dynamically add a new device ID to a PCI device driver.
33 This may allow the driver to support more hardware than
34 was included in the driver's static device ID support
35 table at compile time. The format for the device ID is:
36 VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID,
37 Device ID, Subsystem Vendor ID, Subsystem Device ID,
38 Class, Class Mask, and Private Driver Data. The Vendor ID
39 and Device ID fields are required, the rest are optional.
40 Upon successfully adding an ID, the driver will probe
41 for the device and attempt to bind to it. For example:
42 # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
43
1What: /sys/bus/pci/devices/.../vpd 44What: /sys/bus/pci/devices/.../vpd
2Date: February 2008 45Date: February 2008
3Contact: Ben Hutchings <bhutchings@solarflare.com> 46Contact: Ben Hutchings <bhutchings@solarflare.com>
diff --git a/Documentation/ABI/testing/sysfs-firmware-memmap b/Documentation/ABI/testing/sysfs-firmware-memmap
index 0d99ee6ae02e..eca0d65087dc 100644
--- a/Documentation/ABI/testing/sysfs-firmware-memmap
+++ b/Documentation/ABI/testing/sysfs-firmware-memmap
@@ -1,6 +1,6 @@
1What: /sys/firmware/memmap/ 1What: /sys/firmware/memmap/
2Date: June 2008 2Date: June 2008
3Contact: Bernhard Walle <bwalle@suse.de> 3Contact: Bernhard Walle <bernhard.walle@gmx.de>
4Description: 4Description:
5 On all platforms, the firmware provides a memory map which the 5 On all platforms, the firmware provides a memory map which the
6 kernel reads. The resources from that memory map are registered 6 kernel reads. The resources from that memory map are registered
diff --git a/Documentation/Changes b/Documentation/Changes
index cb2b141b1c3e..b95082be4d5e 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -33,10 +33,12 @@ o Gnu make 3.79.1 # make --version
33o binutils 2.12 # ld -v 33o binutils 2.12 # ld -v
34o util-linux 2.10o # fdformat --version 34o util-linux 2.10o # fdformat --version
35o module-init-tools 0.9.10 # depmod -V 35o module-init-tools 0.9.10 # depmod -V
36o e2fsprogs 1.29 # tune2fs 36o e2fsprogs 1.41.4 # e2fsck -V
37o jfsutils 1.1.3 # fsck.jfs -V 37o jfsutils 1.1.3 # fsck.jfs -V
38o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs 38o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
39o xfsprogs 2.6.0 # xfs_db -V 39o xfsprogs 2.6.0 # xfs_db -V
40o squashfs-tools 4.0 # mksquashfs -version
41o btrfs-progs 0.18 # btrfsck
40o pcmciautils 004 # pccardctl -V 42o pcmciautils 004 # pccardctl -V
41o quota-tools 3.09 # quota -V 43o quota-tools 3.09 # quota -V
42o PPP 2.4.0 # pppd --version 44o PPP 2.4.0 # pppd --version
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 1875e502f872..72968cd5eaf3 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -483,17 +483,25 @@ values. To do the latter, you can stick the following in your .emacs file:
483 (* (max steps 1) 483 (* (max steps 1)
484 c-basic-offset))) 484 c-basic-offset)))
485 485
486(add-hook 'c-mode-common-hook
487 (lambda ()
488 ;; Add kernel style
489 (c-add-style
490 "linux-tabs-only"
491 '("linux" (c-offsets-alist
492 (arglist-cont-nonempty
493 c-lineup-gcc-asm-reg
494 c-lineup-arglist-tabs-only))))))
495
486(add-hook 'c-mode-hook 496(add-hook 'c-mode-hook
487 (lambda () 497 (lambda ()
488 (let ((filename (buffer-file-name))) 498 (let ((filename (buffer-file-name)))
489 ;; Enable kernel mode for the appropriate files 499 ;; Enable kernel mode for the appropriate files
490 (when (and filename 500 (when (and filename
491 (string-match "~/src/linux-trees" filename)) 501 (string-match (expand-file-name "~/src/linux-trees")
502 filename))
492 (setq indent-tabs-mode t) 503 (setq indent-tabs-mode t)
493 (c-set-style "linux") 504 (c-set-style "linux-tabs-only")))))
494 (c-set-offset 'arglist-cont-nonempty
495 '(c-lineup-gcc-asm-reg
496 c-lineup-arglist-tabs-only))))))
497 505
498This will make emacs go better with the kernel coding style for C 506This will make emacs go better with the kernel coding style for C
499files below ~/src/linux-trees. 507files below ~/src/linux-trees.
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 52441694fe03..2a3fcc55e981 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -5,7 +5,7 @@
5 5
6This document describes the DMA API. For a more gentle introduction 6This document describes the DMA API. For a more gentle introduction
7phrased in terms of the pci_ equivalents (and actual examples) see 7phrased in terms of the pci_ equivalents (and actual examples) see
8DMA-mapping.txt 8Documentation/PCI/PCI-DMA-mapping.txt.
9 9
10This API is split into two pieces. Part I describes the API and the 10This API is split into two pieces. Part I describes the API and the
11corresponding pci_ API. Part II describes the extensions to the API 11corresponding pci_ API. Part II describes the extensions to the API
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index dc3154e49279..1462ed86d40a 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -6,7 +6,7 @@
6# To add a new book the only step required is to add the book to the 6# To add a new book the only step required is to add the book to the
7# list of DOCBOOKS. 7# list of DOCBOOKS.
8 8
9DOCBOOKS := z8530book.xml mcabook.xml \ 9DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
10 kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ 10 kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
11 procfs-guide.xml writing_usb_driver.xml networking.xml \ 11 procfs-guide.xml writing_usb_driver.xml networking.xml \
12 kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ 12 kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
new file mode 100644
index 000000000000..94a20fe8fedf
--- /dev/null
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -0,0 +1,418 @@
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
4
5<book id="LinuxDriversAPI">
6 <bookinfo>
7 <title>Linux Device Drivers</title>
8
9 <legalnotice>
10 <para>
11 This documentation is free software; you can redistribute
12 it and/or modify it under the terms of the GNU General Public
13 License as published by the Free Software Foundation; either
14 version 2 of the License, or (at your option) any later
15 version.
16 </para>
17
18 <para>
19 This program is distributed in the hope that it will be
20 useful, but WITHOUT ANY WARRANTY; without even the implied
21 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
22 See the GNU General Public License for more details.
23 </para>
24
25 <para>
26 You should have received a copy of the GNU General Public
27 License along with this program; if not, write to the Free
28 Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
29 MA 02111-1307 USA
30 </para>
31
32 <para>
33 For more details see the file COPYING in the source
34 distribution of Linux.
35 </para>
36 </legalnotice>
37 </bookinfo>
38
39<toc></toc>
40
41 <chapter id="Basics">
42 <title>Driver Basics</title>
43 <sect1><title>Driver Entry and Exit points</title>
44!Iinclude/linux/init.h
45 </sect1>
46
47 <sect1><title>Atomic and pointer manipulation</title>
48!Iarch/x86/include/asm/atomic_32.h
49!Iarch/x86/include/asm/unaligned.h
50 </sect1>
51
52 <sect1><title>Delaying, scheduling, and timer routines</title>
53!Iinclude/linux/sched.h
54!Ekernel/sched.c
55!Ekernel/timer.c
56 </sect1>
57 <sect1><title>High-resolution timers</title>
58!Iinclude/linux/ktime.h
59!Iinclude/linux/hrtimer.h
60!Ekernel/hrtimer.c
61 </sect1>
62 <sect1><title>Workqueues and Kevents</title>
63!Ekernel/workqueue.c
64 </sect1>
65 <sect1><title>Internal Functions</title>
66!Ikernel/exit.c
67!Ikernel/signal.c
68!Iinclude/linux/kthread.h
69!Ekernel/kthread.c
70 </sect1>
71
72 <sect1><title>Kernel objects manipulation</title>
73<!--
74X!Iinclude/linux/kobject.h
75-->
76!Elib/kobject.c
77 </sect1>
78
79 <sect1><title>Kernel utility functions</title>
80!Iinclude/linux/kernel.h
81!Ekernel/printk.c
82!Ekernel/panic.c
83!Ekernel/sys.c
84!Ekernel/rcupdate.c
85 </sect1>
86
87 <sect1><title>Device Resource Management</title>
88!Edrivers/base/devres.c
89 </sect1>
90
91 </chapter>
92
93 <chapter id="devdrivers">
94 <title>Device drivers infrastructure</title>
95 <sect1><title>Device Drivers Base</title>
96<!--
97X!Iinclude/linux/device.h
98-->
99!Edrivers/base/driver.c
100!Edrivers/base/core.c
101!Edrivers/base/class.c
102!Edrivers/base/firmware_class.c
103!Edrivers/base/transport_class.c
104<!-- Cannot be included, because
105 attribute_container_add_class_device_adapter
106 and attribute_container_classdev_to_container
107 exceed allowed 44 characters maximum
108X!Edrivers/base/attribute_container.c
109-->
110!Edrivers/base/sys.c
111<!--
112X!Edrivers/base/interface.c
113-->
114!Edrivers/base/platform.c
115!Edrivers/base/bus.c
116 </sect1>
117 <sect1><title>Device Drivers Power Management</title>
118!Edrivers/base/power/main.c
119 </sect1>
120 <sect1><title>Device Drivers ACPI Support</title>
121<!-- Internal functions only
122X!Edrivers/acpi/sleep/main.c
123X!Edrivers/acpi/sleep/wakeup.c
124X!Edrivers/acpi/motherboard.c
125X!Edrivers/acpi/bus.c
126-->
127!Edrivers/acpi/scan.c
128!Idrivers/acpi/scan.c
129<!-- No correct structured comments
130X!Edrivers/acpi/pci_bind.c
131-->
132 </sect1>
133 <sect1><title>Device drivers PnP support</title>
134!Idrivers/pnp/core.c
135<!-- No correct structured comments
136X!Edrivers/pnp/system.c
137 -->
138!Edrivers/pnp/card.c
139!Idrivers/pnp/driver.c
140!Edrivers/pnp/manager.c
141!Edrivers/pnp/support.c
142 </sect1>
143 <sect1><title>Userspace IO devices</title>
144!Edrivers/uio/uio.c
145!Iinclude/linux/uio_driver.h
146 </sect1>
147 </chapter>
148
149 <chapter id="parportdev">
150 <title>Parallel Port Devices</title>
151!Iinclude/linux/parport.h
152!Edrivers/parport/ieee1284.c
153!Edrivers/parport/share.c
154!Idrivers/parport/daisy.c
155 </chapter>
156
157 <chapter id="message_devices">
158 <title>Message-based devices</title>
159 <sect1><title>Fusion message devices</title>
160!Edrivers/message/fusion/mptbase.c
161!Idrivers/message/fusion/mptbase.c
162!Edrivers/message/fusion/mptscsih.c
163!Idrivers/message/fusion/mptscsih.c
164!Idrivers/message/fusion/mptctl.c
165!Idrivers/message/fusion/mptspi.c
166!Idrivers/message/fusion/mptfc.c
167!Idrivers/message/fusion/mptlan.c
168 </sect1>
169 <sect1><title>I2O message devices</title>
170!Iinclude/linux/i2o.h
171!Idrivers/message/i2o/core.h
172!Edrivers/message/i2o/iop.c
173!Idrivers/message/i2o/iop.c
174!Idrivers/message/i2o/config-osm.c
175!Edrivers/message/i2o/exec-osm.c
176!Idrivers/message/i2o/exec-osm.c
177!Idrivers/message/i2o/bus-osm.c
178!Edrivers/message/i2o/device.c
179!Idrivers/message/i2o/device.c
180!Idrivers/message/i2o/driver.c
181!Idrivers/message/i2o/pci.c
182!Idrivers/message/i2o/i2o_block.c
183!Idrivers/message/i2o/i2o_scsi.c
184!Idrivers/message/i2o/i2o_proc.c
185 </sect1>
186 </chapter>
187
188 <chapter id="snddev">
189 <title>Sound Devices</title>
190!Iinclude/sound/core.h
191!Esound/sound_core.c
192!Iinclude/sound/pcm.h
193!Esound/core/pcm.c
194!Esound/core/device.c
195!Esound/core/info.c
196!Esound/core/rawmidi.c
197!Esound/core/sound.c
198!Esound/core/memory.c
199!Esound/core/pcm_memory.c
200!Esound/core/init.c
201!Esound/core/isadma.c
202!Esound/core/control.c
203!Esound/core/pcm_lib.c
204!Esound/core/hwdep.c
205!Esound/core/pcm_native.c
206!Esound/core/memalloc.c
207<!-- FIXME: Removed for now since no structured comments in source
208X!Isound/sound_firmware.c
209-->
210 </chapter>
211
212 <chapter id="uart16x50">
213 <title>16x50 UART Driver</title>
214!Iinclude/linux/serial_core.h
215!Edrivers/serial/serial_core.c
216!Edrivers/serial/8250.c
217 </chapter>
218
219 <chapter id="fbdev">
220 <title>Frame Buffer Library</title>
221
222 <para>
223 The frame buffer drivers depend heavily on four data structures.
224 These structures are declared in include/linux/fb.h. They are
225 fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs.
226 The last three can be made available to and from userland.
227 </para>
228
229 <para>
230 fb_info defines the current state of a particular video card.
231 Inside fb_info, there exists a fb_ops structure which is a
232 collection of needed functions to make fbdev and fbcon work.
233 fb_info is only visible to the kernel.
234 </para>
235
236 <para>
237 fb_var_screeninfo is used to describe the features of a video card
238 that are user defined. With fb_var_screeninfo, things such as
239 depth and the resolution may be defined.
240 </para>
241
242 <para>
243 The next structure is fb_fix_screeninfo. This defines the
244 properties of a card that are created when a mode is set and can't
245 be changed otherwise. A good example of this is the start of the
246 frame buffer memory. This "locks" the address of the frame buffer
247 memory, so that it cannot be changed or moved.
248 </para>
249
250 <para>
251 The last structure is fb_monospecs. In the old API, there was
252 little importance for fb_monospecs. This allowed for forbidden things
253 such as setting a mode of 800x600 on a fix frequency monitor. With
254 the new API, fb_monospecs prevents such things, and if used
255 correctly, can prevent a monitor from being cooked. fb_monospecs
256 will not be useful until kernels 2.5.x.
257 </para>
258
259 <sect1><title>Frame Buffer Memory</title>
260!Edrivers/video/fbmem.c
261 </sect1>
262<!--
263 <sect1><title>Frame Buffer Console</title>
264X!Edrivers/video/console/fbcon.c
265 </sect1>
266-->
267 <sect1><title>Frame Buffer Colormap</title>
268!Edrivers/video/fbcmap.c
269 </sect1>
270<!-- FIXME:
271 drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment
272 out until somebody adds docs. KAO
273 <sect1><title>Frame Buffer Generic Functions</title>
274X!Idrivers/video/fbgen.c
275 </sect1>
276KAO -->
277 <sect1><title>Frame Buffer Video Mode Database</title>
278!Idrivers/video/modedb.c
279!Edrivers/video/modedb.c
280 </sect1>
281 <sect1><title>Frame Buffer Macintosh Video Mode Database</title>
282!Edrivers/video/macmodes.c
283 </sect1>
284 <sect1><title>Frame Buffer Fonts</title>
285 <para>
286 Refer to the file drivers/video/console/fonts.c for more information.
287 </para>
288<!-- FIXME: Removed for now since no structured comments in source
289X!Idrivers/video/console/fonts.c
290-->
291 </sect1>
292 </chapter>
293
294 <chapter id="input_subsystem">
295 <title>Input Subsystem</title>
296!Iinclude/linux/input.h
297!Edrivers/input/input.c
298!Edrivers/input/ff-core.c
299!Edrivers/input/ff-memless.c
300 </chapter>
301
302 <chapter id="spi">
303 <title>Serial Peripheral Interface (SPI)</title>
304 <para>
305 SPI is the "Serial Peripheral Interface", widely used with
306 embedded systems because it is a simple and efficient
307 interface: basically a multiplexed shift register.
308 Its three signal wires hold a clock (SCK, often in the range
309 of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and
310 a "Master In, Slave Out" (MISO) data line.
311 SPI is a full duplex protocol; for each bit shifted out the
312 MOSI line (one per clock) another is shifted in on the MISO line.
313 Those bits are assembled into words of various sizes on the
314 way to and from system memory.
315 An additional chipselect line is usually active-low (nCS);
316 four signals are normally used for each peripheral, plus
317 sometimes an interrupt.
318 </para>
319 <para>
320 The SPI bus facilities listed here provide a generalized
321 interface to declare SPI busses and devices, manage them
322 according to the standard Linux driver model, and perform
323 input/output operations.
324 At this time, only "master" side interfaces are supported,
325 where Linux talks to SPI peripherals and does not implement
326 such a peripheral itself.
327 (Interfaces to support implementing SPI slaves would
328 necessarily look different.)
329 </para>
330 <para>
331 The programming interface is structured around two kinds of driver,
332 and two kinds of device.
333 A "Controller Driver" abstracts the controller hardware, which may
334 be as simple as a set of GPIO pins or as complex as a pair of FIFOs
335 connected to dual DMA engines on the other side of the SPI shift
336 register (maximizing throughput). Such drivers bridge between
337 whatever bus they sit on (often the platform bus) and SPI, and
338 expose the SPI side of their device as a
339 <structname>struct spi_master</structname>.
340 SPI devices are children of that master, represented as a
341 <structname>struct spi_device</structname> and manufactured from
342 <structname>struct spi_board_info</structname> descriptors which
343 are usually provided by board-specific initialization code.
344 A <structname>struct spi_driver</structname> is called a
345 "Protocol Driver", and is bound to a spi_device using normal
346 driver model calls.
347 </para>
348 <para>
349 The I/O model is a set of queued messages. Protocol drivers
350 submit one or more <structname>struct spi_message</structname>
351 objects, which are processed and completed asynchronously.
352 (There are synchronous wrappers, however.) Messages are
353 built from one or more <structname>struct spi_transfer</structname>
354 objects, each of which wraps a full duplex SPI transfer.
355 A variety of protocol tweaking options are needed, because
356 different chips adopt very different policies for how they
357 use the bits transferred with SPI.
358 </para>
359!Iinclude/linux/spi/spi.h
360!Fdrivers/spi/spi.c spi_register_board_info
361!Edrivers/spi/spi.c
362 </chapter>
363
364 <chapter id="i2c">
365 <title>I<superscript>2</superscript>C and SMBus Subsystem</title>
366
367 <para>
368 I<superscript>2</superscript>C (or without fancy typography, "I2C")
369 is an acronym for the "Inter-IC" bus, a simple bus protocol which is
370 widely used where low data rate communications suffice.
371 Since it's also a licensed trademark, some vendors use another
372 name (such as "Two-Wire Interface", TWI) for the same bus.
373 I2C only needs two signals (SCL for clock, SDA for data), conserving
374 board real estate and minimizing signal quality issues.
375 Most I2C devices use seven bit addresses, and bus speeds of up
376 to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
377 found wide use.
378 I2C is a multi-master bus; open drain signaling is used to
379 arbitrate between masters, as well as to handshake and to
380 synchronize clocks from slower clients.
381 </para>
382
383 <para>
384 The Linux I2C programming interfaces support only the master
385 side of bus interactions, not the slave side.
386 The programming interface is structured around two kinds of driver,
387 and two kinds of device.
388 An I2C "Adapter Driver" abstracts the controller hardware; it binds
389 to a physical device (perhaps a PCI device or platform_device) and
390 exposes a <structname>struct i2c_adapter</structname> representing
391 each I2C bus segment it manages.
392 On each I2C bus segment will be I2C devices represented by a
393 <structname>struct i2c_client</structname>. Those devices will
394 be bound to a <structname>struct i2c_driver</structname>,
395 which should follow the standard Linux driver model.
396 (At this writing, a legacy model is more widely used.)
397 There are functions to perform various I2C protocol operations; at
398 this writing all such functions are usable only from task context.
399 </para>
400
401 <para>
402 The System Management Bus (SMBus) is a sibling protocol. Most SMBus
403 systems are also I2C conformant. The electrical constraints are
404 tighter for SMBus, and it standardizes particular protocol messages
405 and idioms. Controllers that support I2C can also support most
406 SMBus operations, but SMBus controllers don't support all the protocol
407 options that an I2C controller will.
408 There are functions to perform various SMBus protocol operations,
409 either using I2C primitives or by issuing SMBus commands to
410 i2c_adapter devices which don't support those I2C operations.
411 </para>
412
413!Iinclude/linux/i2c.h
414!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
415!Edrivers/i2c/i2c-core.c
416 </chapter>
417
418</book>
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index 5818ff75786a..bc962cda6504 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -38,58 +38,6 @@
38 38
39<toc></toc> 39<toc></toc>
40 40
41 <chapter id="Basics">
42 <title>Driver Basics</title>
43 <sect1><title>Driver Entry and Exit points</title>
44!Iinclude/linux/init.h
45 </sect1>
46
47 <sect1><title>Atomic and pointer manipulation</title>
48!Iarch/x86/include/asm/atomic_32.h
49!Iarch/x86/include/asm/unaligned.h
50 </sect1>
51
52 <sect1><title>Delaying, scheduling, and timer routines</title>
53!Iinclude/linux/sched.h
54!Ekernel/sched.c
55!Ekernel/timer.c
56 </sect1>
57 <sect1><title>High-resolution timers</title>
58!Iinclude/linux/ktime.h
59!Iinclude/linux/hrtimer.h
60!Ekernel/hrtimer.c
61 </sect1>
62 <sect1><title>Workqueues and Kevents</title>
63!Ekernel/workqueue.c
64 </sect1>
65 <sect1><title>Internal Functions</title>
66!Ikernel/exit.c
67!Ikernel/signal.c
68!Iinclude/linux/kthread.h
69!Ekernel/kthread.c
70 </sect1>
71
72 <sect1><title>Kernel objects manipulation</title>
73<!--
74X!Iinclude/linux/kobject.h
75-->
76!Elib/kobject.c
77 </sect1>
78
79 <sect1><title>Kernel utility functions</title>
80!Iinclude/linux/kernel.h
81!Ekernel/printk.c
82!Ekernel/panic.c
83!Ekernel/sys.c
84!Ekernel/rcupdate.c
85 </sect1>
86
87 <sect1><title>Device Resource Management</title>
88!Edrivers/base/devres.c
89 </sect1>
90
91 </chapter>
92
93 <chapter id="adt"> 41 <chapter id="adt">
94 <title>Data Types</title> 42 <title>Data Types</title>
95 <sect1><title>Doubly Linked Lists</title> 43 <sect1><title>Doubly Linked Lists</title>
@@ -298,62 +246,6 @@ X!Earch/x86/kernel/mca_32.c
298!Ikernel/acct.c 246!Ikernel/acct.c
299 </chapter> 247 </chapter>
300 248
301 <chapter id="devdrivers">
302 <title>Device drivers infrastructure</title>
303 <sect1><title>Device Drivers Base</title>
304<!--
305X!Iinclude/linux/device.h
306-->
307!Edrivers/base/driver.c
308!Edrivers/base/core.c
309!Edrivers/base/class.c
310!Edrivers/base/firmware_class.c
311!Edrivers/base/transport_class.c
312<!-- Cannot be included, because
313 attribute_container_add_class_device_adapter
314 and attribute_container_classdev_to_container
315 exceed allowed 44 characters maximum
316X!Edrivers/base/attribute_container.c
317-->
318!Edrivers/base/sys.c
319<!--
320X!Edrivers/base/interface.c
321-->
322!Edrivers/base/platform.c
323!Edrivers/base/bus.c
324 </sect1>
325 <sect1><title>Device Drivers Power Management</title>
326!Edrivers/base/power/main.c
327 </sect1>
328 <sect1><title>Device Drivers ACPI Support</title>
329<!-- Internal functions only
330X!Edrivers/acpi/sleep/main.c
331X!Edrivers/acpi/sleep/wakeup.c
332X!Edrivers/acpi/motherboard.c
333X!Edrivers/acpi/bus.c
334-->
335!Edrivers/acpi/scan.c
336!Idrivers/acpi/scan.c
337<!-- No correct structured comments
338X!Edrivers/acpi/pci_bind.c
339-->
340 </sect1>
341 <sect1><title>Device drivers PnP support</title>
342!Idrivers/pnp/core.c
343<!-- No correct structured comments
344X!Edrivers/pnp/system.c
345 -->
346!Edrivers/pnp/card.c
347!Idrivers/pnp/driver.c
348!Edrivers/pnp/manager.c
349!Edrivers/pnp/support.c
350 </sect1>
351 <sect1><title>Userspace IO devices</title>
352!Edrivers/uio/uio.c
353!Iinclude/linux/uio_driver.h
354 </sect1>
355 </chapter>
356
357 <chapter id="blkdev"> 249 <chapter id="blkdev">
358 <title>Block Devices</title> 250 <title>Block Devices</title>
359!Eblock/blk-core.c 251!Eblock/blk-core.c
@@ -381,275 +273,6 @@ X!Edrivers/pnp/system.c
381!Edrivers/char/misc.c 273!Edrivers/char/misc.c
382 </chapter> 274 </chapter>
383 275
384 <chapter id="parportdev">
385 <title>Parallel Port Devices</title>
386!Iinclude/linux/parport.h
387!Edrivers/parport/ieee1284.c
388!Edrivers/parport/share.c
389!Idrivers/parport/daisy.c
390 </chapter>
391
392 <chapter id="message_devices">
393 <title>Message-based devices</title>
394 <sect1><title>Fusion message devices</title>
395!Edrivers/message/fusion/mptbase.c
396!Idrivers/message/fusion/mptbase.c
397!Edrivers/message/fusion/mptscsih.c
398!Idrivers/message/fusion/mptscsih.c
399!Idrivers/message/fusion/mptctl.c
400!Idrivers/message/fusion/mptspi.c
401!Idrivers/message/fusion/mptfc.c
402!Idrivers/message/fusion/mptlan.c
403 </sect1>
404 <sect1><title>I2O message devices</title>
405!Iinclude/linux/i2o.h
406!Idrivers/message/i2o/core.h
407!Edrivers/message/i2o/iop.c
408!Idrivers/message/i2o/iop.c
409!Idrivers/message/i2o/config-osm.c
410!Edrivers/message/i2o/exec-osm.c
411!Idrivers/message/i2o/exec-osm.c
412!Idrivers/message/i2o/bus-osm.c
413!Edrivers/message/i2o/device.c
414!Idrivers/message/i2o/device.c
415!Idrivers/message/i2o/driver.c
416!Idrivers/message/i2o/pci.c
417!Idrivers/message/i2o/i2o_block.c
418!Idrivers/message/i2o/i2o_scsi.c
419!Idrivers/message/i2o/i2o_proc.c
420 </sect1>
421 </chapter>
422
423 <chapter id="snddev">
424 <title>Sound Devices</title>
425!Iinclude/sound/core.h
426!Esound/sound_core.c
427!Iinclude/sound/pcm.h
428!Esound/core/pcm.c
429!Esound/core/device.c
430!Esound/core/info.c
431!Esound/core/rawmidi.c
432!Esound/core/sound.c
433!Esound/core/memory.c
434!Esound/core/pcm_memory.c
435!Esound/core/init.c
436!Esound/core/isadma.c
437!Esound/core/control.c
438!Esound/core/pcm_lib.c
439!Esound/core/hwdep.c
440!Esound/core/pcm_native.c
441!Esound/core/memalloc.c
442<!-- FIXME: Removed for now since no structured comments in source
443X!Isound/sound_firmware.c
444-->
445 </chapter>
446
447 <chapter id="uart16x50">
448 <title>16x50 UART Driver</title>
449!Iinclude/linux/serial_core.h
450!Edrivers/serial/serial_core.c
451!Edrivers/serial/8250.c
452 </chapter>
453
454 <chapter id="fbdev">
455 <title>Frame Buffer Library</title>
456
457 <para>
458 The frame buffer drivers depend heavily on four data structures.
459 These structures are declared in include/linux/fb.h. They are
460 fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs.
461 The last three can be made available to and from userland.
462 </para>
463
464 <para>
465 fb_info defines the current state of a particular video card.
466 Inside fb_info, there exists a fb_ops structure which is a
467 collection of needed functions to make fbdev and fbcon work.
468 fb_info is only visible to the kernel.
469 </para>
470
471 <para>
472 fb_var_screeninfo is used to describe the features of a video card
473 that are user defined. With fb_var_screeninfo, things such as
474 depth and the resolution may be defined.
475 </para>
476
477 <para>
478 The next structure is fb_fix_screeninfo. This defines the
479 properties of a card that are created when a mode is set and can't
480 be changed otherwise. A good example of this is the start of the
481 frame buffer memory. This "locks" the address of the frame buffer
482 memory, so that it cannot be changed or moved.
483 </para>
484
485 <para>
486 The last structure is fb_monospecs. In the old API, there was
487 little importance for fb_monospecs. This allowed for forbidden things
488 such as setting a mode of 800x600 on a fix frequency monitor. With
489 the new API, fb_monospecs prevents such things, and if used
490 correctly, can prevent a monitor from being cooked. fb_monospecs
491 will not be useful until kernels 2.5.x.
492 </para>
493
494 <sect1><title>Frame Buffer Memory</title>
495!Edrivers/video/fbmem.c
496 </sect1>
497<!--
498 <sect1><title>Frame Buffer Console</title>
499X!Edrivers/video/console/fbcon.c
500 </sect1>
501-->
502 <sect1><title>Frame Buffer Colormap</title>
503!Edrivers/video/fbcmap.c
504 </sect1>
505<!-- FIXME:
506 drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment
507 out until somebody adds docs. KAO
508 <sect1><title>Frame Buffer Generic Functions</title>
509X!Idrivers/video/fbgen.c
510 </sect1>
511KAO -->
512 <sect1><title>Frame Buffer Video Mode Database</title>
513!Idrivers/video/modedb.c
514!Edrivers/video/modedb.c
515 </sect1>
516 <sect1><title>Frame Buffer Macintosh Video Mode Database</title>
517!Edrivers/video/macmodes.c
518 </sect1>
519 <sect1><title>Frame Buffer Fonts</title>
520 <para>
521 Refer to the file drivers/video/console/fonts.c for more information.
522 </para>
523<!-- FIXME: Removed for now since no structured comments in source
524X!Idrivers/video/console/fonts.c
525-->
526 </sect1>
527 </chapter>
528
529 <chapter id="input_subsystem">
530 <title>Input Subsystem</title>
531!Iinclude/linux/input.h
532!Edrivers/input/input.c
533!Edrivers/input/ff-core.c
534!Edrivers/input/ff-memless.c
535 </chapter>
536
537 <chapter id="spi">
538 <title>Serial Peripheral Interface (SPI)</title>
539 <para>
540 SPI is the "Serial Peripheral Interface", widely used with
541 embedded systems because it is a simple and efficient
542 interface: basically a multiplexed shift register.
543 Its three signal wires hold a clock (SCK, often in the range
544 of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and
545 a "Master In, Slave Out" (MISO) data line.
546 SPI is a full duplex protocol; for each bit shifted out the
547 MOSI line (one per clock) another is shifted in on the MISO line.
548 Those bits are assembled into words of various sizes on the
549 way to and from system memory.
550 An additional chipselect line is usually active-low (nCS);
551 four signals are normally used for each peripheral, plus
552 sometimes an interrupt.
553 </para>
554 <para>
555 The SPI bus facilities listed here provide a generalized
556 interface to declare SPI busses and devices, manage them
557 according to the standard Linux driver model, and perform
558 input/output operations.
559 At this time, only "master" side interfaces are supported,
560 where Linux talks to SPI peripherals and does not implement
561 such a peripheral itself.
562 (Interfaces to support implementing SPI slaves would
563 necessarily look different.)
564 </para>
565 <para>
566 The programming interface is structured around two kinds of driver,
567 and two kinds of device.
568 A "Controller Driver" abstracts the controller hardware, which may
569 be as simple as a set of GPIO pins or as complex as a pair of FIFOs
570 connected to dual DMA engines on the other side of the SPI shift
571 register (maximizing throughput). Such drivers bridge between
572 whatever bus they sit on (often the platform bus) and SPI, and
573 expose the SPI side of their device as a
574 <structname>struct spi_master</structname>.
575 SPI devices are children of that master, represented as a
576 <structname>struct spi_device</structname> and manufactured from
577 <structname>struct spi_board_info</structname> descriptors which
578 are usually provided by board-specific initialization code.
579 A <structname>struct spi_driver</structname> is called a
580 "Protocol Driver", and is bound to a spi_device using normal
581 driver model calls.
582 </para>
583 <para>
584 The I/O model is a set of queued messages. Protocol drivers
585 submit one or more <structname>struct spi_message</structname>
586 objects, which are processed and completed asynchronously.
587 (There are synchronous wrappers, however.) Messages are
588 built from one or more <structname>struct spi_transfer</structname>
589 objects, each of which wraps a full duplex SPI transfer.
590 A variety of protocol tweaking options are needed, because
591 different chips adopt very different policies for how they
592 use the bits transferred with SPI.
593 </para>
594!Iinclude/linux/spi/spi.h
595!Fdrivers/spi/spi.c spi_register_board_info
596!Edrivers/spi/spi.c
597 </chapter>
598
599 <chapter id="i2c">
600 <title>I<superscript>2</superscript>C and SMBus Subsystem</title>
601
602 <para>
603 I<superscript>2</superscript>C (or without fancy typography, "I2C")
604 is an acronym for the "Inter-IC" bus, a simple bus protocol which is
605 widely used where low data rate communications suffice.
606 Since it's also a licensed trademark, some vendors use another
607 name (such as "Two-Wire Interface", TWI) for the same bus.
608 I2C only needs two signals (SCL for clock, SDA for data), conserving
609 board real estate and minimizing signal quality issues.
610 Most I2C devices use seven bit addresses, and bus speeds of up
611 to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
612 found wide use.
613 I2C is a multi-master bus; open drain signaling is used to
614 arbitrate between masters, as well as to handshake and to
615 synchronize clocks from slower clients.
616 </para>
617
618 <para>
619 The Linux I2C programming interfaces support only the master
620 side of bus interactions, not the slave side.
621 The programming interface is structured around two kinds of driver,
622 and two kinds of device.
623 An I2C "Adapter Driver" abstracts the controller hardware; it binds
624 to a physical device (perhaps a PCI device or platform_device) and
625 exposes a <structname>struct i2c_adapter</structname> representing
626 each I2C bus segment it manages.
627 On each I2C bus segment will be I2C devices represented by a
628 <structname>struct i2c_client</structname>. Those devices will
629 be bound to a <structname>struct i2c_driver</structname>,
630 which should follow the standard Linux driver model.
631 (At this writing, a legacy model is more widely used.)
632 There are functions to perform various I2C protocol operations; at
633 this writing all such functions are usable only from task context.
634 </para>
635
636 <para>
637 The System Management Bus (SMBus) is a sibling protocol. Most SMBus
638 systems are also I2C conformant. The electrical constraints are
639 tighter for SMBus, and it standardizes particular protocol messages
640 and idioms. Controllers that support I2C can also support most
641 SMBus operations, but SMBus controllers don't support all the protocol
642 options that an I2C controller will.
643 There are functions to perform various SMBus protocol operations,
644 either using I2C primitives or by issuing SMBus commands to
645 i2c_adapter devices which don't support those I2C operations.
646 </para>
647
648!Iinclude/linux/i2c.h
649!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
650!Edrivers/i2c/i2c-core.c
651 </chapter>
652
653 <chapter id="clk"> 276 <chapter id="clk">
654 <title>Clock Framework</title> 277 <title>Clock Framework</title>
655 278
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index b787e4721c90..52e1b79ce0e6 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -42,6 +42,12 @@ GPL version 2.
42 42
43<revhistory> 43<revhistory>
44 <revision> 44 <revision>
45 <revnumber>0.7</revnumber>
46 <date>2008-12-23</date>
47 <authorinitials>hjk</authorinitials>
48 <revremark>Added generic platform drivers and offset attribute.</revremark>
49 </revision>
50 <revision>
45 <revnumber>0.6</revnumber> 51 <revnumber>0.6</revnumber>
46 <date>2008-12-05</date> 52 <date>2008-12-05</date>
47 <authorinitials>hjk</authorinitials> 53 <authorinitials>hjk</authorinitials>
@@ -312,6 +318,16 @@ interested in translating it, please email me
312 pointed to by addr. 318 pointed to by addr.
313 </para> 319 </para>
314</listitem> 320</listitem>
321<listitem>
322 <para>
323 <filename>offset</filename>: The offset, in bytes, that has to be
324 added to the pointer returned by <function>mmap()</function> to get
325 to the actual device memory. This is important if the device's memory
326 is not page aligned. Remember that pointers returned by
327 <function>mmap()</function> are always page aligned, so it is good
328 style to always add this offset.
329 </para>
330</listitem>
315</itemizedlist> 331</itemizedlist>
316 332
317<para> 333<para>
@@ -594,6 +610,78 @@ framework to set up sysfs files for this region. Simply leave it alone.
594 </para> 610 </para>
595</sect1> 611</sect1>
596 612
613<sect1 id="using_uio_pdrv">
614<title>Using uio_pdrv for platform devices</title>
615 <para>
616 In many cases, UIO drivers for platform devices can be handled in a
617 generic way. In the same place where you define your
618 <varname>struct platform_device</varname>, you simply also implement
619 your interrupt handler and fill your
620 <varname>struct uio_info</varname>. A pointer to this
621 <varname>struct uio_info</varname> is then used as
622 <varname>platform_data</varname> for your platform device.
623 </para>
624 <para>
625 You also need to set up an array of <varname>struct resource</varname>
626 containing addresses and sizes of your memory mappings. This
627 information is passed to the driver using the
628 <varname>.resource</varname> and <varname>.num_resources</varname>
629 elements of <varname>struct platform_device</varname>.
630 </para>
631 <para>
632 You now have to set the <varname>.name</varname> element of
633 <varname>struct platform_device</varname> to
634 <varname>"uio_pdrv"</varname> to use the generic UIO platform device
635 driver. This driver will fill the <varname>mem[]</varname> array
636 according to the resources given, and register the device.
637 </para>
638 <para>
639 The advantage of this approach is that you only have to edit a file
640 you need to edit anyway. You do not have to create an extra driver.
641 </para>
642</sect1>
643
644<sect1 id="using_uio_pdrv_genirq">
645<title>Using uio_pdrv_genirq for platform devices</title>
646 <para>
647 Especially in embedded devices, you frequently find chips where the
648 irq pin is tied to its own dedicated interrupt line. In such cases,
649 where you can be really sure the interrupt is not shared, we can take
650 the concept of <varname>uio_pdrv</varname> one step further and use a
651 generic interrupt handler. That's what
652 <varname>uio_pdrv_genirq</varname> does.
653 </para>
654 <para>
655 The setup for this driver is the same as described above for
656 <varname>uio_pdrv</varname>, except that you do not implement an
657 interrupt handler. The <varname>.handler</varname> element of
658 <varname>struct uio_info</varname> must remain
659 <varname>NULL</varname>. The <varname>.irq_flags</varname> element
660 must not contain <varname>IRQF_SHARED</varname>.
661 </para>
662 <para>
663 You will set the <varname>.name</varname> element of
664 <varname>struct platform_device</varname> to
665 <varname>"uio_pdrv_genirq"</varname> to use this driver.
666 </para>
667 <para>
668 The generic interrupt handler of <varname>uio_pdrv_genirq</varname>
669 will simply disable the interrupt line using
670 <function>disable_irq_nosync()</function>. After doing its work,
671 userspace can reenable the interrupt by writing 0x00000001 to the UIO
672 device file. The driver already implements an
673 <function>irq_control()</function> to make this possible, you must not
674 implement your own.
675 </para>
676 <para>
677 Using <varname>uio_pdrv_genirq</varname> not only saves a few lines of
678 interrupt handler code. You also do not need to know anything about
679 the chip's internal registers to create the kernel part of the driver.
680 All you need to know is the irq number of the pin the chip is
681 connected to.
682 </para>
683</sect1>
684
597</chapter> 685</chapter>
598 686
599<chapter id="userspace_driver" xreflabel="Writing a driver in user space"> 687<chapter id="userspace_driver" xreflabel="Writing a driver in user space">
diff --git a/Documentation/IO-mapping.txt b/Documentation/IO-mapping.txt
index 86edb61bdee6..78a440695e11 100644
--- a/Documentation/IO-mapping.txt
+++ b/Documentation/IO-mapping.txt
@@ -1,6 +1,6 @@
1[ NOTE: The virt_to_bus() and bus_to_virt() functions have been 1[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
2 superseded by the functionality provided by the PCI DMA 2 superseded by the functionality provided by the PCI DMA interface
3 interface (see Documentation/DMA-mapping.txt). They continue 3 (see Documentation/PCI/PCI-DMA-mapping.txt). They continue
4 to be documented below for historical purposes, but new code 4 to be documented below for historical purposes, but new code
5 must not use them. --davidm 00/12/12 ] 5 must not use them. --davidm 00/12/12 ]
6 6
diff --git a/Documentation/PCI/PCIEBUS-HOWTO.txt b/Documentation/PCI/PCIEBUS-HOWTO.txt
index 9a07e38631b0..6bd5f372adec 100644
--- a/Documentation/PCI/PCIEBUS-HOWTO.txt
+++ b/Documentation/PCI/PCIEBUS-HOWTO.txt
@@ -93,7 +93,7 @@ the PCI Express Port Bus driver from loading a service driver.
93 93
94int pcie_port_service_register(struct pcie_port_service_driver *new) 94int pcie_port_service_register(struct pcie_port_service_driver *new)
95 95
96This API replaces the Linux Driver Model's pci_module_init API. A 96This API replaces the Linux Driver Model's pci_register_driver API. A
97service driver should always calls pcie_port_service_register at 97service driver should always calls pcie_port_service_register at
98module init. Note that after service driver being loaded, calls 98module init. Note that after service driver being loaded, calls
99such as pci_enable_device(dev) and pci_set_master(dev) are no longer 99such as pci_enable_device(dev) and pci_set_master(dev) are no longer
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 3c5434c83daf..ecad6ee75705 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -186,8 +186,9 @@ a virtual address mapping (unlike the earlier scheme of virtual address
186do not have a corresponding kernel virtual address space mapping) and 186do not have a corresponding kernel virtual address space mapping) and
187low-memory pages. 187low-memory pages.
188 188
189Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA 189Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
190aspects and mapping of scatter gather lists, and support for 64 bit PCI. 190on PCI high mem DMA aspects and mapping of scatter gather lists, and support
191for 64 bit PCI.
191 192
192Special handling is required only for cases where i/o needs to happen on 193Special handling is required only for cases where i/o needs to happen on
193pages at physical memory addresses beyond what the device can support. In these 194pages at physical memory addresses beyond what the device can support. In these
@@ -953,14 +954,14 @@ elevator_allow_merge_fn called whenever the block layer determines
953 results in some sort of conflict internally, 954 results in some sort of conflict internally,
954 this hook allows it to do that. 955 this hook allows it to do that.
955 956
956elevator_dispatch_fn fills the dispatch queue with ready requests. 957elevator_dispatch_fn* fills the dispatch queue with ready requests.
957 I/O schedulers are free to postpone requests by 958 I/O schedulers are free to postpone requests by
958 not filling the dispatch queue unless @force 959 not filling the dispatch queue unless @force
959 is non-zero. Once dispatched, I/O schedulers 960 is non-zero. Once dispatched, I/O schedulers
960 are not allowed to manipulate the requests - 961 are not allowed to manipulate the requests -
961 they belong to generic dispatch queue. 962 they belong to generic dispatch queue.
962 963
963elevator_add_req_fn called to add a new request into the scheduler 964elevator_add_req_fn* called to add a new request into the scheduler
964 965
965elevator_queue_empty_fn returns true if the merge queue is empty. 966elevator_queue_empty_fn returns true if the merge queue is empty.
966 Drivers shouldn't use this, but rather check 967 Drivers shouldn't use this, but rather check
@@ -990,7 +991,7 @@ elevator_activate_req_fn Called when device driver first sees a request.
990elevator_deactivate_req_fn Called when device driver decides to delay 991elevator_deactivate_req_fn Called when device driver decides to delay
991 a request by requeueing it. 992 a request by requeueing it.
992 993
993elevator_init_fn 994elevator_init_fn*
994elevator_exit_fn Allocate and free any elevator specific storage 995elevator_exit_fn Allocate and free any elevator specific storage
995 for a queue. 996 for a queue.
996 997
diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt
new file mode 100644
index 000000000000..e164403f60e1
--- /dev/null
+++ b/Documentation/block/queue-sysfs.txt
@@ -0,0 +1,63 @@
1Queue sysfs files
2=================
3
4This text file will detail the queue files that are located in the sysfs tree
5for each block device. Note that stacked devices typically do not export
6any settings, since their queue merely functions are a remapping target.
7These files are the ones found in the /sys/block/xxx/queue/ directory.
8
9Files denoted with a RO postfix are readonly and the RW postfix means
10read-write.
11
12hw_sector_size (RO)
13-------------------
14This is the hardware sector size of the device, in bytes.
15
16max_hw_sectors_kb (RO)
17----------------------
18This is the maximum number of kilobytes supported in a single data transfer.
19
20max_sectors_kb (RW)
21-------------------
22This is the maximum number of kilobytes that the block layer will allow
23for a filesystem request. Must be smaller than or equal to the maximum
24size allowed by the hardware.
25
26nomerges (RW)
27-------------
28This enables the user to disable the lookup logic involved with IO merging
29requests in the block layer. Merging may still occur through a direct
301-hit cache, since that comes for (almost) free. The IO scheduler will not
31waste cycles doing tree/hash lookups for merges if nomerges is 1. Defaults
32to 0, enabling all merges.
33
34nr_requests (RW)
35----------------
36This controls how many requests may be allocated in the block layer for
37read or write requests. Note that the total allocated number may be twice
38this amount, since it applies only to reads or writes (not the accumulated
39sum).
40
41read_ahead_kb (RW)
42------------------
43Maximum number of kilobytes to read-ahead for filesystems on this block
44device.
45
46rq_affinity (RW)
47----------------
48If this option is enabled, the block layer will migrate request completions
49to the CPU that originally submitted the request. For some workloads
50this provides a significant reduction in CPU cycles due to caching effects.
51
52scheduler (RW)
53--------------
54When read, this file will display the current and available IO schedulers
55for this block device. The currently active IO scheduler will be enclosed
56in [] brackets. Writing an IO scheduler name to this file will switch
57control of this block device to that new IO scheduler. Note that writing
58an IO scheduler name to this file will attempt to load that IO scheduler
59module, if it isn't already present in the system.
60
61
62
63Jens Axboe <jens.axboe@oracle.com>, February 2009
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index d9e5d6f41b92..93feb8444489 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -252,10 +252,8 @@ cgroup file system directories.
252When a task is moved from one cgroup to another, it gets a new 252When a task is moved from one cgroup to another, it gets a new
253css_set pointer - if there's an already existing css_set with the 253css_set pointer - if there's an already existing css_set with the
254desired collection of cgroups then that group is reused, else a new 254desired collection of cgroups then that group is reused, else a new
255css_set is allocated. Note that the current implementation uses a 255css_set is allocated. The appropriate existing css_set is located by
256linear search to locate an appropriate existing css_set, so isn't 256looking into a hash table.
257very efficient. A future version will use a hash table for better
258performance.
259 257
260To allow access from a cgroup to the css_sets (and hence tasks) 258To allow access from a cgroup to the css_sets (and hence tasks)
261that comprise it, a set of cg_cgroup_link objects form a lattice; 259that comprise it, a set of cg_cgroup_link objects form a lattice;
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt
index 5c86c258c791..0611e9528c7c 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -142,7 +142,7 @@ into the rest of the kernel, none in performance critical paths:
142 - in fork and exit, to attach and detach a task from its cpuset. 142 - in fork and exit, to attach and detach a task from its cpuset.
143 - in sched_setaffinity, to mask the requested CPUs by what's 143 - in sched_setaffinity, to mask the requested CPUs by what's
144 allowed in that tasks cpuset. 144 allowed in that tasks cpuset.
145 - in sched.c migrate_all_tasks(), to keep migrating tasks within 145 - in sched.c migrate_live_tasks(), to keep migrating tasks within
146 the CPUs allowed by their cpuset, if possible. 146 the CPUs allowed by their cpuset, if possible.
147 - in the mbind and set_mempolicy system calls, to mask the requested 147 - in the mbind and set_mempolicy system calls, to mask the requested
148 Memory Nodes by what's allowed in that tasks cpuset. 148 Memory Nodes by what's allowed in that tasks cpuset.
@@ -175,6 +175,10 @@ files describing that cpuset:
175 - mem_exclusive flag: is memory placement exclusive? 175 - mem_exclusive flag: is memory placement exclusive?
176 - mem_hardwall flag: is memory allocation hardwalled 176 - mem_hardwall flag: is memory allocation hardwalled
177 - memory_pressure: measure of how much paging pressure in cpuset 177 - memory_pressure: measure of how much paging pressure in cpuset
178 - memory_spread_page flag: if set, spread page cache evenly on allowed nodes
179 - memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes
180 - sched_load_balance flag: if set, load balance within CPUs on that cpuset
181 - sched_relax_domain_level: the searching range when migrating tasks
178 182
179In addition, the root cpuset only has the following file: 183In addition, the root cpuset only has the following file:
180 - memory_pressure_enabled flag: compute memory_pressure? 184 - memory_pressure_enabled flag: compute memory_pressure?
@@ -252,7 +256,7 @@ is causing.
252 256
253This is useful both on tightly managed systems running a wide mix of 257This is useful both on tightly managed systems running a wide mix of
254submitted jobs, which may choose to terminate or re-prioritize jobs that 258submitted jobs, which may choose to terminate or re-prioritize jobs that
255are trying to use more memory than allowed on the nodes assigned them, 259are trying to use more memory than allowed on the nodes assigned to them,
256and with tightly coupled, long running, massively parallel scientific 260and with tightly coupled, long running, massively parallel scientific
257computing jobs that will dramatically fail to meet required performance 261computing jobs that will dramatically fail to meet required performance
258goals if they start to use more memory than allowed to them. 262goals if they start to use more memory than allowed to them.
@@ -378,7 +382,7 @@ as cpusets and sched_setaffinity.
378The algorithmic cost of load balancing and its impact on key shared 382The algorithmic cost of load balancing and its impact on key shared
379kernel data structures such as the task list increases more than 383kernel data structures such as the task list increases more than
380linearly with the number of CPUs being balanced. So the scheduler 384linearly with the number of CPUs being balanced. So the scheduler
381has support to partition the systems CPUs into a number of sched 385has support to partition the systems CPUs into a number of sched
382domains such that it only load balances within each sched domain. 386domains such that it only load balances within each sched domain.
383Each sched domain covers some subset of the CPUs in the system; 387Each sched domain covers some subset of the CPUs in the system;
384no two sched domains overlap; some CPUs might not be in any sched 388no two sched domains overlap; some CPUs might not be in any sched
@@ -485,17 +489,22 @@ of CPUs allowed to a cpuset having 'sched_load_balance' enabled.
485The internal kernel cpuset to scheduler interface passes from the 489The internal kernel cpuset to scheduler interface passes from the
486cpuset code to the scheduler code a partition of the load balanced 490cpuset code to the scheduler code a partition of the load balanced
487CPUs in the system. This partition is a set of subsets (represented 491CPUs in the system. This partition is a set of subsets (represented
488as an array of cpumask_t) of CPUs, pairwise disjoint, that cover all 492as an array of struct cpumask) of CPUs, pairwise disjoint, that cover
489the CPUs that must be load balanced. 493all the CPUs that must be load balanced.
490 494
491Whenever the 'sched_load_balance' flag changes, or CPUs come or go 495The cpuset code builds a new such partition and passes it to the
492from a cpuset with this flag enabled, or a cpuset with this flag 496scheduler sched domain setup code, to have the sched domains rebuilt
493enabled is removed, the cpuset code builds a new such partition and 497as necessary, whenever:
494passes it to the scheduler sched domain setup code, to have the sched 498 - the 'sched_load_balance' flag of a cpuset with non-empty CPUs changes,
495domains rebuilt as necessary. 499 - or CPUs come or go from a cpuset with this flag enabled,
500 - or 'sched_relax_domain_level' value of a cpuset with non-empty CPUs
501 and with this flag enabled changes,
502 - or a cpuset with non-empty CPUs and with this flag enabled is removed,
503 - or a cpu is offlined/onlined.
496 504
497This partition exactly defines what sched domains the scheduler should 505This partition exactly defines what sched domains the scheduler should
498setup - one sched domain for each element (cpumask_t) in the partition. 506setup - one sched domain for each element (struct cpumask) in the
507partition.
499 508
500The scheduler remembers the currently active sched domain partitions. 509The scheduler remembers the currently active sched domain partitions.
501When the scheduler routine partition_sched_domains() is invoked from 510When the scheduler routine partition_sched_domains() is invoked from
@@ -559,7 +568,7 @@ domain, the largest value among those is used. Be careful, if one
559requests 0 and others are -1 then 0 is used. 568requests 0 and others are -1 then 0 is used.
560 569
561Note that modifying this file will have both good and bad effects, 570Note that modifying this file will have both good and bad effects,
562and whether it is acceptable or not will be depend on your situation. 571and whether it is acceptable or not depends on your situation.
563Don't modify this file if you are not sure. 572Don't modify this file if you are not sure.
564 573
565If your situation is: 574If your situation is:
@@ -600,19 +609,15 @@ to allocate a page of memory for that task.
600 609
601If a cpuset has its 'cpus' modified, then each task in that cpuset 610If a cpuset has its 'cpus' modified, then each task in that cpuset
602will have its allowed CPU placement changed immediately. Similarly, 611will have its allowed CPU placement changed immediately. Similarly,
603if a tasks pid is written to a cpusets 'tasks' file, in either its 612if a tasks pid is written to another cpusets 'tasks' file, then its
604current cpuset or another cpuset, then its allowed CPU placement is 613allowed CPU placement is changed immediately. If such a task had been
605changed immediately. If such a task had been bound to some subset 614bound to some subset of its cpuset using the sched_setaffinity() call,
606of its cpuset using the sched_setaffinity() call, the task will be 615the task will be allowed to run on any CPU allowed in its new cpuset,
607allowed to run on any CPU allowed in its new cpuset, negating the 616negating the effect of the prior sched_setaffinity() call.
608affect of the prior sched_setaffinity() call.
609 617
610In summary, the memory placement of a task whose cpuset is changed is 618In summary, the memory placement of a task whose cpuset is changed is
611updated by the kernel, on the next allocation of a page for that task, 619updated by the kernel, on the next allocation of a page for that task,
612but the processor placement is not updated, until that tasks pid is 620and the processor placement is updated immediately.
613rewritten to the 'tasks' file of its cpuset. This is done to avoid
614impacting the scheduler code in the kernel with a check for changes
615in a tasks processor placement.
616 621
617Normally, once a page is allocated (given a physical page 622Normally, once a page is allocated (given a physical page
618of main memory) then that page stays on whatever node it 623of main memory) then that page stays on whatever node it
@@ -681,10 +686,14 @@ and then start a subshell 'sh' in that cpuset:
681 # The next line should display '/Charlie' 686 # The next line should display '/Charlie'
682 cat /proc/self/cpuset 687 cat /proc/self/cpuset
683 688
684In the future, a C library interface to cpusets will likely be 689There are ways to query or modify cpusets:
685available. For now, the only way to query or modify cpusets is 690 - via the cpuset file system directly, using the various cd, mkdir, echo,
686via the cpuset file system, using the various cd, mkdir, echo, cat, 691 cat, rmdir commands from the shell, or their equivalent from C.
687rmdir commands from the shell, or their equivalent from C. 692 - via the C library libcpuset.
693 - via the C library libcgroup.
694 (http://sourceforge.net/proects/libcg/)
695 - via the python application cset.
696 (http://developer.novell.com/wiki/index.php/Cpuset)
688 697
689The sched_setaffinity calls can also be done at the shell prompt using 698The sched_setaffinity calls can also be done at the shell prompt using
690SGI's runon or Robert Love's taskset. The mbind and set_mempolicy 699SGI's runon or Robert Love's taskset. The mbind and set_mempolicy
@@ -756,7 +765,7 @@ mount -t cpuset X /dev/cpuset
756 765
757is equivalent to 766is equivalent to
758 767
759mount -t cgroup -ocpuset X /dev/cpuset 768mount -t cgroup -ocpuset,noprefix X /dev/cpuset
760echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent 769echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent
761 770
7622.2 Adding/removing cpus 7712.2 Adding/removing cpus
diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt
index 19533f93b7a2..523a9c16c400 100644
--- a/Documentation/cgroups/memcg_test.txt
+++ b/Documentation/cgroups/memcg_test.txt
@@ -1,6 +1,6 @@
1Memory Resource Controller(Memcg) Implementation Memo. 1Memory Resource Controller(Memcg) Implementation Memo.
2Last Updated: 2008/12/15 2Last Updated: 2009/1/19
3Base Kernel Version: based on 2.6.28-rc8-mm. 3Base Kernel Version: based on 2.6.29-rc2.
4 4
5Because VM is getting complex (one of reasons is memcg...), memcg's behavior 5Because VM is getting complex (one of reasons is memcg...), memcg's behavior
6is complex. This is a document for memcg's internal behavior. 6is complex. This is a document for memcg's internal behavior.
@@ -340,3 +340,23 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
340 # mount -t cgroup none /cgroup -t cpuset,memory,cpu,devices 340 # mount -t cgroup none /cgroup -t cpuset,memory,cpu,devices
341 341
342 and do task move, mkdir, rmdir etc...under this. 342 and do task move, mkdir, rmdir etc...under this.
343
344 9.7 swapoff.
345 Besides management of swap is one of complicated parts of memcg,
346 call path of swap-in at swapoff is not same as usual swap-in path..
347 It's worth to be tested explicitly.
348
349 For example, test like following is good.
350 (Shell-A)
351 # mount -t cgroup none /cgroup -t memory
352 # mkdir /cgroup/test
353 # echo 40M > /cgroup/test/memory.limit_in_bytes
354 # echo 0 > /cgroup/test/tasks
355 Run malloc(100M) program under this. You'll see 60M of swaps.
356 (Shell-B)
357 # move all tasks in /cgroup/test to /cgroup
358 # /sbin/swapoff -a
359 # rmdir /test/cgroup
360 # kill malloc task.
361
362 Of course, tmpfs v.s. swapoff test should be tested, too.
diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c
index be7af146dd30..6977c178729a 100644
--- a/Documentation/connector/cn_test.c
+++ b/Documentation/connector/cn_test.c
@@ -137,7 +137,7 @@ static void cn_test_timer_func(unsigned long __data)
137 137
138 memcpy(m + 1, data, m->len); 138 memcpy(m + 1, data, m->len);
139 139
140 cn_netlink_send(m, 0, gfp_any()); 140 cn_netlink_send(m, 0, GFP_ATOMIC);
141 kfree(m); 141 kfree(m);
142 } 142 }
143 143
@@ -160,10 +160,8 @@ static int cn_test_init(void)
160 goto err_out; 160 goto err_out;
161 } 161 }
162 162
163 init_timer(&cn_test_timer); 163 setup_timer(&cn_test_timer, cn_test_timer_func, 0);
164 cn_test_timer.function = cn_test_timer_func;
165 cn_test_timer.expires = jiffies + HZ; 164 cn_test_timer.expires = jiffies + HZ;
166 cn_test_timer.data = 0;
167 add_timer(&cn_test_timer); 165 add_timer(&cn_test_timer);
168 166
169 return 0; 167 return 0;
diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt
index e3443ddcfb89..917918f84fc7 100644
--- a/Documentation/cpu-freq/user-guide.txt
+++ b/Documentation/cpu-freq/user-guide.txt
@@ -195,19 +195,3 @@ scaling_setspeed. By "echoing" a new frequency into this
195 you can change the speed of the CPU, 195 you can change the speed of the CPU,
196 but only within the limits of 196 but only within the limits of
197 scaling_min_freq and scaling_max_freq. 197 scaling_min_freq and scaling_max_freq.
198
199
2003.2 Deprecated Interfaces
201-------------------------
202
203Depending on your kernel configuration, you might find the following
204cpufreq-related files:
205/proc/cpufreq
206/proc/sys/cpu/*/speed
207/proc/sys/cpu/*/speed-min
208/proc/sys/cpu/*/speed-max
209
210These are files for deprecated interfaces to cpufreq, which offer far
211less functionality. Because of this, these interfaces aren't described
212here.
213
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt
index a05ec50f8004..a7cbfff40d07 100644
--- a/Documentation/driver-model/device.txt
+++ b/Documentation/driver-model/device.txt
@@ -127,9 +127,11 @@ void unlock_device(struct device * dev);
127Attributes 127Attributes
128~~~~~~~~~~ 128~~~~~~~~~~
129struct device_attribute { 129struct device_attribute {
130 struct attribute attr; 130 struct attribute attr;
131 ssize_t (*show)(struct device * dev, char * buf, size_t count, loff_t off); 131 ssize_t (*show)(struct device *dev, struct device_attribute *attr,
132 ssize_t (*store)(struct device * dev, const char * buf, size_t count, loff_t off); 132 char *buf);
133 ssize_t (*store)(struct device *dev, struct device_attribute *attr,
134 const char *buf, size_t count);
133}; 135};
134 136
135Attributes of devices can be exported via drivers using a simple 137Attributes of devices can be exported via drivers using a simple
diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop
deleted file mode 100644
index 5515469de7cf..000000000000
--- a/Documentation/dvb/README.flexcop
+++ /dev/null
@@ -1,205 +0,0 @@
1This README escorted the skystar2-driver rewriting procedure. It describes the
2state of the new flexcop-driver set and some internals are written down here
3too.
4
5This document hopefully describes things about the flexcop and its
6device-offsprings. Goal was to write an easy-to-write and easy-to-read set of
7drivers based on the skystar2.c and other information.
8
9Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been
10touched and rewritten.
11
12History & News
13==============
14 2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana)
15
16
17
18
19General coding processing
20=========================
21
22We should proceed as follows (as long as no one complains):
23
240) Think before start writing code!
25
261) rewriting the skystar2.c with the help of the flexcop register descriptions
27and splitting up the files to a pci-bus-part and a flexcop-part.
28The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the
29device-specific part and b2c2-flexcop.ko for the common flexcop-functions.
30
312) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c
32and other pci drivers)
33
343) make some beautification (see 'Improvements when rewriting (refactoring) is
35done')
36
374) Testing the new driver and maybe substitute the skystar2.c with it, to reach
38a wider tester audience.
39
405) creating an usb-bus-part using the already written flexcop code for the pci
41card.
42
43Idea: create a kernel-object for the flexcop and export all important
44functions. This option saves kernel-memory, but maybe a lot of functions have
45to be exported to kernel namespace.
46
47
48Current situation
49=================
50
510) Done :)
521) Done (some minor issues left)
532) Done
543) Not ready yet, more information is necessary
554) next to be done (see the table below)
565) USB driver is working (yes, there are some minor issues)
57
58What seems to be ready?
59-----------------------
60
611) Rewriting
621a) i2c is cut off from the flexcop-pci.c and seems to work
631b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c
641c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c
651e) eeprom (reading MAC address)
661d) sram (no dynamic sll size detection (commented out) (using default as JJ told me))
671f) misc. register accesses for reading parameters (e.g. resetting, revision)
681g) pid/mac filter (flexcop-hw-filter.c)
691i) dvb-stuff initialization in flexcop.c (done)
701h) dma stuff (now just using the size-irq, instead of all-together, to be done)
711j) remove flexcop initialization from flexcop-pci.c completely (done)
721l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO')
731k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from
74non-static where possible, moved code to proper places)
75
762) Search for errors in the leftover of flexcop-pci.c (partially done)
775a) add MAC address reading
785c) feeding of ISOC data to the software demux (format of the isochronous data
79and speed optimization, no real error) (thanks to Vadim Catana)
80
81What to do in the near future?
82--------------------------------------
83(no special order here)
84
855) USB driver
865b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting)
87
88Testing changes
89---------------
90
91O = item is working
92P = item is partially working
93X = item is not working
94N = item does not apply here
95<empty field> = item need to be examined
96
97 | PCI | USB
98item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312
99-------+-------+---------+---------+-------+-------+---------+---------+-------
1001a) | O | | | | N | N | N | N
1011b) | O | | | | | | O |
1021c) | N | N | | | N | N | O |
1031d) | O | O
1041e) | O | O
1051f) | P
1061g) | O
1071h) | P |
1081i) | O | N
1091j) | O | N
1101l) | O | N
1112) | O | N
1125a) | N | O
1135b)* | N |
1145c) | N | O
115
116* - not done yet
117
118Known bugs and problems and TODO
119--------------------------------
120
1211g/h/l) when pid filtering is enabled on the pci card
122
123DMA usage currently:
124 The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first
125 address and triggers an IRQ when it's full and starts writing to the second
126 address. When the second address is full, the IRQ is triggered again, and
127 the flexcop writes to first address again, and so on.
128 The buffersize of each address is currently 640*188 bytes.
129
130 Problem is, when using hw-pid-filtering and doing some low-bandwidth
131 operation (like scanning) the buffers won't be filled enough to trigger
132 the IRQ. That's why:
133
134 When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ
135 is triggered. Is the current write address of DMA1 different to the one
136 during the last IRQ, then the data is passed to the demuxer.
137
138 There is an additional DMA-IRQ-method: packet count IRQ. This isn't
139 implemented correctly yet.
140
141 The solution is to disable HW PID filtering, but I don't know how the DVB
142 API software demux behaves on slow systems with 45MBit/s TS.
143
144Solved bugs :)
145--------------
1461g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't
147working)
148SOLUTION: also index 0 was affected, because net_translation is done for
149these indexes by default
150
1515b) isochronous transfer does only work in the first attempt (for the Sky2PC
152USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really
153woke up again (don't know if this need fixes, see
154flexcop-fe-tuner.c:flexcop_sleep)
155
156NEWS: when the driver is loaded and unloaded and loaded again (w/o doing
157anything in the while the driver is loaded the first time), no transfers take
158place anymore.
159
160Improvements when rewriting (refactoring) is done
161=================================================
162
163- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control
164 (enable sleeping for other demods than dvb-s)
165- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA)
166
167Debugging
168---------
169- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it
170 with this flexcop, this is important, because i2c is now using the
171 flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for
172 that, please tell us so).
173
174Everything which is identical in the following table, can be put into a common
175flexcop-module.
176
177 PCI USB
178-------------------------------------------------------------------------------
179Different:
180Register access: accessing IO memory USB control message
181I2C bus: I2C bus of the FC USB control message
182Data transfer: DMA isochronous transfer
183EEPROM transfer: through i2c bus not clear yet
184
185Identical:
186Streaming: accessing registers
187PID Filtering: accessing registers
188Sram destinations: accessing registers
189Tuner/Demod: I2C bus
190DVB-stuff: can be written for common use
191
192Acknowledgements (just for the rewriting part)
193================
194
195Bjarne Steinsbo thought a lot in the first place of the pci part for this code
196sharing idea.
197
198Andreas Oberritter for providing a recent PCI initialization template
199(pluto2.c).
200
201Boleslaw Ciesielski for pointing out a problem with firmware loader.
202
203Vadim Catana for correcting the USB transfer.
204
205comments, critics and ideas to linux-dvb@linuxtv.org.
diff --git a/Documentation/dvb/technisat.txt b/Documentation/dvb/technisat.txt
index cdf6ee4b2da1..3f435ffb289c 100644
--- a/Documentation/dvb/technisat.txt
+++ b/Documentation/dvb/technisat.txt
@@ -1,5 +1,5 @@
1How to set up the Technisat devices 1How to set up the Technisat/B2C2 Flexcop devices
2=================================== 2================================================
3 3
41) Find out what device you have 41) Find out what device you have
5================================ 5================================
@@ -16,54 +16,60 @@ DVB: registering frontend 0 (Conexant CX24123/CX24109)...
16 16
17If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one: 17If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one:
18"Multimedia devices" => "Customise analog and hybrid tuner modules to build" 18"Multimedia devices" => "Customise analog and hybrid tuner modules to build"
19In this directory uncheck every driver which is activated there. 19In this directory uncheck every driver which is activated there (except "Simple tuner support" for case 9 only).
20 20
21Then please activate: 21Then please activate:
222a) Main module part: 222a) Main module part:
23 23
24a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" 24a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters"
25b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card OR 25b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card
26OR
26c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter 27c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter
27d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers" 28d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers"
28Notice: d.) is helpful for troubleshooting 29Notice: d.) is helpful for troubleshooting
29 30
302b) Frontend module part: 312b) Frontend module part:
31 32
321.) Revision 2.3: 331.) SkyStar DVB-S Revision 2.3:
33a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" 34a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
34b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based" 35b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based"
35 36
362.) Revision 2.6: 372.) SkyStar DVB-S Revision 2.6:
37a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" 38a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
38b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based" 39b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based"
39 40
403.) Revision 2.7: 413.) SkyStar DVB-S Revision 2.7:
41a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" 42a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
42b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based" 43b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based"
43c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS" 44c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS"
44d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" 45d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
45 46
464.) Revision 2.8: 474.) SkyStar DVB-S Revision 2.8:
47a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" 48a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
48b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS" 49b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS"
49c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based" 50c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based"
50d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" 51d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
51 52
525.) DVB-T card: 535.) AirStar DVB-T card:
53a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" 54a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
54b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based" 55b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based"
55 56
566.) DVB-C card: 576.) CableStar DVB-C card:
57a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" 58a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
58b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based" 59b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based"
59 60
607.) ATSC card 1st generation: 617.) AirStar ATSC card 1st generation:
61a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" 62a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
62b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510" 63b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510"
63 64
648.) ATSC card 2nd generation: 658.) AirStar ATSC card 2nd generation:
65a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" 66a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
66b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based" 67b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based"
67c.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based" 68c.)"Multimedia devices" => "Customise DVB frontends" => "Generic I2C PLL based tuners"
68 69
69Author: Uwe Bugla <uwe.bugla@gmx.de> December 2008 709.) AirStar ATSC card 3rd generation:
71a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
72b.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
73c.)"Multimedia devices" => "Customise analog and hybrid tuner modules to build" => "Simple tuner support"
74
75Author: Uwe Bugla <uwe.bugla@gmx.de> February 2009
diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs-rdma.txt
index 44bd766f2e5d..85eaeaddd27c 100644
--- a/Documentation/filesystems/nfs-rdma.txt
+++ b/Documentation/filesystems/nfs-rdma.txt
@@ -251,7 +251,7 @@ NFS/RDMA Setup
251 251
252 Instruct the server to listen on the RDMA transport: 252 Instruct the server to listen on the RDMA transport:
253 253
254 $ echo rdma 2050 > /proc/fs/nfsd/portlist 254 $ echo rdma 20049 > /proc/fs/nfsd/portlist
255 255
256 - On the client system 256 - On the client system
257 257
@@ -263,7 +263,7 @@ NFS/RDMA Setup
263 Regardless of how the client was built (module or built-in), use this 263 Regardless of how the client was built (module or built-in), use this
264 command to mount the NFS/RDMA server: 264 command to mount the NFS/RDMA server:
265 265
266 $ mount -o rdma,port=2050 <IPoIB-server-name-or-address>:/<export> /mnt 266 $ mount -o rdma,port=20049 <IPoIB-server-name-or-address>:/<export> /mnt
267 267
268 To verify that the mount is using RDMA, run "cat /proc/mounts" and check 268 To verify that the mount is using RDMA, run "cat /proc/mounts" and check
269 the "proto" field for the given mount. 269 the "proto" field for the given mount.
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index bbebc3a43ac0..a87be42f8211 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -2027,6 +2027,34 @@ increase the likelihood of this process being killed by the oom-killer. Valid
2027values are in the range -16 to +15, plus the special value -17, which disables 2027values are in the range -16 to +15, plus the special value -17, which disables
2028oom-killing altogether for this process. 2028oom-killing altogether for this process.
2029 2029
2030The process to be killed in an out-of-memory situation is selected among all others
2031based on its badness score. This value equals the original memory size of the process
2032and is then updated according to its CPU time (utime + stime) and the
2033run time (uptime - start time). The longer it runs the smaller is the score.
2034Badness score is divided by the square root of the CPU time and then by
2035the double square root of the run time.
2036
2037Swapped out tasks are killed first. Half of each child's memory size is added to
2038the parent's score if they do not share the same memory. Thus forking servers
2039are the prime candidates to be killed. Having only one 'hungry' child will make
2040parent less preferable than the child.
2041
2042/proc/<pid>/oom_score shows process' current badness score.
2043
2044The following heuristics are then applied:
2045 * if the task was reniced, its score doubles
2046 * superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE
2047 or CAP_SYS_RAWIO) have their score divided by 4
2048 * if oom condition happened in one cpuset and checked task does not belong
2049 to it, its score is divided by 8
2050 * the resulting score is multiplied by two to the power of oom_adj, i.e.
2051 points <<= oom_adj when it is positive and
2052 points >>= -(oom_adj) otherwise
2053
2054The task with the highest badness score is then selected and its children
2055are killed, process itself will be killed in an OOM situation when it does
2056not have children or some of them disabled oom like described above.
2057
20302.13 /proc/<pid>/oom_score - Display current oom-killer score 20582.13 /proc/<pid>/oom_score - Display current oom-killer score
2031------------------------------------------------------------- 2059-------------------------------------------------------------
2032 2060
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
index 68ef48839c04..9f8740ca3f3b 100644
--- a/Documentation/filesystems/sysfs-pci.txt
+++ b/Documentation/filesystems/sysfs-pci.txt
@@ -9,6 +9,7 @@ that support it. For example, a given bus might look like this:
9 | |-- class 9 | |-- class
10 | |-- config 10 | |-- config
11 | |-- device 11 | |-- device
12 | |-- enable
12 | |-- irq 13 | |-- irq
13 | |-- local_cpus 14 | |-- local_cpus
14 | |-- resource 15 | |-- resource
@@ -32,6 +33,7 @@ files, each with their own function.
32 class PCI class (ascii, ro) 33 class PCI class (ascii, ro)
33 config PCI config space (binary, rw) 34 config PCI config space (binary, rw)
34 device PCI device (ascii, ro) 35 device PCI device (ascii, ro)
36 enable Whether the device is enabled (ascii, rw)
35 irq IRQ number (ascii, ro) 37 irq IRQ number (ascii, ro)
36 local_cpus nearby CPU mask (cpumask, ro) 38 local_cpus nearby CPU mask (cpumask, ro)
37 resource PCI resource host addresses (ascii, ro) 39 resource PCI resource host addresses (ascii, ro)
@@ -57,10 +59,19 @@ used to do actual device programming from userspace. Note that some platforms
57don't support mmapping of certain resources, so be sure to check the return 59don't support mmapping of certain resources, so be sure to check the return
58value from any attempted mmap. 60value from any attempted mmap.
59 61
62The 'enable' file provides a counter that indicates how many times the device
63has been enabled. If the 'enable' file currently returns '4', and a '1' is
64echoed into it, it will then return '5'. Echoing a '0' into it will decrease
65the count. Even when it returns to 0, though, some of the initialisation
66may not be reversed.
67
60The 'rom' file is special in that it provides read-only access to the device's 68The 'rom' file is special in that it provides read-only access to the device's
61ROM file, if available. It's disabled by default, however, so applications 69ROM file, if available. It's disabled by default, however, so applications
62should write the string "1" to the file to enable it before attempting a read 70should write the string "1" to the file to enable it before attempting a read
63call, and disable it following the access by writing "0" to the file. 71call, and disable it following the access by writing "0" to the file. Note
72that the device must be enabled for a rom read to return data succesfully.
73In the event a driver is not bound to the device, it can be enabled using the
74'enable' file, documented above.
64 75
65Accessing legacy resources through sysfs 76Accessing legacy resources through sysfs
66---------------------------------------- 77----------------------------------------
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index 9e9c348275a9..7e81e37c0b1e 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -2,8 +2,10 @@
2sysfs - _The_ filesystem for exporting kernel objects. 2sysfs - _The_ filesystem for exporting kernel objects.
3 3
4Patrick Mochel <mochel@osdl.org> 4Patrick Mochel <mochel@osdl.org>
5Mike Murphy <mamurph@cs.clemson.edu>
5 6
610 January 2003 7Revised: 22 February 2009
8Original: 10 January 2003
7 9
8 10
9What it is: 11What it is:
@@ -64,12 +66,13 @@ An attribute definition is simply:
64 66
65struct attribute { 67struct attribute {
66 char * name; 68 char * name;
69 struct module *owner;
67 mode_t mode; 70 mode_t mode;
68}; 71};
69 72
70 73
71int sysfs_create_file(struct kobject * kobj, struct attribute * attr); 74int sysfs_create_file(struct kobject * kobj, const struct attribute * attr);
72void sysfs_remove_file(struct kobject * kobj, struct attribute * attr); 75void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr);
73 76
74 77
75A bare attribute contains no means to read or write the value of the 78A bare attribute contains no means to read or write the value of the
@@ -80,9 +83,11 @@ a specific object type.
80For example, the driver model defines struct device_attribute like: 83For example, the driver model defines struct device_attribute like:
81 84
82struct device_attribute { 85struct device_attribute {
83 struct attribute attr; 86 struct attribute attr;
84 ssize_t (*show)(struct device * dev, char * buf); 87 ssize_t (*show)(struct device *dev, struct device_attribute *attr,
85 ssize_t (*store)(struct device * dev, const char * buf); 88 char *buf);
89 ssize_t (*store)(struct device *dev, struct device_attribute *attr,
90 const char *buf, size_t count);
86}; 91};
87 92
88int device_create_file(struct device *, struct device_attribute *); 93int device_create_file(struct device *, struct device_attribute *);
@@ -90,12 +95,8 @@ void device_remove_file(struct device *, struct device_attribute *);
90 95
91It also defines this helper for defining device attributes: 96It also defines this helper for defining device attributes:
92 97
93#define DEVICE_ATTR(_name, _mode, _show, _store) \ 98#define DEVICE_ATTR(_name, _mode, _show, _store) \
94struct device_attribute dev_attr_##_name = { \ 99struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
95 .attr = {.name = __stringify(_name) , .mode = _mode }, \
96 .show = _show, \
97 .store = _store, \
98};
99 100
100For example, declaring 101For example, declaring
101 102
@@ -107,9 +108,9 @@ static struct device_attribute dev_attr_foo = {
107 .attr = { 108 .attr = {
108 .name = "foo", 109 .name = "foo",
109 .mode = S_IWUSR | S_IRUGO, 110 .mode = S_IWUSR | S_IRUGO,
111 .show = show_foo,
112 .store = store_foo,
110 }, 113 },
111 .show = show_foo,
112 .store = store_foo,
113}; 114};
114 115
115 116
@@ -161,10 +162,12 @@ To read or write attributes, show() or store() methods must be
161specified when declaring the attribute. The method types should be as 162specified when declaring the attribute. The method types should be as
162simple as those defined for device attributes: 163simple as those defined for device attributes:
163 164
164 ssize_t (*show)(struct device * dev, char * buf); 165ssize_t (*show)(struct device * dev, struct device_attribute * attr,
165 ssize_t (*store)(struct device * dev, const char * buf); 166 char * buf);
167ssize_t (*store)(struct device * dev, struct device_attribute * attr,
168 const char * buf);
166 169
167IOW, they should take only an object and a buffer as parameters. 170IOW, they should take only an object, an attribute, and a buffer as parameters.
168 171
169 172
170sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the 173sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the
@@ -299,14 +302,16 @@ The following interface layers currently exist in sysfs:
299Structure: 302Structure:
300 303
301struct device_attribute { 304struct device_attribute {
302 struct attribute attr; 305 struct attribute attr;
303 ssize_t (*show)(struct device * dev, char * buf); 306 ssize_t (*show)(struct device *dev, struct device_attribute *attr,
304 ssize_t (*store)(struct device * dev, const char * buf); 307 char *buf);
308 ssize_t (*store)(struct device *dev, struct device_attribute *attr,
309 const char *buf, size_t count);
305}; 310};
306 311
307Declaring: 312Declaring:
308 313
309DEVICE_ATTR(_name, _str, _mode, _show, _store); 314DEVICE_ATTR(_name, _mode, _show, _store);
310 315
311Creation/Removal: 316Creation/Removal:
312 317
@@ -342,7 +347,8 @@ Structure:
342struct driver_attribute { 347struct driver_attribute {
343 struct attribute attr; 348 struct attribute attr;
344 ssize_t (*show)(struct device_driver *, char * buf); 349 ssize_t (*show)(struct device_driver *, char * buf);
345 ssize_t (*store)(struct device_driver *, const char * buf); 350 ssize_t (*store)(struct device_driver *, const char * buf,
351 size_t count);
346}; 352};
347 353
348Declaring: 354Declaring:
diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt
index 84da2a4ba25a..12fedb7834c6 100644
--- a/Documentation/filesystems/ubifs.txt
+++ b/Documentation/filesystems/ubifs.txt
@@ -79,13 +79,6 @@ Mount options
79 79
80(*) == default. 80(*) == default.
81 81
82norm_unmount (*) commit on unmount; the journal is committed
83 when the file-system is unmounted so that the
84 next mount does not have to replay the journal
85 and it becomes very fast;
86fast_unmount do not commit on unmount; this option makes
87 unmount faster, but the next mount slower
88 because of the need to replay the journal.
89bulk_read read more in one go to take advantage of flash 82bulk_read read more in one go to take advantage of flash
90 media that read faster sequentially 83 media that read faster sequentially
91no_bulk_read (*) do not bulk-read 84no_bulk_read (*) do not bulk-read
diff --git a/Documentation/hwmon/hpfall.c b/Documentation/hwmon/hpfall.c
new file mode 100644
index 000000000000..bbea1ccfd46a
--- /dev/null
+++ b/Documentation/hwmon/hpfall.c
@@ -0,0 +1,101 @@
1/* Disk protection for HP machines.
2 *
3 * Copyright 2008 Eric Piel
4 * Copyright 2009 Pavel Machek <pavel@suse.cz>
5 *
6 * GPLv2.
7 */
8
9#include <stdio.h>
10#include <stdlib.h>
11#include <unistd.h>
12#include <fcntl.h>
13#include <sys/stat.h>
14#include <sys/types.h>
15#include <string.h>
16#include <stdint.h>
17#include <errno.h>
18#include <signal.h>
19
20void write_int(char *path, int i)
21{
22 char buf[1024];
23 int fd = open(path, O_RDWR);
24 if (fd < 0) {
25 perror("open");
26 exit(1);
27 }
28 sprintf(buf, "%d", i);
29 if (write(fd, buf, strlen(buf)) != strlen(buf)) {
30 perror("write");
31 exit(1);
32 }
33 close(fd);
34}
35
36void set_led(int on)
37{
38 write_int("/sys/class/leds/hp::hddprotect/brightness", on);
39}
40
41void protect(int seconds)
42{
43 write_int("/sys/block/sda/device/unload_heads", seconds*1000);
44}
45
46int on_ac(void)
47{
48// /sys/class/power_supply/AC0/online
49}
50
51int lid_open(void)
52{
53// /proc/acpi/button/lid/LID/state
54}
55
56void ignore_me(void)
57{
58 protect(0);
59 set_led(0);
60
61}
62
63int main(int argc, char* argv[])
64{
65 int fd, ret;
66
67 fd = open("/dev/freefall", O_RDONLY);
68 if (fd < 0) {
69 perror("open");
70 return EXIT_FAILURE;
71 }
72
73 signal(SIGALRM, ignore_me);
74
75 for (;;) {
76 unsigned char count;
77
78 ret = read(fd, &count, sizeof(count));
79 alarm(0);
80 if ((ret == -1) && (errno == EINTR)) {
81 /* Alarm expired, time to unpark the heads */
82 continue;
83 }
84
85 if (ret != sizeof(count)) {
86 perror("read");
87 break;
88 }
89
90 protect(21);
91 set_led(1);
92 if (1 || on_ac() || lid_open()) {
93 alarm(2);
94 } else {
95 alarm(20);
96 }
97 }
98
99 close(fd);
100 return EXIT_SUCCESS;
101}
diff --git a/Documentation/hwmon/lis3lv02d b/Documentation/hwmon/lis3lv02d
index 0fcfc4a7ccdc..287f8c902656 100644
--- a/Documentation/hwmon/lis3lv02d
+++ b/Documentation/hwmon/lis3lv02d
@@ -33,6 +33,14 @@ rate - reports the sampling rate of the accelerometer device in HZ
33This driver also provides an absolute input class device, allowing 33This driver also provides an absolute input class device, allowing
34the laptop to act as a pinball machine-esque joystick. 34the laptop to act as a pinball machine-esque joystick.
35 35
36Another feature of the driver is misc device called "freefall" that
37acts similar to /dev/rtc and reacts on free-fall interrupts received
38from the device. It supports blocking operations, poll/select and
39fasync operation modes. You must read 1 bytes from the device. The
40result is number of free-fall interrupts since the last successful
41read (or 255 if number of interrupts would not fit).
42
43
36Axes orientation 44Axes orientation
37---------------- 45----------------
38 46
diff --git a/Documentation/ja_JP/stable_kernel_rules.txt b/Documentation/ja_JP/stable_kernel_rules.txt
index b3ffe870de33..14265837c4ce 100644
--- a/Documentation/ja_JP/stable_kernel_rules.txt
+++ b/Documentation/ja_JP/stable_kernel_rules.txt
@@ -12,11 +12,11 @@ file at first.
12 12
13================================== 13==================================
14これは、 14これは、
15linux-2.6.24/Documentation/stable_kernel_rules.txt 15linux-2.6.29/Documentation/stable_kernel_rules.txt
16の和訳です。 16の和訳です。
17 17
18翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > 18翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
19翻訳日： 2007/12/30 19翻訳日： 2009/1/14
20翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> 20翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
21校正者： 武井伸光さん、<takei at webmasters dot gr dot jp> 21校正者： 武井伸光さん、<takei at webmasters dot gr dot jp>
22 かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp> 22 かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp>
@@ -38,12 +38,15 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt
38 - ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー 38 - ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー
39 タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という 39 タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という
40 ようなものを修正しなければならない。短く言えば、重大な問題。 40 ようなものを修正しなければならない。短く言えば、重大な問題。
41 - 新しい device ID とクオークも受け入れられる。
41 - どのように競合状態が発生するかの説明も一緒に書かれていない限り、 42 - どのように競合状態が発生するかの説明も一緒に書かれていない限り、
42 "理論的には競合状態になる"ようなものは不可。 43 "理論的には競合状態になる"ようなものは不可。
43 - いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー 44 - いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー
44 ンアップなど) 45 ンアップなど)
45 - 対応するサブシステムメンテナが受け入れたものでなければならない。
46 - Documentation/SubmittingPatches の規則に従ったものでなければならない。 46 - Documentation/SubmittingPatches の規則に従ったものでなければならない。
47 - パッチ自体か同等の修正が Linus のツリーに既に存在しなければならない。
48　 Linus のツリーでのコミットID を -stable へのパッチ投稿の際に引用す
49 ること。
47 50
48-stable ツリーにパッチを送付する手続き- 51-stable ツリーにパッチを送付する手続き-
49 52
@@ -52,8 +55,10 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt
52 - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合 55 - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合
53 には NAK を受け取る。この反応は開発者たちのスケジュールによって、数 56 には NAK を受け取る。この反応は開発者たちのスケジュールによって、数
54 日かかる場合がある。 57 日かかる場合がある。
55 - もし受け取られたら、パッチは他の開発者たちのレビューのために 58 - もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの
56 -stable キューに追加される。 59 メンテナーによるレビューのために -stable キューに追加される。
60 - パッチに stable@kernel.org のアドレスが付加されているときには、それ
61 が Linus のツリーに入る時に自動的に stable チームに email される。
57 - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ 62 - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ
58 きではなく、代わりに security@kernel.org のアドレスに送られる。 63 きではなく、代わりに security@kernel.org のアドレスに送られる。
59 64
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index 923f9ddee8f6..f3355b6812df 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -3,7 +3,7 @@ Environment variables
3KCPPFLAGS 3KCPPFLAGS
4-------------------------------------------------- 4--------------------------------------------------
5Additional options to pass when preprocessing. The preprocessing options 5Additional options to pass when preprocessing. The preprocessing options
6will be used in all cases where kbuild do preprocessing including 6will be used in all cases where kbuild does preprocessing including
7building C files and assembler files. 7building C files and assembler files.
8 8
9KAFLAGS 9KAFLAGS
@@ -16,7 +16,7 @@ Additional options to the C compiler.
16 16
17KBUILD_VERBOSE 17KBUILD_VERBOSE
18-------------------------------------------------- 18--------------------------------------------------
19Set the kbuild verbosity. Can be assinged same values as "V=...". 19Set the kbuild verbosity. Can be assigned same values as "V=...".
20See make help for the full list. 20See make help for the full list.
21Setting "V=..." takes precedence over KBUILD_VERBOSE. 21Setting "V=..." takes precedence over KBUILD_VERBOSE.
22 22
@@ -35,14 +35,14 @@ KBUILD_OUTPUT
35-------------------------------------------------- 35--------------------------------------------------
36Specify the output directory when building the kernel. 36Specify the output directory when building the kernel.
37The output directory can also be specificed using "O=...". 37The output directory can also be specificed using "O=...".
38Setting "O=..." takes precedence over KBUILD_OUTPUT 38Setting "O=..." takes precedence over KBUILD_OUTPUT.
39 39
40ARCH 40ARCH
41-------------------------------------------------- 41--------------------------------------------------
42Set ARCH to the architecture to be built. 42Set ARCH to the architecture to be built.
43In most cases the name of the architecture is the same as the 43In most cases the name of the architecture is the same as the
44directory name found in the arch/ directory. 44directory name found in the arch/ directory.
45But some architectures suach as x86 and sparc has aliases. 45But some architectures such as x86 and sparc have aliases.
46x86: i386 for 32 bit, x86_64 for 64 bit 46x86: i386 for 32 bit, x86_64 for 64 bit
47sparc: sparc for 32 bit, sparc64 for 64 bit 47sparc: sparc for 32 bit, sparc64 for 64 bit
48 48
@@ -63,7 +63,7 @@ CF is often used on the command-line like this:
63INSTALL_PATH 63INSTALL_PATH
64-------------------------------------------------- 64--------------------------------------------------
65INSTALL_PATH specifies where to place the updated kernel and system map 65INSTALL_PATH specifies where to place the updated kernel and system map
66images. Default is /boot, but you can set it to other values 66images. Default is /boot, but you can set it to other values.
67 67
68 68
69MODLIB 69MODLIB
@@ -90,7 +90,7 @@ INSTALL_MOD_STRIP will used as the options to the strip command.
90 90
91INSTALL_FW_PATH 91INSTALL_FW_PATH
92-------------------------------------------------- 92--------------------------------------------------
93INSTALL_FW_PATH specify where to install the firmware blobs. 93INSTALL_FW_PATH specifies where to install the firmware blobs.
94The default value is: 94The default value is:
95 95
96 $(INSTALL_MOD_PATH)/lib/firmware 96 $(INSTALL_MOD_PATH)/lib/firmware
@@ -99,7 +99,7 @@ The value can be overridden in which case the default value is ignored.
99 99
100INSTALL_HDR_PATH 100INSTALL_HDR_PATH
101-------------------------------------------------- 101--------------------------------------------------
102INSTALL_HDR_PATH specify where to install user space headers when 102INSTALL_HDR_PATH specifies where to install user space headers when
103executing "make headers_*". 103executing "make headers_*".
104The default value is: 104The default value is:
105 105
@@ -112,22 +112,23 @@ The value can be overridden in which case the default value is ignored.
112 112
113KBUILD_MODPOST_WARN 113KBUILD_MODPOST_WARN
114-------------------------------------------------- 114--------------------------------------------------
115KBUILD_MODPOST_WARN can be set to avoid error out in case of undefined 115KBUILD_MODPOST_WARN can be set to avoid errors in case of undefined
116symbols in the final module linking stage. 116symbols in the final module linking stage. It changes such errors
117into warnings.
117 118
118KBUILD_MODPOST_FINAL 119KBUILD_MODPOST_NOFINAL
119-------------------------------------------------- 120--------------------------------------------------
120KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules. 121KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules.
121This is solely usefull to speed up test compiles. 122This is solely useful to speed up test compiles.
122 123
123KBUILD_EXTRA_SYMBOLS 124KBUILD_EXTRA_SYMBOLS
124-------------------------------------------------- 125--------------------------------------------------
125For modules use symbols from another modules. 126For modules that use symbols from other modules.
126See more details in modules.txt. 127See more details in modules.txt.
127 128
128ALLSOURCE_ARCHS 129ALLSOURCE_ARCHS
129-------------------------------------------------- 130--------------------------------------------------
130For tags/TAGS/cscope targets, you can specify more than one archs 131For tags/TAGS/cscope targets, you can specify more than one arch
131to be included in the databases, separated by blankspace. e.g. 132to be included in the databases, separated by blank space. E.g.:
132 133
133 $ make ALLSOURCE_ARCHS="x86 mips arm" tags 134 $ make ALLSOURCE_ARCHS="x86 mips arm" tags
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt
index d73fbd2b2b45..026ec7d57384 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -43,7 +43,8 @@ Only comments so marked will be considered by the kernel-doc scripts,
43and any comment so marked must be in kernel-doc format. Do not use 43and any comment so marked must be in kernel-doc format. Do not use
44"/**" to be begin a comment block unless the comment block contains 44"/**" to be begin a comment block unless the comment block contains
45kernel-doc formatted comments. The closing comment marker for 45kernel-doc formatted comments. The closing comment marker for
46kernel-doc comments can be either "*/" or "**/". 46kernel-doc comments can be either "*/" or "**/", but "*/" is
47preferred in the Linux kernel tree.
47 48
48Kernel-doc comments should be placed just before the function 49Kernel-doc comments should be placed just before the function
49or data structure being described. 50or data structure being described.
@@ -63,7 +64,7 @@ Example kernel-doc function comment:
63 * comment lines. 64 * comment lines.
64 * 65 *
65 * The longer description can have multiple paragraphs. 66 * The longer description can have multiple paragraphs.
66 **/ 67 */
67 68
68The first line, with the short description, must be on a single line. 69The first line, with the short description, must be on a single line.
69 70
@@ -85,7 +86,7 @@ Example kernel-doc data structure comment.
85 * perhaps with more lines and words. 86 * perhaps with more lines and words.
86 * 87 *
87 * Longer description of this structure. 88 * Longer description of this structure.
88 **/ 89 */
89 90
90The kernel-doc function comments describe each parameter to the 91The kernel-doc function comments describe each parameter to the
91function, in order, with the @name lines. 92function, in order, with the @name lines.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 8511d3532c27..54f21a5c262b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -114,7 +114,7 @@ In addition, the following text indicates that the option:
114Parameters denoted with BOOT are actually interpreted by the boot 114Parameters denoted with BOOT are actually interpreted by the boot
115loader, and have no meaning to the kernel directly. 115loader, and have no meaning to the kernel directly.
116Do not modify the syntax of boot loader parameters without extreme 116Do not modify the syntax of boot loader parameters without extreme
117need or coordination with <Documentation/x86/i386/boot.txt>. 117need or coordination with <Documentation/x86/boot.txt>.
118 118
119There are also arch-specific kernel-parameters not documented here. 119There are also arch-specific kernel-parameters not documented here.
120See for example <Documentation/x86/x86_64/boot-options.txt>. 120See for example <Documentation/x86/x86_64/boot-options.txt>.
@@ -134,7 +134,7 @@ and is between 256 and 4096 characters. It is defined in the file
134 134
135 acpi= [HW,ACPI,X86-64,i386] 135 acpi= [HW,ACPI,X86-64,i386]
136 Advanced Configuration and Power Interface 136 Advanced Configuration and Power Interface
137 Format: { force | off | ht | strict | noirq } 137 Format: { force | off | ht | strict | noirq | rsdt }
138 force -- enable ACPI if default was off 138 force -- enable ACPI if default was off
139 off -- disable ACPI if default was on 139 off -- disable ACPI if default was on
140 noirq -- do not use ACPI for IRQ routing 140 noirq -- do not use ACPI for IRQ routing
@@ -577,9 +577,6 @@ and is between 256 and 4096 characters. It is defined in the file
577 a memory unit (amount[KMG]). See also 577 a memory unit (amount[KMG]). See also
578 Documentation/kdump/kdump.txt for a example. 578 Documentation/kdump/kdump.txt for a example.
579 579
580 cs4232= [HW,OSS]
581 Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq>
582
583 cs89x0_dma= [HW,NET] 580 cs89x0_dma= [HW,NET]
584 Format: <dma> 581 Format: <dma>
585 582
@@ -732,10 +729,6 @@ and is between 256 and 4096 characters. It is defined in the file
732 Default value is 0. 729 Default value is 0.
733 Value can be changed at runtime via /selinux/enforce. 730 Value can be changed at runtime via /selinux/enforce.
734 731
735 es1371= [HW,OSS]
736 Format: <spdif>,[<nomix>,[<amplifier>]]
737 See also header of sound/oss/es1371.c.
738
739 ether= [HW,NET] Ethernet cards parameters 732 ether= [HW,NET] Ethernet cards parameters
740 This option is obsoleted by the "netdev=" option, which 733 This option is obsoleted by the "netdev=" option, which
741 has equivalent usage. See its documentation for details. 734 has equivalent usage. See its documentation for details.
@@ -875,8 +868,10 @@ and is between 256 and 4096 characters. It is defined in the file
875 icn= [HW,ISDN] 868 icn= [HW,ISDN]
876 Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]] 869 Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
877 870
878 ide= [HW] (E)IDE subsystem 871 ide-core.nodma= [HW] (E)IDE subsystem
879 Format: ide=nodma or ide=doubler 872 Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc
873 .vlb_clock .pci_clock .noflush .noprobe .nowerr .cdrom
874 .chs .ignore_cable are additional options
880 See Documentation/ide/ide.txt. 875 See Documentation/ide/ide.txt.
881 876
882 idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed 877 idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
@@ -944,6 +939,8 @@ and is between 256 and 4096 characters. It is defined in the file
944 939
945 940
946 intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option 941 intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
942 on
943 Enable intel iommu driver.
947 off 944 off
948 Disable intel iommu driver. 945 Disable intel iommu driver.
949 igfx_off [Default Off] 946 igfx_off [Default Off]
@@ -2454,7 +2451,7 @@ and is between 256 and 4096 characters. It is defined in the file
2454 See Documentation/fb/modedb.txt. 2451 See Documentation/fb/modedb.txt.
2455 2452
2456 vga= [BOOT,X86-32] Select a particular video mode 2453 vga= [BOOT,X86-32] Select a particular video mode
2457 See Documentation/x86/i386/boot.txt and 2454 See Documentation/x86/boot.txt and
2458 Documentation/svga.txt. 2455 Documentation/svga.txt.
2459 Use vga=ask for menu. 2456 Use vga=ask for menu.
2460 This is actually a boot loader parameter; the value is 2457 This is actually a boot loader parameter; the value is
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 898b4987bb80..41bc99fa1884 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -1,7 +1,7 @@
1 ThinkPad ACPI Extras Driver 1 ThinkPad ACPI Extras Driver
2 2
3 Version 0.21 3 Version 0.22
4 May 29th, 2008 4 November 23rd, 2008
5 5
6 Borislav Deianov <borislav@users.sf.net> 6 Borislav Deianov <borislav@users.sf.net>
7 Henrique de Moraes Holschuh <hmh@hmh.eng.br> 7 Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@@ -16,7 +16,8 @@ supported by the generic Linux ACPI drivers.
16This driver used to be named ibm-acpi until kernel 2.6.21 and release 16This driver used to be named ibm-acpi until kernel 2.6.21 and release
170.13-20070314. It used to be in the drivers/acpi tree, but it was 170.13-20070314. It used to be in the drivers/acpi tree, but it was
18moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel 18moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel
192.6.22, and release 0.14. 192.6.22, and release 0.14. It was moved to drivers/platform/x86 for
20kernel 2.6.29 and release 0.22.
20 21
21The driver is named "thinkpad-acpi". In some places, like module 22The driver is named "thinkpad-acpi". In some places, like module
22names, "thinkpad_acpi" is used because of userspace issues. 23names, "thinkpad_acpi" is used because of userspace issues.
@@ -1412,6 +1413,24 @@ Sysfs notes:
1412 rfkill controller switch "tpacpi_wwan_sw": refer to 1413 rfkill controller switch "tpacpi_wwan_sw": refer to
1413 Documentation/rfkill.txt for details. 1414 Documentation/rfkill.txt for details.
1414 1415
1416EXPERIMENTAL: UWB
1417-----------------
1418
1419This feature is marked EXPERIMENTAL because it has not been extensively
1420tested and validated in various ThinkPad models yet. The feature may not
1421work as expected. USE WITH CAUTION! To use this feature, you need to supply
1422the experimental=1 parameter when loading the module.
1423
1424sysfs rfkill class: switch "tpacpi_uwb_sw"
1425
1426This feature exports an rfkill controller for the UWB device, if one is
1427present and enabled in the BIOS.
1428
1429Sysfs notes:
1430
1431 rfkill controller switch "tpacpi_uwb_sw": refer to
1432 Documentation/rfkill.txt for details.
1433
1415Multiple Commands, Module Parameters 1434Multiple Commands, Module Parameters
1416------------------------------------ 1435------------------------------------
1417 1436
diff --git a/Documentation/lguest/Makefile b/Documentation/lguest/Makefile
index 725eef81cd48..1f4f9e888bd1 100644
--- a/Documentation/lguest/Makefile
+++ b/Documentation/lguest/Makefile
@@ -1,5 +1,5 @@
1# This creates the demonstration utility "lguest" which runs a Linux guest. 1# This creates the demonstration utility "lguest" which runs a Linux guest.
2CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include 2CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE
3LDLIBS:=-lz 3LDLIBS:=-lz
4 4
5all: lguest 5all: lguest
diff --git a/Documentation/networking/alias.txt b/Documentation/networking/alias.txt
index cd12c2ff518a..85046f53fcfc 100644
--- a/Documentation/networking/alias.txt
+++ b/Documentation/networking/alias.txt
@@ -2,13 +2,13 @@
2IP-Aliasing: 2IP-Aliasing:
3============ 3============
4 4
5IP-aliases are additional IP-addresses/masks hooked up to a base 5IP-aliases are an obsolete way to manage multiple IP-addresses/masks
6interface by adding a colon and a string when running ifconfig. 6per interface. Newer tools such as iproute2 support multiple
7This string is usually numeric, but this is not a must. 7address/prefixes per interface, but aliases are still supported
8 8for backwards compatibility.
9IP-Aliases are avail if CONFIG_INET (`standard' IPv4 networking)
10is configured in the kernel.
11 9
10An alias is formed by adding a colon and a string when running ifconfig.
11This string is usually numeric, but this is not a must.
12 12
13o Alias creation. 13o Alias creation.
14 Alias creation is done by 'magic' interface naming: eg. to create a 14 Alias creation is done by 'magic' interface naming: eg. to create a
@@ -38,16 +38,3 @@ o Relationship with main device
38 38
39 If the base device is shut down the added aliases will be deleted 39 If the base device is shut down the added aliases will be deleted
40 too. 40 too.
41
42
43Contact
44-------
45Please finger or e-mail me:
46 Juan Jose Ciarlante <jjciarla@raiz.uncu.edu.ar>
47
48Updated by Erik Schoenfelder <schoenfr@gaertner.DE>
49
50; local variables:
51; mode: indented-text
52; mode: auto-fill
53; end:
diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
index 3c2f2b328638..8d022073e3ef 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -51,7 +51,8 @@ Built-in netconsole starts immediately after the TCP stack is
51initialized and attempts to bring up the supplied dev at the supplied 51initialized and attempts to bring up the supplied dev at the supplied
52address. 52address.
53 53
54The remote host can run either 'netcat -u -l -p <port>' or syslogd. 54The remote host can run either 'netcat -u -l -p <port>',
55'nc -l -u <port>' or syslogd.
55 56
56Dynamic reconfiguration: 57Dynamic reconfiguration:
57======================== 58========================
diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
new file mode 100644
index 000000000000..8447fd7090d0
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
@@ -0,0 +1,180 @@
1MPC5200 Device Tree Bindings
2----------------------------
3
4(c) 2006-2009 Secret Lab Technologies Ltd
5Grant Likely <grant.likely@secretlab.ca>
6
7Naming conventions
8------------------
9For mpc5200 on-chip devices, the format for each compatible value is
10<chip>-<device>[-<mode>]. The OS should be able to match a device driver
11to the device based solely on the compatible value. If two drivers
12match on the compatible list; the 'most compatible' driver should be
13selected.
14
15The split between the MPC5200 and the MPC5200B leaves a bit of a
16conundrum. How should the compatible property be set up to provide
17maximum compatibility information; but still accurately describe the
18chip? For the MPC5200; the answer is easy. Most of the SoC devices
19originally appeared on the MPC5200. Since they didn't exist anywhere
20else; the 5200 compatible properties will contain only one item;
21"fsl,mpc5200-<device>".
22
23The 5200B is almost the same as the 5200, but not quite. It fixes
24silicon bugs and it adds a small number of enhancements. Most of the
25devices either provide exactly the same interface as on the 5200. A few
26devices have extra functions but still have a backwards compatible mode.
27To express this information as completely as possible, 5200B device trees
28should have two items in the compatible list:
29 compatible = "fsl,mpc5200b-<device>","fsl,mpc5200-<device>";
30
31It is *strongly* recommended that 5200B device trees follow this convention
32(instead of only listing the base mpc5200 item).
33
34ie. ethernet on mpc5200: compatible = "fsl,mpc5200-fec";
35 ethernet on mpc5200b: compatible = "fsl,mpc5200b-fec", "fsl,mpc5200-fec";
36
37Modal devices, like PSCs, also append the configured function to the
38end of the compatible field. ie. A PSC in i2s mode would specify
39"fsl,mpc5200-psc-i2s", not "fsl,mpc5200-i2s". This convention is chosen to
40avoid naming conflicts with non-psc devices providing the same
41function. For example, "fsl,mpc5200-spi" and "fsl,mpc5200-psc-spi" describe
42the mpc5200 simple spi device and a PSC spi mode respectively.
43
44At the time of writing, exact chip may be either 'fsl,mpc5200' or
45'fsl,mpc5200b'.
46
47The soc node
48------------
49This node describes the on chip SOC peripherals. Every mpc5200 based
50board will have this node, and as such there is a common naming
51convention for SOC devices.
52
53Required properties:
54name description
55---- -----------
56ranges Memory range of the internal memory mapped registers.
57 Should be <0 [baseaddr] 0xc000>
58reg Should be <[baseaddr] 0x100>
59compatible mpc5200: "fsl,mpc5200-immr"
60 mpc5200b: "fsl,mpc5200b-immr"
61system-frequency 'fsystem' frequency in Hz; XLB, IPB, USB and PCI
62 clocks are derived from the fsystem clock.
63bus-frequency IPB bus frequency in Hz. Clock rate
64 used by most of the soc devices.
65
66soc child nodes
67---------------
68Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
69
70Note: The tables below show the value for the mpc5200. A mpc5200b device
71tree should use the "fsl,mpc5200b-<device>","fsl,mpc5200-<device>" form.
72
73Required soc5200 child nodes:
74name compatible Description
75---- ---------- -----------
76cdm@<addr> fsl,mpc5200-cdm Clock Distribution
77interrupt-controller@<addr> fsl,mpc5200-pic need an interrupt
78 controller to boot
79bestcomm@<addr> fsl,mpc5200-bestcomm Bestcomm DMA controller
80
81Recommended soc5200 child nodes; populate as needed for your board
82name compatible Description
83---- ---------- -----------
84timer@<addr> fsl,mpc5200-gpt General purpose timers
85gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio controller
86gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio controller
87rtc@<addr> fsl,mpc5200-rtc Real time clock
88mscan@<addr> fsl,mpc5200-mscan CAN bus controller
89pci@<addr> fsl,mpc5200-pci PCI bridge
90serial@<addr> fsl,mpc5200-psc-uart PSC in serial mode
91i2s@<addr> fsl,mpc5200-psc-i2s PSC in i2s mode
92ac97@<addr> fsl,mpc5200-psc-ac97 PSC in ac97 mode
93spi@<addr> fsl,mpc5200-psc-spi PSC in spi mode
94irda@<addr> fsl,mpc5200-psc-irda PSC in IrDA mode
95spi@<addr> fsl,mpc5200-spi MPC5200 spi device
96ethernet@<addr> fsl,mpc5200-fec MPC5200 ethernet device
97ata@<addr> fsl,mpc5200-ata IDE ATA interface
98i2c@<addr> fsl,mpc5200-i2c I2C controller
99usb@<addr> fsl,mpc5200-ohci,ohci-be USB controller
100xlb@<addr> fsl,mpc5200-xlb XLB arbitrator
101
102fsl,mpc5200-gpt nodes
103---------------------
104On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
105design supports the internal wdt, then the device node for GPT0 should
106include the empty property 'fsl,has-wdt'.
107
108An mpc5200-gpt can be used as a single line GPIO controller. To do so,
109add the following properties to the gpt node:
110 gpio-controller;
111 #gpio-cells = <2>;
112When referencing the GPIO line from another node, the first cell must always
113be zero and the second cell represents the gpio flags and described in the
114gpio device tree binding.
115
116An mpc5200-gpt can be used as a single line edge sensitive interrupt
117controller. To do so, add the following properties to the gpt node:
118 interrupt-controller;
119 #interrupt-cells = <1>;
120When referencing the IRQ line from another node, the cell represents the
121sense mode; 1 for edge rising, 2 for edge falling.
122
123fsl,mpc5200-psc nodes
124---------------------
125The PSCs should include a cell-index which is the index of the PSC in
126hardware. cell-index is used to determine which shared SoC registers to
127use when setting up PSC clocking. cell-index number starts at '0'. ie:
128 PSC1 has 'cell-index = <0>'
129 PSC4 has 'cell-index = <3>'
130
131PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in
132i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
133compatible field.
134
135
136fsl,mpc5200-gpio and fsl,mpc5200-gpio-wkup nodes
137------------------------------------------------
138Each GPIO controller node should have the empty property gpio-controller and
139#gpio-cells set to 2. First cell is the GPIO number which is interpreted
140according to the bit numbers in the GPIO control registers. The second cell
141is for flags which is currently unused.
142
143fsl,mpc5200-fec nodes
144---------------------
145The FEC node can specify one of the following properties to configure
146the MII link:
147- fsl,7-wire-mode - An empty property that specifies the link uses 7-wire
148 mode instead of MII
149- current-speed - Specifies that the MII should be configured for a fixed
150 speed. This property should contain two cells. The
151 first cell specifies the speed in Mbps and the second
152 should be '0' for half duplex and '1' for full duplex
153- phy-handle - Contains a phandle to an Ethernet PHY.
154
155Interrupt controller (fsl,mpc5200-pic) node
156-------------------------------------------
157The mpc5200 pic binding splits hardware IRQ numbers into two levels. The
158split reflects the layout of the PIC hardware itself, which groups
159interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
160Bestcomm dma engine has it's own set of interrupt sources which are
161cascaded off of peripheral interrupt 0, which the driver interprets as a
162fourth group, SDMA.
163
164The interrupts property for device nodes using the mpc5200 pic consists
165of three cells; <L1 L2 level>
166
167 L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
168 L2 := interrupt number; directly mapped from the value in the
169 "ICTL PerStat, MainStat, CritStat Encoded Register"
170 level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
171
172For external IRQs, use the following interrupt property values (how to
173specify external interrupts is a frequently asked question):
174External interrupts:
175 external irq0: interrupts = <0 0 n>;
176 external irq1: interrupts = <1 1 n>;
177 external irq2: interrupts = <1 2 n>;
178 external irq3: interrupts = <1 3 n>;
179'n' is sense (0: level high, 1: edge rising, 2: edge falling 3: level low)
180
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
deleted file mode 100644
index 6f12f1c79c0c..000000000000
--- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ /dev/null
@@ -1,277 +0,0 @@
1MPC5200 Device Tree Bindings
2----------------------------
3
4(c) 2006-2007 Secret Lab Technologies Ltd
5Grant Likely <grant.likely at secretlab.ca>
6
7********** DRAFT ***********
8* WARNING: Do not depend on the stability of these bindings just yet.
9* The MPC5200 device tree conventions are still in flux
10* Keep an eye on the linuxppc-dev mailing list for more details
11********** DRAFT ***********
12
13I - Introduction
14================
15Boards supported by the arch/powerpc architecture require device tree be
16passed by the boot loader to the kernel at boot time. The device tree
17describes what devices are present on the board and how they are
18connected. The device tree can either be passed as a binary blob (as
19described in Documentation/powerpc/booting-without-of.txt), or passed
20by Open Firmware (IEEE 1275) compatible firmware using an OF compatible
21client interface API.
22
23This document specifies the requirements on the device-tree for mpc5200
24based boards. These requirements are above and beyond the details
25specified in either the Open Firmware spec or booting-without-of.txt
26
27All new mpc5200-based boards are expected to match this document. In
28cases where this document is not sufficient to support a new board port,
29this document should be updated as part of adding the new board support.
30
31II - Philosophy
32===============
33The core of this document is naming convention. The whole point of
34defining this convention is to reduce or eliminate the number of
35special cases required to support a 5200 board. If all 5200 boards
36follow the same convention, then generic 5200 support code will work
37rather than coding special cases for each new board.
38
39This section tries to capture the thought process behind why the naming
40convention is what it is.
41
421. names
43---------
44There is strong convention/requirements already established for children
45of the root node. 'cpus' describes the processor cores, 'memory'
46describes memory, and 'chosen' provides boot configuration. Other nodes
47are added to describe devices attached to the processor local bus.
48
49Following convention already established with other system-on-chip
50processors, 5200 device trees should use the name 'soc5200' for the
51parent node of on chip devices, and the root node should be its parent.
52
53Child nodes are typically named after the configured function. ie.
54the FEC node is named 'ethernet', and a PSC in uart mode is named 'serial'.
55
562. device_type property
57-----------------------
58similar to the node name convention above; the device_type reflects the
59configured function of a device. ie. 'serial' for a uart and 'spi' for
60an spi controller. However, while node names *should* reflect the
61configured function, device_type *must* match the configured function
62exactly.
63
643. compatible property
65----------------------
66Since device_type isn't enough to match devices to drivers, there also
67needs to be a naming convention for the compatible property. Compatible
68is an list of device descriptions sorted from specific to generic. For
69the mpc5200, the required format for each compatible value is
70<chip>-<device>[-<mode>]. The OS should be able to match a device driver
71to the device based solely on the compatible value. If two drivers
72match on the compatible list; the 'most compatible' driver should be
73selected.
74
75The split between the MPC5200 and the MPC5200B leaves a bit of a
76conundrum. How should the compatible property be set up to provide
77maximum compatibility information; but still accurately describe the
78chip? For the MPC5200; the answer is easy. Most of the SoC devices
79originally appeared on the MPC5200. Since they didn't exist anywhere
80else; the 5200 compatible properties will contain only one item;
81"mpc5200-<device>".
82
83The 5200B is almost the same as the 5200, but not quite. It fixes
84silicon bugs and it adds a small number of enhancements. Most of the
85devices either provide exactly the same interface as on the 5200. A few
86devices have extra functions but still have a backwards compatible mode.
87To express this information as completely as possible, 5200B device trees
88should have two items in the compatible list;
89"mpc5200b-<device>\0mpc5200-<device>". It is *strongly* recommended
90that 5200B device trees follow this convention (instead of only listing
91the base mpc5200 item).
92
93If another chip appear on the market with one of the mpc5200 SoC
94devices, then the compatible list should include mpc5200-<device>.
95
96ie. ethernet on mpc5200: compatible = "mpc5200-ethernet"
97 ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc5200-ethernet"
98
99Modal devices, like PSCs, also append the configured function to the
100end of the compatible field. ie. A PSC in i2s mode would specify
101"mpc5200-psc-i2s", not "mpc5200-i2s". This convention is chosen to
102avoid naming conflicts with non-psc devices providing the same
103function. For example, "mpc5200-spi" and "mpc5200-psc-spi" describe
104the mpc5200 simple spi device and a PSC spi mode respectively.
105
106If the soc device is more generic and present on other SOCs, the
107compatible property can specify the more generic device type also.
108
109ie. mscan: compatible = "mpc5200-mscan\0fsl,mscan";
110
111At the time of writing, exact chip may be either 'mpc5200' or
112'mpc5200b'.
113
114Device drivers should always try to match as generically as possible.
115
116III - Structure
117===============
118The device tree for an mpc5200 board follows the structure defined in
119booting-without-of.txt with the following additional notes:
120
1210) the root node
122----------------
123Typical root description node; see booting-without-of
124
1251) The cpus node
126----------------
127The cpus node follows the basic layout described in booting-without-of.
128The bus-frequency property holds the XLB bus frequency
129The clock-frequency property holds the core frequency
130
1312) The memory node
132------------------
133Typical memory description node; see booting-without-of.
134
1353) The soc5200 node
136-------------------
137This node describes the on chip SOC peripherals. Every mpc5200 based
138board will have this node, and as such there is a common naming
139convention for SOC devices.
140
141Required properties:
142name type description
143---- ---- -----------
144device_type string must be "soc"
145ranges int should be <0 baseaddr baseaddr+10000>
146reg int must be <baseaddr 10000>
147compatible string mpc5200: "mpc5200-soc"
148 mpc5200b: "mpc5200b-soc\0mpc5200-soc"
149system-frequency int Fsystem frequency; source of all
150 other clocks.
151bus-frequency int IPB bus frequency in HZ. Clock rate
152 used by most of the soc devices.
153#interrupt-cells int must be <3>.
154
155Recommended properties:
156name type description
157---- ---- -----------
158model string Exact model of the chip;
159 ie: model="fsl,mpc5200"
160revision string Silicon revision of chip
161 ie: revision="M08A"
162
163The 'model' and 'revision' properties are *strongly* recommended. Having
164them presence acts as a bit of a safety net for working around as yet
165undiscovered bugs on one version of silicon. For example, device drivers
166can use the model and revision properties to decide if a bug fix should
167be turned on.
168
1694) soc5200 child nodes
170----------------------
171Any on chip SOC devices available to Linux must appear as soc5200 child nodes.
172
173Note: The tables below show the value for the mpc5200. A mpc5200b device
174tree should use the "mpc5200b-<device>\0mpc5200-<device> form.
175
176Required soc5200 child nodes:
177name device_type compatible Description
178---- ----------- ---------- -----------
179cdm@<addr> cdm mpc5200-cmd Clock Distribution
180pic@<addr> interrupt-controller mpc5200-pic need an interrupt
181 controller to boot
182bestcomm@<addr> dma-controller mpc5200-bestcomm 5200 pic also requires
183 the bestcomm device
184
185Recommended soc5200 child nodes; populate as needed for your board
186name device_type compatible Description
187---- ----------- ---------- -----------
188gpt@<addr> gpt fsl,mpc5200-gpt General purpose timers
189gpt@<addr> gpt fsl,mpc5200-gpt-gpio General purpose
190 timers in GPIO mode
191gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio
192 controller
193gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio
194 controller
195rtc@<addr> rtc mpc5200-rtc Real time clock
196mscan@<addr> mscan mpc5200-mscan CAN bus controller
197pci@<addr> pci mpc5200-pci PCI bridge
198serial@<addr> serial mpc5200-psc-uart PSC in serial mode
199i2s@<addr> sound mpc5200-psc-i2s PSC in i2s mode
200ac97@<addr> sound mpc5200-psc-ac97 PSC in ac97 mode
201spi@<addr> spi mpc5200-psc-spi PSC in spi mode
202irda@<addr> irda mpc5200-psc-irda PSC in IrDA mode
203spi@<addr> spi mpc5200-spi MPC5200 spi device
204ethernet@<addr> network mpc5200-fec MPC5200 ethernet device
205ata@<addr> ata mpc5200-ata IDE ATA interface
206i2c@<addr> i2c mpc5200-i2c I2C controller
207usb@<addr> usb-ohci-be mpc5200-ohci,ohci-be USB controller
208xlb@<addr> xlb mpc5200-xlb XLB arbitrator
209
210Important child node properties
211name type description
212---- ---- -----------
213cell-index int When multiple devices are present, is the
214 index of the device in the hardware (ie. There
215 are 6 PSC on the 5200 numbered PSC1 to PSC6)
216 PSC1 has 'cell-index = <0>'
217 PSC4 has 'cell-index = <3>'
218
2195) General Purpose Timer nodes (child of soc5200 node)
220On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
221design supports the internal wdt, then the device node for GPT0 should
222include the empty property 'fsl,has-wdt'.
223
2246) PSC nodes (child of soc5200 node)
225PSC nodes can define the optional 'port-number' property to force assignment
226order of serial ports. For example, PSC5 might be physically connected to
227the port labeled 'COM1' and PSC1 wired to 'COM1'. In this case, PSC5 would
228have a "port-number = <0>" property, and PSC1 would have "port-number = <1>".
229
230PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in
231i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
232compatible field.
233
2347) GPIO controller nodes
235Each GPIO controller node should have the empty property gpio-controller and
236#gpio-cells set to 2. First cell is the GPIO number which is interpreted
237according to the bit numbers in the GPIO control registers. The second cell
238is for flags which is currently unsused.
239
2408) FEC nodes
241The FEC node can specify one of the following properties to configure
242the MII link:
243"fsl,7-wire-mode" - An empty property that specifies the link uses 7-wire
244 mode instead of MII
245"current-speed" - Specifies that the MII should be configured for a fixed
246 speed. This property should contain two cells. The
247 first cell specifies the speed in Mbps and the second
248 should be '0' for half duplex and '1' for full duplex
249"phy-handle" - Contains a phandle to an Ethernet PHY.
250
251IV - Extra Notes
252================
253
2541. Interrupt mapping
255--------------------
256The mpc5200 pic driver splits hardware IRQ numbers into two levels. The
257split reflects the layout of the PIC hardware itself, which groups
258interrupts into one of three groups; CRIT, MAIN or PERP. Also, the
259Bestcomm dma engine has it's own set of interrupt sources which are
260cascaded off of peripheral interrupt 0, which the driver interprets as a
261fourth group, SDMA.
262
263The interrupts property for device nodes using the mpc5200 pic consists
264of three cells; <L1 L2 level>
265
266 L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
267 L2 := interrupt number; directly mapped from the value in the
268 "ICTL PerStat, MainStat, CritStat Encoded Register"
269 level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
270
2712. Shared registers
272-------------------
273Some SoC devices share registers between them. ie. the i2c devices use
274a single clock control register, and almost all device are affected by
275the port_config register. Devices which need to manipulate shared regs
276should look to the parent SoC node. The soc node is responsible
277for arbitrating all shared register access.
diff --git a/Documentation/scsi/cxgb3i.txt b/Documentation/scsi/cxgb3i.txt
index 8141fa01978e..7ac8032ee9b2 100644
--- a/Documentation/scsi/cxgb3i.txt
+++ b/Documentation/scsi/cxgb3i.txt
@@ -4,7 +4,7 @@ Introduction
4============ 4============
5 5
6The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc. 6The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc.
7series of products) supports iSCSI acceleration and iSCSI Direct Data Placement 7series of products) support iSCSI acceleration and iSCSI Direct Data Placement
8(DDP) where the hardware handles the expensive byte touching operations, such 8(DDP) where the hardware handles the expensive byte touching operations, such
9as CRC computation and verification, and direct DMA to the final host memory 9as CRC computation and verification, and direct DMA to the final host memory
10destination: 10destination:
@@ -31,9 +31,9 @@ destination:
31 the TCP segments onto the wire. It handles TCP retransmission if 31 the TCP segments onto the wire. It handles TCP retransmission if
32 needed. 32 needed.
33 33
34 On receving, S3 h/w recovers the iSCSI PDU by reassembling TCP 34 On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP
35 segments, separating the header and data, calculating and verifying 35 segments, separating the header and data, calculating and verifying
36 the digests, then forwards the header to the host. The payload data, 36 the digests, then forwarding the header to the host. The payload data,
37 if possible, will be directly placed into the pre-posted host DDP 37 if possible, will be directly placed into the pre-posted host DDP
38 buffer. Otherwise, the payload data will be sent to the host too. 38 buffer. Otherwise, the payload data will be sent to the host too.
39 39
@@ -68,9 +68,8 @@ The following steps need to be taken to accelerates the open-iscsi initiator:
68 sure the ip address is unique in the network. 68 sure the ip address is unique in the network.
69 69
703. edit /etc/iscsi/iscsid.conf 703. edit /etc/iscsi/iscsid.conf
71 The default setting for MaxRecvDataSegmentLength (131072) is too big, 71 The default setting for MaxRecvDataSegmentLength (131072) is too big;
72 replace "node.conn[0].iscsi.MaxRecvDataSegmentLength" to be a value no 72 replace with a value no bigger than 15360 (for example 8192):
73 bigger than 15360 (for example 8192):
74 73
75 node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192 74 node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192
76 75
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index 64eb1100eec1..0f5d26bea80f 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -349,6 +349,7 @@ STAC92HD73*
349STAC92HD83* 349STAC92HD83*
350=========== 350===========
351 ref Reference board 351 ref Reference board
352 mic-ref Reference board with power managment for ports
352 353
353STAC9872 354STAC9872
354======== 355========
diff --git a/Documentation/tracers/mmiotrace.txt b/Documentation/tracers/mmiotrace.txt
index cde23b4a12a1..5731c67abc55 100644
--- a/Documentation/tracers/mmiotrace.txt
+++ b/Documentation/tracers/mmiotrace.txt
@@ -78,12 +78,10 @@ to view your kernel log and look for "mmiotrace has lost events" warning. If
78events were lost, the trace is incomplete. You should enlarge the buffers and 78events were lost, the trace is incomplete. You should enlarge the buffers and
79try again. Buffers are enlarged by first seeing how large the current buffers 79try again. Buffers are enlarged by first seeing how large the current buffers
80are: 80are:
81$ cat /debug/tracing/trace_entries 81$ cat /debug/tracing/buffer_size_kb
82gives you a number. Approximately double this number and write it back, for 82gives you a number. Approximately double this number and write it back, for
83instance: 83instance:
84$ echo 0 > /debug/tracing/tracing_enabled 84$ echo 128000 > /debug/tracing/buffer_size_kb
85$ echo 128000 > /debug/tracing/trace_entries
86$ echo 1 > /debug/tracing/tracing_enabled
87Then start again from the top. 85Then start again from the top.
88 86
89If you are doing a trace for a driver project, e.g. Nouveau, you should also 87If you are doing a trace for a driver project, e.g. Nouveau, you should also
diff --git a/Documentation/usb/dma.txt b/Documentation/usb/dma.txt
index e8b50b7de9d9..cfdcd16e3abf 100644
--- a/Documentation/usb/dma.txt
+++ b/Documentation/usb/dma.txt
@@ -6,8 +6,9 @@ in the kernel usb programming guide (kerneldoc, from the source code).
6API OVERVIEW 6API OVERVIEW
7 7
8The big picture is that USB drivers can continue to ignore most DMA issues, 8The big picture is that USB drivers can continue to ignore most DMA issues,
9though they still must provide DMA-ready buffers (see DMA-mapping.txt). 9though they still must provide DMA-ready buffers (see
10That's how they've worked through the 2.4 (and earlier) kernels. 10Documentation/PCI/PCI-DMA-mapping.txt). That's how they've worked through
11the 2.4 (and earlier) kernels.
11 12
12OR: they can now be DMA-aware. 13OR: they can now be DMA-aware.
13 14
@@ -62,8 +63,8 @@ and effects like cache-trashing can impose subtle penalties.
62 force a consistent memory access ordering by using memory barriers. It's 63 force a consistent memory access ordering by using memory barriers. It's
63 not using a streaming DMA mapping, so it's good for small transfers on 64 not using a streaming DMA mapping, so it's good for small transfers on
64 systems where the I/O would otherwise thrash an IOMMU mapping. (See 65 systems where the I/O would otherwise thrash an IOMMU mapping. (See
65 Documentation/DMA-mapping.txt for definitions of "coherent" and "streaming" 66 Documentation/PCI/PCI-DMA-mapping.txt for definitions of "coherent" and
66 DMA mappings.) 67 "streaming" DMA mappings.)
67 68
68 Asking for 1/Nth of a page (as well as asking for N pages) is reasonably 69 Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
69 space-efficient. 70 space-efficient.
@@ -93,7 +94,7 @@ WORKING WITH EXISTING BUFFERS
93Existing buffers aren't usable for DMA without first being mapped into the 94Existing buffers aren't usable for DMA without first being mapped into the
94DMA address space of the device. However, most buffers passed to your 95DMA address space of the device. However, most buffers passed to your
95driver can safely be used with such DMA mapping. (See the first section 96driver can safely be used with such DMA mapping. (See the first section
96of DMA-mapping.txt, titled "What memory is DMA-able?") 97of Documentation/PCI/PCI-DMA-mapping.txt, titled "What memory is DMA-able?")
97 98
98- When you're using scatterlists, you can map everything at once. On some 99- When you're using scatterlists, you can map everything at once. On some
99 systems, this kicks in an IOMMU and turns the scatterlists into single 100 systems, this kicks in an IOMMU and turns the scatterlists into single
diff --git a/Documentation/video4linux/v4lgrab.c b/Documentation/video4linux/v4lgrab.c
index 079b628481cf..d6e70bef8ad0 100644
--- a/Documentation/video4linux/v4lgrab.c
+++ b/Documentation/video4linux/v4lgrab.c
@@ -4,12 +4,21 @@
4 * 4 *
5 * Compile with: 5 * Compile with:
6 * gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab 6 * gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab
7 * Use as: 7 * Use as:
8 * v4lgrab >image.ppm 8 * v4lgrab >image.ppm
9 * 9 *
10 * Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org> 10 * Copyright (C) 1998-05-03, Phil Blundell <philb@gnu.org>
11 * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c 11 * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c
12 * with minor modifications (Dave Forrest, drf5n@virginia.edu). 12 * with minor modifications (Dave Forrest, drf5n@virginia.edu).
13 *
14 *
15 * For some cameras you may need to pre-load libv4l to perform
16 * the necessary decompression, e.g.:
17 *
18 * export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
19 * ./v4lgrab >image.ppm
20 *
21 * see http://hansdegoede.livejournal.com/3636.html for details.
13 * 22 *
14 */ 23 */
15 24
@@ -24,7 +33,7 @@
24#include <linux/types.h> 33#include <linux/types.h>
25#include <linux/videodev.h> 34#include <linux/videodev.h>
26 35
27#define FILE "/dev/video0" 36#define VIDEO_DEV "/dev/video0"
28 37
29/* Stole this from tvset.c */ 38/* Stole this from tvset.c */
30 39
@@ -90,7 +99,7 @@ int get_brightness_adj(unsigned char *image, long size, int *brightness) {
90 99
91int main(int argc, char ** argv) 100int main(int argc, char ** argv)
92{ 101{
93 int fd = open(FILE, O_RDONLY), f; 102 int fd = open(VIDEO_DEV, O_RDONLY), f;
94 struct video_capability cap; 103 struct video_capability cap;
95 struct video_window win; 104 struct video_window win;
96 struct video_picture vpic; 105 struct video_picture vpic;
@@ -100,13 +109,13 @@ int main(int argc, char ** argv)
100 unsigned int i, src_depth; 109 unsigned int i, src_depth;
101 110
102 if (fd < 0) { 111 if (fd < 0) {
103 perror(FILE); 112 perror(VIDEO_DEV);
104 exit(1); 113 exit(1);
105 } 114 }
106 115
107 if (ioctl(fd, VIDIOCGCAP, &cap) < 0) { 116 if (ioctl(fd, VIDIOCGCAP, &cap) < 0) {
108 perror("VIDIOGCAP"); 117 perror("VIDIOGCAP");
109 fprintf(stderr, "(" FILE " not a video4linux device?)\n"); 118 fprintf(stderr, "(" VIDEO_DEV " not a video4linux device?)\n");
110 close(fd); 119 close(fd);
111 exit(1); 120 exit(1);
112 } 121 }
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-18 02:51:31 -0500