diff options
Diffstat (limited to 'Documentation')
53 files changed, 2295 insertions, 721 deletions
diff --git a/Documentation/ABI/testing/sysfs-dev b/Documentation/ABI/testing/sysfs-dev new file mode 100644 index 000000000000..a9f2b8b0530f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-dev | |||
@@ -0,0 +1,20 @@ | |||
1 | What: /sys/dev | ||
2 | Date: April 2008 | ||
3 | KernelVersion: 2.6.26 | ||
4 | Contact: Dan Williams <dan.j.williams@intel.com> | ||
5 | Description: The /sys/dev tree provides a method to look up the sysfs | ||
6 | path for a device using the information returned from | ||
7 | stat(2). There are two directories, 'block' and 'char', | ||
8 | beneath /sys/dev containing symbolic links with names of | ||
9 | the form "<major>:<minor>". These links point to the | ||
10 | corresponding sysfs path for the given device. | ||
11 | |||
12 | Example: | ||
13 | $ readlink /sys/dev/block/8:32 | ||
14 | ../../block/sdc | ||
15 | |||
16 | Entries in /sys/dev/char and /sys/dev/block will be | ||
17 | dynamically created and destroyed as devices enter and | ||
18 | leave the system. | ||
19 | |||
20 | Users: mdadm <linux-raid@vger.kernel.org> | ||
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt index 6d772f84b477..b768cc0e402b 100644 --- a/Documentation/DMA-attributes.txt +++ b/Documentation/DMA-attributes.txt | |||
@@ -22,3 +22,12 @@ ready and available in memory. The DMA of the "completion indication" | |||
22 | could race with data DMA. Mapping the memory used for completion | 22 | could race with data DMA. Mapping the memory used for completion |
23 | indications with DMA_ATTR_WRITE_BARRIER would prevent the race. | 23 | indications with DMA_ATTR_WRITE_BARRIER would prevent the race. |
24 | 24 | ||
25 | DMA_ATTR_WEAK_ORDERING | ||
26 | ---------------------- | ||
27 | |||
28 | DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping | ||
29 | may be weakly ordered, that is that reads and writes may pass each other. | ||
30 | |||
31 | Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING, | ||
32 | those that do not will simply ignore the attribute and exhibit default | ||
33 | behavior. | ||
diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 5a8ffa761e09..ea3bc9565e6a 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl | |||
@@ -524,6 +524,44 @@ These utilities include endpoint autoconfiguration. | |||
524 | <!-- !Edrivers/usb/gadget/epautoconf.c --> | 524 | <!-- !Edrivers/usb/gadget/epautoconf.c --> |
525 | </sect1> | 525 | </sect1> |
526 | 526 | ||
527 | <sect1 id="composite"><title>Composite Device Framework</title> | ||
528 | |||
529 | <para>The core API is sufficient for writing drivers for composite | ||
530 | USB devices (with more than one function in a given configuration), | ||
531 | and also multi-configuration devices (also more than one function, | ||
532 | but not necessarily sharing a given configuration). | ||
533 | There is however an optional framework which makes it easier to | ||
534 | reuse and combine functions. | ||
535 | </para> | ||
536 | |||
537 | <para>Devices using this framework provide a <emphasis>struct | ||
538 | usb_composite_driver</emphasis>, which in turn provides one or | ||
539 | more <emphasis>struct usb_configuration</emphasis> instances. | ||
540 | Each such configuration includes at least one | ||
541 | <emphasis>struct usb_function</emphasis>, which packages a user | ||
542 | visible role such as "network link" or "mass storage device". | ||
543 | Management functions may also exist, such as "Device Firmware | ||
544 | Upgrade". | ||
545 | </para> | ||
546 | |||
547 | !Iinclude/linux/usb/composite.h | ||
548 | !Edrivers/usb/gadget/composite.c | ||
549 | |||
550 | </sect1> | ||
551 | |||
552 | <sect1 id="functions"><title>Composite Device Functions</title> | ||
553 | |||
554 | <para>At this writing, a few of the current gadget drivers have | ||
555 | been converted to this framework. | ||
556 | Near-term plans include converting all of them, except for "gadgetfs". | ||
557 | </para> | ||
558 | |||
559 | !Edrivers/usb/gadget/f_acm.c | ||
560 | !Edrivers/usb/gadget/f_serial.c | ||
561 | |||
562 | </sect1> | ||
563 | |||
564 | |||
527 | </chapter> | 565 | </chapter> |
528 | 566 | ||
529 | <chapter id="controllers"><title>Peripheral Controller Drivers</title> | 567 | <chapter id="controllers"><title>Peripheral Controller Drivers</title> |
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index fdd7f4f887b7..df87d1b93605 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl | |||
@@ -21,6 +21,18 @@ | |||
21 | </affiliation> | 21 | </affiliation> |
22 | </author> | 22 | </author> |
23 | 23 | ||
24 | <copyright> | ||
25 | <year>2006-2008</year> | ||
26 | <holder>Hans-Jürgen Koch.</holder> | ||
27 | </copyright> | ||
28 | |||
29 | <legalnotice> | ||
30 | <para> | ||
31 | This documentation is Free Software licensed under the terms of the | ||
32 | GPL version 2. | ||
33 | </para> | ||
34 | </legalnotice> | ||
35 | |||
24 | <pubdate>2006-12-11</pubdate> | 36 | <pubdate>2006-12-11</pubdate> |
25 | 37 | ||
26 | <abstract> | 38 | <abstract> |
@@ -30,6 +42,12 @@ | |||
30 | 42 | ||
31 | <revhistory> | 43 | <revhistory> |
32 | <revision> | 44 | <revision> |
45 | <revnumber>0.5</revnumber> | ||
46 | <date>2008-05-22</date> | ||
47 | <authorinitials>hjk</authorinitials> | ||
48 | <revremark>Added description of write() function.</revremark> | ||
49 | </revision> | ||
50 | <revision> | ||
33 | <revnumber>0.4</revnumber> | 51 | <revnumber>0.4</revnumber> |
34 | <date>2007-11-26</date> | 52 | <date>2007-11-26</date> |
35 | <authorinitials>hjk</authorinitials> | 53 | <authorinitials>hjk</authorinitials> |
@@ -57,20 +75,9 @@ | |||
57 | </bookinfo> | 75 | </bookinfo> |
58 | 76 | ||
59 | <chapter id="aboutthisdoc"> | 77 | <chapter id="aboutthisdoc"> |
60 | <?dbhtml filename="about.html"?> | 78 | <?dbhtml filename="aboutthis.html"?> |
61 | <title>About this document</title> | 79 | <title>About this document</title> |
62 | 80 | ||
63 | <sect1 id="copyright"> | ||
64 | <?dbhtml filename="copyright.html"?> | ||
65 | <title>Copyright and License</title> | ||
66 | <para> | ||
67 | Copyright (c) 2006 by Hans-Jürgen Koch.</para> | ||
68 | <para> | ||
69 | This documentation is Free Software licensed under the terms of the | ||
70 | GPL version 2. | ||
71 | </para> | ||
72 | </sect1> | ||
73 | |||
74 | <sect1 id="translations"> | 81 | <sect1 id="translations"> |
75 | <?dbhtml filename="translations.html"?> | 82 | <?dbhtml filename="translations.html"?> |
76 | <title>Translations</title> | 83 | <title>Translations</title> |
@@ -189,6 +196,30 @@ interested in translating it, please email me | |||
189 | represents the total interrupt count. You can use this number | 196 | represents the total interrupt count. You can use this number |
190 | to figure out if you missed some interrupts. | 197 | to figure out if you missed some interrupts. |
191 | </para> | 198 | </para> |
199 | <para> | ||
200 | For some hardware that has more than one interrupt source internally, | ||
201 | but not separate IRQ mask and status registers, there might be | ||
202 | situations where userspace cannot determine what the interrupt source | ||
203 | was if the kernel handler disables them by writing to the chip's IRQ | ||
204 | register. In such a case, the kernel has to disable the IRQ completely | ||
205 | to leave the chip's register untouched. Now the userspace part can | ||
206 | determine the cause of the interrupt, but it cannot re-enable | ||
207 | interrupts. Another cornercase is chips where re-enabling interrupts | ||
208 | is a read-modify-write operation to a combined IRQ status/acknowledge | ||
209 | register. This would be racy if a new interrupt occurred | ||
210 | simultaneously. | ||
211 | </para> | ||
212 | <para> | ||
213 | To address these problems, UIO also implements a write() function. It | ||
214 | is normally not used and can be ignored for hardware that has only a | ||
215 | single interrupt source or has separate IRQ mask and status registers. | ||
216 | If you need it, however, a write to <filename>/dev/uioX</filename> | ||
217 | will call the <function>irqcontrol()</function> function implemented | ||
218 | by the driver. You have to write a 32-bit value that is usually either | ||
219 | 0 or 1 to disable or enable interrupts. If a driver does not implement | ||
220 | <function>irqcontrol()</function>, <function>write()</function> will | ||
221 | return with <varname>-ENOSYS</varname>. | ||
222 | </para> | ||
192 | 223 | ||
193 | <para> | 224 | <para> |
194 | To handle interrupts properly, your custom kernel module can | 225 | To handle interrupts properly, your custom kernel module can |
@@ -362,6 +393,14 @@ device is actually used. | |||
362 | <function>open()</function>, you will probably also want a custom | 393 | <function>open()</function>, you will probably also want a custom |
363 | <function>release()</function> function. | 394 | <function>release()</function> function. |
364 | </para></listitem> | 395 | </para></listitem> |
396 | |||
397 | <listitem><para> | ||
398 | <varname>int (*irqcontrol)(struct uio_info *info, s32 irq_on) | ||
399 | </varname>: Optional. If you need to be able to enable or disable | ||
400 | interrupts from userspace by writing to <filename>/dev/uioX</filename>, | ||
401 | you can implement this function. The parameter <varname>irq_on</varname> | ||
402 | will be 0 to disable interrupts and 1 to enable them. | ||
403 | </para></listitem> | ||
365 | </itemizedlist> | 404 | </itemizedlist> |
366 | 405 | ||
367 | <para> | 406 | <para> |
diff --git a/Documentation/HOWTO b/Documentation/HOWTO index 619e8caf30db..c2371c5a98f9 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO | |||
@@ -358,7 +358,7 @@ Here is a list of some of the different kernel trees available: | |||
358 | - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> | 358 | - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net> |
359 | git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git | 359 | git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git |
360 | 360 | ||
361 | - SCSI, James Bottomley <James.Bottomley@SteelEye.com> | 361 | - SCSI, James Bottomley <James.Bottomley@hansenpartnership.com> |
362 | git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git | 362 | git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git |
363 | 363 | ||
364 | - x86, Ingo Molnar <mingo@elte.hu> | 364 | - x86, Ingo Molnar <mingo@elte.hu> |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 65a1482457a8..9f73587219e8 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -308,9 +308,41 @@ Who: Matthew Wilcox <willy@linux.intel.com> | |||
308 | 308 | ||
309 | --------------------------- | 309 | --------------------------- |
310 | 310 | ||
311 | What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD, | ||
312 | SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD | ||
313 | When: June 2009 | ||
314 | Why: A newer version of the options have been introduced in 2005 that | ||
315 | removes the limitions of the old API. The sctp library has been | ||
316 | converted to use these new options at the same time. Any user | ||
317 | space app that directly uses the old options should convert to using | ||
318 | the new options. | ||
319 | Who: Vlad Yasevich <vladislav.yasevich@hp.com> | ||
320 | |||
321 | --------------------------- | ||
322 | |||
311 | What: CONFIG_THERMAL_HWMON | 323 | What: CONFIG_THERMAL_HWMON |
312 | When: January 2009 | 324 | When: January 2009 |
313 | Why: This option was introduced just to allow older lm-sensors userspace | 325 | Why: This option was introduced just to allow older lm-sensors userspace |
314 | to keep working over the upgrade to 2.6.26. At the scheduled time of | 326 | to keep working over the upgrade to 2.6.26. At the scheduled time of |
315 | removal fixed lm-sensors (2.x or 3.x) should be readily available. | 327 | removal fixed lm-sensors (2.x or 3.x) should be readily available. |
316 | Who: Rene Herman <rene.herman@gmail.com> | 328 | Who: Rene Herman <rene.herman@gmail.com> |
329 | |||
330 | --------------------------- | ||
331 | |||
332 | What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS | ||
333 | (in net/core/net-sysfs.c) | ||
334 | When: After the only user (hal) has seen a release with the patches | ||
335 | for enough time, probably some time in 2010. | ||
336 | Why: Over 1K .text/.data size reduction, data is available in other | ||
337 | ways (ioctls) | ||
338 | Who: Johannes Berg <johannes@sipsolutions.net> | ||
339 | |||
340 | --------------------------- | ||
341 | |||
342 | What: CONFIG_NF_CT_ACCT | ||
343 | When: 2.6.29 | ||
344 | Why: Accounting can now be enabled/disabled without kernel recompilation. | ||
345 | Currently used only to set a default value for a feature that is also | ||
346 | controlled by a kernel/module/sysfs/sysctl parameter. | ||
347 | Who: Krzysztof Piotr Oledzki <ole@ans.pl> | ||
348 | |||
diff --git a/Documentation/filesystems/bfs.txt b/Documentation/filesystems/bfs.txt index ea825e178e79..78043d5a8fc3 100644 --- a/Documentation/filesystems/bfs.txt +++ b/Documentation/filesystems/bfs.txt | |||
@@ -26,11 +26,11 @@ You can simplify mounting by just typing: | |||
26 | 26 | ||
27 | this will allocate the first available loopback device (and load loop.o | 27 | this will allocate the first available loopback device (and load loop.o |
28 | kernel module if necessary) automatically. If the loopback driver is not | 28 | kernel module if necessary) automatically. If the loopback driver is not |
29 | loaded automatically, make sure that your kernel is compiled with kmod | 29 | loaded automatically, make sure that you have compiled the module and |
30 | support (CONFIG_KMOD) enabled. Beware that umount will not | 30 | that modprobe is functioning. Beware that umount will not deallocate |
31 | deallocate /dev/loopN device if /etc/mtab file on your system is a | 31 | /dev/loopN device if /etc/mtab file on your system is a symbolic link to |
32 | symbolic link to /proc/mounts. You will need to do it manually using | 32 | /proc/mounts. You will need to do it manually using "-d" switch of |
33 | "-d" switch of losetup(8). Read losetup(8) manpage for more info. | 33 | losetup(8). Read losetup(8) manpage for more info. |
34 | 34 | ||
35 | To create the BFS image under UnixWare you need to find out first which | 35 | To create the BFS image under UnixWare you need to find out first which |
36 | slice contains it. The command prtvtoc(1M) is your friend: | 36 | slice contains it. The command prtvtoc(1M) is your friend: |
diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt index 15838d706ea2..44c97e6accb2 100644 --- a/Documentation/filesystems/configfs/configfs.txt +++ b/Documentation/filesystems/configfs/configfs.txt | |||
@@ -233,12 +233,10 @@ accomplished via the group operations specified on the group's | |||
233 | config_item_type. | 233 | config_item_type. |
234 | 234 | ||
235 | struct configfs_group_operations { | 235 | struct configfs_group_operations { |
236 | int (*make_item)(struct config_group *group, | 236 | struct config_item *(*make_item)(struct config_group *group, |
237 | const char *name, | 237 | const char *name); |
238 | struct config_item **new_item); | 238 | struct config_group *(*make_group)(struct config_group *group, |
239 | int (*make_group)(struct config_group *group, | 239 | const char *name); |
240 | const char *name, | ||
241 | struct config_group **new_group); | ||
242 | int (*commit_item)(struct config_item *item); | 240 | int (*commit_item)(struct config_item *item); |
243 | void (*disconnect_notify)(struct config_group *group, | 241 | void (*disconnect_notify)(struct config_group *group, |
244 | struct config_item *item); | 242 | struct config_item *item); |
diff --git a/Documentation/filesystems/configfs/configfs_example.c b/Documentation/filesystems/configfs/configfs_example.c index 0b422acd470c..039648791701 100644 --- a/Documentation/filesystems/configfs/configfs_example.c +++ b/Documentation/filesystems/configfs/configfs_example.c | |||
@@ -273,13 +273,13 @@ static inline struct simple_children *to_simple_children(struct config_item *ite | |||
273 | return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; | 273 | return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; |
274 | } | 274 | } |
275 | 275 | ||
276 | static int simple_children_make_item(struct config_group *group, const char *name, struct config_item **new_item) | 276 | static struct config_item *simple_children_make_item(struct config_group *group, const char *name) |
277 | { | 277 | { |
278 | struct simple_child *simple_child; | 278 | struct simple_child *simple_child; |
279 | 279 | ||
280 | simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); | 280 | simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); |
281 | if (!simple_child) | 281 | if (!simple_child) |
282 | return -ENOMEM; | 282 | return ERR_PTR(-ENOMEM); |
283 | 283 | ||
284 | 284 | ||
285 | config_item_init_type_name(&simple_child->item, name, | 285 | config_item_init_type_name(&simple_child->item, name, |
@@ -287,8 +287,7 @@ static int simple_children_make_item(struct config_group *group, const char *nam | |||
287 | 287 | ||
288 | simple_child->storeme = 0; | 288 | simple_child->storeme = 0; |
289 | 289 | ||
290 | *new_item = &simple_child->item; | 290 | return &simple_child->item; |
291 | return 0; | ||
292 | } | 291 | } |
293 | 292 | ||
294 | static struct configfs_attribute simple_children_attr_description = { | 293 | static struct configfs_attribute simple_children_attr_description = { |
@@ -360,21 +359,20 @@ static struct configfs_subsystem simple_children_subsys = { | |||
360 | * children of its own. | 359 | * children of its own. |
361 | */ | 360 | */ |
362 | 361 | ||
363 | static int group_children_make_group(struct config_group *group, const char *name, struct config_group **new_group) | 362 | static struct config_group *group_children_make_group(struct config_group *group, const char *name) |
364 | { | 363 | { |
365 | struct simple_children *simple_children; | 364 | struct simple_children *simple_children; |
366 | 365 | ||
367 | simple_children = kzalloc(sizeof(struct simple_children), | 366 | simple_children = kzalloc(sizeof(struct simple_children), |
368 | GFP_KERNEL); | 367 | GFP_KERNEL); |
369 | if (!simple_children) | 368 | if (!simple_children) |
370 | return -ENOMEM; | 369 | return ERR_PTR(-ENOMEM); |
371 | 370 | ||
372 | 371 | ||
373 | config_group_init_type_name(&simple_children->group, name, | 372 | config_group_init_type_name(&simple_children->group, name, |
374 | &simple_children_type); | 373 | &simple_children_type); |
375 | 374 | ||
376 | *new_group = &simple_children->group; | 375 | return &simple_children->group; |
377 | return 0; | ||
378 | } | 376 | } |
379 | 377 | ||
380 | static struct configfs_attribute group_children_attr_description = { | 378 | static struct configfs_attribute group_children_attr_description = { |
diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs-rdma.txt index d0ec45ae4e7d..44bd766f2e5d 100644 --- a/Documentation/filesystems/nfs-rdma.txt +++ b/Documentation/filesystems/nfs-rdma.txt | |||
@@ -5,7 +5,7 @@ | |||
5 | ################################################################################ | 5 | ################################################################################ |
6 | 6 | ||
7 | Author: NetApp and Open Grid Computing | 7 | Author: NetApp and Open Grid Computing |
8 | Date: April 15, 2008 | 8 | Date: May 29, 2008 |
9 | 9 | ||
10 | Table of Contents | 10 | Table of Contents |
11 | ~~~~~~~~~~~~~~~~~ | 11 | ~~~~~~~~~~~~~~~~~ |
@@ -60,16 +60,18 @@ Installation | |||
60 | The procedures described in this document have been tested with | 60 | The procedures described in this document have been tested with |
61 | distributions from Red Hat's Fedora Project (http://fedora.redhat.com/). | 61 | distributions from Red Hat's Fedora Project (http://fedora.redhat.com/). |
62 | 62 | ||
63 | - Install nfs-utils-1.1.1 or greater on the client | 63 | - Install nfs-utils-1.1.2 or greater on the client |
64 | 64 | ||
65 | An NFS/RDMA mount point can only be obtained by using the mount.nfs | 65 | An NFS/RDMA mount point can be obtained by using the mount.nfs command in |
66 | command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs | 66 | nfs-utils-1.1.2 or greater (nfs-utils-1.1.1 was the first nfs-utils |
67 | you are using, type: | 67 | version with support for NFS/RDMA mounts, but for various reasons we |
68 | recommend using nfs-utils-1.1.2 or greater). To see which version of | ||
69 | mount.nfs you are using, type: | ||
68 | 70 | ||
69 | > /sbin/mount.nfs -V | 71 | $ /sbin/mount.nfs -V |
70 | 72 | ||
71 | If the version is less than 1.1.1 or the command does not exist, | 73 | If the version is less than 1.1.2 or the command does not exist, |
72 | then you will need to install the latest version of nfs-utils. | 74 | you should install the latest version of nfs-utils. |
73 | 75 | ||
74 | Download the latest package from: | 76 | Download the latest package from: |
75 | 77 | ||
@@ -77,22 +79,33 @@ Installation | |||
77 | 79 | ||
78 | Uncompress the package and follow the installation instructions. | 80 | Uncompress the package and follow the installation instructions. |
79 | 81 | ||
80 | If you will not be using GSS and NFSv4, the installation process | 82 | If you will not need the idmapper and gssd executables (you do not need |
81 | can be simplified by disabling these features when running configure: | 83 | these to create an NFS/RDMA enabled mount command), the installation |
84 | process can be simplified by disabling these features when running | ||
85 | configure: | ||
82 | 86 | ||
83 | > ./configure --disable-gss --disable-nfsv4 | 87 | $ ./configure --disable-gss --disable-nfsv4 |
84 | 88 | ||
85 | For more information on this see the package's README and INSTALL files. | 89 | To build nfs-utils you will need the tcp_wrappers package installed. For |
90 | more information on this see the package's README and INSTALL files. | ||
86 | 91 | ||
87 | After building the nfs-utils package, there will be a mount.nfs binary in | 92 | After building the nfs-utils package, there will be a mount.nfs binary in |
88 | the utils/mount directory. This binary can be used to initiate NFS v2, v3, | 93 | the utils/mount directory. This binary can be used to initiate NFS v2, v3, |
89 | or v4 mounts. To initiate a v4 mount, the binary must be called mount.nfs4. | 94 | or v4 mounts. To initiate a v4 mount, the binary must be called |
90 | The standard technique is to create a symlink called mount.nfs4 to mount.nfs. | 95 | mount.nfs4. The standard technique is to create a symlink called |
96 | mount.nfs4 to mount.nfs. | ||
91 | 97 | ||
92 | NOTE: mount.nfs and therefore nfs-utils-1.1.1 or greater is only needed | 98 | This mount.nfs binary should be installed at /sbin/mount.nfs as follows: |
99 | |||
100 | $ sudo cp utils/mount/mount.nfs /sbin/mount.nfs | ||
101 | |||
102 | In this location, mount.nfs will be invoked automatically for NFS mounts | ||
103 | by the system mount commmand. | ||
104 | |||
105 | NOTE: mount.nfs and therefore nfs-utils-1.1.2 or greater is only needed | ||
93 | on the NFS client machine. You do not need this specific version of | 106 | on the NFS client machine. You do not need this specific version of |
94 | nfs-utils on the server. Furthermore, only the mount.nfs command from | 107 | nfs-utils on the server. Furthermore, only the mount.nfs command from |
95 | nfs-utils-1.1.1 is needed on the client. | 108 | nfs-utils-1.1.2 is needed on the client. |
96 | 109 | ||
97 | - Install a Linux kernel with NFS/RDMA | 110 | - Install a Linux kernel with NFS/RDMA |
98 | 111 | ||
@@ -156,8 +169,8 @@ Check RDMA and NFS Setup | |||
156 | this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel | 169 | this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel |
157 | card: | 170 | card: |
158 | 171 | ||
159 | > modprobe ib_mthca | 172 | $ modprobe ib_mthca |
160 | > modprobe ib_ipoib | 173 | $ modprobe ib_ipoib |
161 | 174 | ||
162 | If you are using InfiniBand, make sure there is a Subnet Manager (SM) | 175 | If you are using InfiniBand, make sure there is a Subnet Manager (SM) |
163 | running on the network. If your IB switch has an embedded SM, you can | 176 | running on the network. If your IB switch has an embedded SM, you can |
@@ -166,7 +179,7 @@ Check RDMA and NFS Setup | |||
166 | 179 | ||
167 | If an SM is running on your network, you should see the following: | 180 | If an SM is running on your network, you should see the following: |
168 | 181 | ||
169 | > cat /sys/class/infiniband/driverX/ports/1/state | 182 | $ cat /sys/class/infiniband/driverX/ports/1/state |
170 | 4: ACTIVE | 183 | 4: ACTIVE |
171 | 184 | ||
172 | where driverX is mthca0, ipath5, ehca3, etc. | 185 | where driverX is mthca0, ipath5, ehca3, etc. |
@@ -174,10 +187,10 @@ Check RDMA and NFS Setup | |||
174 | To further test the InfiniBand software stack, use IPoIB (this | 187 | To further test the InfiniBand software stack, use IPoIB (this |
175 | assumes you have two IB hosts named host1 and host2): | 188 | assumes you have two IB hosts named host1 and host2): |
176 | 189 | ||
177 | host1> ifconfig ib0 a.b.c.x | 190 | host1$ ifconfig ib0 a.b.c.x |
178 | host2> ifconfig ib0 a.b.c.y | 191 | host2$ ifconfig ib0 a.b.c.y |
179 | host1> ping a.b.c.y | 192 | host1$ ping a.b.c.y |
180 | host2> ping a.b.c.x | 193 | host2$ ping a.b.c.x |
181 | 194 | ||
182 | For other device types, follow the appropriate procedures. | 195 | For other device types, follow the appropriate procedures. |
183 | 196 | ||
@@ -202,11 +215,11 @@ NFS/RDMA Setup | |||
202 | /vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash) | 215 | /vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash) |
203 | /vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash) | 216 | /vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash) |
204 | 217 | ||
205 | The IP address(es) is(are) the client's IPoIB address for an InfiniBand HCA or the | 218 | The IP address(es) is(are) the client's IPoIB address for an InfiniBand |
206 | cleint's iWARP address(es) for an RNIC. | 219 | HCA or the cleint's iWARP address(es) for an RNIC. |
207 | 220 | ||
208 | NOTE: The "insecure" option must be used because the NFS/RDMA client does not | 221 | NOTE: The "insecure" option must be used because the NFS/RDMA client does |
209 | use a reserved port. | 222 | not use a reserved port. |
210 | 223 | ||
211 | Each time a machine boots: | 224 | Each time a machine boots: |
212 | 225 | ||
@@ -214,43 +227,45 @@ NFS/RDMA Setup | |||
214 | 227 | ||
215 | For InfiniBand using a Mellanox adapter: | 228 | For InfiniBand using a Mellanox adapter: |
216 | 229 | ||
217 | > modprobe ib_mthca | 230 | $ modprobe ib_mthca |
218 | > modprobe ib_ipoib | 231 | $ modprobe ib_ipoib |
219 | > ifconfig ib0 a.b.c.d | 232 | $ ifconfig ib0 a.b.c.d |
220 | 233 | ||
221 | NOTE: use unique addresses for the client and server | 234 | NOTE: use unique addresses for the client and server |
222 | 235 | ||
223 | - Start the NFS server | 236 | - Start the NFS server |
224 | 237 | ||
225 | If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), | 238 | If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in |
226 | load the RDMA transport module: | 239 | kernel config), load the RDMA transport module: |
227 | 240 | ||
228 | > modprobe svcrdma | 241 | $ modprobe svcrdma |
229 | 242 | ||
230 | Regardless of how the server was built (module or built-in), start the server: | 243 | Regardless of how the server was built (module or built-in), start the |
244 | server: | ||
231 | 245 | ||
232 | > /etc/init.d/nfs start | 246 | $ /etc/init.d/nfs start |
233 | 247 | ||
234 | or | 248 | or |
235 | 249 | ||
236 | > service nfs start | 250 | $ service nfs start |
237 | 251 | ||
238 | Instruct the server to listen on the RDMA transport: | 252 | Instruct the server to listen on the RDMA transport: |
239 | 253 | ||
240 | > echo rdma 2050 > /proc/fs/nfsd/portlist | 254 | $ echo rdma 2050 > /proc/fs/nfsd/portlist |
241 | 255 | ||
242 | - On the client system | 256 | - On the client system |
243 | 257 | ||
244 | If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config), | 258 | If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in |
245 | load the RDMA client module: | 259 | kernel config), load the RDMA client module: |
246 | 260 | ||
247 | > modprobe xprtrdma.ko | 261 | $ modprobe xprtrdma.ko |
248 | 262 | ||
249 | Regardless of how the client was built (module or built-in), issue the mount.nfs command: | 263 | Regardless of how the client was built (module or built-in), use this |
264 | command to mount the NFS/RDMA server: | ||
250 | 265 | ||
251 | > /path/to/your/mount.nfs <IPoIB-server-name-or-address>:/<export> /mnt -i -o rdma,port=2050 | 266 | $ mount -o rdma,port=2050 <IPoIB-server-name-or-address>:/<export> /mnt |
252 | 267 | ||
253 | To verify that the mount is using RDMA, run "cat /proc/mounts" and check the | 268 | To verify that the mount is using RDMA, run "cat /proc/mounts" and check |
254 | "proto" field for the given mount. | 269 | the "proto" field for the given mount. |
255 | 270 | ||
256 | Congratulations! You're using NFS/RDMA! | 271 | Congratulations! You're using NFS/RDMA! |
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 7f27b8f840d0..9e9c348275a9 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt | |||
@@ -248,6 +248,7 @@ The top level sysfs directory looks like: | |||
248 | block/ | 248 | block/ |
249 | bus/ | 249 | bus/ |
250 | class/ | 250 | class/ |
251 | dev/ | ||
251 | devices/ | 252 | devices/ |
252 | firmware/ | 253 | firmware/ |
253 | net/ | 254 | net/ |
@@ -274,6 +275,11 @@ fs/ contains a directory for some filesystems. Currently each | |||
274 | filesystem wanting to export attributes must create its own hierarchy | 275 | filesystem wanting to export attributes must create its own hierarchy |
275 | below fs/ (see ./fuse.txt for an example). | 276 | below fs/ (see ./fuse.txt for an example). |
276 | 277 | ||
278 | dev/ contains two directories char/ and block/. Inside these two | ||
279 | directories there are symlinks named <major>:<minor>. These symlinks | ||
280 | point to the sysfs directory for the given device. /sys/dev provides a | ||
281 | quick way to lookup the sysfs interface for a device from the result of | ||
282 | a stat(2) operation. | ||
277 | 283 | ||
278 | More information can driver-model specific features can be found in | 284 | More information can driver-model specific features can be found in |
279 | Documentation/driver-model/. | 285 | Documentation/driver-model/. |
diff --git a/Documentation/ia64/paravirt_ops.txt b/Documentation/ia64/paravirt_ops.txt new file mode 100644 index 000000000000..39ded02ec33f --- /dev/null +++ b/Documentation/ia64/paravirt_ops.txt | |||
@@ -0,0 +1,137 @@ | |||
1 | Paravirt_ops on IA64 | ||
2 | ==================== | ||
3 | 21 May 2008, Isaku Yamahata <yamahata@valinux.co.jp> | ||
4 | |||
5 | |||
6 | Introduction | ||
7 | ------------ | ||
8 | The aim of this documentation is to help with maintainability and/or to | ||
9 | encourage people to use paravirt_ops/IA64. | ||
10 | |||
11 | paravirt_ops (pv_ops in short) is a way for virtualization support of | ||
12 | Linux kernel on x86. Several ways for virtualization support were | ||
13 | proposed, paravirt_ops is the winner. | ||
14 | On the other hand, now there are also several IA64 virtualization | ||
15 | technologies like kvm/IA64, xen/IA64 and many other academic IA64 | ||
16 | hypervisors so that it is good to add generic virtualization | ||
17 | infrastructure on Linux/IA64. | ||
18 | |||
19 | |||
20 | What is paravirt_ops? | ||
21 | --------------------- | ||
22 | It has been developed on x86 as virtualization support via API, not ABI. | ||
23 | It allows each hypervisor to override operations which are important for | ||
24 | hypervisors at API level. And it allows a single kernel binary to run on | ||
25 | all supported execution environments including native machine. | ||
26 | Essentially paravirt_ops is a set of function pointers which represent | ||
27 | operations corresponding to low level sensitive instructions and high | ||
28 | level functionalities in various area. But one significant difference | ||
29 | from usual function pointer table is that it allows optimization with | ||
30 | binary patch. It is because some of these operations are very | ||
31 | performance sensitive and indirect call overhead is not negligible. | ||
32 | With binary patch, indirect C function call can be transformed into | ||
33 | direct C function call or in-place execution to eliminate the overhead. | ||
34 | |||
35 | Thus, operations of paravirt_ops are classified into three categories. | ||
36 | - simple indirect call | ||
37 | These operations correspond to high level functionality so that the | ||
38 | overhead of indirect call isn't very important. | ||
39 | |||
40 | - indirect call which allows optimization with binary patch | ||
41 | Usually these operations correspond to low level instructions. They | ||
42 | are called frequently and performance critical. So the overhead is | ||
43 | very important. | ||
44 | |||
45 | - a set of macros for hand written assembly code | ||
46 | Hand written assembly codes (.S files) also need paravirtualization | ||
47 | because they include sensitive instructions or some of code paths in | ||
48 | them are very performance critical. | ||
49 | |||
50 | |||
51 | The relation to the IA64 machine vector | ||
52 | --------------------------------------- | ||
53 | Linux/IA64 has the IA64 machine vector functionality which allows the | ||
54 | kernel to switch implementations (e.g. initialization, ipi, dma api...) | ||
55 | depending on executing platform. | ||
56 | We can replace some implementations very easily defining a new machine | ||
57 | vector. Thus another approach for virtualization support would be | ||
58 | enhancing the machine vector functionality. | ||
59 | But paravirt_ops approach was taken because | ||
60 | - virtualization support needs wider support than machine vector does. | ||
61 | e.g. low level instruction paravirtualization. It must be | ||
62 | initialized very early before platform detection. | ||
63 | |||
64 | - virtualization support needs more functionality like binary patch. | ||
65 | Probably the calling overhead might not be very large compared to the | ||
66 | emulation overhead of virtualization. However in the native case, the | ||
67 | overhead should be eliminated completely. | ||
68 | A single kernel binary should run on each environment including native, | ||
69 | and the overhead of paravirt_ops on native environment should be as | ||
70 | small as possible. | ||
71 | |||
72 | - for full virtualization technology, e.g. KVM/IA64 or | ||
73 | Xen/IA64 HVM domain, the result would be | ||
74 | (the emulated platform machine vector. probably dig) + (pv_ops). | ||
75 | This means that the virtualization support layer should be under | ||
76 | the machine vector layer. | ||
77 | |||
78 | Possibly it might be better to move some function pointers from | ||
79 | paravirt_ops to machine vector. In fact, Xen domU case utilizes both | ||
80 | pv_ops and machine vector. | ||
81 | |||
82 | |||
83 | IA64 paravirt_ops | ||
84 | ----------------- | ||
85 | In this section, the concrete paravirt_ops will be discussed. | ||
86 | Because of the architecture difference between ia64 and x86, the | ||
87 | resulting set of functions is very different from x86 pv_ops. | ||
88 | |||
89 | - C function pointer tables | ||
90 | They are not very performance critical so that simple C indirect | ||
91 | function call is acceptable. The following structures are defined at | ||
92 | this moment. For details see linux/include/asm-ia64/paravirt.h | ||
93 | - struct pv_info | ||
94 | This structure describes the execution environment. | ||
95 | - struct pv_init_ops | ||
96 | This structure describes the various initialization hooks. | ||
97 | - struct pv_iosapic_ops | ||
98 | This structure describes hooks to iosapic operations. | ||
99 | - struct pv_irq_ops | ||
100 | This structure describes hooks to irq related operations | ||
101 | - struct pv_time_op | ||
102 | This structure describes hooks to steal time accounting. | ||
103 | |||
104 | - a set of indirect calls which need optimization | ||
105 | Currently this class of functions correspond to a subset of IA64 | ||
106 | intrinsics. At this moment the optimization with binary patch isn't | ||
107 | implemented yet. | ||
108 | struct pv_cpu_op is defined. For details see | ||
109 | linux/include/asm-ia64/paravirt_privop.h | ||
110 | Mostly they correspond to ia64 intrinsics 1-to-1. | ||
111 | Caveat: Now they are defined as C indirect function pointers, but in | ||
112 | order to support binary patch optimization, they will be changed | ||
113 | using GCC extended inline assembly code. | ||
114 | |||
115 | - a set of macros for hand written assembly code (.S files) | ||
116 | For maintenance purpose, the taken approach for .S files is single | ||
117 | source code and compile multiple times with different macros definitions. | ||
118 | Each pv_ops instance must define those macros to compile. | ||
119 | The important thing here is that sensitive, but non-privileged | ||
120 | instructions must be paravirtualized and that some privileged | ||
121 | instructions also need paravirtualization for reasonable performance. | ||
122 | Developers who modify .S files must be aware of that. At this moment | ||
123 | an easy checker is implemented to detect paravirtualization breakage. | ||
124 | But it doesn't cover all the cases. | ||
125 | |||
126 | Sometimes this set of macros is called pv_cpu_asm_op. But there is no | ||
127 | corresponding structure in the source code. | ||
128 | Those macros mostly 1:1 correspond to a subset of privileged | ||
129 | instructions. See linux/include/asm-ia64/native/inst.h. | ||
130 | And some functions written in assembly also need to be overrided so | ||
131 | that each pv_ops instance have to define some macros. Again see | ||
132 | linux/include/asm-ia64/native/inst.h. | ||
133 | |||
134 | |||
135 | Those structures must be initialized very early before start_kernel. | ||
136 | Probably initialized in head.S using multi entry point or some other trick. | ||
137 | For native case implementation see linux/arch/ia64/kernel/paravirt.c. | ||
diff --git a/Documentation/input/gameport-programming.txt b/Documentation/input/gameport-programming.txt index 14e0a8b70225..03a74fc3b496 100644 --- a/Documentation/input/gameport-programming.txt +++ b/Documentation/input/gameport-programming.txt | |||
@@ -1,5 +1,3 @@ | |||
1 | $Id: gameport-programming.txt,v 1.3 2001/04/24 13:51:37 vojtech Exp $ | ||
2 | |||
3 | Programming gameport drivers | 1 | Programming gameport drivers |
4 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
5 | 3 | ||
diff --git a/Documentation/input/input.txt b/Documentation/input/input.txt index ff8cea0225f9..686ee9932dff 100644 --- a/Documentation/input/input.txt +++ b/Documentation/input/input.txt | |||
@@ -1,7 +1,6 @@ | |||
1 | Linux Input drivers v1.0 | 1 | Linux Input drivers v1.0 |
2 | (c) 1999-2001 Vojtech Pavlik <vojtech@ucw.cz> | 2 | (c) 1999-2001 Vojtech Pavlik <vojtech@ucw.cz> |
3 | Sponsored by SuSE | 3 | Sponsored by SuSE |
4 | $Id: input.txt,v 1.8 2002/05/29 03:15:01 bradleym Exp $ | ||
5 | ---------------------------------------------------------------------------- | 4 | ---------------------------------------------------------------------------- |
6 | 5 | ||
7 | 0. Disclaimer | 6 | 0. Disclaimer |
diff --git a/Documentation/input/joystick-api.txt b/Documentation/input/joystick-api.txt index acbd32b88454..c507330740cd 100644 --- a/Documentation/input/joystick-api.txt +++ b/Documentation/input/joystick-api.txt | |||
@@ -5,8 +5,6 @@ | |||
5 | 5 | ||
6 | 7 Aug 1998 | 6 | 7 Aug 1998 |
7 | 7 | ||
8 | $Id: joystick-api.txt,v 1.2 2001/05/08 21:21:23 vojtech Exp $ | ||
9 | |||
10 | 1. Initialization | 8 | 1. Initialization |
11 | ~~~~~~~~~~~~~~~~~ | 9 | ~~~~~~~~~~~~~~~~~ |
12 | 10 | ||
diff --git a/Documentation/input/joystick-parport.txt b/Documentation/input/joystick-parport.txt index ede5f33daad3..1c856f32ff2c 100644 --- a/Documentation/input/joystick-parport.txt +++ b/Documentation/input/joystick-parport.txt | |||
@@ -2,7 +2,6 @@ | |||
2 | (c) 1998-2000 Vojtech Pavlik <vojtech@ucw.cz> | 2 | (c) 1998-2000 Vojtech Pavlik <vojtech@ucw.cz> |
3 | (c) 1998 Andree Borrmann <a.borrmann@tu-bs.de> | 3 | (c) 1998 Andree Borrmann <a.borrmann@tu-bs.de> |
4 | Sponsored by SuSE | 4 | Sponsored by SuSE |
5 | $Id: joystick-parport.txt,v 1.6 2001/09/25 09:31:32 vojtech Exp $ | ||
6 | ---------------------------------------------------------------------------- | 5 | ---------------------------------------------------------------------------- |
7 | 6 | ||
8 | 0. Disclaimer | 7 | 0. Disclaimer |
diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt index 389de9bd9878..154d767b2acb 100644 --- a/Documentation/input/joystick.txt +++ b/Documentation/input/joystick.txt | |||
@@ -1,7 +1,6 @@ | |||
1 | Linux Joystick driver v2.0.0 | 1 | Linux Joystick driver v2.0.0 |
2 | (c) 1996-2000 Vojtech Pavlik <vojtech@ucw.cz> | 2 | (c) 1996-2000 Vojtech Pavlik <vojtech@ucw.cz> |
3 | Sponsored by SuSE | 3 | Sponsored by SuSE |
4 | $Id: joystick.txt,v 1.12 2002/03/03 12:13:07 jdeneux Exp $ | ||
5 | ---------------------------------------------------------------------------- | 4 | ---------------------------------------------------------------------------- |
6 | 5 | ||
7 | 0. Disclaimer | 6 | 0. Disclaimer |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 09ad7450647b..47e7d8794fc6 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -1206,7 +1206,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1206 | or | 1206 | or |
1207 | memmap=0x10000$0x18690000 | 1207 | memmap=0x10000$0x18690000 |
1208 | 1208 | ||
1209 | memtest= [KNL,X86_64] Enable memtest | 1209 | memtest= [KNL,X86] Enable memtest |
1210 | Format: <integer> | 1210 | Format: <integer> |
1211 | range: 0,4 : pattern number | 1211 | range: 0,4 : pattern number |
1212 | default : 0 <disable> | 1212 | default : 0 <disable> |
@@ -1279,6 +1279,13 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1279 | This usage is only documented in each driver source | 1279 | This usage is only documented in each driver source |
1280 | file if at all. | 1280 | file if at all. |
1281 | 1281 | ||
1282 | nf_conntrack.acct= | ||
1283 | [NETFILTER] Enable connection tracking flow accounting | ||
1284 | 0 to disable accounting | ||
1285 | 1 to enable accounting | ||
1286 | Default value depends on CONFIG_NF_CT_ACCT that is | ||
1287 | going to be removed in 2.6.29. | ||
1288 | |||
1282 | nfsaddrs= [NFS] | 1289 | nfsaddrs= [NFS] |
1283 | See Documentation/filesystems/nfsroot.txt. | 1290 | See Documentation/filesystems/nfsroot.txt. |
1284 | 1291 | ||
@@ -2027,6 +2034,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2027 | 2034 | ||
2028 | snd-ymfpci= [HW,ALSA] | 2035 | snd-ymfpci= [HW,ALSA] |
2029 | 2036 | ||
2037 | softlockup_panic= | ||
2038 | [KNL] Should the soft-lockup detector generate panics. | ||
2039 | |||
2030 | sonypi.*= [HW] Sony Programmable I/O Control Device driver | 2040 | sonypi.*= [HW] Sony Programmable I/O Control Device driver |
2031 | See Documentation/sonypi.txt | 2041 | See Documentation/sonypi.txt |
2032 | 2042 | ||
@@ -2158,6 +2168,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2158 | Note that genuine overcurrent events won't be | 2168 | Note that genuine overcurrent events won't be |
2159 | reported either. | 2169 | reported either. |
2160 | 2170 | ||
2171 | unknown_nmi_panic | ||
2172 | [X86-32,X86-64] | ||
2173 | Set unknown_nmi_panic=1 early on boot. | ||
2174 | |||
2161 | usbcore.autosuspend= | 2175 | usbcore.autosuspend= |
2162 | [USB] The autosuspend time delay (in seconds) used | 2176 | [USB] The autosuspend time delay (in seconds) used |
2163 | for newly-detected USB devices (default 2). This | 2177 | for newly-detected USB devices (default 2). This |
diff --git a/Documentation/md.txt b/Documentation/md.txt index a8b430627473..1da9d1b1793f 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt | |||
@@ -236,6 +236,11 @@ All md devices contain: | |||
236 | writing the word for the desired state, however some states | 236 | writing the word for the desired state, however some states |
237 | cannot be explicitly set, and some transitions are not allowed. | 237 | cannot be explicitly set, and some transitions are not allowed. |
238 | 238 | ||
239 | Select/poll works on this file. All changes except between | ||
240 | active_idle and active (which can be frequent and are not | ||
241 | very interesting) are notified. active->active_idle is | ||
242 | reported if the metadata is externally managed. | ||
243 | |||
239 | clear | 244 | clear |
240 | No devices, no size, no level | 245 | No devices, no size, no level |
241 | Writing is equivalent to STOP_ARRAY ioctl | 246 | Writing is equivalent to STOP_ARRAY ioctl |
@@ -292,6 +297,10 @@ Each directory contains: | |||
292 | writemostly - device will only be subject to read | 297 | writemostly - device will only be subject to read |
293 | requests if there are no other options. | 298 | requests if there are no other options. |
294 | This applies only to raid1 arrays. | 299 | This applies only to raid1 arrays. |
300 | blocked - device has failed, metadata is "external", | ||
301 | and the failure hasn't been acknowledged yet. | ||
302 | Writes that would write to this device if | ||
303 | it were not faulty are blocked. | ||
295 | spare - device is working, but not a full member. | 304 | spare - device is working, but not a full member. |
296 | This includes spares that are in the process | 305 | This includes spares that are in the process |
297 | of being recovered to | 306 | of being recovered to |
@@ -301,6 +310,12 @@ Each directory contains: | |||
301 | Writing "remove" removes the device from the array. | 310 | Writing "remove" removes the device from the array. |
302 | Writing "writemostly" sets the writemostly flag. | 311 | Writing "writemostly" sets the writemostly flag. |
303 | Writing "-writemostly" clears the writemostly flag. | 312 | Writing "-writemostly" clears the writemostly flag. |
313 | Writing "blocked" sets the "blocked" flag. | ||
314 | Writing "-blocked" clear the "blocked" flag and allows writes | ||
315 | to complete. | ||
316 | |||
317 | This file responds to select/poll. Any change to 'faulty' | ||
318 | or 'blocked' causes an event. | ||
304 | 319 | ||
305 | errors | 320 | errors |
306 | An approximate count of read errors that have been detected on | 321 | An approximate count of read errors that have been detected on |
@@ -332,7 +347,7 @@ Each directory contains: | |||
332 | for storage of data. This will normally be the same as the | 347 | for storage of data. This will normally be the same as the |
333 | component_size. This can be written while assembling an | 348 | component_size. This can be written while assembling an |
334 | array. If a value less than the current component_size is | 349 | array. If a value less than the current component_size is |
335 | written, component_size will be reduced to this value. | 350 | written, it will be rejected. |
336 | 351 | ||
337 | 352 | ||
338 | An active md device will also contain and entry for each active device | 353 | An active md device will also contain and entry for each active device |
@@ -381,6 +396,19 @@ also have | |||
381 | 'check' and 'repair' will start the appropriate process | 396 | 'check' and 'repair' will start the appropriate process |
382 | providing the current state is 'idle'. | 397 | providing the current state is 'idle'. |
383 | 398 | ||
399 | This file responds to select/poll. Any important change in the value | ||
400 | triggers a poll event. Sometimes the value will briefly be | ||
401 | "recover" if a recovery seems to be needed, but cannot be | ||
402 | achieved. In that case, the transition to "recover" isn't | ||
403 | notified, but the transition away is. | ||
404 | |||
405 | degraded | ||
406 | This contains a count of the number of devices by which the | ||
407 | arrays is degraded. So an optimal array with show '0'. A | ||
408 | single failed/missing drive will show '1', etc. | ||
409 | This file responds to select/poll, any increase or decrease | ||
410 | in the count of missing devices will trigger an event. | ||
411 | |||
384 | mismatch_count | 412 | mismatch_count |
385 | When performing 'check' and 'repair', and possibly when | 413 | When performing 'check' and 'repair', and possibly when |
386 | performing 'resync', md will count the number of errors that are | 414 | performing 'resync', md will count the number of errors that are |
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index a0cda062bc33..7fa7fe71d7a8 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt | |||
@@ -289,35 +289,73 @@ downdelay | |||
289 | fail_over_mac | 289 | fail_over_mac |
290 | 290 | ||
291 | Specifies whether active-backup mode should set all slaves to | 291 | Specifies whether active-backup mode should set all slaves to |
292 | the same MAC address (the traditional behavior), or, when | 292 | the same MAC address at enslavement (the traditional |
293 | enabled, change the bond's MAC address when changing the | 293 | behavior), or, when enabled, perform special handling of the |
294 | active interface (i.e., fail over the MAC address itself). | 294 | bond's MAC address in accordance with the selected policy. |
295 | 295 | ||
296 | Fail over MAC is useful for devices that cannot ever alter | 296 | Possible values are: |
297 | their MAC address, or for devices that refuse incoming | 297 | |
298 | broadcasts with their own source MAC (which interferes with | 298 | none or 0 |
299 | the ARP monitor). | 299 | |
300 | 300 | This setting disables fail_over_mac, and causes | |
301 | The down side of fail over MAC is that every device on the | 301 | bonding to set all slaves of an active-backup bond to |
302 | network must be updated via gratuitous ARP, vs. just updating | 302 | the same MAC address at enslavement time. This is the |
303 | a switch or set of switches (which often takes place for any | 303 | default. |
304 | traffic, not just ARP traffic, if the switch snoops incoming | 304 | |
305 | traffic to update its tables) for the traditional method. If | 305 | active or 1 |
306 | the gratuitous ARP is lost, communication may be disrupted. | 306 | |
307 | 307 | The "active" fail_over_mac policy indicates that the | |
308 | When fail over MAC is used in conjuction with the mii monitor, | 308 | MAC address of the bond should always be the MAC |
309 | devices which assert link up prior to being able to actually | 309 | address of the currently active slave. The MAC |
310 | transmit and receive are particularly susecptible to loss of | 310 | address of the slaves is not changed; instead, the MAC |
311 | the gratuitous ARP, and an appropriate updelay setting may be | 311 | address of the bond changes during a failover. |
312 | required. | 312 | |
313 | 313 | This policy is useful for devices that cannot ever | |
314 | A value of 0 disables fail over MAC, and is the default. A | 314 | alter their MAC address, or for devices that refuse |
315 | value of 1 enables fail over MAC. This option is enabled | 315 | incoming broadcasts with their own source MAC (which |
316 | automatically if the first slave added cannot change its MAC | 316 | interferes with the ARP monitor). |
317 | address. This option may be modified via sysfs only when no | 317 | |
318 | slaves are present in the bond. | 318 | The down side of this policy is that every device on |
319 | 319 | the network must be updated via gratuitous ARP, | |
320 | This option was added in bonding version 3.2.0. | 320 | vs. just updating a switch or set of switches (which |
321 | often takes place for any traffic, not just ARP | ||
322 | traffic, if the switch snoops incoming traffic to | ||
323 | update its tables) for the traditional method. If the | ||
324 | gratuitous ARP is lost, communication may be | ||
325 | disrupted. | ||
326 | |||
327 | When this policy is used in conjuction with the mii | ||
328 | monitor, devices which assert link up prior to being | ||
329 | able to actually transmit and receive are particularly | ||
330 | susecptible to loss of the gratuitous ARP, and an | ||
331 | appropriate updelay setting may be required. | ||
332 | |||
333 | follow or 2 | ||
334 | |||
335 | The "follow" fail_over_mac policy causes the MAC | ||
336 | address of the bond to be selected normally (normally | ||
337 | the MAC address of the first slave added to the bond). | ||
338 | However, the second and subsequent slaves are not set | ||
339 | to this MAC address while they are in a backup role; a | ||
340 | slave is programmed with the bond's MAC address at | ||
341 | failover time (and the formerly active slave receives | ||
342 | the newly active slave's MAC address). | ||
343 | |||
344 | This policy is useful for multiport devices that | ||
345 | either become confused or incur a performance penalty | ||
346 | when multiple ports are programmed with the same MAC | ||
347 | address. | ||
348 | |||
349 | |||
350 | The default policy is none, unless the first slave cannot | ||
351 | change its MAC address, in which case the active policy is | ||
352 | selected by default. | ||
353 | |||
354 | This option may be modified via sysfs only when no slaves are | ||
355 | present in the bond. | ||
356 | |||
357 | This option was added in bonding version 3.2.0. The "follow" | ||
358 | policy was added in bonding version 3.3.0. | ||
321 | 359 | ||
322 | lacp_rate | 360 | lacp_rate |
323 | 361 | ||
@@ -338,7 +376,8 @@ max_bonds | |||
338 | Specifies the number of bonding devices to create for this | 376 | Specifies the number of bonding devices to create for this |
339 | instance of the bonding driver. E.g., if max_bonds is 3, and | 377 | instance of the bonding driver. E.g., if max_bonds is 3, and |
340 | the bonding driver is not already loaded, then bond0, bond1 | 378 | the bonding driver is not already loaded, then bond0, bond1 |
341 | and bond2 will be created. The default value is 1. | 379 | and bond2 will be created. The default value is 1. Specifying |
380 | a value of 0 will load bonding, but will not create any devices. | ||
342 | 381 | ||
343 | miimon | 382 | miimon |
344 | 383 | ||
@@ -501,6 +540,17 @@ mode | |||
501 | swapped with the new curr_active_slave that was | 540 | swapped with the new curr_active_slave that was |
502 | chosen. | 541 | chosen. |
503 | 542 | ||
543 | num_grat_arp | ||
544 | |||
545 | Specifies the number of gratuitous ARPs to be issued after a | ||
546 | failover event. One gratuitous ARP is issued immediately after | ||
547 | the failover, subsequent ARPs are sent at a rate of one per link | ||
548 | monitor interval (arp_interval or miimon, whichever is active). | ||
549 | |||
550 | The valid range is 0 - 255; the default value is 1. This option | ||
551 | affects only the active-backup mode. This option was added for | ||
552 | bonding version 3.3.0. | ||
553 | |||
504 | primary | 554 | primary |
505 | 555 | ||
506 | A string (eth0, eth2, etc) specifying which slave is the | 556 | A string (eth0, eth2, etc) specifying which slave is the |
diff --git a/Documentation/networking/dm9000.txt b/Documentation/networking/dm9000.txt new file mode 100644 index 000000000000..65df3dea5561 --- /dev/null +++ b/Documentation/networking/dm9000.txt | |||
@@ -0,0 +1,167 @@ | |||
1 | DM9000 Network driver | ||
2 | ===================== | ||
3 | |||
4 | Copyright 2008 Simtec Electronics, | ||
5 | Ben Dooks <ben@simtec.co.uk> <ben-linux@fluff.org> | ||
6 | |||
7 | |||
8 | Introduction | ||
9 | ------------ | ||
10 | |||
11 | This file describes how to use the DM9000 platform-device based network driver | ||
12 | that is contained in the files drivers/net/dm9000.c and drivers/net/dm9000.h. | ||
13 | |||
14 | The driver supports three DM9000 variants, the DM9000E which is the first chip | ||
15 | supported as well as the newer DM9000A and DM9000B devices. It is currently | ||
16 | maintained and tested by Ben Dooks, who should be CC: to any patches for this | ||
17 | driver. | ||
18 | |||
19 | |||
20 | Defining the platform device | ||
21 | ---------------------------- | ||
22 | |||
23 | The minimum set of resources attached to the platform device are as follows: | ||
24 | |||
25 | 1) The physical address of the address register | ||
26 | 2) The physical address of the data register | ||
27 | 3) The IRQ line the device's interrupt pin is connected to. | ||
28 | |||
29 | These resources should be specified in that order, as the ordering of the | ||
30 | two address regions is important (the driver expects these to be address | ||
31 | and then data). | ||
32 | |||
33 | An example from arch/arm/mach-s3c2410/mach-bast.c is: | ||
34 | |||
35 | static struct resource bast_dm9k_resource[] = { | ||
36 | [0] = { | ||
37 | .start = S3C2410_CS5 + BAST_PA_DM9000, | ||
38 | .end = S3C2410_CS5 + BAST_PA_DM9000 + 3, | ||
39 | .flags = IORESOURCE_MEM, | ||
40 | }, | ||
41 | [1] = { | ||
42 | .start = S3C2410_CS5 + BAST_PA_DM9000 + 0x40, | ||
43 | .end = S3C2410_CS5 + BAST_PA_DM9000 + 0x40 + 0x3f, | ||
44 | .flags = IORESOURCE_MEM, | ||
45 | }, | ||
46 | [2] = { | ||
47 | .start = IRQ_DM9000, | ||
48 | .end = IRQ_DM9000, | ||
49 | .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL, | ||
50 | } | ||
51 | }; | ||
52 | |||
53 | static struct platform_device bast_device_dm9k = { | ||
54 | .name = "dm9000", | ||
55 | .id = 0, | ||
56 | .num_resources = ARRAY_SIZE(bast_dm9k_resource), | ||
57 | .resource = bast_dm9k_resource, | ||
58 | }; | ||
59 | |||
60 | Note the setting of the IRQ trigger flag in bast_dm9k_resource[2].flags, | ||
61 | as this will generate a warning if it is not present. The trigger from | ||
62 | the flags field will be passed to request_irq() when registering the IRQ | ||
63 | handler to ensure that the IRQ is setup correctly. | ||
64 | |||
65 | This shows a typical platform device, without the optional configuration | ||
66 | platform data supplied. The next example uses the same resources, but adds | ||
67 | the optional platform data to pass extra configuration data: | ||
68 | |||
69 | static struct dm9000_plat_data bast_dm9k_platdata = { | ||
70 | .flags = DM9000_PLATF_16BITONLY, | ||
71 | }; | ||
72 | |||
73 | static struct platform_device bast_device_dm9k = { | ||
74 | .name = "dm9000", | ||
75 | .id = 0, | ||
76 | .num_resources = ARRAY_SIZE(bast_dm9k_resource), | ||
77 | .resource = bast_dm9k_resource, | ||
78 | .dev = { | ||
79 | .platform_data = &bast_dm9k_platdata, | ||
80 | } | ||
81 | }; | ||
82 | |||
83 | The platform data is defined in include/linux/dm9000.h and described below. | ||
84 | |||
85 | |||
86 | Platform data | ||
87 | ------------- | ||
88 | |||
89 | Extra platform data for the DM9000 can describe the IO bus width to the | ||
90 | device, whether or not an external PHY is attached to the device and | ||
91 | the availability of an external configuration EEPROM. | ||
92 | |||
93 | The flags for the platform data .flags field are as follows: | ||
94 | |||
95 | DM9000_PLATF_8BITONLY | ||
96 | |||
97 | The IO should be done with 8bit operations. | ||
98 | |||
99 | DM9000_PLATF_16BITONLY | ||
100 | |||
101 | The IO should be done with 16bit operations. | ||
102 | |||
103 | DM9000_PLATF_32BITONLY | ||
104 | |||
105 | The IO should be done with 32bit operations. | ||
106 | |||
107 | DM9000_PLATF_EXT_PHY | ||
108 | |||
109 | The chip is connected to an external PHY. | ||
110 | |||
111 | DM9000_PLATF_NO_EEPROM | ||
112 | |||
113 | This can be used to signify that the board does not have an | ||
114 | EEPROM, or that the EEPROM should be hidden from the user. | ||
115 | |||
116 | DM9000_PLATF_SIMPLE_PHY | ||
117 | |||
118 | Switch to using the simpler PHY polling method which does not | ||
119 | try and read the MII PHY state regularly. This is only available | ||
120 | when using the internal PHY. See the section on link state polling | ||
121 | for more information. | ||
122 | |||
123 | The config symbol DM9000_FORCE_SIMPLE_PHY_POLL, Kconfig entry | ||
124 | "Force simple NSR based PHY polling" allows this flag to be | ||
125 | forced on at build time. | ||
126 | |||
127 | |||
128 | PHY Link state polling | ||
129 | ---------------------- | ||
130 | |||
131 | The driver keeps track of the link state and informs the network core | ||
132 | about link (carrier) availablilty. This is managed by several methods | ||
133 | depending on the version of the chip and on which PHY is being used. | ||
134 | |||
135 | For the internal PHY, the original (and currently default) method is | ||
136 | to read the MII state, either when the status changes if we have the | ||
137 | necessary interrupt support in the chip or every two seconds via a | ||
138 | periodic timer. | ||
139 | |||
140 | To reduce the overhead for the internal PHY, there is now the option | ||
141 | of using the DM9000_FORCE_SIMPLE_PHY_POLL config, or DM9000_PLATF_SIMPLE_PHY | ||
142 | platform data option to read the summary information without the | ||
143 | expensive MII accesses. This method is faster, but does not print | ||
144 | as much information. | ||
145 | |||
146 | When using an external PHY, the driver currently has to poll the MII | ||
147 | link status as there is no method for getting an interrupt on link change. | ||
148 | |||
149 | |||
150 | DM9000A / DM9000B | ||
151 | ----------------- | ||
152 | |||
153 | These chips are functionally similar to the DM9000E and are supported easily | ||
154 | by the same driver. The features are: | ||
155 | |||
156 | 1) Interrupt on internal PHY state change. This means that the periodic | ||
157 | polling of the PHY status may be disabled on these devices when using | ||
158 | the internal PHY. | ||
159 | |||
160 | 2) TCP/UDP checksum offloading, which the driver does not currently support. | ||
161 | |||
162 | |||
163 | ethtool | ||
164 | ------- | ||
165 | |||
166 | The driver supports the ethtool interface for access to the driver | ||
167 | state information, the PHY state and the EEPROM. | ||
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 61b171cf5313..2df71861e578 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt | |||
@@ -513,21 +513,11 @@ Additional Configurations | |||
513 | Intel(R) PRO/1000 PT Dual Port Server Connection | 513 | Intel(R) PRO/1000 PT Dual Port Server Connection |
514 | Intel(R) PRO/1000 PT Dual Port Server Adapter | 514 | Intel(R) PRO/1000 PT Dual Port Server Adapter |
515 | Intel(R) PRO/1000 PF Dual Port Server Adapter | 515 | Intel(R) PRO/1000 PF Dual Port Server Adapter |
516 | Intel(R) PRO/1000 PT Quad Port Server Adapter | 516 | Intel(R) PRO/1000 PT Quad Port Server Adapter |
517 | 517 | ||
518 | NAPI | 518 | NAPI |
519 | ---- | 519 | ---- |
520 | NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled | 520 | NAPI (Rx polling mode) is enabled in the e1000 driver. |
521 | or disabled based on the configuration of the kernel. To override | ||
522 | the default, use the following compile-time flags. | ||
523 | |||
524 | To enable NAPI, compile the driver module, passing in a configuration option: | ||
525 | |||
526 | make CFLAGS_EXTRA=-DE1000_NAPI install | ||
527 | |||
528 | To disable NAPI, compile the driver module, passing in a configuration option: | ||
529 | |||
530 | make CFLAGS_EXTRA=-DE1000_NO_NAPI install | ||
531 | 521 | ||
532 | See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. | 522 | See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. |
533 | 523 | ||
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 946b66e1b652..d84932650fd3 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt | |||
@@ -551,8 +551,9 @@ icmp_echo_ignore_broadcasts - BOOLEAN | |||
551 | icmp_ratelimit - INTEGER | 551 | icmp_ratelimit - INTEGER |
552 | Limit the maximal rates for sending ICMP packets whose type matches | 552 | Limit the maximal rates for sending ICMP packets whose type matches |
553 | icmp_ratemask (see below) to specific targets. | 553 | icmp_ratemask (see below) to specific targets. |
554 | 0 to disable any limiting, otherwise the maximal rate in jiffies(1) | 554 | 0 to disable any limiting, |
555 | Default: 100 | 555 | otherwise the minimal space between responses in milliseconds. |
556 | Default: 1000 | ||
556 | 557 | ||
557 | icmp_ratemask - INTEGER | 558 | icmp_ratemask - INTEGER |
558 | Mask made of ICMP types for which rates are being limited. | 559 | Mask made of ICMP types for which rates are being limited. |
@@ -1023,11 +1024,23 @@ max_addresses - INTEGER | |||
1023 | autoconfigured addresses. | 1024 | autoconfigured addresses. |
1024 | Default: 16 | 1025 | Default: 16 |
1025 | 1026 | ||
1027 | disable_ipv6 - BOOLEAN | ||
1028 | Disable IPv6 operation. | ||
1029 | Default: FALSE (enable IPv6 operation) | ||
1030 | |||
1031 | accept_dad - INTEGER | ||
1032 | Whether to accept DAD (Duplicate Address Detection). | ||
1033 | 0: Disable DAD | ||
1034 | 1: Enable DAD (default) | ||
1035 | 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate | ||
1036 | link-local address has been found. | ||
1037 | |||
1026 | icmp/*: | 1038 | icmp/*: |
1027 | ratelimit - INTEGER | 1039 | ratelimit - INTEGER |
1028 | Limit the maximal rates for sending ICMPv6 packets. | 1040 | Limit the maximal rates for sending ICMPv6 packets. |
1029 | 0 to disable any limiting, otherwise the maximal rate in jiffies(1) | 1041 | 0 to disable any limiting, |
1030 | Default: 100 | 1042 | otherwise the minimal space between responses in milliseconds. |
1043 | Default: 1000 | ||
1031 | 1044 | ||
1032 | 1045 | ||
1033 | IPv6 Update by: | 1046 | IPv6 Update by: |
diff --git a/Documentation/networking/ixgb.txt b/Documentation/networking/ixgb.txt index 7c98277777eb..a0d0ffb5e584 100644 --- a/Documentation/networking/ixgb.txt +++ b/Documentation/networking/ixgb.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | Linux* Base Driver for the Intel(R) PRO/10GbE Family of Adapters | 1 | Linux Base Driver for 10 Gigabit Intel(R) Network Connection |
2 | ================================================================ | 2 | ============================================================= |
3 | 3 | ||
4 | November 17, 2004 | 4 | October 9, 2007 |
5 | 5 | ||
6 | 6 | ||
7 | Contents | 7 | Contents |
@@ -9,94 +9,151 @@ Contents | |||
9 | 9 | ||
10 | - In This Release | 10 | - In This Release |
11 | - Identifying Your Adapter | 11 | - Identifying Your Adapter |
12 | - Building and Installation | ||
12 | - Command Line Parameters | 13 | - Command Line Parameters |
13 | - Improving Performance | 14 | - Improving Performance |
15 | - Additional Configurations | ||
16 | - Known Issues/Troubleshooting | ||
14 | - Support | 17 | - Support |
15 | 18 | ||
16 | 19 | ||
20 | |||
17 | In This Release | 21 | In This Release |
18 | =============== | 22 | =============== |
19 | 23 | ||
20 | This file describes the Linux* Base Driver for the Intel(R) PRO/10GbE Family | 24 | This file describes the ixgb Linux Base Driver for the 10 Gigabit Intel(R) |
21 | of Adapters, version 1.0.x. | 25 | Network Connection. This driver includes support for Itanium(R)2-based |
26 | systems. | ||
27 | |||
28 | For questions related to hardware requirements, refer to the documentation | ||
29 | supplied with your 10 Gigabit adapter. All hardware requirements listed apply | ||
30 | to use with Linux. | ||
31 | |||
32 | The following features are available in this kernel: | ||
33 | - Native VLANs | ||
34 | - Channel Bonding (teaming) | ||
35 | - SNMP | ||
36 | |||
37 | Channel Bonding documentation can be found in the Linux kernel source: | ||
38 | /Documentation/networking/bonding.txt | ||
39 | |||
40 | The driver information previously displayed in the /proc filesystem is not | ||
41 | supported in this release. Alternatively, you can use ethtool (version 1.6 | ||
42 | or later), lspci, and ifconfig to obtain the same information. | ||
43 | |||
44 | Instructions on updating ethtool can be found in the section "Additional | ||
45 | Configurations" later in this document. | ||
22 | 46 | ||
23 | For questions related to hardware requirements, refer to the documentation | ||
24 | supplied with your Intel PRO/10GbE adapter. All hardware requirements listed | ||
25 | apply to use with Linux. | ||
26 | 47 | ||
27 | Identifying Your Adapter | 48 | Identifying Your Adapter |
28 | ======================== | 49 | ======================== |
29 | 50 | ||
30 | To verify your Intel adapter is supported, find the board ID number on the | 51 | The following Intel network adapters are compatible with the drivers in this |
31 | adapter. Look for a label that has a barcode and a number in the format | 52 | release: |
32 | A12345-001. | 53 | |
54 | Controller Adapter Name Physical Layer | ||
55 | ---------- ------------ -------------- | ||
56 | 82597EX Intel(R) PRO/10GbE LR/SR/CX4 10G Base-LR (1310 nm optical fiber) | ||
57 | Server Adapters 10G Base-SR (850 nm optical fiber) | ||
58 | 10G Base-CX4(twin-axial copper cabling) | ||
59 | |||
60 | For more information on how to identify your adapter, go to the Adapter & | ||
61 | Driver ID Guide at: | ||
62 | |||
63 | http://support.intel.com/support/network/sb/CS-012904.htm | ||
64 | |||
65 | |||
66 | Building and Installation | ||
67 | ========================= | ||
68 | |||
69 | select m for "Intel(R) PRO/10GbE support" located at: | ||
70 | Location: | ||
71 | -> Device Drivers | ||
72 | -> Network device support (NETDEVICES [=y]) | ||
73 | -> Ethernet (10000 Mbit) (NETDEV_10000 [=y]) | ||
74 | 1. make modules && make modules_install | ||
75 | |||
76 | 2. Load the module: | ||
77 | |||
78 | modprobe ixgb <parameter>=<value> | ||
79 | |||
80 | The insmod command can be used if the full | ||
81 | path to the driver module is specified. For example: | ||
82 | |||
83 | insmod /lib/modules/<KERNEL VERSION>/kernel/drivers/net/ixgb/ixgb.ko | ||
84 | |||
85 | With 2.6 based kernels also make sure that older ixgb drivers are | ||
86 | removed from the kernel, before loading the new module: | ||
33 | 87 | ||
34 | Use the above information and the Adapter & Driver ID Guide at: | 88 | rmmod ixgb; modprobe ixgb |
35 | 89 | ||
36 | http://support.intel.com/support/network/adapter/pro100/21397.htm | 90 | 3. Assign an IP address to the interface by entering the following, where |
91 | x is the interface number: | ||
37 | 92 | ||
38 | For the latest Intel network drivers for Linux, go to: | 93 | ifconfig ethx <IP_address> |
94 | |||
95 | 4. Verify that the interface works. Enter the following, where <IP_address> | ||
96 | is the IP address for another machine on the same subnet as the interface | ||
97 | that is being tested: | ||
98 | |||
99 | ping <IP_address> | ||
39 | 100 | ||
40 | http://downloadfinder.intel.com/scripts-df/support_intel.asp | ||
41 | 101 | ||
42 | Command Line Parameters | 102 | Command Line Parameters |
43 | ======================= | 103 | ======================= |
44 | 104 | ||
45 | If the driver is built as a module, the following optional parameters are | 105 | If the driver is built as a module, the following optional parameters are |
46 | used by entering them on the command line with the modprobe or insmod command | 106 | used by entering them on the command line with the modprobe command using |
47 | using this syntax: | 107 | this syntax: |
48 | 108 | ||
49 | modprobe ixgb [<option>=<VAL1>,<VAL2>,...] | 109 | modprobe ixgb [<option>=<VAL1>,<VAL2>,...] |
50 | 110 | ||
51 | insmod ixgb [<option>=<VAL1>,<VAL2>,...] | 111 | For example, with two 10GbE PCI adapters, entering: |
52 | 112 | ||
53 | For example, with two PRO/10GbE PCI adapters, entering: | 113 | modprobe ixgb TxDescriptors=80,128 |
54 | 114 | ||
55 | insmod ixgb TxDescriptors=80,128 | 115 | loads the ixgb driver with 80 TX resources for the first adapter and 128 TX |
56 | |||
57 | loads the ixgb driver with 80 TX resources for the first adapter and 128 TX | ||
58 | resources for the second adapter. | 116 | resources for the second adapter. |
59 | 117 | ||
60 | The default value for each parameter is generally the recommended setting, | 118 | The default value for each parameter is generally the recommended setting, |
61 | unless otherwise noted. Also, if the driver is statically built into the | 119 | unless otherwise noted. |
62 | kernel, the driver is loaded with the default values for all the parameters. | ||
63 | Ethtool can be used to change some of the parameters at runtime. | ||
64 | 120 | ||
65 | FlowControl | 121 | FlowControl |
66 | Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx) | 122 | Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx) |
67 | Default: Read from the EEPROM | 123 | Default: Read from the EEPROM |
68 | If EEPROM is not detected, default is 3 | 124 | If EEPROM is not detected, default is 1 |
69 | This parameter controls the automatic generation(Tx) and response(Rx) to | 125 | This parameter controls the automatic generation(Tx) and response(Rx) to |
70 | Ethernet PAUSE frames. | 126 | Ethernet PAUSE frames. There are hardware bugs associated with enabling |
127 | Tx flow control so beware. | ||
71 | 128 | ||
72 | RxDescriptors | 129 | RxDescriptors |
73 | Valid Range: 64-512 | 130 | Valid Range: 64-512 |
74 | Default Value: 512 | 131 | Default Value: 512 |
75 | This value is the number of receive descriptors allocated by the driver. | 132 | This value is the number of receive descriptors allocated by the driver. |
76 | Increasing this value allows the driver to buffer more incoming packets. | 133 | Increasing this value allows the driver to buffer more incoming packets. |
77 | Each descriptor is 16 bytes. A receive buffer is also allocated for | 134 | Each descriptor is 16 bytes. A receive buffer is also allocated for |
78 | each descriptor and can be either 2048, 4056, 8192, or 16384 bytes, | 135 | each descriptor and can be either 2048, 4056, 8192, or 16384 bytes, |
79 | depending on the MTU setting. When the MTU size is 1500 or less, the | 136 | depending on the MTU setting. When the MTU size is 1500 or less, the |
80 | receive buffer size is 2048 bytes. When the MTU is greater than 1500 the | 137 | receive buffer size is 2048 bytes. When the MTU is greater than 1500 the |
81 | receive buffer size will be either 4056, 8192, or 16384 bytes. The | 138 | receive buffer size will be either 4056, 8192, or 16384 bytes. The |
82 | maximum MTU size is 16114. | 139 | maximum MTU size is 16114. |
83 | 140 | ||
84 | RxIntDelay | 141 | RxIntDelay |
85 | Valid Range: 0-65535 (0=off) | 142 | Valid Range: 0-65535 (0=off) |
86 | Default Value: 6 | 143 | Default Value: 72 |
87 | This value delays the generation of receive interrupts in units of | 144 | This value delays the generation of receive interrupts in units of |
88 | 0.8192 microseconds. Receive interrupt reduction can improve CPU | 145 | 0.8192 microseconds. Receive interrupt reduction can improve CPU |
89 | efficiency if properly tuned for specific network traffic. Increasing | 146 | efficiency if properly tuned for specific network traffic. Increasing |
90 | this value adds extra latency to frame reception and can end up | 147 | this value adds extra latency to frame reception and can end up |
91 | decreasing the throughput of TCP traffic. If the system is reporting | 148 | decreasing the throughput of TCP traffic. If the system is reporting |
92 | dropped receives, this value may be set too high, causing the driver to | 149 | dropped receives, this value may be set too high, causing the driver to |
93 | run out of available receive descriptors. | 150 | run out of available receive descriptors. |
94 | 151 | ||
95 | TxDescriptors | 152 | TxDescriptors |
96 | Valid Range: 64-4096 | 153 | Valid Range: 64-4096 |
97 | Default Value: 256 | 154 | Default Value: 256 |
98 | This value is the number of transmit descriptors allocated by the driver. | 155 | This value is the number of transmit descriptors allocated by the driver. |
99 | Increasing this value allows the driver to queue more transmits. Each | 156 | Increasing this value allows the driver to queue more transmits. Each |
100 | descriptor is 16 bytes. | 157 | descriptor is 16 bytes. |
101 | 158 | ||
102 | XsumRX | 159 | XsumRX |
@@ -105,51 +162,49 @@ Default Value: 1 | |||
105 | A value of '1' indicates that the driver should enable IP checksum | 162 | A value of '1' indicates that the driver should enable IP checksum |
106 | offload for received packets (both UDP and TCP) to the adapter hardware. | 163 | offload for received packets (both UDP and TCP) to the adapter hardware. |
107 | 164 | ||
108 | XsumTX | ||
109 | Valid Range: 0-1 | ||
110 | Default Value: 1 | ||
111 | A value of '1' indicates that the driver should enable IP checksum | ||
112 | offload for transmitted packets (both UDP and TCP) to the adapter | ||
113 | hardware. | ||
114 | 165 | ||
115 | Improving Performance | 166 | Improving Performance |
116 | ===================== | 167 | ===================== |
117 | 168 | ||
118 | With the Intel PRO/10 GbE adapter, the default Linux configuration will very | 169 | With the 10 Gigabit server adapters, the default Linux configuration will |
119 | likely limit the total available throughput artificially. There is a set of | 170 | very likely limit the total available throughput artificially. There is a set |
120 | things that when applied together increase the ability of Linux to transmit | 171 | of configuration changes that, when applied together, will increase the ability |
121 | and receive data. The following enhancements were originally acquired from | 172 | of Linux to transmit and receive data. The following enhancements were |
122 | settings published at http://www.spec.org/web99 for various submitted results | 173 | originally acquired from settings published at http://www.spec.org/web99/ for |
123 | using Linux. | 174 | various submitted results using Linux. |
124 | 175 | ||
125 | NOTE: These changes are only suggestions, and serve as a starting point for | 176 | NOTE: These changes are only suggestions, and serve as a starting point for |
126 | tuning your network performance. | 177 | tuning your network performance. |
127 | 178 | ||
128 | The changes are made in three major ways, listed in order of greatest effect: | 179 | The changes are made in three major ways, listed in order of greatest effect: |
129 | - Use ifconfig to modify the mtu (maximum transmission unit) and the txqueuelen | 180 | - Use ifconfig to modify the mtu (maximum transmission unit) and the txqueuelen |
130 | parameter. | 181 | parameter. |
131 | - Use sysctl to modify /proc parameters (essentially kernel tuning) | 182 | - Use sysctl to modify /proc parameters (essentially kernel tuning) |
132 | - Use setpci to modify the MMRBC field in PCI-X configuration space to increase | 183 | - Use setpci to modify the MMRBC field in PCI-X configuration space to increase |
133 | transmit burst lengths on the bus. | 184 | transmit burst lengths on the bus. |
134 | 185 | ||
135 | NOTE: setpci modifies the adapter's configuration registers to allow it to read | 186 | NOTE: setpci modifies the adapter's configuration registers to allow it to read |
136 | up to 4k bytes at a time (for transmits). However, for some systems the | 187 | up to 4k bytes at a time (for transmits). However, for some systems the |
137 | behavior after modifying this register may be undefined (possibly errors of some | 188 | behavior after modifying this register may be undefined (possibly errors of |
138 | kind). A power-cycle, hard reset or explicitly setting the e6 register back to | 189 | some kind). A power-cycle, hard reset or explicitly setting the e6 register |
139 | 22 (setpci -d 8086:1048 e6.b=22) may be required to get back to a stable | 190 | back to 22 (setpci -d 8086:1a48 e6.b=22) may be required to get back to a |
140 | configuration. | 191 | stable configuration. |
141 | 192 | ||
142 | - COPY these lines and paste them into ixgb_perf.sh: | 193 | - COPY these lines and paste them into ixgb_perf.sh: |
143 | #!/bin/bash | 194 | #!/bin/bash |
144 | echo "configuring network performance , edit this file to change the interface" | 195 | echo "configuring network performance , edit this file to change the interface |
196 | or device ID of 10GbE card" | ||
145 | # set mmrbc to 4k reads, modify only Intel 10GbE device IDs | 197 | # set mmrbc to 4k reads, modify only Intel 10GbE device IDs |
146 | setpci -d 8086:1048 e6.b=2e | 198 | # replace 1a48 with appropriate 10GbE device's ID installed on the system, |
147 | # set the MTU (max transmission unit) - it requires your switch and clients to change too! | 199 | # if needed. |
200 | setpci -d 8086:1a48 e6.b=2e | ||
201 | # set the MTU (max transmission unit) - it requires your switch and clients | ||
202 | # to change as well. | ||
148 | # set the txqueuelen | 203 | # set the txqueuelen |
149 | # your ixgb adapter should be loaded as eth1 for this to work, change if needed | 204 | # your ixgb adapter should be loaded as eth1 for this to work, change if needed |
150 | ifconfig eth1 mtu 9000 txqueuelen 1000 up | 205 | ifconfig eth1 mtu 9000 txqueuelen 1000 up |
151 | # call the sysctl utility to modify /proc/sys entries | 206 | # call the sysctl utility to modify /proc/sys entries |
152 | sysctl -p ./sysctl_ixgb.conf | 207 | sysctl -p ./sysctl_ixgb.conf |
153 | - END ixgb_perf.sh | 208 | - END ixgb_perf.sh |
154 | 209 | ||
155 | - COPY these lines and paste them into sysctl_ixgb.conf: | 210 | - COPY these lines and paste them into sysctl_ixgb.conf: |
@@ -159,54 +214,220 @@ sysctl -p ./sysctl_ixgb.conf | |||
159 | # several network benchmark tests, your mileage may vary | 214 | # several network benchmark tests, your mileage may vary |
160 | 215 | ||
161 | ### IPV4 specific settings | 216 | ### IPV4 specific settings |
162 | net.ipv4.tcp_timestamps = 0 # turns TCP timestamp support off, default 1, reduces CPU use | 217 | # turn TCP timestamp support off, default 1, reduces CPU use |
163 | net.ipv4.tcp_sack = 0 # turn SACK support off, default on | 218 | net.ipv4.tcp_timestamps = 0 |
164 | # on systems with a VERY fast bus -> memory interface this is the big gainer | 219 | # turn SACK support off, default on |
165 | net.ipv4.tcp_rmem = 10000000 10000000 10000000 # sets min/default/max TCP read buffer, default 4096 87380 174760 | 220 | # on systems with a VERY fast bus -> memory interface this is the big gainer |
166 | net.ipv4.tcp_wmem = 10000000 10000000 10000000 # sets min/pressure/max TCP write buffer, default 4096 16384 131072 | 221 | net.ipv4.tcp_sack = 0 |
167 | net.ipv4.tcp_mem = 10000000 10000000 10000000 # sets min/pressure/max TCP buffer space, default 31744 32256 32768 | 222 | # set min/default/max TCP read buffer, default 4096 87380 174760 |
223 | net.ipv4.tcp_rmem = 10000000 10000000 10000000 | ||
224 | # set min/pressure/max TCP write buffer, default 4096 16384 131072 | ||
225 | net.ipv4.tcp_wmem = 10000000 10000000 10000000 | ||
226 | # set min/pressure/max TCP buffer space, default 31744 32256 32768 | ||
227 | net.ipv4.tcp_mem = 10000000 10000000 10000000 | ||
168 | 228 | ||
169 | ### CORE settings (mostly for socket and UDP effect) | 229 | ### CORE settings (mostly for socket and UDP effect) |
170 | net.core.rmem_max = 524287 # maximum receive socket buffer size, default 131071 | 230 | # set maximum receive socket buffer size, default 131071 |
171 | net.core.wmem_max = 524287 # maximum send socket buffer size, default 131071 | 231 | net.core.rmem_max = 524287 |
172 | net.core.rmem_default = 524287 # default receive socket buffer size, default 65535 | 232 | # set maximum send socket buffer size, default 131071 |
173 | net.core.wmem_default = 524287 # default send socket buffer size, default 65535 | 233 | net.core.wmem_max = 524287 |
174 | net.core.optmem_max = 524287 # maximum amount of option memory buffers, default 10240 | 234 | # set default receive socket buffer size, default 65535 |
175 | net.core.netdev_max_backlog = 300000 # number of unprocessed input packets before kernel starts dropping them, default 300 | 235 | net.core.rmem_default = 524287 |
236 | # set default send socket buffer size, default 65535 | ||
237 | net.core.wmem_default = 524287 | ||
238 | # set maximum amount of option memory buffers, default 10240 | ||
239 | net.core.optmem_max = 524287 | ||
240 | # set number of unprocessed input packets before kernel starts dropping them; default 300 | ||
241 | net.core.netdev_max_backlog = 300000 | ||
176 | - END sysctl_ixgb.conf | 242 | - END sysctl_ixgb.conf |
177 | 243 | ||
178 | Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface | 244 | Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface |
179 | your ixgb driver is using. | 245 | your ixgb driver is using and/or replace '1a48' with appropriate 10GbE device's |
246 | ID installed on the system. | ||
180 | 247 | ||
181 | NOTE: Unless these scripts are added to the boot process, these changes will | 248 | NOTE: Unless these scripts are added to the boot process, these changes will |
182 | only last only until the next system reboot. | 249 | only last only until the next system reboot. |
183 | 250 | ||
184 | 251 | ||
185 | Resolving Slow UDP Traffic | 252 | Resolving Slow UDP Traffic |
186 | -------------------------- | 253 | -------------------------- |
254 | If your server does not seem to be able to receive UDP traffic as fast as it | ||
255 | can receive TCP traffic, it could be because Linux, by default, does not set | ||
256 | the network stack buffers as large as they need to be to support high UDP | ||
257 | transfer rates. One way to alleviate this problem is to allow more memory to | ||
258 | be used by the IP stack to store incoming data. | ||
187 | 259 | ||
188 | If your server does not seem to be able to receive UDP traffic as fast as it | 260 | For instance, use the commands: |
189 | can receive TCP traffic, it could be because Linux, by default, does not set | ||
190 | the network stack buffers as large as they need to be to support high UDP | ||
191 | transfer rates. One way to alleviate this problem is to allow more memory to | ||
192 | be used by the IP stack to store incoming data. | ||
193 | |||
194 | For instance, use the commands: | ||
195 | sysctl -w net.core.rmem_max=262143 | 261 | sysctl -w net.core.rmem_max=262143 |
196 | and | 262 | and |
197 | sysctl -w net.core.rmem_default=262143 | 263 | sysctl -w net.core.rmem_default=262143 |
198 | to increase the read buffer memory max and default to 262143 (256k - 1) from | 264 | to increase the read buffer memory max and default to 262143 (256k - 1) from |
199 | defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables | 265 | defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables |
200 | will increase the amount of memory used by the network stack for receives, and | 266 | will increase the amount of memory used by the network stack for receives, and |
201 | can be increased significantly more if necessary for your application. | 267 | can be increased significantly more if necessary for your application. |
202 | 268 | ||
269 | |||
270 | Additional Configurations | ||
271 | ========================= | ||
272 | |||
273 | Configuring the Driver on Different Distributions | ||
274 | ------------------------------------------------- | ||
275 | Configuring a network driver to load properly when the system is started is | ||
276 | distribution dependent. Typically, the configuration process involves adding | ||
277 | an alias line to /etc/modprobe.conf as well as editing other system startup | ||
278 | scripts and/or configuration files. Many popular Linux distributions ship | ||
279 | with tools to make these changes for you. To learn the proper way to | ||
280 | configure a network device for your system, refer to your distribution | ||
281 | documentation. If during this process you are asked for the driver or module | ||
282 | name, the name for the Linux Base Driver for the Intel 10GbE Family of | ||
283 | Adapters is ixgb. | ||
284 | |||
285 | Viewing Link Messages | ||
286 | --------------------- | ||
287 | Link messages will not be displayed to the console if the distribution is | ||
288 | restricting system messages. In order to see network driver link messages on | ||
289 | your console, set dmesg to eight by entering the following: | ||
290 | |||
291 | dmesg -n 8 | ||
292 | |||
293 | NOTE: This setting is not saved across reboots. | ||
294 | |||
295 | |||
296 | Jumbo Frames | ||
297 | ------------ | ||
298 | The driver supports Jumbo Frames for all adapters. Jumbo Frames support is | ||
299 | enabled by changing the MTU to a value larger than the default of 1500. | ||
300 | The maximum value for the MTU is 16114. Use the ifconfig command to | ||
301 | increase the MTU size. For example: | ||
302 | |||
303 | ifconfig ethx mtu 9000 up | ||
304 | |||
305 | The maximum MTU setting for Jumbo Frames is 16114. This value coincides | ||
306 | with the maximum Jumbo Frames size of 16128. | ||
307 | |||
308 | |||
309 | Ethtool | ||
310 | ------- | ||
311 | The driver utilizes the ethtool interface for driver configuration and | ||
312 | diagnostics, as well as displaying statistical information. Ethtool | ||
313 | version 1.6 or later is required for this functionality. | ||
314 | |||
315 | The latest release of ethtool can be found from | ||
316 | http://sourceforge.net/projects/gkernel | ||
317 | |||
318 | NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support | ||
319 | for a more complete ethtool feature set can be enabled by upgrading | ||
320 | to the latest version. | ||
321 | |||
322 | |||
323 | NAPI | ||
324 | ---- | ||
325 | |||
326 | NAPI (Rx polling mode) is supported in the ixgb driver. NAPI is enabled | ||
327 | or disabled based on the configuration of the kernel. see CONFIG_IXGB_NAPI | ||
328 | |||
329 | See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. | ||
330 | |||
331 | |||
332 | Known Issues/Troubleshooting | ||
333 | ============================ | ||
334 | |||
335 | NOTE: After installing the driver, if your Intel Network Connection is not | ||
336 | working, verify in the "In This Release" section of the readme that you have | ||
337 | installed the correct driver. | ||
338 | |||
339 | Intel(R) PRO/10GbE CX4 Server Adapter Cable Interoperability Issue with | ||
340 | Fujitsu XENPAK Module in SmartBits Chassis | ||
341 | --------------------------------------------------------------------- | ||
342 | Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 | ||
343 | Server adapter is connected to a Fujitsu XENPAK CX4 module in a SmartBits | ||
344 | chassis using 15 m/24AWG cable assemblies manufactured by Fujitsu or Leoni. | ||
345 | The CRC errors may be received either by the Intel(R) PRO/10GbE CX4 | ||
346 | Server adapter or the SmartBits. If this situation occurs using a different | ||
347 | cable assembly may resolve the issue. | ||
348 | |||
349 | CX4 Server Adapter Cable Interoperability Issues with HP Procurve 3400cl | ||
350 | Switch Port | ||
351 | ------------------------------------------------------------------------ | ||
352 | Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 Server | ||
353 | adapter is connected to an HP Procurve 3400cl switch port using short cables | ||
354 | (1 m or shorter). If this situation occurs, using a longer cable may resolve | ||
355 | the issue. | ||
356 | |||
357 | Excessive CRC errors may be observed using Fujitsu 24AWG cable assemblies that | ||
358 | Are 10 m or longer or where using a Leoni 15 m/24AWG cable assembly. The CRC | ||
359 | errors may be received either by the CX4 Server adapter or at the switch. If | ||
360 | this situation occurs, using a different cable assembly may resolve the issue. | ||
361 | |||
362 | |||
363 | Jumbo Frames System Requirement | ||
364 | ------------------------------- | ||
365 | Memory allocation failures have been observed on Linux systems with 64 MB | ||
366 | of RAM or less that are running Jumbo Frames. If you are using Jumbo | ||
367 | Frames, your system may require more than the advertised minimum | ||
368 | requirement of 64 MB of system memory. | ||
369 | |||
370 | |||
371 | Performance Degradation with Jumbo Frames | ||
372 | ----------------------------------------- | ||
373 | Degradation in throughput performance may be observed in some Jumbo frames | ||
374 | environments. If this is observed, increasing the application's socket buffer | ||
375 | size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help. | ||
376 | See the specific application manual and /usr/src/linux*/Documentation/ | ||
377 | networking/ip-sysctl.txt for more details. | ||
378 | |||
379 | |||
380 | Allocating Rx Buffers when Using Jumbo Frames | ||
381 | --------------------------------------------- | ||
382 | Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if | ||
383 | the available memory is heavily fragmented. This issue may be seen with PCI-X | ||
384 | adapters or with packet split disabled. This can be reduced or eliminated | ||
385 | by changing the amount of available memory for receive buffer allocation, by | ||
386 | increasing /proc/sys/vm/min_free_kbytes. | ||
387 | |||
388 | |||
389 | Multiple Interfaces on Same Ethernet Broadcast Network | ||
390 | ------------------------------------------------------ | ||
391 | Due to the default ARP behavior on Linux, it is not possible to have | ||
392 | one system on two IP networks in the same Ethernet broadcast domain | ||
393 | (non-partitioned switch) behave as expected. All Ethernet interfaces | ||
394 | will respond to IP traffic for any IP address assigned to the system. | ||
395 | This results in unbalanced receive traffic. | ||
396 | |||
397 | If you have multiple interfaces in a server, do either of the following: | ||
398 | |||
399 | - Turn on ARP filtering by entering: | ||
400 | echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter | ||
401 | |||
402 | - Install the interfaces in separate broadcast domains - either in | ||
403 | different switches or in a switch partitioned to VLANs. | ||
404 | |||
405 | |||
406 | UDP Stress Test Dropped Packet Issue | ||
407 | -------------------------------------- | ||
408 | Under small packets UDP stress test with 10GbE driver, the Linux system | ||
409 | may drop UDP packets due to the fullness of socket buffers. You may want | ||
410 | to change the driver's Flow Control variables to the minimum value for | ||
411 | controlling packet reception. | ||
412 | |||
413 | |||
414 | Tx Hangs Possible Under Stress | ||
415 | ------------------------------ | ||
416 | Under stress conditions, if TX hangs occur, turning off TSO | ||
417 | "ethtool -K eth0 tso off" may resolve the problem. | ||
418 | |||
419 | |||
203 | Support | 420 | Support |
204 | ======= | 421 | ======= |
205 | 422 | ||
206 | For general information and support, go to the Intel support website at: | 423 | For general information, go to the Intel support website at: |
207 | 424 | ||
208 | http://support.intel.com | 425 | http://support.intel.com |
209 | 426 | ||
427 | or the Intel Wired Networking project hosted by Sourceforge at: | ||
428 | |||
429 | http://sourceforge.net/projects/e1000 | ||
430 | |||
210 | If an issue is identified with the released source code on the supported | 431 | If an issue is identified with the released source code on the supported |
211 | kernel with a supported adapter, email the specific information related to | 432 | kernel with a supported adapter, email the specific information related |
212 | the issue to linux.nics@intel.com. | 433 | to the issue to e1000-devel@lists.sf.net |
diff --git a/Documentation/networking/mac80211_hwsim/README b/Documentation/networking/mac80211_hwsim/README new file mode 100644 index 000000000000..2ff8ccb8dc37 --- /dev/null +++ b/Documentation/networking/mac80211_hwsim/README | |||
@@ -0,0 +1,67 @@ | |||
1 | mac80211_hwsim - software simulator of 802.11 radio(s) for mac80211 | ||
2 | Copyright (c) 2008, Jouni Malinen <j@w1.fi> | ||
3 | |||
4 | This program is free software; you can redistribute it and/or modify | ||
5 | it under the terms of the GNU General Public License version 2 as | ||
6 | published by the Free Software Foundation. | ||
7 | |||
8 | |||
9 | Introduction | ||
10 | |||
11 | mac80211_hwsim is a Linux kernel module that can be used to simulate | ||
12 | arbitrary number of IEEE 802.11 radios for mac80211. It can be used to | ||
13 | test most of the mac80211 functionality and user space tools (e.g., | ||
14 | hostapd and wpa_supplicant) in a way that matches very closely with | ||
15 | the normal case of using real WLAN hardware. From the mac80211 view | ||
16 | point, mac80211_hwsim is yet another hardware driver, i.e., no changes | ||
17 | to mac80211 are needed to use this testing tool. | ||
18 | |||
19 | The main goal for mac80211_hwsim is to make it easier for developers | ||
20 | to test their code and work with new features to mac80211, hostapd, | ||
21 | and wpa_supplicant. The simulated radios do not have the limitations | ||
22 | of real hardware, so it is easy to generate an arbitrary test setup | ||
23 | and always reproduce the same setup for future tests. In addition, | ||
24 | since all radio operation is simulated, any channel can be used in | ||
25 | tests regardless of regulatory rules. | ||
26 | |||
27 | mac80211_hwsim kernel module has a parameter 'radios' that can be used | ||
28 | to select how many radios are simulated (default 2). This allows | ||
29 | configuration of both very simply setups (e.g., just a single access | ||
30 | point and a station) or large scale tests (multiple access points with | ||
31 | hundreds of stations). | ||
32 | |||
33 | mac80211_hwsim works by tracking the current channel of each virtual | ||
34 | radio and copying all transmitted frames to all other radios that are | ||
35 | currently enabled and on the same channel as the transmitting | ||
36 | radio. Software encryption in mac80211 is used so that the frames are | ||
37 | actually encrypted over the virtual air interface to allow more | ||
38 | complete testing of encryption. | ||
39 | |||
40 | A global monitoring netdev, hwsim#, is created independent of | ||
41 | mac80211. This interface can be used to monitor all transmitted frames | ||
42 | regardless of channel. | ||
43 | |||
44 | |||
45 | Simple example | ||
46 | |||
47 | This example shows how to use mac80211_hwsim to simulate two radios: | ||
48 | one to act as an access point and the other as a station that | ||
49 | associates with the AP. hostapd and wpa_supplicant are used to take | ||
50 | care of WPA2-PSK authentication. In addition, hostapd is also | ||
51 | processing access point side of association. | ||
52 | |||
53 | Please note that the current Linux kernel does not enable AP mode, so a | ||
54 | simple patch is needed to enable AP mode selection: | ||
55 | http://johannes.sipsolutions.net/patches/kernel/all/LATEST/006-allow-ap-vlan-modes.patch | ||
56 | |||
57 | |||
58 | # Build mac80211_hwsim as part of kernel configuration | ||
59 | |||
60 | # Load the module | ||
61 | modprobe mac80211_hwsim | ||
62 | |||
63 | # Run hostapd (AP) for wlan0 | ||
64 | hostapd hostapd.conf | ||
65 | |||
66 | # Run wpa_supplicant (station) for wlan1 | ||
67 | wpa_supplicant -Dwext -iwlan1 -c wpa_supplicant.conf | ||
diff --git a/Documentation/networking/mac80211_hwsim/hostapd.conf b/Documentation/networking/mac80211_hwsim/hostapd.conf new file mode 100644 index 000000000000..08cde7e35f2e --- /dev/null +++ b/Documentation/networking/mac80211_hwsim/hostapd.conf | |||
@@ -0,0 +1,11 @@ | |||
1 | interface=wlan0 | ||
2 | driver=nl80211 | ||
3 | |||
4 | hw_mode=g | ||
5 | channel=1 | ||
6 | ssid=mac80211 test | ||
7 | |||
8 | wpa=2 | ||
9 | wpa_key_mgmt=WPA-PSK | ||
10 | wpa_pairwise=CCMP | ||
11 | wpa_passphrase=12345678 | ||
diff --git a/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf b/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf new file mode 100644 index 000000000000..299128cff035 --- /dev/null +++ b/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf | |||
@@ -0,0 +1,10 @@ | |||
1 | ctrl_interface=/var/run/wpa_supplicant | ||
2 | |||
3 | network={ | ||
4 | ssid="mac80211 test" | ||
5 | psk="12345678" | ||
6 | key_mgmt=WPA-PSK | ||
7 | proto=WPA2 | ||
8 | pairwise=CCMP | ||
9 | group=CCMP | ||
10 | } | ||
diff --git a/Documentation/networking/multiqueue.txt b/Documentation/networking/multiqueue.txt index ea5a42e8f79f..d391ea631141 100644 --- a/Documentation/networking/multiqueue.txt +++ b/Documentation/networking/multiqueue.txt | |||
@@ -3,19 +3,11 @@ | |||
3 | =========================================== | 3 | =========================================== |
4 | 4 | ||
5 | Section 1: Base driver requirements for implementing multiqueue support | 5 | Section 1: Base driver requirements for implementing multiqueue support |
6 | Section 2: Qdisc support for multiqueue devices | ||
7 | Section 3: Brief howto using PRIO or RR for multiqueue devices | ||
8 | |||
9 | 6 | ||
10 | Intro: Kernel support for multiqueue devices | 7 | Intro: Kernel support for multiqueue devices |
11 | --------------------------------------------------------- | 8 | --------------------------------------------------------- |
12 | 9 | ||
13 | Kernel support for multiqueue devices is only an API that is presented to the | 10 | Kernel support for multiqueue devices is always present. |
14 | netdevice layer for base drivers to implement. This feature is part of the | ||
15 | core networking stack, and all network devices will be running on the | ||
16 | multiqueue-aware stack. If a base driver only has one queue, then these | ||
17 | changes are transparent to that driver. | ||
18 | |||
19 | 11 | ||
20 | Section 1: Base driver requirements for implementing multiqueue support | 12 | Section 1: Base driver requirements for implementing multiqueue support |
21 | ----------------------------------------------------------------------- | 13 | ----------------------------------------------------------------------- |
@@ -32,84 +24,4 @@ netif_{start|stop|wake}_subqueue() functions to manage each queue while the | |||
32 | device is still operational. netdev->queue_lock is still used when the device | 24 | device is still operational. netdev->queue_lock is still used when the device |
33 | comes online or when it's completely shut down (unregister_netdev(), etc.). | 25 | comes online or when it's completely shut down (unregister_netdev(), etc.). |
34 | 26 | ||
35 | Finally, the base driver should indicate that it is a multiqueue device. The | ||
36 | feature flag NETIF_F_MULTI_QUEUE should be added to the netdev->features | ||
37 | bitmap on device initialization. Below is an example from e1000: | ||
38 | |||
39 | #ifdef CONFIG_E1000_MQ | ||
40 | if ( (adapter->hw.mac.type == e1000_82571) || | ||
41 | (adapter->hw.mac.type == e1000_82572) || | ||
42 | (adapter->hw.mac.type == e1000_80003es2lan)) | ||
43 | netdev->features |= NETIF_F_MULTI_QUEUE; | ||
44 | #endif | ||
45 | |||
46 | |||
47 | Section 2: Qdisc support for multiqueue devices | ||
48 | ----------------------------------------------- | ||
49 | |||
50 | Currently two qdiscs support multiqueue devices. A new round-robin qdisc, | ||
51 | sch_rr, and sch_prio. The qdisc is responsible for classifying the skb's to | ||
52 | bands and queues, and will store the queue mapping into skb->queue_mapping. | ||
53 | Use this field in the base driver to determine which queue to send the skb | ||
54 | to. | ||
55 | |||
56 | sch_rr has been added for hardware that doesn't want scheduling policies from | ||
57 | software, so it's a straight round-robin qdisc. It uses the same syntax and | ||
58 | classification priomap that sch_prio uses, so it should be intuitive to | ||
59 | configure for people who've used sch_prio. | ||
60 | |||
61 | In order to utilitize the multiqueue features of the qdiscs, the network | ||
62 | device layer needs to enable multiple queue support. This can be done by | ||
63 | selecting NETDEVICES_MULTIQUEUE under Drivers. | ||
64 | |||
65 | The PRIO qdisc naturally plugs into a multiqueue device. If | ||
66 | NETDEVICES_MULTIQUEUE is selected, then on qdisc load, the number of | ||
67 | bands requested is compared to the number of queues on the hardware. If they | ||
68 | are equal, it sets a one-to-one mapping up between the queues and bands. If | ||
69 | they're not equal, it will not load the qdisc. This is the same behavior | ||
70 | for RR. Once the association is made, any skb that is classified will have | ||
71 | skb->queue_mapping set, which will allow the driver to properly queue skb's | ||
72 | to multiple queues. | ||
73 | |||
74 | |||
75 | Section 3: Brief howto using PRIO and RR for multiqueue devices | ||
76 | --------------------------------------------------------------- | ||
77 | |||
78 | The userspace command 'tc,' part of the iproute2 package, is used to configure | ||
79 | qdiscs. To add the PRIO qdisc to your network device, assuming the device is | ||
80 | called eth0, run the following command: | ||
81 | |||
82 | # tc qdisc add dev eth0 root handle 1: prio bands 4 multiqueue | ||
83 | |||
84 | This will create 4 bands, 0 being highest priority, and associate those bands | ||
85 | to the queues on your NIC. Assuming eth0 has 4 Tx queues, the band mapping | ||
86 | would look like: | ||
87 | |||
88 | band 0 => queue 0 | ||
89 | band 1 => queue 1 | ||
90 | band 2 => queue 2 | ||
91 | band 3 => queue 3 | ||
92 | |||
93 | Traffic will begin flowing through each queue if your TOS values are assigning | ||
94 | traffic across the various bands. For example, ssh traffic will always try to | ||
95 | go out band 0 based on TOS -> Linux priority conversion (realtime traffic), | ||
96 | so it will be sent out queue 0. ICMP traffic (pings) fall into the "normal" | ||
97 | traffic classification, which is band 1. Therefore pings will be send out | ||
98 | queue 1 on the NIC. | ||
99 | |||
100 | Note the use of the multiqueue keyword. This is only in versions of iproute2 | ||
101 | that support multiqueue networking devices; if this is omitted when loading | ||
102 | a qdisc onto a multiqueue device, the qdisc will load and operate the same | ||
103 | if it were loaded onto a single-queue device (i.e. - sends all traffic to | ||
104 | queue 0). | ||
105 | |||
106 | Another alternative to multiqueue band allocation can be done by using the | ||
107 | multiqueue option and specify 0 bands. If this is the case, the qdisc will | ||
108 | allocate the number of bands to equal the number of queues that the device | ||
109 | reports, and bring the qdisc online. | ||
110 | |||
111 | The behavior of tc filters remains the same, where it will override TOS priority | ||
112 | classification. | ||
113 | |||
114 | |||
115 | Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com> | 27 | Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com> |
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt index 1e28e2ddb90a..c3d6b4d5d014 100644 --- a/Documentation/networking/s2io.txt +++ b/Documentation/networking/s2io.txt | |||
@@ -52,13 +52,10 @@ d. MSI/MSI-X. Can be enabled on platforms which support this feature | |||
52 | (IA64, Xeon) resulting in noticeable performance improvement(upto 7% | 52 | (IA64, Xeon) resulting in noticeable performance improvement(upto 7% |
53 | on certain platforms). | 53 | on certain platforms). |
54 | 54 | ||
55 | e. NAPI. Compile-time option(CONFIG_S2IO_NAPI) for better Rx interrupt | 55 | e. Statistics. Comprehensive MAC-level and software statistics displayed |
56 | moderation. | ||
57 | |||
58 | f. Statistics. Comprehensive MAC-level and software statistics displayed | ||
59 | using "ethtool -S" option. | 56 | using "ethtool -S" option. |
60 | 57 | ||
61 | g. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, | 58 | f. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, |
62 | with multiple steering options. | 59 | with multiple steering options. |
63 | 60 | ||
64 | 4. Command line parameters | 61 | 4. Command line parameters |
diff --git a/Documentation/networking/udplite.txt b/Documentation/networking/udplite.txt index 3870f280280b..855d8da57a23 100644 --- a/Documentation/networking/udplite.txt +++ b/Documentation/networking/udplite.txt | |||
@@ -148,7 +148,7 @@ | |||
148 | getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...); | 148 | getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...); |
149 | 149 | ||
150 | is meaningless (as in TCP). Packets with a zero checksum field are | 150 | is meaningless (as in TCP). Packets with a zero checksum field are |
151 | illegal (cf. RFC 3828, sec. 3.1) will be silently discarded. | 151 | illegal (cf. RFC 3828, sec. 3.1) and will be silently discarded. |
152 | 152 | ||
153 | 4) Fragmentation | 153 | 4) Fragmentation |
154 | 154 | ||
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index de2e5c05d6e7..ea1b70b35793 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt | |||
@@ -41,12 +41,24 @@ Table of Contents | |||
41 | VI - System-on-a-chip devices and nodes | 41 | VI - System-on-a-chip devices and nodes |
42 | 1) Defining child nodes of an SOC | 42 | 1) Defining child nodes of an SOC |
43 | 2) Representing devices without a current OF specification | 43 | 2) Representing devices without a current OF specification |
44 | a) PHY nodes | 44 | a) MDIO IO device |
45 | b) Interrupt controllers | 45 | b) Gianfar-compatible ethernet nodes |
46 | c) CFI or JEDEC memory-mapped NOR flash | 46 | c) PHY nodes |
47 | d) 4xx/Axon EMAC ethernet nodes | 47 | d) Interrupt controllers |
48 | e) Xilinx IP cores | 48 | e) I2C |
49 | f) USB EHCI controllers | 49 | f) Freescale SOC USB controllers |
50 | g) Freescale SOC SEC Security Engines | ||
51 | h) Board Control and Status (BCSR) | ||
52 | i) Freescale QUICC Engine module (QE) | ||
53 | j) CFI or JEDEC memory-mapped NOR flash | ||
54 | k) Global Utilities Block | ||
55 | l) Freescale Communications Processor Module | ||
56 | m) Chipselect/Local Bus | ||
57 | n) 4xx/Axon EMAC ethernet nodes | ||
58 | o) Xilinx IP cores | ||
59 | p) Freescale Synchronous Serial Interface | ||
60 | q) USB EHCI controllers | ||
61 | r) MDIO on GPIOs | ||
50 | 62 | ||
51 | VII - Marvell Discovery mv64[345]6x System Controller chips | 63 | VII - Marvell Discovery mv64[345]6x System Controller chips |
52 | 1) The /system-controller node | 64 | 1) The /system-controller node |
@@ -77,10 +89,12 @@ Table of Contents | |||
77 | 3) OpenPIC Interrupt Controllers | 89 | 3) OpenPIC Interrupt Controllers |
78 | 4) ISA Interrupt Controllers | 90 | 4) ISA Interrupt Controllers |
79 | 91 | ||
80 | VIII - Specifying GPIO information for devices | 92 | IX - Specifying GPIO information for devices |
81 | 1) gpios property | 93 | 1) gpios property |
82 | 2) gpio-controller nodes | 94 | 2) gpio-controller nodes |
83 | 95 | ||
96 | X - Specifying device power management information (sleep property) | ||
97 | |||
84 | Appendix A - Sample SOC node for MPC8540 | 98 | Appendix A - Sample SOC node for MPC8540 |
85 | 99 | ||
86 | 100 | ||
@@ -1815,6 +1829,60 @@ platforms are moved over to use the flattened-device-tree model. | |||
1815 | big-endian; | 1829 | big-endian; |
1816 | }; | 1830 | }; |
1817 | 1831 | ||
1832 | r) Freescale Display Interface Unit | ||
1833 | |||
1834 | The Freescale DIU is a LCD controller, with proper hardware, it can also | ||
1835 | drive DVI monitors. | ||
1836 | |||
1837 | Required properties: | ||
1838 | - compatible : should be "fsl-diu". | ||
1839 | - reg : should contain at least address and length of the DIU register | ||
1840 | set. | ||
1841 | - Interrupts : one DIU interrupt should be describe here. | ||
1842 | |||
1843 | Example (MPC8610HPCD) | ||
1844 | display@2c000 { | ||
1845 | compatible = "fsl,diu"; | ||
1846 | reg = <0x2c000 100>; | ||
1847 | interrupts = <72 2>; | ||
1848 | interrupt-parent = <&mpic>; | ||
1849 | }; | ||
1850 | |||
1851 | s) Freescale on board FPGA | ||
1852 | |||
1853 | This is the memory-mapped registers for on board FPGA. | ||
1854 | |||
1855 | Required properities: | ||
1856 | - compatible : should be "fsl,fpga-pixis". | ||
1857 | - reg : should contain the address and the lenght of the FPPGA register | ||
1858 | set. | ||
1859 | |||
1860 | Example (MPC8610HPCD) | ||
1861 | board-control@e8000000 { | ||
1862 | compatible = "fsl,fpga-pixis"; | ||
1863 | reg = <0xe8000000 32>; | ||
1864 | }; | ||
1865 | |||
1866 | r) MDIO on GPIOs | ||
1867 | |||
1868 | Currently defined compatibles: | ||
1869 | - virtual,gpio-mdio | ||
1870 | |||
1871 | MDC and MDIO lines connected to GPIO controllers are listed in the | ||
1872 | gpios property as described in section VIII.1 in the following order: | ||
1873 | |||
1874 | MDC, MDIO. | ||
1875 | |||
1876 | Example: | ||
1877 | |||
1878 | mdio { | ||
1879 | compatible = "virtual,mdio-gpio"; | ||
1880 | #address-cells = <1>; | ||
1881 | #size-cells = <0>; | ||
1882 | gpios = <&qe_pio_a 11 | ||
1883 | &qe_pio_c 6>; | ||
1884 | }; | ||
1885 | |||
1818 | VII - Marvell Discovery mv64[345]6x System Controller chips | 1886 | VII - Marvell Discovery mv64[345]6x System Controller chips |
1819 | =========================================================== | 1887 | =========================================================== |
1820 | 1888 | ||
@@ -2422,8 +2490,8 @@ encodings listed below: | |||
2422 | 2 = high to low edge sensitive type enabled | 2490 | 2 = high to low edge sensitive type enabled |
2423 | 3 = low to high edge sensitive type enabled | 2491 | 3 = low to high edge sensitive type enabled |
2424 | 2492 | ||
2425 | VIII - Specifying GPIO information for devices | 2493 | IX - Specifying GPIO information for devices |
2426 | ============================================== | 2494 | ============================================ |
2427 | 2495 | ||
2428 | 1) gpios property | 2496 | 1) gpios property |
2429 | ----------------- | 2497 | ----------------- |
@@ -2471,116 +2539,151 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: | |||
2471 | gpio-controller; | 2539 | gpio-controller; |
2472 | }; | 2540 | }; |
2473 | 2541 | ||
2542 | X - Specifying Device Power Management Information (sleep property) | ||
2543 | =================================================================== | ||
2544 | |||
2545 | Devices on SOCs often have mechanisms for placing devices into low-power | ||
2546 | states that are decoupled from the devices' own register blocks. Sometimes, | ||
2547 | this information is more complicated than a cell-index property can | ||
2548 | reasonably describe. Thus, each device controlled in such a manner | ||
2549 | may contain a "sleep" property which describes these connections. | ||
2550 | |||
2551 | The sleep property consists of one or more sleep resources, each of | ||
2552 | which consists of a phandle to a sleep controller, followed by a | ||
2553 | controller-specific sleep specifier of zero or more cells. | ||
2554 | |||
2555 | The semantics of what type of low power modes are possible are defined | ||
2556 | by the sleep controller. Some examples of the types of low power modes | ||
2557 | that may be supported are: | ||
2558 | |||
2559 | - Dynamic: The device may be disabled or enabled at any time. | ||
2560 | - System Suspend: The device may request to be disabled or remain | ||
2561 | awake during system suspend, but will not be disabled until then. | ||
2562 | - Permanent: The device is disabled permanently (until the next hard | ||
2563 | reset). | ||
2564 | |||
2565 | Some devices may share a clock domain with each other, such that they should | ||
2566 | only be suspended when none of the devices are in use. Where reasonable, | ||
2567 | such nodes should be placed on a virtual bus, where the bus has the sleep | ||
2568 | property. If the clock domain is shared among devices that cannot be | ||
2569 | reasonably grouped in this manner, then create a virtual sleep controller | ||
2570 | (similar to an interrupt nexus, except that defining a standardized | ||
2571 | sleep-map should wait until its necessity is demonstrated). | ||
2572 | |||
2474 | Appendix A - Sample SOC node for MPC8540 | 2573 | Appendix A - Sample SOC node for MPC8540 |
2475 | ======================================== | 2574 | ======================================== |
2476 | 2575 | ||
2477 | Note that the #address-cells and #size-cells for the SoC node | 2576 | soc@e0000000 { |
2478 | in this example have been explicitly listed; these are likely | ||
2479 | not necessary as they are usually the same as the root node. | ||
2480 | |||
2481 | soc8540@e0000000 { | ||
2482 | #address-cells = <1>; | 2577 | #address-cells = <1>; |
2483 | #size-cells = <1>; | 2578 | #size-cells = <1>; |
2484 | #interrupt-cells = <2>; | 2579 | compatible = "fsl,mpc8540-ccsr", "simple-bus"; |
2485 | device_type = "soc"; | 2580 | device_type = "soc"; |
2486 | ranges = <00000000 e0000000 00100000> | 2581 | ranges = <0x00000000 0xe0000000 0x00100000> |
2487 | reg = <e0000000 00003000>; | ||
2488 | bus-frequency = <0>; | 2582 | bus-frequency = <0>; |
2489 | 2583 | interrupt-parent = <&pic>; | |
2490 | mdio@24520 { | ||
2491 | reg = <24520 20>; | ||
2492 | device_type = "mdio"; | ||
2493 | compatible = "gianfar"; | ||
2494 | |||
2495 | ethernet-phy@0 { | ||
2496 | linux,phandle = <2452000> | ||
2497 | interrupt-parent = <40000>; | ||
2498 | interrupts = <35 1>; | ||
2499 | reg = <0>; | ||
2500 | device_type = "ethernet-phy"; | ||
2501 | }; | ||
2502 | |||
2503 | ethernet-phy@1 { | ||
2504 | linux,phandle = <2452001> | ||
2505 | interrupt-parent = <40000>; | ||
2506 | interrupts = <35 1>; | ||
2507 | reg = <1>; | ||
2508 | device_type = "ethernet-phy"; | ||
2509 | }; | ||
2510 | |||
2511 | ethernet-phy@3 { | ||
2512 | linux,phandle = <2452002> | ||
2513 | interrupt-parent = <40000>; | ||
2514 | interrupts = <35 1>; | ||
2515 | reg = <3>; | ||
2516 | device_type = "ethernet-phy"; | ||
2517 | }; | ||
2518 | |||
2519 | }; | ||
2520 | 2584 | ||
2521 | ethernet@24000 { | 2585 | ethernet@24000 { |
2522 | #size-cells = <0>; | 2586 | #address-cells = <1>; |
2587 | #size-cells = <1>; | ||
2523 | device_type = "network"; | 2588 | device_type = "network"; |
2524 | model = "TSEC"; | 2589 | model = "TSEC"; |
2525 | compatible = "gianfar"; | 2590 | compatible = "gianfar", "simple-bus"; |
2526 | reg = <24000 1000>; | 2591 | reg = <0x24000 0x1000>; |
2527 | mac-address = [ 00 E0 0C 00 73 00 ]; | 2592 | local-mac-address = [ 00 E0 0C 00 73 00 ]; |
2528 | interrupts = <d 3 e 3 12 3>; | 2593 | interrupts = <29 2 30 2 34 2>; |
2529 | interrupt-parent = <40000>; | 2594 | phy-handle = <&phy0>; |
2530 | phy-handle = <2452000>; | 2595 | sleep = <&pmc 00000080>; |
2596 | ranges; | ||
2597 | |||
2598 | mdio@24520 { | ||
2599 | reg = <0x24520 0x20>; | ||
2600 | compatible = "fsl,gianfar-mdio"; | ||
2601 | |||
2602 | phy0: ethernet-phy@0 { | ||
2603 | interrupts = <5 1>; | ||
2604 | reg = <0>; | ||
2605 | device_type = "ethernet-phy"; | ||
2606 | }; | ||
2607 | |||
2608 | phy1: ethernet-phy@1 { | ||
2609 | interrupts = <5 1>; | ||
2610 | reg = <1>; | ||
2611 | device_type = "ethernet-phy"; | ||
2612 | }; | ||
2613 | |||
2614 | phy3: ethernet-phy@3 { | ||
2615 | interrupts = <7 1>; | ||
2616 | reg = <3>; | ||
2617 | device_type = "ethernet-phy"; | ||
2618 | }; | ||
2619 | }; | ||
2531 | }; | 2620 | }; |
2532 | 2621 | ||
2533 | ethernet@25000 { | 2622 | ethernet@25000 { |
2534 | #address-cells = <1>; | ||
2535 | #size-cells = <0>; | ||
2536 | device_type = "network"; | 2623 | device_type = "network"; |
2537 | model = "TSEC"; | 2624 | model = "TSEC"; |
2538 | compatible = "gianfar"; | 2625 | compatible = "gianfar"; |
2539 | reg = <25000 1000>; | 2626 | reg = <0x25000 0x1000>; |
2540 | mac-address = [ 00 E0 0C 00 73 01 ]; | 2627 | local-mac-address = [ 00 E0 0C 00 73 01 ]; |
2541 | interrupts = <13 3 14 3 18 3>; | 2628 | interrupts = <13 2 14 2 18 2>; |
2542 | interrupt-parent = <40000>; | 2629 | phy-handle = <&phy1>; |
2543 | phy-handle = <2452001>; | 2630 | sleep = <&pmc 00000040>; |
2544 | }; | 2631 | }; |
2545 | 2632 | ||
2546 | ethernet@26000 { | 2633 | ethernet@26000 { |
2547 | #address-cells = <1>; | ||
2548 | #size-cells = <0>; | ||
2549 | device_type = "network"; | 2634 | device_type = "network"; |
2550 | model = "FEC"; | 2635 | model = "FEC"; |
2551 | compatible = "gianfar"; | 2636 | compatible = "gianfar"; |
2552 | reg = <26000 1000>; | 2637 | reg = <0x26000 0x1000>; |
2553 | mac-address = [ 00 E0 0C 00 73 02 ]; | 2638 | local-mac-address = [ 00 E0 0C 00 73 02 ]; |
2554 | interrupts = <19 3>; | 2639 | interrupts = <41 2>; |
2555 | interrupt-parent = <40000>; | 2640 | phy-handle = <&phy3>; |
2556 | phy-handle = <2452002>; | 2641 | sleep = <&pmc 00000020>; |
2557 | }; | 2642 | }; |
2558 | 2643 | ||
2559 | serial@4500 { | 2644 | serial@4500 { |
2560 | device_type = "serial"; | 2645 | #address-cells = <1>; |
2561 | compatible = "ns16550"; | 2646 | #size-cells = <1>; |
2562 | reg = <4500 100>; | 2647 | compatible = "fsl,mpc8540-duart", "simple-bus"; |
2563 | clock-frequency = <0>; | 2648 | sleep = <&pmc 00000002>; |
2564 | interrupts = <1a 3>; | 2649 | ranges; |
2565 | interrupt-parent = <40000>; | 2650 | |
2651 | serial@4500 { | ||
2652 | device_type = "serial"; | ||
2653 | compatible = "ns16550"; | ||
2654 | reg = <0x4500 0x100>; | ||
2655 | clock-frequency = <0>; | ||
2656 | interrupts = <42 2>; | ||
2657 | }; | ||
2658 | |||
2659 | serial@4600 { | ||
2660 | device_type = "serial"; | ||
2661 | compatible = "ns16550"; | ||
2662 | reg = <0x4600 0x100>; | ||
2663 | clock-frequency = <0>; | ||
2664 | interrupts = <42 2>; | ||
2665 | }; | ||
2566 | }; | 2666 | }; |
2567 | 2667 | ||
2568 | pic@40000 { | 2668 | pic: pic@40000 { |
2569 | linux,phandle = <40000>; | ||
2570 | interrupt-controller; | 2669 | interrupt-controller; |
2571 | #address-cells = <0>; | 2670 | #address-cells = <0>; |
2572 | reg = <40000 40000>; | 2671 | #interrupt-cells = <2>; |
2672 | reg = <0x40000 0x40000>; | ||
2573 | compatible = "chrp,open-pic"; | 2673 | compatible = "chrp,open-pic"; |
2574 | device_type = "open-pic"; | 2674 | device_type = "open-pic"; |
2575 | }; | 2675 | }; |
2576 | 2676 | ||
2577 | i2c@3000 { | 2677 | i2c@3000 { |
2578 | interrupt-parent = <40000>; | 2678 | interrupts = <43 2>; |
2579 | interrupts = <1b 3>; | 2679 | reg = <0x3000 0x100>; |
2580 | reg = <3000 18>; | ||
2581 | device_type = "i2c"; | ||
2582 | compatible = "fsl-i2c"; | 2680 | compatible = "fsl-i2c"; |
2583 | dfsrr; | 2681 | dfsrr; |
2682 | sleep = <&pmc 00000004>; | ||
2584 | }; | 2683 | }; |
2585 | 2684 | ||
2685 | pmc: power@e0070 { | ||
2686 | compatible = "fsl,mpc8540-pmc", "fsl,mpc8548-pmc"; | ||
2687 | reg = <0xe0070 0x20>; | ||
2688 | }; | ||
2586 | }; | 2689 | }; |
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt new file mode 100644 index 000000000000..1815dfede1bc --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt | |||
@@ -0,0 +1,38 @@ | |||
1 | Every GPIO controller node must have #gpio-cells property defined, | ||
2 | this information will be used to translate gpio-specifiers. | ||
3 | |||
4 | On CPM1 devices, all ports are using slightly different register layouts. | ||
5 | Ports A, C and D are 16bit ports and Ports B and E are 32bit ports. | ||
6 | |||
7 | On CPM2 devices, all ports are 32bit ports and use a common register layout. | ||
8 | |||
9 | Required properties: | ||
10 | - compatible : "fsl,cpm1-pario-bank-a", "fsl,cpm1-pario-bank-b", | ||
11 | "fsl,cpm1-pario-bank-c", "fsl,cpm1-pario-bank-d", | ||
12 | "fsl,cpm1-pario-bank-e", "fsl,cpm2-pario-bank" | ||
13 | - #gpio-cells : Should be two. The first cell is the pin number and the | ||
14 | second cell is used to specify optional paramters (currently unused). | ||
15 | - gpio-controller : Marks the port as GPIO controller. | ||
16 | |||
17 | Example of three SOC GPIO banks defined as gpio-controller nodes: | ||
18 | |||
19 | CPM1_PIO_A: gpio-controller@950 { | ||
20 | #gpio-cells = <2>; | ||
21 | compatible = "fsl,cpm1-pario-bank-a"; | ||
22 | reg = <0x950 0x10>; | ||
23 | gpio-controller; | ||
24 | }; | ||
25 | |||
26 | CPM1_PIO_B: gpio-controller@ab8 { | ||
27 | #gpio-cells = <2>; | ||
28 | compatible = "fsl,cpm1-pario-bank-b"; | ||
29 | reg = <0xab8 0x10>; | ||
30 | gpio-controller; | ||
31 | }; | ||
32 | |||
33 | CPM1_PIO_E: gpio-controller@ac8 { | ||
34 | #gpio-cells = <2>; | ||
35 | compatible = "fsl,cpm1-pario-bank-e"; | ||
36 | reg = <0xac8 0x18>; | ||
37 | gpio-controller; | ||
38 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt index c8f44d6bcbcf..9ccd5f30405b 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt | |||
@@ -1,22 +1,37 @@ | |||
1 | * USB (Universal Serial Bus Controller) | 1 | Freescale QUICC Engine USB Controller |
2 | 2 | ||
3 | Required properties: | 3 | Required properties: |
4 | - compatible : could be "qe_udc" or "fhci-hcd". | 4 | - compatible : should be "fsl,<chip>-qe-usb", "fsl,mpc8323-qe-usb". |
5 | - mode : the could be "host" or "slave". | 5 | - reg : the first two cells should contain usb registers location and |
6 | - reg : Offset and length of the register set for the device | 6 | length, the next two two cells should contain PRAM location and |
7 | - interrupts : <a b> where a is the interrupt number and b is a | 7 | length. |
8 | field that represents an encoding of the sense and level | 8 | - interrupts : should contain USB interrupt. |
9 | information for the interrupt. This should be encoded based on | 9 | - interrupt-parent : interrupt source phandle. |
10 | the information in section 2) depending on the type of interrupt | 10 | - fsl,fullspeed-clock : specifies the full speed USB clock source: |
11 | controller you have. | 11 | "none": clock source is disabled |
12 | - interrupt-parent : the phandle for the interrupt controller that | 12 | "brg1" through "brg16": clock source is BRG1-BRG16, respectively |
13 | services interrupts for this device. | 13 | "clk1" through "clk24": clock source is CLK1-CLK24, respectively |
14 | - fsl,lowspeed-clock : specifies the low speed USB clock source: | ||
15 | "none": clock source is disabled | ||
16 | "brg1" through "brg16": clock source is BRG1-BRG16, respectively | ||
17 | "clk1" through "clk24": clock source is CLK1-CLK24, respectively | ||
18 | - hub-power-budget : USB power budget for the root hub, in mA. | ||
19 | - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP, | ||
20 | USBRN, SPEED (optional), and POWER (optional). | ||
14 | 21 | ||
15 | Example(slave): | 22 | Example: |
16 | usb@6c0 { | 23 | |
17 | compatible = "qe_udc"; | 24 | usb@6c0 { |
18 | reg = <6c0 40>; | 25 | compatible = "fsl,mpc8360-qe-usb", "fsl,mpc8323-qe-usb"; |
19 | interrupts = <8b 0>; | 26 | reg = <0x6c0 0x40 0x8b00 0x100>; |
20 | interrupt-parent = <700>; | 27 | interrupts = <11>; |
21 | mode = "slave"; | 28 | interrupt-parent = <&qeic>; |
22 | }; | 29 | fsl,fullspeed-clock = "clk21"; |
30 | gpios = <&qe_pio_b 2 0 /* USBOE */ | ||
31 | &qe_pio_b 3 0 /* USBTP */ | ||
32 | &qe_pio_b 8 0 /* USBTN */ | ||
33 | &qe_pio_b 9 0 /* USBRP */ | ||
34 | &qe_pio_b 11 0 /* USBRN */ | ||
35 | &qe_pio_e 20 0 /* SPEED */ | ||
36 | &qe_pio_e 21 0 /* POWER */>; | ||
37 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt b/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt new file mode 100644 index 000000000000..0f766333b6eb --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt | |||
@@ -0,0 +1,17 @@ | |||
1 | Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU) | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx". | ||
5 | - reg : should specify I2C address (0x0a). | ||
6 | - #gpio-cells : should be 2. | ||
7 | - gpio-controller : should be present. | ||
8 | |||
9 | Example: | ||
10 | |||
11 | mcu@0a { | ||
12 | #gpio-cells = <2>; | ||
13 | compatible = "fsl,mc9s08qg8-mpc8349emitx", | ||
14 | "fsl,mcu-mpc8349emitx"; | ||
15 | reg = <0x0a>; | ||
16 | gpio-controller; | ||
17 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/pmc.txt b/Documentation/powerpc/dts-bindings/fsl/pmc.txt new file mode 100644 index 000000000000..02f6f43ee1b7 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/pmc.txt | |||
@@ -0,0 +1,63 @@ | |||
1 | * Power Management Controller | ||
2 | |||
3 | Properties: | ||
4 | - compatible: "fsl,<chip>-pmc". | ||
5 | |||
6 | "fsl,mpc8349-pmc" should be listed for any chip whose PMC is | ||
7 | compatible. "fsl,mpc8313-pmc" should also be listed for any chip | ||
8 | whose PMC is compatible, and implies deep-sleep capability. | ||
9 | |||
10 | "fsl,mpc8548-pmc" should be listed for any chip whose PMC is | ||
11 | compatible. "fsl,mpc8536-pmc" should also be listed for any chip | ||
12 | whose PMC is compatible, and implies deep-sleep capability. | ||
13 | |||
14 | "fsl,mpc8641d-pmc" should be listed for any chip whose PMC is | ||
15 | compatible; all statements below that apply to "fsl,mpc8548-pmc" also | ||
16 | apply to "fsl,mpc8641d-pmc". | ||
17 | |||
18 | Compatibility does not include bit assigments in SCCR/PMCDR/DEVDISR; these | ||
19 | bit assigments are indicated via the sleep specifier in each device's | ||
20 | sleep property. | ||
21 | |||
22 | - reg: For devices compatible with "fsl,mpc8349-pmc", the first resource | ||
23 | is the PMC block, and the second resource is the Clock Configuration | ||
24 | block. | ||
25 | |||
26 | For devices compatible with "fsl,mpc8548-pmc", the first resource | ||
27 | is a 32-byte block beginning with DEVDISR. | ||
28 | |||
29 | - interrupts: For "fsl,mpc8349-pmc"-compatible devices, the first | ||
30 | resource is the PMC block interrupt. | ||
31 | |||
32 | - fsl,mpc8313-wakeup-timer: For "fsl,mpc8313-pmc"-compatible devices, | ||
33 | this is a phandle to an "fsl,gtm" node on which timer 4 can be used as | ||
34 | a wakeup source from deep sleep. | ||
35 | |||
36 | Sleep specifiers: | ||
37 | |||
38 | fsl,mpc8349-pmc: Sleep specifiers consist of one cell. For each bit | ||
39 | that is set in the cell, the corresponding bit in SCCR will be saved | ||
40 | and cleared on suspend, and restored on resume. This sleep controller | ||
41 | supports disabling and resuming devices at any time. | ||
42 | |||
43 | fsl,mpc8536-pmc: Sleep specifiers consist of three cells, the third of | ||
44 | which will be ORed into PMCDR upon suspend, and cleared from PMCDR | ||
45 | upon resume. The first two cells are as described for fsl,mpc8578-pmc. | ||
46 | This sleep controller only supports disabling devices during system | ||
47 | sleep, or permanently. | ||
48 | |||
49 | fsl,mpc8548-pmc: Sleep specifiers consist of one or two cells, the | ||
50 | first of which will be ORed into DEVDISR (and the second into | ||
51 | DEVDISR2, if present -- this cell should be zero or absent if the | ||
52 | hardware does not have DEVDISR2) upon a request for permanent device | ||
53 | disabling. This sleep controller does not support configuring devices | ||
54 | to disable during system sleep (unless supported by another compatible | ||
55 | match), or dynamically. | ||
56 | |||
57 | Example: | ||
58 | |||
59 | power@b00 { | ||
60 | compatible = "fsl,mpc8313-pmc", "fsl,mpc8349-pmc"; | ||
61 | reg = <0xb00 0x100 0xa00 0x100>; | ||
62 | interrupts = <80 8>; | ||
63 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt b/Documentation/powerpc/dts-bindings/fsl/tsec.txt index 583ef6b56c43..cf55fa4112d2 100644 --- a/Documentation/powerpc/dts-bindings/fsl/tsec.txt +++ b/Documentation/powerpc/dts-bindings/fsl/tsec.txt | |||
@@ -24,46 +24,39 @@ Example: | |||
24 | 24 | ||
25 | * Gianfar-compatible ethernet nodes | 25 | * Gianfar-compatible ethernet nodes |
26 | 26 | ||
27 | Required properties: | 27 | Properties: |
28 | 28 | ||
29 | - device_type : Should be "network" | 29 | - device_type : Should be "network" |
30 | - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" | 30 | - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" |
31 | - compatible : Should be "gianfar" | 31 | - compatible : Should be "gianfar" |
32 | - reg : Offset and length of the register set for the device | 32 | - reg : Offset and length of the register set for the device |
33 | - mac-address : List of bytes representing the ethernet address of | 33 | - local-mac-address : List of bytes representing the ethernet address of |
34 | this controller | 34 | this controller |
35 | - interrupts : <a b> where a is the interrupt number and b is a | 35 | - interrupts : For FEC devices, the first interrupt is the device's |
36 | field that represents an encoding of the sense and level | 36 | interrupt. For TSEC and eTSEC devices, the first interrupt is |
37 | information for the interrupt. This should be encoded based on | 37 | transmit, the second is receive, and the third is error. |
38 | the information in section 2) depending on the type of interrupt | ||
39 | controller you have. | ||
40 | - interrupt-parent : the phandle for the interrupt controller that | ||
41 | services interrupts for this device. | ||
42 | - phy-handle : The phandle for the PHY connected to this ethernet | 38 | - phy-handle : The phandle for the PHY connected to this ethernet |
43 | controller. | 39 | controller. |
44 | - fixed-link : <a b c d e> where a is emulated phy id - choose any, | 40 | - fixed-link : <a b c d e> where a is emulated phy id - choose any, |
45 | but unique to the all specified fixed-links, b is duplex - 0 half, | 41 | but unique to the all specified fixed-links, b is duplex - 0 half, |
46 | 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no | 42 | 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no |
47 | pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. | 43 | pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. |
48 | |||
49 | Recommended properties: | ||
50 | |||
51 | - phy-connection-type : a string naming the controller/PHY interface type, | 44 | - phy-connection-type : a string naming the controller/PHY interface type, |
52 | i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", | 45 | i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", |
53 | "tbi", or "rtbi". This property is only really needed if the connection | 46 | "tbi", or "rtbi". This property is only really needed if the connection |
54 | is of type "rgmii-id", as all other connection types are detected by | 47 | is of type "rgmii-id", as all other connection types are detected by |
55 | hardware. | 48 | hardware. |
56 | 49 | - fsl,magic-packet : If present, indicates that the hardware supports | |
50 | waking up via magic packet. | ||
57 | 51 | ||
58 | Example: | 52 | Example: |
59 | ethernet@24000 { | 53 | ethernet@24000 { |
60 | #size-cells = <0>; | ||
61 | device_type = "network"; | 54 | device_type = "network"; |
62 | model = "TSEC"; | 55 | model = "TSEC"; |
63 | compatible = "gianfar"; | 56 | compatible = "gianfar"; |
64 | reg = <24000 1000>; | 57 | reg = <0x24000 0x1000>; |
65 | mac-address = [ 00 E0 0C 00 73 00 ]; | 58 | local-mac-address = [ 00 E0 0C 00 73 00 ]; |
66 | interrupts = <d 3 e 3 12 3>; | 59 | interrupts = <29 2 30 2 34 2>; |
67 | interrupt-parent = <40000>; | 60 | interrupt-parent = <&mpic>; |
68 | phy-handle = <2452000> | 61 | phy-handle = <&phy0> |
69 | }; | 62 | }; |
diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt new file mode 100644 index 000000000000..84a04d5eb8e6 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt | |||
@@ -0,0 +1,28 @@ | |||
1 | Freescale Localbus UPM programmed to work with NAND flash | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : "fsl,upm-nand". | ||
5 | - reg : should specify localbus chip select and size used for the chip. | ||
6 | - fsl,upm-addr-offset : UPM pattern offset for the address latch. | ||
7 | - fsl,upm-cmd-offset : UPM pattern offset for the command latch. | ||
8 | - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin. | ||
9 | |||
10 | Example: | ||
11 | |||
12 | upm@1,0 { | ||
13 | compatible = "fsl,upm-nand"; | ||
14 | reg = <1 0 1>; | ||
15 | fsl,upm-addr-offset = <16>; | ||
16 | fsl,upm-cmd-offset = <8>; | ||
17 | gpios = <&qe_pio_e 18 0>; | ||
18 | |||
19 | flash { | ||
20 | #address-cells = <1>; | ||
21 | #size-cells = <1>; | ||
22 | compatible = "..."; | ||
23 | |||
24 | partition@0 { | ||
25 | ... | ||
26 | }; | ||
27 | }; | ||
28 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/powerpc/dts-bindings/gpio/led.txt new file mode 100644 index 000000000000..ff51f4c0fa9d --- /dev/null +++ b/Documentation/powerpc/dts-bindings/gpio/led.txt | |||
@@ -0,0 +1,15 @@ | |||
1 | LED connected to GPIO | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : should be "gpio-led". | ||
5 | - label : (optional) the label for this LED. If omitted, the label is | ||
6 | taken from the node name (excluding the unit address). | ||
7 | - gpios : should specify LED GPIO. | ||
8 | |||
9 | Example: | ||
10 | |||
11 | led@0 { | ||
12 | compatible = "gpio-led"; | ||
13 | label = "hdd"; | ||
14 | gpios = <&mcu_pio 0 1>; | ||
15 | }; | ||
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index a83ff23cd68c..0843ed0163a5 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt | |||
@@ -1,89 +1,528 @@ | |||
1 | rfkill - RF switch subsystem support | 1 | rfkill - RF switch subsystem support |
2 | ==================================== | 2 | ==================================== |
3 | 3 | ||
4 | 1 Implementation details | 4 | 1 Introduction |
5 | 2 Driver support | 5 | 2 Implementation details |
6 | 3 Userspace support | 6 | 3 Kernel driver guidelines |
7 | 3.1 wireless device drivers | ||
8 | 3.2 platform/switch drivers | ||
9 | 3.3 input device drivers | ||
10 | 4 Kernel API | ||
11 | 5 Userspace support | ||
7 | 12 | ||
8 | =============================================================================== | ||
9 | 1: Implementation details | ||
10 | 13 | ||
11 | The rfkill switch subsystem offers support for keys often found on laptops | 14 | 1. Introduction: |
12 | to enable wireless devices like WiFi and Bluetooth. | 15 | |
16 | The rfkill switch subsystem exists to add a generic interface to circuitry that | ||
17 | can enable or disable the signal output of a wireless *transmitter* of any | ||
18 | type. By far, the most common use is to disable radio-frequency transmitters. | ||
13 | 19 | ||
14 | This is done by providing the user 3 possibilities: | 20 | Note that disabling the signal output means that the the transmitter is to be |
15 | 1 - The rfkill system handles all events; userspace is not aware of events. | 21 | made to not emit any energy when "blocked". rfkill is not about blocking data |
16 | 2 - The rfkill system handles all events; userspace is informed about the events. | 22 | transmissions, it is about blocking energy emission. |
17 | 3 - The rfkill system does not handle events; userspace handles all events. | ||
18 | 23 | ||
19 | The buttons to enable and disable the wireless radios are important in | 24 | The rfkill subsystem offers support for keys and switches often found on |
25 | laptops to enable wireless devices like WiFi and Bluetooth, so that these keys | ||
26 | and switches actually perform an action in all wireless devices of a given type | ||
27 | attached to the system. | ||
28 | |||
29 | The buttons to enable and disable the wireless transmitters are important in | ||
20 | situations where the user is for example using his laptop on a location where | 30 | situations where the user is for example using his laptop on a location where |
21 | wireless radios _must_ be disabled (e.g. airplanes). | 31 | radio-frequency transmitters _must_ be disabled (e.g. airplanes). |
22 | Because of this requirement, userspace support for the keys should not be | 32 | |
23 | made mandatory. Because userspace might want to perform some additional smarter | 33 | Because of this requirement, userspace support for the keys should not be made |
24 | tasks when the key is pressed, rfkill still provides userspace the possibility | 34 | mandatory. Because userspace might want to perform some additional smarter |
25 | to take over the task to handle the key events. | 35 | tasks when the key is pressed, rfkill provides userspace the possibility to |
36 | take over the task to handle the key events. | ||
37 | |||
38 | =============================================================================== | ||
39 | 2: Implementation details | ||
40 | |||
41 | The rfkill subsystem is composed of various components: the rfkill class, the | ||
42 | rfkill-input module (an input layer handler), and some specific input layer | ||
43 | events. | ||
44 | |||
45 | The rfkill class provides kernel drivers with an interface that allows them to | ||
46 | know when they should enable or disable a wireless network device transmitter. | ||
47 | This is enabled by the CONFIG_RFKILL Kconfig option. | ||
48 | |||
49 | The rfkill class support makes sure userspace will be notified of all state | ||
50 | changes on rfkill devices through uevents. It provides a notification chain | ||
51 | for interested parties in the kernel to also get notified of rfkill state | ||
52 | changes in other drivers. It creates several sysfs entries which can be used | ||
53 | by userspace. See section "Userspace support". | ||
54 | |||
55 | The rfkill-input module provides the kernel with the ability to implement a | ||
56 | basic response when the user presses a key or button (or toggles a switch) | ||
57 | related to rfkill functionality. It is an in-kernel implementation of default | ||
58 | policy of reacting to rfkill-related input events and neither mandatory nor | ||
59 | required for wireless drivers to operate. It is enabled by the | ||
60 | CONFIG_RFKILL_INPUT Kconfig option. | ||
61 | |||
62 | rfkill-input is a rfkill-related events input layer handler. This handler will | ||
63 | listen to all rfkill key events and will change the rfkill state of the | ||
64 | wireless devices accordingly. With this option enabled userspace could either | ||
65 | do nothing or simply perform monitoring tasks. | ||
66 | |||
67 | The rfkill-input module also provides EPO (emergency power-off) functionality | ||
68 | for all wireless transmitters. This function cannot be overridden, and it is | ||
69 | always active. rfkill EPO is related to *_RFKILL_ALL input layer events. | ||
70 | |||
71 | |||
72 | Important terms for the rfkill subsystem: | ||
73 | |||
74 | In order to avoid confusion, we avoid the term "switch" in rfkill when it is | ||
75 | referring to an electronic control circuit that enables or disables a | ||
76 | transmitter. We reserve it for the physical device a human manipulates | ||
77 | (which is an input device, by the way): | ||
78 | |||
79 | rfkill switch: | ||
80 | |||
81 | A physical device a human manipulates. Its state can be perceived by | ||
82 | the kernel either directly (through a GPIO pin, ACPI GPE) or by its | ||
83 | effect on a rfkill line of a wireless device. | ||
84 | |||
85 | rfkill controller: | ||
86 | |||
87 | A hardware circuit that controls the state of a rfkill line, which a | ||
88 | kernel driver can interact with *to modify* that state (i.e. it has | ||
89 | either write-only or read/write access). | ||
90 | |||
91 | rfkill line: | ||
92 | |||
93 | An input channel (hardware or software) of a wireless device, which | ||
94 | causes a wireless transmitter to stop emitting energy (BLOCK) when it | ||
95 | is active. Point of view is extremely important here: rfkill lines are | ||
96 | always seen from the PoV of a wireless device (and its driver). | ||
97 | |||
98 | soft rfkill line/software rfkill line: | ||
99 | |||
100 | A rfkill line the wireless device driver can directly change the state | ||
101 | of. Related to rfkill_state RFKILL_STATE_SOFT_BLOCKED. | ||
102 | |||
103 | hard rfkill line/hardware rfkill line: | ||
104 | |||
105 | A rfkill line that works fully in hardware or firmware, and that cannot | ||
106 | be overridden by the kernel driver. The hardware device or the | ||
107 | firmware just exports its status to the driver, but it is read-only. | ||
108 | Related to rfkill_state RFKILL_STATE_HARD_BLOCKED. | ||
109 | |||
110 | The enum rfkill_state describes the rfkill state of a transmitter: | ||
111 | |||
112 | When a rfkill line or rfkill controller is in the RFKILL_STATE_UNBLOCKED state, | ||
113 | the wireless transmitter (radio TX circuit for example) is *enabled*. When the | ||
114 | it is in the RFKILL_STATE_SOFT_BLOCKED or RFKILL_STATE_HARD_BLOCKED, the | ||
115 | wireless transmitter is to be *blocked* from operating. | ||
116 | |||
117 | RFKILL_STATE_SOFT_BLOCKED indicates that a call to toggle_radio() can change | ||
118 | that state. RFKILL_STATE_HARD_BLOCKED indicates that a call to toggle_radio() | ||
119 | will not be able to change the state and will return with a suitable error if | ||
120 | attempts are made to set the state to RFKILL_STATE_UNBLOCKED. | ||
121 | |||
122 | RFKILL_STATE_HARD_BLOCKED is used by drivers to signal that the device is | ||
123 | locked in the BLOCKED state by a hardwire rfkill line (typically an input pin | ||
124 | that, when active, forces the transmitter to be disabled) which the driver | ||
125 | CANNOT override. | ||
126 | |||
127 | Full rfkill functionality requires two different subsystems to cooperate: the | ||
128 | input layer and the rfkill class. The input layer issues *commands* to the | ||
129 | entire system requesting that devices registered to the rfkill class change | ||
130 | state. The way this interaction happens is not complex, but it is not obvious | ||
131 | either: | ||
132 | |||
133 | Kernel Input layer: | ||
134 | |||
135 | * Generates KEY_WWAN, KEY_WLAN, KEY_BLUETOOTH, SW_RFKILL_ALL, and | ||
136 | other such events when the user presses certain keys, buttons, or | ||
137 | toggles certain physical switches. | ||
138 | |||
139 | THE INPUT LAYER IS NEVER USED TO PROPAGATE STATUS, NOTIFICATIONS OR THE | ||
140 | KIND OF STUFF AN ON-SCREEN-DISPLAY APPLICATION WOULD REPORT. It is | ||
141 | used to issue *commands* for the system to change behaviour, and these | ||
142 | commands may or may not be carried out by some kernel driver or | ||
143 | userspace application. It follows that doing user feedback based only | ||
144 | on input events is broken, as there is no guarantee that an input event | ||
145 | will be acted upon. | ||
146 | |||
147 | Most wireless communication device drivers implementing rfkill | ||
148 | functionality MUST NOT generate these events, and have no reason to | ||
149 | register themselves with the input layer. Doing otherwise is a common | ||
150 | misconception. There is an API to propagate rfkill status change | ||
151 | information, and it is NOT the input layer. | ||
152 | |||
153 | rfkill class: | ||
154 | |||
155 | * Calls a hook in a driver to effectively change the wireless | ||
156 | transmitter state; | ||
157 | * Keeps track of the wireless transmitter state (with help from | ||
158 | the driver); | ||
159 | * Generates userspace notifications (uevents) and a call to a | ||
160 | notification chain (kernel) when there is a wireless transmitter | ||
161 | state change; | ||
162 | * Connects a wireless communications driver with the common rfkill | ||
163 | control system, which, for example, allows actions such as | ||
164 | "switch all bluetooth devices offline" to be carried out by | ||
165 | userspace or by rfkill-input. | ||
166 | |||
167 | THE RFKILL CLASS NEVER ISSUES INPUT EVENTS. THE RFKILL CLASS DOES | ||
168 | NOT LISTEN TO INPUT EVENTS. NO DRIVER USING THE RFKILL CLASS SHALL | ||
169 | EVER LISTEN TO, OR ACT ON RFKILL INPUT EVENTS. Doing otherwise is | ||
170 | a layering violation. | ||
171 | |||
172 | Most wireless data communication drivers in the kernel have just to | ||
173 | implement the rfkill class API to work properly. Interfacing to the | ||
174 | input layer is not often required (and is very often a *bug*) on | ||
175 | wireless drivers. | ||
176 | |||
177 | Platform drivers often have to attach to the input layer to *issue* | ||
178 | (but never to listen to) rfkill events for rfkill switches, and also to | ||
179 | the rfkill class to export a control interface for the platform rfkill | ||
180 | controllers to the rfkill subsystem. This does NOT mean the rfkill | ||
181 | switch is attached to a rfkill class (doing so is almost always wrong). | ||
182 | It just means the same kernel module is the driver for different | ||
183 | devices (rfkill switches and rfkill controllers). | ||
184 | |||
185 | |||
186 | Userspace input handlers (uevents) or kernel input handlers (rfkill-input): | ||
187 | |||
188 | * Implements the policy of what should happen when one of the input | ||
189 | layer events related to rfkill operation is received. | ||
190 | * Uses the sysfs interface (userspace) or private rfkill API calls | ||
191 | to tell the devices registered with the rfkill class to change | ||
192 | their state (i.e. translates the input layer event into real | ||
193 | action). | ||
194 | * rfkill-input implements EPO by handling EV_SW SW_RFKILL_ALL 0 | ||
195 | (power off all transmitters) in a special way: it ignores any | ||
196 | overrides and local state cache and forces all transmitters to the | ||
197 | RFKILL_STATE_SOFT_BLOCKED state (including those which are already | ||
198 | supposed to be BLOCKED). Note that the opposite event (power on all | ||
199 | transmitters) is handled normally. | ||
200 | |||
201 | Userspace uevent handler or kernel platform-specific drivers hooked to the | ||
202 | rfkill notifier chain: | ||
203 | |||
204 | * Taps into the rfkill notifier chain or to KOBJ_CHANGE uevents, | ||
205 | in order to know when a device that is registered with the rfkill | ||
206 | class changes state; | ||
207 | * Issues feedback notifications to the user; | ||
208 | * In the rare platforms where this is required, synthesizes an input | ||
209 | event to command all *OTHER* rfkill devices to also change their | ||
210 | statues when a specific rfkill device changes state. | ||
211 | |||
212 | |||
213 | =============================================================================== | ||
214 | 3: Kernel driver guidelines | ||
215 | |||
216 | Remember: point-of-view is everything for a driver that connects to the rfkill | ||
217 | subsystem. All the details below must be measured/perceived from the point of | ||
218 | view of the specific driver being modified. | ||
219 | |||
220 | The first thing one needs to know is whether his driver should be talking to | ||
221 | the rfkill class or to the input layer. In rare cases (platform drivers), it | ||
222 | could happen that you need to do both, as platform drivers often handle a | ||
223 | variety of devices in the same driver. | ||
224 | |||
225 | Do not mistake input devices for rfkill controllers. The only type of "rfkill | ||
226 | switch" device that is to be registered with the rfkill class are those | ||
227 | directly controlling the circuits that cause a wireless transmitter to stop | ||
228 | working (or the software equivalent of them), i.e. what we call a rfkill | ||
229 | controller. Every other kind of "rfkill switch" is just an input device and | ||
230 | MUST NOT be registered with the rfkill class. | ||
231 | |||
232 | A driver should register a device with the rfkill class when ALL of the | ||
233 | following conditions are met (they define a rfkill controller): | ||
234 | |||
235 | 1. The device is/controls a data communications wireless transmitter; | ||
236 | |||
237 | 2. The kernel can interact with the hardware/firmware to CHANGE the wireless | ||
238 | transmitter state (block/unblock TX operation); | ||
239 | |||
240 | 3. The transmitter can be made to not emit any energy when "blocked": | ||
241 | rfkill is not about blocking data transmissions, it is about blocking | ||
242 | energy emission; | ||
243 | |||
244 | A driver should register a device with the input subsystem to issue | ||
245 | rfkill-related events (KEY_WLAN, KEY_BLUETOOTH, KEY_WWAN, KEY_WIMAX, | ||
246 | SW_RFKILL_ALL, etc) when ALL of the folowing conditions are met: | ||
247 | |||
248 | 1. It is directly related to some physical device the user interacts with, to | ||
249 | command the O.S./firmware/hardware to enable/disable a data communications | ||
250 | wireless transmitter. | ||
251 | |||
252 | Examples of the physical device are: buttons, keys and switches the user | ||
253 | will press/touch/slide/switch to enable or disable the wireless | ||
254 | communication device. | ||
255 | |||
256 | 2. It is NOT slaved to another device, i.e. there is no other device that | ||
257 | issues rfkill-related input events in preference to this one. | ||
26 | 258 | ||
27 | The system inside the kernel has been split into 2 separate sections: | 259 | Please refer to the corner cases and examples section for more details. |
28 | 1 - RFKILL | ||
29 | 2 - RFKILL_INPUT | ||
30 | 260 | ||
31 | The first option enables rfkill support and will make sure userspace will | 261 | When in doubt, do not issue input events. For drivers that should generate |
32 | be notified of any events through the input device. It also creates several | 262 | input events in some platforms, but not in others (e.g. b43), the best solution |
33 | sysfs entries which can be used by userspace. See section "Userspace support". | 263 | is to NEVER generate input events in the first place. That work should be |
264 | deferred to a platform-specific kernel module (which will know when to generate | ||
265 | events through the rfkill notifier chain) or to userspace. This avoids the | ||
266 | usual maintenance problems with DMI whitelisting. | ||
34 | 267 | ||
35 | The second option provides an rfkill input handler. This handler will | ||
36 | listen to all rfkill key events and will toggle the radio accordingly. | ||
37 | With this option enabled userspace could either do nothing or simply | ||
38 | perform monitoring tasks. | ||
39 | 268 | ||
269 | Corner cases and examples: | ||
40 | ==================================== | 270 | ==================================== |
41 | 2: Driver support | ||
42 | 271 | ||
43 | To build a driver with rfkill subsystem support, the driver should | 272 | 1. If the device is an input device that, because of hardware or firmware, |
44 | depend on the Kconfig symbol RFKILL; it should _not_ depend on | 273 | causes wireless transmitters to be blocked regardless of the kernel's will, it |
45 | RKFILL_INPUT. | 274 | is still just an input device, and NOT to be registered with the rfkill class. |
46 | 275 | ||
47 | Unless key events trigger an interrupt to which the driver listens, polling | 276 | 2. If the wireless transmitter switch control is read-only, it is an input |
48 | will be required to determine the key state changes. For this the input | 277 | device and not to be registered with the rfkill class (and maybe not to be made |
49 | layer providers the input-polldev handler. | 278 | an input layer event source either, see below). |
50 | 279 | ||
51 | A driver should implement a few steps to correctly make use of the | 280 | 3. If there is some other device driver *closer* to the actual hardware the |
52 | rfkill subsystem. First for non-polling drivers: | 281 | user interacted with (the button/switch/key) to issue an input event, THAT is |
282 | the device driver that should be issuing input events. | ||
53 | 283 | ||
54 | - rfkill_allocate() | 284 | E.g: |
55 | - input_allocate_device() | 285 | [RFKILL slider switch] -- [GPIO hardware] -- [WLAN card rf-kill input] |
56 | - rfkill_register() | 286 | (platform driver) (wireless card driver) |
57 | - input_register_device() | 287 | |
288 | The user is closer to the RFKILL slide switch plaform driver, so the driver | ||
289 | which must issue input events is the platform driver looking at the GPIO | ||
290 | hardware, and NEVER the wireless card driver (which is just a slave). It is | ||
291 | very likely that there are other leaves than just the WLAN card rf-kill input | ||
292 | (e.g. a bluetooth card, etc)... | ||
293 | |||
294 | On the other hand, some embedded devices do this: | ||
295 | |||
296 | [RFKILL slider switch] -- [WLAN card rf-kill input] | ||
297 | (wireless card driver) | ||
298 | |||
299 | In this situation, the wireless card driver *could* register itself as an input | ||
300 | device and issue rf-kill related input events... but in order to AVOID the need | ||
301 | for DMI whitelisting, the wireless card driver does NOT do it. Userspace (HAL) | ||
302 | or a platform driver (that exists only on these embedded devices) will do the | ||
303 | dirty job of issuing the input events. | ||
304 | |||
305 | |||
306 | COMMON MISTAKES in kernel drivers, related to rfkill: | ||
307 | ==================================== | ||
308 | |||
309 | 1. NEVER confuse input device keys and buttons with input device switches. | ||
310 | |||
311 | 1a. Switches are always set or reset. They report the current state | ||
312 | (on position or off position). | ||
313 | |||
314 | 1b. Keys and buttons are either in the pressed or not-pressed state, and | ||
315 | that's it. A "button" that latches down when you press it, and | ||
316 | unlatches when you press it again is in fact a switch as far as input | ||
317 | devices go. | ||
318 | |||
319 | Add the SW_* events you need for switches, do NOT try to emulate a button using | ||
320 | KEY_* events just because there is no such SW_* event yet. Do NOT try to use, | ||
321 | for example, KEY_BLUETOOTH when you should be using SW_BLUETOOTH instead. | ||
322 | |||
323 | 2. Input device switches (sources of EV_SW events) DO store their current state | ||
324 | (so you *must* initialize it by issuing a gratuitous input layer event on | ||
325 | driver start-up and also when resuming from sleep), and that state CAN be | ||
326 | queried from userspace through IOCTLs. There is no sysfs interface for this, | ||
327 | but that doesn't mean you should break things trying to hook it to the rfkill | ||
328 | class to get a sysfs interface :-) | ||
329 | |||
330 | 3. Do not issue *_RFKILL_ALL events by default, unless you are sure it is the | ||
331 | correct event for your switch/button. These events are emergency power-off | ||
332 | events when they are trying to turn the transmitters off. An example of an | ||
333 | input device which SHOULD generate *_RFKILL_ALL events is the wireless-kill | ||
334 | switch in a laptop which is NOT a hotkey, but a real switch that kills radios | ||
335 | in hardware, even if the O.S. has gone to lunch. An example of an input device | ||
336 | which SHOULD NOT generate *_RFKILL_ALL events by default, is any sort of hot | ||
337 | key that does nothing by itself, as well as any hot key that is type-specific | ||
338 | (e.g. the one for WLAN). | ||
339 | |||
340 | |||
341 | 3.1 Guidelines for wireless device drivers | ||
342 | ------------------------------------------ | ||
343 | |||
344 | 1. Each independent transmitter in a wireless device (usually there is only one | ||
345 | transmitter per device) should have a SINGLE rfkill class attached to it. | ||
346 | |||
347 | 2. If the device does not have any sort of hardware assistance to allow the | ||
348 | driver to rfkill the device, the driver should emulate it by taking all actions | ||
349 | required to silence the transmitter. | ||
350 | |||
351 | 3. If it is impossible to silence the transmitter (i.e. it still emits energy, | ||
352 | even if it is just in brief pulses, when there is no data to transmit and there | ||
353 | is no hardware support to turn it off) do NOT lie to the users. Do not attach | ||
354 | it to a rfkill class. The rfkill subsystem does not deal with data | ||
355 | transmission, it deals with energy emission. If the transmitter is emitting | ||
356 | energy, it is not blocked in rfkill terms. | ||
357 | |||
358 | 4. It doesn't matter if the device has multiple rfkill input lines affecting | ||
359 | the same transmitter, their combined state is to be exported as a single state | ||
360 | per transmitter (see rule 1). | ||
361 | |||
362 | This rule exists because users of the rfkill subsystem expect to get (and set, | ||
363 | when possible) the overall transmitter rfkill state, not of a particular rfkill | ||
364 | line. | ||
365 | |||
366 | Example of a WLAN wireless driver connected to the rfkill subsystem: | ||
367 | -------------------------------------------------------------------- | ||
368 | |||
369 | A certain WLAN card has one input pin that causes it to block the transmitter | ||
370 | and makes the status of that input pin available (only for reading!) to the | ||
371 | kernel driver. This is a hard rfkill input line (it cannot be overridden by | ||
372 | the kernel driver). | ||
373 | |||
374 | The card also has one PCI register that, if manipulated by the driver, causes | ||
375 | it to block the transmitter. This is a soft rfkill input line. | ||
376 | |||
377 | It has also a thermal protection circuitry that shuts down its transmitter if | ||
378 | the card overheats, and makes the status of that protection available (only for | ||
379 | reading!) to the kernel driver. This is also a hard rfkill input line. | ||
380 | |||
381 | If either one of these rfkill lines are active, the transmitter is blocked by | ||
382 | the hardware and forced offline. | ||
383 | |||
384 | The driver should allocate and attach to its struct device *ONE* instance of | ||
385 | the rfkill class (there is only one transmitter). | ||
386 | |||
387 | It can implement the get_state() hook, and return RFKILL_STATE_HARD_BLOCKED if | ||
388 | either one of its two hard rfkill input lines are active. If the two hard | ||
389 | rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft | ||
390 | rfkill input line is active. Only if none of the rfkill input lines are | ||
391 | active, will it return RFKILL_STATE_UNBLOCKED. | ||
58 | 392 | ||
59 | For polling drivers: | 393 | If it doesn't implement the get_state() hook, it must make sure that its calls |
394 | to rfkill_force_state() are enough to keep the status always up-to-date, and it | ||
395 | must do a rfkill_force_state() on resume from sleep. | ||
60 | 396 | ||
397 | Every time the driver gets a notification from the card that one of its rfkill | ||
398 | lines changed state (polling might be needed on badly designed cards that don't | ||
399 | generate interrupts for such events), it recomputes the rfkill state as per | ||
400 | above, and calls rfkill_force_state() to update it. | ||
401 | |||
402 | The driver should implement the toggle_radio() hook, that: | ||
403 | |||
404 | 1. Returns an error if one of the hardware rfkill lines are active, and the | ||
405 | caller asked for RFKILL_STATE_UNBLOCKED. | ||
406 | |||
407 | 2. Activates the soft rfkill line if the caller asked for state | ||
408 | RFKILL_STATE_SOFT_BLOCKED. It should do this even if one of the hard rfkill | ||
409 | lines are active, effectively double-blocking the transmitter. | ||
410 | |||
411 | 3. Deactivates the soft rfkill line if none of the hardware rfkill lines are | ||
412 | active and the caller asked for RFKILL_STATE_UNBLOCKED. | ||
413 | |||
414 | =============================================================================== | ||
415 | 4: Kernel API | ||
416 | |||
417 | To build a driver with rfkill subsystem support, the driver should depend on | ||
418 | (or select) the Kconfig symbol RFKILL; it should _not_ depend on RKFILL_INPUT. | ||
419 | |||
420 | The hardware the driver talks to may be write-only (where the current state | ||
421 | of the hardware is unknown), or read-write (where the hardware can be queried | ||
422 | about its current state). | ||
423 | |||
424 | The rfkill class will call the get_state hook of a device every time it needs | ||
425 | to know the *real* current state of the hardware. This can happen often. | ||
426 | |||
427 | Some hardware provides events when its status changes. In these cases, it is | ||
428 | best for the driver to not provide a get_state hook, and instead register the | ||
429 | rfkill class *already* with the correct status, and keep it updated using | ||
430 | rfkill_force_state() when it gets an event from the hardware. | ||
431 | |||
432 | There is no provision for a statically-allocated rfkill struct. You must | ||
433 | use rfkill_allocate() to allocate one. | ||
434 | |||
435 | You should: | ||
61 | - rfkill_allocate() | 436 | - rfkill_allocate() |
62 | - input_allocate_polled_device() | 437 | - modify rfkill fields (flags, name) |
438 | - modify state to the current hardware state (THIS IS THE ONLY TIME | ||
439 | YOU CAN ACCESS state DIRECTLY) | ||
63 | - rfkill_register() | 440 | - rfkill_register() |
64 | - input_register_polled_device() | ||
65 | 441 | ||
66 | When a key event has been detected, the correct event should be | 442 | The only way to set a device to the RFKILL_STATE_HARD_BLOCKED state is through |
67 | sent over the input device which has been registered by the driver. | 443 | a suitable return of get_state() or through rfkill_force_state(). |
68 | 444 | ||
69 | ==================================== | 445 | When a device is in the RFKILL_STATE_HARD_BLOCKED state, the only way to switch |
70 | 3: Userspace support | 446 | it to a different state is through a suitable return of get_state() or through |
447 | rfkill_force_state(). | ||
448 | |||
449 | If toggle_radio() is called to set a device to state RFKILL_STATE_SOFT_BLOCKED | ||
450 | when that device is already at the RFKILL_STATE_HARD_BLOCKED state, it should | ||
451 | not return an error. Instead, it should try to double-block the transmitter, | ||
452 | so that its state will change from RFKILL_STATE_HARD_BLOCKED to | ||
453 | RFKILL_STATE_SOFT_BLOCKED should the hardware blocking cease. | ||
71 | 454 | ||
72 | For each key an input device will be created which will send out the correct | 455 | Please refer to the source for more documentation. |
73 | key event when the rfkill key has been pressed. | 456 | |
457 | =============================================================================== | ||
458 | 5: Userspace support | ||
459 | |||
460 | rfkill devices issue uevents (with an action of "change"), with the following | ||
461 | environment variables set: | ||
462 | |||
463 | RFKILL_NAME | ||
464 | RFKILL_STATE | ||
465 | RFKILL_TYPE | ||
466 | |||
467 | The ABI for these variables is defined by the sysfs attributes. It is best | ||
468 | to take a quick look at the source to make sure of the possible values. | ||
469 | |||
470 | It is expected that HAL will trap those, and bridge them to DBUS, etc. These | ||
471 | events CAN and SHOULD be used to give feedback to the user about the rfkill | ||
472 | status of the system. | ||
473 | |||
474 | Input devices may issue events that are related to rfkill. These are the | ||
475 | various KEY_* events and SW_* events supported by rfkill-input.c. | ||
476 | |||
477 | ******IMPORTANT****** | ||
478 | When rfkill-input is ACTIVE, userspace is NOT TO CHANGE THE STATE OF AN RFKILL | ||
479 | SWITCH IN RESPONSE TO AN INPUT EVENT also handled by rfkill-input, unless it | ||
480 | has set to true the user_claim attribute for that particular switch. This rule | ||
481 | is *absolute*; do NOT violate it. | ||
482 | ******IMPORTANT****** | ||
483 | |||
484 | Userspace must not assume it is the only source of control for rfkill switches. | ||
485 | Their state CAN and WILL change due to firmware actions, direct user actions, | ||
486 | and the rfkill-input EPO override for *_RFKILL_ALL. | ||
487 | |||
488 | When rfkill-input is not active, userspace must initiate a rfkill status | ||
489 | change by writing to the "state" attribute in order for anything to happen. | ||
490 | |||
491 | Take particular care to implement EV_SW SW_RFKILL_ALL properly. When that | ||
492 | switch is set to OFF, *every* rfkill device *MUST* be immediately put into the | ||
493 | RFKILL_STATE_SOFT_BLOCKED state, no questions asked. | ||
74 | 494 | ||
75 | The following sysfs entries will be created: | 495 | The following sysfs entries will be created: |
76 | 496 | ||
77 | name: Name assigned by driver to this key (interface or driver name). | 497 | name: Name assigned by driver to this key (interface or driver name). |
78 | type: Name of the key type ("wlan", "bluetooth", etc). | 498 | type: Name of the key type ("wlan", "bluetooth", etc). |
79 | state: Current state of the key. 1: On, 0: Off. | 499 | state: Current state of the transmitter |
500 | 0: RFKILL_STATE_SOFT_BLOCKED | ||
501 | transmitter is forced off, but one can override it | ||
502 | by a write to the state attribute; | ||
503 | 1: RFKILL_STATE_UNBLOCKED | ||
504 | transmiter is NOT forced off, and may operate if | ||
505 | all other conditions for such operation are met | ||
506 | (such as interface is up and configured, etc); | ||
507 | 2: RFKILL_STATE_HARD_BLOCKED | ||
508 | transmitter is forced off by something outside of | ||
509 | the driver's control. One cannot set a device to | ||
510 | this state through writes to the state attribute; | ||
80 | claim: 1: Userspace handles events, 0: Kernel handles events | 511 | claim: 1: Userspace handles events, 0: Kernel handles events |
81 | 512 | ||
82 | Both the "state" and "claim" entries are also writable. For the "state" entry | 513 | Both the "state" and "claim" entries are also writable. For the "state" entry |
83 | this means that when 1 or 0 is written all radios, not yet in the requested | 514 | this means that when 1 or 0 is written, the device rfkill state (if not yet in |
84 | state, will be will be toggled accordingly. | 515 | the requested state), will be will be toggled accordingly. |
516 | |||
85 | For the "claim" entry writing 1 to it means that the kernel no longer handles | 517 | For the "claim" entry writing 1 to it means that the kernel no longer handles |
86 | key events even though RFKILL_INPUT input was enabled. When "claim" has been | 518 | key events even though RFKILL_INPUT input was enabled. When "claim" has been |
87 | set to 0, userspace should make sure that it listens for the input events or | 519 | set to 0, userspace should make sure that it listens for the input events or |
88 | check the sysfs "state" entry regularly to correctly perform the required | 520 | check the sysfs "state" entry regularly to correctly perform the required tasks |
89 | tasks when the rkfill key is pressed. | 521 | when the rkfill key is pressed. |
522 | |||
523 | A note about input devices and EV_SW events: | ||
524 | |||
525 | In order to know the current state of an input device switch (like | ||
526 | SW_RFKILL_ALL), you will need to use an IOCTL. That information is not | ||
527 | available through sysfs in a generic way at this time, and it is not available | ||
528 | through the rfkill class AT ALL. | ||
diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 88ad615dd338..77ba0afbe4db 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver | |||
@@ -186,6 +186,17 @@ hardware. | |||
186 | Locking: port_sem taken. | 186 | Locking: port_sem taken. |
187 | Interrupts: caller dependent. | 187 | Interrupts: caller dependent. |
188 | 188 | ||
189 | flush_buffer(port) | ||
190 | Flush any write buffers, reset any DMA state and stop any | ||
191 | ongoing DMA transfers. | ||
192 | |||
193 | This will be called whenever the port->info->xmit circular | ||
194 | buffer is cleared. | ||
195 | |||
196 | Locking: port->lock taken. | ||
197 | Interrupts: locally disabled. | ||
198 | This call must not sleep | ||
199 | |||
189 | set_termios(port,termios,oldtermios) | 200 | set_termios(port,termios,oldtermios) |
190 | Change the port parameters, including word length, parity, stop | 201 | Change the port parameters, including word length, parity, stop |
191 | bits. Update read_status_mask and ignore_status_mask to indicate | 202 | bits. Update read_status_mask and ignore_status_mask to indicate |
diff --git a/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl b/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl index c4d2e3507af9..9d644f7e241e 100644 --- a/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl +++ b/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl | |||
@@ -42,7 +42,7 @@ | |||
42 | <sect1><title>Device Components</title> | 42 | <sect1><title>Device Components</title> |
43 | !Esound/core/device.c | 43 | !Esound/core/device.c |
44 | </sect1> | 44 | </sect1> |
45 | <sect1><title>KMOD and Device File Entries</title> | 45 | <sect1><title>Module requests and Device File Entries</title> |
46 | !Esound/core/sound.c | 46 | !Esound/core/sound.c |
47 | </sect1> | 47 | </sect1> |
48 | <sect1><title>Memory Management Helpers</title> | 48 | <sect1><title>Memory Management Helpers</title> |
diff --git a/Documentation/specialix.txt b/Documentation/specialix.txt index 4a4b428ce8f6..6eb6f3a3331c 100644 --- a/Documentation/specialix.txt +++ b/Documentation/specialix.txt | |||
@@ -270,8 +270,8 @@ The pinout of the connectors on the IO8+ is: | |||
270 | Hardware handshaking issues. | 270 | Hardware handshaking issues. |
271 | ============================ | 271 | ============================ |
272 | 272 | ||
273 | The driver can be compiled in two different ways. The default | 273 | The driver can be told to operate in two different ways. The default |
274 | ("Specialix DTR/RTS pin is RTS" is off) the pin behaves as DTR when | 274 | behaviour is specialix.sx_rtscts = 0 where the pin behaves as DTR when |
275 | hardware handshaking is off. It behaves as the RTS hardware | 275 | hardware handshaking is off. It behaves as the RTS hardware |
276 | handshaking signal when hardware handshaking is selected. | 276 | handshaking signal when hardware handshaking is selected. |
277 | 277 | ||
@@ -280,7 +280,7 @@ cable will either be compatible with hardware handshaking or with | |||
280 | software handshaking. So switching on the fly is not really an | 280 | software handshaking. So switching on the fly is not really an |
281 | option. | 281 | option. |
282 | 282 | ||
283 | I actually prefer to use the "Specialix DTR/RTS pin is RTS" option. | 283 | I actually prefer to use the "specialix.sx_rtscts=1" option. |
284 | This makes the DTR/RTS pin always an RTS pin, and ioctls to | 284 | This makes the DTR/RTS pin always an RTS pin, and ioctls to |
285 | change DTR are always ignored. I have a cable that is configured | 285 | change DTR are always ignored. I have a cable that is configured |
286 | for this. | 286 | for this. |
@@ -379,7 +379,5 @@ it doesn't fit in your computer, bring back the card. | |||
379 | You have to WRITE to the address register to even | 379 | You have to WRITE to the address register to even |
380 | read-probe a CD186x register. Disable autodetection? | 380 | read-probe a CD186x register. Disable autodetection? |
381 | -- Specialix: any suggestions? | 381 | -- Specialix: any suggestions? |
382 | - Arbitrary baud rates are not implemented yet. | ||
383 | If you need this, bug me about it. | ||
384 | 382 | ||
385 | 383 | ||
diff --git a/Documentation/sysfs-rules.txt b/Documentation/sysfs-rules.txt index 80ef562160bb..6049a2a84dda 100644 --- a/Documentation/sysfs-rules.txt +++ b/Documentation/sysfs-rules.txt | |||
@@ -3,9 +3,8 @@ Rules on how to access information in the Linux kernel sysfs | |||
3 | The kernel-exported sysfs exports internal kernel implementation details | 3 | The kernel-exported sysfs exports internal kernel implementation details |
4 | and depends on internal kernel structures and layout. It is agreed upon | 4 | and depends on internal kernel structures and layout. It is agreed upon |
5 | by the kernel developers that the Linux kernel does not provide a stable | 5 | by the kernel developers that the Linux kernel does not provide a stable |
6 | internal API. As sysfs is a direct export of kernel internal | 6 | internal API. Therefore, there are aspects of the sysfs interface that |
7 | structures, the sysfs interface cannot provide a stable interface either; | 7 | may not be stable across kernel releases. |
8 | it may always change along with internal kernel changes. | ||
9 | 8 | ||
10 | To minimize the risk of breaking users of sysfs, which are in most cases | 9 | To minimize the risk of breaking users of sysfs, which are in most cases |
11 | low-level userspace applications, with a new kernel release, the users | 10 | low-level userspace applications, with a new kernel release, the users |
diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt index 621024fd3a18..44d124005bad 100644 --- a/Documentation/telephony/ixj.txt +++ b/Documentation/telephony/ixj.txt | |||
@@ -305,21 +305,14 @@ driver, like this: | |||
305 | 305 | ||
306 | which will result in the needed drivers getting loaded automatically. | 306 | which will result in the needed drivers getting loaded automatically. |
307 | 307 | ||
308 | g. if you are planning on using kerneld to automatically load the | 308 | g. if you are planning on having the kernel automatically request |
309 | module for you, then you need to edit /etc/conf.modules and add the | 309 | the module for you, then you need to edit /etc/conf.modules and add the |
310 | following lines: | 310 | following lines: |
311 | 311 | ||
312 | options ixj dspio=0x340 xio=0x330 ixjdebug=0 | 312 | options ixj dspio=0x340 xio=0x330 ixjdebug=0 |
313 | 313 | ||
314 | If you do this, then when you execute an application that uses the | 314 | If you do this, then when you execute an application that uses the |
315 | module kerneld will load the module for you. Note that to do this, | 315 | module the kernel will request that it is loaded. |
316 | you need to have your kernel set to support kerneld. You can check | ||
317 | for this by looking at /usr/src/linux/.config and you should see this: | ||
318 | |||
319 | # Loadable module support | ||
320 | # | ||
321 | <snip> | ||
322 | CONFIG_KMOD=y | ||
323 | 316 | ||
324 | h. if you want non-root users to be able to read and write to the | 317 | h. if you want non-root users to be able to read and write to the |
325 | ixj devices (this is a good idea!) you should do the following: | 318 | ixj devices (this is a good idea!) you should do the following: |
diff --git a/Documentation/usb/gadget_serial.txt b/Documentation/usb/gadget_serial.txt index 815f5c2301ff..9b22bd14c348 100644 --- a/Documentation/usb/gadget_serial.txt +++ b/Documentation/usb/gadget_serial.txt | |||
@@ -1,6 +1,7 @@ | |||
1 | 1 | ||
2 | Linux Gadget Serial Driver v2.0 | 2 | Linux Gadget Serial Driver v2.0 |
3 | 11/20/2004 | 3 | 11/20/2004 |
4 | (updated 8-May-2008 for v2.3) | ||
4 | 5 | ||
5 | 6 | ||
6 | License and Disclaimer | 7 | License and Disclaimer |
@@ -31,7 +32,7 @@ Prerequisites | |||
31 | ------------- | 32 | ------------- |
32 | Versions of the gadget serial driver are available for the | 33 | Versions of the gadget serial driver are available for the |
33 | 2.4 Linux kernels, but this document assumes you are using | 34 | 2.4 Linux kernels, but this document assumes you are using |
34 | version 2.0 or later of the gadget serial driver in a 2.6 | 35 | version 2.3 or later of the gadget serial driver in a 2.6 |
35 | Linux kernel. | 36 | Linux kernel. |
36 | 37 | ||
37 | This document assumes that you are familiar with Linux and | 38 | This document assumes that you are familiar with Linux and |
@@ -40,6 +41,12 @@ standard utilities, use minicom and HyperTerminal, and work with | |||
40 | USB and serial devices. It also assumes you configure the Linux | 41 | USB and serial devices. It also assumes you configure the Linux |
41 | gadget and usb drivers as modules. | 42 | gadget and usb drivers as modules. |
42 | 43 | ||
44 | With version 2.3 of the driver, major and minor device nodes are | ||
45 | no longer statically defined. Your Linux based system should mount | ||
46 | sysfs in /sys, and use "mdev" (in Busybox) or "udev" to make the | ||
47 | /dev nodes matching the sysfs /sys/class/tty files. | ||
48 | |||
49 | |||
43 | 50 | ||
44 | Overview | 51 | Overview |
45 | -------- | 52 | -------- |
@@ -104,15 +111,8 @@ driver. All this are listed under "USB Gadget Support" when | |||
104 | configuring the kernel. Then rebuild and install the kernel or | 111 | configuring the kernel. Then rebuild and install the kernel or |
105 | modules. | 112 | modules. |
106 | 113 | ||
107 | The gadget serial driver uses major number 127, for now. So you | ||
108 | will need to create a device node for it, like this: | ||
109 | |||
110 | mknod /dev/ttygserial c 127 0 | ||
111 | |||
112 | You only need to do this once. | ||
113 | |||
114 | Then you must load the gadget serial driver. To load it as an | 114 | Then you must load the gadget serial driver. To load it as an |
115 | ACM device, do this: | 115 | ACM device (recommended for interoperability), do this: |
116 | 116 | ||
117 | modprobe g_serial use_acm=1 | 117 | modprobe g_serial use_acm=1 |
118 | 118 | ||
@@ -125,6 +125,23 @@ controller driver. This must be done each time you reboot the gadget | |||
125 | side Linux system. You can add this to the start up scripts, if | 125 | side Linux system. You can add this to the start up scripts, if |
126 | desired. | 126 | desired. |
127 | 127 | ||
128 | Your system should use mdev (from busybox) or udev to make the | ||
129 | device nodes. After this gadget driver has been set up you should | ||
130 | then see a /dev/ttyGS0 node: | ||
131 | |||
132 | # ls -l /dev/ttyGS0 | cat | ||
133 | crw-rw---- 1 root root 253, 0 May 8 14:10 /dev/ttyGS0 | ||
134 | # | ||
135 | |||
136 | Note that the major number (253, above) is system-specific. If | ||
137 | you need to create /dev nodes by hand, the right numbers to use | ||
138 | will be in the /sys/class/tty/ttyGS0/dev file. | ||
139 | |||
140 | When you link this gadget driver early, perhaps even statically, | ||
141 | you may want to set up an /etc/inittab entry to run "getty" on it. | ||
142 | The /dev/ttyGS0 line should work like most any other serial port. | ||
143 | |||
144 | |||
128 | If gadget serial is loaded as an ACM device you will want to use | 145 | If gadget serial is loaded as an ACM device you will want to use |
129 | either the Windows or Linux ACM driver on the host side. If gadget | 146 | either the Windows or Linux ACM driver on the host side. If gadget |
130 | serial is loaded as a bulk in/out device, you will want to use the | 147 | serial is loaded as a bulk in/out device, you will want to use the |
diff --git a/Documentation/usb/persist.txt b/Documentation/usb/persist.txt index d56cb1a11550..074b159b77c2 100644 --- a/Documentation/usb/persist.txt +++ b/Documentation/usb/persist.txt | |||
@@ -81,8 +81,11 @@ re-enumeration shows that the device now attached to that port has the | |||
81 | same descriptors as before, including the Vendor and Product IDs, then | 81 | same descriptors as before, including the Vendor and Product IDs, then |
82 | the kernel continues to use the same device structure. In effect, the | 82 | the kernel continues to use the same device structure. In effect, the |
83 | kernel treats the device as though it had merely been reset instead of | 83 | kernel treats the device as though it had merely been reset instead of |
84 | unplugged. The same thing happens if the host controller is in the | 84 | unplugged. |
85 | expected state but a USB device was unplugged and then replugged. | 85 | |
86 | The same thing happens if the host controller is in the expected state | ||
87 | but a USB device was unplugged and then replugged, or if a USB device | ||
88 | fails to carry out a normal resume. | ||
86 | 89 | ||
87 | If no device is now attached to the port, or if the descriptors are | 90 | If no device is now attached to the port, or if the descriptors are |
88 | different from what the kernel remembers, then the treatment is what | 91 | different from what the kernel remembers, then the treatment is what |
diff --git a/Documentation/usb/uhci.txt b/Documentation/usb/uhci.txt deleted file mode 100644 index 2f25952c86c6..000000000000 --- a/Documentation/usb/uhci.txt +++ /dev/null | |||
@@ -1,165 +0,0 @@ | |||
1 | Specification and Internals for the New UHCI Driver (Whitepaper...) | ||
2 | |||
3 | brought to you by | ||
4 | |||
5 | Georg Acher, acher@in.tum.de (executive slave) (base guitar) | ||
6 | Deti Fliegl, deti@fliegl.de (executive slave) (lead voice) | ||
7 | Thomas Sailer, sailer@ife.ee.ethz.ch (chief consultant) (cheer leader) | ||
8 | |||
9 | $Id: README.uhci,v 1.1 1999/12/14 14:03:02 fliegl Exp $ | ||
10 | |||
11 | This document and the new uhci sources can be found on | ||
12 | http://hotswap.in.tum.de/usb | ||
13 | |||
14 | 1. General issues | ||
15 | |||
16 | 1.1 Why a new UHCI driver, we already have one?!? | ||
17 | |||
18 | Correct, but its internal structure got more and more mixed up by the (still | ||
19 | ongoing) efforts to get isochronous transfers (ISO) to work. | ||
20 | Since there is an increasing need for reliable ISO-transfers (especially | ||
21 | for USB-audio needed by TS and for a DAB-USB-Receiver build by GA and DF), | ||
22 | this state was a bit unsatisfying in our opinion, so we've decided (based | ||
23 | on knowledge and experiences with the old UHCI driver) to start | ||
24 | from scratch with a new approach, much simpler but at the same time more | ||
25 | powerful. | ||
26 | It is inspired by the way Win98/Win2000 handles USB requests via URBs, | ||
27 | but it's definitely 100% free of MS-code and doesn't crash while | ||
28 | unplugging an used ISO-device like Win98 ;-) | ||
29 | Some code for HW setup and root hub management was taken from the | ||
30 | original UHCI driver, but heavily modified to fit into the new code. | ||
31 | The invention of the basic concept, and major coding were completed in two | ||
32 | days (and nights) on the 16th and 17th of October 1999, now known as the | ||
33 | great USB-October-Revolution started by GA, DF, and TS ;-) | ||
34 | |||
35 | Since the concept is in no way UHCI dependent, we hope that it will also be | ||
36 | transferred to the OHCI-driver, so both drivers share a common API. | ||
37 | |||
38 | 1.2. Advantages and disadvantages | ||
39 | |||
40 | + All USB transfer types work now! | ||
41 | + Asynchronous operation | ||
42 | + Simple, but powerful interface (only two calls for start and cancel) | ||
43 | + Easy migration to the new API, simplified by a compatibility API | ||
44 | + Simple usage of ISO transfers | ||
45 | + Automatic linking of requests | ||
46 | + ISO transfers allow variable length for each frame and striping | ||
47 | + No CPU dependent and non-portable atomic memory access, no asm()-inlines | ||
48 | + Tested on x86 and Alpha | ||
49 | |||
50 | - Rewriting for ISO transfers needed | ||
51 | |||
52 | 1.3. Is there some compatibility to the old API? | ||
53 | |||
54 | Yes, but only for control, bulk and interrupt transfers. We've implemented | ||
55 | some wrapper calls for these transfer types. The usbcore works fine with | ||
56 | these wrappers. For ISO there's no compatibility, because the old ISO-API | ||
57 | and its semantics were unnecessary complicated in our opinion. | ||
58 | |||
59 | 1.4. What's really working? | ||
60 | |||
61 | As said above, CTRL and BULK already work fine even with the wrappers, | ||
62 | so legacy code wouldn't notice the change. | ||
63 | Regarding to Thomas, ISO transfers now run stable with USB audio. | ||
64 | INT transfers (e.g. mouse driver) work fine, too. | ||
65 | |||
66 | 1.5. Are there any bugs? | ||
67 | |||
68 | No ;-) | ||
69 | Hm... | ||
70 | Well, of course this implementation needs extensive testing on all available | ||
71 | hardware, but we believe that any fixes shouldn't harm the overall concept. | ||
72 | |||
73 | 1.6. What should be done next? | ||
74 | |||
75 | A large part of the request handling seems to be identical for UHCI and | ||
76 | OHCI, so it would be a good idea to extract the common parts and have only | ||
77 | the HW specific stuff in uhci.c. Furthermore, all other USB device drivers | ||
78 | should need URBification, if they use isochronous or interrupt transfers. | ||
79 | One thing missing in the current implementation (and the old UHCI driver) | ||
80 | is fair queueing for BULK transfers. Since this would need (in principle) | ||
81 | the alteration of already constructed TD chains (to switch from depth to | ||
82 | breadth execution), another way has to be found. Maybe some simple | ||
83 | heuristics work with the same effect. | ||
84 | |||
85 | --------------------------------------------------------------------------- | ||
86 | |||
87 | 2. Internal structure and mechanisms | ||
88 | |||
89 | To get quickly familiar with the internal structures, here's a short | ||
90 | description how the new UHCI driver works. However, the ultimate source of | ||
91 | truth is only uhci.c! | ||
92 | |||
93 | 2.1. Descriptor structure (QHs and TDs) | ||
94 | |||
95 | During initialization, the following skeleton is allocated in init_skel: | ||
96 | |||
97 | framespecific | common chain | ||
98 | |||
99 | framelist[] | ||
100 | [ 0 ]-----> TD --> TD -------\ | ||
101 | [ 1 ]-----> TD --> TD --------> TD ----> QH -------> QH -------> QH ---> NULL | ||
102 | ... TD --> TD -------/ | ||
103 | [1023]-----> TD --> TD ------/ | ||
104 | |||
105 | ^^ ^^ ^^ ^^ ^^ ^^ | ||
106 | 1024 TDs for 7 TDs for 1 TD for Start of Start of End Chain | ||
107 | ISO INT (2-128ms) 1ms-INT CTRL Chain BULK Chain | ||
108 | |||
109 | For each CTRL or BULK transfer a new QH is allocated and the containing data | ||
110 | transfers are appended as (vertical) TDs. After building the whole QH with its | ||
111 | dangling TDs, the QH is inserted before the BULK Chain QH (for CTRL) or | ||
112 | before the End Chain QH (for BULK). Since only the QH->next pointers are | ||
113 | affected, no atomic memory operation is required. The three QHs in the | ||
114 | common chain are never equipped with TDs! | ||
115 | |||
116 | For ISO or INT, the TD for each frame is simply inserted into the appropriate | ||
117 | ISO/INT-TD-chain for the desired frame. The 7 skeleton INT-TDs are scattered | ||
118 | among the 1024 frames similar to the old UHCI driver. | ||
119 | |||
120 | For CTRL/BULK/ISO, the last TD in the transfer has the IOC-bit set. For INT, | ||
121 | every TD (there is only one...) has the IOC-bit set. | ||
122 | |||
123 | Besides the data for the UHCI controller (2 or 4 32bit words), the descriptors | ||
124 | are double-linked through the .vertical and .horizontal elements in the | ||
125 | SW data of the descriptor (using the double-linked list structures and | ||
126 | operations), but SW-linking occurs only in closed domains, i.e. for each of | ||
127 | the 1024 ISO-chains and the 8 INT-chains there is a closed cycle. This | ||
128 | simplifies all insertions and unlinking operations and avoids costly | ||
129 | bus_to_virt()-calls. | ||
130 | |||
131 | 2.2. URB structure and linking to QH/TDs | ||
132 | |||
133 | During assembly of the QH and TDs of the requested action, these descriptors | ||
134 | are stored in urb->urb_list, so the allocated QH/TD descriptors are bound to | ||
135 | this URB. | ||
136 | If the assembly was successful and the descriptors were added to the HW chain, | ||
137 | the corresponding URB is inserted into a global URB list for this controller. | ||
138 | This list stores all pending URBs. | ||
139 | |||
140 | 2.3. Interrupt processing | ||
141 | |||
142 | Since UHCI provides no means to directly detect completed transactions, the | ||
143 | following is done in each UHCI interrupt (uhci_interrupt()): | ||
144 | |||
145 | For each URB in the pending queue (process_urb()), the ACTIVE-flag of the | ||
146 | associated TDs are processed (depending on the transfer type | ||
147 | process_{transfer|interrupt|iso}()). If the TDs are not active anymore, | ||
148 | they indicate the completion of the transaction and the status is calculated. | ||
149 | Inactive QH/TDs are removed from the HW chain (since the host controller | ||
150 | already removed the TDs from the QH, no atomic access is needed) and | ||
151 | eventually the URB is marked as completed (OK or errors) and removed from the | ||
152 | pending queue. Then the next linked URB is submitted. After (or immediately | ||
153 | before) that, the completion handler is called. | ||
154 | |||
155 | 2.4. Unlinking URBs | ||
156 | |||
157 | First, all QH/TDs stored in the URB are unlinked from the HW chain. | ||
158 | To ensure that the host controller really left a vertical TD chain, we | ||
159 | wait for one frame. After that, the TDs are physically destroyed. | ||
160 | |||
161 | 2.5. URB linking and the consequences | ||
162 | |||
163 | Since URBs can be linked and the corresponding submit_urb is called in | ||
164 | the UHCI-interrupt, all work associated with URB/QH/TD assembly has to be | ||
165 | interrupt save. This forces kmalloc to use GFP_ATOMIC in the interrupt. | ||
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 191194ea1e25..f0e613ba55b8 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 | |||
@@ -8,3 +8,4 @@ | |||
8 | 7 -> Hauppauge WinTV-HVR1200 [0070:71d1,0070:71d3] | 8 | 7 -> Hauppauge WinTV-HVR1200 [0070:71d1,0070:71d3] |
9 | 8 -> Hauppauge WinTV-HVR1700 [0070:8101] | 9 | 8 -> Hauppauge WinTV-HVR1700 [0070:8101] |
10 | 9 -> Hauppauge WinTV-HVR1400 [0070:8010] | 10 | 9 -> Hauppauge WinTV-HVR1400 [0070:8010] |
11 | 10 -> DViCO FusionHDTV7 Dual Express [18ac:d618] | ||
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 1d6a245c828f..10591467ef16 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx | |||
@@ -8,10 +8,13 @@ | |||
8 | 7 -> Leadtek Winfast USB II (em2800) | 8 | 7 -> Leadtek Winfast USB II (em2800) |
9 | 8 -> Kworld USB2800 (em2800) | 9 | 8 -> Kworld USB2800 (em2800) |
10 | 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a] | 10 | 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a] |
11 | 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500,2040:6502] | 11 | 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] |
12 | 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] | 12 | 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] |
13 | 12 -> Kworld PVR TV 2800 RF (em2820/em2840) | 13 | 12 -> Kworld PVR TV 2800 RF (em2820/em2840) |
14 | 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] | 14 | 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] |
15 | 14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) | 15 | 14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) |
16 | 15 -> V-Gear PocketTV (em2800) | 16 | 15 -> V-Gear PocketTV (em2800) |
17 | 16 -> Hauppauge WinTV HVR 950 (em2880) [2040:6513,2040:6517,2040:651b,2040:651f] | 17 | 16 -> Hauppauge WinTV HVR 950 (em2880) [2040:6513,2040:6517,2040:651b,2040:651f] |
18 | 17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227] | ||
19 | 18 -> Hauppauge WinTV HVR 900 (R2) (em2880) [2040:6502] | ||
20 | 19 -> PointNix Intra-Oral Camera (em2860) | ||
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 67937df1e974..39868af9cf9f 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 | |||
@@ -37,7 +37,7 @@ | |||
37 | 36 -> UPMOST PURPLE TV [12ab:0800] | 37 | 36 -> UPMOST PURPLE TV [12ab:0800] |
38 | 37 -> Items MuchTV Plus / IT-005 | 38 | 37 -> Items MuchTV Plus / IT-005 |
39 | 38 -> Terratec Cinergy 200 TV [153b:1152] | 39 | 38 -> Terratec Cinergy 200 TV [153b:1152] |
40 | 39 -> LifeView FlyTV Platinum Mini [5168:0212,4e42:0212] | 40 | 39 -> LifeView FlyTV Platinum Mini [5168:0212,4e42:0212,5169:1502] |
41 | 40 -> Compro VideoMate TV PVR/FM [185b:c100] | 41 | 40 -> Compro VideoMate TV PVR/FM [185b:c100] |
42 | 41 -> Compro VideoMate TV Gold+ [185b:c100] | 42 | 41 -> Compro VideoMate TV Gold+ [185b:c100] |
43 | 42 -> Sabrent SBT-TVFM (saa7130) | 43 | 42 -> Sabrent SBT-TVFM (saa7130) |
@@ -128,7 +128,7 @@ | |||
128 | 127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090] | 128 | 127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090] |
129 | 128 -> Beholder BeholdTV Columbus TVFM [0000:5201] | 129 | 128 -> Beholder BeholdTV Columbus TVFM [0000:5201] |
130 | 129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093] | 130 | 129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093] |
131 | 130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193,5ace:6191] | 131 | 130 -> Beholder BeholdTV M6 [5ace:6190] |
132 | 131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] | 132 | 131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] |
133 | 132 -> Genius TVGO AM11MCE | 133 | 132 -> Genius TVGO AM11MCE |
134 | 133 -> NXP Snake DVB-S reference design | 134 | 133 -> NXP Snake DVB-S reference design |
@@ -141,3 +141,7 @@ | |||
141 | 140 -> Avermedia DVB-S Pro A700 [1461:a7a1] | 141 | 140 -> Avermedia DVB-S Pro A700 [1461:a7a1] |
142 | 141 -> Avermedia DVB-S Hybrid+FM A700 [1461:a7a2] | 142 | 141 -> Avermedia DVB-S Hybrid+FM A700 [1461:a7a2] |
143 | 142 -> Beholder BeholdTV H6 [5ace:6290] | 143 | 142 -> Beholder BeholdTV H6 [5ace:6290] |
144 | 143 -> Beholder BeholdTV M63 [5ace:6191] | ||
145 | 144 -> Beholder BeholdTV M6 Extra [5ace:6193] | ||
146 | 145 -> AVerMedia MiniPCI DVB-T Hybrid M103 [1461:f636] | ||
147 | 146 -> ASUSTeK P7131 Analog | ||
diff --git a/Documentation/video4linux/cx18.txt b/Documentation/video4linux/cx18.txt index 6842c262890f..914cb7e734a2 100644 --- a/Documentation/video4linux/cx18.txt +++ b/Documentation/video4linux/cx18.txt | |||
@@ -1,36 +1,30 @@ | |||
1 | Some notes regarding the cx18 driver for the Conexant CX23418 MPEG | 1 | Some notes regarding the cx18 driver for the Conexant CX23418 MPEG |
2 | encoder chip: | 2 | encoder chip: |
3 | 3 | ||
4 | 1) The only hardware currently supported is the Hauppauge HVR-1600 | 4 | 1) Currently supported are: |
5 | card and the Compro VideoMate H900 (note that this card only | ||
6 | supports analog input, it has no digital tuner!). | ||
7 | 5 | ||
8 | 2) Some people have problems getting the i2c bus to work. Cause unknown. | 6 | - Hauppauge HVR-1600 |
9 | The symptom is that the eeprom cannot be read and the card is | 7 | - Compro VideoMate H900 |
10 | unusable. | 8 | - Yuan MPC718 |
9 | - Conexant Raptor PAL/SECAM devkit | ||
11 | 10 | ||
12 | 3) The audio from the analog tuner is mono only. Probably caused by | 11 | 2) Some people have problems getting the i2c bus to work. |
13 | incorrect audio register information in the datasheet. We are | 12 | The symptom is that the eeprom cannot be read and the card is |
14 | waiting for updated information from Conexant. | 13 | unusable. This is probably fixed, but if you have problems |
14 | then post to the video4linux or ivtv-users mailinglist. | ||
15 | 15 | ||
16 | 4) VBI (raw or sliced) has not yet been implemented. | 16 | 3) VBI (raw or sliced) has not yet been implemented. |
17 | 17 | ||
18 | 5) MPEG indexing is not yet implemented. | 18 | 4) MPEG indexing is not yet implemented. |
19 | 19 | ||
20 | 6) The driver is still a bit rough around the edges, this should | 20 | 5) The driver is still a bit rough around the edges, this should |
21 | improve over time. | 21 | improve over time. |
22 | 22 | ||
23 | 23 | ||
24 | Firmware: | 24 | Firmware: |
25 | 25 | ||
26 | The firmware needs to be extracted from the Windows Hauppauge HVR-1600 | 26 | You can obtain the firmware files here: |
27 | driver, available here: | ||
28 | |||
29 | http://hauppauge.lightpath.net/software/install_cd/hauppauge_cd_3.4d1.zip | ||
30 | 27 | ||
31 | Unzip, then copy the following files to the firmware directory | 28 | http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz |
32 | and rename them as follows: | ||
33 | 29 | ||
34 | Drivers/Driver18/hcw18apu.rom -> v4l-cx23418-apu.fw | 30 | Untar and copy the .fw files to your firmware directory. |
35 | Drivers/Driver18/hcw18enc.rom -> v4l-cx23418-cpu.fw | ||
36 | Drivers/Driver18/hcw18mlC.rom -> v4l-cx23418-dig.fw | ||
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt new file mode 100644 index 000000000000..0c4880af57a3 --- /dev/null +++ b/Documentation/video4linux/gspca.txt | |||
@@ -0,0 +1,243 @@ | |||
1 | List of the webcams know by gspca. | ||
2 | |||
3 | The modules are: | ||
4 | gspca_main main driver | ||
5 | gspca_xxxx subdriver module with xxxx as follows | ||
6 | |||
7 | xxxx vend:prod | ||
8 | ---- | ||
9 | spca501 0000:0000 MystFromOri Unknow Camera | ||
10 | spca501 040a:0002 Kodak DVC-325 | ||
11 | spca500 040a:0300 Kodak EZ200 | ||
12 | zc3xx 041e:041e Creative WebCam Live! | ||
13 | spca500 041e:400a Creative PC-CAM 300 | ||
14 | sunplus 041e:400b Creative PC-CAM 600 | ||
15 | sunplus 041e:4012 PC-Cam350 | ||
16 | sunplus 041e:4013 Creative Pccam750 | ||
17 | zc3xx 041e:4017 Creative Webcam Mobile PD1090 | ||
18 | spca508 041e:4018 Creative Webcam Vista (PD1100) | ||
19 | spca561 041e:401a Creative Webcam Vista (PD1100) | ||
20 | zc3xx 041e:401c Creative NX | ||
21 | spca505 041e:401d Creative Webcam NX ULTRA | ||
22 | zc3xx 041e:401e Creative Nx Pro | ||
23 | zc3xx 041e:401f Creative Webcam Notebook PD1171 | ||
24 | pac207 041e:4028 Creative Webcam Vista Plus | ||
25 | zc3xx 041e:4029 Creative WebCam Vista Pro | ||
26 | zc3xx 041e:4034 Creative Instant P0620 | ||
27 | zc3xx 041e:4035 Creative Instant P0620D | ||
28 | zc3xx 041e:4036 Creative Live ! | ||
29 | zc3xx 041e:403a Creative Nx Pro 2 | ||
30 | spca561 041e:403b Creative Webcam Vista (VF0010) | ||
31 | zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250) | ||
32 | ov519 041e:4052 Creative Live! VISTA IM | ||
33 | zc3xx 041e:4053 Creative Live!Cam Video IM | ||
34 | ov519 041e:405f Creative Live! VISTA VF0330 | ||
35 | ov519 041e:4060 Creative Live! VISTA VF0350 | ||
36 | ov519 041e:4061 Creative Live! VISTA VF0400 | ||
37 | ov519 041e:4064 Creative Live! VISTA VF0420 | ||
38 | ov519 041e:4068 Creative Live! VISTA VF0470 | ||
39 | spca561 0458:7004 Genius VideoCAM Express V2 | ||
40 | sunplus 0458:7006 Genius Dsc 1.3 Smart | ||
41 | zc3xx 0458:7007 Genius VideoCam V2 | ||
42 | zc3xx 0458:700c Genius VideoCam V3 | ||
43 | zc3xx 0458:700f Genius VideoCam Web V2 | ||
44 | sonixj 0458:7025 Genius Eye 311Q | ||
45 | sonixj 045e:00f5 MicroSoft VX3000 | ||
46 | sonixj 045e:00f7 MicroSoft VX1000 | ||
47 | ov519 045e:028c Micro$oft xbox cam | ||
48 | spca508 0461:0815 Micro Innovation IC200 | ||
49 | sunplus 0461:0821 Fujifilm MV-1 | ||
50 | zc3xx 0461:0a00 MicroInnovation WebCam320 | ||
51 | spca500 046d:0890 Logitech QuickCam traveler | ||
52 | vc032x 046d:0892 Logitech Orbicam | ||
53 | vc032x 046d:0896 Logitech Orbicam | ||
54 | zc3xx 046d:08a0 Logitech QC IM | ||
55 | zc3xx 046d:08a1 Logitech QC IM 0x08A1 +sound | ||
56 | zc3xx 046d:08a2 Labtec Webcam Pro | ||
57 | zc3xx 046d:08a3 Logitech QC Chat | ||
58 | zc3xx 046d:08a6 Logitech QCim | ||
59 | zc3xx 046d:08a7 Logitech QuickCam Image | ||
60 | zc3xx 046d:08a9 Logitech Notebook Deluxe | ||
61 | zc3xx 046d:08aa Labtec Webcam Notebook | ||
62 | zc3xx 046d:08ac Logitech QuickCam Cool | ||
63 | zc3xx 046d:08ad Logitech QCCommunicate STX | ||
64 | zc3xx 046d:08ae Logitech QuickCam for Notebooks | ||
65 | zc3xx 046d:08af Logitech QuickCam Cool | ||
66 | zc3xx 046d:08b9 Logitech QC IM ??? | ||
67 | zc3xx 046d:08d7 Logitech QCam STX | ||
68 | zc3xx 046d:08d9 Logitech QuickCam IM/Connect | ||
69 | zc3xx 046d:08d8 Logitech Notebook Deluxe | ||
70 | zc3xx 046d:08da Logitech QuickCam Messenger | ||
71 | zc3xx 046d:08dd Logitech QuickCam for Notebooks | ||
72 | spca500 046d:0900 Logitech Inc. ClickSmart 310 | ||
73 | spca500 046d:0901 Logitech Inc. ClickSmart 510 | ||
74 | sunplus 046d:0905 Logitech ClickSmart 820 | ||
75 | tv8532 046d:0920 QC Express | ||
76 | tv8532 046d:0921 Labtec Webcam | ||
77 | spca561 046d:0928 Logitech QC Express Etch2 | ||
78 | spca561 046d:0929 Labtec Webcam Elch2 | ||
79 | spca561 046d:092a Logitech QC for Notebook | ||
80 | spca561 046d:092b Labtec Webcam Plus | ||
81 | spca561 046d:092c Logitech QC chat Elch2 | ||
82 | spca561 046d:092d Logitech QC Elch2 | ||
83 | spca561 046d:092e Logitech QC Elch2 | ||
84 | spca561 046d:092f Logitech QC Elch2 | ||
85 | sunplus 046d:0960 Logitech ClickSmart 420 | ||
86 | sunplus 0471:0322 Philips DMVC1300K | ||
87 | zc3xx 0471:0325 Philips SPC 200 NC | ||
88 | zc3xx 0471:0326 Philips SPC 300 NC | ||
89 | sonixj 0471:0327 Philips SPC 600 NC | ||
90 | sonixj 0471:0328 Philips SPC 700 NC | ||
91 | zc3xx 0471:032d Philips spc210nc | ||
92 | zc3xx 0471:032e Philips spc315nc | ||
93 | sonixj 0471:0330 Philips SPC 710NC | ||
94 | spca501 0497:c001 Smile International | ||
95 | sunplus 04a5:3003 Benq DC 1300 | ||
96 | sunplus 04a5:3008 Benq DC 1500 | ||
97 | sunplus 04a5:300a Benq DC3410 | ||
98 | spca500 04a5:300c Benq DC1016 | ||
99 | sunplus 04f1:1001 JVC GC A50 | ||
100 | spca561 04fc:0561 Flexcam 100 | ||
101 | sunplus 04fc:500c Sunplus CA500C | ||
102 | sunplus 04fc:504a Aiptek Mini PenCam 1.3 | ||
103 | sunplus 04fc:504b Maxell MaxPocket LE 1.3 | ||
104 | sunplus 04fc:5330 Digitrex 2110 | ||
105 | sunplus 04fc:5360 Sunplus Generic | ||
106 | spca500 04fc:7333 PalmPixDC85 | ||
107 | sunplus 04fc:ffff Pure DigitalDakota | ||
108 | spca501 0506:00df 3Com HomeConnect Lite | ||
109 | sunplus 052b:1513 Megapix V4 | ||
110 | tv8532 0545:808b Veo Stingray | ||
111 | tv8532 0545:8333 Veo Stingray | ||
112 | sunplus 0546:3155 Polaroid PDC3070 | ||
113 | sunplus 0546:3191 Polaroid Ion 80 | ||
114 | sunplus 0546:3273 Polaroid PDC2030 | ||
115 | ov519 054c:0154 Sonny toy4 | ||
116 | ov519 054c:0155 Sonny toy5 | ||
117 | zc3xx 055f:c005 Mustek Wcam300A | ||
118 | spca500 055f:c200 Mustek Gsmart 300 | ||
119 | sunplus 055f:c211 Kowa Bs888e Microcamera | ||
120 | spca500 055f:c220 Gsmart Mini | ||
121 | sunplus 055f:c230 Mustek Digicam 330K | ||
122 | sunplus 055f:c232 Mustek MDC3500 | ||
123 | sunplus 055f:c360 Mustek DV4000 Mpeg4 | ||
124 | sunplus 055f:c420 Mustek gSmart Mini 2 | ||
125 | sunplus 055f:c430 Mustek Gsmart LCD 2 | ||
126 | sunplus 055f:c440 Mustek DV 3000 | ||
127 | sunplus 055f:c520 Mustek gSmart Mini 3 | ||
128 | sunplus 055f:c530 Mustek Gsmart LCD 3 | ||
129 | sunplus 055f:c540 Gsmart D30 | ||
130 | sunplus 055f:c630 Mustek MDC4000 | ||
131 | sunplus 055f:c650 Mustek MDC5500Z | ||
132 | zc3xx 055f:d003 Mustek WCam300A | ||
133 | zc3xx 055f:d004 Mustek WCam300 AN | ||
134 | conex 0572:0041 Creative Notebook cx11646 | ||
135 | ov519 05a9:0519 OmniVision | ||
136 | ov519 05a9:0530 OmniVision | ||
137 | ov519 05a9:4519 OmniVision | ||
138 | ov519 05a9:8519 OmniVision | ||
139 | sunplus 05da:1018 Digital Dream Enigma 1.3 | ||
140 | stk014 05e1:0893 Syntek DV4000 | ||
141 | spca561 060b:a001 Maxell Compact Pc PM3 | ||
142 | zc3xx 0698:2003 CTX M730V built in | ||
143 | spca500 06bd:0404 Agfa CL20 | ||
144 | spca500 06be:0800 Optimedia | ||
145 | sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom | ||
146 | spca506 06e1:a190 ADS Instant VCD | ||
147 | spca508 0733:0110 ViewQuest VQ110 | ||
148 | spca508 0130:0130 Clone Digital Webcam 11043 | ||
149 | spca501 0733:0401 Intel Create and Share | ||
150 | spca501 0733:0402 ViewQuest M318B | ||
151 | spca505 0733:0430 Intel PC Camera Pro | ||
152 | sunplus 0733:1311 Digital Dream Epsilon 1.3 | ||
153 | sunplus 0733:1314 Mercury 2.1MEG Deluxe Classic Cam | ||
154 | sunplus 0733:2211 Jenoptik jdc 21 LCD | ||
155 | sunplus 0733:2221 Mercury Digital Pro 3.1p | ||
156 | sunplus 0733:3261 Concord 3045 spca536a | ||
157 | sunplus 0733:3281 Cyberpix S550V | ||
158 | spca506 0734:043b 3DeMon USB Capture aka | ||
159 | spca500 084d:0003 D-Link DSC-350 | ||
160 | spca500 08ca:0103 Aiptek PocketDV | ||
161 | sunplus 08ca:0104 Aiptek PocketDVII 1.3 | ||
162 | sunplus 08ca:0106 Aiptek Pocket DV3100+ | ||
163 | sunplus 08ca:2008 Aiptek Mini PenCam 2 M | ||
164 | sunplus 08ca:2010 Aiptek PocketCam 3M | ||
165 | sunplus 08ca:2016 Aiptek PocketCam 2 Mega | ||
166 | sunplus 08ca:2018 Aiptek Pencam SD 2M | ||
167 | sunplus 08ca:2020 Aiptek Slim 3000F | ||
168 | sunplus 08ca:2022 Aiptek Slim 3200 | ||
169 | sunplus 08ca:2024 Aiptek DV3500 Mpeg4 | ||
170 | sunplus 08ca:2028 Aiptek PocketCam4M | ||
171 | sunplus 08ca:2040 Aiptek PocketDV4100M | ||
172 | sunplus 08ca:2042 Aiptek PocketDV5100 | ||
173 | sunplus 08ca:2050 Medion MD 41437 | ||
174 | sunplus 08ca:2060 Aiptek PocketDV5300 | ||
175 | tv8532 0923:010f ICM532 cams | ||
176 | mars 093a:050f Mars-Semi Pc-Camera | ||
177 | pac207 093a:2460 PAC207 Qtec Webcam 100 | ||
178 | pac207 093a:2463 Philips spc200nc pac207 | ||
179 | pac207 093a:2464 Labtec Webcam 1200 | ||
180 | pac207 093a:2468 PAC207 | ||
181 | pac207 093a:2470 Genius GF112 | ||
182 | pac207 093a:2471 PAC207 Genius VideoCam ge111 | ||
183 | pac207 093a:2472 PAC207 Genius VideoCam ge110 | ||
184 | pac7311 093a:2600 PAC7311 Typhoon | ||
185 | pac7311 093a:2601 PAC7311 Phillips SPC610NC | ||
186 | pac7311 093a:2603 PAC7312 | ||
187 | pac7311 093a:2608 PAC7311 Trust WB-3300p | ||
188 | pac7311 093a:260e PAC7311 Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350 | ||
189 | pac7311 093a:260f PAC7311 SnakeCam | ||
190 | pac7311 093a:2621 PAC731x | ||
191 | zc3xx 0ac8:0302 Z-star Vimicro zc0302 | ||
192 | vc032x 0ac8:0321 Vimicro generic vc0321 | ||
193 | vc032x 0ac8:0323 Vimicro Vc0323 | ||
194 | vc032x 0ac8:0328 A4Tech PK-130MG | ||
195 | zc3xx 0ac8:301b Z-Star zc301b | ||
196 | zc3xx 0ac8:303b Vimicro 0x303b | ||
197 | zc3xx 0ac8:305b Z-star Vimicro zc0305b | ||
198 | zc3xx 0ac8:307b Ldlc VC302+Ov7620 | ||
199 | vc032x 0ac8:c001 Sony embedded vimicro | ||
200 | vc032x 0ac8:c002 Sony embedded vimicro | ||
201 | spca508 0af9:0010 Hama USB Sightcam 100 | ||
202 | spca508 0af9:0011 Hama USB Sightcam 100 | ||
203 | sonixb 0c45:6001 Genius VideoCAM NB | ||
204 | sonixb 0c45:6005 Microdia Sweex Mini Webcam | ||
205 | sonixb 0c45:6007 Sonix sn9c101 + Tas5110D | ||
206 | sonixb 0c45:6009 spcaCam@120 | ||
207 | sonixb 0c45:600d spcaCam@120 | ||
208 | sonixb 0c45:6011 Microdia PC Camera (SN9C102) | ||
209 | sonixb 0c45:6019 Generic Sonix OV7630 | ||
210 | sonixb 0c45:6024 Generic Sonix Tas5130c | ||
211 | sonixb 0c45:6025 Xcam Shanga | ||
212 | sonixb 0c45:6028 Sonix Btc Pc380 | ||
213 | sonixb 0c45:6029 spcaCam@150 | ||
214 | sonixb 0c45:602c Generic Sonix OV7630 | ||
215 | sonixb 0c45:602d LIC-200 LG | ||
216 | sonixb 0c45:602e Genius VideoCam Messenger | ||
217 | sonixj 0c45:6040 Speed NVC 350K | ||
218 | sonixj 0c45:607c Sonix sn9c102p Hv7131R | ||
219 | sonixj 0c45:60c0 Sangha Sn535 | ||
220 | sonixj 0c45:60ec SN9C105+MO4000 | ||
221 | sonixj 0c45:60fb Surfer NoName | ||
222 | sonixj 0c45:60fc LG-LIC300 | ||
223 | sonixj 0c45:612a Avant Camera | ||
224 | sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix | ||
225 | sonixj 0c45:6130 Sonix Pccam | ||
226 | sonixj 0c45:6138 Sn9c120 Mo4000 | ||
227 | sonixj 0c45:613b Surfer SN-206 | ||
228 | sonixj 0c45:613c Sonix Pccam168 | ||
229 | sunplus 0d64:0303 Sunplus FashionCam DXG | ||
230 | etoms 102c:6151 Qcam Sangha CIF | ||
231 | etoms 102c:6251 Qcam xxxxxx VGA | ||
232 | zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128 | ||
233 | spca561 10fd:7e50 FlyCam Usb 100 | ||
234 | zc3xx 10fd:8050 Typhoon Webshot II USB 300k | ||
235 | spca501 1776:501c Arowana 300K CMOS Camera | ||
236 | t613 17a1:0128 T613/TAS5130A | ||
237 | vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC | ||
238 | pac207 2001:f115 D-Link DSB-C120 | ||
239 | spca500 2899:012c Toptro Industrial | ||
240 | spca508 8086:0110 Intel Easy PC Camera | ||
241 | spca500 8086:0630 Intel Pocket PC Camera | ||
242 | spca506 99fa:8988 Grandtec V.cap | ||
243 | spca561 abcd:cdee Petcam | ||
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt index e0bba8393c77..05138e8aea07 100644 --- a/Documentation/video4linux/w9968cf.txt +++ b/Documentation/video4linux/w9968cf.txt | |||
@@ -193,9 +193,6 @@ Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled. | |||
193 | loads that module automatically. This action is performed as | 193 | loads that module automatically. This action is performed as |
194 | once soon as the 'w9968cf' module is loaded into memory. | 194 | once soon as the 'w9968cf' module is loaded into memory. |
195 | Default: 1 | 195 | Default: 1 |
196 | Note: The kernel must be compiled with the CONFIG_KMOD option | ||
197 | enabled for the 'ovcamchip' module to be loaded and for | ||
198 | this parameter to be present. | ||
199 | ------------------------------------------------------------------------------- | 196 | ------------------------------------------------------------------------------- |
200 | Name: simcams | 197 | Name: simcams |
201 | Type: int | 198 | Type: int |