diff options
author | Mauro Carvalho Chehab <mchehab@s-opensource.com> | 2016-09-19 15:35:26 -0400 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@s-opensource.com> | 2016-09-19 15:36:41 -0400 |
commit | 142a0e11b52c18a82c4fe55132b762005dda05c0 (patch) | |
tree | f7f86ccc559311f0ae7fe42f479bea50bc543c59 | |
parent | 6ff7b7aff34a4c21953ebf360d8941aeec0a215e (diff) | |
parent | 2cfd100bf2f7d979c0ecaf0298f3de2f03ac9d5d (diff) |
Merge tag 'docs-next' of git://git.lwn.net/linux.git into patchwork
Merge back from docs-next in order to get the cdomain extension.
With such extension, the number of warnings when building docs
in nitpick mode reduced from 22 to 2 warnings.
* docs-next/docs-next:
docs/driver-model: fix typo
DMA-API-HOWTO: <asm/generic/scatterlist.h> is no more
doc-rst:c-domain: function-like macros arguments
doc-rst:c-domain: fix sphinx version incompatibility
Documentation/filesystems: Fixed typo
docs: Don't format internal MPT docs
docs: split up serial-interfaces.rst
docs: Pull the HSI documentation together
docs: Special-case function-pointer parameters in kernel-doc
docs: make kernel-doc handle varargs properly
x86: fix memory ranges in mm documentation
documentation/scsi: Remove nodisconnect parameter
doc: ioctl: Add some clarifications to botching-up-ioctls
docs: split up the driver book
Docs: sphinxify device-drivers.tmpl
25 files changed, 819 insertions, 620 deletions
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 781024ef9050..494ffac655ee 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt | |||
@@ -931,10 +931,8 @@ to "Closing". | |||
931 | 931 | ||
932 | 1) Struct scatterlist requirements. | 932 | 1) Struct scatterlist requirements. |
933 | 933 | ||
934 | Don't invent the architecture specific struct scatterlist; just use | 934 | You need to enable CONFIG_NEED_SG_DMA_LENGTH if the architecture |
935 | <asm-generic/scatterlist.h>. You need to enable | 935 | supports IOMMUs (including software IOMMU). |
936 | CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs | ||
937 | (including software IOMMU). | ||
938 | 936 | ||
939 | 2) ARCH_DMA_MINALIGN | 937 | 2) ARCH_DMA_MINALIGN |
940 | 938 | ||
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index a558dfcc9e2d..736f5916daea 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 | ||
9 | DOCBOOKS := z8530book.xml device-drivers.xml \ | 9 | DOCBOOKS := z8530book.xml \ |
10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ | 10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ |
11 | writing_usb_driver.xml networking.xml \ | 11 | 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 deleted file mode 100644 index 9c10030eb2be..000000000000 --- a/Documentation/DocBook/device-drivers.tmpl +++ /dev/null | |||
@@ -1,521 +0,0 @@ | |||
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.h | ||
49 | </sect1> | ||
50 | |||
51 | <sect1><title>Delaying, scheduling, and timer routines</title> | ||
52 | !Iinclude/linux/sched.h | ||
53 | !Ekernel/sched/core.c | ||
54 | !Ikernel/sched/cpupri.c | ||
55 | !Ikernel/sched/fair.c | ||
56 | !Iinclude/linux/completion.h | ||
57 | !Ekernel/time/timer.c | ||
58 | </sect1> | ||
59 | <sect1><title>Wait queues and Wake events</title> | ||
60 | !Iinclude/linux/wait.h | ||
61 | !Ekernel/sched/wait.c | ||
62 | </sect1> | ||
63 | <sect1><title>High-resolution timers</title> | ||
64 | !Iinclude/linux/ktime.h | ||
65 | !Iinclude/linux/hrtimer.h | ||
66 | !Ekernel/time/hrtimer.c | ||
67 | </sect1> | ||
68 | <sect1><title>Workqueues and Kevents</title> | ||
69 | !Iinclude/linux/workqueue.h | ||
70 | !Ekernel/workqueue.c | ||
71 | </sect1> | ||
72 | <sect1><title>Internal Functions</title> | ||
73 | !Ikernel/exit.c | ||
74 | !Ikernel/signal.c | ||
75 | !Iinclude/linux/kthread.h | ||
76 | !Ekernel/kthread.c | ||
77 | </sect1> | ||
78 | |||
79 | <sect1><title>Kernel objects manipulation</title> | ||
80 | <!-- | ||
81 | X!Iinclude/linux/kobject.h | ||
82 | --> | ||
83 | !Elib/kobject.c | ||
84 | </sect1> | ||
85 | |||
86 | <sect1><title>Kernel utility functions</title> | ||
87 | !Iinclude/linux/kernel.h | ||
88 | !Ekernel/printk/printk.c | ||
89 | !Ekernel/panic.c | ||
90 | !Ekernel/sys.c | ||
91 | !Ekernel/rcu/srcu.c | ||
92 | !Ekernel/rcu/tree.c | ||
93 | !Ekernel/rcu/tree_plugin.h | ||
94 | !Ekernel/rcu/update.c | ||
95 | </sect1> | ||
96 | |||
97 | <sect1><title>Device Resource Management</title> | ||
98 | !Edrivers/base/devres.c | ||
99 | </sect1> | ||
100 | |||
101 | </chapter> | ||
102 | |||
103 | <chapter id="devdrivers"> | ||
104 | <title>Device drivers infrastructure</title> | ||
105 | <sect1><title>The Basic Device Driver-Model Structures </title> | ||
106 | !Iinclude/linux/device.h | ||
107 | </sect1> | ||
108 | <sect1><title>Device Drivers Base</title> | ||
109 | !Idrivers/base/init.c | ||
110 | !Edrivers/base/driver.c | ||
111 | !Edrivers/base/core.c | ||
112 | !Edrivers/base/syscore.c | ||
113 | !Edrivers/base/class.c | ||
114 | !Idrivers/base/node.c | ||
115 | !Edrivers/base/firmware_class.c | ||
116 | !Edrivers/base/transport_class.c | ||
117 | <!-- Cannot be included, because | ||
118 | attribute_container_add_class_device_adapter | ||
119 | and attribute_container_classdev_to_container | ||
120 | exceed allowed 44 characters maximum | ||
121 | X!Edrivers/base/attribute_container.c | ||
122 | --> | ||
123 | !Edrivers/base/dd.c | ||
124 | <!-- | ||
125 | X!Edrivers/base/interface.c | ||
126 | --> | ||
127 | !Iinclude/linux/platform_device.h | ||
128 | !Edrivers/base/platform.c | ||
129 | !Edrivers/base/bus.c | ||
130 | </sect1> | ||
131 | <sect1> | ||
132 | <title>Buffer Sharing and Synchronization</title> | ||
133 | <para> | ||
134 | The dma-buf subsystem provides the framework for sharing buffers | ||
135 | for hardware (DMA) access across multiple device drivers and | ||
136 | subsystems, and for synchronizing asynchronous hardware access. | ||
137 | </para> | ||
138 | <para> | ||
139 | This is used, for example, by drm "prime" multi-GPU support, but | ||
140 | is of course not limited to GPU use cases. | ||
141 | </para> | ||
142 | <para> | ||
143 | The three main components of this are: (1) dma-buf, representing | ||
144 | a sg_table and exposed to userspace as a file descriptor to allow | ||
145 | passing between devices, (2) fence, which provides a mechanism | ||
146 | to signal when one device as finished access, and (3) reservation, | ||
147 | which manages the shared or exclusive fence(s) associated with | ||
148 | the buffer. | ||
149 | </para> | ||
150 | <sect2><title>dma-buf</title> | ||
151 | !Edrivers/dma-buf/dma-buf.c | ||
152 | !Iinclude/linux/dma-buf.h | ||
153 | </sect2> | ||
154 | <sect2><title>reservation</title> | ||
155 | !Pdrivers/dma-buf/reservation.c Reservation Object Overview | ||
156 | !Edrivers/dma-buf/reservation.c | ||
157 | !Iinclude/linux/reservation.h | ||
158 | </sect2> | ||
159 | <sect2><title>fence</title> | ||
160 | !Edrivers/dma-buf/fence.c | ||
161 | !Iinclude/linux/fence.h | ||
162 | !Edrivers/dma-buf/seqno-fence.c | ||
163 | !Iinclude/linux/seqno-fence.h | ||
164 | !Edrivers/dma-buf/fence-array.c | ||
165 | !Iinclude/linux/fence-array.h | ||
166 | !Edrivers/dma-buf/reservation.c | ||
167 | !Iinclude/linux/reservation.h | ||
168 | !Edrivers/dma-buf/sync_file.c | ||
169 | !Iinclude/linux/sync_file.h | ||
170 | </sect2> | ||
171 | </sect1> | ||
172 | <sect1><title>Device Drivers DMA Management</title> | ||
173 | !Edrivers/base/dma-coherent.c | ||
174 | !Edrivers/base/dma-mapping.c | ||
175 | </sect1> | ||
176 | <sect1><title>Device Drivers Power Management</title> | ||
177 | !Edrivers/base/power/main.c | ||
178 | </sect1> | ||
179 | <sect1><title>Device Drivers ACPI Support</title> | ||
180 | <!-- Internal functions only | ||
181 | X!Edrivers/acpi/sleep/main.c | ||
182 | X!Edrivers/acpi/sleep/wakeup.c | ||
183 | X!Edrivers/acpi/motherboard.c | ||
184 | X!Edrivers/acpi/bus.c | ||
185 | --> | ||
186 | !Edrivers/acpi/scan.c | ||
187 | !Idrivers/acpi/scan.c | ||
188 | <!-- No correct structured comments | ||
189 | X!Edrivers/acpi/pci_bind.c | ||
190 | --> | ||
191 | </sect1> | ||
192 | <sect1><title>Device drivers PnP support</title> | ||
193 | !Idrivers/pnp/core.c | ||
194 | <!-- No correct structured comments | ||
195 | X!Edrivers/pnp/system.c | ||
196 | --> | ||
197 | !Edrivers/pnp/card.c | ||
198 | !Idrivers/pnp/driver.c | ||
199 | !Edrivers/pnp/manager.c | ||
200 | !Edrivers/pnp/support.c | ||
201 | </sect1> | ||
202 | <sect1><title>Userspace IO devices</title> | ||
203 | !Edrivers/uio/uio.c | ||
204 | !Iinclude/linux/uio_driver.h | ||
205 | </sect1> | ||
206 | </chapter> | ||
207 | |||
208 | <chapter id="parportdev"> | ||
209 | <title>Parallel Port Devices</title> | ||
210 | !Iinclude/linux/parport.h | ||
211 | !Edrivers/parport/ieee1284.c | ||
212 | !Edrivers/parport/share.c | ||
213 | !Idrivers/parport/daisy.c | ||
214 | </chapter> | ||
215 | |||
216 | <chapter id="message_devices"> | ||
217 | <title>Message-based devices</title> | ||
218 | <sect1><title>Fusion message devices</title> | ||
219 | !Edrivers/message/fusion/mptbase.c | ||
220 | !Idrivers/message/fusion/mptbase.c | ||
221 | !Edrivers/message/fusion/mptscsih.c | ||
222 | !Idrivers/message/fusion/mptscsih.c | ||
223 | !Idrivers/message/fusion/mptctl.c | ||
224 | !Idrivers/message/fusion/mptspi.c | ||
225 | !Idrivers/message/fusion/mptfc.c | ||
226 | !Idrivers/message/fusion/mptlan.c | ||
227 | </sect1> | ||
228 | </chapter> | ||
229 | |||
230 | <chapter id="snddev"> | ||
231 | <title>Sound Devices</title> | ||
232 | !Iinclude/sound/core.h | ||
233 | !Esound/sound_core.c | ||
234 | !Iinclude/sound/pcm.h | ||
235 | !Esound/core/pcm.c | ||
236 | !Esound/core/device.c | ||
237 | !Esound/core/info.c | ||
238 | !Esound/core/rawmidi.c | ||
239 | !Esound/core/sound.c | ||
240 | !Esound/core/memory.c | ||
241 | !Esound/core/pcm_memory.c | ||
242 | !Esound/core/init.c | ||
243 | !Esound/core/isadma.c | ||
244 | !Esound/core/control.c | ||
245 | !Esound/core/pcm_lib.c | ||
246 | !Esound/core/hwdep.c | ||
247 | !Esound/core/pcm_native.c | ||
248 | !Esound/core/memalloc.c | ||
249 | <!-- FIXME: Removed for now since no structured comments in source | ||
250 | X!Isound/sound_firmware.c | ||
251 | --> | ||
252 | </chapter> | ||
253 | |||
254 | |||
255 | <chapter id="uart16x50"> | ||
256 | <title>16x50 UART Driver</title> | ||
257 | !Edrivers/tty/serial/serial_core.c | ||
258 | !Edrivers/tty/serial/8250/8250_core.c | ||
259 | </chapter> | ||
260 | |||
261 | <chapter id="fbdev"> | ||
262 | <title>Frame Buffer Library</title> | ||
263 | |||
264 | <para> | ||
265 | The frame buffer drivers depend heavily on four data structures. | ||
266 | These structures are declared in include/linux/fb.h. They are | ||
267 | fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. | ||
268 | The last three can be made available to and from userland. | ||
269 | </para> | ||
270 | |||
271 | <para> | ||
272 | fb_info defines the current state of a particular video card. | ||
273 | Inside fb_info, there exists a fb_ops structure which is a | ||
274 | collection of needed functions to make fbdev and fbcon work. | ||
275 | fb_info is only visible to the kernel. | ||
276 | </para> | ||
277 | |||
278 | <para> | ||
279 | fb_var_screeninfo is used to describe the features of a video card | ||
280 | that are user defined. With fb_var_screeninfo, things such as | ||
281 | depth and the resolution may be defined. | ||
282 | </para> | ||
283 | |||
284 | <para> | ||
285 | The next structure is fb_fix_screeninfo. This defines the | ||
286 | properties of a card that are created when a mode is set and can't | ||
287 | be changed otherwise. A good example of this is the start of the | ||
288 | frame buffer memory. This "locks" the address of the frame buffer | ||
289 | memory, so that it cannot be changed or moved. | ||
290 | </para> | ||
291 | |||
292 | <para> | ||
293 | The last structure is fb_monospecs. In the old API, there was | ||
294 | little importance for fb_monospecs. This allowed for forbidden things | ||
295 | such as setting a mode of 800x600 on a fix frequency monitor. With | ||
296 | the new API, fb_monospecs prevents such things, and if used | ||
297 | correctly, can prevent a monitor from being cooked. fb_monospecs | ||
298 | will not be useful until kernels 2.5.x. | ||
299 | </para> | ||
300 | |||
301 | <sect1><title>Frame Buffer Memory</title> | ||
302 | !Edrivers/video/fbdev/core/fbmem.c | ||
303 | </sect1> | ||
304 | <!-- | ||
305 | <sect1><title>Frame Buffer Console</title> | ||
306 | X!Edrivers/video/console/fbcon.c | ||
307 | </sect1> | ||
308 | --> | ||
309 | <sect1><title>Frame Buffer Colormap</title> | ||
310 | !Edrivers/video/fbdev/core/fbcmap.c | ||
311 | </sect1> | ||
312 | <!-- FIXME: | ||
313 | drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment | ||
314 | out until somebody adds docs. KAO | ||
315 | <sect1><title>Frame Buffer Generic Functions</title> | ||
316 | X!Idrivers/video/fbgen.c | ||
317 | </sect1> | ||
318 | KAO --> | ||
319 | <sect1><title>Frame Buffer Video Mode Database</title> | ||
320 | !Idrivers/video/fbdev/core/modedb.c | ||
321 | !Edrivers/video/fbdev/core/modedb.c | ||
322 | </sect1> | ||
323 | <sect1><title>Frame Buffer Macintosh Video Mode Database</title> | ||
324 | !Edrivers/video/fbdev/macmodes.c | ||
325 | </sect1> | ||
326 | <sect1><title>Frame Buffer Fonts</title> | ||
327 | <para> | ||
328 | Refer to the file lib/fonts/fonts.c for more information. | ||
329 | </para> | ||
330 | <!-- FIXME: Removed for now since no structured comments in source | ||
331 | X!Ilib/fonts/fonts.c | ||
332 | --> | ||
333 | </sect1> | ||
334 | </chapter> | ||
335 | |||
336 | <chapter id="input_subsystem"> | ||
337 | <title>Input Subsystem</title> | ||
338 | <sect1><title>Input core</title> | ||
339 | !Iinclude/linux/input.h | ||
340 | !Edrivers/input/input.c | ||
341 | !Edrivers/input/ff-core.c | ||
342 | !Edrivers/input/ff-memless.c | ||
343 | </sect1> | ||
344 | <sect1><title>Multitouch Library</title> | ||
345 | !Iinclude/linux/input/mt.h | ||
346 | !Edrivers/input/input-mt.c | ||
347 | </sect1> | ||
348 | <sect1><title>Polled input devices</title> | ||
349 | !Iinclude/linux/input-polldev.h | ||
350 | !Edrivers/input/input-polldev.c | ||
351 | </sect1> | ||
352 | <sect1><title>Matrix keyboards/keypads</title> | ||
353 | !Iinclude/linux/input/matrix_keypad.h | ||
354 | </sect1> | ||
355 | <sect1><title>Sparse keymap support</title> | ||
356 | !Iinclude/linux/input/sparse-keymap.h | ||
357 | !Edrivers/input/sparse-keymap.c | ||
358 | </sect1> | ||
359 | </chapter> | ||
360 | |||
361 | <chapter id="spi"> | ||
362 | <title>Serial Peripheral Interface (SPI)</title> | ||
363 | <para> | ||
364 | SPI is the "Serial Peripheral Interface", widely used with | ||
365 | embedded systems because it is a simple and efficient | ||
366 | interface: basically a multiplexed shift register. | ||
367 | Its three signal wires hold a clock (SCK, often in the range | ||
368 | of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and | ||
369 | a "Master In, Slave Out" (MISO) data line. | ||
370 | SPI is a full duplex protocol; for each bit shifted out the | ||
371 | MOSI line (one per clock) another is shifted in on the MISO line. | ||
372 | Those bits are assembled into words of various sizes on the | ||
373 | way to and from system memory. | ||
374 | An additional chipselect line is usually active-low (nCS); | ||
375 | four signals are normally used for each peripheral, plus | ||
376 | sometimes an interrupt. | ||
377 | </para> | ||
378 | <para> | ||
379 | The SPI bus facilities listed here provide a generalized | ||
380 | interface to declare SPI busses and devices, manage them | ||
381 | according to the standard Linux driver model, and perform | ||
382 | input/output operations. | ||
383 | At this time, only "master" side interfaces are supported, | ||
384 | where Linux talks to SPI peripherals and does not implement | ||
385 | such a peripheral itself. | ||
386 | (Interfaces to support implementing SPI slaves would | ||
387 | necessarily look different.) | ||
388 | </para> | ||
389 | <para> | ||
390 | The programming interface is structured around two kinds of driver, | ||
391 | and two kinds of device. | ||
392 | A "Controller Driver" abstracts the controller hardware, which may | ||
393 | be as simple as a set of GPIO pins or as complex as a pair of FIFOs | ||
394 | connected to dual DMA engines on the other side of the SPI shift | ||
395 | register (maximizing throughput). Such drivers bridge between | ||
396 | whatever bus they sit on (often the platform bus) and SPI, and | ||
397 | expose the SPI side of their device as a | ||
398 | <structname>struct spi_master</structname>. | ||
399 | SPI devices are children of that master, represented as a | ||
400 | <structname>struct spi_device</structname> and manufactured from | ||
401 | <structname>struct spi_board_info</structname> descriptors which | ||
402 | are usually provided by board-specific initialization code. | ||
403 | A <structname>struct spi_driver</structname> is called a | ||
404 | "Protocol Driver", and is bound to a spi_device using normal | ||
405 | driver model calls. | ||
406 | </para> | ||
407 | <para> | ||
408 | The I/O model is a set of queued messages. Protocol drivers | ||
409 | submit one or more <structname>struct spi_message</structname> | ||
410 | objects, which are processed and completed asynchronously. | ||
411 | (There are synchronous wrappers, however.) Messages are | ||
412 | built from one or more <structname>struct spi_transfer</structname> | ||
413 | objects, each of which wraps a full duplex SPI transfer. | ||
414 | A variety of protocol tweaking options are needed, because | ||
415 | different chips adopt very different policies for how they | ||
416 | use the bits transferred with SPI. | ||
417 | </para> | ||
418 | !Iinclude/linux/spi/spi.h | ||
419 | !Fdrivers/spi/spi.c spi_register_board_info | ||
420 | !Edrivers/spi/spi.c | ||
421 | </chapter> | ||
422 | |||
423 | <chapter id="i2c"> | ||
424 | <title>I<superscript>2</superscript>C and SMBus Subsystem</title> | ||
425 | |||
426 | <para> | ||
427 | I<superscript>2</superscript>C (or without fancy typography, "I2C") | ||
428 | is an acronym for the "Inter-IC" bus, a simple bus protocol which is | ||
429 | widely used where low data rate communications suffice. | ||
430 | Since it's also a licensed trademark, some vendors use another | ||
431 | name (such as "Two-Wire Interface", TWI) for the same bus. | ||
432 | I2C only needs two signals (SCL for clock, SDA for data), conserving | ||
433 | board real estate and minimizing signal quality issues. | ||
434 | Most I2C devices use seven bit addresses, and bus speeds of up | ||
435 | to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet | ||
436 | found wide use. | ||
437 | I2C is a multi-master bus; open drain signaling is used to | ||
438 | arbitrate between masters, as well as to handshake and to | ||
439 | synchronize clocks from slower clients. | ||
440 | </para> | ||
441 | |||
442 | <para> | ||
443 | The Linux I2C programming interfaces support only the master | ||
444 | side of bus interactions, not the slave side. | ||
445 | The programming interface is structured around two kinds of driver, | ||
446 | and two kinds of device. | ||
447 | An I2C "Adapter Driver" abstracts the controller hardware; it binds | ||
448 | to a physical device (perhaps a PCI device or platform_device) and | ||
449 | exposes a <structname>struct i2c_adapter</structname> representing | ||
450 | each I2C bus segment it manages. | ||
451 | On each I2C bus segment will be I2C devices represented by a | ||
452 | <structname>struct i2c_client</structname>. Those devices will | ||
453 | be bound to a <structname>struct i2c_driver</structname>, | ||
454 | which should follow the standard Linux driver model. | ||
455 | (At this writing, a legacy model is more widely used.) | ||
456 | There are functions to perform various I2C protocol operations; at | ||
457 | this writing all such functions are usable only from task context. | ||
458 | </para> | ||
459 | |||
460 | <para> | ||
461 | The System Management Bus (SMBus) is a sibling protocol. Most SMBus | ||
462 | systems are also I2C conformant. The electrical constraints are | ||
463 | tighter for SMBus, and it standardizes particular protocol messages | ||
464 | and idioms. Controllers that support I2C can also support most | ||
465 | SMBus operations, but SMBus controllers don't support all the protocol | ||
466 | options that an I2C controller will. | ||
467 | There are functions to perform various SMBus protocol operations, | ||
468 | either using I2C primitives or by issuing SMBus commands to | ||
469 | i2c_adapter devices which don't support those I2C operations. | ||
470 | </para> | ||
471 | |||
472 | !Iinclude/linux/i2c.h | ||
473 | !Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info | ||
474 | !Edrivers/i2c/i2c-core.c | ||
475 | </chapter> | ||
476 | |||
477 | <chapter id="hsi"> | ||
478 | <title>High Speed Synchronous Serial Interface (HSI)</title> | ||
479 | |||
480 | <para> | ||
481 | High Speed Synchronous Serial Interface (HSI) is a | ||
482 | serial interface mainly used for connecting application | ||
483 | engines (APE) with cellular modem engines (CMT) in cellular | ||
484 | handsets. | ||
485 | |||
486 | HSI provides multiplexing for up to 16 logical channels, | ||
487 | low-latency and full duplex communication. | ||
488 | </para> | ||
489 | |||
490 | !Iinclude/linux/hsi/hsi.h | ||
491 | !Edrivers/hsi/hsi_core.c | ||
492 | </chapter> | ||
493 | |||
494 | <chapter id="pwm"> | ||
495 | <title>Pulse-Width Modulation (PWM)</title> | ||
496 | <para> | ||
497 | Pulse-width modulation is a modulation technique primarily used to | ||
498 | control power supplied to electrical devices. | ||
499 | </para> | ||
500 | <para> | ||
501 | The PWM framework provides an abstraction for providers and consumers | ||
502 | of PWM signals. A controller that provides one or more PWM signals is | ||
503 | registered as <structname>struct pwm_chip</structname>. Providers are | ||
504 | expected to embed this structure in a driver-specific structure. This | ||
505 | structure contains fields that describe a particular chip. | ||
506 | </para> | ||
507 | <para> | ||
508 | A chip exposes one or more PWM signal sources, each of which exposed | ||
509 | as a <structname>struct pwm_device</structname>. Operations can be | ||
510 | performed on PWM devices to control the period, duty cycle, polarity | ||
511 | and active state of the signal. | ||
512 | </para> | ||
513 | <para> | ||
514 | Note that PWM devices are exclusive resources: they can always only be | ||
515 | used by one consumer at a time. | ||
516 | </para> | ||
517 | !Iinclude/linux/pwm.h | ||
518 | !Edrivers/pwm/core.c | ||
519 | </chapter> | ||
520 | |||
521 | </book> | ||
diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst new file mode 100644 index 000000000000..935b9b8d456c --- /dev/null +++ b/Documentation/driver-api/basics.rst | |||
@@ -0,0 +1,120 @@ | |||
1 | Driver Basics | ||
2 | ============= | ||
3 | |||
4 | Driver Entry and Exit points | ||
5 | ---------------------------- | ||
6 | |||
7 | .. kernel-doc:: include/linux/init.h | ||
8 | :internal: | ||
9 | |||
10 | Atomic and pointer manipulation | ||
11 | ------------------------------- | ||
12 | |||
13 | .. kernel-doc:: arch/x86/include/asm/atomic.h | ||
14 | :internal: | ||
15 | |||
16 | Delaying, scheduling, and timer routines | ||
17 | ---------------------------------------- | ||
18 | |||
19 | .. kernel-doc:: include/linux/sched.h | ||
20 | :internal: | ||
21 | |||
22 | .. kernel-doc:: kernel/sched/core.c | ||
23 | :export: | ||
24 | |||
25 | .. kernel-doc:: kernel/sched/cpupri.c | ||
26 | :internal: | ||
27 | |||
28 | .. kernel-doc:: kernel/sched/fair.c | ||
29 | :internal: | ||
30 | |||
31 | .. kernel-doc:: include/linux/completion.h | ||
32 | :internal: | ||
33 | |||
34 | .. kernel-doc:: kernel/time/timer.c | ||
35 | :export: | ||
36 | |||
37 | Wait queues and Wake events | ||
38 | --------------------------- | ||
39 | |||
40 | .. kernel-doc:: include/linux/wait.h | ||
41 | :internal: | ||
42 | |||
43 | .. kernel-doc:: kernel/sched/wait.c | ||
44 | :export: | ||
45 | |||
46 | High-resolution timers | ||
47 | ---------------------- | ||
48 | |||
49 | .. kernel-doc:: include/linux/ktime.h | ||
50 | :internal: | ||
51 | |||
52 | .. kernel-doc:: include/linux/hrtimer.h | ||
53 | :internal: | ||
54 | |||
55 | .. kernel-doc:: kernel/time/hrtimer.c | ||
56 | :export: | ||
57 | |||
58 | Workqueues and Kevents | ||
59 | ---------------------- | ||
60 | |||
61 | .. kernel-doc:: include/linux/workqueue.h | ||
62 | :internal: | ||
63 | |||
64 | .. kernel-doc:: kernel/workqueue.c | ||
65 | :export: | ||
66 | |||
67 | Internal Functions | ||
68 | ------------------ | ||
69 | |||
70 | .. kernel-doc:: kernel/exit.c | ||
71 | :internal: | ||
72 | |||
73 | .. kernel-doc:: kernel/signal.c | ||
74 | :internal: | ||
75 | |||
76 | .. kernel-doc:: include/linux/kthread.h | ||
77 | :internal: | ||
78 | |||
79 | .. kernel-doc:: kernel/kthread.c | ||
80 | :export: | ||
81 | |||
82 | Kernel objects manipulation | ||
83 | --------------------------- | ||
84 | |||
85 | .. kernel-doc:: lib/kobject.c | ||
86 | :export: | ||
87 | |||
88 | Kernel utility functions | ||
89 | ------------------------ | ||
90 | |||
91 | .. kernel-doc:: include/linux/kernel.h | ||
92 | :internal: | ||
93 | |||
94 | .. kernel-doc:: kernel/printk/printk.c | ||
95 | :export: | ||
96 | |||
97 | .. kernel-doc:: kernel/panic.c | ||
98 | :export: | ||
99 | |||
100 | .. kernel-doc:: kernel/sys.c | ||
101 | :export: | ||
102 | |||
103 | .. kernel-doc:: kernel/rcu/srcu.c | ||
104 | :export: | ||
105 | |||
106 | .. kernel-doc:: kernel/rcu/tree.c | ||
107 | :export: | ||
108 | |||
109 | .. kernel-doc:: kernel/rcu/tree_plugin.h | ||
110 | :export: | ||
111 | |||
112 | .. kernel-doc:: kernel/rcu/update.c | ||
113 | :export: | ||
114 | |||
115 | Device Resource Management | ||
116 | -------------------------- | ||
117 | |||
118 | .. kernel-doc:: drivers/base/devres.c | ||
119 | :export: | ||
120 | |||
diff --git a/Documentation/driver-api/frame-buffer.rst b/Documentation/driver-api/frame-buffer.rst new file mode 100644 index 000000000000..9dd3060f027d --- /dev/null +++ b/Documentation/driver-api/frame-buffer.rst | |||
@@ -0,0 +1,62 @@ | |||
1 | Frame Buffer Library | ||
2 | ==================== | ||
3 | |||
4 | The frame buffer drivers depend heavily on four data structures. These | ||
5 | structures are declared in include/linux/fb.h. They are fb_info, | ||
6 | fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. The last | ||
7 | three can be made available to and from userland. | ||
8 | |||
9 | fb_info defines the current state of a particular video card. Inside | ||
10 | fb_info, there exists a fb_ops structure which is a collection of | ||
11 | needed functions to make fbdev and fbcon work. fb_info is only visible | ||
12 | to the kernel. | ||
13 | |||
14 | fb_var_screeninfo is used to describe the features of a video card | ||
15 | that are user defined. With fb_var_screeninfo, things such as depth | ||
16 | and the resolution may be defined. | ||
17 | |||
18 | The next structure is fb_fix_screeninfo. This defines the properties | ||
19 | of a card that are created when a mode is set and can't be changed | ||
20 | otherwise. A good example of this is the start of the frame buffer | ||
21 | memory. This "locks" the address of the frame buffer memory, so that it | ||
22 | cannot be changed or moved. | ||
23 | |||
24 | The last structure is fb_monospecs. In the old API, there was little | ||
25 | importance for fb_monospecs. This allowed for forbidden things such as | ||
26 | setting a mode of 800x600 on a fix frequency monitor. With the new API, | ||
27 | fb_monospecs prevents such things, and if used correctly, can prevent a | ||
28 | monitor from being cooked. fb_monospecs will not be useful until | ||
29 | kernels 2.5.x. | ||
30 | |||
31 | Frame Buffer Memory | ||
32 | ------------------- | ||
33 | |||
34 | .. kernel-doc:: drivers/video/fbdev/core/fbmem.c | ||
35 | :export: | ||
36 | |||
37 | Frame Buffer Colormap | ||
38 | --------------------- | ||
39 | |||
40 | .. kernel-doc:: drivers/video/fbdev/core/fbcmap.c | ||
41 | :export: | ||
42 | |||
43 | Frame Buffer Video Mode Database | ||
44 | -------------------------------- | ||
45 | |||
46 | .. kernel-doc:: drivers/video/fbdev/core/modedb.c | ||
47 | :internal: | ||
48 | |||
49 | .. kernel-doc:: drivers/video/fbdev/core/modedb.c | ||
50 | :export: | ||
51 | |||
52 | Frame Buffer Macintosh Video Mode Database | ||
53 | ------------------------------------------ | ||
54 | |||
55 | .. kernel-doc:: drivers/video/fbdev/macmodes.c | ||
56 | :export: | ||
57 | |||
58 | Frame Buffer Fonts | ||
59 | ------------------ | ||
60 | |||
61 | Refer to the file lib/fonts/fonts.c for more information. | ||
62 | |||
diff --git a/Documentation/driver-api/hsi.rst b/Documentation/driver-api/hsi.rst new file mode 100644 index 000000000000..f9cec02b72a1 --- /dev/null +++ b/Documentation/driver-api/hsi.rst | |||
@@ -0,0 +1,88 @@ | |||
1 | High Speed Synchronous Serial Interface (HSI) | ||
2 | ============================================= | ||
3 | |||
4 | Introduction | ||
5 | --------------- | ||
6 | |||
7 | High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol, | ||
8 | that is optimized for die-level interconnect between an Application Processor | ||
9 | and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and | ||
10 | implemented by multiple vendors since then. | ||
11 | |||
12 | The HSI interface supports full duplex communication over multiple channels | ||
13 | (typically 8) and is capable of reaching speeds up to 200 Mbit/s. | ||
14 | |||
15 | The serial protocol uses two signals, DATA and FLAG as combined data and clock | ||
16 | signals and an additional READY signal for flow control. An additional WAKE | ||
17 | signal can be used to wakeup the chips from standby modes. The signals are | ||
18 | commonly prefixed by AC for signals going from the application die to the | ||
19 | cellular die and CA for signals going the other way around. | ||
20 | |||
21 | :: | ||
22 | |||
23 | +------------+ +---------------+ | ||
24 | | Cellular | | Application | | ||
25 | | Die | | Die | | ||
26 | | | - - - - - - CAWAKE - - - - - - >| | | ||
27 | | T|------------ CADATA ------------>|R | | ||
28 | | X|------------ CAFLAG ------------>|X | | ||
29 | | |<----------- ACREADY ------------| | | ||
30 | | | | | | ||
31 | | | | | | ||
32 | | |< - - - - - ACWAKE - - - - - - -| | | ||
33 | | R|<----------- ACDATA -------------|T | | ||
34 | | X|<----------- ACFLAG -------------|X | | ||
35 | | |------------ CAREADY ----------->| | | ||
36 | | | | | | ||
37 | | | | | | ||
38 | +------------+ +---------------+ | ||
39 | |||
40 | HSI Subsystem in Linux | ||
41 | ------------------------- | ||
42 | |||
43 | In the Linux kernel the hsi subsystem is supposed to be used for HSI devices. | ||
44 | The hsi subsystem contains drivers for hsi controllers including support for | ||
45 | multi-port controllers and provides a generic API for using the HSI ports. | ||
46 | |||
47 | It also contains HSI client drivers, which make use of the generic API to | ||
48 | implement a protocol used on the HSI interface. These client drivers can | ||
49 | use an arbitrary number of channels. | ||
50 | |||
51 | hsi-char Device | ||
52 | ------------------ | ||
53 | |||
54 | Each port automatically registers a generic client driver called hsi_char, | ||
55 | which provides a charecter device for userspace representing the HSI port. | ||
56 | It can be used to communicate via HSI from userspace. Userspace may | ||
57 | configure the hsi_char device using the following ioctl commands: | ||
58 | |||
59 | HSC_RESET | ||
60 | flush the HSI port | ||
61 | |||
62 | HSC_SET_PM | ||
63 | enable or disable the client. | ||
64 | |||
65 | HSC_SEND_BREAK | ||
66 | send break | ||
67 | |||
68 | HSC_SET_RX | ||
69 | set RX configuration | ||
70 | |||
71 | HSC_GET_RX | ||
72 | get RX configuration | ||
73 | |||
74 | HSC_SET_TX | ||
75 | set TX configuration | ||
76 | |||
77 | HSC_GET_TX | ||
78 | get TX configuration | ||
79 | |||
80 | The kernel HSI API | ||
81 | ------------------ | ||
82 | |||
83 | .. kernel-doc:: include/linux/hsi/hsi.h | ||
84 | :internal: | ||
85 | |||
86 | .. kernel-doc:: drivers/hsi/hsi_core.c | ||
87 | :export: | ||
88 | |||
diff --git a/Documentation/driver-api/i2c.rst b/Documentation/driver-api/i2c.rst new file mode 100644 index 000000000000..f3939f7852bd --- /dev/null +++ b/Documentation/driver-api/i2c.rst | |||
@@ -0,0 +1,46 @@ | |||
1 | I\ :sup:`2`\ C and SMBus Subsystem | ||
2 | ================================== | ||
3 | |||
4 | I\ :sup:`2`\ C (or without fancy typography, "I2C") is an acronym for | ||
5 | the "Inter-IC" bus, a simple bus protocol which is widely used where low | ||
6 | data rate communications suffice. Since it's also a licensed trademark, | ||
7 | some vendors use another name (such as "Two-Wire Interface", TWI) for | ||
8 | the same bus. I2C only needs two signals (SCL for clock, SDA for data), | ||
9 | conserving board real estate and minimizing signal quality issues. Most | ||
10 | I2C devices use seven bit addresses, and bus speeds of up to 400 kHz; | ||
11 | there's a high speed extension (3.4 MHz) that's not yet found wide use. | ||
12 | I2C is a multi-master bus; open drain signaling is used to arbitrate | ||
13 | between masters, as well as to handshake and to synchronize clocks from | ||
14 | slower clients. | ||
15 | |||
16 | The Linux I2C programming interfaces support only the master side of bus | ||
17 | interactions, not the slave side. The programming interface is | ||
18 | structured around two kinds of driver, and two kinds of device. An I2C | ||
19 | "Adapter Driver" abstracts the controller hardware; it binds to a | ||
20 | physical device (perhaps a PCI device or platform_device) and exposes a | ||
21 | :c:type:`struct i2c_adapter <i2c_adapter>` representing each | ||
22 | I2C bus segment it manages. On each I2C bus segment will be I2C devices | ||
23 | represented by a :c:type:`struct i2c_client <i2c_client>`. | ||
24 | Those devices will be bound to a :c:type:`struct i2c_driver | ||
25 | <i2c_driver>`, which should follow the standard Linux driver | ||
26 | model. (At this writing, a legacy model is more widely used.) There are | ||
27 | functions to perform various I2C protocol operations; at this writing | ||
28 | all such functions are usable only from task context. | ||
29 | |||
30 | The System Management Bus (SMBus) is a sibling protocol. Most SMBus | ||
31 | systems are also I2C conformant. The electrical constraints are tighter | ||
32 | for SMBus, and it standardizes particular protocol messages and idioms. | ||
33 | Controllers that support I2C can also support most SMBus operations, but | ||
34 | SMBus controllers don't support all the protocol options that an I2C | ||
35 | controller will. There are functions to perform various SMBus protocol | ||
36 | operations, either using I2C primitives or by issuing SMBus commands to | ||
37 | i2c_adapter devices which don't support those I2C operations. | ||
38 | |||
39 | .. kernel-doc:: include/linux/i2c.h | ||
40 | :internal: | ||
41 | |||
42 | .. kernel-doc:: drivers/i2c/i2c-boardinfo.c | ||
43 | :functions: i2c_register_board_info | ||
44 | |||
45 | .. kernel-doc:: drivers/i2c/i2c-core.c | ||
46 | :export: | ||
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst new file mode 100644 index 000000000000..8e259c5d0322 --- /dev/null +++ b/Documentation/driver-api/index.rst | |||
@@ -0,0 +1,26 @@ | |||
1 | ======================================== | ||
2 | The Linux driver implementer's API guide | ||
3 | ======================================== | ||
4 | |||
5 | The kernel offers a wide variety of interfaces to support the development | ||
6 | of device drivers. This document is an only somewhat organized collection | ||
7 | of some of those interfaces — it will hopefully get better over time! The | ||
8 | available subsections can be seen below. | ||
9 | |||
10 | .. class:: toc-title | ||
11 | |||
12 | Table of contents | ||
13 | |||
14 | .. toctree:: | ||
15 | :maxdepth: 2 | ||
16 | |||
17 | basics | ||
18 | infrastructure | ||
19 | message-based | ||
20 | sound | ||
21 | frame-buffer | ||
22 | input | ||
23 | spi | ||
24 | i2c | ||
25 | hsi | ||
26 | miscellaneous | ||
diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst new file mode 100644 index 000000000000..5d50d6733db3 --- /dev/null +++ b/Documentation/driver-api/infrastructure.rst | |||
@@ -0,0 +1,169 @@ | |||
1 | Device drivers infrastructure | ||
2 | ============================= | ||
3 | |||
4 | The Basic Device Driver-Model Structures | ||
5 | ---------------------------------------- | ||
6 | |||
7 | .. kernel-doc:: include/linux/device.h | ||
8 | :internal: | ||
9 | |||
10 | Device Drivers Base | ||
11 | ------------------- | ||
12 | |||
13 | .. kernel-doc:: drivers/base/init.c | ||
14 | :internal: | ||
15 | |||
16 | .. kernel-doc:: drivers/base/driver.c | ||
17 | :export: | ||
18 | |||
19 | .. kernel-doc:: drivers/base/core.c | ||
20 | :export: | ||
21 | |||
22 | .. kernel-doc:: drivers/base/syscore.c | ||
23 | :export: | ||
24 | |||
25 | .. kernel-doc:: drivers/base/class.c | ||
26 | :export: | ||
27 | |||
28 | .. kernel-doc:: drivers/base/node.c | ||
29 | :internal: | ||
30 | |||
31 | .. kernel-doc:: drivers/base/firmware_class.c | ||
32 | :export: | ||
33 | |||
34 | .. kernel-doc:: drivers/base/transport_class.c | ||
35 | :export: | ||
36 | |||
37 | .. kernel-doc:: drivers/base/dd.c | ||
38 | :export: | ||
39 | |||
40 | .. kernel-doc:: include/linux/platform_device.h | ||
41 | :internal: | ||
42 | |||
43 | .. kernel-doc:: drivers/base/platform.c | ||
44 | :export: | ||
45 | |||
46 | .. kernel-doc:: drivers/base/bus.c | ||
47 | :export: | ||
48 | |||
49 | Buffer Sharing and Synchronization | ||
50 | ---------------------------------- | ||
51 | |||
52 | The dma-buf subsystem provides the framework for sharing buffers for | ||
53 | hardware (DMA) access across multiple device drivers and subsystems, and | ||
54 | for synchronizing asynchronous hardware access. | ||
55 | |||
56 | This is used, for example, by drm "prime" multi-GPU support, but is of | ||
57 | course not limited to GPU use cases. | ||
58 | |||
59 | The three main components of this are: (1) dma-buf, representing a | ||
60 | sg_table and exposed to userspace as a file descriptor to allow passing | ||
61 | between devices, (2) fence, which provides a mechanism to signal when | ||
62 | one device as finished access, and (3) reservation, which manages the | ||
63 | shared or exclusive fence(s) associated with the buffer. | ||
64 | |||
65 | dma-buf | ||
66 | ~~~~~~~ | ||
67 | |||
68 | .. kernel-doc:: drivers/dma-buf/dma-buf.c | ||
69 | :export: | ||
70 | |||
71 | .. kernel-doc:: include/linux/dma-buf.h | ||
72 | :internal: | ||
73 | |||
74 | reservation | ||
75 | ~~~~~~~~~~~ | ||
76 | |||
77 | .. kernel-doc:: drivers/dma-buf/reservation.c | ||
78 | :doc: Reservation Object Overview | ||
79 | |||
80 | .. kernel-doc:: drivers/dma-buf/reservation.c | ||
81 | :export: | ||
82 | |||
83 | .. kernel-doc:: include/linux/reservation.h | ||
84 | :internal: | ||
85 | |||
86 | fence | ||
87 | ~~~~~ | ||
88 | |||
89 | .. kernel-doc:: drivers/dma-buf/fence.c | ||
90 | :export: | ||
91 | |||
92 | .. kernel-doc:: include/linux/fence.h | ||
93 | :internal: | ||
94 | |||
95 | .. kernel-doc:: drivers/dma-buf/seqno-fence.c | ||
96 | :export: | ||
97 | |||
98 | .. kernel-doc:: include/linux/seqno-fence.h | ||
99 | :internal: | ||
100 | |||
101 | .. kernel-doc:: drivers/dma-buf/fence-array.c | ||
102 | :export: | ||
103 | |||
104 | .. kernel-doc:: include/linux/fence-array.h | ||
105 | :internal: | ||
106 | |||
107 | .. kernel-doc:: drivers/dma-buf/reservation.c | ||
108 | :export: | ||
109 | |||
110 | .. kernel-doc:: include/linux/reservation.h | ||
111 | :internal: | ||
112 | |||
113 | .. kernel-doc:: drivers/dma-buf/sync_file.c | ||
114 | :export: | ||
115 | |||
116 | .. kernel-doc:: include/linux/sync_file.h | ||
117 | :internal: | ||
118 | |||
119 | Device Drivers DMA Management | ||
120 | ----------------------------- | ||
121 | |||
122 | .. kernel-doc:: drivers/base/dma-coherent.c | ||
123 | :export: | ||
124 | |||
125 | .. kernel-doc:: drivers/base/dma-mapping.c | ||
126 | :export: | ||
127 | |||
128 | Device Drivers Power Management | ||
129 | ------------------------------- | ||
130 | |||
131 | .. kernel-doc:: drivers/base/power/main.c | ||
132 | :export: | ||
133 | |||
134 | Device Drivers ACPI Support | ||
135 | --------------------------- | ||
136 | |||
137 | .. kernel-doc:: drivers/acpi/scan.c | ||
138 | :export: | ||
139 | |||
140 | .. kernel-doc:: drivers/acpi/scan.c | ||
141 | :internal: | ||
142 | |||
143 | Device drivers PnP support | ||
144 | -------------------------- | ||
145 | |||
146 | .. kernel-doc:: drivers/pnp/core.c | ||
147 | :internal: | ||
148 | |||
149 | .. kernel-doc:: drivers/pnp/card.c | ||
150 | :export: | ||
151 | |||
152 | .. kernel-doc:: drivers/pnp/driver.c | ||
153 | :internal: | ||
154 | |||
155 | .. kernel-doc:: drivers/pnp/manager.c | ||
156 | :export: | ||
157 | |||
158 | .. kernel-doc:: drivers/pnp/support.c | ||
159 | :export: | ||
160 | |||
161 | Userspace IO devices | ||
162 | -------------------- | ||
163 | |||
164 | .. kernel-doc:: drivers/uio/uio.c | ||
165 | :export: | ||
166 | |||
167 | .. kernel-doc:: include/linux/uio_driver.h | ||
168 | :internal: | ||
169 | |||
diff --git a/Documentation/driver-api/input.rst b/Documentation/driver-api/input.rst new file mode 100644 index 000000000000..d05bf58fa83e --- /dev/null +++ b/Documentation/driver-api/input.rst | |||
@@ -0,0 +1,51 @@ | |||
1 | Input Subsystem | ||
2 | =============== | ||
3 | |||
4 | Input core | ||
5 | ---------- | ||
6 | |||
7 | .. kernel-doc:: include/linux/input.h | ||
8 | :internal: | ||
9 | |||
10 | .. kernel-doc:: drivers/input/input.c | ||
11 | :export: | ||
12 | |||
13 | .. kernel-doc:: drivers/input/ff-core.c | ||
14 | :export: | ||
15 | |||
16 | .. kernel-doc:: drivers/input/ff-memless.c | ||
17 | :export: | ||
18 | |||
19 | Multitouch Library | ||
20 | ------------------ | ||
21 | |||
22 | .. kernel-doc:: include/linux/input/mt.h | ||
23 | :internal: | ||
24 | |||
25 | .. kernel-doc:: drivers/input/input-mt.c | ||
26 | :export: | ||
27 | |||
28 | Polled input devices | ||
29 | -------------------- | ||
30 | |||
31 | .. kernel-doc:: include/linux/input-polldev.h | ||
32 | :internal: | ||
33 | |||
34 | .. kernel-doc:: drivers/input/input-polldev.c | ||
35 | :export: | ||
36 | |||
37 | Matrix keyboards/keypads | ||
38 | ------------------------ | ||
39 | |||
40 | .. kernel-doc:: include/linux/input/matrix_keypad.h | ||
41 | :internal: | ||
42 | |||
43 | Sparse keymap support | ||
44 | --------------------- | ||
45 | |||
46 | .. kernel-doc:: include/linux/input/sparse-keymap.h | ||
47 | :internal: | ||
48 | |||
49 | .. kernel-doc:: drivers/input/sparse-keymap.c | ||
50 | :export: | ||
51 | |||
diff --git a/Documentation/driver-api/message-based.rst b/Documentation/driver-api/message-based.rst new file mode 100644 index 000000000000..18ff94ef6d8e --- /dev/null +++ b/Documentation/driver-api/message-based.rst | |||
@@ -0,0 +1,12 @@ | |||
1 | Message-based devices | ||
2 | ===================== | ||
3 | |||
4 | Fusion message devices | ||
5 | ---------------------- | ||
6 | |||
7 | .. kernel-doc:: drivers/message/fusion/mptbase.c | ||
8 | :export: | ||
9 | |||
10 | .. kernel-doc:: drivers/message/fusion/mptscsih.c | ||
11 | :export: | ||
12 | |||
diff --git a/Documentation/driver-api/miscellaneous.rst b/Documentation/driver-api/miscellaneous.rst new file mode 100644 index 000000000000..8da7d115bafc --- /dev/null +++ b/Documentation/driver-api/miscellaneous.rst | |||
@@ -0,0 +1,50 @@ | |||
1 | Parallel Port Devices | ||
2 | ===================== | ||
3 | |||
4 | .. kernel-doc:: include/linux/parport.h | ||
5 | :internal: | ||
6 | |||
7 | .. kernel-doc:: drivers/parport/ieee1284.c | ||
8 | :export: | ||
9 | |||
10 | .. kernel-doc:: drivers/parport/share.c | ||
11 | :export: | ||
12 | |||
13 | .. kernel-doc:: drivers/parport/daisy.c | ||
14 | :internal: | ||
15 | |||
16 | 16x50 UART Driver | ||
17 | ================= | ||
18 | |||
19 | .. kernel-doc:: drivers/tty/serial/serial_core.c | ||
20 | :export: | ||
21 | |||
22 | .. kernel-doc:: drivers/tty/serial/8250/8250_core.c | ||
23 | :export: | ||
24 | |||
25 | Pulse-Width Modulation (PWM) | ||
26 | ============================ | ||
27 | |||
28 | Pulse-width modulation is a modulation technique primarily used to | ||
29 | control power supplied to electrical devices. | ||
30 | |||
31 | The PWM framework provides an abstraction for providers and consumers of | ||
32 | PWM signals. A controller that provides one or more PWM signals is | ||
33 | registered as :c:type:`struct pwm_chip <pwm_chip>`. Providers | ||
34 | are expected to embed this structure in a driver-specific structure. | ||
35 | This structure contains fields that describe a particular chip. | ||
36 | |||
37 | A chip exposes one or more PWM signal sources, each of which exposed as | ||
38 | a :c:type:`struct pwm_device <pwm_device>`. Operations can be | ||
39 | performed on PWM devices to control the period, duty cycle, polarity and | ||
40 | active state of the signal. | ||
41 | |||
42 | Note that PWM devices are exclusive resources: they can always only be | ||
43 | used by one consumer at a time. | ||
44 | |||
45 | .. kernel-doc:: include/linux/pwm.h | ||
46 | :internal: | ||
47 | |||
48 | .. kernel-doc:: drivers/pwm/core.c | ||
49 | :export: | ||
50 | |||
diff --git a/Documentation/driver-api/sound.rst b/Documentation/driver-api/sound.rst new file mode 100644 index 000000000000..afef6eabc073 --- /dev/null +++ b/Documentation/driver-api/sound.rst | |||
@@ -0,0 +1,54 @@ | |||
1 | Sound Devices | ||
2 | ============= | ||
3 | |||
4 | .. kernel-doc:: include/sound/core.h | ||
5 | :internal: | ||
6 | |||
7 | .. kernel-doc:: sound/sound_core.c | ||
8 | :export: | ||
9 | |||
10 | .. kernel-doc:: include/sound/pcm.h | ||
11 | :internal: | ||
12 | |||
13 | .. kernel-doc:: sound/core/pcm.c | ||
14 | :export: | ||
15 | |||
16 | .. kernel-doc:: sound/core/device.c | ||
17 | :export: | ||
18 | |||
19 | .. kernel-doc:: sound/core/info.c | ||
20 | :export: | ||
21 | |||
22 | .. kernel-doc:: sound/core/rawmidi.c | ||
23 | :export: | ||
24 | |||
25 | .. kernel-doc:: sound/core/sound.c | ||
26 | :export: | ||
27 | |||
28 | .. kernel-doc:: sound/core/memory.c | ||
29 | :export: | ||
30 | |||
31 | .. kernel-doc:: sound/core/pcm_memory.c | ||
32 | :export: | ||
33 | |||
34 | .. kernel-doc:: sound/core/init.c | ||
35 | :export: | ||
36 | |||
37 | .. kernel-doc:: sound/core/isadma.c | ||
38 | :export: | ||
39 | |||
40 | .. kernel-doc:: sound/core/control.c | ||
41 | :export: | ||
42 | |||
43 | .. kernel-doc:: sound/core/pcm_lib.c | ||
44 | :export: | ||
45 | |||
46 | .. kernel-doc:: sound/core/hwdep.c | ||
47 | :export: | ||
48 | |||
49 | .. kernel-doc:: sound/core/pcm_native.c | ||
50 | :export: | ||
51 | |||
52 | .. kernel-doc:: sound/core/memalloc.c | ||
53 | :export: | ||
54 | |||
diff --git a/Documentation/driver-api/spi.rst b/Documentation/driver-api/spi.rst new file mode 100644 index 000000000000..f64cb666498a --- /dev/null +++ b/Documentation/driver-api/spi.rst | |||
@@ -0,0 +1,53 @@ | |||
1 | Serial Peripheral Interface (SPI) | ||
2 | ================================= | ||
3 | |||
4 | SPI is the "Serial Peripheral Interface", widely used with embedded | ||
5 | systems because it is a simple and efficient interface: basically a | ||
6 | multiplexed shift register. Its three signal wires hold a clock (SCK, | ||
7 | often in the range of 1-20 MHz), a "Master Out, Slave In" (MOSI) data | ||
8 | line, and a "Master In, Slave Out" (MISO) data line. SPI is a full | ||
9 | duplex protocol; for each bit shifted out the MOSI line (one per clock) | ||
10 | another is shifted in on the MISO line. Those bits are assembled into | ||
11 | words of various sizes on the way to and from system memory. An | ||
12 | additional chipselect line is usually active-low (nCS); four signals are | ||
13 | normally used for each peripheral, plus sometimes an interrupt. | ||
14 | |||
15 | The SPI bus facilities listed here provide a generalized interface to | ||
16 | declare SPI busses and devices, manage them according to the standard | ||
17 | Linux driver model, and perform input/output operations. At this time, | ||
18 | only "master" side interfaces are supported, where Linux talks to SPI | ||
19 | peripherals and does not implement such a peripheral itself. (Interfaces | ||
20 | to support implementing SPI slaves would necessarily look different.) | ||
21 | |||
22 | The programming interface is structured around two kinds of driver, and | ||
23 | two kinds of device. A "Controller Driver" abstracts the controller | ||
24 | hardware, which may be as simple as a set of GPIO pins or as complex as | ||
25 | a pair of FIFOs connected to dual DMA engines on the other side of the | ||
26 | SPI shift register (maximizing throughput). Such drivers bridge between | ||
27 | whatever bus they sit on (often the platform bus) and SPI, and expose | ||
28 | the SPI side of their device as a :c:type:`struct spi_master | ||
29 | <spi_master>`. SPI devices are children of that master, | ||
30 | represented as a :c:type:`struct spi_device <spi_device>` and | ||
31 | manufactured from :c:type:`struct spi_board_info | ||
32 | <spi_board_info>` descriptors which are usually provided by | ||
33 | board-specific initialization code. A :c:type:`struct spi_driver | ||
34 | <spi_driver>` is called a "Protocol Driver", and is bound to a | ||
35 | spi_device using normal driver model calls. | ||
36 | |||
37 | The I/O model is a set of queued messages. Protocol drivers submit one | ||
38 | or more :c:type:`struct spi_message <spi_message>` objects, | ||
39 | which are processed and completed asynchronously. (There are synchronous | ||
40 | wrappers, however.) Messages are built from one or more | ||
41 | :c:type:`struct spi_transfer <spi_transfer>` objects, each of | ||
42 | which wraps a full duplex SPI transfer. A variety of protocol tweaking | ||
43 | options are needed, because different chips adopt very different | ||
44 | policies for how they use the bits transferred with SPI. | ||
45 | |||
46 | .. kernel-doc:: include/linux/spi/spi.h | ||
47 | :internal: | ||
48 | |||
49 | .. kernel-doc:: drivers/spi/spi.c | ||
50 | :functions: spi_register_board_info | ||
51 | |||
52 | .. kernel-doc:: drivers/spi/spi.c | ||
53 | :export: | ||
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt index 1e70220d20f4..2403eb856187 100644 --- a/Documentation/driver-model/device.txt +++ b/Documentation/driver-model/device.txt | |||
@@ -50,7 +50,7 @@ Attributes of devices can be exported by a device driver through sysfs. | |||
50 | Please see Documentation/filesystems/sysfs.txt for more information | 50 | Please see Documentation/filesystems/sysfs.txt for more information |
51 | on how sysfs works. | 51 | on how sysfs works. |
52 | 52 | ||
53 | As explained in Documentation/kobject.txt, device attributes must be be | 53 | As explained in Documentation/kobject.txt, device attributes must be |
54 | created before the KOBJ_ADD uevent is generated. The only way to realize | 54 | created before the KOBJ_ADD uevent is generated. The only way to realize |
55 | that is by defining an attribute group. | 55 | that is by defining an attribute group. |
56 | 56 | ||
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 68080ad6a75e..fcc1ac094282 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -145,7 +145,7 @@ Table 1-1: Process specific entries in /proc | |||
145 | symbol the task is blocked in - or "0" if not blocked. | 145 | symbol the task is blocked in - or "0" if not blocked. |
146 | pagemap Page table | 146 | pagemap Page table |
147 | stack Report full stack trace, enable via CONFIG_STACKTRACE | 147 | stack Report full stack trace, enable via CONFIG_STACKTRACE |
148 | smaps a extension based on maps, showing the memory consumption of | 148 | smaps an extension based on maps, showing the memory consumption of |
149 | each mapping and flags associated with it | 149 | each mapping and flags associated with it |
150 | numa_maps an extension based on maps, showing the memory locality and | 150 | numa_maps an extension based on maps, showing the memory locality and |
151 | binding policy as well as mem usage (in pages) of each mapping. | 151 | binding policy as well as mem usage (in pages) of each mapping. |
diff --git a/Documentation/hsi.txt b/Documentation/hsi.txt deleted file mode 100644 index 6ac6cd51852a..000000000000 --- a/Documentation/hsi.txt +++ /dev/null | |||
@@ -1,75 +0,0 @@ | |||
1 | HSI - High-speed Synchronous Serial Interface | ||
2 | |||
3 | 1. Introduction | ||
4 | ~~~~~~~~~~~~~~~ | ||
5 | |||
6 | High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol, | ||
7 | that is optimized for die-level interconnect between an Application Processor | ||
8 | and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and | ||
9 | implemented by multiple vendors since then. | ||
10 | |||
11 | The HSI interface supports full duplex communication over multiple channels | ||
12 | (typically 8) and is capable of reaching speeds up to 200 Mbit/s. | ||
13 | |||
14 | The serial protocol uses two signals, DATA and FLAG as combined data and clock | ||
15 | signals and an additional READY signal for flow control. An additional WAKE | ||
16 | signal can be used to wakeup the chips from standby modes. The signals are | ||
17 | commonly prefixed by AC for signals going from the application die to the | ||
18 | cellular die and CA for signals going the other way around. | ||
19 | |||
20 | +------------+ +---------------+ | ||
21 | | Cellular | | Application | | ||
22 | | Die | | Die | | ||
23 | | | - - - - - - CAWAKE - - - - - - >| | | ||
24 | | T|------------ CADATA ------------>|R | | ||
25 | | X|------------ CAFLAG ------------>|X | | ||
26 | | |<----------- ACREADY ------------| | | ||
27 | | | | | | ||
28 | | | | | | ||
29 | | |< - - - - - ACWAKE - - - - - - -| | | ||
30 | | R|<----------- ACDATA -------------|T | | ||
31 | | X|<----------- ACFLAG -------------|X | | ||
32 | | |------------ CAREADY ----------->| | | ||
33 | | | | | | ||
34 | | | | | | ||
35 | +------------+ +---------------+ | ||
36 | |||
37 | 2. HSI Subsystem in Linux | ||
38 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
39 | |||
40 | In the Linux kernel the hsi subsystem is supposed to be used for HSI devices. | ||
41 | The hsi subsystem contains drivers for hsi controllers including support for | ||
42 | multi-port controllers and provides a generic API for using the HSI ports. | ||
43 | |||
44 | It also contains HSI client drivers, which make use of the generic API to | ||
45 | implement a protocol used on the HSI interface. These client drivers can | ||
46 | use an arbitrary number of channels. | ||
47 | |||
48 | 3. hsi-char Device | ||
49 | ~~~~~~~~~~~~~~~~~~ | ||
50 | |||
51 | Each port automatically registers a generic client driver called hsi_char, | ||
52 | which provides a charecter device for userspace representing the HSI port. | ||
53 | It can be used to communicate via HSI from userspace. Userspace may | ||
54 | configure the hsi_char device using the following ioctl commands: | ||
55 | |||
56 | * HSC_RESET: | ||
57 | - flush the HSI port | ||
58 | |||
59 | * HSC_SET_PM | ||
60 | - enable or disable the client. | ||
61 | |||
62 | * HSC_SEND_BREAK | ||
63 | - send break | ||
64 | |||
65 | * HSC_SET_RX | ||
66 | - set RX configuration | ||
67 | |||
68 | * HSC_GET_RX | ||
69 | - get RX configuration | ||
70 | |||
71 | * HSC_SET_TX | ||
72 | - set TX configuration | ||
73 | |||
74 | * HSC_GET_TX | ||
75 | - get TX configuration | ||
diff --git a/Documentation/index.rst b/Documentation/index.rst index 05eded59820e..9fe5e0cacdd0 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst | |||
@@ -13,6 +13,7 @@ Contents: | |||
13 | 13 | ||
14 | kernel-documentation | 14 | kernel-documentation |
15 | dev-tools/tools | 15 | dev-tools/tools |
16 | driver-api/index | ||
16 | media/index | 17 | media/index |
17 | gpu/index | 18 | gpu/index |
18 | 19 | ||
diff --git a/Documentation/ioctl/botching-up-ioctls.txt b/Documentation/ioctl/botching-up-ioctls.txt index cc30b14791cb..36138c632f7a 100644 --- a/Documentation/ioctl/botching-up-ioctls.txt +++ b/Documentation/ioctl/botching-up-ioctls.txt | |||
@@ -34,15 +34,18 @@ will need to add a a 32-bit compat layer: | |||
34 | 64-bit platforms do. So we always need padding to the natural size to get | 34 | 64-bit platforms do. So we always need padding to the natural size to get |
35 | this right. | 35 | this right. |
36 | 36 | ||
37 | * Pad the entire struct to a multiple of 64-bits - the structure size will | 37 | * Pad the entire struct to a multiple of 64-bits if the structure contains |
38 | otherwise differ on 32-bit versus 64-bit. Having a different structure size | 38 | 64-bit types - the structure size will otherwise differ on 32-bit versus |
39 | hurts when passing arrays of structures to the kernel, or if the kernel | 39 | 64-bit. Having a different structure size hurts when passing arrays of |
40 | checks the structure size, which e.g. the drm core does. | 40 | structures to the kernel, or if the kernel checks the structure size, which |
41 | e.g. the drm core does. | ||
41 | 42 | ||
42 | * Pointers are __u64, cast from/to a uintprt_t on the userspace side and | 43 | * Pointers are __u64, cast from/to a uintprt_t on the userspace side and |
43 | from/to a void __user * in the kernel. Try really hard not to delay this | 44 | from/to a void __user * in the kernel. Try really hard not to delay this |
44 | conversion or worse, fiddle the raw __u64 through your code since that | 45 | conversion or worse, fiddle the raw __u64 through your code since that |
45 | diminishes the checking tools like sparse can provide. | 46 | diminishes the checking tools like sparse can provide. The macro |
47 | u64_to_user_ptr can be used in the kernel to avoid warnings about integers | ||
48 | and pointres of different sizes. | ||
46 | 49 | ||
47 | 50 | ||
48 | Basics | 51 | Basics |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 1fa28092ec00..861f57514fbd 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -2574,8 +2574,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
2574 | 2574 | ||
2575 | nodelayacct [KNL] Disable per-task delay accounting | 2575 | nodelayacct [KNL] Disable per-task delay accounting |
2576 | 2576 | ||
2577 | nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects. | ||
2578 | |||
2579 | nodsp [SH] Disable hardware DSP at boot time. | 2577 | nodsp [SH] Disable hardware DSP at boot time. |
2580 | 2578 | ||
2581 | noefi Disable EFI runtime services support. | 2579 | noefi Disable EFI runtime services support. |
diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 1241ac11edb1..d5ae6ced6be3 100644 --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt | |||
@@ -79,8 +79,6 @@ parameters may be changed at runtime by the command | |||
79 | 79 | ||
80 | ncr53c8xx= [HW,SCSI] | 80 | ncr53c8xx= [HW,SCSI] |
81 | 81 | ||
82 | nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects. | ||
83 | |||
84 | osst= [HW,SCSI] SCSI Tape Driver | 82 | osst= [HW,SCSI] SCSI Tape Driver |
85 | Format: <buffer_size>,<write_threshold> | 83 | Format: <buffer_size>,<write_threshold> |
86 | See also Documentation/scsi/st.txt. | 84 | See also Documentation/scsi/st.txt. |
diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py index 9eb714ada394..df0419c62096 100644 --- a/Documentation/sphinx/cdomain.py +++ b/Documentation/sphinx/cdomain.py | |||
@@ -1,4 +1,5 @@ | |||
1 | # -*- coding: utf-8; mode: python -*- | 1 | # -*- coding: utf-8; mode: python -*- |
2 | # pylint: disable=W0141,C0113,C0103,C0325 | ||
2 | u""" | 3 | u""" |
3 | cdomain | 4 | cdomain |
4 | ~~~~~~~ | 5 | ~~~~~~~ |
@@ -25,15 +26,26 @@ u""" | |||
25 | 26 | ||
26 | * :c:func:`VIDIOC_LOG_STATUS` or | 27 | * :c:func:`VIDIOC_LOG_STATUS` or |
27 | * :any:`VIDIOC_LOG_STATUS` (``:any:`` needs sphinx 1.3) | 28 | * :any:`VIDIOC_LOG_STATUS` (``:any:`` needs sphinx 1.3) |
29 | |||
30 | * Handle signatures of function-like macros well. Don't try to deduce | ||
31 | arguments types of function-like macros. | ||
32 | |||
28 | """ | 33 | """ |
29 | 34 | ||
35 | from docutils import nodes | ||
30 | from docutils.parsers.rst import directives | 36 | from docutils.parsers.rst import directives |
31 | 37 | ||
38 | import sphinx | ||
39 | from sphinx import addnodes | ||
40 | from sphinx.domains.c import c_funcptr_sig_re, c_sig_re | ||
32 | from sphinx.domains.c import CObject as Base_CObject | 41 | from sphinx.domains.c import CObject as Base_CObject |
33 | from sphinx.domains.c import CDomain as Base_CDomain | 42 | from sphinx.domains.c import CDomain as Base_CDomain |
34 | 43 | ||
35 | __version__ = '1.0' | 44 | __version__ = '1.0' |
36 | 45 | ||
46 | # Get Sphinx version | ||
47 | major, minor, patch = map(int, sphinx.__version__.split(".")) | ||
48 | |||
37 | def setup(app): | 49 | def setup(app): |
38 | 50 | ||
39 | app.override_domain(CDomain) | 51 | app.override_domain(CDomain) |
@@ -53,9 +65,54 @@ class CObject(Base_CObject): | |||
53 | "name" : directives.unchanged | 65 | "name" : directives.unchanged |
54 | } | 66 | } |
55 | 67 | ||
68 | def handle_func_like_macro(self, sig, signode): | ||
69 | u"""Handles signatures of function-like macros. | ||
70 | |||
71 | If the objtype is 'function' and the the signature ``sig`` is a | ||
72 | function-like macro, the name of the macro is returned. Otherwise | ||
73 | ``False`` is returned. """ | ||
74 | |||
75 | if not self.objtype == 'function': | ||
76 | return False | ||
77 | |||
78 | m = c_funcptr_sig_re.match(sig) | ||
79 | if m is None: | ||
80 | m = c_sig_re.match(sig) | ||
81 | if m is None: | ||
82 | raise ValueError('no match') | ||
83 | |||
84 | rettype, fullname, arglist, _const = m.groups() | ||
85 | arglist = arglist.strip() | ||
86 | if rettype or not arglist: | ||
87 | return False | ||
88 | |||
89 | arglist = arglist.replace('`', '').replace('\\ ', '') # remove markup | ||
90 | arglist = [a.strip() for a in arglist.split(",")] | ||
91 | |||
92 | # has the first argument a type? | ||
93 | if len(arglist[0].split(" ")) > 1: | ||
94 | return False | ||
95 | |||
96 | # This is a function-like macro, it's arguments are typeless! | ||
97 | signode += addnodes.desc_name(fullname, fullname) | ||
98 | paramlist = addnodes.desc_parameterlist() | ||
99 | signode += paramlist | ||
100 | |||
101 | for argname in arglist: | ||
102 | param = addnodes.desc_parameter('', '', noemph=True) | ||
103 | # separate by non-breaking space in the output | ||
104 | param += nodes.emphasis(argname, argname) | ||
105 | paramlist += param | ||
106 | |||
107 | return fullname | ||
108 | |||
56 | def handle_signature(self, sig, signode): | 109 | def handle_signature(self, sig, signode): |
57 | """Transform a C signature into RST nodes.""" | 110 | """Transform a C signature into RST nodes.""" |
58 | fullname = super(CObject, self).handle_signature(sig, signode) | 111 | |
112 | fullname = self.handle_func_like_macro(sig, signode) | ||
113 | if not fullname: | ||
114 | fullname = super(CObject, self).handle_signature(sig, signode) | ||
115 | |||
59 | if "name" in self.options: | 116 | if "name" in self.options: |
60 | if self.objtype == 'function': | 117 | if self.objtype == 'function': |
61 | fullname = self.options["name"] | 118 | fullname = self.options["name"] |
@@ -85,8 +142,14 @@ class CObject(Base_CObject): | |||
85 | 142 | ||
86 | indextext = self.get_index_text(name) | 143 | indextext = self.get_index_text(name) |
87 | if indextext: | 144 | if indextext: |
88 | self.indexnode['entries'].append(('single', indextext, | 145 | if major == 1 and minor < 4: |
89 | targetname, '', None)) | 146 | # indexnode's tuple changed in 1.4 |
147 | # https://github.com/sphinx-doc/sphinx/commit/e6a5a3a92e938fcd75866b4227db9e0524d58f7c | ||
148 | self.indexnode['entries'].append( | ||
149 | ('single', indextext, targetname, '')) | ||
150 | else: | ||
151 | self.indexnode['entries'].append( | ||
152 | ('single', indextext, targetname, '', None)) | ||
90 | 153 | ||
91 | class CDomain(Base_CDomain): | 154 | class CDomain(Base_CDomain): |
92 | 155 | ||
diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt index 8c7dd5957ae1..5724092db811 100644 --- a/Documentation/x86/x86_64/mm.txt +++ b/Documentation/x86/x86_64/mm.txt | |||
@@ -12,13 +12,13 @@ ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space | |||
12 | ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole | 12 | ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole |
13 | ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) | 13 | ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) |
14 | ... unused hole ... | 14 | ... unused hole ... |
15 | ffffec0000000000 - fffffc0000000000 (=44 bits) kasan shadow memory (16TB) | 15 | ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB) |
16 | ... unused hole ... | 16 | ... unused hole ... |
17 | ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks | 17 | ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks |
18 | ... unused hole ... | 18 | ... unused hole ... |
19 | ffffffef00000000 - ffffffff00000000 (=64 GB) EFI region mapping space | 19 | ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space |
20 | ... unused hole ... | 20 | ... unused hole ... |
21 | ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 | 21 | ffffffff80000000 - ffffffff9fffffff (=512 MB) kernel text mapping, from phys 0 |
22 | ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space | 22 | ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space |
23 | ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls | 23 | ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls |
24 | ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole | 24 | ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole |
diff --git a/MAINTAINERS b/MAINTAINERS index d5c793b0f30f..46a2ce64df68 100644 --- a/MAINTAINERS +++ b/MAINTAINERS | |||
@@ -5606,7 +5606,7 @@ M: Sebastian Reichel <sre@kernel.org> | |||
5606 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git | 5606 | T: git git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git |
5607 | S: Maintained | 5607 | S: Maintained |
5608 | F: Documentation/ABI/testing/sysfs-bus-hsi | 5608 | F: Documentation/ABI/testing/sysfs-bus-hsi |
5609 | F: Documentation/hsi.txt | 5609 | F: Documentation/device-drivers/serial-interfaces.rst |
5610 | F: drivers/hsi/ | 5610 | F: drivers/hsi/ |
5611 | F: include/linux/hsi/ | 5611 | F: include/linux/hsi/ |
5612 | F: include/uapi/linux/hsi/ | 5612 | F: include/uapi/linux/hsi/ |
diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 301bf874cac8..93721f3c91bf 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc | |||
@@ -212,6 +212,7 @@ my $anon_struct_union = 0; | |||
212 | my $type_constant = '\%([-_\w]+)'; | 212 | my $type_constant = '\%([-_\w]+)'; |
213 | my $type_func = '(\w+)\(\)'; | 213 | my $type_func = '(\w+)\(\)'; |
214 | my $type_param = '\@(\w+)'; | 214 | my $type_param = '\@(\w+)'; |
215 | my $type_fp_param = '\@(\w+)\(\)'; # Special RST handling for func ptr params | ||
215 | my $type_struct = '\&((struct\s*)*[_\w]+)'; | 216 | my $type_struct = '\&((struct\s*)*[_\w]+)'; |
216 | my $type_struct_xml = '\\&((struct\s*)*[_\w]+)'; | 217 | my $type_struct_xml = '\\&((struct\s*)*[_\w]+)'; |
217 | my $type_env = '(\$\w+)'; | 218 | my $type_env = '(\$\w+)'; |
@@ -292,6 +293,7 @@ my @highlights_rst = ( | |||
292 | # Note: need to escape () to avoid func matching later | 293 | # Note: need to escape () to avoid func matching later |
293 | [$type_member_func, "\\:c\\:type\\:`\$1\$2\\\\(\\\\) <\$1>`"], | 294 | [$type_member_func, "\\:c\\:type\\:`\$1\$2\\\\(\\\\) <\$1>`"], |
294 | [$type_member, "\\:c\\:type\\:`\$1\$2 <\$1>`"], | 295 | [$type_member, "\\:c\\:type\\:`\$1\$2 <\$1>`"], |
296 | [$type_fp_param, "**\$1\\\\(\\\\)**"], | ||
295 | [$type_func, "\\:c\\:func\\:`\$1()`"], | 297 | [$type_func, "\\:c\\:func\\:`\$1()`"], |
296 | [$type_struct_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"], | 298 | [$type_struct_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"], |
297 | [$type_enum_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"], | 299 | [$type_enum_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"], |
@@ -412,7 +414,7 @@ my $doc_com_body = '\s*\* ?'; | |||
412 | my $doc_decl = $doc_com . '(\w+)'; | 414 | my $doc_decl = $doc_com . '(\w+)'; |
413 | # @params and a strictly limited set of supported section names | 415 | # @params and a strictly limited set of supported section names |
414 | my $doc_sect = $doc_com . | 416 | my $doc_sect = $doc_com . |
415 | '\s*(\@\w+|description|context|returns?|notes?|examples?)\s*:(.*)'; | 417 | '\s*(\@[.\w]+|\@\.\.\.|description|context|returns?|notes?|examples?)\s*:(.*)'; |
416 | my $doc_content = $doc_com_body . '(.*)'; | 418 | my $doc_content = $doc_com_body . '(.*)'; |
417 | my $doc_block = $doc_com . 'DOC:\s*(.*)?'; | 419 | my $doc_block = $doc_com . 'DOC:\s*(.*)?'; |
418 | my $doc_inline_start = '^\s*/\*\*\s*$'; | 420 | my $doc_inline_start = '^\s*/\*\*\s*$'; |
@@ -2351,6 +2353,7 @@ sub push_parameter($$$) { | |||
2351 | 2353 | ||
2352 | if ($type eq "" && $param =~ /\.\.\.$/) | 2354 | if ($type eq "" && $param =~ /\.\.\.$/) |
2353 | { | 2355 | { |
2356 | $param = "..."; | ||
2354 | if (!defined $parameterdescs{$param} || $parameterdescs{$param} eq "") { | 2357 | if (!defined $parameterdescs{$param} || $parameterdescs{$param} eq "") { |
2355 | $parameterdescs{$param} = "variable arguments"; | 2358 | $parameterdescs{$param} = "variable arguments"; |
2356 | } | 2359 | } |