From df291fa993c506da89a89264ff8166bccd172a14 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Thu, 8 Jan 2009 10:59:34 -0800 Subject: kbuild: fix kbuild.txt typos Fix typos in the new kbuild.txt file. Signed-off-by: Randy Dunlap Signed-off-by: Sam Ravnborg --- Documentation/kbuild/kbuild.txt | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 923f9dd..f3355b6 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -3,7 +3,7 @@ Environment variables KCPPFLAGS -------------------------------------------------- Additional options to pass when preprocessing. The preprocessing options -will be used in all cases where kbuild do preprocessing including +will be used in all cases where kbuild does preprocessing including building C files and assembler files. KAFLAGS @@ -16,7 +16,7 @@ Additional options to the C compiler. KBUILD_VERBOSE -------------------------------------------------- -Set the kbuild verbosity. Can be assinged same values as "V=...". +Set the kbuild verbosity. Can be assigned same values as "V=...". See make help for the full list. Setting "V=..." takes precedence over KBUILD_VERBOSE. @@ -35,14 +35,14 @@ KBUILD_OUTPUT -------------------------------------------------- Specify the output directory when building the kernel. The output directory can also be specificed using "O=...". -Setting "O=..." takes precedence over KBUILD_OUTPUT +Setting "O=..." takes precedence over KBUILD_OUTPUT. ARCH -------------------------------------------------- Set ARCH to the architecture to be built. In most cases the name of the architecture is the same as the directory name found in the arch/ directory. -But some architectures suach as x86 and sparc has aliases. +But some architectures such as x86 and sparc have aliases. x86: i386 for 32 bit, x86_64 for 64 bit sparc: sparc for 32 bit, sparc64 for 64 bit @@ -63,7 +63,7 @@ CF is often used on the command-line like this: INSTALL_PATH -------------------------------------------------- INSTALL_PATH specifies where to place the updated kernel and system map -images. Default is /boot, but you can set it to other values +images. Default is /boot, but you can set it to other values. MODLIB @@ -90,7 +90,7 @@ INSTALL_MOD_STRIP will used as the options to the strip command. INSTALL_FW_PATH -------------------------------------------------- -INSTALL_FW_PATH specify where to install the firmware blobs. +INSTALL_FW_PATH specifies where to install the firmware blobs. The default value is: $(INSTALL_MOD_PATH)/lib/firmware @@ -99,7 +99,7 @@ The value can be overridden in which case the default value is ignored. INSTALL_HDR_PATH -------------------------------------------------- -INSTALL_HDR_PATH specify where to install user space headers when +INSTALL_HDR_PATH specifies where to install user space headers when executing "make headers_*". The default value is: @@ -112,22 +112,23 @@ The value can be overridden in which case the default value is ignored. KBUILD_MODPOST_WARN -------------------------------------------------- -KBUILD_MODPOST_WARN can be set to avoid error out in case of undefined -symbols in the final module linking stage. +KBUILD_MODPOST_WARN can be set to avoid errors in case of undefined +symbols in the final module linking stage. It changes such errors +into warnings. -KBUILD_MODPOST_FINAL +KBUILD_MODPOST_NOFINAL -------------------------------------------------- KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules. -This is solely usefull to speed up test compiles. +This is solely useful to speed up test compiles. KBUILD_EXTRA_SYMBOLS -------------------------------------------------- -For modules use symbols from another modules. +For modules that use symbols from other modules. See more details in modules.txt. ALLSOURCE_ARCHS -------------------------------------------------- -For tags/TAGS/cscope targets, you can specify more than one archs -to be included in the databases, separated by blankspace. e.g. +For tags/TAGS/cscope targets, you can specify more than one arch +to be included in the databases, separated by blank space. E.g.: $ make ALLSOURCE_ARCHS="x86 mips arm" tags -- cgit v1.1 From cd9f8e64c232eeb1247950007ee95de00b89ba7a Mon Sep 17 00:00:00 2001 From: Henrik Kretzschmar Date: Sun, 18 Jan 2009 10:40:24 +0100 Subject: sound: Remove removed OSS kernel parameters from doc Remove removed OSS kernel parameters from kernel-parameters.txt Remove the kernel parameters from the OSS drivers of the chips es1371 (removed 10-2007/2.6.24) and cs4232 (removed 02-2008/2.6.25) from the kernel parameters documentation. Signed-off-by: Henrik Kretzschmar Signed-off-by: Takashi Iwai --- Documentation/kernel-parameters.txt | 7 ------- 1 file changed, 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 8511d35..d8362cf 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -577,9 +577,6 @@ and is between 256 and 4096 characters. It is defined in the file a memory unit (amount[KMG]). See also Documentation/kdump/kdump.txt for a example. - cs4232= [HW,OSS] - Format: ,,,,, - cs89x0_dma= [HW,NET] Format: @@ -732,10 +729,6 @@ and is between 256 and 4096 characters. It is defined in the file Default value is 0. Value can be changed at runtime via /selinux/enforce. - es1371= [HW,OSS] - Format: ,[,[]] - See also header of sound/oss/es1371.c. - ether= [HW,NET] Ethernet cards parameters This option is obsoleted by the "netdev=" option, which has equivalent usage. See its documentation for details. -- cgit v1.1 From 32ed3f4640631ab7a4c0bc0f1463cf019d510341 Mon Sep 17 00:00:00 2001 From: Matthew Ranostay Date: Thu, 22 Jan 2009 20:53:29 -0500 Subject: ALSA: hda: Add STAC92HD83XXX_PWR_REF quirk Some revisions of the 92hd8xxx codec's not supporting port power downs in which the using of it causes capture and also randomly playback streams to not function at all. Thus by disabling it by default and adding a option to enable it manually will fix all issue on current and future revisions. Signed-off-by: Matthew Ranostay Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 64eb110..0f5d26b 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -349,6 +349,7 @@ STAC92HD73* STAC92HD83* =========== ref Reference board + mic-ref Reference board with power managment for ports STAC9872 ======== -- cgit v1.1 From e955281cd6afef7ad7ea11cae0ca71d78a7b2b2b Mon Sep 17 00:00:00 2001 From: Jesse Barnes Date: Mon, 26 Jan 2009 12:19:23 -0800 Subject: networking: document "nc" in addition to "netcat" in netconsole.txt It always annoyed me that the netconsole documentation didn't give me the correct command for my distro. Update it with a command line that actually works on my Fedora install. Signed-off-by: Jesse Barnes Signed-off-by: Randy Dunlap Signed-off-by: Matt Mackall Signed-off-by: David S. Miller --- Documentation/networking/netconsole.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt index 3c2f2b3..8d02207 100644 --- a/Documentation/networking/netconsole.txt +++ b/Documentation/networking/netconsole.txt @@ -51,7 +51,8 @@ Built-in netconsole starts immediately after the TCP stack is initialized and attempts to bring up the supplied dev at the supplied address. -The remote host can run either 'netcat -u -l -p ' or syslogd. +The remote host can run either 'netcat -u -l -p ', +'nc -l -u ' or syslogd. Dynamic reconfiguration: ======================== -- cgit v1.1 From 096abd77038a2ff74efd194d074eadcde80fb97d Mon Sep 17 00:00:00 2001 From: James Lentini Date: Thu, 8 Jan 2009 13:13:26 -0500 Subject: update port number in NFS/RDMA documentation Update the NFS/RDMA documentation to use the new port number assigned by IANA. Signed-off-by: James Lentini Signed-off-by: J. Bruce Fields --- Documentation/filesystems/nfs-rdma.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs-rdma.txt index 44bd766..85eaead 100644 --- a/Documentation/filesystems/nfs-rdma.txt +++ b/Documentation/filesystems/nfs-rdma.txt @@ -251,7 +251,7 @@ NFS/RDMA Setup Instruct the server to listen on the RDMA transport: - $ echo rdma 2050 > /proc/fs/nfsd/portlist + $ echo rdma 20049 > /proc/fs/nfsd/portlist - On the client system @@ -263,7 +263,7 @@ NFS/RDMA Setup Regardless of how the client was built (module or built-in), use this command to mount the NFS/RDMA server: - $ mount -o rdma,port=2050 :/ /mnt + $ mount -o rdma,port=20049 :/ /mnt To verify that the mount is using RDMA, run "cat /proc/mounts" and check the "proto" field for the given mount. -- cgit v1.1 From 720893fd5fb6de1f752f816a89e630f08ae8b20a Mon Sep 17 00:00:00 2001 From: Tsugikazu Shibata Date: Fri, 23 Jan 2009 09:59:50 +0900 Subject: Sync patch for jp_JP/stable_kernel_rules.txt Updated jp_JP/stable_kernel_rules.txt due to changes in the main version of the file. Also, this patch is already reviewed by Japanese translation community called JF. Signed-off-by: Tsugikazu Shibata Signed-off-by: Greg Kroah-Hartman --- Documentation/ja_JP/stable_kernel_rules.txt | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ja_JP/stable_kernel_rules.txt b/Documentation/ja_JP/stable_kernel_rules.txt index b3ffe87..1426583 100644 --- a/Documentation/ja_JP/stable_kernel_rules.txt +++ b/Documentation/ja_JP/stable_kernel_rules.txt @@ -12,11 +12,11 @@ file at first. ================================== これは、 -linux-2.6.24/Documentation/stable_kernel_rules.txt +linux-2.6.29/Documentation/stable_kernel_rules.txt の和訳です。 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > -翻訳日： 2007/12/30 +翻訳日： 2009/1/14 翻訳者： Tsugikazu Shibata 校正者： 武井伸光さん、 かねこさん (Seiji Kaneko) @@ -38,12 +38,15 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt - ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という ようなものを修正しなければならない。短く言えば、重大な問題。 + - 新しい device ID とクオークも受け入れられる。 - どのように競合状態が発生するかの説明も一緒に書かれていない限り、 "理論的には競合状態になる"ようなものは不可。 - いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー ンアップなど) - - 対応するサブシステムメンテナが受け入れたものでなければならない。 - Documentation/SubmittingPatches の規則に従ったものでなければならない。 + - パッチ自体か同等の修正が Linus のツリーに既に存在しなければならない。 +　 Linus のツリーでのコミットID を -stable へのパッチ投稿の際に引用す + ること。 -stable ツリーにパッチを送付する手続き- @@ -52,8 +55,10 @@ linux-2.6.24/Documentation/stable_kernel_rules.txt - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合 には NAK を受け取る。この反応は開発者たちのスケジュールによって、数 日かかる場合がある。 - - もし受け取られたら、パッチは他の開発者たちのレビューのために - -stable キューに追加される。 + - もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの + メンテナーによるレビューのために -stable キューに追加される。 + - パッチに stable@kernel.org のアドレスが付加されているときには、それ + が Linus のツリーに入る時に自動的に stable チームに email される。 - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ きではなく、代わりに security@kernel.org のアドレスに送られる。 -- cgit v1.1 From 6a1b699678c8c0d45f88a37b32358a9e82bef6bb Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Wed, 7 Jan 2009 00:12:37 +0100 Subject: UIO: Add missing documentation of features added recently MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The following features were added to the UIO framework in the near past: * Generic drivers for platform devices (uio_pdrv, uio_pdrv_genirq) * an "offset" sysfs attribute for memory mappings Unfortunately, all this went in without documentation (won't happen again...) This patch updates UIO documentation. Signed-off-by: Hans J. Koch Acked-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman --- Documentation/DocBook/uio-howto.tmpl | 88 ++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index b787e47..52e1b79 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -42,6 +42,12 @@ GPL version 2. + 0.7 + 2008-12-23 + hjk + Added generic platform drivers and offset attribute. + + 0.6 2008-12-05 hjk @@ -312,6 +318,16 @@ interested in translating it, please email me pointed to by addr. + + + offset: The offset, in bytes, that has to be + added to the pointer returned by mmap() to get + to the actual device memory. This is important if the device's memory + is not page aligned. Remember that pointers returned by + mmap() are always page aligned, so it is good + style to always add this offset. + + @@ -594,6 +610,78 @@ framework to set up sysfs files for this region. Simply leave it alone. + +Using uio_pdrv for platform devices + + In many cases, UIO drivers for platform devices can be handled in a + generic way. In the same place where you define your + struct platform_device, you simply also implement + your interrupt handler and fill your + struct uio_info. A pointer to this + struct uio_info is then used as + platform_data for your platform device. + + + You also need to set up an array of struct resource + containing addresses and sizes of your memory mappings. This + information is passed to the driver using the + .resource and .num_resources + elements of struct platform_device. + + + You now have to set the .name element of + struct platform_device to + "uio_pdrv" to use the generic UIO platform device + driver. This driver will fill the mem[] array + according to the resources given, and register the device. + + + The advantage of this approach is that you only have to edit a file + you need to edit anyway. You do not have to create an extra driver. + + + + +Using uio_pdrv_genirq for platform devices + + Especially in embedded devices, you frequently find chips where the + irq pin is tied to its own dedicated interrupt line. In such cases, + where you can be really sure the interrupt is not shared, we can take + the concept of uio_pdrv one step further and use a + generic interrupt handler. That's what + uio_pdrv_genirq does. + + + The setup for this driver is the same as described above for + uio_pdrv, except that you do not implement an + interrupt handler. The .handler element of + struct uio_info must remain + NULL. The .irq_flags element + must not contain IRQF_SHARED. + + + You will set the .name element of + struct platform_device to + "uio_pdrv_genirq" to use this driver. + + + The generic interrupt handler of uio_pdrv_genirq + will simply disable the interrupt line using + disable_irq_nosync(). After doing its work, + userspace can reenable the interrupt by writing 0x00000001 to the UIO + device file. The driver already implements an + irq_control() to make this possible, you must not + implement your own. + + + Using uio_pdrv_genirq not only saves a few lines of + interrupt handler code. You also do not need to know anything about + the chip's internal registers to create the kernel part of the driver. + All you need to know is the irq number of the pin the chip is + connected to. + + + -- cgit v1.1 From f90c3c0bdd7a3f16eecf1b077f5e031c44ddb605 Mon Sep 17 00:00:00 2001 From: Simon Harrison Date: Fri, 9 Jan 2009 09:07:07 -0300 Subject: V4L/DVB (10210): Fix a bug on v4lgrab.c v4lgrab breaks the fputc macro on some systems, because of #defined FILE. Also, I also added comments because it was not at all clear that to get gspca cameras to work with this application you need v4l1compat. Signed-off-by: Simon Harrison Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4lgrab.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4lgrab.c b/Documentation/video4linux/v4lgrab.c index 079b628..d6e70be 100644 --- a/Documentation/video4linux/v4lgrab.c +++ b/Documentation/video4linux/v4lgrab.c @@ -4,12 +4,21 @@ * * Compile with: * gcc -s -Wall -Wstrict-prototypes v4lgrab.c -o v4lgrab - * Use as: - * v4lgrab >image.ppm + * Use as: + * v4lgrab >image.ppm * * Copyright (C) 1998-05-03, Phil Blundell - * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c - * with minor modifications (Dave Forrest, drf5n@virginia.edu). + * Copied from http://www.tazenda.demon.co.uk/phil/vgrabber.c + * with minor modifications (Dave Forrest, drf5n@virginia.edu). + * + * + * For some cameras you may need to pre-load libv4l to perform + * the necessary decompression, e.g.: + * + * export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so + * ./v4lgrab >image.ppm + * + * see http://hansdegoede.livejournal.com/3636.html for details. * */ @@ -24,7 +33,7 @@ #include #include -#define FILE "/dev/video0" +#define VIDEO_DEV "/dev/video0" /* Stole this from tvset.c */ @@ -90,7 +99,7 @@ int get_brightness_adj(unsigned char *image, long size, int *brightness) { int main(int argc, char ** argv) { - int fd = open(FILE, O_RDONLY), f; + int fd = open(VIDEO_DEV, O_RDONLY), f; struct video_capability cap; struct video_window win; struct video_picture vpic; @@ -100,13 +109,13 @@ int main(int argc, char ** argv) unsigned int i, src_depth; if (fd < 0) { - perror(FILE); + perror(VIDEO_DEV); exit(1); } if (ioctl(fd, VIDIOCGCAP, &cap) < 0) { perror("VIDIOGCAP"); - fprintf(stderr, "(" FILE " not a video4linux device?)\n"); + fprintf(stderr, "(" VIDEO_DEV " not a video4linux device?)\n"); close(fd); exit(1); } -- cgit v1.1 From 27ad27993313312a4ad0047d0a944c425cd511a5 Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Thu, 29 Jan 2009 16:34:30 +0200 Subject: UBIFS: remove fast unmounting This UBIFS feature has never worked properly, and it was a mistake to add it because we simply have no use-cases. So, lets still accept the fast_unmount mount option, but ignore it. This does not change much, because UBIFS commit in sync_fs anyway, and sync_fs is called while unmounting. Signed-off-by: Artem Bityutskiy --- Documentation/filesystems/ubifs.txt | 7 ------- 1 file changed, 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt index 84da2a4..12fedb7 100644 --- a/Documentation/filesystems/ubifs.txt +++ b/Documentation/filesystems/ubifs.txt @@ -79,13 +79,6 @@ Mount options (*) == default. -norm_unmount (*) commit on unmount; the journal is committed - when the file-system is unmounted so that the - next mount does not have to replay the journal - and it becomes very fast; -fast_unmount do not commit on unmount; this option makes - unmount faster, but the next mount slower - because of the need to replay the journal. bulk_read read more in one go to take advantage of flash media that read faster sequentially no_bulk_read (*) do not bulk-read -- cgit v1.1 From 58092d1e0a896eb1d9163d58f93df7ed704fa8e1 Mon Sep 17 00:00:00 2001 From: Stephen Hemminger Date: Thu, 29 Jan 2009 16:16:31 -0800 Subject: net: update documentation ip aliases This documentation is old. Add a short note to describe why aliases are no long necessary, and remove the old contact/edit info. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller --- Documentation/networking/alias.txt | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/alias.txt b/Documentation/networking/alias.txt index cd12c2f..85046f5 100644 --- a/Documentation/networking/alias.txt +++ b/Documentation/networking/alias.txt @@ -2,13 +2,13 @@ IP-Aliasing: ============ -IP-aliases are additional IP-addresses/masks hooked up to a base -interface by adding a colon and a string when running ifconfig. -This string is usually numeric, but this is not a must. - -IP-Aliases are avail if CONFIG_INET (`standard' IPv4 networking) -is configured in the kernel. +IP-aliases are an obsolete way to manage multiple IP-addresses/masks +per interface. Newer tools such as iproute2 support multiple +address/prefixes per interface, but aliases are still supported +for backwards compatibility. +An alias is formed by adding a colon and a string when running ifconfig. +This string is usually numeric, but this is not a must. o Alias creation. Alias creation is done by 'magic' interface naming: eg. to create a @@ -38,16 +38,3 @@ o Relationship with main device If the base device is shut down the added aliases will be deleted too. - - -Contact -------- -Please finger or e-mail me: - Juan Jose Ciarlante - -Updated by Erik Schoenfelder - -; local variables: -; mode: indented-text -; mode: auto-fill -; end: -- cgit v1.1 From b44d49ab0954accefba4c71274ab58abe1c25c52 Mon Sep 17 00:00:00 2001 From: Tim 'mithro' Ansell Date: Thu, 22 Jan 2009 15:06:41 +1100 Subject: lguest: disable the FORTIFY for lguest. Makes all the warnings go away when compiling lguest on Ubuntu on Intrepid or greater. Signed-off-by: Timothy R Ansell Signed-off-by: Rusty Russell --- Documentation/lguest/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/lguest/Makefile b/Documentation/lguest/Makefile index 725eef8..1f4f9e8 100644 --- a/Documentation/lguest/Makefile +++ b/Documentation/lguest/Makefile @@ -1,5 +1,5 @@ # This creates the demonstration utility "lguest" which runs a Linux guest. -CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include +CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE LDLIBS:=-lz all: lguest -- cgit v1.1 From 9e9e3cbc62da43c66e894d5a61fa08b427e25202 Mon Sep 17 00:00:00 2001 From: Evgeniy Polyakov Date: Thu, 29 Jan 2009 14:25:09 -0800 Subject: mm: OOM documentation update Signed-off-by: Evgeniy Polyakov Acked-by: David Rientjes Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index bbebc3a..a87be42 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -2027,6 +2027,34 @@ increase the likelihood of this process being killed by the oom-killer. Valid values are in the range -16 to +15, plus the special value -17, which disables oom-killing altogether for this process. +The process to be killed in an out-of-memory situation is selected among all others +based on its badness score. This value equals the original memory size of the process +and is then updated according to its CPU time (utime + stime) and the +run time (uptime - start time). The longer it runs the smaller is the score. +Badness score is divided by the square root of the CPU time and then by +the double square root of the run time. + +Swapped out tasks are killed first. Half of each child's memory size is added to +the parent's score if they do not share the same memory. Thus forking servers +are the prime candidates to be killed. Having only one 'hungry' child will make +parent less preferable than the child. + +/proc//oom_score shows process' current badness score. + +The following heuristics are then applied: + * if the task was reniced, its score doubles + * superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE + or CAP_SYS_RAWIO) have their score divided by 4 + * if oom condition happened in one cpuset and checked task does not belong + to it, its score is divided by 8 + * the resulting score is multiplied by two to the power of oom_adj, i.e. + points <<= oom_adj when it is positive and + points >>= -(oom_adj) otherwise + +The task with the highest badness score is then selected and its children +are killed, process itself will be killed in an OOM situation when it does +not have children or some of them disabled oom like described above. + 2.13 /proc//oom_score - Display current oom-killer score ------------------------------------------------------------- -- cgit v1.1 From 8d50d369d1b3ccc4d96ce01f62146173ee7064ca Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki Date: Thu, 29 Jan 2009 14:25:14 -0800 Subject: memcg: update document to mention that swapoff should be tested Considering the recently found problem "memcg: fix refcnt handling at swapoff", it's better to mention swapoff behavior in the memcg_test document. Signed-off-by: KAMEZAWA Hiroyuki Acked-by: Balbir Singh Cc: Li Zefan Cc: Daisuke Nishimura Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/memcg_test.txt | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt index 19533f9..523a9c1 100644 --- a/Documentation/cgroups/memcg_test.txt +++ b/Documentation/cgroups/memcg_test.txt @@ -1,6 +1,6 @@ Memory Resource Controller(Memcg) Implementation Memo. -Last Updated: 2008/12/15 -Base Kernel Version: based on 2.6.28-rc8-mm. +Last Updated: 2009/1/19 +Base Kernel Version: based on 2.6.29-rc2. Because VM is getting complex (one of reasons is memcg...), memcg's behavior is complex. This is a document for memcg's internal behavior. @@ -340,3 +340,23 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. # mount -t cgroup none /cgroup -t cpuset,memory,cpu,devices and do task move, mkdir, rmdir etc...under this. + + 9.7 swapoff. + Besides management of swap is one of complicated parts of memcg, + call path of swap-in at swapoff is not same as usual swap-in path.. + It's worth to be tested explicitly. + + For example, test like following is good. + (Shell-A) + # mount -t cgroup none /cgroup -t memory + # mkdir /cgroup/test + # echo 40M > /cgroup/test/memory.limit_in_bytes + # echo 0 > /cgroup/test/tasks + Run malloc(100M) program under this. You'll see 60M of swaps. + (Shell-B) + # move all tasks in /cgroup/test to /cgroup + # /sbin/swapoff -a + # rmdir /test/cgroup + # kill malloc task. + + Of course, tmpfs v.s. swapoff test should be tested, too. -- cgit v1.1 From 5872fb94f85d2e4fdef94657bd14e1a492df9825 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Thu, 29 Jan 2009 16:28:02 -0800 Subject: Documentation: move DMA-mapping.txt to Doc/PCI/ Move DMA-mapping.txt to Documentation/PCI/. DMA-mapping.txt was supposed to be moved from Documentation/ to Documentation/PCI/. The 00-INDEX files in those two directories were updated, along with a few other text files, but the file itself somehow escaped being moved, so move it and update more text files and source files with its new location. Signed-off-by: Randy Dunlap Acked-by: Greg Kroah-Hartman cc: Jesse Barnes Signed-off-by: Linus Torvalds --- Documentation/DMA-API.txt | 2 +- Documentation/IO-mapping.txt | 4 ++-- Documentation/block/biodoc.txt | 5 +++-- Documentation/usb/dma.txt | 11 ++++++----- 4 files changed, 12 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 5244169..2a3fcc55 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -5,7 +5,7 @@ This document describes the DMA API. For a more gentle introduction phrased in terms of the pci_ equivalents (and actual examples) see -DMA-mapping.txt +Documentation/PCI/PCI-DMA-mapping.txt. This API is split into two pieces. Part I describes the API and the corresponding pci_ API. Part II describes the extensions to the API diff --git a/Documentation/IO-mapping.txt b/Documentation/IO-mapping.txt index 86edb61..78a4406 100644 --- a/Documentation/IO-mapping.txt +++ b/Documentation/IO-mapping.txt @@ -1,6 +1,6 @@ [ NOTE: The virt_to_bus() and bus_to_virt() functions have been - superseded by the functionality provided by the PCI DMA - interface (see Documentation/DMA-mapping.txt). They continue + superseded by the functionality provided by the PCI DMA interface + (see Documentation/PCI/PCI-DMA-mapping.txt). They continue to be documented below for historical purposes, but new code must not use them. --davidm 00/12/12 ] diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 3c5434c..5d2480d 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -186,8 +186,9 @@ a virtual address mapping (unlike the earlier scheme of virtual address do not have a corresponding kernel virtual address space mapping) and low-memory pages. -Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA -aspects and mapping of scatter gather lists, and support for 64 bit PCI. +Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion +on PCI high mem DMA aspects and mapping of scatter gather lists, and support +for 64 bit PCI. Special handling is required only for cases where i/o needs to happen on pages at physical memory addresses beyond what the device can support. In these diff --git a/Documentation/usb/dma.txt b/Documentation/usb/dma.txt index e8b50b7..cfdcd16 100644 --- a/Documentation/usb/dma.txt +++ b/Documentation/usb/dma.txt @@ -6,8 +6,9 @@ in the kernel usb programming guide (kerneldoc, from the source code). API OVERVIEW The big picture is that USB drivers can continue to ignore most DMA issues, -though they still must provide DMA-ready buffers (see DMA-mapping.txt). -That's how they've worked through the 2.4 (and earlier) kernels. +though they still must provide DMA-ready buffers (see +Documentation/PCI/PCI-DMA-mapping.txt). That's how they've worked through +the 2.4 (and earlier) kernels. OR: they can now be DMA-aware. @@ -62,8 +63,8 @@ and effects like cache-trashing can impose subtle penalties. force a consistent memory access ordering by using memory barriers. It's not using a streaming DMA mapping, so it's good for small transfers on systems where the I/O would otherwise thrash an IOMMU mapping. (See - Documentation/DMA-mapping.txt for definitions of "coherent" and "streaming" - DMA mappings.) + Documentation/PCI/PCI-DMA-mapping.txt for definitions of "coherent" and + "streaming" DMA mappings.) Asking for 1/Nth of a page (as well as asking for N pages) is reasonably space-efficient. @@ -93,7 +94,7 @@ WORKING WITH EXISTING BUFFERS Existing buffers aren't usable for DMA without first being mapped into the DMA address space of the device. However, most buffers passed to your driver can safely be used with such DMA mapping. (See the first section -of DMA-mapping.txt, titled "What memory is DMA-able?") +of Documentation/PCI/PCI-DMA-mapping.txt, titled "What memory is DMA-able?") - When you're using scatterlists, you can map everything at once. On some systems, this kicks in an IOMMU and turns the scatterlists into single -- cgit v1.1 From 0acbc6c651911dc9ffb4f59b34306bc1ccb751e5 Mon Sep 17 00:00:00 2001 From: Teemu Likonen Date: Thu, 29 Jan 2009 16:28:16 -0800 Subject: Documentation: update CodingStyle tips for Emacs users With the previous Emacs tips example the kernel style was made available for files in the kernel-tree only. This patch updates the tip to add a separate cc-mode indent style ("linux-tabs-only"). This makes it easy to switch between different indent styles and also makes the kernel style easily available for any filetype mode (c++, awk, ...) that is managed by the Emacs cc-mode. Signed-off-by: Teemu Likonen Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/CodingStyle | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 1875e50..7b5762e 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -483,6 +483,16 @@ values. To do the latter, you can stick the following in your .emacs file: (* (max steps 1) c-basic-offset))) +(add-hook 'c-mode-common-hook + (lambda () + ;; Add kernel style + (c-add-style + "linux-tabs-only" + '("linux" (c-offsets-alist + (arglist-cont-nonempty + c-lineup-gcc-asm-reg + c-lineup-arglist-tabs-only)))))) + (add-hook 'c-mode-hook (lambda () (let ((filename (buffer-file-name))) @@ -490,10 +500,7 @@ values. To do the latter, you can stick the following in your .emacs file: (when (and filename (string-match "~/src/linux-trees" filename)) (setq indent-tabs-mode t) - (c-set-style "linux") - (c-set-offset 'arglist-cont-nonempty - '(c-lineup-gcc-asm-reg - c-lineup-arglist-tabs-only)))))) + (c-set-style "linux-tabs-only"))))) This will make emacs go better with the kernel coding style for C files below ~/src/linux-trees. -- cgit v1.1 From 70221395ba980392ba98c1d78f6c9f77be03df9e Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Thu, 29 Jan 2009 16:28:28 -0800 Subject: fix emacs indenting howto filename expansion I don't think emacs understands tilde expansion, so use "expand-file-name" to do that. Signed-off-by: Dan Carpenter Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/CodingStyle | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7b5762e..72968cd 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -498,7 +498,8 @@ values. To do the latter, you can stick the following in your .emacs file: (let ((filename (buffer-file-name))) ;; Enable kernel mode for the appropriate files (when (and filename - (string-match "~/src/linux-trees" filename)) + (string-match (expand-file-name "~/src/linux-trees") + filename)) (setq indent-tabs-mode t) (c-set-style "linux-tabs-only"))))) -- cgit v1.1 From 242f45da5b7bf63c50f1f18301750712e7885dd6 Mon Sep 17 00:00:00 2001 From: Bill Nottingham Date: Thu, 29 Jan 2009 16:28:40 -0800 Subject: Documentation/Changes: add required versions for new filesystems btrfs requires version 0.18 of its tools, and squashfs requires 4.0. ext3 should use and ext4 requires v1.41.4 of e2fsprogs. Signed-off-by: Bill Nottingham Signed-off-by: Randy Dunlap cc: Ted Tso Signed-off-by: Linus Torvalds --- Documentation/Changes | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/Changes b/Documentation/Changes index cb2b141..b95082b 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -33,10 +33,12 @@ o Gnu make 3.79.1 # make --version o binutils 2.12 # ld -v o util-linux 2.10o # fdformat --version o module-init-tools 0.9.10 # depmod -V -o e2fsprogs 1.29 # tune2fs +o e2fsprogs 1.41.4 # e2fsck -V o jfsutils 1.1.3 # fsck.jfs -V o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs o xfsprogs 2.6.0 # xfs_db -V +o squashfs-tools 4.0 # mksquashfs -version +o btrfs-progs 0.18 # btrfsck o pcmciautils 004 # pccardctl -V o quota-tools 3.09 # quota -V o PPP 2.4.0 # pppd --version -- cgit v1.1 From 7598909e3ee2a08726276d6415b69dadb52d0d76 Mon Sep 17 00:00:00 2001 From: Nikanth Karthikesan Date: Tue, 27 Jan 2009 09:29:24 +0100 Subject: Mark mandatory elevator functions in the biodoc.txt biodoc.txt mentions that elevator functions marked with * are mandatory, but no function is marked with *. Mark the 3 functions which should be implemented by any io scheduler. Signed-off-by: Nikanth Karthikesan Signed-off-by: Jens Axboe --- Documentation/block/biodoc.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 5d2480d..ecad6ee 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -954,14 +954,14 @@ elevator_allow_merge_fn called whenever the block layer determines results in some sort of conflict internally, this hook allows it to do that. -elevator_dispatch_fn fills the dispatch queue with ready requests. +elevator_dispatch_fn* fills the dispatch queue with ready requests. I/O schedulers are free to postpone requests by not filling the dispatch queue unless @force is non-zero. Once dispatched, I/O schedulers are not allowed to manipulate the requests - they belong to generic dispatch queue. -elevator_add_req_fn called to add a new request into the scheduler +elevator_add_req_fn* called to add a new request into the scheduler elevator_queue_empty_fn returns true if the merge queue is empty. Drivers shouldn't use this, but rather check @@ -991,7 +991,7 @@ elevator_activate_req_fn Called when device driver first sees a request. elevator_deactivate_req_fn Called when device driver decides to delay a request by requeueing it. -elevator_init_fn +elevator_init_fn* elevator_exit_fn Allocate and free any elevator specific storage for a queue. -- cgit v1.1 From 34df9f69a4e298e2e8b939d8a7cc0d55846ba544 Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Fri, 30 Jan 2009 08:23:33 -0700 Subject: powerpc/5200: update device tree binding documentation This patch updates the mpc5200 binding documentation to match actual usage conventions, to remove incorrect information, and to remove topics which are more thoroughly described elsewhere. Signed-off-by: Grant Likely Reviewed-by: Wolfram Sang --- Documentation/powerpc/dts-bindings/fsl/mpc5200.txt | 180 +++++++++++++ .../powerpc/mpc52xx-device-tree-bindings.txt | 277 --------------------- 2 files changed, 180 insertions(+), 277 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt delete mode 100644 Documentation/powerpc/mpc52xx-device-tree-bindings.txt (limited to 'Documentation') diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt new file mode 100644 index 0000000..8447fd7 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt @@ -0,0 +1,180 @@ +MPC5200 Device Tree Bindings +---------------------------- + +(c) 2006-2009 Secret Lab Technologies Ltd +Grant Likely + +Naming conventions +------------------ +For mpc5200 on-chip devices, the format for each compatible value is +-[-]. The OS should be able to match a device driver +to the device based solely on the compatible value. If two drivers +match on the compatible list; the 'most compatible' driver should be +selected. + +The split between the MPC5200 and the MPC5200B leaves a bit of a +conundrum. How should the compatible property be set up to provide +maximum compatibility information; but still accurately describe the +chip? For the MPC5200; the answer is easy. Most of the SoC devices +originally appeared on the MPC5200. Since they didn't exist anywhere +else; the 5200 compatible properties will contain only one item; +"fsl,mpc5200-". + +The 5200B is almost the same as the 5200, but not quite. It fixes +silicon bugs and it adds a small number of enhancements. Most of the +devices either provide exactly the same interface as on the 5200. A few +devices have extra functions but still have a backwards compatible mode. +To express this information as completely as possible, 5200B device trees +should have two items in the compatible list: + compatible = "fsl,mpc5200b-","fsl,mpc5200-"; + +It is *strongly* recommended that 5200B device trees follow this convention +(instead of only listing the base mpc5200 item). + +ie. ethernet on mpc5200: compatible = "fsl,mpc5200-fec"; + ethernet on mpc5200b: compatible = "fsl,mpc5200b-fec", "fsl,mpc5200-fec"; + +Modal devices, like PSCs, also append the configured function to the +end of the compatible field. ie. A PSC in i2s mode would specify +"fsl,mpc5200-psc-i2s", not "fsl,mpc5200-i2s". This convention is chosen to +avoid naming conflicts with non-psc devices providing the same +function. For example, "fsl,mpc5200-spi" and "fsl,mpc5200-psc-spi" describe +the mpc5200 simple spi device and a PSC spi mode respectively. + +At the time of writing, exact chip may be either 'fsl,mpc5200' or +'fsl,mpc5200b'. + +The soc node +------------ +This node describes the on chip SOC peripherals. Every mpc5200 based +board will have this node, and as such there is a common naming +convention for SOC devices. + +Required properties: +name description +---- ----------- +ranges Memory range of the internal memory mapped registers. + Should be <0 [baseaddr] 0xc000> +reg Should be <[baseaddr] 0x100> +compatible mpc5200: "fsl,mpc5200-immr" + mpc5200b: "fsl,mpc5200b-immr" +system-frequency 'fsystem' frequency in Hz; XLB, IPB, USB and PCI + clocks are derived from the fsystem clock. +bus-frequency IPB bus frequency in Hz. Clock rate + used by most of the soc devices. + +soc child nodes +--------------- +Any on chip SOC devices available to Linux must appear as soc5200 child nodes. + +Note: The tables below show the value for the mpc5200. A mpc5200b device +tree should use the "fsl,mpc5200b-","fsl,mpc5200-" form. + +Required soc5200 child nodes: +name compatible Description +---- ---------- ----------- +cdm@ fsl,mpc5200-cdm Clock Distribution +interrupt-controller@ fsl,mpc5200-pic need an interrupt + controller to boot +bestcomm@ fsl,mpc5200-bestcomm Bestcomm DMA controller + +Recommended soc5200 child nodes; populate as needed for your board +name compatible Description +---- ---------- ----------- +timer@ fsl,mpc5200-gpt General purpose timers +gpio@ fsl,mpc5200-gpio MPC5200 simple gpio controller +gpio@ fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio controller +rtc@ fsl,mpc5200-rtc Real time clock +mscan@ fsl,mpc5200-mscan CAN bus controller +pci@ fsl,mpc5200-pci PCI bridge +serial@ fsl,mpc5200-psc-uart PSC in serial mode +i2s@ fsl,mpc5200-psc-i2s PSC in i2s mode +ac97@ fsl,mpc5200-psc-ac97 PSC in ac97 mode +spi@ fsl,mpc5200-psc-spi PSC in spi mode +irda@ fsl,mpc5200-psc-irda PSC in IrDA mode +spi@ fsl,mpc5200-spi MPC5200 spi device +ethernet@ fsl,mpc5200-fec MPC5200 ethernet device +ata@ fsl,mpc5200-ata IDE ATA interface +i2c@ fsl,mpc5200-i2c I2C controller +usb@ fsl,mpc5200-ohci,ohci-be USB controller +xlb@ fsl,mpc5200-xlb XLB arbitrator + +fsl,mpc5200-gpt nodes +--------------------- +On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board +design supports the internal wdt, then the device node for GPT0 should +include the empty property 'fsl,has-wdt'. + +An mpc5200-gpt can be used as a single line GPIO controller. To do so, +add the following properties to the gpt node: + gpio-controller; + #gpio-cells = <2>; +When referencing the GPIO line from another node, the first cell must always +be zero and the second cell represents the gpio flags and described in the +gpio device tree binding. + +An mpc5200-gpt can be used as a single line edge sensitive interrupt +controller. To do so, add the following properties to the gpt node: + interrupt-controller; + #interrupt-cells = <1>; +When referencing the IRQ line from another node, the cell represents the +sense mode; 1 for edge rising, 2 for edge falling. + +fsl,mpc5200-psc nodes +--------------------- +The PSCs should include a cell-index which is the index of the PSC in +hardware. cell-index is used to determine which shared SoC registers to +use when setting up PSC clocking. cell-index number starts at '0'. ie: + PSC1 has 'cell-index = <0>' + PSC4 has 'cell-index = <3>' + +PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in +i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the +compatible field. + + +fsl,mpc5200-gpio and fsl,mpc5200-gpio-wkup nodes +------------------------------------------------ +Each GPIO controller node should have the empty property gpio-controller and +#gpio-cells set to 2. First cell is the GPIO number which is interpreted +according to the bit numbers in the GPIO control registers. The second cell +is for flags which is currently unused. + +fsl,mpc5200-fec nodes +--------------------- +The FEC node can specify one of the following properties to configure +the MII link: +- fsl,7-wire-mode - An empty property that specifies the link uses 7-wire + mode instead of MII +- current-speed - Specifies that the MII should be configured for a fixed + speed. This property should contain two cells. The + first cell specifies the speed in Mbps and the second + should be '0' for half duplex and '1' for full duplex +- phy-handle - Contains a phandle to an Ethernet PHY. + +Interrupt controller (fsl,mpc5200-pic) node +------------------------------------------- +The mpc5200 pic binding splits hardware IRQ numbers into two levels. The +split reflects the layout of the PIC hardware itself, which groups +interrupts into one of three groups; CRIT, MAIN or PERP. Also, the +Bestcomm dma engine has it's own set of interrupt sources which are +cascaded off of peripheral interrupt 0, which the driver interprets as a +fourth group, SDMA. + +The interrupts property for device nodes using the mpc5200 pic consists +of three cells; + + L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3] + L2 := interrupt number; directly mapped from the value in the + "ICTL PerStat, MainStat, CritStat Encoded Register" + level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3] + +For external IRQs, use the following interrupt property values (how to +specify external interrupts is a frequently asked question): +External interrupts: + external irq0: interrupts = <0 0 n>; + external irq1: interrupts = <1 1 n>; + external irq2: interrupts = <1 2 n>; + external irq3: interrupts = <1 3 n>; +'n' is sense (0: level high, 1: edge rising, 2: edge falling 3: level low) + diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt deleted file mode 100644 index 6f12f1c..0000000 --- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt +++ /dev/null @@ -1,277 +0,0 @@ -MPC5200 Device Tree Bindings ----------------------------- - -(c) 2006-2007 Secret Lab Technologies Ltd -Grant Likely - -********** DRAFT *********** -* WARNING: Do not depend on the stability of these bindings just yet. -* The MPC5200 device tree conventions are still in flux -* Keep an eye on the linuxppc-dev mailing list for more details -********** DRAFT *********** - -I - Introduction -================ -Boards supported by the arch/powerpc architecture require device tree be -passed by the boot loader to the kernel at boot time. The device tree -describes what devices are present on the board and how they are -connected. The device tree can either be passed as a binary blob (as -described in Documentation/powerpc/booting-without-of.txt), or passed -by Open Firmware (IEEE 1275) compatible firmware using an OF compatible -client interface API. - -This document specifies the requirements on the device-tree for mpc5200 -based boards. These requirements are above and beyond the details -specified in either the Open Firmware spec or booting-without-of.txt - -All new mpc5200-based boards are expected to match this document. In -cases where this document is not sufficient to support a new board port, -this document should be updated as part of adding the new board support. - -II - Philosophy -=============== -The core of this document is naming convention. The whole point of -defining this convention is to reduce or eliminate the number of -special cases required to support a 5200 board. If all 5200 boards -follow the same convention, then generic 5200 support code will work -rather than coding special cases for each new board. - -This section tries to capture the thought process behind why the naming -convention is what it is. - -1. names ---------- -There is strong convention/requirements already established for children -of the root node. 'cpus' describes the processor cores, 'memory' -describes memory, and 'chosen' provides boot configuration. Other nodes -are added to describe devices attached to the processor local bus. - -Following convention already established with other system-on-chip -processors, 5200 device trees should use the name 'soc5200' for the -parent node of on chip devices, and the root node should be its parent. - -Child nodes are typically named after the configured function. ie. -the FEC node is named 'ethernet', and a PSC in uart mode is named 'serial'. - -2. device_type property ------------------------ -similar to the node name convention above; the device_type reflects the -configured function of a device. ie. 'serial' for a uart and 'spi' for -an spi controller. However, while node names *should* reflect the -configured function, device_type *must* match the configured function -exactly. - -3. compatible property ----------------------- -Since device_type isn't enough to match devices to drivers, there also -needs to be a naming convention for the compatible property. Compatible -is an list of device descriptions sorted from specific to generic. For -the mpc5200, the required format for each compatible value is --[-]. The OS should be able to match a device driver -to the device based solely on the compatible value. If two drivers -match on the compatible list; the 'most compatible' driver should be -selected. - -The split between the MPC5200 and the MPC5200B leaves a bit of a -conundrum. How should the compatible property be set up to provide -maximum compatibility information; but still accurately describe the -chip? For the MPC5200; the answer is easy. Most of the SoC devices -originally appeared on the MPC5200. Since they didn't exist anywhere -else; the 5200 compatible properties will contain only one item; -"mpc5200-". - -The 5200B is almost the same as the 5200, but not quite. It fixes -silicon bugs and it adds a small number of enhancements. Most of the -devices either provide exactly the same interface as on the 5200. A few -devices have extra functions but still have a backwards compatible mode. -To express this information as completely as possible, 5200B device trees -should have two items in the compatible list; -"mpc5200b-\0mpc5200-". It is *strongly* recommended -that 5200B device trees follow this convention (instead of only listing -the base mpc5200 item). - -If another chip appear on the market with one of the mpc5200 SoC -devices, then the compatible list should include mpc5200-. - -ie. ethernet on mpc5200: compatible = "mpc5200-ethernet" - ethernet on mpc5200b: compatible = "mpc5200b-ethernet\0mpc5200-ethernet" - -Modal devices, like PSCs, also append the configured function to the -end of the compatible field. ie. A PSC in i2s mode would specify -"mpc5200-psc-i2s", not "mpc5200-i2s". This convention is chosen to -avoid naming conflicts with non-psc devices providing the same -function. For example, "mpc5200-spi" and "mpc5200-psc-spi" describe -the mpc5200 simple spi device and a PSC spi mode respectively. - -If the soc device is more generic and present on other SOCs, the -compatible property can specify the more generic device type also. - -ie. mscan: compatible = "mpc5200-mscan\0fsl,mscan"; - -At the time of writing, exact chip may be either 'mpc5200' or -'mpc5200b'. - -Device drivers should always try to match as generically as possible. - -III - Structure -=============== -The device tree for an mpc5200 board follows the structure defined in -booting-without-of.txt with the following additional notes: - -0) the root node ----------------- -Typical root description node; see booting-without-of - -1) The cpus node ----------------- -The cpus node follows the basic layout described in booting-without-of. -The bus-frequency property holds the XLB bus frequency -The clock-frequency property holds the core frequency - -2) The memory node ------------------- -Typical memory description node; see booting-without-of. - -3) The soc5200 node -------------------- -This node describes the on chip SOC peripherals. Every mpc5200 based -board will have this node, and as such there is a common naming -convention for SOC devices. - -Required properties: -name type description ----- ---- ----------- -device_type string must be "soc" -ranges int should be <0 baseaddr baseaddr+10000> -reg int must be -compatible string mpc5200: "mpc5200-soc" - mpc5200b: "mpc5200b-soc\0mpc5200-soc" -system-frequency int Fsystem frequency; source of all - other clocks. -bus-frequency int IPB bus frequency in HZ. Clock rate - used by most of the soc devices. -#interrupt-cells int must be <3>. - -Recommended properties: -name type description ----- ---- ----------- -model string Exact model of the chip; - ie: model="fsl,mpc5200" -revision string Silicon revision of chip - ie: revision="M08A" - -The 'model' and 'revision' properties are *strongly* recommended. Having -them presence acts as a bit of a safety net for working around as yet -undiscovered bugs on one version of silicon. For example, device drivers -can use the model and revision properties to decide if a bug fix should -be turned on. - -4) soc5200 child nodes ----------------------- -Any on chip SOC devices available to Linux must appear as soc5200 child nodes. - -Note: The tables below show the value for the mpc5200. A mpc5200b device -tree should use the "mpc5200b-\0mpc5200- form. - -Required soc5200 child nodes: -name device_type compatible Description ----- ----------- ---------- ----------- -cdm@ cdm mpc5200-cmd Clock Distribution -pic@ interrupt-controller mpc5200-pic need an interrupt - controller to boot -bestcomm@ dma-controller mpc5200-bestcomm 5200 pic also requires - the bestcomm device - -Recommended soc5200 child nodes; populate as needed for your board -name device_type compatible Description ----- ----------- ---------- ----------- -gpt@ gpt fsl,mpc5200-gpt General purpose timers -gpt@ gpt fsl,mpc5200-gpt-gpio General purpose - timers in GPIO mode -gpio@ fsl,mpc5200-gpio MPC5200 simple gpio - controller -gpio@ fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio - controller -rtc@ rtc mpc5200-rtc Real time clock -mscan@ mscan mpc5200-mscan CAN bus controller -pci@ pci mpc5200-pci PCI bridge -serial@ serial mpc5200-psc-uart PSC in serial mode -i2s@ sound mpc5200-psc-i2s PSC in i2s mode -ac97@ sound mpc5200-psc-ac97 PSC in ac97 mode -spi@ spi mpc5200-psc-spi PSC in spi mode -irda@ irda mpc5200-psc-irda PSC in IrDA mode -spi@ spi mpc5200-spi MPC5200 spi device -ethernet@ network mpc5200-fec MPC5200 ethernet device -ata@ ata mpc5200-ata IDE ATA interface -i2c@ i2c mpc5200-i2c I2C controller -usb@ usb-ohci-be mpc5200-ohci,ohci-be USB controller -xlb@ xlb mpc5200-xlb XLB arbitrator - -Important child node properties -name type description ----- ---- ----------- -cell-index int When multiple devices are present, is the - index of the device in the hardware (ie. There - are 6 PSC on the 5200 numbered PSC1 to PSC6) - PSC1 has 'cell-index = <0>' - PSC4 has 'cell-index = <3>' - -5) General Purpose Timer nodes (child of soc5200 node) -On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board -design supports the internal wdt, then the device node for GPT0 should -include the empty property 'fsl,has-wdt'. - -6) PSC nodes (child of soc5200 node) -PSC nodes can define the optional 'port-number' property to force assignment -order of serial ports. For example, PSC5 might be physically connected to -the port labeled 'COM1' and PSC1 wired to 'COM1'. In this case, PSC5 would -have a "port-number = <0>" property, and PSC1 would have "port-number = <1>". - -PSC in i2s mode: The mpc5200 and mpc5200b PSCs are not compatible when in -i2s mode. An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the -compatible field. - -7) GPIO controller nodes -Each GPIO controller node should have the empty property gpio-controller and -#gpio-cells set to 2. First cell is the GPIO number which is interpreted -according to the bit numbers in the GPIO control registers. The second cell -is for flags which is currently unsused. - -8) FEC nodes -The FEC node can specify one of the following properties to configure -the MII link: -"fsl,7-wire-mode" - An empty property that specifies the link uses 7-wire - mode instead of MII -"current-speed" - Specifies that the MII should be configured for a fixed - speed. This property should contain two cells. The - first cell specifies the speed in Mbps and the second - should be '0' for half duplex and '1' for full duplex -"phy-handle" - Contains a phandle to an Ethernet PHY. - -IV - Extra Notes -================ - -1. Interrupt mapping --------------------- -The mpc5200 pic driver splits hardware IRQ numbers into two levels. The -split reflects the layout of the PIC hardware itself, which groups -interrupts into one of three groups; CRIT, MAIN or PERP. Also, the -Bestcomm dma engine has it's own set of interrupt sources which are -cascaded off of peripheral interrupt 0, which the driver interprets as a -fourth group, SDMA. - -The interrupts property for device nodes using the mpc5200 pic consists -of three cells; - - L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3] - L2 := interrupt number; directly mapped from the value in the - "ICTL PerStat, MainStat, CritStat Encoded Register" - level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3] - -2. Shared registers -------------------- -Some SoC devices share registers between them. ie. the i2c devices use -a single clock control register, and almost all device are affected by -the port_config register. Devices which need to manipulate shared regs -should look to the parent SoC node. The soc node is responsible -for arbitrating all shared register access. -- cgit v1.1 From cbb5901b904e122139e97c6f4caed9b1f13c3455 Mon Sep 17 00:00:00 2001 From: Jens Axboe Date: Mon, 2 Feb 2009 13:02:31 +0100 Subject: block: add text file detailing queue/ sysfs files Signed-off-by: Jens Axboe --- Documentation/block/queue-sysfs.txt | 63 +++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 Documentation/block/queue-sysfs.txt (limited to 'Documentation') diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt new file mode 100644 index 0000000..e164403 --- /dev/null +++ b/Documentation/block/queue-sysfs.txt @@ -0,0 +1,63 @@ +Queue sysfs files +================= + +This text file will detail the queue files that are located in the sysfs tree +for each block device. Note that stacked devices typically do not export +any settings, since their queue merely functions are a remapping target. +These files are the ones found in the /sys/block/xxx/queue/ directory. + +Files denoted with a RO postfix are readonly and the RW postfix means +read-write. + +hw_sector_size (RO) +------------------- +This is the hardware sector size of the device, in bytes. + +max_hw_sectors_kb (RO) +---------------------- +This is the maximum number of kilobytes supported in a single data transfer. + +max_sectors_kb (RW) +------------------- +This is the maximum number of kilobytes that the block layer will allow +for a filesystem request. Must be smaller than or equal to the maximum +size allowed by the hardware. + +nomerges (RW) +------------- +This enables the user to disable the lookup logic involved with IO merging +requests in the block layer. Merging may still occur through a direct +1-hit cache, since that comes for (almost) free. The IO scheduler will not +waste cycles doing tree/hash lookups for merges if nomerges is 1. Defaults +to 0, enabling all merges. + +nr_requests (RW) +---------------- +This controls how many requests may be allocated in the block layer for +read or write requests. Note that the total allocated number may be twice +this amount, since it applies only to reads or writes (not the accumulated +sum). + +read_ahead_kb (RW) +------------------ +Maximum number of kilobytes to read-ahead for filesystems on this block +device. + +rq_affinity (RW) +---------------- +If this option is enabled, the block layer will migrate request completions +to the CPU that originally submitted the request. For some workloads +this provides a significant reduction in CPU cycles due to caching effects. + +scheduler (RW) +-------------- +When read, this file will display the current and available IO schedulers +for this block device. The currently active IO scheduler will be enclosed +in [] brackets. Writing an IO scheduler name to this file will switch +control of this block device to that new IO scheduler. Note that writing +an IO scheduler name to this file will attempt to load that IO scheduler +module, if it isn't already present in the system. + + + +Jens Axboe , February 2009 -- cgit v1.1 From 62663ea8220366472fe20462831f2d69d7987439 Mon Sep 17 00:00:00 2001 From: Thomas Renninger Date: Tue, 3 Feb 2009 17:46:46 +0100 Subject: ACPI: cpufreq: Remove deprecated /proc/acpi/processor/../performance proc entries They were long enough set deprecated... Update Documentation/cpu-freq/users-guide.txt: The deprecated files listed there seen not to exist for some time anymore already. Signed-off-by: Thomas Renninger Signed-off-by: Len Brown --- Documentation/cpu-freq/user-guide.txt | 16 ---------------- 1 file changed, 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt index e3443dd..917918f 100644 --- a/Documentation/cpu-freq/user-guide.txt +++ b/Documentation/cpu-freq/user-guide.txt @@ -195,19 +195,3 @@ scaling_setspeed. By "echoing" a new frequency into this you can change the speed of the CPU, but only within the limits of scaling_min_freq and scaling_max_freq. - - -3.2 Deprecated Interfaces -------------------------- - -Depending on your kernel configuration, you might find the following -cpufreq-related files: -/proc/cpufreq -/proc/sys/cpu/*/speed -/proc/sys/cpu/*/speed-min -/proc/sys/cpu/*/speed-max - -These are files for deprecated interfaces to cpufreq, which offer far -less functionality. Because of this, these interfaces aren't described -here. - -- cgit v1.1 From 97c44836cdec1ea713a15d84098a1a908157e68f Mon Sep 17 00:00:00 2001 From: "Timothy S. Nelson" Date: Fri, 30 Jan 2009 06:12:47 +1100 Subject: PCI: return error on failure to read PCI ROMs This patch makes the ROM reading code return an error to user space if the size of the ROM read is equal to 0. The patch also emits a warnings if the contents of the ROM are invalid, and documents the effects of the "enable" file on ROM reading. Signed-off-by: Timothy S. Nelson Acked-by: Alex Villacis-Lasso Signed-off-by: Jesse Barnes --- Documentation/filesystems/sysfs-pci.txt | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt index 68ef488..9f8740c 100644 --- a/Documentation/filesystems/sysfs-pci.txt +++ b/Documentation/filesystems/sysfs-pci.txt @@ -9,6 +9,7 @@ that support it. For example, a given bus might look like this: | |-- class | |-- config | |-- device + | |-- enable | |-- irq | |-- local_cpus | |-- resource @@ -32,6 +33,7 @@ files, each with their own function. class PCI class (ascii, ro) config PCI config space (binary, rw) device PCI device (ascii, ro) + enable Whether the device is enabled (ascii, rw) irq IRQ number (ascii, ro) local_cpus nearby CPU mask (cpumask, ro) resource PCI resource host addresses (ascii, ro) @@ -57,10 +59,19 @@ used to do actual device programming from userspace. Note that some platforms don't support mmapping of certain resources, so be sure to check the return value from any attempted mmap. +The 'enable' file provides a counter that indicates how many times the device +has been enabled. If the 'enable' file currently returns '4', and a '1' is +echoed into it, it will then return '5'. Echoing a '0' into it will decrease +the count. Even when it returns to 0, though, some of the initialisation +may not be reversed. + The 'rom' file is special in that it provides read-only access to the device's ROM file, if available. It's disabled by default, however, so applications should write the string "1" to the file to enable it before attempting a read -call, and disable it following the access by writing "0" to the file. +call, and disable it following the access by writing "0" to the file. Note +that the device must be enabled for a rom read to return data succesfully. +In the event a driver is not bound to the device, it can be enabled using the +'enable' file, documented above. Accessing legacy resources through sysfs ---------------------------------------- -- cgit v1.1 From 0cd5c3c80a0ebd68c08312fa7d8c13149cc61c4c Mon Sep 17 00:00:00 2001 From: Kyle McMartin Date: Wed, 4 Feb 2009 14:29:19 -0800 Subject: x86: disable intel_iommu support by default Due to recurring issues with DMAR support on certain platforms. There's a number of filesystem corruption incidents reported: https://bugzilla.redhat.com/show_bug.cgi?id=479996 http://bugzilla.kernel.org/show_bug.cgi?id=12578 Provide a Kconfig option to change whether it is enabled by default. If disabled, it can still be reenabled by passing intel_iommu=on to the kernel. Keep the .config option off by default. Signed-off-by: Kyle McMartin Signed-off-by: Andrew Morton Acked-By: David Woodhouse Signed-off-by: Ingo Molnar --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d8362cf..b182626 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -937,6 +937,8 @@ and is between 256 and 4096 characters. It is defined in the file intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option + on + Enable intel iommu driver. off Disable intel iommu driver. igfx_off [Default Off] -- cgit v1.1 From f40b45a2e45b0f02aeedfcfbb28d8e2d4b8b86b1 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Wed, 11 Feb 2009 13:04:31 -0800 Subject: kernel-doc: preferred ending marker and examples Fix kernel-doc-nano-HOWTO.txt to use */ as the ending marker in kernel-doc examples and state that */ is the preferred ending marker. Signed-off-by: Randy Dunlap Reported-by: Robert Love Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-doc-nano-HOWTO.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index d73fbd2..026ec7d 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt @@ -43,7 +43,8 @@ Only comments so marked will be considered by the kernel-doc scripts, and any comment so marked must be in kernel-doc format. Do not use "/**" to be begin a comment block unless the comment block contains kernel-doc formatted comments. The closing comment marker for -kernel-doc comments can be either "*/" or "**/". +kernel-doc comments can be either "*/" or "**/", but "*/" is +preferred in the Linux kernel tree. Kernel-doc comments should be placed just before the function or data structure being described. @@ -63,7 +64,7 @@ Example kernel-doc function comment: * comment lines. * * The longer description can have multiple paragraphs. - **/ + */ The first line, with the short description, must be on a single line. @@ -85,7 +86,7 @@ Example kernel-doc data structure comment. * perhaps with more lines and words. * * Longer description of this structure. - **/ + */ The kernel-doc function comments describe each parameter to the function, in order, with the @name lines. -- cgit v1.1 From f82da723398ff18d49275a5f03de6cae5f592e8e Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Thu, 12 Feb 2009 16:47:01 -0800 Subject: Documentation/connector/cn_test.c: don't use gfp_any() cn_test_timer_func() is a timer handler and can never use GFP_KERNEL - there's no point in using gfp_any() here. Also, use setup_timer(). Signed-off-by: Andrew Morton Signed-off-by: David S. Miller --- Documentation/connector/cn_test.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c index be7af14..6977c17 100644 --- a/Documentation/connector/cn_test.c +++ b/Documentation/connector/cn_test.c @@ -137,7 +137,7 @@ static void cn_test_timer_func(unsigned long __data) memcpy(m + 1, data, m->len); - cn_netlink_send(m, 0, gfp_any()); + cn_netlink_send(m, 0, GFP_ATOMIC); kfree(m); } @@ -160,10 +160,8 @@ static int cn_test_init(void) goto err_out; } - init_timer(&cn_test_timer); - cn_test_timer.function = cn_test_timer_func; + setup_timer(&cn_test_timer, cn_test_timer_func, 0); cn_test_timer.expires = jiffies + HZ; - cn_test_timer.data = 0; add_timer(&cn_test_timer); return 0; -- cgit v1.1 From a08f6e04d74478d91f34a0484e69e89870adb33d Mon Sep 17 00:00:00 2001 From: Alex Chiang Date: Fri, 13 Feb 2009 12:03:17 -0700 Subject: PCI: Documentation: fix minor PCIe HOWTO thinko Update doc to correctly refer to replacing the pci_register_driver API, and not the non-existent "pci_module_init" API. Signed-off-by: Alex Chiang Signed-off-by: Jesse Barnes --- Documentation/PCI/PCIEBUS-HOWTO.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/PCI/PCIEBUS-HOWTO.txt b/Documentation/PCI/PCIEBUS-HOWTO.txt index 9a07e38..6bd5f37 100644 --- a/Documentation/PCI/PCIEBUS-HOWTO.txt +++ b/Documentation/PCI/PCIEBUS-HOWTO.txt @@ -93,7 +93,7 @@ the PCI Express Port Bus driver from loading a service driver. int pcie_port_service_register(struct pcie_port_service_driver *new) -This API replaces the Linux Driver Model's pci_module_init API. A +This API replaces the Linux Driver Model's pci_register_driver API. A service driver should always calls pcie_port_service_register at module init. Note that after service driver being loaded, calls such as pci_enable_device(dev) and pci_set_master(dev) are no longer -- cgit v1.1 From f9aa28adfc6a4b01268ebb6d88566cca8627905f Mon Sep 17 00:00:00 2001 From: Pekka Paalanen Date: Sat, 3 Jan 2009 21:09:27 +0200 Subject: doc: mmiotrace.txt, buffer size control change Impact: prevents confusing the user when buffer size is inadequate The tracing framework offers a resizeable buffer, which mmiotrace uses to record events. If the buffer is full, the following events will be lost. Events should not be lost, so the documentation instructs the user to increase the buffer size. The buffer size is set via a debugfs file. Mmiotrace documentation was not updated the same time the debugfs file was changed. The old file was tracing/trace_entries and first contained the number of entries the buffer had space for, per cpu. Nowadays this file is replaced with the file tracing/buffer_size_kb, which tells the amount of memory reserved for the buffer, per cpu, in kilobytes. Previously, a flag had to be toggled via the debugfs file tracing/tracing_enabled when the buffer size was changed. This is no longer necessary. The mmiotrace documentation is updated to reflect the current state of the tracing framework. Signed-off-by: Pekka Paalanen Signed-off-by: Steven Rostedt Signed-off-by: Ingo Molnar --- Documentation/tracers/mmiotrace.txt | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/tracers/mmiotrace.txt b/Documentation/tracers/mmiotrace.txt index cde23b4..5731c67 100644 --- a/Documentation/tracers/mmiotrace.txt +++ b/Documentation/tracers/mmiotrace.txt @@ -78,12 +78,10 @@ to view your kernel log and look for "mmiotrace has lost events" warning. If events were lost, the trace is incomplete. You should enlarge the buffers and try again. Buffers are enlarged by first seeing how large the current buffers are: -$ cat /debug/tracing/trace_entries +$ cat /debug/tracing/buffer_size_kb gives you a number. Approximately double this number and write it back, for instance: -$ echo 0 > /debug/tracing/tracing_enabled -$ echo 128000 > /debug/tracing/trace_entries -$ echo 1 > /debug/tracing/tracing_enabled +$ echo 128000 > /debug/tracing/buffer_size_kb Then start again from the top. If you are doing a trace for a driver project, e.g. Nouveau, you should also -- cgit v1.1 From b851ee7921fabdd7dfc96ffc4e9609f5062bd12b Mon Sep 17 00:00:00 2001 From: Li Zefan Date: Wed, 18 Feb 2009 14:48:14 -0800 Subject: cgroups: update documentation about css_set hash table The css_set hash table was introduced in 2.6.26, so update the documentation accordingly. Signed-off-by: Li Zefan Acked-by: Paul Menage Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/cgroups.txt | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index d9e5d6f..93feb84 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -252,10 +252,8 @@ cgroup file system directories. When a task is moved from one cgroup to another, it gets a new css_set pointer - if there's an already existing css_set with the desired collection of cgroups then that group is reused, else a new -css_set is allocated. Note that the current implementation uses a -linear search to locate an appropriate existing css_set, so isn't -very efficient. A future version will use a hash table for better -performance. +css_set is allocated. The appropriate existing css_set is located by +looking into a hash table. To allow access from a cgroup to the css_sets (and hence tasks) that comprise it, a set of cg_cgroup_link objects form a lattice; -- cgit v1.1 From ef2cfc790bf5f0ff189b01eabc0f4feb5e8524df Mon Sep 17 00:00:00 2001 From: Pavel Machek Date: Wed, 18 Feb 2009 14:48:23 -0800 Subject: hp accelerometer: add freefall detection MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This adds freefall handling to hp_accel driver. According to HP, it should just work, without us having to set the chip up by hand. hpfall.c is example .c program that parks the disk when accelerometer detects free fall. It should work; for now, it uses fixed 20seconds protection period. Signed-off-by: Pavel Machek Cc: Thomas Renninger Cc: Éric Piel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/hwmon/hpfall.c | 101 ++++++++++++++++++++++++++++++++++++++++++ Documentation/hwmon/lis3lv02d | 8 ++++ 2 files changed, 109 insertions(+) create mode 100644 Documentation/hwmon/hpfall.c (limited to 'Documentation') diff --git a/Documentation/hwmon/hpfall.c b/Documentation/hwmon/hpfall.c new file mode 100644 index 0000000..bbea1cc --- /dev/null +++ b/Documentation/hwmon/hpfall.c @@ -0,0 +1,101 @@ +/* Disk protection for HP machines. + * + * Copyright 2008 Eric Piel + * Copyright 2009 Pavel Machek + * + * GPLv2. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +void write_int(char *path, int i) +{ + char buf[1024]; + int fd = open(path, O_RDWR); + if (fd < 0) { + perror("open"); + exit(1); + } + sprintf(buf, "%d", i); + if (write(fd, buf, strlen(buf)) != strlen(buf)) { + perror("write"); + exit(1); + } + close(fd); +} + +void set_led(int on) +{ + write_int("/sys/class/leds/hp::hddprotect/brightness", on); +} + +void protect(int seconds) +{ + write_int("/sys/block/sda/device/unload_heads", seconds*1000); +} + +int on_ac(void) +{ +// /sys/class/power_supply/AC0/online +} + +int lid_open(void) +{ +// /proc/acpi/button/lid/LID/state +} + +void ignore_me(void) +{ + protect(0); + set_led(0); + +} + +int main(int argc, char* argv[]) +{ + int fd, ret; + + fd = open("/dev/freefall", O_RDONLY); + if (fd < 0) { + perror("open"); + return EXIT_FAILURE; + } + + signal(SIGALRM, ignore_me); + + for (;;) { + unsigned char count; + + ret = read(fd, &count, sizeof(count)); + alarm(0); + if ((ret == -1) && (errno == EINTR)) { + /* Alarm expired, time to unpark the heads */ + continue; + } + + if (ret != sizeof(count)) { + perror("read"); + break; + } + + protect(21); + set_led(1); + if (1 || on_ac() || lid_open()) { + alarm(2); + } else { + alarm(20); + } + } + + close(fd); + return EXIT_SUCCESS; +} diff --git a/Documentation/hwmon/lis3lv02d b/Documentation/hwmon/lis3lv02d index 0fcfc4a..287f8c9 100644 --- a/Documentation/hwmon/lis3lv02d +++ b/Documentation/hwmon/lis3lv02d @@ -33,6 +33,14 @@ rate - reports the sampling rate of the accelerometer device in HZ This driver also provides an absolute input class device, allowing the laptop to act as a pinball machine-esque joystick. +Another feature of the driver is misc device called "freefall" that +acts similar to /dev/rtc and reacts on free-fall interrupts received +from the device. It supports blocking operations, poll/select and +fasync operation modes. You must read 1 bytes from the device. The +result is number of free-fall interrupts since the last successful +read (or 255 if number of interrupts would not fit). + + Axes orientation ---------------- -- cgit v1.1 From 97bef7dd05563807539122c488a5dd93ed327722 Mon Sep 17 00:00:00 2001 From: Bernhard Walle Date: Wed, 18 Feb 2009 14:48:40 -0800 Subject: Bernhard has moved Since I don't work for SUSE any more and the bwalle@suse.de address is invalid, correct it in the copyright headers and documentation. Signed-off-by: Bernhard Walle Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/ABI/testing/sysfs-firmware-memmap | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-firmware-memmap b/Documentation/ABI/testing/sysfs-firmware-memmap index 0d99ee6..eca0d65 100644 --- a/Documentation/ABI/testing/sysfs-firmware-memmap +++ b/Documentation/ABI/testing/sysfs-firmware-memmap @@ -1,6 +1,6 @@ What: /sys/firmware/memmap/ Date: June 2008 -Contact: Bernhard Walle +Contact: Bernhard Walle Description: On all platforms, the firmware provides a memory map which the kernel reads. The resources from that memory map are registered -- cgit v1.1 From 3fd076dd955a34c35dc456f4ef676e03cdced044 Mon Sep 17 00:00:00 2001 From: Li Zefan Date: Fri, 20 Feb 2009 15:38:48 -0800 Subject: cpuset: various documentation fixes and updates I noticed the old commit 8f5aa26c75b7722e80c0c5c5bb833d41865d7019 ("cpusets: update_cpumask documentation fix") is not a complete fix, resulting in inconsistent paragraphs. This patch fixes it and does other fixes and updates: - s/migrate_all_tasks()/migrate_live_tasks()/ - describe more cpuset control files - s/cpumask_t/struct cpumask/ - document cpu hotplug and change of 'sched_relax_domain_level' may cause domain rebuild - document various ways to query and modify cpusets - the equivalent of "mount -t cpuset" is "mount -t cgroup -o cpuset,noprefix" Signed-off-by: Li Zefan Acked-by: Randy Dunlap Cc: Paul Menage Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/cpusets.txt | 65 ++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 28 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 5c86c25..0611e95 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt @@ -142,7 +142,7 @@ into the rest of the kernel, none in performance critical paths: - in fork and exit, to attach and detach a task from its cpuset. - in sched_setaffinity, to mask the requested CPUs by what's allowed in that tasks cpuset. - - in sched.c migrate_all_tasks(), to keep migrating tasks within + - in sched.c migrate_live_tasks(), to keep migrating tasks within the CPUs allowed by their cpuset, if possible. - in the mbind and set_mempolicy system calls, to mask the requested Memory Nodes by what's allowed in that tasks cpuset. @@ -175,6 +175,10 @@ files describing that cpuset: - mem_exclusive flag: is memory placement exclusive? - mem_hardwall flag: is memory allocation hardwalled - memory_pressure: measure of how much paging pressure in cpuset + - memory_spread_page flag: if set, spread page cache evenly on allowed nodes + - memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes + - sched_load_balance flag: if set, load balance within CPUs on that cpuset + - sched_relax_domain_level: the searching range when migrating tasks In addition, the root cpuset only has the following file: - memory_pressure_enabled flag: compute memory_pressure? @@ -252,7 +256,7 @@ is causing. This is useful both on tightly managed systems running a wide mix of submitted jobs, which may choose to terminate or re-prioritize jobs that -are trying to use more memory than allowed on the nodes assigned them, +are trying to use more memory than allowed on the nodes assigned to them, and with tightly coupled, long running, massively parallel scientific computing jobs that will dramatically fail to meet required performance goals if they start to use more memory than allowed to them. @@ -378,7 +382,7 @@ as cpusets and sched_setaffinity. The algorithmic cost of load balancing and its impact on key shared kernel data structures such as the task list increases more than linearly with the number of CPUs being balanced. So the scheduler -has support to partition the systems CPUs into a number of sched +has support to partition the systems CPUs into a number of sched domains such that it only load balances within each sched domain. Each sched domain covers some subset of the CPUs in the system; no two sched domains overlap; some CPUs might not be in any sched @@ -485,17 +489,22 @@ of CPUs allowed to a cpuset having 'sched_load_balance' enabled. The internal kernel cpuset to scheduler interface passes from the cpuset code to the scheduler code a partition of the load balanced CPUs in the system. This partition is a set of subsets (represented -as an array of cpumask_t) of CPUs, pairwise disjoint, that cover all -the CPUs that must be load balanced. - -Whenever the 'sched_load_balance' flag changes, or CPUs come or go -from a cpuset with this flag enabled, or a cpuset with this flag -enabled is removed, the cpuset code builds a new such partition and -passes it to the scheduler sched domain setup code, to have the sched -domains rebuilt as necessary. +as an array of struct cpumask) of CPUs, pairwise disjoint, that cover +all the CPUs that must be load balanced. + +The cpuset code builds a new such partition and passes it to the +scheduler sched domain setup code, to have the sched domains rebuilt +as necessary, whenever: + - the 'sched_load_balance' flag of a cpuset with non-empty CPUs changes, + - or CPUs come or go from a cpuset with this flag enabled, + - or 'sched_relax_domain_level' value of a cpuset with non-empty CPUs + and with this flag enabled changes, + - or a cpuset with non-empty CPUs and with this flag enabled is removed, + - or a cpu is offlined/onlined. This partition exactly defines what sched domains the scheduler should -setup - one sched domain for each element (cpumask_t) in the partition. +setup - one sched domain for each element (struct cpumask) in the +partition. The scheduler remembers the currently active sched domain partitions. When the scheduler routine partition_sched_domains() is invoked from @@ -559,7 +568,7 @@ domain, the largest value among those is used. Be careful, if one requests 0 and others are -1 then 0 is used. Note that modifying this file will have both good and bad effects, -and whether it is acceptable or not will be depend on your situation. +and whether it is acceptable or not depends on your situation. Don't modify this file if you are not sure. If your situation is: @@ -600,19 +609,15 @@ to allocate a page of memory for that task. If a cpuset has its 'cpus' modified, then each task in that cpuset will have its allowed CPU placement changed immediately. Similarly, -if a tasks pid is written to a cpusets 'tasks' file, in either its -current cpuset or another cpuset, then its allowed CPU placement is -changed immediately. If such a task had been bound to some subset -of its cpuset using the sched_setaffinity() call, the task will be -allowed to run on any CPU allowed in its new cpuset, negating the -affect of the prior sched_setaffinity() call. +if a tasks pid is written to another cpusets 'tasks' file, then its +allowed CPU placement is changed immediately. If such a task had been +bound to some subset of its cpuset using the sched_setaffinity() call, +the task will be allowed to run on any CPU allowed in its new cpuset, +negating the effect of the prior sched_setaffinity() call. In summary, the memory placement of a task whose cpuset is changed is updated by the kernel, on the next allocation of a page for that task, -but the processor placement is not updated, until that tasks pid is -rewritten to the 'tasks' file of its cpuset. This is done to avoid -impacting the scheduler code in the kernel with a check for changes -in a tasks processor placement. +and the processor placement is updated immediately. Normally, once a page is allocated (given a physical page of main memory) then that page stays on whatever node it @@ -681,10 +686,14 @@ and then start a subshell 'sh' in that cpuset: # The next line should display '/Charlie' cat /proc/self/cpuset -In the future, a C library interface to cpusets will likely be -available. For now, the only way to query or modify cpusets is -via the cpuset file system, using the various cd, mkdir, echo, cat, -rmdir commands from the shell, or their equivalent from C. +There are ways to query or modify cpusets: + - via the cpuset file system directly, using the various cd, mkdir, echo, + cat, rmdir commands from the shell, or their equivalent from C. + - via the C library libcpuset. + - via the C library libcgroup. + (http://sourceforge.net/proects/libcg/) + - via the python application cset. + (http://developer.novell.com/wiki/index.php/Cpuset) The sched_setaffinity calls can also be done at the shell prompt using SGI's runon or Robert Love's taskset. The mbind and set_mempolicy @@ -756,7 +765,7 @@ mount -t cpuset X /dev/cpuset is equivalent to -mount -t cgroup -ocpuset X /dev/cpuset +mount -t cgroup -ocpuset,noprefix X /dev/cpuset echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent 2.2 Adding/removing cpus -- cgit v1.1 From 802d52734adf0f288c49c05ed433872d7559c932 Mon Sep 17 00:00:00 2001 From: Karen Xie Date: Fri, 13 Feb 2009 21:39:04 -0800 Subject: [SCSI] cxgb3i: Fix spelling errors in documentation Signed-off-by: Karen Xie Signed-off-by: James Bottomley --- Documentation/scsi/cxgb3i.txt | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/cxgb3i.txt b/Documentation/scsi/cxgb3i.txt index 8141fa0..7ac8032 100644 --- a/Documentation/scsi/cxgb3i.txt +++ b/Documentation/scsi/cxgb3i.txt @@ -4,7 +4,7 @@ Introduction ============ The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc. -series of products) supports iSCSI acceleration and iSCSI Direct Data Placement +series of products) support iSCSI acceleration and iSCSI Direct Data Placement (DDP) where the hardware handles the expensive byte touching operations, such as CRC computation and verification, and direct DMA to the final host memory destination: @@ -31,9 +31,9 @@ destination: the TCP segments onto the wire. It handles TCP retransmission if needed. - On receving, S3 h/w recovers the iSCSI PDU by reassembling TCP + On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP segments, separating the header and data, calculating and verifying - the digests, then forwards the header to the host. The payload data, + the digests, then forwarding the header to the host. The payload data, if possible, will be directly placed into the pre-posted host DDP buffer. Otherwise, the payload data will be sent to the host too. @@ -68,9 +68,8 @@ The following steps need to be taken to accelerates the open-iscsi initiator: sure the ip address is unique in the network. 3. edit /etc/iscsi/iscsid.conf - The default setting for MaxRecvDataSegmentLength (131072) is too big, - replace "node.conn[0].iscsi.MaxRecvDataSegmentLength" to be a value no - bigger than 15360 (for example 8192): + The default setting for MaxRecvDataSegmentLength (131072) is too big; + replace with a value no bigger than 15360 (for example 8192): node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192 -- cgit v1.1 From 245127dbe9ea1e5a93aae0d3ede09992f1e99f53 Mon Sep 17 00:00:00 2001 From: Mike Murphy Date: Sun, 22 Feb 2009 01:17:14 -0500 Subject: PATCH [1/2] Documentation/driver-model/device.txt: fix struct device_attribute Fix the presented definition of struct device_attribute to match the actual definition in include/linux/device.h Signed-off-by: Mike Murphy Signed-off-by: Linus Torvalds --- Documentation/driver-model/device.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt index a05ec50..a7cbfff 100644 --- a/Documentation/driver-model/device.txt +++ b/Documentation/driver-model/device.txt @@ -127,9 +127,11 @@ void unlock_device(struct device * dev); Attributes ~~~~~~~~~~ struct device_attribute { - struct attribute attr; - ssize_t (*show)(struct device * dev, char * buf, size_t count, loff_t off); - ssize_t (*store)(struct device * dev, const char * buf, size_t count, loff_t off); + struct attribute attr; + ssize_t (*show)(struct device *dev, struct device_attribute *attr, + char *buf); + ssize_t (*store)(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count); }; Attributes of devices can be exported via drivers using a simple -- cgit v1.1 From f8a1af6bbc63218cabce742a7a291ac7c08bbd00 Mon Sep 17 00:00:00 2001 From: Mike Murphy Date: Sun, 22 Feb 2009 01:19:23 -0500 Subject: PATCH [2/2] Documentation/filesystems/sysfs.txt: fix descriptions of device attributes Fix descriptions of device attributes to be consistent with the actual implementations in include/linux/device.h Signed-off-by: Mike Murphy Signed-off-by: Linus Torvalds --- Documentation/filesystems/sysfs.txt | 50 +++++++++++++++++++++---------------- 1 file changed, 28 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 9e9c348..7e81e37 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -2,8 +2,10 @@ sysfs - _The_ filesystem for exporting kernel objects. Patrick Mochel +Mike Murphy -10 January 2003 +Revised: 22 February 2009 +Original: 10 January 2003 What it is: @@ -64,12 +66,13 @@ An attribute definition is simply: struct attribute { char * name; + struct module *owner; mode_t mode; }; -int sysfs_create_file(struct kobject * kobj, struct attribute * attr); -void sysfs_remove_file(struct kobject * kobj, struct attribute * attr); +int sysfs_create_file(struct kobject * kobj, const struct attribute * attr); +void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr); A bare attribute contains no means to read or write the value of the @@ -80,9 +83,11 @@ a specific object type. For example, the driver model defines struct device_attribute like: struct device_attribute { - struct attribute attr; - ssize_t (*show)(struct device * dev, char * buf); - ssize_t (*store)(struct device * dev, const char * buf); + struct attribute attr; + ssize_t (*show)(struct device *dev, struct device_attribute *attr, + char *buf); + ssize_t (*store)(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count); }; int device_create_file(struct device *, struct device_attribute *); @@ -90,12 +95,8 @@ void device_remove_file(struct device *, struct device_attribute *); It also defines this helper for defining device attributes: -#define DEVICE_ATTR(_name, _mode, _show, _store) \ -struct device_attribute dev_attr_##_name = { \ - .attr = {.name = __stringify(_name) , .mode = _mode }, \ - .show = _show, \ - .store = _store, \ -}; +#define DEVICE_ATTR(_name, _mode, _show, _store) \ +struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store) For example, declaring @@ -107,9 +108,9 @@ static struct device_attribute dev_attr_foo = { .attr = { .name = "foo", .mode = S_IWUSR | S_IRUGO, + .show = show_foo, + .store = store_foo, }, - .show = show_foo, - .store = store_foo, }; @@ -161,10 +162,12 @@ To read or write attributes, show() or store() methods must be specified when declaring the attribute. The method types should be as simple as those defined for device attributes: - ssize_t (*show)(struct device * dev, char * buf); - ssize_t (*store)(struct device * dev, const char * buf); +ssize_t (*show)(struct device * dev, struct device_attribute * attr, + char * buf); +ssize_t (*store)(struct device * dev, struct device_attribute * attr, + const char * buf); -IOW, they should take only an object and a buffer as parameters. +IOW, they should take only an object, an attribute, and a buffer as parameters. sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the @@ -299,14 +302,16 @@ The following interface layers currently exist in sysfs: Structure: struct device_attribute { - struct attribute attr; - ssize_t (*show)(struct device * dev, char * buf); - ssize_t (*store)(struct device * dev, const char * buf); + struct attribute attr; + ssize_t (*show)(struct device *dev, struct device_attribute *attr, + char *buf); + ssize_t (*store)(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count); }; Declaring: -DEVICE_ATTR(_name, _str, _mode, _show, _store); +DEVICE_ATTR(_name, _mode, _show, _store); Creation/Removal: @@ -342,7 +347,8 @@ Structure: struct driver_attribute { struct attribute attr; ssize_t (*show)(struct device_driver *, char * buf); - ssize_t (*store)(struct device_driver *, const char * buf); + ssize_t (*store)(struct device_driver *, const char * buf, + size_t count); }; Declaring: -- cgit v1.1 From f7f84f38cd916552c175f1f3d09cb6e85c1b29fc Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 22 Feb 2009 12:15:45 -0800 Subject: docbook: split kernel-api for device-drivers The kernel-api docbook was much larger than any of the others, so processing it took longer and needed some docbook extras in some cases, so split it into kernel-api (infrastructure etc.) and device drivers/device subsystems. This allows these docbooks to be generated in parallel. (This reduced the docbook processing time on my 4-proc system with make -j4 from about 5min:16sec to about 2min:01sec.) The chapters that were moved from kernel-api to device-drivers are: Driver Basics Device drivers infrastructure Parallel Port Devices Message-based devices Sound Devices 16x50 UART Driver Frame Buffer Library Input Subsystem Serial Peripheral Interface (SPI) I2C and SMBus Subsystem Signed-off-by: Randy Dunlap Acked-by: Sam Ravnborg Signed-off-by: Linus Torvalds --- Documentation/DocBook/Makefile | 2 +- Documentation/DocBook/device-drivers.tmpl | 418 ++++++++++++++++++++++++++++++ Documentation/DocBook/kernel-api.tmpl | 377 --------------------------- 3 files changed, 419 insertions(+), 378 deletions(-) create mode 100644 Documentation/DocBook/device-drivers.tmpl (limited to 'Documentation') diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index dc3154e..1462ed8 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -6,7 +6,7 @@ # To add a new book the only step required is to add the book to the # list of DOCBOOKS. -DOCBOOKS := z8530book.xml mcabook.xml \ +DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ procfs-guide.xml writing_usb_driver.xml networking.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl new file mode 100644 index 0000000..94a20fe --- /dev/null +++ b/Documentation/DocBook/device-drivers.tmpl @@ -0,0 +1,418 @@ + + + + + + Linux Device Drivers + + + + This documentation is free software; you can redistribute + it and/or modify it under the terms of the GNU General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later + version. + + + + This program is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the GNU General Public License for more details. + + + + You should have received a copy of the GNU General Public + License along with this program; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, + MA 02111-1307 USA + + + + For more details see the file COPYING in the source + distribution of Linux. + + + + + + + + Driver Basics + Driver Entry and Exit points +!Iinclude/linux/init.h + + + Atomic and pointer manipulation +!Iarch/x86/include/asm/atomic_32.h +!Iarch/x86/include/asm/unaligned.h + + + Delaying, scheduling, and timer routines +!Iinclude/linux/sched.h +!Ekernel/sched.c +!Ekernel/timer.c + + High-resolution timers +!Iinclude/linux/ktime.h +!Iinclude/linux/hrtimer.h +!Ekernel/hrtimer.c + + Workqueues and Kevents +!Ekernel/workqueue.c + + Internal Functions +!Ikernel/exit.c +!Ikernel/signal.c +!Iinclude/linux/kthread.h +!Ekernel/kthread.c + + + Kernel objects manipulation + +!Elib/kobject.c + + + Kernel utility functions +!Iinclude/linux/kernel.h +!Ekernel/printk.c +!Ekernel/panic.c +!Ekernel/sys.c +!Ekernel/rcupdate.c + + + Device Resource Management +!Edrivers/base/devres.c + + + + + + Device drivers infrastructure + Device Drivers Base + +!Edrivers/base/driver.c +!Edrivers/base/core.c +!Edrivers/base/class.c +!Edrivers/base/firmware_class.c +!Edrivers/base/transport_class.c + +!Edrivers/base/sys.c + +!Edrivers/base/platform.c +!Edrivers/base/bus.c + + Device Drivers Power Management +!Edrivers/base/power/main.c + + Device Drivers ACPI Support + +!Edrivers/acpi/scan.c +!Idrivers/acpi/scan.c + + + Device drivers PnP support +!Idrivers/pnp/core.c + +!Edrivers/pnp/card.c +!Idrivers/pnp/driver.c +!Edrivers/pnp/manager.c +!Edrivers/pnp/support.c + + Userspace IO devices +!Edrivers/uio/uio.c +!Iinclude/linux/uio_driver.h + + + + + Parallel Port Devices +!Iinclude/linux/parport.h +!Edrivers/parport/ieee1284.c +!Edrivers/parport/share.c +!Idrivers/parport/daisy.c + + + + Message-based devices + Fusion message devices +!Edrivers/message/fusion/mptbase.c +!Idrivers/message/fusion/mptbase.c +!Edrivers/message/fusion/mptscsih.c +!Idrivers/message/fusion/mptscsih.c +!Idrivers/message/fusion/mptctl.c +!Idrivers/message/fusion/mptspi.c +!Idrivers/message/fusion/mptfc.c +!Idrivers/message/fusion/mptlan.c + + I2O message devices +!Iinclude/linux/i2o.h +!Idrivers/message/i2o/core.h +!Edrivers/message/i2o/iop.c +!Idrivers/message/i2o/iop.c +!Idrivers/message/i2o/config-osm.c +!Edrivers/message/i2o/exec-osm.c +!Idrivers/message/i2o/exec-osm.c +!Idrivers/message/i2o/bus-osm.c +!Edrivers/message/i2o/device.c +!Idrivers/message/i2o/device.c +!Idrivers/message/i2o/driver.c +!Idrivers/message/i2o/pci.c +!Idrivers/message/i2o/i2o_block.c +!Idrivers/message/i2o/i2o_scsi.c +!Idrivers/message/i2o/i2o_proc.c + + + + + Sound Devices +!Iinclude/sound/core.h +!Esound/sound_core.c +!Iinclude/sound/pcm.h +!Esound/core/pcm.c +!Esound/core/device.c +!Esound/core/info.c +!Esound/core/rawmidi.c +!Esound/core/sound.c +!Esound/core/memory.c +!Esound/core/pcm_memory.c +!Esound/core/init.c +!Esound/core/isadma.c +!Esound/core/control.c +!Esound/core/pcm_lib.c +!Esound/core/hwdep.c +!Esound/core/pcm_native.c +!Esound/core/memalloc.c + + + + + 16x50 UART Driver +!Iinclude/linux/serial_core.h +!Edrivers/serial/serial_core.c +!Edrivers/serial/8250.c + + + + Frame Buffer Library + + + The frame buffer drivers depend heavily on four data structures. + These structures are declared in include/linux/fb.h. They are + fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. + The last three can be made available to and from userland. + + + + fb_info defines the current state of a particular video card. + Inside fb_info, there exists a fb_ops structure which is a + collection of needed functions to make fbdev and fbcon work. + fb_info is only visible to the kernel. + + + + fb_var_screeninfo is used to describe the features of a video card + that are user defined. With fb_var_screeninfo, things such as + depth and the resolution may be defined. + + + + The next structure is fb_fix_screeninfo. This defines the + properties of a card that are created when a mode is set and can't + be changed otherwise. A good example of this is the start of the + frame buffer memory. This "locks" the address of the frame buffer + memory, so that it cannot be changed or moved. + + + + The last structure is fb_monospecs. In the old API, there was + little importance for fb_monospecs. This allowed for forbidden things + such as setting a mode of 800x600 on a fix frequency monitor. With + the new API, fb_monospecs prevents such things, and if used + correctly, can prevent a monitor from being cooked. fb_monospecs + will not be useful until kernels 2.5.x. + + + Frame Buffer Memory +!Edrivers/video/fbmem.c + + + Frame Buffer Colormap +!Edrivers/video/fbcmap.c + + + Frame Buffer Video Mode Database +!Idrivers/video/modedb.c +!Edrivers/video/modedb.c + + Frame Buffer Macintosh Video Mode Database +!Edrivers/video/macmodes.c + + Frame Buffer Fonts + + Refer to the file drivers/video/console/fonts.c for more information. + + + + + + + Input Subsystem +!Iinclude/linux/input.h +!Edrivers/input/input.c +!Edrivers/input/ff-core.c +!Edrivers/input/ff-memless.c + + + + Serial Peripheral Interface (SPI) + + SPI is the "Serial Peripheral Interface", widely used with + embedded systems because it is a simple and efficient + interface: basically a multiplexed shift register. + Its three signal wires hold a clock (SCK, often in the range + of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and + a "Master In, Slave Out" (MISO) data line. + SPI is a full duplex protocol; for each bit shifted out the + MOSI line (one per clock) another is shifted in on the MISO line. + Those bits are assembled into words of various sizes on the + way to and from system memory. + An additional chipselect line is usually active-low (nCS); + four signals are normally used for each peripheral, plus + sometimes an interrupt. + + + The SPI bus facilities listed here provide a generalized + interface to declare SPI busses and devices, manage them + according to the standard Linux driver model, and perform + input/output operations. + At this time, only "master" side interfaces are supported, + where Linux talks to SPI peripherals and does not implement + such a peripheral itself. + (Interfaces to support implementing SPI slaves would + necessarily look different.) + + + The programming interface is structured around two kinds of driver, + and two kinds of device. + A "Controller Driver" abstracts the controller hardware, which may + be as simple as a set of GPIO pins or as complex as a pair of FIFOs + connected to dual DMA engines on the other side of the SPI shift + register (maximizing throughput). Such drivers bridge between + whatever bus they sit on (often the platform bus) and SPI, and + expose the SPI side of their device as a + struct spi_master. + SPI devices are children of that master, represented as a + struct spi_device and manufactured from + struct spi_board_info descriptors which + are usually provided by board-specific initialization code. + A struct spi_driver is called a + "Protocol Driver", and is bound to a spi_device using normal + driver model calls. + + + The I/O model is a set of queued messages. Protocol drivers + submit one or more struct spi_message + objects, which are processed and completed asynchronously. + (There are synchronous wrappers, however.) Messages are + built from one or more struct spi_transfer + objects, each of which wraps a full duplex SPI transfer. + A variety of protocol tweaking options are needed, because + different chips adopt very different policies for how they + use the bits transferred with SPI. + +!Iinclude/linux/spi/spi.h +!Fdrivers/spi/spi.c spi_register_board_info +!Edrivers/spi/spi.c + + + + I<superscript>2</superscript>C and SMBus Subsystem + + + I2C (or without fancy typography, "I2C") + is an acronym for the "Inter-IC" bus, a simple bus protocol which is + widely used where low data rate communications suffice. + Since it's also a licensed trademark, some vendors use another + name (such as "Two-Wire Interface", TWI) for the same bus. + I2C only needs two signals (SCL for clock, SDA for data), conserving + board real estate and minimizing signal quality issues. + Most I2C devices use seven bit addresses, and bus speeds of up + to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet + found wide use. + I2C is a multi-master bus; open drain signaling is used to + arbitrate between masters, as well as to handshake and to + synchronize clocks from slower clients. + + + + The Linux I2C programming interfaces support only the master + side of bus interactions, not the slave side. + The programming interface is structured around two kinds of driver, + and two kinds of device. + An I2C "Adapter Driver" abstracts the controller hardware; it binds + to a physical device (perhaps a PCI device or platform_device) and + exposes a struct i2c_adapter representing + each I2C bus segment it manages. + On each I2C bus segment will be I2C devices represented by a + struct i2c_client. Those devices will + be bound to a struct i2c_driver, + which should follow the standard Linux driver model. + (At this writing, a legacy model is more widely used.) + There are functions to perform various I2C protocol operations; at + this writing all such functions are usable only from task context. + + + + The System Management Bus (SMBus) is a sibling protocol. Most SMBus + systems are also I2C conformant. The electrical constraints are + tighter for SMBus, and it standardizes particular protocol messages + and idioms. Controllers that support I2C can also support most + SMBus operations, but SMBus controllers don't support all the protocol + options that an I2C controller will. + There are functions to perform various SMBus protocol operations, + either using I2C primitives or by issuing SMBus commands to + i2c_adapter devices which don't support those I2C operations. + + +!Iinclude/linux/i2c.h +!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info +!Edrivers/i2c/i2c-core.c + + + diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 5818ff7..bc962cd 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -38,58 +38,6 @@ - - Driver Basics - Driver Entry and Exit points -!Iinclude/linux/init.h - - - Atomic and pointer manipulation -!Iarch/x86/include/asm/atomic_32.h -!Iarch/x86/include/asm/unaligned.h - - - Delaying, scheduling, and timer routines -!Iinclude/linux/sched.h -!Ekernel/sched.c -!Ekernel/timer.c - - High-resolution timers -!Iinclude/linux/ktime.h -!Iinclude/linux/hrtimer.h -!Ekernel/hrtimer.c - - Workqueues and Kevents -!Ekernel/workqueue.c - - Internal Functions -!Ikernel/exit.c -!Ikernel/signal.c -!Iinclude/linux/kthread.h -!Ekernel/kthread.c - - - Kernel objects manipulation - -!Elib/kobject.c - - - Kernel utility functions -!Iinclude/linux/kernel.h -!Ekernel/printk.c -!Ekernel/panic.c -!Ekernel/sys.c -!Ekernel/rcupdate.c - - - Device Resource Management -!Edrivers/base/devres.c - - - - Data Types Doubly Linked Lists @@ -298,62 +246,6 @@ X!Earch/x86/kernel/mca_32.c !Ikernel/acct.c - - Device drivers infrastructure - Device Drivers Base - -!Edrivers/base/driver.c -!Edrivers/base/core.c -!Edrivers/base/class.c -!Edrivers/base/firmware_class.c -!Edrivers/base/transport_class.c - -!Edrivers/base/sys.c - -!Edrivers/base/platform.c -!Edrivers/base/bus.c - - Device Drivers Power Management -!Edrivers/base/power/main.c - - Device Drivers ACPI Support - -!Edrivers/acpi/scan.c -!Idrivers/acpi/scan.c - - - Device drivers PnP support -!Idrivers/pnp/core.c - -!Edrivers/pnp/card.c -!Idrivers/pnp/driver.c -!Edrivers/pnp/manager.c -!Edrivers/pnp/support.c - - Userspace IO devices -!Edrivers/uio/uio.c -!Iinclude/linux/uio_driver.h - - - Block Devices !Eblock/blk-core.c @@ -381,275 +273,6 @@ X!Edrivers/pnp/system.c !Edrivers/char/misc.c - - Parallel Port Devices -!Iinclude/linux/parport.h -!Edrivers/parport/ieee1284.c -!Edrivers/parport/share.c -!Idrivers/parport/daisy.c - - - - Message-based devices - Fusion message devices -!Edrivers/message/fusion/mptbase.c -!Idrivers/message/fusion/mptbase.c -!Edrivers/message/fusion/mptscsih.c -!Idrivers/message/fusion/mptscsih.c -!Idrivers/message/fusion/mptctl.c -!Idrivers/message/fusion/mptspi.c -!Idrivers/message/fusion/mptfc.c -!Idrivers/message/fusion/mptlan.c - - I2O message devices -!Iinclude/linux/i2o.h -!Idrivers/message/i2o/core.h -!Edrivers/message/i2o/iop.c -!Idrivers/message/i2o/iop.c -!Idrivers/message/i2o/config-osm.c -!Edrivers/message/i2o/exec-osm.c -!Idrivers/message/i2o/exec-osm.c -!Idrivers/message/i2o/bus-osm.c -!Edrivers/message/i2o/device.c -!Idrivers/message/i2o/device.c -!Idrivers/message/i2o/driver.c -!Idrivers/message/i2o/pci.c -!Idrivers/message/i2o/i2o_block.c -!Idrivers/message/i2o/i2o_scsi.c -!Idrivers/message/i2o/i2o_proc.c - - - - - Sound Devices -!Iinclude/sound/core.h -!Esound/sound_core.c -!Iinclude/sound/pcm.h -!Esound/core/pcm.c -!Esound/core/device.c -!Esound/core/info.c -!Esound/core/rawmidi.c -!Esound/core/sound.c -!Esound/core/memory.c -!Esound/core/pcm_memory.c -!Esound/core/init.c -!Esound/core/isadma.c -!Esound/core/control.c -!Esound/core/pcm_lib.c -!Esound/core/hwdep.c -!Esound/core/pcm_native.c -!Esound/core/memalloc.c - - - - - 16x50 UART Driver -!Iinclude/linux/serial_core.h -!Edrivers/serial/serial_core.c -!Edrivers/serial/8250.c - - - - Frame Buffer Library - - - The frame buffer drivers depend heavily on four data structures. - These structures are declared in include/linux/fb.h. They are - fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. - The last three can be made available to and from userland. - - - - fb_info defines the current state of a particular video card. - Inside fb_info, there exists a fb_ops structure which is a - collection of needed functions to make fbdev and fbcon work. - fb_info is only visible to the kernel. - - - - fb_var_screeninfo is used to describe the features of a video card - that are user defined. With fb_var_screeninfo, things such as - depth and the resolution may be defined. - - - - The next structure is fb_fix_screeninfo. This defines the - properties of a card that are created when a mode is set and can't - be changed otherwise. A good example of this is the start of the - frame buffer memory. This "locks" the address of the frame buffer - memory, so that it cannot be changed or moved. - - - - The last structure is fb_monospecs. In the old API, there was - little importance for fb_monospecs. This allowed for forbidden things - such as setting a mode of 800x600 on a fix frequency monitor. With - the new API, fb_monospecs prevents such things, and if used - correctly, can prevent a monitor from being cooked. fb_monospecs - will not be useful until kernels 2.5.x. - - - Frame Buffer Memory -!Edrivers/video/fbmem.c - - - Frame Buffer Colormap -!Edrivers/video/fbcmap.c - - - Frame Buffer Video Mode Database -!Idrivers/video/modedb.c -!Edrivers/video/modedb.c - - Frame Buffer Macintosh Video Mode Database -!Edrivers/video/macmodes.c - - Frame Buffer Fonts - - Refer to the file drivers/video/console/fonts.c for more information. - - - - - - - Input Subsystem -!Iinclude/linux/input.h -!Edrivers/input/input.c -!Edrivers/input/ff-core.c -!Edrivers/input/ff-memless.c - - - - Serial Peripheral Interface (SPI) - - SPI is the "Serial Peripheral Interface", widely used with - embedded systems because it is a simple and efficient - interface: basically a multiplexed shift register. - Its three signal wires hold a clock (SCK, often in the range - of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and - a "Master In, Slave Out" (MISO) data line. - SPI is a full duplex protocol; for each bit shifted out the - MOSI line (one per clock) another is shifted in on the MISO line. - Those bits are assembled into words of various sizes on the - way to and from system memory. - An additional chipselect line is usually active-low (nCS); - four signals are normally used for each peripheral, plus - sometimes an interrupt. - - - The SPI bus facilities listed here provide a generalized - interface to declare SPI busses and devices, manage them - according to the standard Linux driver model, and perform - input/output operations. - At this time, only "master" side interfaces are supported, - where Linux talks to SPI peripherals and does not implement - such a peripheral itself. - (Interfaces to support implementing SPI slaves would - necessarily look different.) - - - The programming interface is structured around two kinds of driver, - and two kinds of device. - A "Controller Driver" abstracts the controller hardware, which may - be as simple as a set of GPIO pins or as complex as a pair of FIFOs - connected to dual DMA engines on the other side of the SPI shift - register (maximizing throughput). Such drivers bridge between - whatever bus they sit on (often the platform bus) and SPI, and - expose the SPI side of their device as a - struct spi_master. - SPI devices are children of that master, represented as a - struct spi_device and manufactured from - struct spi_board_info descriptors which - are usually provided by board-specific initialization code. - A struct spi_driver is called a - "Protocol Driver", and is bound to a spi_device using normal - driver model calls. - - - The I/O model is a set of queued messages. Protocol drivers - submit one or more struct spi_message - objects, which are processed and completed asynchronously. - (There are synchronous wrappers, however.) Messages are - built from one or more struct spi_transfer - objects, each of which wraps a full duplex SPI transfer. - A variety of protocol tweaking options are needed, because - different chips adopt very different policies for how they - use the bits transferred with SPI. - -!Iinclude/linux/spi/spi.h -!Fdrivers/spi/spi.c spi_register_board_info -!Edrivers/spi/spi.c - - - - I<superscript>2</superscript>C and SMBus Subsystem - - - I2C (or without fancy typography, "I2C") - is an acronym for the "Inter-IC" bus, a simple bus protocol which is - widely used where low data rate communications suffice. - Since it's also a licensed trademark, some vendors use another - name (such as "Two-Wire Interface", TWI) for the same bus. - I2C only needs two signals (SCL for clock, SDA for data), conserving - board real estate and minimizing signal quality issues. - Most I2C devices use seven bit addresses, and bus speeds of up - to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet - found wide use. - I2C is a multi-master bus; open drain signaling is used to - arbitrate between masters, as well as to handshake and to - synchronize clocks from slower clients. - - - - The Linux I2C programming interfaces support only the master - side of bus interactions, not the slave side. - The programming interface is structured around two kinds of driver, - and two kinds of device. - An I2C "Adapter Driver" abstracts the controller hardware; it binds - to a physical device (perhaps a PCI device or platform_device) and - exposes a struct i2c_adapter representing - each I2C bus segment it manages. - On each I2C bus segment will be I2C devices represented by a - struct i2c_client. Those devices will - be bound to a struct i2c_driver, - which should follow the standard Linux driver model. - (At this writing, a legacy model is more widely used.) - There are functions to perform various I2C protocol operations; at - this writing all such functions are usable only from task context. - - - - The System Management Bus (SMBus) is a sibling protocol. Most SMBus - systems are also I2C conformant. The electrical constraints are - tighter for SMBus, and it standardizes particular protocol messages - and idioms. Controllers that support I2C can also support most - SMBus operations, but SMBus controllers don't support all the protocol - options that an I2C controller will. - There are functions to perform various SMBus protocol operations, - either using I2C primitives or by issuing SMBus commands to - i2c_adapter devices which don't support those I2C operations. - - -!Iinclude/linux/i2c.h -!Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info -!Edrivers/i2c/i2c-core.c - - Clock Framework -- cgit v1.1 From af23f573e817642479fdd05e2b5da5b268eacfaf Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 22 Feb 2009 17:05:22 -0800 Subject: acpi/doc: add missing param value Add missing parameter value to list of available values for acpi=. Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index b182626..319785b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -134,7 +134,7 @@ and is between 256 and 4096 characters. It is defined in the file acpi= [HW,ACPI,X86-64,i386] Advanced Configuration and Power Interface - Format: { force | off | ht | strict | noirq } + Format: { force | off | ht | strict | noirq | rsdt } force -- enable ACPI if default was off off -- disable ACPI if default was on noirq -- do not use ACPI for IRQ routing -- cgit v1.1 From 954a8b8162ecab1d5ddf6c5b993b2d4da3fcaef7 Mon Sep 17 00:00:00 2001 From: Kyle McMartin Date: Thu, 19 Feb 2009 16:48:14 -0500 Subject: x86, doc: fix references to Documentation/x86/i386/boot.txt Impact: Documentation fix The amazing dancing boot.txt file has jumped places again. It should never have been in Documentation/x86/i386, since it never was 32-bit-specific, but it unfortunately ended up there for a while. Signed-off-by: Kyle McMartin Signed-off-by: H. Peter Anvin --- Documentation/kernel-parameters.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 319785b..f6d5d5b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -114,7 +114,7 @@ In addition, the following text indicates that the option: Parameters denoted with BOOT are actually interpreted by the boot loader, and have no meaning to the kernel directly. Do not modify the syntax of boot loader parameters without extreme -need or coordination with . +need or coordination with . There are also arch-specific kernel-parameters not documented here. See for example . @@ -2449,7 +2449,7 @@ and is between 256 and 4096 characters. It is defined in the file See Documentation/fb/modedb.txt. vga= [BOOT,X86-32] Select a particular video mode - See Documentation/x86/i386/boot.txt and + See Documentation/x86/boot.txt and Documentation/svga.txt. Use vga=ask for menu. This is actually a boot loader parameter; the value is -- cgit v1.1 From d22157b3d7a24d953ef5cce4515436be65b2e121 Mon Sep 17 00:00:00 2001 From: Chris Wright Date: Mon, 23 Feb 2009 21:50:35 -0800 Subject: PCI: add some sysfs ABI docs Add sysfs ABI docs for driver entries bind, unbind and new_id. These entries are pretty old, from 2.6.0 onwards AFAIK, so this documents current behaviour. Signed-off-by: Chris Wright Acked-by: Greg Kroah-Hartman Signed-off-by: Jesse Barnes --- Documentation/ABI/testing/sysfs-bus-pci | 43 +++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index ceddcff..e638e15 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -1,3 +1,46 @@ +What: /sys/bus/pci/drivers/.../bind +Date: December 2003 +Contact: linux-pci@vger.kernel.org +Description: + Writing a device location to this file will cause + the driver to attempt to bind to the device found at + this location. This is useful for overriding default + bindings. The format for the location is: DDDD:BB:DD.F. + That is Domain:Bus:Device.Function and is the same as + found in /sys/bus/pci/devices/. For example: + # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind + (Note: kernels before 2.6.28 may require echo -n). + +What: /sys/bus/pci/drivers/.../unbind +Date: December 2003 +Contact: linux-pci@vger.kernel.org +Description: + Writing a device location to this file will cause the + driver to attempt to unbind from the device found at + this location. This may be useful when overriding default + bindings. The format for the location is: DDDD:BB:DD.F. + That is Domain:Bus:Device.Function and is the same as + found in /sys/bus/pci/devices/. For example: + # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind + (Note: kernels before 2.6.28 may require echo -n). + +What: /sys/bus/pci/drivers/.../new_id +Date: December 2003 +Contact: linux-pci@vger.kernel.org +Description: + Writing a device ID to this file will attempt to + dynamically add a new device ID to a PCI device driver. + This may allow the driver to support more hardware than + was included in the driver's static device ID support + table at compile time. The format for the device ID is: + VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID, + Device ID, Subsystem Vendor ID, Subsystem Device ID, + Class, Class Mask, and Private Driver Data. The Vendor ID + and Device ID fields are required, the rest are optional. + Upon successfully adding an ID, the driver will probe + for the device and attempt to bind to it. For example: + # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id + What: /sys/bus/pci/devices/.../vpd Date: February 2008 Contact: Ben Hutchings -- cgit v1.1 From 0af80c04e2f2e45ae09fceb17df8050f828a5c40 Mon Sep 17 00:00:00 2001 From: David Fries Date: Wed, 25 Feb 2009 20:28:21 +0100 Subject: ide: ide.c 'clear' fix, update "ide=nodma" documentation Documentation/kernel-parameters.txt - ide=nodma is no longer valid. drivers/ide/Kconfig - The module is ide-core.ko not ide. drivers/ide/ide.c - It took me a while to figure out what the arguments %d.%d:%d to nodma module parameter ment, so I added a comment to each. - Added a comment to each of the sscanf lines. - There is a bug, if j is 0 it would previously clear all the other bits except the current device, changed in three different places. mask &= (1 << i) should be mask &= ~(1 << i). Signed-off-by: David Fries [bart: s/disk/device/ in ide.c, beautify patch description] Signed-off-by: Bartlomiej Zolnierkiewicz --- Documentation/kernel-parameters.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 319785b..0ed3234 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -868,8 +868,10 @@ and is between 256 and 4096 characters. It is defined in the file icn= [HW,ISDN] Format: [,[,[,]]] - ide= [HW] (E)IDE subsystem - Format: ide=nodma or ide=doubler + ide-core.nodma= [HW] (E)IDE subsystem + Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc + .vlb_clock .pci_clock .noflush .noprobe .nowerr .cdrom + .chs .ignore_cable are additional options See Documentation/ide/ide.txt. idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed -- cgit v1.1 From f5a3258335eef2baf534243da00bcd0e760dd2b5 Mon Sep 17 00:00:00 2001 From: Uwe Bugla Date: Mon, 23 Feb 2009 10:54:20 -0300 Subject: V4L/DVB (10695): Update Technisat card documentation Fixes for documentation of Technisat-based cards Signed-off-by: Uwe Bugla Signed-off-by: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/technisat.txt | 34 ++++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dvb/technisat.txt b/Documentation/dvb/technisat.txt index cdf6ee4..3f435ff 100644 --- a/Documentation/dvb/technisat.txt +++ b/Documentation/dvb/technisat.txt @@ -1,5 +1,5 @@ -How to set up the Technisat devices -=================================== +How to set up the Technisat/B2C2 Flexcop devices +================================================ 1) Find out what device you have ================================ @@ -16,54 +16,60 @@ DVB: registering frontend 0 (Conexant CX24123/CX24109)... If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one: "Multimedia devices" => "Customise analog and hybrid tuner modules to build" -In this directory uncheck every driver which is activated there. +In this directory uncheck every driver which is activated there (except "Simple tuner support" for case 9 only). Then please activate: 2a) Main module part: a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" -b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card OR +b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card +OR c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers" Notice: d.) is helpful for troubleshooting 2b) Frontend module part: -1.) Revision 2.3: +1.) SkyStar DVB-S Revision 2.3: a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based" -2.) Revision 2.6: +2.) SkyStar DVB-S Revision 2.6: a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based" -3.) Revision 2.7: +3.) SkyStar DVB-S Revision 2.7: a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based" c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS" d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" -4.) Revision 2.8: +4.) SkyStar DVB-S Revision 2.8: a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS" c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based" d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" -5.) DVB-T card: +5.) AirStar DVB-T card: a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based" -6.) DVB-C card: +6.) CableStar DVB-C card: a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based" -7.) ATSC card 1st generation: +7.) AirStar ATSC card 1st generation: a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510" -8.) ATSC card 2nd generation: +8.) AirStar ATSC card 2nd generation: a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based" -c.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based" +c.)"Multimedia devices" => "Customise DVB frontends" => "Generic I2C PLL based tuners" -Author: Uwe Bugla December 2008 +9.) AirStar ATSC card 3rd generation: +a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" +b.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based" +c.)"Multimedia devices" => "Customise analog and hybrid tuner modules to build" => "Simple tuner support" + +Author: Uwe Bugla February 2009 -- cgit v1.1 From b391d0f08fb0858f7d2cc034ddcca6cd0545bd7d Mon Sep 17 00:00:00 2001 From: Uwe Bugla Date: Mon, 23 Feb 2009 10:56:11 -0300 Subject: V4L/DVB (10696): Remove outdated README for the flexcop-driver This patch removes an outdated README for the flexcop-driver. Signed-off-by: Uwe Bugla Signed-off-by: Patrick Boettcher Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/README.flexcop | 205 --------------------------------------- 1 file changed, 205 deletions(-) delete mode 100644 Documentation/dvb/README.flexcop (limited to 'Documentation') diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop deleted file mode 100644 index 5515469..0000000 --- a/Documentation/dvb/README.flexcop +++ /dev/null @@ -1,205 +0,0 @@ -This README escorted the skystar2-driver rewriting procedure. It describes the -state of the new flexcop-driver set and some internals are written down here -too. - -This document hopefully describes things about the flexcop and its -device-offsprings. Goal was to write an easy-to-write and easy-to-read set of -drivers based on the skystar2.c and other information. - -Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been -touched and rewritten. - -History & News -============== - 2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana) - - - - -General coding processing -========================= - -We should proceed as follows (as long as no one complains): - -0) Think before start writing code! - -1) rewriting the skystar2.c with the help of the flexcop register descriptions -and splitting up the files to a pci-bus-part and a flexcop-part. -The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the -device-specific part and b2c2-flexcop.ko for the common flexcop-functions. - -2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c -and other pci drivers) - -3) make some beautification (see 'Improvements when rewriting (refactoring) is -done') - -4) Testing the new driver and maybe substitute the skystar2.c with it, to reach -a wider tester audience. - -5) creating an usb-bus-part using the already written flexcop code for the pci -card. - -Idea: create a kernel-object for the flexcop and export all important -functions. This option saves kernel-memory, but maybe a lot of functions have -to be exported to kernel namespace. - - -Current situation -================= - -0) Done :) -1) Done (some minor issues left) -2) Done -3) Not ready yet, more information is necessary -4) next to be done (see the table below) -5) USB driver is working (yes, there are some minor issues) - -What seems to be ready? ------------------------ - -1) Rewriting -1a) i2c is cut off from the flexcop-pci.c and seems to work -1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c -1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c -1e) eeprom (reading MAC address) -1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me)) -1f) misc. register accesses for reading parameters (e.g. resetting, revision) -1g) pid/mac filter (flexcop-hw-filter.c) -1i) dvb-stuff initialization in flexcop.c (done) -1h) dma stuff (now just using the size-irq, instead of all-together, to be done) -1j) remove flexcop initialization from flexcop-pci.c completely (done) -1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO') -1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from -non-static where possible, moved code to proper places) - -2) Search for errors in the leftover of flexcop-pci.c (partially done) -5a) add MAC address reading -5c) feeding of ISOC data to the software demux (format of the isochronous data -and speed optimization, no real error) (thanks to Vadim Catana) - -What to do in the near future? --------------------------------------- -(no special order here) - -5) USB driver -5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting) - -Testing changes ---------------- - -O = item is working -P = item is partially working -X = item is not working -N = item does not apply here - = item need to be examined - - | PCI | USB -item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312 --------+-------+---------+---------+-------+-------+---------+---------+------- -1a) | O | | | | N | N | N | N -1b) | O | | | | | | O | -1c) | N | N | | | N | N | O | -1d) | O | O -1e) | O | O -1f) | P -1g) | O -1h) | P | -1i) | O | N -1j) | O | N -1l) | O | N -2) | O | N -5a) | N | O -5b)* | N | -5c) | N | O - -* - not done yet - -Known bugs and problems and TODO --------------------------------- - -1g/h/l) when pid filtering is enabled on the pci card - -DMA usage currently: - The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first - address and triggers an IRQ when it's full and starts writing to the second - address. When the second address is full, the IRQ is triggered again, and - the flexcop writes to first address again, and so on. - The buffersize of each address is currently 640*188 bytes. - - Problem is, when using hw-pid-filtering and doing some low-bandwidth - operation (like scanning) the buffers won't be filled enough to trigger - the IRQ. That's why: - - When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ - is triggered. Is the current write address of DMA1 different to the one - during the last IRQ, then the data is passed to the demuxer. - - There is an additional DMA-IRQ-method: packet count IRQ. This isn't - implemented correctly yet. - - The solution is to disable HW PID filtering, but I don't know how the DVB - API software demux behaves on slow systems with 45MBit/s TS. - -Solved bugs :) --------------- -1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't -working) -SOLUTION: also index 0 was affected, because net_translation is done for -these indexes by default - -5b) isochronous transfer does only work in the first attempt (for the Sky2PC -USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really -woke up again (don't know if this need fixes, see -flexcop-fe-tuner.c:flexcop_sleep) - -NEWS: when the driver is loaded and unloaded and loaded again (w/o doing -anything in the while the driver is loaded the first time), no transfers take -place anymore. - -Improvements when rewriting (refactoring) is done -================================================= - -- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control - (enable sleeping for other demods than dvb-s) -- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA) - -Debugging ---------- -- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it - with this flexcop, this is important, because i2c is now using the - flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for - that, please tell us so). - -Everything which is identical in the following table, can be put into a common -flexcop-module. - - PCI USB -------------------------------------------------------------------------------- -Different: -Register access: accessing IO memory USB control message -I2C bus: I2C bus of the FC USB control message -Data transfer: DMA isochronous transfer -EEPROM transfer: through i2c bus not clear yet - -Identical: -Streaming: accessing registers -PID Filtering: accessing registers -Sram destinations: accessing registers -Tuner/Demod: I2C bus -DVB-stuff: can be written for common use - -Acknowledgements (just for the rewriting part) -================ - -Bjarne Steinsbo thought a lot in the first place of the pci part for this code -sharing idea. - -Andreas Oberritter for providing a recent PCI initialization template -(pluto2.c). - -Boleslaw Ciesielski for pointing out a problem with firmware loader. - -Vadim Catana for correcting the USB transfer. - -comments, critics and ideas to linux-dvb@linuxtv.org. -- cgit v1.1 From fe7ca2e1e847b65c12d245cbf402af89da96888a Mon Sep 17 00:00:00 2001 From: Brian Haley Date: Wed, 4 Mar 2009 03:18:11 -0800 Subject: IPv6: add "disable" module parameter support to ipv6.ko Add "disable" module parameter support to ipv6.ko by specifying "disable=1" on module load. We just do the minimum of initializing inetsw6[] so calls from other modules to inet6_register_protosw() won't OOPs, then bail out. No IPv6 addresses or sockets can be created as a result, and a reboot is required to enable IPv6. Signed-off-by: Brian Haley Signed-off-by: David S. Miller --- Documentation/networking/ipv6.txt | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/networking/ipv6.txt (limited to 'Documentation') diff --git a/Documentation/networking/ipv6.txt b/Documentation/networking/ipv6.txt new file mode 100644 index 0000000..268e5c1 --- /dev/null +++ b/Documentation/networking/ipv6.txt @@ -0,0 +1,35 @@ + +Options for the ipv6 module are supplied as parameters at load time. + +Module options may be given as command line arguments to the insmod +or modprobe command, but are usually specified in either the +/etc/modules.conf or /etc/modprobe.conf configuration file, or in a +distro-specific configuration file. + +The available ipv6 module parameters are listed below. If a parameter +is not specified the default value is used. + +The parameters are as follows: + +disable + + Specifies whether to load the IPv6 module, but disable all + its functionality. This might be used when another module + has a dependency on the IPv6 module being loaded, but no + IPv6 addresses or operations are desired. + + The possible values and their effects are: + + 0 + IPv6 is enabled. + + This is the default value. + + 1 + IPv6 is disabled. + + No IPv6 addresses will be added to interfaces, and + it will not be possible to open an IPv6 socket. + + A reboot is required to enable IPv6. + -- cgit v1.1 From edf2e2811efa9304ebe14f778d33b764cfd58b7a Mon Sep 17 00:00:00 2001 From: Phillip Lougher Date: Thu, 5 Mar 2009 00:40:13 +0000 Subject: Squashfs: fix documentation typo, Cramfs filesystem limit is 256 MiB Signed-off-by: Phillip Lougher --- Documentation/filesystems/squashfs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt index 3e79e4a..b324c03 100644 --- a/Documentation/filesystems/squashfs.txt +++ b/Documentation/filesystems/squashfs.txt @@ -22,7 +22,7 @@ Squashfs filesystem features versus Cramfs: Squashfs Cramfs -Max filesystem size: 2^64 16 MiB +Max filesystem size: 2^64 256 MiB Max file size: ~ 2 TiB 16 MiB Max files: unlimited unlimited Max directories: unlimited unlimited -- cgit v1.1 From 753b7aea8e4611433c13ac157f944d8b4bf42482 Mon Sep 17 00:00:00 2001 From: Dave Jones Date: Mon, 9 Mar 2009 15:14:37 -0400 Subject: [CPUFREQ] Add p4-clockmod sysfs-ui removal to feature-removal schedule. Signed-off-by: Matthew Garrett Signed-off-by: Dave Jones --- Documentation/feature-removal-schedule.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 5ddbe35..20d3b94 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -335,3 +335,12 @@ Why: In 2.6.18 the Secmark concept was introduced to replace the "compat_net" Secmark, it is time to deprecate the older mechanism and start the process of removing the old code. Who: Paul Moore +--------------------------- + +What: sysfs ui for changing p4-clockmod parameters +When: September 2009 +Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and + e088e4c9cdb618675874becb91b2fd581ee707e6. + Removal is subject to fixing any remaining bugs in ACPI which may + cause the thermal throttling not to happen at the right time. +Who: Dave Jones , Matthew Garrett -- cgit v1.1 From 0612ea00a010e36fde61e7b7649a1105b0ef1080 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Tue, 10 Mar 2009 12:55:57 -0700 Subject: rcu: documentation 1Q09 update Update the RCU documentation to call out the need for callers of primitives like call_rcu() and synchronize_rcu() to prevent subsequent RCU readers from hazard. Signed-off-by: Paul E. McKenney Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/RCU/checklist.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 6e25340..accfe2f 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -298,3 +298,15 @@ over a rather long period of time, but improvements are always welcome! Note that, rcu_assign_pointer() and rcu_dereference() relate to SRCU just as they do to other forms of RCU. + +15. The whole point of call_rcu(), synchronize_rcu(), and friends + is to wait until all pre-existing readers have finished before + carrying out some otherwise-destructive operation. It is + therefore critically important to -first- remove any path + that readers can follow that could be affected by the + destructive operation, and -only- -then- invoke call_rcu(), + synchronize_rcu(), or friends. + + Because these primitives only wait for pre-existing readers, + it is the caller's responsibility to guarantee safety to + any subsequent readers. -- cgit v1.1 From 1a51e068c900eb6ea23ce597361ebf3b19a57b23 Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" Date: Thu, 12 Mar 2009 13:36:38 +0100 Subject: hwmon: (lm90) Document support for the MAX6648/6692 chips Update documentation to prevent further confusion/duplication. Signed-off-by: Darrick J. Wong Signed-off-by: Jean Delvare --- Documentation/hwmon/lm90 | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90 index 0e84117..93d8e3d 100644 --- a/Documentation/hwmon/lm90 +++ b/Documentation/hwmon/lm90 @@ -42,6 +42,11 @@ Supported chips: Addresses scanned: I2C 0x4e Datasheet: Publicly available at the Maxim website http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3497 + * Maxim MAX6648 + Prefix: 'max6646' + Addresses scanned: I2C 0x4c + Datasheet: Publicly available at the Maxim website + http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500 * Maxim MAX6649 Prefix: 'max6646' Addresses scanned: I2C 0x4c @@ -74,6 +79,11 @@ Supported chips: 0x4c, 0x4d and 0x4e Datasheet: Publicly available at the Maxim website http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370 + * Maxim MAX6692 + Prefix: 'max6646' + Addresses scanned: I2C 0x4c + Datasheet: Publicly available at the Maxim website + http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500 Author: Jean Delvare -- cgit v1.1 From ab03eca8d4754ef2ba9821d581975b10b8f317e7 Mon Sep 17 00:00:00 2001 From: Jody McIntyre Date: Thu, 12 Mar 2009 17:39:23 -0400 Subject: trivial: fix bad links in the ext2 and ext3 documentation Trivial patch to fix bad links in the ext2 and ext3 documentation. Signed-off-by: Jody McIntyre Signed-off-by: Linus Torvalds --- Documentation/filesystems/ext2.txt | 10 +++++----- Documentation/filesystems/ext3.txt | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt index 4333e83..2344855 100644 --- a/Documentation/filesystems/ext2.txt +++ b/Documentation/filesystems/ext2.txt @@ -373,10 +373,10 @@ Filesystem Resizing http://ext2resize.sourceforge.net/ Compression (*) http://e2compr.sourceforge.net/ Implementations for: -Windows 95/98/NT/2000 http://uranus.it.swin.edu.au/~jn/linux/Explore2fs.htm -Windows 95 (*) http://www.yipton.demon.co.uk/content.html#FSDEXT2 +Windows 95/98/NT/2000 http://www.chrysocome.net/explore2fs +Windows 95 (*) http://www.yipton.net/content.html#FSDEXT2 DOS client (*) ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/ -OS/2 http://perso.wanadoo.fr/matthieu.willm/ext2-os2/ -RISC OS client ftp://ftp.barnet.ac.uk/pub/acorn/armlinux/iscafs/ +OS/2 (*) ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/ +RISC OS client http://www.esw-heim.tu-clausthal.de/~marco/smorbrod/IscaFS/ -(*) no longer actively developed/supported (as of Apr 2001) +(*) no longer actively developed/supported (as of Mar 2009) diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 9dd2a3bb..e5f3833 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -198,5 +198,5 @@ kernel source: programs: http://e2fsprogs.sourceforge.net/ http://ext2resize.sourceforge.net -useful links: http://www-106.ibm.com/developerworks/linux/library/l-fs7/ - http://www-106.ibm.com/developerworks/linux/library/l-fs8/ +useful links: http://www.ibm.com/developerworks/library/l-fs7.html + http://www.ibm.com/developerworks/library/l-fs8.html -- cgit v1.1