diff --git a/[refs] b/[refs] index 44b55ef3353f..c14501d4a182 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 2f41fc806434f8466bb361570589a3f6099ca65d +refs/heads/master: 904f7a3f042b5c6aa9e53ce83f2c9de5e33170ff diff --git a/trunk/CREDITS b/trunk/CREDITS index 79fd13dbb8e4..273d72b610c3 100644 --- a/trunk/CREDITS +++ b/trunk/CREDITS @@ -3301,6 +3301,14 @@ S: 12725 SW Millikan Way, Suite 400 S: Beaverton, Oregon 97005 S: USA +N: Li Yang +E: leoli@freescale.com +D: Freescale Highspeed USB device driver +D: Freescale QE SoC support and Ethernet driver +S: B-1206 Jingmao Guojigongyu +S: 16 Baliqiao Nanjie, Beijing 101100 +S: People's Repulic of China + N: Marcelo Tosatti E: marcelo@kvack.org D: v2.4 kernel maintainer @@ -3718,14 +3726,6 @@ S: 542 West 112th Street, 5N S: New York, New York 10025 S: USA -N: Li Yang -E: leoli@freescale.com -D: Freescale Highspeed USB device driver -D: Freescale QE SoC support and Ethernet driver -S: B-1206 Jingmao Guojigongyu -S: 16 Baliqiao Nanjie, Beijing 101100 -S: People's Repulic of China - N: Victor Yodaiken E: yodaiken@fsmlabs.com D: RTLinux (RealTime Linux) diff --git a/trunk/Documentation/ABI/removed/raw1394_legacy_isochronous b/trunk/Documentation/ABI/removed/raw1394_legacy_isochronous deleted file mode 100644 index 1b629622d883..000000000000 --- a/trunk/Documentation/ABI/removed/raw1394_legacy_isochronous +++ /dev/null @@ -1,16 +0,0 @@ -What: legacy isochronous ABI of raw1394 (1st generation iso ABI) -Date: June 2007 (scheduled), removed in kernel v2.6.23 -Contact: linux1394-devel@lists.sourceforge.net -Description: - The two request types RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN have - been deprecated for quite some time. They are very inefficient as they - come with high interrupt load and several layers of callbacks for each - packet. Because of these deficiencies, the video1394 and dv1394 drivers - and the 3rd-generation isochronous ABI in raw1394 (rawiso) were created. - -Users: - libraw1394 users via the long deprecated API raw1394_iso_write, - raw1394_start_iso_write, raw1394_start_iso_rcv, raw1394_stop_iso_rcv - - libdc1394, which optionally uses these old libraw1394 calls - alternatively to the more efficient video1394 ABI diff --git a/trunk/Documentation/BUG-HUNTING b/trunk/Documentation/BUG-HUNTING index 35f5bd243336..65b97e1dbf70 100644 --- a/trunk/Documentation/BUG-HUNTING +++ b/trunk/Documentation/BUG-HUNTING @@ -191,30 +191,6 @@ e.g. crash dump output as shown by Dave Miller. > mov 0x8(%ebp), %ebx ! %ebx = skb->sk > mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt -In addition, you can use GDB to figure out the exact file and line -number of the OOPS from the vmlinux file. If you have -CONFIG_DEBUG_INFO enabled, you can simply copy the EIP value from the -OOPS: - - EIP: 0060:[] Not tainted VLI - -And use GDB to translate that to human-readable form: - - gdb vmlinux - (gdb) l *0xc021e50e - -If you don't have CONFIG_DEBUG_INFO enabled, you use the function -offset from the OOPS: - - EIP is at vt_ioctl+0xda8/0x1482 - -And recompile the kernel with CONFIG_DEBUG_INFO enabled: - - make vmlinux - gdb vmlinux - (gdb) p vt_ioctl - (gdb) l *(0x
+ 0xda8) - Another very useful option of the Kernel Hacking section in menuconfig is Debug memory allocations. This will help you see whether data has been initialised and not set before use etc. To see the values that get assigned diff --git a/trunk/Documentation/CodingStyle b/trunk/Documentation/CodingStyle index b49b92edb396..afc286775891 100644 --- a/trunk/Documentation/CodingStyle +++ b/trunk/Documentation/CodingStyle @@ -495,40 +495,29 @@ re-formatting you may want to take a look at the man page. But remember: "indent" is not a fix for bad programming. - Chapter 10: Kconfig configuration files + Chapter 10: Configuration-files -For all of the Kconfig* configuration files throughout the source tree, -the indentation is somewhat different. Lines under a "config" definition -are indented with one tab, while help text is indented an additional two -spaces. Example: +For configuration options (arch/xxx/Kconfig, and all the Kconfig files), +somewhat different indentation is used. -config AUDIT - bool "Auditing support" - depends on NET - help - Enable auditing infrastructure that can be used with another - kernel subsystem, such as SELinux (which requires this for - logging of avc messages output). Does not do system-call - auditing without CONFIG_AUDITSYSCALL. - -Features that might still be considered unstable should be defined as -dependent on "EXPERIMENTAL": - -config SLUB - depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT - bool "SLUB (Unqueued Allocator)" - ... +Help text is indented with 2 spaces. -while seriously dangerous features (such as write support for certain -filesystems) should advertise this prominently in their prompt string: - -config ADFS_FS_RW - bool "ADFS write support (DANGEROUS)" - depends on ADFS_FS - ... +if CONFIG_EXPERIMENTAL + tristate CONFIG_BOOM + default n + help + Apply nitroglycerine inside the keyboard (DANGEROUS) + bool CONFIG_CHEER + depends on CONFIG_BOOM + default y + help + Output nice messages when you explode +endif -For full documentation on the configuration files, see the file -Documentation/kbuild/kconfig-language.txt. +Generally, CONFIG_EXPERIMENTAL should surround all options not considered +stable. All options that are known to trash data (experimental write- +support for file-systems, for instance) should be denoted (DANGEROUS), other +experimental options should be denoted (EXPERIMENTAL). Chapter 11: Data structures diff --git a/trunk/Documentation/DMA-mapping.txt b/trunk/Documentation/DMA-mapping.txt index e07f2530326b..028614cdd062 100644 --- a/trunk/Documentation/DMA-mapping.txt +++ b/trunk/Documentation/DMA-mapping.txt @@ -664,6 +664,109 @@ It is that simple. Well, not for some odd devices. See the next section for information about that. + DAC Addressing for Address Space Hungry Devices + +There exists a class of devices which do not mesh well with the PCI +DMA mapping API. By definition these "mappings" are a finite +resource. The number of total available mappings per bus is platform +specific, but there will always be a reasonable amount. + +What is "reasonable"? Reasonable means that networking and block I/O +devices need not worry about using too many mappings. + +As an example of a problematic device, consider compute cluster cards. +They can potentially need to access gigabytes of memory at once via +DMA. Dynamic mappings are unsuitable for this kind of access pattern. + +To this end we've provided a small API by which a device driver +may use DAC cycles to directly address all of physical memory. +Not all platforms support this, but most do. It is easy to determine +whether the platform will work properly at probe time. + +First, understand that there may be a SEVERE performance penalty for +using these interfaces on some platforms. Therefore, you MUST only +use these interfaces if it is absolutely required. %99 of devices can +use the normal APIs without any problems. + +Note that for streaming type mappings you must either use these +interfaces, or the dynamic mapping interfaces above. You may not mix +usage of both for the same device. Such an act is illegal and is +guaranteed to put a banana in your tailpipe. + +However, consistent mappings may in fact be used in conjunction with +these interfaces. Remember that, as defined, consistent mappings are +always going to be SAC addressable. + +The first thing your driver needs to do is query the PCI platform +layer if it is capable of handling your devices DAC addressing +capabilities: + + int pci_dac_dma_supported(struct pci_dev *hwdev, u64 mask); + +You may not use the following interfaces if this routine fails. + +Next, DMA addresses using this API are kept track of using the +dma64_addr_t type. It is guaranteed to be big enough to hold any +DAC address the platform layer will give to you from the following +routines. If you have consistent mappings as well, you still +use plain dma_addr_t to keep track of those. + +All mappings obtained here will be direct. The mappings are not +translated, and this is the purpose of this dialect of the DMA API. + +All routines work with page/offset pairs. This is the _ONLY_ way to +portably refer to any piece of memory. If you have a cpu pointer +(which may be validly DMA'd too) you may easily obtain the page +and offset using something like this: + + struct page *page = virt_to_page(ptr); + unsigned long offset = offset_in_page(ptr); + +Here are the interfaces: + + dma64_addr_t pci_dac_page_to_dma(struct pci_dev *pdev, + struct page *page, + unsigned long offset, + int direction); + +The DAC address for the tuple PAGE/OFFSET are returned. The direction +argument is the same as for pci_{map,unmap}_single(). The same rules +for cpu/device access apply here as for the streaming mapping +interfaces. To reiterate: + + The cpu may touch the buffer before pci_dac_page_to_dma. + The device may touch the buffer after pci_dac_page_to_dma + is made, but the cpu may NOT. + +When the DMA transfer is complete, invoke: + + void pci_dac_dma_sync_single_for_cpu(struct pci_dev *pdev, + dma64_addr_t dma_addr, + size_t len, int direction); + +This must be done before the CPU looks at the buffer again. +This interface behaves identically to pci_dma_sync_{single,sg}_for_cpu(). + +And likewise, if you wish to let the device get back at the buffer after +the cpu has read/written it, invoke: + + void pci_dac_dma_sync_single_for_device(struct pci_dev *pdev, + dma64_addr_t dma_addr, + size_t len, int direction); + +before letting the device access the DMA area again. + +If you need to get back to the PAGE/OFFSET tuple from a dma64_addr_t +the following interfaces are provided: + + struct page *pci_dac_dma_to_page(struct pci_dev *pdev, + dma64_addr_t dma_addr); + unsigned long pci_dac_dma_to_offset(struct pci_dev *pdev, + dma64_addr_t dma_addr); + +This is possible with the DAC interfaces purely because they are +not translated in any way. + Optimizing Unmap State Space Consumption On many platforms, pci_unmap_{single,page}() is simply a nop. diff --git a/trunk/Documentation/DocBook/gadget.tmpl b/trunk/Documentation/DocBook/gadget.tmpl index 6996d977bf8f..e7fc96433408 100644 --- a/trunk/Documentation/DocBook/gadget.tmpl +++ b/trunk/Documentation/DocBook/gadget.tmpl @@ -52,7 +52,7 @@ -Introduction +Introduction This document presents a Linux-USB "Gadget" kernel mode diff --git a/trunk/Documentation/DocBook/kernel-api.tmpl b/trunk/Documentation/DocBook/kernel-api.tmpl index 46bcff2849bd..38f88b6ae405 100644 --- a/trunk/Documentation/DocBook/kernel-api.tmpl +++ b/trunk/Documentation/DocBook/kernel-api.tmpl @@ -643,70 +643,4 @@ X!Idrivers/video/console/fonts.c !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 - - - - splice API - ) - splice is a method for moving blocks of data around inside the - kernel, without continually transferring it between the kernel - and user space. - -!Iinclude/linux/splice.h -!Ffs/splice.c - - - diff --git a/trunk/Documentation/DocBook/kernel-locking.tmpl b/trunk/Documentation/DocBook/kernel-locking.tmpl index 0a441f73261a..644c3884fab9 100644 --- a/trunk/Documentation/DocBook/kernel-locking.tmpl +++ b/trunk/Documentation/DocBook/kernel-locking.tmpl @@ -551,12 +551,10 @@ spin_lock_irqsave(), which is a superset of all other spinlock primitives. - Table of Locking Requirements - IRQ Handler A @@ -578,128 +576,97 @@ IRQ Handler B -SLIS +spin_lock_irqsave None Softirq A -SLI -SLI -SL +spin_lock_irq +spin_lock_irq +spin_lock Softirq B -SLI -SLI -SL -SL +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock Tasklet A -SLI -SLI -SL -SL +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock None Tasklet B -SLI -SLI -SL -SL -SL +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock +spin_lock None Timer A -SLI -SLI -SL -SL -SL -SL +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock +spin_lock +spin_lock None Timer B -SLI -SLI -SL -SL -SL -SL -SL +spin_lock_irq +spin_lock_irq +spin_lock +spin_lock +spin_lock +spin_lock +spin_lock None User Context A -SLI -SLI -SLBH -SLBH -SLBH -SLBH -SLBH -SLBH +spin_lock_irq +spin_lock_irq +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh None User Context B -SLI -SLI -SLBH -SLBH -SLBH -SLBH -SLBH -SLBH -DI -None - - - - -
- - -Legend for Locking Requirements Table - - - - -SLIS -spin_lock_irqsave - - -SLI spin_lock_irq - - -SL -spin_lock - - -SLBH +spin_lock_irq +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh +spin_lock_bh spin_lock_bh - - -DI down_interruptible +None
- diff --git a/trunk/Documentation/DocBook/usb.tmpl b/trunk/Documentation/DocBook/usb.tmpl index af293606fbe3..a2ebd651b05a 100644 --- a/trunk/Documentation/DocBook/usb.tmpl +++ b/trunk/Documentation/DocBook/usb.tmpl @@ -185,7 +185,7 @@ -USB-Standard Types +USB-Standard Types In <linux/usb/ch9.h> you will find the USB data types defined in chapter 9 of the USB specification. @@ -197,7 +197,7 @@ -Host-Side Data Types and Macros +Host-Side Data Types and Macros The host side API exposes several layers to drivers, some of which are more necessary than others. @@ -211,7 +211,7 @@ - USB Core APIs + USB Core APIs There are two basic I/O models in the USB API. The most elemental one is asynchronous: drivers submit requests @@ -248,7 +248,7 @@ !Edrivers/usb/core/hub.c - Host Controller APIs + Host Controller APIs These APIs are only for use by host controller drivers, most of which implement standard register interfaces such as @@ -285,7 +285,7 @@ !Idrivers/usb/core/buffer.c - + The USB Filesystem (usbfs) This chapter presents the Linux usbfs. @@ -317,7 +317,7 @@ not it has a kernel driver. - + What files are in "usbfs"? Conventionally mounted at @@ -356,7 +356,7 @@ - + Mounting and Access Control There are a number of mount options for usbfs, which will @@ -439,7 +439,7 @@ - + /proc/bus/usb/devices This file is handy for status viewing tools in user @@ -473,7 +473,7 @@ for (;;) { - + /proc/bus/usb/BBB/DDD Use these files in one of these basic ways: @@ -510,7 +510,7 @@ for (;;) { - + Life Cycle of User Mode Drivers Such a driver first needs to find a device file @@ -565,7 +565,7 @@ for (;;) { - The ioctl() Requests + The ioctl() Requests To use these ioctls, you need to include the following headers in your userspace program: @@ -604,7 +604,7 @@ for (;;) { - + Management/Status Requests A number of usbfs requests don't deal very directly @@ -736,7 +736,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) - + Synchronous I/O Support Synchronous requests involve the kernel blocking @@ -865,7 +865,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) - + Asynchronous I/O Support As mentioned above, there are situations where it may be diff --git a/trunk/Documentation/HOWTO b/trunk/Documentation/HOWTO index 98e2701c746f..48123dba5e6a 100644 --- a/trunk/Documentation/HOWTO +++ b/trunk/Documentation/HOWTO @@ -322,34 +322,39 @@ kernel releases as described above. Here is a list of some of the different kernel trees available: git trees: - Kbuild development tree, Sam Ravnborg - git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git + kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git - ACPI development tree, Len Brown - git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git + kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git - Block development tree, Jens Axboe - git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git + kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git - DRM development tree, Dave Airlie - git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git + kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git - ia64 development tree, Tony Luck - git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git + kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git + + - ieee1394 development tree, Jody McIntyre + kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git - infiniband, Roland Dreier - git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git + kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git - libata, Jeff Garzik - git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git + kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git - network drivers, Jeff Garzik - git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git + kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git - pcmcia, Dominik Brodowski - git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git + kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git - SCSI, James Bottomley - git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git + kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git + + Other git kernel trees can be found listed at http://kernel.org/git quilt trees: - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman @@ -357,9 +362,6 @@ Here is a list of some of the different kernel trees available: - x86-64, partly i386, Andi Kleen ftp.firstfloor.org:/pub/ak/x86_64/quilt/ - Other kernel trees can be found listed at http://git.kernel.org/ and in - the MAINTAINERS file. - Bug Reporting ------------- @@ -394,6 +396,26 @@ bugme-janitor mailing list (every change in the bugzilla is mailed here) +Managing bug reports +-------------------- + +One of the best ways to put into practice your hacking skills is by fixing +bugs reported by other people. Not only you will help to make the kernel +more stable, you'll learn to fix real world problems and you will improve +your skills, and other developers will be aware of your presence. Fixing +bugs is one of the best ways to get merits among other developers, because +not many people like wasting time fixing other people's bugs. + +To work in the already reported bug reports, go to http://bugzilla.kernel.org. +If you want to be advised of the future bug reports, you can subscribe to the +bugme-new mailing list (only new bug reports are mailed here) or to the +bugme-janitor mailing list (every change in the bugzilla is mailed here) + + http://lists.osdl.org/mailman/listinfo/bugme-new + http://lists.osdl.org/mailman/listinfo/bugme-janitors + + + Mailing lists ------------- diff --git a/trunk/Documentation/SM501.txt b/trunk/Documentation/SM501.txt deleted file mode 100644 index 3a1bd95d3767..000000000000 --- a/trunk/Documentation/SM501.txt +++ /dev/null @@ -1,66 +0,0 @@ - SM501 Driver - ============ - -Copyright 2006, 2007 Simtec Electronics - -Core ----- - -The core driver in drivers/mfd provides common services for the -drivers which manage the specific hardware blocks. These services -include locking for common registers, clock control and resource -management. - -The core registers drivers for both PCI and generic bus based -chips via the platform device and driver system. - -On detection of a device, the core initialises the chip (which may -be specified by the platform data) and then exports the selected -peripheral set as platform devices for the specific drivers. - -The core re-uses the platform device system as the platform device -system provides enough features to support the drivers without the -need to create a new bus-type and the associated code to go with it. - - -Resources ---------- - -Each peripheral has a view of the device which is implicitly narrowed to -the specific set of resources that peripheral requires in order to -function correctly. - -The centralised memory allocation allows the driver to ensure that the -maximum possible resource allocation can be made to the video subsystem -as this is by-far the most resource-sensitive of the on-chip functions. - -The primary issue with memory allocation is that of moving the video -buffers once a display mode is chosen. Indeed when a video mode change -occurs the memory footprint of the video subsystem changes. - -Since video memory is difficult to move without changing the display -(unless sufficient contiguous memory can be provided for the old and new -modes simultaneously) the video driver fully utilises the memory area -given to it by aligning fb0 to the start of the area and fb1 to the end -of it. Any memory left over in the middle is used for the acceleration -functions, which are transient and thus their location is less critical -as it can be moved. - - -Configuration -------------- - -The platform device driver uses a set of platform data to pass -configurations through to the core and the subsidiary drivers -so that there can be support for more than one system carrying -an SM501 built into a single kernel image. - -The PCI driver assumes that the PCI card behaves as per the Silicon -Motion reference design. - -There is an errata (AB-5) affecting the selection of the -of the M1XCLK and M1CLK frequencies. These two clocks -must be sourced from the same PLL, although they can then -be divided down individually. If this is not set, then SM501 may -lock and hang the whole system. The driver will refuse to -attach if the PLL selection is different. diff --git a/trunk/Documentation/SubmitChecklist b/trunk/Documentation/SubmitChecklist index 6ebffb57e3db..3af3e65cf43b 100644 --- a/trunk/Documentation/SubmitChecklist +++ b/trunk/Documentation/SubmitChecklist @@ -84,9 +84,3 @@ kernel patches. 24: Avoid whitespace damage such as indenting with spaces or whitespace at the end of lines. You can test this by feeding the patch to "git apply --check --whitespace=error-all" - -25: Check your patch for general style as detailed in - Documentation/CodingStyle. Check for trivial violations with the - patch style checker prior to submission (scripts/checkpatch.pl). - You should be able to justify all violations that remain in - your patch. diff --git a/trunk/Documentation/SubmittingPatches b/trunk/Documentation/SubmittingPatches index 0958e97d4bf4..a417b25fb1aa 100644 --- a/trunk/Documentation/SubmittingPatches +++ b/trunk/Documentation/SubmittingPatches @@ -118,20 +118,7 @@ then only post say 15 or so at a time and wait for review and integration. -4) Style check your changes. - -Check your patch for basic style violations, details of which can be -found in Documentation/CodingStyle. Failure to do so simply wastes -the reviewers time and will get your patch rejected, probabally -without even being read. - -At a minimum you should check your patches with the patch style -checker prior to submission (scripts/patchcheck.pl). You should -be able to justify all violations that remain in your patch. - - - -5) Select e-mail destination. +4) Select e-mail destination. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with @@ -159,7 +146,7 @@ discussed should the patch then be submitted to Linus. -6) Select your CC (e-mail carbon copy) list. +5) Select your CC (e-mail carbon copy) list. Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org. @@ -200,7 +187,8 @@ URL: -7) No MIME, no links, no compression, no attachments. Just plain text. + +6) No MIME, no links, no compression, no attachments. Just plain text. Linus and other kernel developers need to be able to read and comment on the changes you are submitting. It is important for a kernel @@ -235,9 +223,9 @@ pref("mailnews.display.disable_format_flowed_support", true); -8) E-mail size. +7) E-mail size. -When sending patches to Linus, always follow step #7. +When sending patches to Linus, always follow step #6. Large changes are not appropriate for mailing lists, and some maintainers. If your patch, uncompressed, exceeds 40 kB in size, @@ -246,7 +234,7 @@ server, and provide instead a URL (link) pointing to your patch. -9) Name your kernel version. +8) Name your kernel version. It is important to note, either in the subject line or in the patch description, the kernel version to which this patch applies. @@ -256,7 +244,7 @@ Linus will not apply it. -10) Don't get discouraged. Re-submit. +9) Don't get discouraged. Re-submit. After you have submitted your change, be patient and wait. If Linus likes your change and applies it, it will appear in the next version @@ -282,7 +270,7 @@ When in doubt, solicit comments on linux-kernel mailing list. -11) Include PATCH in the subject +10) Include PATCH in the subject Due to high e-mail traffic to Linus, and to linux-kernel, it is common convention to prefix your subject line with [PATCH]. This lets Linus @@ -291,7 +279,7 @@ e-mail discussions. -12) Sign your work +11) Sign your work To improve tracking of who did what, especially with patches that can percolate to their final resting place in the kernel through several @@ -340,32 +328,7 @@ now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. -13) When to use Acked-by: - -The Signed-off-by: tag indicates that the signer was involved in the -development of the patch, or that he/she was in the patch's delivery path. - -If a person was not directly involved in the preparation or handling of a -patch but wishes to signify and record their approval of it then they can -arrange to have an Acked-by: line added to the patch's changelog. - -Acked-by: is often used by the maintainer of the affected code when that -maintainer neither contributed to nor forwarded the patch. - -Acked-by: is not as formal as Signed-off-by:. It is a record that the acker -has at least reviewed the patch and has indicated acceptance. Hence patch -mergers will sometimes manually convert an acker's "yep, looks good to me" -into an Acked-by:. - -Acked-by: does not necessarily indicate acknowledgement of the entire patch. -For example, if a patch affects multiple subsystems and has an Acked-by: from -one subsystem maintainer then this usually indicates acknowledgement of just -the part which affects that maintainer's code. Judgement should be used here. - When in doubt people should refer to the original discussion in the mailing -list archives. - - -14) The canonical patch format +12) The canonical patch format The canonical patch subject line is: @@ -464,10 +427,6 @@ section Linus Computer Science 101. Nuff said. If your code deviates too much from this, it is likely to be rejected without further review, and without comment. -Check your patches with the patch style checker prior to submission -(scripts/checkpatch.pl). You should be able to justify all -violations that remain in your patch. - 2) #ifdefs are ugly diff --git a/trunk/Documentation/atomic_ops.txt b/trunk/Documentation/atomic_ops.txt index 05851e9982ed..2a63d5662a93 100644 --- a/trunk/Documentation/atomic_ops.txt +++ b/trunk/Documentation/atomic_ops.txt @@ -149,7 +149,7 @@ defined which accomplish this: void smp_mb__before_atomic_dec(void); void smp_mb__after_atomic_dec(void); void smp_mb__before_atomic_inc(void); - void smp_mb__after_atomic_inc(void); + void smp_mb__after_atomic_dec(void); For example, smp_mb__before_atomic_dec() can be used like so: diff --git a/trunk/Documentation/blackfin/kgdb.txt b/trunk/Documentation/blackfin/kgdb.txt deleted file mode 100644 index 84f6a484ae9a..000000000000 --- a/trunk/Documentation/blackfin/kgdb.txt +++ /dev/null @@ -1,155 +0,0 @@ - A Simple Guide to Configure KGDB - - Sonic Zhang - Aug. 24th 2006 - - -This KGDB patch enables the kernel developer to do source level debugging on -the kernel for the Blackfin architecture. The debugging works over either the -ethernet interface or one of the uarts. Both software breakpoints and -hardware breakpoints are supported in this version. -http://docs.blackfin.uclinux.org/doku.php?id=kgdb - - -2 known issues: -1. This bug: - http://blackfin.uclinux.org/tracker/index.php?func=detail&aid=544&group_id=18&atid=145 - The GDB client for Blackfin uClinux causes incorrect values of local - variables to be displayed when the user breaks the running of kernel in GDB. -2. Because of a hardware bug in Blackfin 533 v1.0.3: - 05000067 - Watchpoints (Hardware Breakpoints) are not supported - Hardware breakpoints cannot be set properly. - - -Debug over Ethernet: - -1. Compile and install the cross platform version of gdb for blackfin, which - can be found at $(BINROOT)/bfin-elf-gdb. - -2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under - "Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb". - With this selected, option "Full Symbolic/Source Debugging support" and - "Compile the kernel with frame pointers" are also selected. - -3. Select option "KGDB: connect over (Ethernet)". Add "kgdboe=@target-IP/,@host-IP/" to - the option "Compiled-in Kernel Boot Parameter" under "Kernel hacking". - -4. Connect minicom to the serial port and boot the kernel image. - -5. Configure the IP "/> ifconfig eth0 target-IP" - -6. Start GDB client "bfin-elf-gdb vmlinux". - -7. Connect to the target "(gdb) target remote udp:target-IP:6443". - -8. Set software breakpoint "(gdb) break sys_open". - -9. Continue "(gdb) c". - -10. Run ls in the target console "/> ls". - -11. Breakpoint hits. "Breakpoint 1: sys_open(..." - -12. Display local variables and function paramters. - (*) This operation gives wrong results, see known issue 1. - -13. Single stepping "(gdb) si". - -14. Remove breakpoint 1. "(gdb) del 1" - -15. Set hardware breakpoint "(gdb) hbreak sys_open". - -16. Continue "(gdb) c". - -17. Run ls in the target console "/> ls". - -18. Hardware breakpoint hits. "Breakpoint 1: sys_open(...". - (*) This hardware breakpoint will not be hit, see known issue 2. - -19. Continue "(gdb) c". - -20. Interrupt the target in GDB "Ctrl+C". - -21. Detach from the target "(gdb) detach". - -22. Exit GDB "(gdb) quit". - - -Debug over the UART: - -1. Compile and install the cross platform version of gdb for blackfin, which - can be found at $(BINROOT)/bfin-elf-gdb. - -2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under - "Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb". - With this selected, option "Full Symbolic/Source Debugging support" and - "Compile the kernel with frame pointers" are also selected. - -3. Select option "KGDB: connect over (UART)". Set "KGDB: UART port number" to be - a different one from the console. Don't forget to change the mode of - blackfin serial driver to PIO. Otherwise kgdb works incorrectly on UART. - -4. If you want connect to kgdb when the kernel boots, enable - "KGDB: Wait for gdb connection early" - -5. Compile kernel. - -6. Connect minicom to the serial port of the console and boot the kernel image. - -7. Start GDB client "bfin-elf-gdb vmlinux". - -8. Set the baud rate in GDB "(gdb) set remotebaud 57600". - -9. Connect to the target on the second serial port "(gdb) target remote /dev/ttyS1". - -10. Set software breakpoint "(gdb) break sys_open". - -11. Continue "(gdb) c". - -12. Run ls in the target console "/> ls". - -13. A breakpoint is hit. "Breakpoint 1: sys_open(..." - -14. All other operations are the same as that in KGDB over Ethernet. - - -Debug over the same UART as console: - -1. Compile and install the cross platform version of gdb for blackfin, which - can be found at $(BINROOT)/bfin-elf-gdb. - -2. Apply this patch to the 2.6.x kernel. Select the menuconfig option under - "Kernel hacking" -> "Kernel debugging" -> "KGDB: kernel debug with remote gdb". - With this selected, option "Full Symbolic/Source Debugging support" and - "Compile the kernel with frame pointers" are also selected. - -3. Select option "KGDB: connect over UART". Set "KGDB: UART port number" to console. - Don't forget to change the mode of blackfin serial driver to PIO. - Otherwise kgdb works incorrectly on UART. - -4. If you want connect to kgdb when the kernel boots, enable - "KGDB: Wait for gdb connection early" - -5. Connect minicom to the serial port and boot the kernel image. - -6. (Optional) Ask target to wait for gdb connection by entering Ctrl+A. In minicom, you should enter Ctrl+A+A. - -7. Start GDB client "bfin-elf-gdb vmlinux". - -8. Set the baud rate in GDB "(gdb) set remotebaud 57600". - -9. Connect to the target "(gdb) target remote /dev/ttyS0". - -10. Set software breakpoint "(gdb) break sys_open". - -11. Continue "(gdb) c". Then enter Ctrl+C twice to stop GDB connection. - -12. Run ls in the target console "/> ls". Dummy string can be seen on the console. - -13. Then connect the gdb to target again. "(gdb) target remote /dev/ttyS0". - Now you will find a breakpoint is hit. "Breakpoint 1: sys_open(..." - -14. All other operations are the same as that in KGDB over Ethernet. The only - difference is that after continue command in GDB, please stop GDB - connection by 2 "Ctrl+C"s and connect again after breakpoints are hit or - Ctrl+A is entered. diff --git a/trunk/Documentation/block/barrier.txt b/trunk/Documentation/block/barrier.txt index 7d279f2f5bb2..a272c3db8094 100644 --- a/trunk/Documentation/block/barrier.txt +++ b/trunk/Documentation/block/barrier.txt @@ -82,12 +82,23 @@ including draining and flushing. typedef void (prepare_flush_fn)(request_queue_t *q, struct request *rq); int blk_queue_ordered(request_queue_t *q, unsigned ordered, - prepare_flush_fn *prepare_flush_fn); + prepare_flush_fn *prepare_flush_fn, + unsigned gfp_mask); + +int blk_queue_ordered_locked(request_queue_t *q, unsigned ordered, + prepare_flush_fn *prepare_flush_fn, + unsigned gfp_mask); + +The only difference between the two functions is whether or not the +caller is holding q->queue_lock on entry. The latter expects the +caller is holding the lock. @q : the queue in question @ordered : the ordered mode the driver/device supports @prepare_flush_fn : this function should prepare @rq such that it flushes cache to physical medium when executed +@gfp_mask : gfp_mask used when allocating data structures + for ordered processing For example, SCSI disk driver's prepare_flush_fn looks like the following. @@ -95,10 +106,9 @@ following. static void sd_prepare_flush(request_queue_t *q, struct request *rq) { memset(rq->cmd, 0, sizeof(rq->cmd)); - rq->cmd_type = REQ_TYPE_BLOCK_PC; + rq->flags |= REQ_BLOCK_PC; rq->timeout = SD_TIMEOUT; rq->cmd[0] = SYNCHRONIZE_CACHE; - rq->cmd_len = 10; } The following seven ordered modes are supported. The following table diff --git a/trunk/Documentation/block/capability.txt b/trunk/Documentation/block/capability.txt deleted file mode 100644 index 2f1729424ef4..000000000000 --- a/trunk/Documentation/block/capability.txt +++ /dev/null @@ -1,15 +0,0 @@ -Generic Block Device Capability -=============================================================================== -This file documents the sysfs file block//capability - -capability is a hex word indicating which capabilities a specific disk -supports. For more information on bits not listed here, see -include/linux/genhd.h - -Capability Value -------------------------------------------------------------------------------- -GENHD_FL_MEDIA_CHANGE_NOTIFY 4 - When this bit is set, the disk supports Asynchronous Notification - of media change events. These events will be broadcast to user - space via kernel uevent. - diff --git a/trunk/Documentation/dontdiff b/trunk/Documentation/dontdiff index 595a5ea4c690..64e9f6c4826b 100644 --- a/trunk/Documentation/dontdiff +++ b/trunk/Documentation/dontdiff @@ -10,12 +10,10 @@ *.grp *.gz *.html -*.i *.jpeg *.ko *.log *.lst -*.moc *.mod.c *.o *.orig @@ -27,9 +25,6 @@ *.s *.sgml *.so -*.symtypes -*.tab.c -*.tab.h *.tex *.ver *.xml @@ -37,13 +32,9 @@ *_vga16.c *cscope* *~ -*.9 -*.9.gz .* .cscope 53c700_d.h -53c7xx_d.h -53c7xx_u.h 53c8xx_d.h* BitKeeper COPYING @@ -79,11 +70,9 @@ bzImage* classlist.h* comp*.log compile.h* -conf config config-* config_data.h* -config_data.gz* conmakehash consolemap_deftbl.c* crc32table.h* @@ -92,23 +81,18 @@ defkeymap.c* devlist.h* docproc dummy_sym.c* -elf2ecoff elfconfig.h* filelist fixdep fore200e_mkfirm fore200e_pca_fw.c* -gconf gen-devlist gen-kdb_cmds.c* gen_crc32table gen_init_cpio genksyms gentbl -*_gray256.c ikconfig.h* -initramfs_data.cpio -initramfs_data.cpio.gz initramfs_list kallsyms kconfig @@ -116,30 +100,19 @@ kconfig.tk keywords.c* ksym.c* ksym.h* -kxgettext -lkc_defs.h lex.c* -lex.*.c -lk201-map.c logo_*.c logo_*_clut224.c logo_*_mono.c lxdialog mach-types mach-types.h -machtypes.h make_times_h map maui_boot.h -mconf -miboot* mk_elfconfig -mkboot -mkbugboot mkdep -mkprep mktables -mktree modpost modversions.h* offset.h @@ -147,28 +120,18 @@ offsets.h oui.c* parse.c* parse.h* -patches* -pca200e.bin -pca200e_ecd.bin2 -piggy.gz -piggyback pnmtologo ppc_defs.h* promcon_tbl.c* pss_boot.h -qconf raid6altivec*.c raid6int*.c raid6tables.c -relocs -series setup sim710_d.h* -sImage sm_tbl* split-include tags -tftpboot.img times.h* tkparse trix_boot.h @@ -176,11 +139,8 @@ utsrelease.h* version.h* vmlinux vmlinux-* -vmlinux.aout vmlinux.lds vsyscall.lds wanxlfw.inc uImage -unifdef -zImage* -zconf.hash.c +zImage diff --git a/trunk/Documentation/driver-model/platform.txt b/trunk/Documentation/driver-model/platform.txt index 2a97320ee17f..19c4a6e13676 100644 --- a/trunk/Documentation/driver-model/platform.txt +++ b/trunk/Documentation/driver-model/platform.txt @@ -96,46 +96,6 @@ System setup also associates those clocks with the device, so that that calls to clk_get(&pdev->dev, clock_name) return them as needed. -Legacy Drivers: Device Probing -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Some drivers are not fully converted to the driver model, because they take -on a non-driver role: the driver registers its platform device, rather than -leaving that for system infrastructure. Such drivers can't be hotplugged -or coldplugged, since those mechanisms require device creation to be in a -different system component than the driver. - -The only "good" reason for this is to handle older system designs which, like -original IBM PCs, rely on error-prone "probe-the-hardware" models for hardware -configuration. Newer systems have largely abandoned that model, in favor of -bus-level support for dynamic configuration (PCI, USB), or device tables -provided by the boot firmware (e.g. PNPACPI on x86). There are too many -conflicting options about what might be where, and even educated guesses by -an operating system will be wrong often enough to make trouble. - -This style of driver is discouraged. If you're updating such a driver, -please try to move the device enumeration to a more appropriate location, -outside the driver. This will usually be cleanup, since such drivers -tend to already have "normal" modes, such as ones using device nodes that -were created by PNP or by platform device setup. - -None the less, there are some APIs to support such legacy drivers. Avoid -using these calls except with such hotplug-deficient drivers. - - struct platform_device *platform_device_alloc( - char *name, unsigned id); - -You can use platform_device_alloc() to dynamically allocate a device, which -you will then initialize with resources and platform_device_register(). -A better solution is usually: - - struct platform_device *platform_device_register_simple( - char *name, unsigned id, - struct resource *res, unsigned nres); - -You can use platform_device_register_simple() as a one-step call to allocate -and register a device. - - Device Naming and Driver Binding ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The platform_device.dev.bus_id is the canonical name for the devices. diff --git a/trunk/Documentation/feature-removal-schedule.txt b/trunk/Documentation/feature-removal-schedule.txt index 0599a0c7c026..498ff31f3aa1 100644 --- a/trunk/Documentation/feature-removal-schedule.txt +++ b/trunk/Documentation/feature-removal-schedule.txt @@ -49,10 +49,20 @@ Who: Adrian Bunk --------------------------- +What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN +When: June 2007 +Why: Deprecated in favour of the more efficient and robust rawiso interface. + Affected are applications which use the deprecated part of libraw1394 + (raw1394_iso_write, raw1394_start_iso_write, raw1394_start_iso_rcv, + raw1394_stop_iso_rcv) or bypass libraw1394. +Who: Dan Dennedy , Stefan Richter + +--------------------------- + What: old NCR53C9x driver When: October 2007 Why: Replaced by the much better esp_scsi driver. Actual low-level - driver can be ported over almost trivially. + driver can ported over almost trivially. Who: David Miller Christoph Hellwig @@ -60,7 +70,6 @@ Who: David Miller What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. When: December 2006 -Files: include/linux/video_decoder.h Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6 series. The old API have lots of drawbacks and don't provide enough means to work with all video and audio standards. The newer API is @@ -94,7 +103,6 @@ Who: Dominik Brodowski What: remove EXPORT_SYMBOL(kernel_thread) When: August 2006 Files: arch/*/kernel/*_ksyms.c -Funcs: kernel_thread Why: kernel_thread is a low-level implementation detail. Drivers should use the API instead which shields them from implementation details and provides a higherlevel interface that @@ -248,6 +256,14 @@ Who: Len Brown --------------------------- +What: sk98lin network driver +When: July 2007 +Why: In kernel tree version of driver is unmaintained. Sk98lin driver + replaced by the skge driver. +Who: Stephen Hemminger + +--------------------------- + What: Compaq touchscreen device emulation When: Oct 2007 Files: drivers/input/tsdev.c @@ -262,6 +278,25 @@ Who: Richard Purdie --------------------------- +What: Multipath cached routing support in ipv4 +When: in 2.6.23 +Why: Code was merged, then submitter immediately disappeared leaving + us with no maintainer and lots of bugs. The code should not have + been merged in the first place, and many aspects of it's + implementation are blocking more critical core networking + development. It's marked EXPERIMENTAL and no distribution + enables it because it cause obscure crashes due to unfixable bugs + (interfaces don't return errors so memory allocation can't be + handled, calling contexts of these interfaces make handling + errors impossible too because they get called after we've + totally commited to creating a route object, for example). + This problem has existed for years and no forward progress + has ever been made, and nobody steps up to try and salvage + this code, so we're going to finally just get rid of it. +Who: David S. Miller + +--------------------------- + What: read_dev_chars(), read_conf_data{,_lpm}() (s390 common I/O layer) When: December 2007 Why: These functions are a leftover from 2.4 times. They have several @@ -293,36 +328,22 @@ Who: Adrian Bunk --------------------------- -What: libata spindown skipping and warning +What: libata.spindown_compat module parameter When: Dec 2008 -Why: Some halt(8) implementations synchronize caches for and spin - down libata disks because libata didn't use to spin down disk on - system halt (only synchronized caches). - Spin down on system halt is now implemented. sysfs node - /sys/class/scsi_disk/h:c:i:l/manage_start_stop is present if - spin down support is available. +Why: halt(8) synchronizes caches for and spins down libata disks + because libata didn't use to spin down disk on system halt + (only synchronized caches). + Spin down on system halt is now implemented and can be tested + using sysfs node /sys/class/scsi_disk/h:c:i:l/manage_start_stop. Because issuing spin down command to an already spun down disk - makes some disks spin up just to spin down again, libata tracks - device spindown status to skip the extra spindown command and - warn about it. - This is to give userspace tools the time to get updated and will - be removed after userspace is reasonably updated. + makes some disks spin up just to spin down again, the old + behavior needs to be maintained till userspace tool is updated + to check the sysfs node and not to spin down disks with the + node set to one. + This module parameter is to give userspace tool the time to + get updated and should be removed after userspace is + reasonably updated. Who: Tejun Heo --------------------------- -What: Legacy RTC drivers (under drivers/i2c/chips) -When: November 2007 -Why: Obsolete. We have a RTC subsystem with better drivers. -Who: Jean Delvare - ---------------------------- - -What: iptables SAME target -When: 1.1. 2008 -Files: net/ipv4/netfilter/ipt_SAME.c, include/linux/netfilter_ipv4/ipt_SAME.h -Why: Obsolete for multiple years now, NAT core provides the same behaviour. - Unfixable broken wrt. 32/64 bit cleanness. -Who: Patrick McHardy - ---------------------------- diff --git a/trunk/Documentation/filesystems/directory-locking b/trunk/Documentation/filesystems/directory-locking index ff7b611abf33..d7099a9266fb 100644 --- a/trunk/Documentation/filesystems/directory-locking +++ b/trunk/Documentation/filesystems/directory-locking @@ -1,6 +1,5 @@ Locking scheme used for directory operations is based on two -kinds of locks - per-inode (->i_mutex) and per-filesystem -(->s_vfs_rename_mutex). +kinds of locks - per-inode (->i_sem) and per-filesystem (->s_vfs_rename_sem). For our purposes all operations fall in 5 classes: @@ -64,7 +63,7 @@ objects - A < B iff A is an ancestor of B. attempt to acquire some lock and already holds at least one lock. Let's consider the set of contended locks. First of all, filesystem lock is not contended, since any process blocked on it is not holding any locks. -Thus all processes are blocked on ->i_mutex. +Thus all processes are blocked on ->i_sem. Non-directory objects are not contended due to (3). Thus link creation can't be a part of deadlock - it can't be blocked on source diff --git a/trunk/Documentation/filesystems/porting b/trunk/Documentation/filesystems/porting index dac45c92d872..5531694059ab 100644 --- a/trunk/Documentation/filesystems/porting +++ b/trunk/Documentation/filesystems/porting @@ -107,7 +107,7 @@ free to drop it... --- [informational] -->link() callers hold ->i_mutex on the object we are linking to. Some of your +->link() callers hold ->i_sem on the object we are linking to. Some of your problems might be over... --- @@ -130,9 +130,9 @@ went in - and hadn't been documented ;-/). Just remove it from fs_flags --- [mandatory] -->setattr() is called without BKL now. Caller _always_ holds ->i_mutex, so -watch for ->i_mutex-grabbing code that might be used by your ->setattr(). -Callers of notify_change() need ->i_mutex now. +->setattr() is called without BKL now. Caller _always_ holds ->i_sem, so +watch for ->i_sem-grabbing code that might be used by your ->setattr(). +Callers of notify_change() need ->i_sem now. --- [recommended] diff --git a/trunk/Documentation/filesystems/tmpfs.txt b/trunk/Documentation/filesystems/tmpfs.txt index 145e44086358..6dd050878a20 100644 --- a/trunk/Documentation/filesystems/tmpfs.txt +++ b/trunk/Documentation/filesystems/tmpfs.txt @@ -94,10 +94,10 @@ largest node numbers in the range. For example, mpol=bind:0-3,5,7,9-15 Note that trying to mount a tmpfs with an mpol option will fail if the running kernel does not support NUMA; and will fail if its nodelist -specifies a node which is not online. If your system relies on that -tmpfs being mounted, but from time to time runs a kernel built without -NUMA capability (perhaps a safe recovery kernel), or with fewer nodes -online, then it is advisable to omit the mpol option from automatic +specifies a node >= MAX_NUMNODES. If your system relies on that tmpfs +being mounted, but from time to time runs a kernel built without NUMA +capability (perhaps a safe recovery kernel), or configured to support +fewer nodes, then it is advisable to omit the mpol option from automatic mount options. It can be added later, when the tmpfs is already mounted on MountPoint, by 'mount -o remount,mpol=Policy:NodeList MountPoint'. @@ -121,4 +121,4 @@ RAM/SWAP in 10240 inodes and it is only accessible by root. Author: Christoph Rohland , 1.12.01 Updated: - Hugh Dickins , 4 June 2007 + Hugh Dickins , 19 February 2006 diff --git a/trunk/Documentation/firmware_class/README b/trunk/Documentation/firmware_class/README index c3480aa66ba8..e9cc8bb26f7d 100644 --- a/trunk/Documentation/firmware_class/README +++ b/trunk/Documentation/firmware_class/README @@ -1,7 +1,7 @@ request_firmware() hotplug interface: ------------------------------------ - Copyright (C) 2003 Manuel Estrada Sainz + Copyright (C) 2003 Manuel Estrada Sainz Why: --- diff --git a/trunk/Documentation/firmware_class/firmware_sample_driver.c b/trunk/Documentation/firmware_class/firmware_sample_driver.c index 6865cbe075ec..87feccdb5c9f 100644 --- a/trunk/Documentation/firmware_class/firmware_sample_driver.c +++ b/trunk/Documentation/firmware_class/firmware_sample_driver.c @@ -1,7 +1,7 @@ /* * firmware_sample_driver.c - * - * Copyright (c) 2003 Manuel Estrada Sainz + * Copyright (c) 2003 Manuel Estrada Sainz * * Sample code on how to use request_firmware() from drivers. * diff --git a/trunk/Documentation/firmware_class/firmware_sample_firmware_class.c b/trunk/Documentation/firmware_class/firmware_sample_firmware_class.c index fba943aacf93..9e1b0e4051cd 100644 --- a/trunk/Documentation/firmware_class/firmware_sample_firmware_class.c +++ b/trunk/Documentation/firmware_class/firmware_sample_firmware_class.c @@ -1,7 +1,7 @@ /* * firmware_sample_firmware_class.c - * - * Copyright (c) 2003 Manuel Estrada Sainz + * Copyright (c) 2003 Manuel Estrada Sainz * * NOTE: This is just a probe of concept, if you think that your driver would * be well served by this mechanism please contact me first. @@ -19,7 +19,7 @@ #include -MODULE_AUTHOR("Manuel Estrada Sainz"); +MODULE_AUTHOR("Manuel Estrada Sainz "); MODULE_DESCRIPTION("Hackish sample for using firmware class directly"); MODULE_LICENSE("GPL"); @@ -78,7 +78,6 @@ static CLASS_DEVICE_ATTR(loading, 0644, firmware_loading_show, firmware_loading_store); static ssize_t firmware_data_read(struct kobject *kobj, - struct bin_attribute *bin_attr, char *buffer, loff_t offset, size_t count) { struct class_device *class_dev = to_class_dev(kobj); @@ -89,7 +88,6 @@ static ssize_t firmware_data_read(struct kobject *kobj, return count; } static ssize_t firmware_data_write(struct kobject *kobj, - struct bin_attribute *bin_attr, char *buffer, loff_t offset, size_t count) { struct class_device *class_dev = to_class_dev(kobj); diff --git a/trunk/Documentation/gpio.txt b/trunk/Documentation/gpio.txt index 36af58eba136..e8be0abb346c 100644 --- a/trunk/Documentation/gpio.txt +++ b/trunk/Documentation/gpio.txt @@ -111,9 +111,7 @@ setting up a platform_device using the GPIO, is mark its direction: The return value is zero for success, else a negative errno. It should be checked, since the get/set calls don't have error returns and since -misconfiguration is possible. You should normally issue these calls from -a task context. However, for spinlock-safe GPIOs it's OK to use them -before tasking is enabled, as part of early board setup. +misconfiguration is possible. (These calls could sleep.) For output GPIOs, the value provided becomes the initial output value. This helps avoid signal glitching during system startup. @@ -199,9 +197,7 @@ However, many platforms don't currently support this mechanism. Passing invalid GPIO numbers to gpio_request() will fail, as will requesting GPIOs that have already been claimed with that call. The return value of -gpio_request() must be checked. You should normally issue these calls from -a task context. However, for spinlock-safe GPIOs it's OK to request GPIOs -before tasking is enabled, as part of early board setup. +gpio_request() must be checked. (These calls could sleep.) These calls serve two basic purposes. One is marking the signals which are actually in use as GPIOs, for better diagnostics; systems may have diff --git a/trunk/Documentation/hrtimer/timer_stats.txt b/trunk/Documentation/hrtimer/timer_stats.txt index 22b0814d0ad0..27f782e3593f 100644 --- a/trunk/Documentation/hrtimer/timer_stats.txt +++ b/trunk/Documentation/hrtimer/timer_stats.txt @@ -2,10 +2,9 @@ timer_stats - timer usage statistics ------------------------------------ timer_stats is a debugging facility to make the timer (ab)usage in a Linux -system visible to kernel and userspace developers. If enabled in the config -but not used it has almost zero runtime overhead, and a relatively small -data structure overhead. Even if collection is enabled runtime all the -locking is per-CPU and lookup is hashed. +system visible to kernel and userspace developers. It is not intended for +production usage as it adds significant overhead to the (hr)timer code and the +(hr)timer data structures. timer_stats should be used by kernel and userspace developers to verify that their code does not make unduly use of timers. This helps to avoid unnecessary diff --git a/trunk/Documentation/i2c/busses/i2c-i801 b/trunk/Documentation/i2c/busses/i2c-i801 index fe6406f2f9a6..c34f0db78a30 100644 --- a/trunk/Documentation/i2c/busses/i2c-i801 +++ b/trunk/Documentation/i2c/busses/i2c-i801 @@ -5,8 +5,8 @@ Supported adapters: '810' and '810E' chipsets) * Intel 82801BA (ICH2 - part of the '815E' chipset) * Intel 82801CA/CAM (ICH3) - * Intel 82801DB (ICH4) (HW PEC supported) - * Intel 82801EB/ER (ICH5) (HW PEC supported) + * Intel 82801DB (ICH4) (HW PEC supported, 32 byte buffer not supported) + * Intel 82801EB/ER (ICH5) (HW PEC supported, 32 byte buffer not supported) * Intel 6300ESB * Intel 82801FB/FR/FW/FRW (ICH6) * Intel 82801G (ICH7) diff --git a/trunk/Documentation/i2c/busses/i2c-piix4 b/trunk/Documentation/i2c/busses/i2c-piix4 index fa0c786a8bf5..7cbe43fa2701 100644 --- a/trunk/Documentation/i2c/busses/i2c-piix4 +++ b/trunk/Documentation/i2c/busses/i2c-piix4 @@ -6,7 +6,7 @@ Supported adapters: Datasheet: Publicly available at the Intel website * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges Datasheet: Only available via NDA from ServerWorks - * ATI IXP200, IXP300, IXP400, SB600 and SB700 southbridges + * ATI IXP200, IXP300, IXP400 and SB600 southbridges Datasheet: Not publicly available * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge Datasheet: Publicly available at the SMSC website http://www.smsc.com diff --git a/trunk/Documentation/i2c/busses/i2c-taos-evm b/trunk/Documentation/i2c/busses/i2c-taos-evm deleted file mode 100644 index 9146e33be6dd..000000000000 --- a/trunk/Documentation/i2c/busses/i2c-taos-evm +++ /dev/null @@ -1,46 +0,0 @@ -Kernel driver i2c-taos-evm - -Author: Jean Delvare - -This is a driver for the evaluation modules for TAOS I2C/SMBus chips. -The modules include an SMBus master with limited capabilities, which can -be controlled over the serial port. Virtually all evaluation modules -are supported, but a few lines of code need to be added for each new -module to instantiate the right I2C chip on the bus. Obviously, a driver -for the chip in question is also needed. - -Currently supported devices are: - -* TAOS TSL2550 EVM - -For addtional information on TAOS products, please see - http://www.taosinc.com/ - - -Using this driver ------------------ - -In order to use this driver, you'll need the serport driver, and the -inputattach tool, which is part of the input-utils package. The following -commands will tell the kernel that you have a TAOS EVM on the first -serial port: - -# modprobe serport -# inputattach --taos-evm /dev/ttyS0 - - -Technical details ------------------ - -Only 4 SMBus transaction types are supported by the TAOS evaluation -modules: -* Receive Byte -* Send Byte -* Read Byte -* Write Byte - -The communication protocol is text-based and pretty simple. It is -described in a PDF document on the CD which comes with the evaluation -module. The communication is rather slow, because the serial port has -to operate at 1200 bps. However, I don't think this is a big concern in -practice, as these modules are meant for evaluation and testing only. diff --git a/trunk/Documentation/i2c/chips/max6875 b/trunk/Documentation/i2c/chips/max6875 index a0cd8af2f408..96fec562a8e9 100644 --- a/trunk/Documentation/i2c/chips/max6875 +++ b/trunk/Documentation/i2c/chips/max6875 @@ -99,7 +99,7 @@ And then read the data or - count = i2c_smbus_read_i2c_block_data(fd, 0x84, 16, buffer); + count = i2c_smbus_read_i2c_block_data(fd, 0x84, buffer); The block read should read 16 bytes. 0x84 is the block read command. diff --git a/trunk/Documentation/i2c/chips/x1205 b/trunk/Documentation/i2c/chips/x1205 new file mode 100644 index 000000000000..09407c991fe5 --- /dev/null +++ b/trunk/Documentation/i2c/chips/x1205 @@ -0,0 +1,38 @@ +Kernel driver x1205 +=================== + +Supported chips: + * Xicor X1205 RTC + Prefix: 'x1205' + Addresses scanned: none + Datasheet: http://www.intersil.com/cda/deviceinfo/0,1477,X1205,00.html + +Authors: + Karen Spearel , + Alessandro Zummo + +Description +----------- + +This module aims to provide complete access to the Xicor X1205 RTC. +Recently Xicor has merged with Intersil, but the chip is +still sold under the Xicor brand. + +This chip is located at address 0x6f and uses a 2-byte register addressing. +Two bytes need to be written to read a single register, while most +other chips just require one and take the second one as the data +to be written. To prevent corrupting unknown chips, the user must +explicitely set the probe parameter. + +example: + +modprobe x1205 probe=0,0x6f + +The module supports one more option, hctosys, which is used to set the +software clock from the x1205. On systems where the x1205 is the +only hardware rtc, this parameter could be used to achieve a correct +date/time earlier in the system boot sequence. + +example: + +modprobe x1205 probe=0,0x6f hctosys=1 diff --git a/trunk/Documentation/i2c/summary b/trunk/Documentation/i2c/summary index 003c7319b8c7..aea60bf7e8f0 100644 --- a/trunk/Documentation/i2c/summary +++ b/trunk/Documentation/i2c/summary @@ -67,6 +67,7 @@ i2c-proc: The /proc/sys/dev/sensors interface for device (client) drivers Algorithm drivers ----------------- +i2c-algo-8xx: An algorithm for CPM's I2C device in Motorola 8xx processors (NOT BUILT BY DEFAULT) i2c-algo-bit: A bit-banging algorithm i2c-algo-pcf: A PCF 8584 style algorithm i2c-algo-ibm_ocp: An algorithm for the I2C device in IBM 4xx processors (NOT BUILT BY DEFAULT) @@ -80,5 +81,6 @@ i2c-pcf-epp: PCF8584 on a EPP parallel port (uses i2c-algo-pcf) (NOT mkpatch i2c-philips-par: Philips style parallel port adapter (uses i2c-algo-bit) i2c-adap-ibm_ocp: IBM 4xx processor I2C device (uses i2c-algo-ibm_ocp) (NOT BUILT BY DEFAULT) i2c-pport: Primitive parallel port adapter (uses i2c-algo-bit) +i2c-rpx: RPX board Motorola 8xx I2C device (uses i2c-algo-8xx) (NOT BUILT BY DEFAULT) i2c-velleman: Velleman K8000 parallel port adapter (uses i2c-algo-bit) diff --git a/trunk/Documentation/i2c/writing-clients b/trunk/Documentation/i2c/writing-clients index 2c170032bf37..3d8d36b0ad12 100644 --- a/trunk/Documentation/i2c/writing-clients +++ b/trunk/Documentation/i2c/writing-clients @@ -571,7 +571,7 @@ SMBus communication u8 command, u8 length, u8 *values); extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client, - u8 command, u8 length, u8 *values); + u8 command, u8 *values); These ones were removed in Linux 2.6.10 because they had no users, but could be added back later if needed: diff --git a/trunk/Documentation/i386/boot.txt b/trunk/Documentation/i386/boot.txt index 35985b34d5a6..d01b7a2a0f2e 100644 --- a/trunk/Documentation/i386/boot.txt +++ b/trunk/Documentation/i386/boot.txt @@ -2,7 +2,7 @@ ---------------------------- H. Peter Anvin - Last update 2007-05-23 + Last update 2007-05-07 On the i386 platform, the Linux kernel uses a rather complicated boot convention. This has evolved partially due to historical aspects, as @@ -52,8 +52,7 @@ zImage kernels, typically looks like: 0A0000 +------------------------+ | Reserved for BIOS | Do not use. Reserved for BIOS EBDA. 09A000 +------------------------+ - | Command line | - | Stack/heap | For use by the kernel real-mode code. + | Stack/heap/cmdline | For use by the kernel real-mode code. 098000 +------------------------+ | Kernel setup | The kernel real-mode code. 090200 +------------------------+ @@ -74,9 +73,10 @@ zImage kernels, typically looks like: When using bzImage, the protected-mode kernel was relocated to 0x100000 ("high memory"), and the kernel real-mode block (boot sector, setup, and stack/heap) was made relocatable to any address between -0x10000 and end of low memory. Unfortunately, in protocols 2.00 and -2.01 the 0x90000+ memory range is still used internally by the kernel; -the 2.02 protocol resolves that problem. +0x10000 and end of low memory. Unfortunately, in protocols 2.00 and +2.01 the command line is still required to live in the 0x9XXXX memory +range, and that memory range is still overwritten by the early kernel. +The 2.02 protocol resolves that problem. It is desirable to keep the "memory ceiling" -- the highest point in low memory touched by the boot loader -- as low as possible, since @@ -93,35 +93,6 @@ zImage or old bzImage kernels, which need data written into the 0x90000 segment, the boot loader should make sure not to use memory above the 0x9A000 point; too many BIOSes will break above that point. -For a modern bzImage kernel with boot protocol version >= 2.02, a -memory layout like the following is suggested: - - ~ ~ - | Protected-mode kernel | -100000 +------------------------+ - | I/O memory hole | -0A0000 +------------------------+ - | Reserved for BIOS | Leave as much as possible unused - ~ ~ - | Command line | (Can also be below the X+10000 mark) -X+10000 +------------------------+ - | Stack/heap | For use by the kernel real-mode code. -X+08000 +------------------------+ - | Kernel setup | The kernel real-mode code. - | Kernel boot sector | The kernel legacy boot sector. -X +------------------------+ - | Boot loader | <- Boot sector entry point 0000:7C00 -001000 +------------------------+ - | Reserved for MBR/BIOS | -000800 +------------------------+ - | Typically used by MBR | -000600 +------------------------+ - | BIOS use only | -000000 +------------------------+ - -... where the address X is as low as the design of the boot loader -permits. - **** THE REAL-MODE KERNEL HEADER @@ -189,147 +160,29 @@ e.g. protocol version 2.01 will contain 0x0201 in this field. When setting fields in the header, you must make sure only to set fields supported by the protocol version in use. - -**** DETAILS OF HEADER FIELDS - -For each field, some are information from the kernel to the bootloader -("read"), some are expected to be filled out by the bootloader -("write"), and some are expected to be read and modified by the -bootloader ("modify"). - -All general purpose boot loaders should write the fields marked -(obligatory). Boot loaders who want to load the kernel at a -nonstandard address should fill in the fields marked (reloc); other -boot loaders can ignore those fields. - -The byte order of all fields is littleendian (this is x86, after all.) - -Field name: setup_secs -Type: read -Offset/size: 0x1f1/1 -Protocol: ALL - - The size of the setup code in 512-byte sectors. If this field is - 0, the real value is 4. The real-mode code consists of the boot - sector (always one 512-byte sector) plus the setup code. - -Field name: root_flags -Type: modify (optional) -Offset/size: 0x1f2/2 -Protocol: ALL - - If this field is nonzero, the root defaults to readonly. The use of - this field is deprecated; use the "ro" or "rw" options on the - command line instead. - -Field name: syssize -Type: read -Offset/size: 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL) -Protocol: 2.04+ - - The size of the protected-mode code in units of 16-byte paragraphs. - For protocol versions older than 2.04 this field is only two bytes - wide, and therefore cannot be trusted for the size of a kernel if - the LOAD_HIGH flag is set. - -Field name: ram_size -Type: kernel internal -Offset/size: 0x1f8/2 -Protocol: ALL - - This field is obsolete. - -Field name: vid_mode -Type: modify (obligatory) -Offset/size: 0x1fa/2 - - Please see the section on SPECIAL COMMAND LINE OPTIONS. - -Field name: root_dev -Type: modify (optional) -Offset/size: 0x1fc/2 -Protocol: ALL - - The default root device device number. The use of this field is - deprecated, use the "root=" option on the command line instead. - -Field name: boot_flag -Type: read -Offset/size: 0x1fe/2 -Protocol: ALL - - Contains 0xAA55. This is the closest thing old Linux kernels have - to a magic number. - -Field name: jump -Type: read -Offset/size: 0x200/2 -Protocol: 2.00+ - - Contains an x86 jump instruction, 0xEB followed by a signed offset - relative to byte 0x202. This can be used to determine the size of - the header. - -Field name: header -Type: read -Offset/size: 0x202/4 -Protocol: 2.00+ - - Contains the magic number "HdrS" (0x53726448). - -Field name: version -Type: read -Offset/size: 0x206/2 -Protocol: 2.00+ - - Contains the boot protocol version, in (major << 8)+minor format, - e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version - 10.17. - -Field name: readmode_swtch -Type: modify (optional) -Offset/size: 0x208/4 -Protocol: 2.00+ - - Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) - -Field name: start_sys -Type: read -Offset/size: 0x20c/4 -Protocol: 2.00+ - - The load low segment (0x1000). Obsolete. - -Field name: kernel_version -Type: read -Offset/size: 0x20e/2 -Protocol: 2.00+ - - If set to a nonzero value, contains a pointer to a NUL-terminated - human-readable kernel version number string, less 0x200. This can - be used to display the kernel version to the user. This value - should be less than (0x200*setup_sects). - - For example, if this value is set to 0x1c00, the kernel version - number string can be found at offset 0x1e00 in the kernel file. - This is a valid value if and only if the "setup_sects" field - contains the value 15 or higher, as: - - 0x1c00 < 15*0x200 (= 0x1e00) but - 0x1c00 >= 14*0x200 (= 0x1c00) - - 0x1c00 >> 9 = 14, so the minimum value for setup_secs is 15. - -Field name: type_of_loader -Type: write (obligatory) -Offset/size: 0x210/1 -Protocol: 2.00+ - - If your boot loader has an assigned id (see table below), enter - 0xTV here, where T is an identifier for the boot loader and V is - a version number. Otherwise, enter 0xFF here. - - Assigned boot loader ids: +The "kernel_version" field, if set to a nonzero value, contains a +pointer to a null-terminated human-readable kernel version number +string, less 0x200. This can be used to display the kernel version to +the user. This value should be less than (0x200*setup_sects). For +example, if this value is set to 0x1c00, the kernel version number +string can be found at offset 0x1e00 in the kernel file. This is a +valid value if and only if the "setup_sects" field contains the value +14 or higher. + +Most boot loaders will simply load the kernel at its target address +directly. Such boot loaders do not need to worry about filling in +most of the fields in the header. The following fields should be +filled out, however: + + vid_mode: + Please see the section on SPECIAL COMMAND LINE OPTIONS. + + type_of_loader: + If your boot loader has an assigned id (see table below), enter + 0xTV here, where T is an identifier for the boot loader and V is + a version number. Otherwise, enter 0xFF here. + + Assigned boot loader ids: 0 LILO (0x00 reserved for pre-2.00 bootloader) 1 Loadlin 2 bootsect-loader (0x20, all other values reserved) @@ -340,145 +193,60 @@ Protocol: 2.00+ 8 U-BOOT 9 Xen A Gujin - B Qemu - - Please contact if you need a bootloader ID - value assigned. - -Field name: loadflags -Type: modify (obligatory) -Offset/size: 0x211/1 -Protocol: 2.00+ - - This field is a bitmask. - - Bit 0 (read): LOADED_HIGH - - If 0, the protected-mode code is loaded at 0x10000. - - If 1, the protected-mode code is loaded at 0x100000. - - Bit 7 (write): CAN_USE_HEAP - Set this bit to 1 to indicate that the value entered in the - heap_end_ptr is valid. If this field is clear, some setup code - functionality will be disabled. - -Field name: setup_move_size -Type: modify (obligatory) -Offset/size: 0x212/2 -Protocol: 2.00-2.01 - - When using protocol 2.00 or 2.01, if the real mode kernel is not - loaded at 0x90000, it gets moved there later in the loading - sequence. Fill in this field if you want additional data (such as - the kernel command line) moved in addition to the real-mode kernel - itself. - - The unit is bytes starting with the beginning of the boot sector. - - This field is can be ignored when the protocol is 2.02 or higher, or - if the real-mode code is loaded at 0x90000. - -Field name: code32_start -Type: modify (optional, reloc) -Offset/size: 0x214/4 -Protocol: 2.00+ - - The address to jump to in protected mode. This defaults to the load - address of the kernel, and can be used by the boot loader to - determine the proper load address. - - This field can be modified for two purposes: - - 1. as a boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) - - 2. if a bootloader which does not install a hook loads a - relocatable kernel at a nonstandard address it will have to modify - this field to point to the load address. - -Field name: ramdisk_image -Type: write (obligatory) -Offset/size: 0x218/4 -Protocol: 2.00+ - - The 32-bit linear address of the initial ramdisk or ramfs. Leave at - zero if there is no initial ramdisk/ramfs. - -Field name: ramdisk_size -Type: write (obligatory) -Offset/size: 0x21c/4 -Protocol: 2.00+ - - Size of the initial ramdisk or ramfs. Leave at zero if there is no - initial ramdisk/ramfs. - -Field name: bootsect_kludge -Type: kernel internal -Offset/size: 0x220/4 -Protocol: 2.00+ - - This field is obsolete. - -Field name: heap_end_ptr -Type: write (obligatory) -Offset/size: 0x224/2 -Protocol: 2.01+ - - Set this field to the offset (from the beginning of the real-mode - code) of the end of the setup stack/heap, minus 0x0200. - -Field name: cmd_line_ptr -Type: write (obligatory) -Offset/size: 0x228/4 -Protocol: 2.02+ - - Set this field to the linear address of the kernel command line. - The kernel command line can be located anywhere between the end of - the setup heap and 0xA0000; it does not have to be located in the - same 64K segment as the real-mode code itself. - - Fill in this field even if your boot loader does not support a - command line, in which case you can point this to an empty string - (or better yet, to the string "auto".) If this field is left at - zero, the kernel will assume that your boot loader does not support - the 2.02+ protocol. - -Field name: initrd_addr_max -Type: read -Offset/size: 0x22c/4 -Protocol: 2.03+ - - The maximum address that may be occupied by the initial - ramdisk/ramfs contents. For boot protocols 2.02 or earlier, this - field is not present, and the maximum address is 0x37FFFFFF. (This - address is defined as the address of the highest safe byte, so if - your ramdisk is exactly 131072 bytes long and this field is - 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.) - -Field name: kernel_alignment -Type: read (reloc) -Offset/size: 0x230/4 -Protocol: 2.05+ - - Alignment unit required by the kernel (if relocatable_kernel is true.) - -Field name: relocatable_kernel -Type: read (reloc) -Offset/size: 0x234/1 -Protocol: 2.05+ - - If this field is nonzero, the protected-mode part of the kernel can - be loaded at any address that satisfies the kernel_alignment field. - After loading, the boot loader must set the code32_start field to - point to the loaded code, or to a boot loader hook. - -Field name: cmdline_size -Type: read -Offset/size: 0x238/4 -Protocol: 2.06+ - The maximum size of the command line without the terminating - zero. This means that the command line can contain at most - cmdline_size characters. With protocol version 2.05 and earlier, the - maximum size was 255. + Please contact if you need a bootloader ID + value assigned. + + loadflags, heap_end_ptr: + If the protocol version is 2.01 or higher, enter the + offset limit of the setup heap into heap_end_ptr and set the + 0x80 bit (CAN_USE_HEAP) of loadflags. heap_end_ptr appears to + be relative to the start of setup (offset 0x0200). + + setup_move_size: + When using protocol 2.00 or 2.01, if the real mode + kernel is not loaded at 0x90000, it gets moved there later in + the loading sequence. Fill in this field if you want + additional data (such as the kernel command line) moved in + addition to the real-mode kernel itself. + + The unit is bytes starting with the beginning of the boot + sector. + + ramdisk_image, ramdisk_size: + If your boot loader has loaded an initial ramdisk (initrd), + set ramdisk_image to the 32-bit pointer to the ramdisk data + and the ramdisk_size to the size of the ramdisk data. + + The initrd should typically be located as high in memory as + possible, as it may otherwise get overwritten by the early + kernel initialization sequence. However, it must never be + located above the address specified in the initrd_addr_max + field. The initrd should be at least 4K page aligned. + + cmd_line_ptr: + If the protocol version is 2.02 or higher, this is a 32-bit + pointer to the kernel command line. The kernel command line + can be located anywhere between the end of setup and 0xA0000. + Fill in this field even if your boot loader does not support a + command line, in which case you can point this to an empty + string (or better yet, to the string "auto".) If this field + is left at zero, the kernel will assume that your boot loader + does not support the 2.02+ protocol. + + ramdisk_max: + The maximum address that may be occupied by the initrd + contents. For boot protocols 2.02 or earlier, this field is + not present, and the maximum address is 0x37FFFFFF. (This + address is defined as the address of the highest safe byte, so + if your ramdisk is exactly 131072 bytes long and this field is + 0x37FFFFFF, you can start your ramdisk at 0x37FE0000.) + + cmdline_size: + The maximum size of the command line without the terminating + zero. This means that the command line can contain at most + cmdline_size characters. With protocol version 2.05 and + earlier, the maximum size was 255. **** THE KERNEL COMMAND LINE @@ -726,7 +494,7 @@ switched off, especially if the loaded kernel has the floppy driver as a demand-loaded module! -**** ADVANCED BOOT LOADER HOOKS +**** ADVANCED BOOT TIME HOOKS If the boot loader runs in a particularly hostile environment (such as LOADLIN, which runs under DOS) it may be impossible to follow the @@ -751,5 +519,4 @@ IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and set them up to BOOT_DS (0x18) yourself. After completing your hook, you should jump to the address - that was in this field before your boot loader overwrote it - (relocated, if appropriate.) + that was in this field before your boot loader overwrote it. diff --git a/trunk/Documentation/i386/zero-page.txt b/trunk/Documentation/i386/zero-page.txt index 75b3680c41eb..c04a421f4a7c 100644 --- a/trunk/Documentation/i386/zero-page.txt +++ b/trunk/Documentation/i386/zero-page.txt @@ -37,7 +37,6 @@ Offset Type Description 0x1d0 unsigned long EFI memory descriptor map pointer 0x1d4 unsigned long EFI memory descriptor map size 0x1e0 unsigned long ALT_MEM_K, alternative mem check, in Kb -0x1e4 unsigned long Scratch field for the kernel setup code 0x1e8 char number of entries in E820MAP (below) 0x1e9 unsigned char number of entries in EDDBUF (below) 0x1ea unsigned char number of entries in EDD_MBR_SIG_BUFFER (below) diff --git a/trunk/Documentation/ia64/aliasing-test.c b/trunk/Documentation/ia64/aliasing-test.c index 773a814d4093..3153167b41c3 100644 --- a/trunk/Documentation/ia64/aliasing-test.c +++ b/trunk/Documentation/ia64/aliasing-test.c @@ -19,7 +19,6 @@ #include #include #include -#include int sum; @@ -35,19 +34,13 @@ int map_mem(char *path, off_t offset, size_t length, int touch) return -1; } - if (fnmatch("/proc/bus/pci/*", path, 0) == 0) { - rc = ioctl(fd, PCIIOC_MMAP_IS_MEM); - if (rc == -1) - perror("PCIIOC_MMAP_IS_MEM ioctl"); - } - addr = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset); if (addr == MAP_FAILED) return 1; if (touch) { c = (int *) addr; - while (c < (int *) (addr + length)) + while (c < (int *) (offset + length)) sum += *c++; } @@ -61,7 +54,7 @@ int map_mem(char *path, off_t offset, size_t length, int touch) return 0; } -int scan_tree(char *path, char *file, off_t offset, size_t length, int touch) +int scan_sysfs(char *path, char *file, off_t offset, size_t length, int touch) { struct dirent **namelist; char *name, *path2; @@ -100,7 +93,7 @@ int scan_tree(char *path, char *file, off_t offset, size_t length, int touch) } else { r = lstat(path2, &buf); if (r == 0 && S_ISDIR(buf.st_mode)) { - rc = scan_tree(path2, file, offset, length, touch); + rc = scan_sysfs(path2, file, offset, length, touch); if (rc < 0) return rc; } @@ -204,7 +197,7 @@ int scan_rom(char *path, char *file) return rc; } -int main() +main() { int rc; @@ -245,15 +238,10 @@ int main() else fprintf(stderr, "FAIL: /dev/mem 0x0-0x100000 not accessible\n"); - scan_tree("/sys/class/pci_bus", "legacy_mem", 0, 0xA0000, 1); - scan_tree("/sys/class/pci_bus", "legacy_mem", 0xA0000, 0x20000, 0); - scan_tree("/sys/class/pci_bus", "legacy_mem", 0xC0000, 0x40000, 1); - scan_tree("/sys/class/pci_bus", "legacy_mem", 0, 1024*1024, 0); + scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0, 0xA0000, 1); + scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0xA0000, 0x20000, 0); + scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0xC0000, 0x40000, 1); + scan_sysfs("/sys/class/pci_bus", "legacy_mem", 0, 1024*1024, 0); scan_rom("/sys/devices", "rom"); - - scan_tree("/proc/bus/pci", "??.?", 0, 0xA0000, 1); - scan_tree("/proc/bus/pci", "??.?", 0xA0000, 0x20000, 0); - scan_tree("/proc/bus/pci", "??.?", 0xC0000, 0x40000, 1); - scan_tree("/proc/bus/pci", "??.?", 0, 1024*1024, 0); } diff --git a/trunk/Documentation/ia64/aliasing.txt b/trunk/Documentation/ia64/aliasing.txt index aa3e953f0f7b..9a431a7d0f5d 100644 --- a/trunk/Documentation/ia64/aliasing.txt +++ b/trunk/Documentation/ia64/aliasing.txt @@ -112,18 +112,6 @@ POTENTIAL ATTRIBUTE ALIASING CASES The /dev/mem mmap constraints apply. - mmap of /proc/bus/pci/.../??.? - - This is an MMIO mmap of PCI functions, which additionally may or - may not be requested as using the WC attribute. - - If WC is requested, and the region in kern_memmap is either WC - or UC, and the EFI memory map designates the region as WC, then - the WC mapping is allowed. - - Otherwise, the user mapping must use the same attribute as the - kernel mapping. - read/write of /dev/mem This uses copy_from_user(), which implicitly uses a kernel diff --git a/trunk/Documentation/initrd.txt b/trunk/Documentation/initrd.txt index d3dc505104da..15f1b35deb34 100644 --- a/trunk/Documentation/initrd.txt +++ b/trunk/Documentation/initrd.txt @@ -27,20 +27,16 @@ When using initrd, the system typically boots as follows: 1) the boot loader loads the kernel and the initial RAM disk 2) the kernel converts initrd into a "normal" RAM disk and frees the memory used by initrd - 3) if the root device is not /dev/ram0, the old (deprecated) - change_root procedure is followed. see the "Obsolete root change - mechanism" section below. - 4) root device is mounted. if it is /dev/ram0, the initrd image is - then mounted as root - 5) /sbin/init is executed (this can be any valid executable, including + 3) initrd is mounted read-write as root + 4) /linuxrc is executed (this can be any valid executable, including shell scripts; it is run with uid 0 and can do basically everything - init can do). - 6) init mounts the "real" root file system - 7) init places the root file system at the root directory using the + init can do) + 5) linuxrc mounts the "real" root file system + 6) linuxrc places the root file system at the root directory using the pivot_root system call - 8) init execs the /sbin/init on the new root filesystem, performing - the usual boot sequence - 9) the initrd file system is removed + 7) the usual boot sequence (e.g. invocation of /sbin/init) is performed + on the root file system + 8) the initrd file system is removed Note that changing the root directory does not involve unmounting it. It is therefore possible to leave processes running on initrd during that @@ -74,7 +70,7 @@ initrd adds the following new options: root=/dev/ram0 initrd is mounted as root, and the normal boot procedure is followed, - with the RAM disk mounted as root. + with the RAM disk still mounted as root. Compressed cpio images ---------------------- @@ -141,11 +137,11 @@ We'll describe the loopback device method: # mkdir /mnt/dev # mknod /mnt/dev/console c 5 1 5) copy all the files that are needed to properly use the initrd - environment. Don't forget the most important file, /sbin/init - Note that /sbin/init's permissions must include "x" (execute). + environment. Don't forget the most important file, /linuxrc + Note that /linuxrc's permissions must include "x" (execute). 6) correct operation the initrd environment can frequently be tested even without rebooting with the command - # chroot /mnt /sbin/init + # chroot /mnt /linuxrc This is of course limited to initrds that do not interfere with the general system state (e.g. by reconfiguring network interfaces, overwriting mounted devices, trying to start already running demons, @@ -158,7 +154,7 @@ We'll describe the loopback device method: # gzip -9 initrd For experimenting with initrd, you may want to take a rescue floppy and -only add a symbolic link from /sbin/init to /bin/sh. Alternatively, you +only add a symbolic link from /linuxrc to /bin/sh. Alternatively, you can try the experimental newlib environment [2] to create a small initrd. @@ -167,14 +163,15 @@ boot loaders support initrd. Since the boot process is still compatible with an older mechanism, the following boot command line parameters have to be given: - root=/dev/ram0 rw + root=/dev/ram0 init=/linuxrc rw (rw is only necessary if writing to the initrd file system.) With LOADLIN, you simply execute LOADLIN initrd= -e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 rw +e.g. LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 + init=/linuxrc rw With LILO, you add the option INITRD= to either the global section or to the section of the respective kernel in /etc/lilo.conf, and pass @@ -182,7 +179,7 @@ the options using APPEND, e.g. image = /bzImage initrd = /boot/initrd.gz - append = "root=/dev/ram0 rw" + append = "root=/dev/ram0 init=/linuxrc rw" and run /sbin/lilo @@ -194,7 +191,7 @@ Now you can boot and enjoy using initrd. Changing the root device ------------------------ -When finished with its duties, init typically changes the root device +When finished with its duties, linuxrc typically changes the root device and proceeds with starting the Linux system on the "real" root device. The procedure involves the following steps: @@ -220,7 +217,7 @@ must exist before calling pivot_root. Example: # mkdir initrd # pivot_root . initrd -Now, the init process may still access the old root via its +Now, the linuxrc process may still access the old root via its executable, shared libraries, standard input/output/error, and its current root directory. All these references are dropped by the following command: @@ -252,6 +249,10 @@ disk can be freed: It is also possible to use initrd with an NFS-mounted root, see the pivot_root(8) man page for details. +Note: if linuxrc or any program exec'ed from it terminates for some +reason, the old change_root mechanism is invoked (see section "Obsolete +root change mechanism"). + Usage scenarios --------------- @@ -263,15 +264,15 @@ as follows: 1) system boots from floppy or other media with a minimal kernel (e.g. support for RAM disks, initrd, a.out, and the Ext2 FS) and loads initrd - 2) /sbin/init determines what is needed to (1) mount the "real" root FS + 2) /linuxrc determines what is needed to (1) mount the "real" root FS (i.e. device type, device drivers, file system) and (2) the distribution media (e.g. CD-ROM, network, tape, ...). This can be done by asking the user, by auto-probing, or by using a hybrid approach. - 3) /sbin/init loads the necessary kernel modules - 4) /sbin/init creates and populates the root file system (this doesn't + 3) /linuxrc loads the necessary kernel modules + 4) /linuxrc creates and populates the root file system (this doesn't have to be a very usable system yet) - 5) /sbin/init invokes pivot_root to change the root file system and + 5) /linuxrc invokes pivot_root to change the root file system and execs - via chroot - a program that continues the installation 6) the boot loader is installed 7) the boot loader is configured to load an initrd with the set of @@ -290,7 +291,7 @@ different hardware configurations in a single administrative domain. In such cases, it is desirable to generate only a small set of kernels (ideally only one) and to keep the system-specific part of configuration information as small as possible. In this case, a common initrd could be -generated with all the necessary modules. Then, only /sbin/init or a file +generated with all the necessary modules. Then, only /linuxrc or a file read by it would have to be different. A third scenario are more convenient recovery disks, because information @@ -336,25 +337,6 @@ This old, deprecated mechanism is commonly called "change_root", while the new, supported mechanism is called "pivot_root". -Mixed change_root and pivot_root mechanism ------------------------------------------- - -In case you did not want to use root=/dev/ram0 to trig the pivot_root mechanism, -you may create both /linuxrc and /sbin/init in your initrd image. - -/linuxrc would contain only the following: - -#! /bin/sh -mount -n -t proc proc /proc -echo 0x0100 >/proc/sys/kernel/real-root-dev -umount -n /proc - -Once linuxrc exited, the kernel would mount again your initrd as root, -this time executing /sbin/init. Again, it would be duty of this init -to build the right environment (maybe using the root= device passed on -the cmdline) before the final execution of the real /sbin/init. - - Resources --------- diff --git a/trunk/Documentation/kernel-parameters.txt b/trunk/Documentation/kernel-parameters.txt index 4d880b3d1f35..09220a1e22d9 100644 --- a/trunk/Documentation/kernel-parameters.txt +++ b/trunk/Documentation/kernel-parameters.txt @@ -170,10 +170,7 @@ and is between 256 and 4096 characters. It is defined in the file acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS Format: To spoof as Windows 98: ="Microsoft Windows" - acpi_osi= [HW,ACPI] Modify list of supported OS interface strings - acpi_osi="string1" # add string1 -- only one string - acpi_osi="!string2" # remove built-in string2 - acpi_osi= # disable all strings + acpi_osi= [HW,ACPI] empty param disables _OSI acpi_serialize [HW,ACPI] force serialization of AML methods @@ -223,6 +220,11 @@ and is between 256 and 4096 characters. It is defined in the file acpi_fake_ecdt [HW,ACPI] Workaround failure due to BIOS lacking ECDT + acpi_generic_hotkey [HW,ACPI] + Allow consolidated generic hotkey driver to + override platform specific driver. + See also Documentation/acpi-hotkey.txt. + acpi_pm_good [IA-32,X86-64] Override the pmtimer bug detection: force the kernel to assume that this machine's pmtimer latches its value @@ -394,26 +396,6 @@ and is between 256 and 4096 characters. It is defined in the file clocksource is not available, it defaults to PIT. Format: { pit | tsc | cyclone | pmtmr } - clocksource= [GENERIC_TIME] Override the default clocksource - Format: - Override the default clocksource and use the clocksource - with the name specified. - Some clocksource names to choose from, depending on - the platform: - [all] jiffies (this is the base, fallback clocksource) - [ACPI] acpi_pm - [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2, - pxa_timer,timer3,32k_counter,timer0_1 - [AVR32] avr32 - [IA-32] pit,hpet,tsc,vmi-timer; - scx200_hrt on Geode; cyclone on IBM x440 - [MIPS] MIPS - [PARISC] cr16 - [S390] tod - [SH] SuperH - [SPARC64] tick - [X86-64] hpet,tsc - code_bytes [IA32] How many bytes of object code to print in an oops report. Range: 0 - 8192 @@ -1014,6 +996,49 @@ and is between 256 and 4096 characters. It is defined in the file mga= [HW,DRM] + migration_cost= + [KNL,SMP] debug: override scheduler migration costs + Format: ,,... + This debugging option can be used to override the + default scheduler migration cost matrix. The numbers + are indexed by 'CPU domain distance'. + E.g. migration_cost=1000,2000,3000 on an SMT NUMA + box will set up an intra-core migration cost of + 1 msec, an inter-core migration cost of 2 msecs, + and an inter-node migration cost of 3 msecs. + + WARNING: using the wrong values here can break + scheduler performance, so it's only for scheduler + development purposes, not production environments. + + migration_debug= + [KNL,SMP] migration cost auto-detect verbosity + Format=<0|1|2> + If a system's migration matrix reported at bootup + seems erroneous then this option can be used to + increase verbosity of the detection process. + We default to 0 (no extra messages), 1 will print + some more information, and 2 will be really + verbose (probably only useful if you also have a + serial console attached to the system). + + migration_factor= + [KNL,SMP] multiply/divide migration costs by a factor + Format= + This debug option can be used to proportionally + increase or decrease the auto-detected migration + costs for all entries of the migration matrix. + E.g. migration_factor=150 will increase migration + costs by 50%. (and thus the scheduler will be less + eager migrating cache-hot tasks) + migration_factor=80 will decrease migration costs + by 20%. (thus the scheduler will be more eager to + migrate tasks) + + WARNING: using the wrong values here can break + scheduler performance, so it's only for scheduler + development purposes, not production environments. + mousedev.tap_time= [MOUSE] Maximum time between finger touching and leaving touchpad surface for touch to be considered @@ -1087,9 +1112,9 @@ and is between 256 and 4096 characters. It is defined in the file when set. Format: - noaliencache [MM, NUMA, SLAB] Disables the allocation of alien - caches in the slab allocator. Saves per-node memory, - but will impact performance. + noaliencache [MM, NUMA] Disables the allcoation of alien caches in + the slab allocator. Saves per-node memory, but will + impact performance on real NUMA hardware. noalign [KNL,ARM] @@ -1568,37 +1593,6 @@ and is between 256 and 4096 characters. It is defined in the file slram= [HW,MTD] - slub_debug [MM, SLUB] - Enabling slub_debug allows one to determine the culprit - if slab objects become corrupted. Enabling slub_debug - creates guard zones around objects and poisons objects - when not in use. Also tracks the last alloc / free. - For more information see Documentation/vm/slub.txt. - - slub_max_order= [MM, SLUB] - Determines the maximum allowed order for slabs. Setting - this too high may cause fragmentation. - For more information see Documentation/vm/slub.txt. - - slub_min_objects= [MM, SLUB] - The minimum objects per slab. SLUB will increase the - slab order up to slub_max_order to generate a - sufficiently big slab to satisfy the number of objects. - The higher the number of objects the smaller the overhead - of tracking slabs. - For more information see Documentation/vm/slub.txt. - - slub_min_order= [MM, SLUB] - Determines the mininum page order for slabs. Must be - lower than slub_max_order - For more information see Documentation/vm/slub.txt. - - slub_nomerge [MM, SLUB] - Disable merging of slabs of similar size. May be - necessary if there is some reason to distinguish - allocs to different slabs. - For more information see Documentation/vm/slub.txt. - smart2= [HW] Format: [,[,...,]] @@ -1813,6 +1807,10 @@ and is between 256 and 4096 characters. It is defined in the file time Show timing data prefixed to each printk message line + clocksource= [GENERIC_TIME] Override the default clocksource + Override the default clocksource and use the clocksource + with the name specified. + tipar.timeout= [HW,PPT] Set communications timeout in tenths of a second (default 15). diff --git a/trunk/Documentation/ldm.txt b/trunk/Documentation/ldm.txt index 718085bc9f1a..e266e11c19a3 100644 --- a/trunk/Documentation/ldm.txt +++ b/trunk/Documentation/ldm.txt @@ -2,13 +2,10 @@ LDM - Logical Disk Manager (Dynamic Disks) ------------------------------------------ -Originally Written by FlatCap - Richard Russon . -Last Updated by Anton Altaparmakov on 30 March 2007 for Windows Vista. - Overview -------- -Windows 2000, XP, and Vista use a new partitioning scheme. It is a complete +Windows 2000 and XP use a new partitioning scheme. It is a complete replacement for the MSDOS style partitions. It stores its information in a 1MiB journalled database at the end of the physical disk. The size of partitions is limited only by disk space. The maximum number of partitions is @@ -26,11 +23,7 @@ Once the LDM driver has divided up the disk, you can use the MD driver to assemble any multi-partition volumes, e.g. Stripes, RAID5. To prevent legacy applications from repartitioning the disk, the LDM creates a -dummy MSDOS partition containing one disk-sized partition. This is what is -supported with the Linux LDM driver. - -A newer approach that has been implemented with Vista is to put LDM on top of a -GPT label disk. This is not supported by the Linux LDM driver yet. +dummy MSDOS partition containing one disk-sized partition. Example @@ -95,13 +88,13 @@ and cannot boot from a Dynamic Disk. More Documentation ------------------ -There is an Overview of the LDM together with complete Technical Documentation. -It is available for download. +There is an Overview of the LDM online together with complete Technical +Documentation. It can also be downloaded in html. - http://www.linux-ntfs.org/content/view/19/37/ + http://linux-ntfs.sourceforge.net/ldm/index.html + http://linux-ntfs.sourceforge.net/downloads.html -If you have any LDM questions that aren't answered in the documentation, email -me. +If you have any LDM questions that aren't answered on the website, email me. Cheers, FlatCap - Richard Russon diff --git a/trunk/Documentation/memory-barriers.txt b/trunk/Documentation/memory-barriers.txt index 650657c54733..58408dd023c7 100644 --- a/trunk/Documentation/memory-barriers.txt +++ b/trunk/Documentation/memory-barriers.txt @@ -24,7 +24,7 @@ Contents: (*) Explicit kernel barriers. - Compiler barrier. - - CPU memory barriers. + - The CPU memory barriers. - MMIO write barrier. (*) Implicit kernel memory barriers. @@ -265,7 +265,7 @@ Memory barriers are such interventions. They impose a perceived partial ordering over the memory operations on either side of the barrier. Such enforcement is important because the CPUs and other devices in a system -can use a variety of tricks to improve performance, including reordering, +can use a variety of tricks to improve performance - including reordering, deferral and combination of memory operations; speculative loads; speculative branch prediction and various types of caching. Memory barriers are used to override or suppress these tricks, allowing the code to sanely control the @@ -457,7 +457,7 @@ sequence, Q must be either &A or &B, and that: (Q == &A) implies (D == 1) (Q == &B) implies (D == 4) -But! CPU 2's perception of P may be updated _before_ its perception of B, thus +But! CPU 2's perception of P may be updated _before_ its perception of B, thus leading to the following situation: (Q == &B) and (D == 2) ???? @@ -573,7 +573,7 @@ Basically, the read barrier always has to be there, even though it can be of the "weaker" type. [!] Note that the stores before the write barrier would normally be expected to -match the loads after the read barrier or the data dependency barrier, and vice +match the loads after the read barrier or data dependency barrier, and vice versa: CPU 1 CPU 2 @@ -588,7 +588,7 @@ versa: EXAMPLES OF MEMORY BARRIER SEQUENCES ------------------------------------ -Firstly, write barriers act as partial orderings on store operations. +Firstly, write barriers act as a partial orderings on store operations. Consider the following sequence of events: CPU 1 @@ -608,15 +608,15 @@ STORE B, STORE C } all occurring before the unordered set of { STORE D, STORE E +-------+ : : | | +------+ | |------>| C=3 | } /\ - | | : +------+ }----- \ -----> Events perceptible to - | | : | A=1 | } \/ the rest of the system + | | : +------+ }----- \ -----> Events perceptible + | | : | A=1 | } \/ to rest of system | | : +------+ } | CPU 1 | : | B=2 | } | | +------+ } | | wwwwwwwwwwwwwwww } <--- At this point the write barrier | | +------+ } requires all stores prior to the | | : | E=5 | } barrier to be committed before - | | : +------+ } further stores may take place + | | : +------+ } further stores may be take place. | |------>| D=4 | } | | +------+ +-------+ : : @@ -626,7 +626,7 @@ STORE B, STORE C } all occurring before the unordered set of { STORE D, STORE E V -Secondly, data dependency barriers act as partial orderings on data-dependent +Secondly, data dependency barriers act as a partial orderings on data-dependent loads. Consider the following sequence of events: CPU 1 CPU 2 @@ -975,7 +975,7 @@ compiler from moving the memory accesses either side of it to the other side: barrier(); -This is a general barrier - lesser varieties of compiler barrier do not exist. +This a general barrier - lesser varieties of compiler barrier do not exist. The compiler barrier has no direct effect on the CPU, which may then reorder things however it wishes. @@ -997,7 +997,7 @@ The Linux kernel has eight basic CPU memory barriers: All CPU memory barriers unconditionally imply compiler barriers. SMP memory barriers are reduced to compiler barriers on uniprocessor compiled -systems because it is assumed that a CPU will appear to be self-consistent, +systems because it is assumed that a CPU will be appear to be self-consistent, and will order overlapping accesses correctly with respect to itself. [!] Note that SMP memory barriers _must_ be used to control the ordering of @@ -1146,9 +1146,9 @@ for each construct. These operations all imply certain barriers: Therefore, from (1), (2) and (4) an UNLOCK followed by an unconditional LOCK is equivalent to a full barrier, but a LOCK followed by an UNLOCK is not. -[!] Note: one of the consequences of LOCKs and UNLOCKs being only one-way - barriers is that the effects of instructions outside of a critical section - may seep into the inside of the critical section. +[!] Note: one of the consequence of LOCKs and UNLOCKs being only one-way + barriers is that the effects instructions outside of a critical section may + seep into the inside of the critical section. A LOCK followed by an UNLOCK may not be assumed to be full memory barrier because it is possible for an access preceding the LOCK to happen after the @@ -1239,7 +1239,7 @@ three CPUs; then should the following sequence of events occur: UNLOCK M UNLOCK Q *D = d; *H = h; -Then there is no guarantee as to what order CPU 3 will see the accesses to *A +Then there is no guarantee as to what order CPU #3 will see the accesses to *A through *H occur in, other than the constraints imposed by the separate locks on the separate CPUs. It might, for example, see: @@ -1269,12 +1269,12 @@ However, if the following occurs: UNLOCK M [2] *H = h; -CPU 3 might see: +CPU #3 might see: *E, LOCK M [1], *C, *B, *A, UNLOCK M [1], LOCK M [2], *H, *F, *G, UNLOCK M [2], *D -But assuming CPU 1 gets the lock first, CPU 3 won't see any of: +But assuming CPU #1 gets the lock first, it won't see any of: *B, *C, *D, *F, *G or *H preceding LOCK M [1] *A, *B or *C following UNLOCK M [1] @@ -1327,12 +1327,12 @@ spinlock, for example: mmiowb(); spin_unlock(Q); -this will ensure that the two stores issued on CPU 1 appear at the PCI bridge -before either of the stores issued on CPU 2. +this will ensure that the two stores issued on CPU #1 appear at the PCI bridge +before either of the stores issued on CPU #2. -Furthermore, following a store by a load from the same device obviates the need -for the mmiowb(), because the load forces the store to complete before the load +Furthermore, following a store by a load to the same device obviates the need +for an mmiowb(), because the load forces the store to complete before the load is performed: CPU 1 CPU 2 @@ -1363,7 +1363,7 @@ circumstances in which reordering definitely _could_ be a problem: (*) Atomic operations. - (*) Accessing devices. + (*) Accessing devices (I/O). (*) Interrupts. @@ -1399,7 +1399,7 @@ To wake up a particular waiter, the up_read() or up_write() functions have to: (1) read the next pointer from this waiter's record to know as to where the next waiter record is; - (2) read the pointer to the waiter's task structure; + (4) read the pointer to the waiter's task structure; (3) clear the task pointer to tell the waiter it has been given the semaphore; @@ -1407,7 +1407,7 @@ To wake up a particular waiter, the up_read() or up_write() functions have to: (5) release the reference held on the waiter's task struct. -In other words, it has to perform this sequence of events: +In otherwords, it has to perform this sequence of events: LOAD waiter->list.next; LOAD waiter->task; @@ -1502,7 +1502,7 @@ operations and adjusting reference counters towards object destruction, and as such the implicit memory barrier effects are necessary. -The following operations are potential problems as they do _not_ imply memory +The following operation are potential problems as they do _not_ imply memory barriers, but might be used for implementing such things as UNLOCK-class operations: @@ -1517,7 +1517,7 @@ With these the appropriate explicit memory barrier should be used if necessary The following also do _not_ imply memory barriers, and so may require explicit memory barriers under some circumstances (smp_mb__before_atomic_dec() for -instance): +instance)): atomic_add(); atomic_sub(); @@ -1641,8 +1641,8 @@ functions: indeed have special I/O space access cycles and instructions, but many CPUs don't have such a concept. - The PCI bus, amongst others, defines an I/O space concept which - on such - CPUs as i386 and x86_64 - readily maps to the CPU's concept of I/O + The PCI bus, amongst others, defines an I/O space concept - which on such + CPUs as i386 and x86_64 cpus readily maps to the CPU's concept of I/O space. However, it may also be mapped as a virtual I/O space in the CPU's memory map, particularly on those CPUs that don't support alternate I/O spaces. @@ -1664,7 +1664,7 @@ functions: i386 architecture machines, for example, this is controlled by way of the MTRR registers. - Ordinarily, these will be guaranteed to be fully ordered and uncombined, + Ordinarily, these will be guaranteed to be fully ordered and uncombined,, provided they're not accessing a prefetchable device. However, intermediary hardware (such as a PCI bridge) may indulge in @@ -1689,7 +1689,7 @@ functions: (*) ioreadX(), iowriteX() - These will perform appropriately for the type of access they're actually + These will perform as appropriate for the type of access they're actually doing, be it inX()/outX() or readX()/writeX(). @@ -1705,7 +1705,7 @@ of arch-specific code. This means that it must be considered that the CPU will execute its instruction stream in any order it feels like - or even in parallel - provided that if an -instruction in the stream depends on an earlier instruction, then that +instruction in the stream depends on the an earlier instruction, then that earlier instruction must be sufficiently complete[*] before the later instruction may proceed; in other words: provided that the appearance of causality is maintained. @@ -1795,8 +1795,8 @@ eventually become visible on all CPUs, there's no guarantee that they will become apparent in the same order on those other CPUs. -Consider dealing with a system that has a pair of CPUs (1 & 2), each of which -has a pair of parallel data caches (CPU 1 has A/B, and CPU 2 has C/D): +Consider dealing with a system that has pair of CPUs (1 & 2), each of which has +a pair of parallel data caches (CPU 1 has A/B, and CPU 2 has C/D): : : +--------+ @@ -1835,7 +1835,7 @@ Imagine the system has the following properties: (*) the coherency queue is not flushed by normal loads to lines already present in the cache, even though the contents of the queue may - potentially affect those loads. + potentially effect those loads. Imagine, then, that two writes are made on the first CPU, with a write barrier between them to guarantee that they will appear to reach that CPU's caches in @@ -1845,7 +1845,7 @@ the requisite order: =============== =============== ======================================= u == 0, v == 1 and p == &u, q == &u v = 2; - smp_wmb(); Make sure change to v is visible before + smp_wmb(); Make sure change to v visible before change to p v is now in cache A exclusively p = &v; @@ -1853,7 +1853,7 @@ the requisite order: The write memory barrier forces the other CPUs in the system to perceive that the local CPU's caches have apparently been updated in the correct order. But -now imagine that the second CPU wants to read those values: +now imagine that the second CPU that wants to read those values: CPU 1 CPU 2 COMMENT =============== =============== ======================================= @@ -1861,7 +1861,7 @@ now imagine that the second CPU wants to read those values: q = p; x = *q; -The above pair of reads may then fail to happen in the expected order, as the +The above pair of reads may then fail to happen in expected order, as the cacheline holding p may get updated in one of the second CPU's caches whilst the update to the cacheline holding v is delayed in the other of the second CPU's caches by some other cache event: @@ -1916,7 +1916,7 @@ access depends on a read, not all do, so it may not be relied on. Other CPUs may also have split caches, but must coordinate between the various cachelets for normal memory accesses. The semantics of the Alpha removes the -need for coordination in the absence of memory barriers. +need for coordination in absence of memory barriers. CACHE COHERENCY VS DMA @@ -1931,10 +1931,10 @@ invalidate them as well). In addition, the data DMA'd to RAM by a device may be overwritten by dirty cache lines being written back to RAM from a CPU's cache after the device has -installed its own data, or cache lines present in the CPU's cache may simply -obscure the fact that RAM has been updated, until at such time as the cacheline -is discarded from the CPU's cache and reloaded. To deal with this, the -appropriate part of the kernel must invalidate the overlapping bits of the +installed its own data, or cache lines simply present in a CPUs cache may +simply obscure the fact that RAM has been updated, until at such time as the +cacheline is discarded from the CPU's cache and reloaded. To deal with this, +the appropriate part of the kernel must invalidate the overlapping bits of the cache on each CPU. See Documentation/cachetlb.txt for more information on cache management. @@ -1944,7 +1944,7 @@ CACHE COHERENCY VS MMIO ----------------------- Memory mapped I/O usually takes place through memory locations that are part of -a window in the CPU's memory space that has different properties assigned than +a window in the CPU's memory space that have different properties assigned than the usual RAM directed window. Amongst these properties is usually the fact that such accesses bypass the @@ -1960,7 +1960,7 @@ THE THINGS CPUS GET UP TO ========================= A programmer might take it for granted that the CPU will perform memory -operations in exactly the order specified, so that if the CPU is, for example, +operations in exactly the order specified, so that if a CPU is, for example, given the following piece of code to execute: a = *A; @@ -1969,7 +1969,7 @@ given the following piece of code to execute: d = *D; *E = e; -they would then expect that the CPU will complete the memory operation for each +They would then expect that the CPU will complete the memory operation for each instruction before moving on to the next one, leading to a definite sequence of operations as seen by external observers in the system: @@ -1986,8 +1986,8 @@ assumption doesn't hold because: (*) loads may be done speculatively, and the result discarded should it prove to have been unnecessary; - (*) loads may be done speculatively, leading to the result having been fetched - at the wrong time in the expected sequence of events; + (*) loads may be done speculatively, leading to the result having being + fetched at the wrong time in the expected sequence of events; (*) the order of the memory accesses may be rearranged to promote better use of the CPU buses and caches; @@ -2069,12 +2069,12 @@ AND THEN THERE'S THE ALPHA The DEC Alpha CPU is one of the most relaxed CPUs there is. Not only that, some versions of the Alpha CPU have a split data cache, permitting them to have -two semantically-related cache lines updated at separate times. This is where +two semantically related cache lines updating at separate times. This is where the data dependency barrier really becomes necessary as this synchronises both caches with the memory coherence system, thus making it seem like pointer changes vs new data occur in the right order. -The Alpha defines the Linux kernel's memory barrier model. +The Alpha defines the Linux's kernel's memory barrier model. See the subsection on "Cache Coherency" above. diff --git a/trunk/Documentation/networking/00-INDEX b/trunk/Documentation/networking/00-INDEX index d63f480afb74..e06b6e3c1db5 100644 --- a/trunk/Documentation/networking/00-INDEX +++ b/trunk/Documentation/networking/00-INDEX @@ -32,8 +32,6 @@ cops.txt - info on the COPS LocalTalk Linux driver cs89x0.txt - the Crystal LAN (CS8900/20-based) Ethernet ISA adapter driver -cxacru.txt - - Conexant AccessRunner USB ADSL Modem de4x5.txt - the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver decnet.txt @@ -96,6 +94,9 @@ routing.txt - the new routing mechanism shaper.txt - info on the module that can shape/limit transmitted traffic. +sk98lin.txt + - Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit + Ethernet Adapter family driver info skfp.txt - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info. smc9.txt diff --git a/trunk/Documentation/networking/cxacru.txt b/trunk/Documentation/networking/cxacru.txt deleted file mode 100644 index b074681a963e..000000000000 --- a/trunk/Documentation/networking/cxacru.txt +++ /dev/null @@ -1,84 +0,0 @@ -Firmware is required for this device: http://accessrunner.sourceforge.net/ - -While it is capable of managing/maintaining the ADSL connection without the -module loaded, the device will sometimes stop responding after unloading the -driver and it is necessary to unplug/remove power to the device to fix this. - -Detected devices will appear as ATM devices named "cxacru". In /sys/class/atm/ -these are directories named cxacruN where N is the device number. A symlink -named device points to the USB interface device's directory which contains -several sysfs attribute files for retrieving device statistics: - -* adsl_controller_version - -* adsl_headend -* adsl_headend_environment - Information about the remote headend. - -* downstream_attenuation (dB) -* downstream_bits_per_frame -* downstream_rate (kbps) -* downstream_snr_margin (dB) - Downstream stats. - -* upstream_attenuation (dB) -* upstream_bits_per_frame -* upstream_rate (kbps) -* upstream_snr_margin (dB) -* transmitter_power (dBm/Hz) - Upstream stats. - -* downstream_crc_errors -* downstream_fec_errors -* downstream_hec_errors -* upstream_crc_errors -* upstream_fec_errors -* upstream_hec_errors - Error counts. - -* line_startable - Indicates that ADSL support on the device - is/can be enabled, see adsl_start. - -* line_status - "initialising" - "down" - "attempting to activate" - "training" - "channel analysis" - "exchange" - "waiting" - "up" - - Changes between "down" and "attempting to activate" - if there is no signal. - -* link_status - "not connected" - "connected" - "lost" - -* mac_address - -* modulation - "ANSI T1.413" - "ITU-T G.992.1 (G.DMT)" - "ITU-T G.992.2 (G.LITE)" - -* startup_attempts - Count of total attempts to initialise ADSL. - -To enable/disable ADSL, the following can be written to the adsl_state file: - "start" - "stop - "restart" (stops, waits 1.5s, then starts) - "poll" (used to resume status polling if it was disabled due to failure) - -Changes in adsl/line state are reported via kernel log messages: - [4942145.150704] ATM dev 0: ADSL state: running - [4942243.663766] ATM dev 0: ADSL line: down - [4942249.665075] ATM dev 0: ADSL line: attempting to activate - [4942253.654954] ATM dev 0: ADSL line: training - [4942255.666387] ATM dev 0: ADSL line: channel analysis - [4942259.656262] ATM dev 0: ADSL line: exchange - [2635357.696901] ATM dev 0: ADSL line: up (8128 kb/s down | 832 kb/s up) diff --git a/trunk/Documentation/networking/ip-sysctl.txt b/trunk/Documentation/networking/ip-sysctl.txt index 09c184e41cf8..af6a63ab9026 100644 --- a/trunk/Documentation/networking/ip-sysctl.txt +++ b/trunk/Documentation/networking/ip-sysctl.txt @@ -874,7 +874,8 @@ accept_redirects - BOOLEAN accept_source_route - INTEGER Accept source routing (routing extension header). - >= 0: Accept only routing header type 2. + > 0: Accept routing header. + = 0: Accept only routing header type 2. < 0: Do not accept routing header. Default: 0 diff --git a/trunk/Documentation/networking/l2tp.txt b/trunk/Documentation/networking/l2tp.txt deleted file mode 100644 index 2451f551c505..000000000000 --- a/trunk/Documentation/networking/l2tp.txt +++ /dev/null @@ -1,169 +0,0 @@ -This brief document describes how to use the kernel's PPPoL2TP driver -to provide L2TP functionality. L2TP is a protocol that tunnels one or -more PPP sessions over a UDP tunnel. It is commonly used for VPNs -(L2TP/IPSec) and by ISPs to tunnel subscriber PPP sessions over an IP -network infrastructure. - -Design -====== - -The PPPoL2TP driver, drivers/net/pppol2tp.c, provides a mechanism by -which PPP frames carried through an L2TP session are passed through -the kernel's PPP subsystem. The standard PPP daemon, pppd, handles all -PPP interaction with the peer. PPP network interfaces are created for -each local PPP endpoint. - -The L2TP protocol http://www.faqs.org/rfcs/rfc2661.html defines L2TP -control and data frames. L2TP control frames carry messages between -L2TP clients/servers and are used to setup / teardown tunnels and -sessions. An L2TP client or server is implemented in userspace and -will use a regular UDP socket per tunnel. L2TP data frames carry PPP -frames, which may be PPP control or PPP data. The kernel's PPP -subsystem arranges for PPP control frames to be delivered to pppd, -while data frames are forwarded as usual. - -Each tunnel and session within a tunnel is assigned a unique tunnel_id -and session_id. These ids are carried in the L2TP header of every -control and data packet. The pppol2tp driver uses them to lookup -internal tunnel and/or session contexts. Zero tunnel / session ids are -treated specially - zero ids are never assigned to tunnels or sessions -in the network. In the driver, the tunnel context keeps a pointer to -the tunnel UDP socket. The session context keeps a pointer to the -PPPoL2TP socket, as well as other data that lets the driver interface -to the kernel PPP subsystem. - -Note that the pppol2tp kernel driver handles only L2TP data frames; -L2TP control frames are simply passed up to userspace in the UDP -tunnel socket. The kernel handles all datapath aspects of the -protocol, including data packet resequencing (if enabled). - -There are a number of requirements on the userspace L2TP daemon in -order to use the pppol2tp driver. - -1. Use a UDP socket per tunnel. - -2. Create a single PPPoL2TP socket per tunnel bound to a special null - session id. This is used only for communicating with the driver but - must remain open while the tunnel is active. Opening this tunnel - management socket causes the driver to mark the tunnel socket as an - L2TP UDP encapsulation socket and flags it for use by the - referenced tunnel id. This hooks up the UDP receive path via - udp_encap_rcv() in net/ipv4/udp.c. PPP data frames are never passed - in this special PPPoX socket. - -3. Create a PPPoL2TP socket per L2TP session. This is typically done - by starting pppd with the pppol2tp plugin and appropriate - arguments. A PPPoL2TP tunnel management socket (Step 2) must be - created before the first PPPoL2TP session socket is created. - -When creating PPPoL2TP sockets, the application provides information -to the driver about the socket in a socket connect() call. Source and -destination tunnel and session ids are provided, as well as the file -descriptor of a UDP socket. See struct pppol2tp_addr in -include/linux/if_ppp.h. Note that zero tunnel / session ids are -treated specially. When creating the per-tunnel PPPoL2TP management -socket in Step 2 above, zero source and destination session ids are -specified, which tells the driver to prepare the supplied UDP file -descriptor for use as an L2TP tunnel socket. - -Userspace may control behavior of the tunnel or session using -setsockopt and ioctl on the PPPoX socket. The following socket -options are supported:- - -DEBUG - bitmask of debug message categories. See below. -SENDSEQ - 0 => don't send packets with sequence numbers - 1 => send packets with sequence numbers -RECVSEQ - 0 => receive packet sequence numbers are optional - 1 => drop receive packets without sequence numbers -LNSMODE - 0 => act as LAC. - 1 => act as LNS. -REORDERTO - reorder timeout (in millisecs). If 0, don't try to reorder. - -Only the DEBUG option is supported by the special tunnel management -PPPoX socket. - -In addition to the standard PPP ioctls, a PPPIOCGL2TPSTATS is provided -to retrieve tunnel and session statistics from the kernel using the -PPPoX socket of the appropriate tunnel or session. - -Debugging -========= - -The driver supports a flexible debug scheme where kernel trace -messages may be optionally enabled per tunnel and per session. Care is -needed when debugging a live system since the messages are not -rate-limited and a busy system could be swamped. Userspace uses -setsockopt on the PPPoX socket to set a debug mask. - -The following debug mask bits are available: - -PPPOL2TP_MSG_DEBUG verbose debug (if compiled in) -PPPOL2TP_MSG_CONTROL userspace - kernel interface -PPPOL2TP_MSG_SEQ sequence numbers handling -PPPOL2TP_MSG_DATA data packets - -Sample Userspace Code -===================== - -1. Create tunnel management PPPoX socket - - kernel_fd = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP); - if (kernel_fd >= 0) { - struct sockaddr_pppol2tp sax; - struct sockaddr_in const *peer_addr; - - peer_addr = l2tp_tunnel_get_peer_addr(tunnel); - memset(&sax, 0, sizeof(sax)); - sax.sa_family = AF_PPPOX; - sax.sa_protocol = PX_PROTO_OL2TP; - sax.pppol2tp.fd = udp_fd; /* fd of tunnel UDP socket */ - sax.pppol2tp.addr.sin_addr.s_addr = peer_addr->sin_addr.s_addr; - sax.pppol2tp.addr.sin_port = peer_addr->sin_port; - sax.pppol2tp.addr.sin_family = AF_INET; - sax.pppol2tp.s_tunnel = tunnel_id; - sax.pppol2tp.s_session = 0; /* special case: mgmt socket */ - sax.pppol2tp.d_tunnel = 0; - sax.pppol2tp.d_session = 0; /* special case: mgmt socket */ - - if(connect(kernel_fd, (struct sockaddr *)&sax, sizeof(sax) ) < 0 ) { - perror("connect failed"); - result = -errno; - goto err; - } - } - -2. Create session PPPoX data socket - - struct sockaddr_pppol2tp sax; - int fd; - - /* Note, the target socket must be bound already, else it will not be ready */ - sax.sa_family = AF_PPPOX; - sax.sa_protocol = PX_PROTO_OL2TP; - sax.pppol2tp.fd = tunnel_fd; - sax.pppol2tp.addr.sin_addr.s_addr = addr->sin_addr.s_addr; - sax.pppol2tp.addr.sin_port = addr->sin_port; - sax.pppol2tp.addr.sin_family = AF_INET; - sax.pppol2tp.s_tunnel = tunnel_id; - sax.pppol2tp.s_session = session_id; - sax.pppol2tp.d_tunnel = peer_tunnel_id; - sax.pppol2tp.d_session = peer_session_id; - - /* session_fd is the fd of the session's PPPoL2TP socket. - * tunnel_fd is the fd of the tunnel UDP socket. - */ - fd = connect(session_fd, (struct sockaddr *)&sax, sizeof(sax)); - if (fd < 0 ) { - return -errno; - } - return 0; - -Miscellanous -============ - -The PPPoL2TP driver was developed as part of the OpenL2TP project by -Katalix Systems Ltd. OpenL2TP is a full-featured L2TP client / server, -designed from the ground up to have the L2TP datapath in the -kernel. The project also implemented the pppol2tp plugin for pppd -which allows pppd to use the kernel driver. Details can be found at -http://openl2tp.sourceforge.net. diff --git a/trunk/Documentation/networking/multiqueue.txt b/trunk/Documentation/networking/multiqueue.txt deleted file mode 100644 index 00b60cce2224..000000000000 --- a/trunk/Documentation/networking/multiqueue.txt +++ /dev/null @@ -1,111 +0,0 @@ - - HOWTO for multiqueue network device support - =========================================== - -Section 1: Base driver requirements for implementing multiqueue support -Section 2: Qdisc support for multiqueue devices -Section 3: Brief howto using PRIO or RR for multiqueue devices - - -Intro: Kernel support for multiqueue devices ---------------------------------------------------------- - -Kernel support for multiqueue devices is only an API that is presented to the -netdevice layer for base drivers to implement. This feature is part of the -core networking stack, and all network devices will be running on the -multiqueue-aware stack. If a base driver only has one queue, then these -changes are transparent to that driver. - - -Section 1: Base driver requirements for implementing multiqueue support ------------------------------------------------------------------------ - -Base drivers are required to use the new alloc_etherdev_mq() or -alloc_netdev_mq() functions to allocate the subqueues for the device. The -underlying kernel API will take care of the allocation and deallocation of -the subqueue memory, as well as netdev configuration of where the queues -exist in memory. - -The base driver will also need to manage the queues as it does the global -netdev->queue_lock today. Therefore base drivers should use the -netif_{start|stop|wake}_subqueue() functions to manage each queue while the -device is still operational. netdev->queue_lock is still used when the device -comes online or when it's completely shut down (unregister_netdev(), etc.). - -Finally, the base driver should indicate that it is a multiqueue device. The -feature flag NETIF_F_MULTI_QUEUE should be added to the netdev->features -bitmap on device initialization. Below is an example from e1000: - -#ifdef CONFIG_E1000_MQ - if ( (adapter->hw.mac.type == e1000_82571) || - (adapter->hw.mac.type == e1000_82572) || - (adapter->hw.mac.type == e1000_80003es2lan)) - netdev->features |= NETIF_F_MULTI_QUEUE; -#endif - - -Section 2: Qdisc support for multiqueue devices ------------------------------------------------ - -Currently two qdiscs support multiqueue devices. A new round-robin qdisc, -sch_rr, and sch_prio. The qdisc is responsible for classifying the skb's to -bands and queues, and will store the queue mapping into skb->queue_mapping. -Use this field in the base driver to determine which queue to send the skb -to. - -sch_rr has been added for hardware that doesn't want scheduling policies from -software, so it's a straight round-robin qdisc. It uses the same syntax and -classification priomap that sch_prio uses, so it should be intuitive to -configure for people who've used sch_prio. - -The PRIO qdisc naturally plugs into a multiqueue device. If PRIO has been -built with NET_SCH_PRIO_MQ, then upon load, it will make sure the number of -bands requested is equal to the number of queues on the hardware. If they -are equal, it sets a one-to-one mapping up between the queues and bands. If -they're not equal, it will not load the qdisc. This is the same behavior -for RR. Once the association is made, any skb that is classified will have -skb->queue_mapping set, which will allow the driver to properly queue skb's -to multiple queues. - - -Section 3: Brief howto using PRIO and RR for multiqueue devices ---------------------------------------------------------------- - -The userspace command 'tc,' part of the iproute2 package, is used to configure -qdiscs. To add the PRIO qdisc to your network device, assuming the device is -called eth0, run the following command: - -# tc qdisc add dev eth0 root handle 1: prio bands 4 multiqueue - -This will create 4 bands, 0 being highest priority, and associate those bands -to the queues on your NIC. Assuming eth0 has 4 Tx queues, the band mapping -would look like: - -band 0 => queue 0 -band 1 => queue 1 -band 2 => queue 2 -band 3 => queue 3 - -Traffic will begin flowing through each queue if your TOS values are assigning -traffic across the various bands. For example, ssh traffic will always try to -go out band 0 based on TOS -> Linux priority conversion (realtime traffic), -so it will be sent out queue 0. ICMP traffic (pings) fall into the "normal" -traffic classification, which is band 1. Therefore pings will be send out -queue 1 on the NIC. - -Note the use of the multiqueue keyword. This is only in versions of iproute2 -that support multiqueue networking devices; if this is omitted when loading -a qdisc onto a multiqueue device, the qdisc will load and operate the same -if it were loaded onto a single-queue device (i.e. - sends all traffic to -queue 0). - -Another alternative to multiqueue band allocation can be done by using the -multiqueue option and specify 0 bands. If this is the case, the qdisc will -allocate the number of bands to equal the number of queues that the device -reports, and bring the qdisc online. - -The behavior of tc filters remains the same, where it will override TOS priority -classification. - - -Author: Peter P. Waskiewicz Jr. diff --git a/trunk/Documentation/networking/netdevices.txt b/trunk/Documentation/networking/netdevices.txt index 37869295fc70..847cedb238f6 100644 --- a/trunk/Documentation/networking/netdevices.txt +++ b/trunk/Documentation/networking/netdevices.txt @@ -20,30 +20,6 @@ private data which gets freed when the network device is freed. If separately allocated data is attached to the network device (dev->priv) then it is up to the module exit handler to free that. -MTU -=== -Each network device has a Maximum Transfer Unit. The MTU does not -include any link layer protocol overhead. Upper layer protocols must -not pass a socket buffer (skb) to a device to transmit with more data -than the mtu. The MTU does not include link layer header overhead, so -for example on Ethernet if the standard MTU is 1500 bytes used, the -actual skb will contain up to 1514 bytes because of the Ethernet -header. Devices should allow for the 4 byte VLAN header as well. - -Segmentation Offload (GSO, TSO) is an exception to this rule. The -upper layer protocol may pass a large socket buffer to the device -transmit routine, and the device will break that up into separate -packets based on the current MTU. - -MTU is symmetrical and applies both to receive and transmit. A device -must be able to receive at least the maximum size packet allowed by -the MTU. A network device may use the MTU as mechanism to size receive -buffers, but the device should allow packets with VLAN header. With -standard Ethernet mtu of 1500 bytes, the device should allow up to -1518 byte packets (1500 + 14 header + 4 tag). The device may either: -drop, truncate, or pass up oversize packets, but dropping oversize -packets is preferred. - struct net_device synchronization rules ======================================= @@ -67,17 +43,16 @@ dev->get_stats: dev->hard_start_xmit: Synchronization: netif_tx_lock spinlock. - When the driver sets NETIF_F_LLTX in dev->features this will be called without holding netif_tx_lock. In this case the driver has to lock by itself when needed. It is recommended to use a try lock - for this and return NETDEV_TX_LOCKED when the spin lock fails. + for this and return -1 when the spin lock fails. The locking there should also properly protect against - set_multicast_list. - - Context: Process with BHs disabled or BH (timer), - will be called with interrupts disabled by netconsole. - + set_multicast_list + Context: BHs disabled + Notes: netif_queue_stopped() is guaranteed false + Interrupts must be enabled when calling hard_start_xmit. + (Interrupts must also be enabled when enabling the BH handler.) Return codes: o NETDEV_TX_OK everything ok. o NETDEV_TX_BUSY Cannot transmit packet, try later @@ -99,5 +74,4 @@ dev->poll: Synchronization: __LINK_STATE_RX_SCHED bit in dev->state. See dev_close code and comments in net/core/dev.c for more info. Context: softirq - will be called with interrupts disabled by netconsole. diff --git a/trunk/Documentation/networking/sk98lin.txt b/trunk/Documentation/networking/sk98lin.txt new file mode 100644 index 000000000000..8590a954df1d --- /dev/null +++ b/trunk/Documentation/networking/sk98lin.txt @@ -0,0 +1,568 @@ +(C)Copyright 1999-2004 Marvell(R). +All rights reserved +=========================================================================== + +sk98lin.txt created 13-Feb-2004 + +Readme File for sk98lin v6.23 +Marvell Yukon/SysKonnect SK-98xx Gigabit Ethernet Adapter family driver for LINUX + +This file contains + 1 Overview + 2 Required Files + 3 Installation + 3.1 Driver Installation + 3.2 Inclusion of adapter at system start + 4 Driver Parameters + 4.1 Per-Port Parameters + 4.2 Adapter Parameters + 5 Large Frame Support + 6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad) + 7 Troubleshooting + +=========================================================================== + + +1 Overview +=========== + +The sk98lin driver supports the Marvell Yukon and SysKonnect +SK-98xx/SK-95xx compliant Gigabit Ethernet Adapter on Linux. It has +been tested with Linux on Intel/x86 machines. +*** + + +2 Required Files +================= + +The linux kernel source. +No additional files required. +*** + + +3 Installation +=============== + +It is recommended to download the latest version of the driver from the +SysKonnect web site www.syskonnect.com. If you have downloaded the latest +driver, the Linux kernel has to be patched before the driver can be +installed. For details on how to patch a Linux kernel, refer to the +patch.txt file. + +3.1 Driver Installation +------------------------ + +The following steps describe the actions that are required to install +the driver and to start it manually. These steps should be carried +out for the initial driver setup. Once confirmed to be ok, they can +be included in the system start. + +NOTE 1: To perform the following tasks you need 'root' access. + +NOTE 2: In case of problems, please read the section "Troubleshooting" + below. + +The driver can either be integrated into the kernel or it can be compiled +as a module. Select the appropriate option during the kernel +configuration. + +Compile/use the driver as a module +---------------------------------- +To compile the driver, go to the directory /usr/src/linux and +execute the command "make menuconfig" or "make xconfig" and proceed as +follows: + +To integrate the driver permanently into the kernel, proceed as follows: + +1. Select the menu "Network device support" and then "Ethernet(1000Mbit)" +2. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support" + with (*) +3. Build a new kernel when the configuration of the above options is + finished. +4. Install the new kernel. +5. Reboot your system. + +To use the driver as a module, proceed as follows: + +1. Enable 'loadable module support' in the kernel. +2. For automatic driver start, enable the 'Kernel module loader'. +3. Select the menu "Network device support" and then "Ethernet(1000Mbit)" +4. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support" + with (M) +5. Execute the command "make modules". +6. Execute the command "make modules_install". + The appropriate modules will be installed. +7. Reboot your system. + + +Load the module manually +------------------------ +To load the module manually, proceed as follows: + +1. Enter "modprobe sk98lin". +2. If a Marvell Yukon or SysKonnect SK-98xx adapter is installed in + your computer and you have a /proc file system, execute the command: + "ls /proc/net/sk98lin/" + This should produce an output containing a line with the following + format: + eth0 eth1 ... + which indicates that your adapter has been found and initialized. + + NOTE 1: If you have more than one Marvell Yukon or SysKonnect SK-98xx + adapter installed, the adapters will be listed as 'eth0', + 'eth1', 'eth2', etc. + For each adapter, repeat steps 3 and 4 below. + + NOTE 2: If you have other Ethernet adapters installed, your Marvell + Yukon or SysKonnect SK-98xx adapter will be mapped to the + next available number, e.g. 'eth1'. The mapping is executed + automatically. + The module installation message (displayed either in a system + log file or on the console) prints a line for each adapter + found containing the corresponding 'ethX'. + +3. Select an IP address and assign it to the respective adapter by + entering: + ifconfig eth0 + With this command, the adapter is connected to the Ethernet. + + SK-98xx Gigabit Ethernet Server Adapters: The yellow LED on the adapter + is now active, the link status LED of the primary port is active and + the link status LED of the secondary port (on dual port adapters) is + blinking (if the ports are connected to a switch or hub). + SK-98xx V2.0 Gigabit Ethernet Adapters: The link status LED is active. + In addition, you will receive a status message on the console stating + "ethX: network connection up using port Y" and showing the selected + connection parameters (x stands for the ethernet device number + (0,1,2, etc), y stands for the port name (A or B)). + + NOTE: If you are in doubt about IP addresses, ask your network + administrator for assistance. + +4. Your adapter should now be fully operational. + Use 'ping ' to verify the connection to other computers + on your network. +5. To check the adapter configuration view /proc/net/sk98lin/[devicename]. + For example by executing: + "cat /proc/net/sk98lin/eth0" + +Unload the module +----------------- +To stop and unload the driver modules, proceed as follows: + +1. Execute the command "ifconfig eth0 down". +2. Execute the command "rmmod sk98lin". + +3.2 Inclusion of adapter at system start +----------------------------------------- + +Since a large number of different Linux distributions are +available, we are unable to describe a general installation procedure +for the driver module. +Because the driver is now integrated in the kernel, installation should +be easy, using the standard mechanism of your distribution. +Refer to the distribution's manual for installation of ethernet adapters. + +*** + +4 Driver Parameters +==================== + +Parameters can be set at the command line after the module has been +loaded with the command 'modprobe'. +In some distributions, the configuration tools are able to pass parameters +to the driver module. + +If you use the kernel module loader, you can set driver parameters +in the file /etc/modprobe.conf (or /etc/modules.conf in 2.4 or earlier). +To set the driver parameters in this file, proceed as follows: + +1. Insert a line of the form : + options sk98lin ... + For "...", the same syntax is required as described for the command + line parameters of modprobe below. +2. To activate the new parameters, either reboot your computer + or + unload and reload the driver. + The syntax of the driver parameters is: + + modprobe sk98lin parameter=value1[,value2[,value3...]] + + where value1 refers to the first adapter, value2 to the second etc. + +NOTE: All parameters are case sensitive. Write them exactly as shown + below. + +Example: +Suppose you have two adapters. You want to set auto-negotiation +on the first adapter to ON and on the second adapter to OFF. +You also want to set DuplexCapabilities on the first adapter +to FULL, and on the second adapter to HALF. +Then, you must enter: + + modprobe sk98lin AutoNeg_A=On,Off DupCap_A=Full,Half + +NOTE: The number of adapters that can be configured this way is + limited in the driver (file skge.c, constant SK_MAX_CARD_PARAM). + The current limit is 16. If you happen to install + more adapters, adjust this and recompile. + + +4.1 Per-Port Parameters +------------------------ + +These settings are available for each port on the adapter. +In the following description, '?' stands for the port for +which you set the parameter (A or B). + +Speed +----- +Parameter: Speed_? +Values: 10, 100, 1000, Auto +Default: Auto + +This parameter is used to set the speed capabilities. It is only valid +for the SK-98xx V2.0 copper adapters. +Usually, the speed is negotiated between the two ports during link +establishment. If this fails, a port can be forced to a specific setting +with this parameter. + +Auto-Negotiation +---------------- +Parameter: AutoNeg_? +Values: On, Off, Sense +Default: On + +The "Sense"-mode automatically detects whether the link partner supports +auto-negotiation or not. + +Duplex Capabilities +------------------- +Parameter: DupCap_? +Values: Half, Full, Both +Default: Both + +This parameters is only relevant if auto-negotiation for this port is +not set to "Sense". If auto-negotiation is set to "On", all three values +are possible. If it is set to "Off", only "Full" and "Half" are allowed. +This parameter is useful if your link partner does not support all +possible combinations. + +Flow Control +------------ +Parameter: FlowCtrl_? +Values: Sym, SymOrRem, LocSend, None +Default: SymOrRem + +This parameter can be used to set the flow control capabilities the +port reports during auto-negotiation. It can be set for each port +individually. +Possible modes: + -- Sym = Symmetric: both link partners are allowed to send + PAUSE frames + -- SymOrRem = SymmetricOrRemote: both or only remote partner + are allowed to send PAUSE frames + -- LocSend = LocalSend: only local link partner is allowed + to send PAUSE frames + -- None = no link partner is allowed to send PAUSE frames + +NOTE: This parameter is ignored if auto-negotiation is set to "Off". + +Role in Master-Slave-Negotiation (1000Base-T only) +-------------------------------------------------- +Parameter: Role_? +Values: Auto, Master, Slave +Default: Auto + +This parameter is only valid for the SK-9821 and SK-9822 adapters. +For two 1000Base-T ports to communicate, one must take the role of the +master (providing timing information), while the other must be the +slave. Usually, this is negotiated between the two ports during link +establishment. If this fails, a port can be forced to a specific setting +with this parameter. + + +4.2 Adapter Parameters +----------------------- + +Connection Type (SK-98xx V2.0 copper adapters only) +--------------- +Parameter: ConType +Values: Auto, 100FD, 100HD, 10FD, 10HD +Default: Auto + +The parameter 'ConType' is a combination of all five per-port parameters +within one single parameter. This simplifies the configuration of both ports +of an adapter card! The different values of this variable reflect the most +meaningful combinations of port parameters. + +The following table shows the values of 'ConType' and the corresponding +combinations of the per-port parameters: + + ConType | DupCap AutoNeg FlowCtrl Role Speed + ----------+------------------------------------------------------ + Auto | Both On SymOrRem Auto Auto + 100FD | Full Off None Auto (ignored) 100 + 100HD | Half Off None Auto (ignored) 100 + 10FD | Full Off None Auto (ignored) 10 + 10HD | Half Off None Auto (ignored) 10 + +Stating any other port parameter together with this 'ConType' variable +will result in a merged configuration of those settings. This due to +the fact, that the per-port parameters (e.g. Speed_? ) have a higher +priority than the combined variable 'ConType'. + +NOTE: This parameter is always used on both ports of the adapter card. + +Interrupt Moderation +-------------------- +Parameter: Moderation +Values: None, Static, Dynamic +Default: None + +Interrupt moderation is employed to limit the maximum number of interrupts +the driver has to serve. That is, one or more interrupts (which indicate any +transmit or receive packet to be processed) are queued until the driver +processes them. When queued interrupts are to be served, is determined by the +'IntsPerSec' parameter, which is explained later below. + +Possible modes: + + -- None - No interrupt moderation is applied on the adapter card. + Therefore, each transmit or receive interrupt is served immediately + as soon as it appears on the interrupt line of the adapter card. + + -- Static - Interrupt moderation is applied on the adapter card. + All transmit and receive interrupts are queued until a complete + moderation interval ends. If such a moderation interval ends, all + queued interrupts are processed in one big bunch without any delay. + The term 'static' reflects the fact, that interrupt moderation is + always enabled, regardless how much network load is currently + passing via a particular interface. In addition, the duration of + the moderation interval has a fixed length that never changes while + the driver is operational. + + -- Dynamic - Interrupt moderation might be applied on the adapter card, + depending on the load of the system. If the driver detects that the + system load is too high, the driver tries to shield the system against + too much network load by enabling interrupt moderation. If - at a later + time - the CPU utilization decreases again (or if the network load is + negligible) the interrupt moderation will automatically be disabled. + +Interrupt moderation should be used when the driver has to handle one or more +interfaces with a high network load, which - as a consequence - leads also to a +high CPU utilization. When moderation is applied in such high network load +situations, CPU load might be reduced by 20-30%. + +NOTE: The drawback of using interrupt moderation is an increase of the round- +trip-time (RTT), due to the queueing and serving of interrupts at dedicated +moderation times. + +Interrupts per second +--------------------- +Parameter: IntsPerSec +Values: 30...40000 (interrupts per second) +Default: 2000 + +This parameter is only used if either static or dynamic interrupt moderation +is used on a network adapter card. Using this parameter if no moderation is +applied will lead to no action performed. + +This parameter determines the length of any interrupt moderation interval. +Assuming that static interrupt moderation is to be used, an 'IntsPerSec' +parameter value of 2000 will lead to an interrupt moderation interval of +500 microseconds. + +NOTE: The duration of the moderation interval is to be chosen with care. +At first glance, selecting a very long duration (e.g. only 100 interrupts per +second) seems to be meaningful, but the increase of packet-processing delay +is tremendous. On the other hand, selecting a very short moderation time might +compensate the use of any moderation being applied. + + +Preferred Port +-------------- +Parameter: PrefPort +Values: A, B +Default: A + +This is used to force the preferred port to A or B (on dual-port network +adapters). The preferred port is the one that is used if both are detected +as fully functional. + +RLMT Mode (Redundant Link Management Technology) +------------------------------------------------ +Parameter: RlmtMode +Values: CheckLinkState,CheckLocalPort, CheckSeg, DualNet +Default: CheckLinkState + +RLMT monitors the status of the port. If the link of the active port +fails, RLMT switches immediately to the standby link. The virtual link is +maintained as long as at least one 'physical' link is up. + +Possible modes: + + -- CheckLinkState - Check link state only: RLMT uses the link state + reported by the adapter hardware for each individual port to + determine whether a port can be used for all network traffic or + not. + + -- CheckLocalPort - In this mode, RLMT monitors the network path + between the two ports of an adapter by regularly exchanging packets + between them. This mode requires a network configuration in which + the two ports are able to "see" each other (i.e. there must not be + any router between the ports). + + -- CheckSeg - Check local port and segmentation: This mode supports the + same functions as the CheckLocalPort mode and additionally checks + network segmentation between the ports. Therefore, this mode is only + to be used if Gigabit Ethernet switches are installed on the network + that have been configured to use the Spanning Tree protocol. + + -- DualNet - In this mode, ports A and B are used as separate devices. + If you have a dual port adapter, port A will be configured as eth0 + and port B as eth1. Both ports can be used independently with + distinct IP addresses. The preferred port setting is not used. + RLMT is turned off. + +NOTE: RLMT modes CLP and CLPSS are designed to operate in configurations + where a network path between the ports on one adapter exists. + Moreover, they are not designed to work where adapters are connected + back-to-back. +*** + + +5 Large Frame Support +====================== + +The driver supports large frames (also called jumbo frames). Using large +frames can result in an improved throughput if transferring large amounts +of data. +To enable large frames, set the MTU (maximum transfer unit) of the +interface to the desired value (up to 9000), execute the following +command: + ifconfig eth0 mtu 9000 +This will only work if you have two adapters connected back-to-back +or if you use a switch that supports large frames. When using a switch, +it should be configured to allow large frames and auto-negotiation should +be set to OFF. The setting must be configured on all adapters that can be +reached by the large frames. If one adapter is not set to receive large +frames, it will simply drop them. + +You can switch back to the standard ethernet frame size by executing the +following command: + ifconfig eth0 mtu 1500 + +To permanently configure this setting, add a script with the 'ifconfig' +line to the system startup sequence (named something like "S99sk98lin" +in /etc/rc.d/rc2.d). +*** + + +6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad) +================================================================== + +The Marvell Yukon/SysKonnect Linux drivers are able to support VLAN and +Link Aggregation according to IEEE standards 802.1, 802.1q, and 802.3ad. +These features are only available after installation of open source +modules available on the Internet: +For VLAN go to: http://www.candelatech.com/~greear/vlan.html +For Link Aggregation go to: http://www.st.rim.or.jp/~yumo + +NOTE: SysKonnect GmbH does not offer any support for these open source + modules and does not take the responsibility for any kind of + failures or problems arising in connection with these modules. + +NOTE: Configuring Link Aggregation on a SysKonnect dual link adapter may + cause problems when unloading the driver. + + +7 Troubleshooting +================== + +If any problems occur during the installation process, check the +following list: + + +Problem: The SK-98xx adapter cannot be found by the driver. +Solution: In /proc/pci search for the following entry: + 'Ethernet controller: SysKonnect SK-98xx ...' + If this entry exists, the SK-98xx or SK-98xx V2.0 adapter has + been found by the system and should be operational. + If this entry does not exist or if the file '/proc/pci' is not + found, there may be a hardware problem or the PCI support may + not be enabled in your kernel. + The adapter can be checked using the diagnostics program which + is available on the SysKonnect web site: + www.syskonnect.com + + Some COMPAQ machines have problems dealing with PCI under Linux. + This problem is described in the 'PCI howto' document + (included in some distributions or available from the + web, e.g. at 'www.linux.org'). + + +Problem: Programs such as 'ifconfig' or 'route' cannot be found or the + error message 'Operation not permitted' is displayed. +Reason: You are not logged in as user 'root'. +Solution: Logout and login as 'root' or change to 'root' via 'su'. + + +Problem: Upon use of the command 'ping
' the message + "ping: sendto: Network is unreachable" is displayed. +Reason: Your route is not set correctly. +Solution: If you are using RedHat, you probably forgot to set up the + route in the 'network configuration'. + Check the existing routes with the 'route' command and check + if an entry for 'eth0' exists, and if so, if it is set correctly. + + +Problem: The driver can be started, the adapter is connected to the + network, but you cannot receive or transmit any packets; + e.g. 'ping' does not work. +Reason: There is an incorrect route in your routing table. +Solution: Check the routing table with the command 'route' and read the + manual help pages dealing with routes (enter 'man route'). + +NOTE: Although the 2.2.x kernel versions generate the routing entry + automatically, problems of this kind may occur here as well. We've + come across a situation in which the driver started correctly at + system start, but after the driver has been removed and reloaded, + the route of the adapter's network pointed to the 'dummy0'device + and had to be corrected manually. + + +Problem: Your computer should act as a router between multiple + IP subnetworks (using multiple adapters), but computers in + other subnetworks cannot be reached. +Reason: Either the router's kernel is not configured for IP forwarding + or the routing table and gateway configuration of at least one + computer is not working. + +Problem: Upon driver start, the following error message is displayed: + "eth0: -- ERROR -- + Class: internal Software error + Nr: 0xcc + Msg: SkGeInitPort() cannot init running ports" +Reason: You are using a driver compiled for single processor machines + on a multiprocessor machine with SMP (Symmetric MultiProcessor) + kernel. +Solution: Configure your kernel appropriately and recompile the kernel or + the modules. + + + +If your problem is not listed here, please contact SysKonnect's technical +support for help (linux@syskonnect.de). +When contacting our technical support, please ensure that the following +information is available: +- System Manufacturer and HW Informations (CPU, Memory... ) +- PCI-Boards in your system +- Distribution +- Kernel version +- Driver version +*** + + + +***End of Readme File*** diff --git a/trunk/Documentation/networking/spider_net.txt b/trunk/Documentation/networking/spider_net.txt deleted file mode 100644 index 4b4adb8eb14f..000000000000 --- a/trunk/Documentation/networking/spider_net.txt +++ /dev/null @@ -1,204 +0,0 @@ - - The Spidernet Device Driver - =========================== - -Written by Linas Vepstas - -Version of 7 June 2007 - -Abstract -======== -This document sketches the structure of portions of the spidernet -device driver in the Linux kernel tree. The spidernet is a gigabit -ethernet device built into the Toshiba southbridge commonly used -in the SONY Playstation 3 and the IBM QS20 Cell blade. - -The Structure of the RX Ring. -============================= -The receive (RX) ring is a circular linked list of RX descriptors, -together with three pointers into the ring that are used to manage its -contents. - -The elements of the ring are called "descriptors" or "descrs"; they -describe the received data. This includes a pointer to a buffer -containing the received data, the buffer size, and various status bits. - -There are three primary states that a descriptor can be in: "empty", -"full" and "not-in-use". An "empty" or "ready" descriptor is ready -to receive data from the hardware. A "full" descriptor has data in it, -and is waiting to be emptied and processed by the OS. A "not-in-use" -descriptor is neither empty or full; it is simply not ready. It may -not even have a data buffer in it, or is otherwise unusable. - -During normal operation, on device startup, the OS (specifically, the -spidernet device driver) allocates a set of RX descriptors and RX -buffers. These are all marked "empty", ready to receive data. This -ring is handed off to the hardware, which sequentially fills in the -buffers, and marks them "full". The OS follows up, taking the full -buffers, processing them, and re-marking them empty. - -This filling and emptying is managed by three pointers, the "head" -and "tail" pointers, managed by the OS, and a hardware current -descriptor pointer (GDACTDPA). The GDACTDPA points at the descr -currently being filled. When this descr is filled, the hardware -marks it full, and advances the GDACTDPA by one. Thus, when there is -flowing RX traffic, every descr behind it should be marked "full", -and everything in front of it should be "empty". If the hardware -discovers that the current descr is not empty, it will signal an -interrupt, and halt processing. - -The tail pointer tails or trails the hardware pointer. When the -hardware is ahead, the tail pointer will be pointing at a "full" -descr. The OS will process this descr, and then mark it "not-in-use", -and advance the tail pointer. Thus, when there is flowing RX traffic, -all of the descrs in front of the tail pointer should be "full", and -all of those behind it should be "not-in-use". When RX traffic is not -flowing, then the tail pointer can catch up to the hardware pointer. -The OS will then note that the current tail is "empty", and halt -processing. - -The head pointer (somewhat mis-named) follows after the tail pointer. -When traffic is flowing, then the head pointer will be pointing at -a "not-in-use" descr. The OS will perform various housekeeping duties -on this descr. This includes allocating a new data buffer and -dma-mapping it so as to make it visible to the hardware. The OS will -then mark the descr as "empty", ready to receive data. Thus, when there -is flowing RX traffic, everything in front of the head pointer should -be "not-in-use", and everything behind it should be "empty". If no -RX traffic is flowing, then the head pointer can catch up to the tail -pointer, at which point the OS will notice that the head descr is -"empty", and it will halt processing. - -Thus, in an idle system, the GDACTDPA, tail and head pointers will -all be pointing at the same descr, which should be "empty". All of the -other descrs in the ring should be "empty" as well. - -The show_rx_chain() routine will print out the the locations of the -GDACTDPA, tail and head pointers. It will also summarize the contents -of the ring, starting at the tail pointer, and listing the status -of the descrs that follow. - -A typical example of the output, for a nearly idle system, might be - -net eth1: Total number of descrs=256 -net eth1: Chain tail located at descr=20 -net eth1: Chain head is at 20 -net eth1: HW curr desc (GDACTDPA) is at 21 -net eth1: Have 1 descrs with stat=x40800101 -net eth1: HW next desc (GDACNEXTDA) is at 22 -net eth1: Last 255 descrs with stat=xa0800000 - -In the above, the hardware has filled in one descr, number 20. Both -head and tail are pointing at 20, because it has not yet been emptied. -Meanwhile, hw is pointing at 21, which is free. - -The "Have nnn decrs" refers to the descr starting at the tail: in this -case, nnn=1 descr, starting at descr 20. The "Last nnn descrs" refers -to all of the rest of the descrs, from the last status change. The "nnn" -is a count of how many descrs have exactly the same status. - -The status x4... corresponds to "full" and status xa... corresponds -to "empty". The actual value printed is RXCOMST_A. - -In the device driver source code, a different set of names are -used for these same concepts, so that - -"empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa -"full" == SPIDER_NET_DESCR_FRAME_END == 0x4 -"not in use" == SPIDER_NET_DESCR_NOT_IN_USE == 0xf - - -The RX RAM full bug/feature -=========================== - -As long as the OS can empty out the RX buffers at a rate faster than -the hardware can fill them, there is no problem. If, for some reason, -the OS fails to empty the RX ring fast enough, the hardware GDACTDPA -pointer will catch up to the head, notice the not-empty condition, -ad stop. However, RX packets may still continue arriving on the wire. -The spidernet chip can save some limited number of these in local RAM. -When this local ram fills up, the spider chip will issue an interrupt -indicating this (GHIINT0STS will show ERRINT, and the GRMFLLINT bit -will be set in GHIINT1STS). When the RX ram full condition occurs, -a certain bug/feature is triggered that has to be specially handled. -This section describes the special handling for this condition. - -When the OS finally has a chance to run, it will empty out the RX ring. -In particular, it will clear the descriptor on which the hardware had -stopped. However, once the hardware has decided that a certain -descriptor is invalid, it will not restart at that descriptor; instead -it will restart at the next descr. This potentially will lead to a -deadlock condition, as the tail pointer will be pointing at this descr, -which, from the OS point of view, is empty; the OS will be waiting for -this descr to be filled. However, the hardware has skipped this descr, -and is filling the next descrs. Since the OS doesn't see this, there -is a potential deadlock, with the OS waiting for one descr to fill, -while the hardware is waiting for a different set of descrs to become -empty. - -A call to show_rx_chain() at this point indicates the nature of the -problem. A typical print when the network is hung shows the following: - -net eth1: Spider RX RAM full, incoming packets might be discarded! -net eth1: Total number of descrs=256 -net eth1: Chain tail located at descr=255 -net eth1: Chain head is at 255 -net eth1: HW curr desc (GDACTDPA) is at 0 -net eth1: Have 1 descrs with stat=xa0800000 -net eth1: HW next desc (GDACNEXTDA) is at 1 -net eth1: Have 127 descrs with stat=x40800101 -net eth1: Have 1 descrs with stat=x40800001 -net eth1: Have 126 descrs with stat=x40800101 -net eth1: Last 1 descrs with stat=xa0800000 - -Both the tail and head pointers are pointing at descr 255, which is -marked xa... which is "empty". Thus, from the OS point of view, there -is nothing to be done. In particular, there is the implicit assumption -that everything in front of the "empty" descr must surely also be empty, -as explained in the last section. The OS is waiting for descr 255 to -become non-empty, which, in this case, will never happen. - -The HW pointer is at descr 0. This descr is marked 0x4.. or "full". -Since its already full, the hardware can do nothing more, and thus has -halted processing. Notice that descrs 0 through 254 are all marked -"full", while descr 254 and 255 are empty. (The "Last 1 descrs" is -descr 254, since tail was at 255.) Thus, the system is deadlocked, -and there can be no forward progress; the OS thinks there's nothing -to do, and the hardware has nowhere to put incoming data. - -This bug/feature is worked around with the spider_net_resync_head_ptr() -routine. When the driver receives RX interrupts, but an examination -of the RX chain seems to show it is empty, then it is probable that -the hardware has skipped a descr or two (sometimes dozens under heavy -network conditions). The spider_net_resync_head_ptr() subroutine will -search the ring for the next full descr, and the driver will resume -operations there. Since this will leave "holes" in the ring, there -is also a spider_net_resync_tail_ptr() that will skip over such holes. - -As of this writing, the spider_net_resync() strategy seems to work very -well, even under heavy network loads. - - -The TX ring -=========== -The TX ring uses a low-watermark interrupt scheme to make sure that -the TX queue is appropriately serviced for large packet sizes. - -For packet sizes greater than about 1KBytes, the kernel can fill -the TX ring quicker than the device can drain it. Once the ring -is full, the netdev is stopped. When there is room in the ring, -the netdev needs to be reawakened, so that more TX packets are placed -in the ring. The hardware can empty the ring about four times per jiffy, -so its not appropriate to wait for the poll routine to refill, since -the poll routine runs only once per jiffy. The low-watermark mechanism -marks a descr about 1/4th of the way from the bottom of the queue, so -that an interrupt is generated when the descr is processed. This -interrupt wakes up the netdev, which can then refill the queue. -For large packets, this mechanism generates a relatively small number -of interrupts, about 1K/sec. For smaller packets, this will drop to zero -interrupts, as the hardware can empty the queue faster than the kernel -can fill it. - - - ======= END OF DOCUMENT ======== - diff --git a/trunk/Documentation/networking/xfrm_sysctl.txt b/trunk/Documentation/networking/xfrm_sysctl.txt deleted file mode 100644 index 5bbd16792fe1..000000000000 --- a/trunk/Documentation/networking/xfrm_sysctl.txt +++ /dev/null @@ -1,4 +0,0 @@ -/proc/sys/net/core/xfrm_* Variables: - -xfrm_acq_expires - INTEGER - default 30 - hard timeout in seconds for acquire requests diff --git a/trunk/Documentation/pci.txt b/trunk/Documentation/pci.txt index 7754f5aea4e9..d38261b67905 100644 --- a/trunk/Documentation/pci.txt +++ b/trunk/Documentation/pci.txt @@ -113,6 +113,9 @@ initialization with a pointer to a structure describing the driver (Please see Documentation/power/pci.txt for descriptions of PCI Power Management and the related functions.) + enable_wake Enable device to generate wake events from a low power + state. + shutdown Hook into reboot_notifier_list (kernel/sys.c). Intended to stop any idling DMA operations. Useful for enabling wake-on-lan (NIC) or changing @@ -296,10 +299,7 @@ If the PCI device can use the PCI Memory-Write-Invalidate transaction, call pci_set_mwi(). This enables the PCI_COMMAND bit for Mem-Wr-Inval and also ensures that the cache line size register is set correctly. Check the return value of pci_set_mwi() as not all architectures -or chip-sets may support Memory-Write-Invalidate. Alternatively, -if Mem-Wr-Inval would be nice to have but is not required, call -pci_try_set_mwi() to have the system do its best effort at enabling -Mem-Wr-Inval. +or chip-sets may support Memory-Write-Invalidate. 3.2 Request MMIO/IOP resources diff --git a/trunk/Documentation/power/pci.txt b/trunk/Documentation/power/pci.txt index dd8fe43888d3..e00b099a4b86 100644 --- a/trunk/Documentation/power/pci.txt +++ b/trunk/Documentation/power/pci.txt @@ -164,6 +164,7 @@ struct pci_driver: int (*suspend) (struct pci_dev *dev, pm_message_t state); int (*resume) (struct pci_dev *dev); + int (*enable_wake) (struct pci_dev *dev, pci_power_t state, int enable); suspend @@ -250,6 +251,42 @@ The driver should update the current_state field in its pci_dev structure in this function, except for PM-capable devices when pci_set_power_state is used. +enable_wake +----------- + +Usage: + +if (dev->driver && dev->driver->enable_wake) + dev->driver->enable_wake(dev,state,enable); + +This callback is generally only relevant for devices that support the PCI PM +spec and have the ability to generate a PME# (Power Management Event Signal) +to wake the system up. (However, it is possible that a device may support +some non-standard way of generating a wake event on sleep.) + +Bits 15:11 of the PMC (Power Mgmt Capabilities) Register in a device's +PM Capabilities describe what power states the device supports generating a +wake event from: + ++------------------+ +| Bit | State | ++------------------+ +| 11 | D0 | +| 12 | D1 | +| 13 | D2 | +| 14 | D3hot | +| 15 | D3cold | ++------------------+ + +A device can use this to enable wake events: + + pci_enable_wake(dev,state,enable); + +Note that to enable PME# from D3cold, a value of 4 should be passed to +pci_enable_wake (since it uses an index into a bitmask). If a driver gets +a request to enable wake events from D3, two calls should be made to +pci_enable_wake (one for both D3hot and D3cold). + A reference implementation ------------------------- diff --git a/trunk/Documentation/power_supply_class.txt b/trunk/Documentation/power_supply_class.txt deleted file mode 100644 index 9758cf433c06..000000000000 --- a/trunk/Documentation/power_supply_class.txt +++ /dev/null @@ -1,167 +0,0 @@ -Linux power supply class -======================== - -Synopsis -~~~~~~~~ -Power supply class used to represent battery, UPS, AC or DC power supply -properties to user-space. - -It defines core set of attributes, which should be applicable to (almost) -every power supply out there. Attributes are available via sysfs and uevent -interfaces. - -Each attribute has well defined meaning, up to unit of measure used. While -the attributes provided are believed to be universally applicable to any -power supply, specific monitoring hardware may not be able to provide them -all, so any of them may be skipped. - -Power supply class is extensible, and allows to define drivers own attributes. -The core attribute set is subject to the standard Linux evolution (i.e. -if it will be found that some attribute is applicable to many power supply -types or their drivers, it can be added to the core set). - -It also integrates with LED framework, for the purpose of providing -typically expected feedback of battery charging/fully charged status and -AC/USB power supply online status. (Note that specific details of the -indication (including whether to use it at all) are fully controllable by -user and/or specific machine defaults, per design principles of LED -framework). - - -Attributes/properties -~~~~~~~~~~~~~~~~~~~~~ -Power supply class has predefined set of attributes, this eliminates code -duplication across drivers. Power supply class insist on reusing its -predefined attributes *and* their units. - -So, userspace gets predictable set of attributes and their units for any -kind of power supply, and can process/present them to a user in consistent -manner. Results for different power supplies and machines are also directly -comparable. - -See drivers/power/ds2760_battery.c and drivers/power/pda_power.c for the -example how to declare and handle attributes. - - -Units -~~~~~ -Quoting include/linux/power_supply.h: - - All voltages, currents, charges, energies, time and temperatures in µV, - µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise - stated. It's driver's job to convert its raw values to units in which - this class operates. - - -Attributes/properties detailed -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -~ ~ ~ ~ ~ ~ ~ Charge/Energy/Capacity - how to not confuse ~ ~ ~ ~ ~ ~ ~ -~ ~ -~ Because both "charge" (µAh) and "energy" (µWh) represents "capacity" ~ -~ of battery, this class distinguish these terms. Don't mix them! ~ -~ ~ -~ CHARGE_* attributes represents capacity in µAh only. ~ -~ ENERGY_* attributes represents capacity in µWh only. ~ -~ CAPACITY attribute represents capacity in *percents*, from 0 to 100. ~ -~ ~ -~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ - -Postfixes: -_AVG - *hardware* averaged value, use it if your hardware is really able to -report averaged values. -_NOW - momentary/instantaneous values. - -STATUS - this attribute represents operating status (charging, full, -discharging (i.e. powering a load), etc.). This corresponds to -BATTERY_STATUS_* values, as defined in battery.h. - -HEALTH - represents health of the battery, values corresponds to -POWER_SUPPLY_HEALTH_*, defined in battery.h. - -VOLTAGE_MAX_DESIGN, VOLTAGE_MIN_DESIGN - design values for maximal and -minimal power supply voltages. Maximal/minimal means values of voltages -when battery considered "full"/"empty" at normal conditions. Yes, there is -no direct relation between voltage and battery capacity, but some dumb -batteries use voltage for very approximated calculation of capacity. -Battery driver also can use this attribute just to inform userspace -about maximal and minimal voltage thresholds of a given battery. - -CHARGE_FULL_DESIGN, CHARGE_EMPTY_DESIGN - design charge values, when -battery considered full/empty. - -ENERGY_FULL_DESIGN, ENERGY_EMPTY_DESIGN - same as above but for energy. - -CHARGE_FULL, CHARGE_EMPTY - These attributes means "last remembered value -of charge when battery became full/empty". It also could mean "value of -charge when battery considered full/empty at given conditions (temperature, -age)". I.e. these attributes represents real thresholds, not design values. - -ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. - -CAPACITY - capacity in percents. -CAPACITY_LEVEL - capacity level. This corresponds to -POWER_SUPPLY_CAPACITY_LEVEL_*. - -TEMP - temperature of the power supply. -TEMP_AMBIENT - ambient temperature. - -TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. -while battery powers a load) -TIME_TO_FULL - seconds left for battery to be considered full (i.e. -while battery is charging) - - -Battery <-> external power supply interaction -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Often power supplies are acting as supplies and supplicants at the same -time. Batteries are good example. So, batteries usually care if they're -externally powered or not. - -For that case, power supply class implements notification mechanism for -batteries. - -External power supply (AC) lists supplicants (batteries) names in -"supplied_to" struct member, and each power_supply_changed() call -issued by external power supply will notify supplicants via -external_power_changed callback. - - -QA -~~ -Q: Where is POWER_SUPPLY_PROP_XYZ attribute? -A: If you cannot find attribute suitable for your driver needs, feel free - to add it and send patch along with your driver. - - The attributes available currently are the ones currently provided by the - drivers written. - - Good candidates to add in future: model/part#, cycle_time, manufacturer, - etc. - - -Q: I have some very specific attribute (e.g. battery color), should I add - this attribute to standard ones? -A: Most likely, no. Such attribute can be placed in the driver itself, if - it is useful. Of course, if the attribute in question applicable to - large set of batteries, provided by many drivers, and/or comes from - some general battery specification/standard, it may be a candidate to - be added to the core attribute set. - - -Q: Suppose, my battery monitoring chip/firmware does not provides capacity - in percents, but provides charge_{now,full,empty}. Should I calculate - percentage capacity manually, inside the driver, and register CAPACITY - attribute? The same question about time_to_empty/time_to_full. -A: Most likely, no. This class is designed to export properties which are - directly measurable by the specific hardware available. - - Inferring not available properties using some heuristics or mathematical - model is not subject of work for a battery driver. Such functionality - should be factored out, and in fact, apm_power, the driver to serve - legacy APM API on top of power supply class, uses a simple heuristic of - approximating remaining battery capacity based on its charge, current, - voltage and so on. But full-fledged battery model is likely not subject - for kernel at all, as it would require floating point calculation to deal - with things like differential equations and Kalman filters. This is - better be handled by batteryd/libbattery, yet to be written. diff --git a/trunk/Documentation/powerpc/booting-without-of.txt b/trunk/Documentation/powerpc/booting-without-of.txt index d42d98107d49..b49ce169a63a 100644 --- a/trunk/Documentation/powerpc/booting-without-of.txt +++ b/trunk/Documentation/powerpc/booting-without-of.txt @@ -1,6 +1,7 @@ Booting the Linux/ppc kernel without Open Firmware -------------------------------------------------- + (c) 2005 Benjamin Herrenschmidt , IBM Corp. (c) 2005 Becky Bruce , @@ -8,62 +9,6 @@ (c) 2006 MontaVista Software, Inc. Flash chip node definition -Table of Contents -================= - - I - Introduction - 1) Entry point for arch/powerpc - 2) Board support - - II - The DT block format - 1) Header - 2) Device tree generalities - 3) Device tree "structure" block - 4) Device tree "strings" block - - III - Required content of the device tree - 1) Note about cells and address representation - 2) Note about "compatible" properties - 3) Note about "name" properties - 4) Note about node and property names and character set - 5) Required nodes and properties - a) The root node - b) The /cpus node - c) The /cpus/* nodes - d) the /memory node(s) - e) The /chosen node - f) the /soc node - - IV - "dtc", the device tree compiler - - V - Recommendations for a bootloader - - VI - System-on-a-chip devices and nodes - 1) Defining child nodes of an SOC - 2) Representing devices without a current OF specification - a) MDIO IO device - c) PHY nodes - b) Gianfar-compatible ethernet nodes - d) Interrupt controllers - e) I2C - f) Freescale SOC USB controllers - g) Freescale SOC SEC Security Engines - h) Board Control and Status (BCSR) - i) Freescale QUICC Engine module (QE) - g) Flash chip nodes - - VII - Specifying interrupt information for devices - 1) interrupts property - 2) interrupt-parent property - 3) OpenPIC Interrupt Controllers - 4) ISA Interrupt Controllers - - Appendix A - Sample SOC node for MPC8540 - - -Revision Information -==================== - May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet. May 19, 2005: Rev 0.2 - Add chapter III and bits & pieces here or @@ -1742,7 +1687,7 @@ platforms are moved over to use the flattened-device-tree model. }; }; - j) Flash chip nodes + g) Flash chip nodes Flash chips (Memory Technology Devices) are often used for solid state file systems on embedded devices. diff --git a/trunk/Documentation/s390/cds.txt b/trunk/Documentation/s390/cds.txt index 58919d6a593a..05a2b4f7e38f 100644 --- a/trunk/Documentation/s390/cds.txt +++ b/trunk/Documentation/s390/cds.txt @@ -51,8 +51,13 @@ The major changes are: * The interrupt handlers must be adapted to use a ccw_device as argument. Moreover, they don't return a devstat, but an irb. * Before initiating an io, the options must be set via ccw_device_set_options(). -* Instead of calling read_dev_chars()/read_conf_data(), the driver issues - the channel program and handles the interrupt itself. + +read_dev_chars() + read device characteristics + +read_conf_data() +read_conf_data_lpm() + read configuration data. ccw_device_get_ciw() get commands from extended sense data. @@ -125,6 +130,11 @@ present their hardware status by the same (shared) IRQ, the operating system has to call every single device driver registered on this IRQ in order to determine the device driver owning the device that raised the interrupt. +In order not to introduce a new I/O concept to the common Linux code, +Linux/390 preserves the IRQ concept and semantically maps the ESA/390 +subchannels to Linux as IRQs. This allows Linux/390 to support up to 64k +different IRQs, uniquely representing a single device each. + Up to kernel 2.4, Linux/390 used to provide interfaces via the IRQ (subchannel). For internal use of the common I/O layer, these are still there. However, device drivers should use the new calling interface via the ccw_device only. @@ -141,8 +151,9 @@ information during their initialization step to recognize the devices they support using the information saved in the struct ccw_device given to them. This methods implies that Linux/390 doesn't require to probe for free (not armed) interrupt request lines (IRQs) to drive its devices with. Where -applicable, the device drivers can use issue the READ DEVICE CHARACTERISTICS -ccw to retrieve device characteristics in its online routine. +applicable, the device drivers can use the read_dev_chars() to retrieve device +characteristics. This can be done without having to request device ownership +previously. In order to allow for easy I/O initiation the CDS layer provides a ccw_device_start() interface that takes a device specific channel program (one @@ -159,6 +170,69 @@ SUBCHANNEL (HSCH) command without having pending I/O requests. This function is also covered by ccw_device_halt(). +read_dev_chars() - Read Device Characteristics + +This routine returns the characteristics for the device specified. + +The function is meant to be called with the device already enabled; that is, +at earliest during set_online() processing. + +The ccw_device must not be locked prior to calling read_dev_chars(). + +The function may be called enabled or disabled. + +int read_dev_chars(struct ccw_device *cdev, void **buffer, int length ); + +cdev - the ccw_device the information is requested for. +buffer - pointer to a buffer pointer. The buffer pointer itself + must contain a valid buffer area. +length - length of the buffer provided. + +The read_dev_chars() function returns : + + 0 - successful completion +-ENODEV - cdev invalid +-EINVAL - an invalid parameter was detected, or the function was called early. +-EBUSY - an irrecoverable I/O error occurred or the device is not + operational. + + +read_conf_data(), read_conf_data_lpm() - Read Configuration Data + +Retrieve the device dependent configuration data. Please have a look at your +device dependent I/O commands for the device specific layout of the node +descriptor elements. read_conf_data_lpm() will retrieve the configuration data +for a specific path. + +The function is meant to be called with the device already enabled; that is, +at earliest during set_online() processing. + +The function may be called enabled or disabled, but the device must not be +locked + +int read_conf_data(struct ccw_device, void **buffer, int *length); +int read_conf_data_lpm(struct ccw_device, void **buffer, int *length, __u8 lpm); + +cdev - the ccw_device the data is requested for. +buffer - Pointer to a buffer pointer. The read_conf_data() routine + will allocate a buffer and initialize the buffer pointer + accordingly. It's the device driver's responsibility to + release the kernel memory if no longer needed. +length - Length of the buffer allocated and retrieved. +lpm - Logical path mask to be used for retrieving the data. If + zero the data is retrieved on the next path available. + +The read_conf_data() function returns : + 0 - Successful completion +-ENODEV - cdev invalid. +-EINVAL - An invalid parameter was detected, or the function was called early. +-EIO - An irrecoverable I/O error occurred or the device is + not operational. +-ENOMEM - The read_conf_data() routine couldn't obtain storage. +-EOPNOTSUPP - The device doesn't support the read configuration + data command. + + get_ciw() - get command information word This call enables a device driver to get information about supported commands diff --git a/trunk/Documentation/sched-design-CFS.txt b/trunk/Documentation/sched-design-CFS.txt deleted file mode 100644 index 16feebb7bdc0..000000000000 --- a/trunk/Documentation/sched-design-CFS.txt +++ /dev/null @@ -1,119 +0,0 @@ - -This is the CFS scheduler. - -80% of CFS's design can be summed up in a single sentence: CFS basically -models an "ideal, precise multi-tasking CPU" on real hardware. - -"Ideal multi-tasking CPU" is a (non-existent :-)) CPU that has 100% -physical power and which can run each task at precise equal speed, in -parallel, each at 1/nr_running speed. For example: if there are 2 tasks -running then it runs each at 50% physical power - totally in parallel. - -On real hardware, we can run only a single task at once, so while that -one task runs, the other tasks that are waiting for the CPU are at a -disadvantage - the current task gets an unfair amount of CPU time. In -CFS this fairness imbalance is expressed and tracked via the per-task -p->wait_runtime (nanosec-unit) value. "wait_runtime" is the amount of -time the task should now run on the CPU for it to become completely fair -and balanced. - -( small detail: on 'ideal' hardware, the p->wait_runtime value would - always be zero - no task would ever get 'out of balance' from the - 'ideal' share of CPU time. ) - -CFS's task picking logic is based on this p->wait_runtime value and it -is thus very simple: it always tries to run the task with the largest -p->wait_runtime value. In other words, CFS tries to run the task with -the 'gravest need' for more CPU time. So CFS always tries to split up -CPU time between runnable tasks as close to 'ideal multitasking -hardware' as possible. - -Most of the rest of CFS's design just falls out of this really simple -concept, with a few add-on embellishments like nice levels, -multiprocessing and various algorithm variants to recognize sleepers. - -In practice it works like this: the system runs a task a bit, and when -the task schedules (or a scheduler tick happens) the task's CPU usage is -'accounted for': the (small) time it just spent using the physical CPU -is deducted from p->wait_runtime. [minus the 'fair share' it would have -gotten anyway]. Once p->wait_runtime gets low enough so that another -task becomes the 'leftmost task' of the time-ordered rbtree it maintains -(plus a small amount of 'granularity' distance relative to the leftmost -task so that we do not over-schedule tasks and trash the cache) then the -new leftmost task is picked and the current task is preempted. - -The rq->fair_clock value tracks the 'CPU time a runnable task would have -fairly gotten, had it been runnable during that time'. So by using -rq->fair_clock values we can accurately timestamp and measure the -'expected CPU time' a task should have gotten. All runnable tasks are -sorted in the rbtree by the "rq->fair_clock - p->wait_runtime" key, and -CFS picks the 'leftmost' task and sticks to it. As the system progresses -forwards, newly woken tasks are put into the tree more and more to the -right - slowly but surely giving a chance for every task to become the -'leftmost task' and thus get on the CPU within a deterministic amount of -time. - -Some implementation details: - - - the introduction of Scheduling Classes: an extensible hierarchy of - scheduler modules. These modules encapsulate scheduling policy - details and are handled by the scheduler core without the core - code assuming about them too much. - - - sched_fair.c implements the 'CFS desktop scheduler': it is a - replacement for the vanilla scheduler's SCHED_OTHER interactivity - code. - - I'd like to give credit to Con Kolivas for the general approach here: - he has proven via RSDL/SD that 'fair scheduling' is possible and that - it results in better desktop scheduling. Kudos Con! - - The CFS patch uses a completely different approach and implementation - from RSDL/SD. My goal was to make CFS's interactivity quality exceed - that of RSDL/SD, which is a high standard to meet :-) Testing - feedback is welcome to decide this one way or another. [ and, in any - case, all of SD's logic could be added via a kernel/sched_sd.c module - as well, if Con is interested in such an approach. ] - - CFS's design is quite radical: it does not use runqueues, it uses a - time-ordered rbtree to build a 'timeline' of future task execution, - and thus has no 'array switch' artifacts (by which both the vanilla - scheduler and RSDL/SD are affected). - - CFS uses nanosecond granularity accounting and does not rely on any - jiffies or other HZ detail. Thus the CFS scheduler has no notion of - 'timeslices' and has no heuristics whatsoever. There is only one - central tunable: - - /proc/sys/kernel/sched_granularity_ns - - which can be used to tune the scheduler from 'desktop' (low - latencies) to 'server' (good batching) workloads. It defaults to a - setting suitable for desktop workloads. SCHED_BATCH is handled by the - CFS scheduler module too. - - Due to its design, the CFS scheduler is not prone to any of the - 'attacks' that exist today against the heuristics of the stock - scheduler: fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c all - work fine and do not impact interactivity and produce the expected - behavior. - - the CFS scheduler has a much stronger handling of nice levels and - SCHED_BATCH: both types of workloads should be isolated much more - agressively than under the vanilla scheduler. - - ( another detail: due to nanosec accounting and timeline sorting, - sched_yield() support is very simple under CFS, and in fact under - CFS sched_yield() behaves much better than under any other - scheduler i have tested so far. ) - - - sched_rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler - way than the vanilla scheduler does. It uses 100 runqueues (for all - 100 RT priority levels, instead of 140 in the vanilla scheduler) - and it needs no expired array. - - - reworked/sanitized SMP load-balancing: the runqueue-walking - assumptions are gone from the load-balancing code now, and - iterators of the scheduling modules are used. The balancing code got - quite a bit simpler as a result. - diff --git a/trunk/Documentation/sound/alsa/ALSA-Configuration.txt b/trunk/Documentation/sound/alsa/ALSA-Configuration.txt index 355ff0a2bb7c..57b878cc393c 100644 --- a/trunk/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/trunk/Documentation/sound/alsa/ALSA-Configuration.txt @@ -917,7 +917,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. ref Reference board, base config m2-2 Some Gateway MX series laptops m6 Some Gateway NX series laptops - pa6 Gateway NX860 series STAC9227/9228/9229/927x ref Reference board diff --git a/trunk/Documentation/spi/spi-summary b/trunk/Documentation/spi/spi-summary index 76ea6c837be5..795fbb48ffa7 100644 --- a/trunk/Documentation/spi/spi-summary +++ b/trunk/Documentation/spi/spi-summary @@ -1,30 +1,26 @@ Overview of Linux kernel SPI support ==================================== -21-May-2007 +02-Dec-2005 What is SPI? ------------ The "Serial Peripheral Interface" (SPI) is a synchronous four wire serial link used to connect microcontrollers to sensors, memory, and peripherals. -It's a simple "de facto" standard, not complicated enough to acquire a -standardization body. SPI uses a master/slave configuration. The three signal wires hold a clock (SCK, often on the order of 10 MHz), and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In, Slave Out" (MISO) signals. (Other names are also used.) There are four clocking modes through which data is exchanged; mode-0 and mode-3 are most commonly used. Each clock cycle shifts data out and data in; the clock -doesn't cycle except when there is a data bit to shift. Not all data bits -are used though; not every protocol uses those full duplex capabilities. +doesn't cycle except when there is data to shift. -SPI masters use a fourth "chip select" line to activate a given SPI slave +SPI masters may use a "chip select" line to activate a given SPI slave device, so those three signal wires may be connected to several chips -in parallel. All SPI slaves support chipselects; they are usually active -low signals, labeled nCSx for slave 'x' (e.g. nCS0). Some devices have +in parallel. All SPI slaves support chipselects. Some devices have other signals, often including an interrupt to the master. -Unlike serial busses like USB or SMBus, even low level protocols for +Unlike serial busses like USB or SMBUS, even low level protocols for SPI slave functions are usually not interoperable between vendors (except for commodities like SPI memory chips). @@ -37,11 +33,6 @@ SPI slave functions are usually not interoperable between vendors - Some devices may use eight bit words. Others may different word lengths, such as streams of 12-bit or 20-bit digital samples. - - Words are usually sent with their most significant bit (MSB) first, - but sometimes the least significant bit (LSB) goes first instead. - - - Sometimes SPI is used to daisy-chain devices, like shift registers. - In the same way, SPI slaves will only rarely support any kind of automatic discovery/enumeration protocol. The tree of slave devices accessible from a given SPI master will normally be set up manually, with configuration @@ -53,14 +44,6 @@ half-duplex SPI, for request/response protocols), SSP ("Synchronous Serial Protocol"), PSP ("Programmable Serial Protocol"), and other related protocols. -Some chips eliminate a signal line by combining MOSI and MISO, and -limiting themselves to half-duplex at the hardware level. In fact -some SPI chips have this signal mode as a strapping option. These -can be accessed using the same programming interface as SPI, but of -course they won't handle full duplex transfers. You may find such -chips described as using "three wire" signaling: SCK, data, nCSx. -(That data line is sometimes called MOMI or SISO.) - Microcontrollers often support both master and slave sides of the SPI protocol. This document (and Linux) currently only supports the master side of SPI interactions. @@ -91,32 +74,6 @@ interfaces with SPI modes. Given SPI support, they could use MMC or SD cards without needing a special purpose MMC/SD/SDIO controller. -I'm confused. What are these four SPI "clock modes"? ------------------------------------------------------ -It's easy to be confused here, and the vendor documentation you'll -find isn't necessarily helpful. The four modes combine two mode bits: - - - CPOL indicates the initial clock polarity. CPOL=0 means the - clock starts low, so the first (leading) edge is rising, and - the second (trailing) edge is falling. CPOL=1 means the clock - starts high, so the first (leading) edge is falling. - - - CPHA indicates the clock phase used to sample data; CPHA=0 says - sample on the leading edge, CPHA=1 means the trailing edge. - - Since the signal needs to stablize before it's sampled, CPHA=0 - implies that its data is written half a clock before the first - clock edge. The chipselect may have made it become available. - -Chip specs won't always say "uses SPI mode X" in as many words, -but their timing diagrams will make the CPOL and CPHA modes clear. - -In the SPI mode number, CPOL is the high order bit and CPHA is the -low order bit. So when a chip's timing diagram shows the clock -starting low (CPOL=0) and data stabilized for sampling during the -trailing clock edge (CPHA=1), that's SPI mode 1. - - How do these driver programming interfaces work? ------------------------------------------------ The header file includes kerneldoc, as does the diff --git a/trunk/Documentation/sysfs-rules.txt b/trunk/Documentation/sysfs-rules.txt deleted file mode 100644 index 42861bb0bc9b..000000000000 --- a/trunk/Documentation/sysfs-rules.txt +++ /dev/null @@ -1,166 +0,0 @@ -Rules on how to access information in the Linux kernel sysfs - -The kernel exported sysfs exports internal kernel implementation-details -and depends on internal kernel structures and layout. It is agreed upon -by the kernel developers that the Linux kernel does not provide a stable -internal API. As sysfs is a direct export of kernel internal -structures, the sysfs interface can not provide a stable interface eighter, -it may always change along with internal kernel changes. - -To minimize the risk of breaking users of sysfs, which are in most cases -low-level userspace applications, with a new kernel release, the users -of sysfs must follow some rules to use an as abstract-as-possible way to -access this filesystem. The current udev and HAL programs already -implement this and users are encouraged to plug, if possible, into the -abstractions these programs provide instead of accessing sysfs -directly. - -But if you really do want or need to access sysfs directly, please follow -the following rules and then your programs should work with future -versions of the sysfs interface. - -- Do not use libsysfs - It makes assumptions about sysfs which are not true. Its API does not - offer any abstraction, it exposes all the kernel driver-core - implementation details in its own API. Therefore it is not better than - reading directories and opening the files yourself. - Also, it is not actively maintained, in the sense of reflecting the - current kernel-development. The goal of providing a stable interface - to sysfs has failed, it causes more problems, than it solves. It - violates many of the rules in this document. - -- sysfs is always at /sys - Parsing /proc/mounts is a waste of time. Other mount points are a - system configuration bug you should not try to solve. For test cases, - possibly support a SYSFS_PATH environment variable to overwrite the - applications behavior, but never try to search for sysfs. Never try - to mount it, if you are not an early boot script. - -- devices are only "devices" - There is no such thing like class-, bus-, physical devices, - interfaces, and such that you can rely on in userspace. Everything is - just simply a "device". Class-, bus-, physical, ... types are just - kernel implementation details, which should not be expected by - applications that look for devices in sysfs. - - The properties of a device are: - o devpath (/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0) - - identical to the DEVPATH value in the event sent from the kernel - at device creation and removal - - the unique key to the device at that point in time - - the kernels path to the device-directory without the leading - /sys, and always starting with with a slash - - all elements of a devpath must be real directories. Symlinks - pointing to /sys/devices must always be resolved to their real - target, and the target path must be used to access the device. - That way the devpath to the device matches the devpath of the - kernel used at event time. - - using or exposing symlink values as elements in a devpath string - is a bug in the application - - o kernel name (sda, tty, 0000:00:1f.2, ...) - - a directory name, identical to the last element of the devpath - - applications need to handle spaces and characters like '!' in - the name - - o subsystem (block, tty, pci, ...) - - simple string, never a path or a link - - retrieved by reading the "subsystem"-link and using only the - last element of the target path - - o driver (tg3, ata_piix, uhci_hcd) - - a simple string, which may contain spaces, never a path or a - link - - it is retrieved by reading the "driver"-link and using only the - last element of the target path - - devices which do not have "driver"-link, just do not have a - driver; copying the driver value in a child device context, is a - bug in the application - - o attributes - - the files in the device directory or files below a subdirectories - of the same device directory - - accessing attributes reached by a symlink pointing to another device, - like the "device"-link, is a bug in the application - - Everything else is just a kernel driver-core implementation detail, - that should not be assumed to be stable across kernel releases. - -- Properties of parent devices never belong into a child device. - Always look at the parent devices themselves for determining device - context properties. If the device 'eth0' or 'sda' does not have a - "driver"-link, then this device does not have a driver. Its value is empty. - Never copy any property of the parent-device into a child-device. Parent - device-properties may change dynamically without any notice to the - child device. - -- Hierarchy in a single device-tree - There is only one valid place in sysfs where hierarchy can be examined - and this is below: /sys/devices. - It is planned, that all device directories will end up in the tree - below this directory. - -- Classification by subsystem - There are currently three places for classification of devices: - /sys/block, /sys/class and /sys/bus. It is planned that these will - not contain any device-directories themselves, but only flat lists of - symlinks pointing to the unified /sys/devices tree. - All three places have completely different rules on how to access - device information. It is planned to merge all three - classification-directories into one place at /sys/subsystem, - following the layout of the bus-directories. All buses and - classes, including the converted block-subsystem, will show up - there. - The devices belonging to a subsystem will create a symlink in the - "devices" directory at /sys/subsystem//devices. - - If /sys/subsystem exists, /sys/bus, /sys/class and /sys/block can be - ignored. If it does not exist, you have always to scan all three - places, as the kernel is free to move a subsystem from one place to - the other, as long as the devices are still reachable by the same - subsystem name. - - Assuming /sys/class/ and /sys/bus/, or - /sys/block and /sys/class/block are not interchangeable, is a bug in - the application. - -- Block - The converted block-subsystem at /sys/class/block, or - /sys/subsystem/block will contain the links for disks and partitions - at the same level, never in a hierarchy. Assuming the block-subsytem to - contain only disks and not partition-devices in the same flat list is - a bug in the application. - -- "device"-link and :-links - Never depend on the "device"-link. The "device"-link is a workaround - for the old layout, where class-devices are not created in - /sys/devices/ like the bus-devices. If the link-resolving of a - device-directory does not end in /sys/devices/, you can use the - "device"-link to find the parent devices in /sys/devices/. That is the - single valid use of the "device"-link, it must never appear in any - path as an element. Assuming the existence of the "device"-link for - a device in /sys/devices/ is a bug in the application. - Accessing /sys/class/net/eth0/device is a bug in the application. - - Never depend on the class-specific links back to the /sys/class - directory. These links are also a workaround for the design mistake - that class-devices are not created in /sys/devices. If a device - directory does not contain directories for child devices, these links - may be used to find the child devices in /sys/class. That is the single - valid use of these links, they must never appear in any path as an - element. Assuming the existence of these links for devices which are - real child device directories in the /sys/devices tree, is a bug in - the application. - - It is planned to remove all these links when when all class-device - directories live in /sys/devices. - -- Position of devices along device chain can change. - Never depend on a specific parent device position in the devpath, - or the chain of parent devices. The kernel is free to insert devices into - the chain. You must always request the parent device you are looking for - by its subsystem value. You need to walk up the chain until you find - the device that matches the expected subsystem. Depending on a specific - position of a parent device, or exposing relative paths, using "../" to - access the chain of parents, is a bug in the application. - diff --git a/trunk/Documentation/thinkpad-acpi.txt b/trunk/Documentation/thinkpad-acpi.txt index 9e6b94face4b..2d4803359a04 100644 --- a/trunk/Documentation/thinkpad-acpi.txt +++ b/trunk/Documentation/thinkpad-acpi.txt @@ -138,7 +138,7 @@ Hot keys -------- procfs: /proc/acpi/ibm/hotkey -sysfs device attribute: hotkey_* +sysfs device attribute: hotkey/* Without this driver, only the Fn-F4 key (sleep button) generates an ACPI event. With the driver loaded, the hotkey feature enabled and the @@ -196,7 +196,10 @@ The following commands can be written to the /proc/acpi/ibm/hotkey file: sysfs notes: - hotkey_bios_enabled: + The hot keys attributes are in a hotkey/ subdirectory off the + thinkpad device. + + bios_enabled: Returns the status of the hot keys feature when thinkpad-acpi was loaded. Upon module unload, the hot key feature status will be restored to this value. @@ -204,19 +207,19 @@ sysfs notes: 0: hot keys were disabled 1: hot keys were enabled - hotkey_bios_mask: + bios_mask: Returns the hot keys mask when thinkpad-acpi was loaded. Upon module unload, the hot keys mask will be restored to this value. - hotkey_enable: + enable: Enables/disables the hot keys feature, and reports current status of the hot keys feature. 0: disables the hot keys feature / feature disabled 1: enables the hot keys feature / feature enabled - hotkey_mask: + mask: bit mask to enable ACPI event generation for each hot key (see above). Returns the current status of the hot keys mask, and allows one to modify it. @@ -226,7 +229,7 @@ Bluetooth --------- procfs: /proc/acpi/ibm/bluetooth -sysfs device attribute: bluetooth_enable +sysfs device attribute: bluetooth/enable This feature shows the presence and current state of a ThinkPad Bluetooth device in the internal ThinkPad CDC slot. @@ -241,7 +244,7 @@ If Bluetooth is installed, the following commands can be used: Sysfs notes: If the Bluetooth CDC card is installed, it can be enabled / - disabled through the "bluetooth_enable" thinkpad-acpi device + disabled through the "bluetooth/enable" thinkpad-acpi device attribute, and its current status can also be queried. enable: @@ -249,7 +252,7 @@ Sysfs notes: 1: enables Bluetooth / Bluetooth is enabled. Note: this interface will be probably be superseeded by the - generic rfkill class, so it is NOT to be considered stable yet. + generic rfkill class. Video output control -- /proc/acpi/ibm/video -------------------------------------------- @@ -895,7 +898,7 @@ EXPERIMENTAL: WAN ----------------- procfs: /proc/acpi/ibm/wan -sysfs device attribute: wwan_enable +sysfs device attribute: wwan/enable This feature is marked EXPERIMENTAL because the implementation directly accesses hardware registers and may not work as expected. USE @@ -918,7 +921,7 @@ If the W-WAN card is installed, the following commands can be used: Sysfs notes: If the W-WAN card is installed, it can be enabled / - disabled through the "wwan_enable" thinkpad-acpi device + disabled through the "wwan/enable" thinkpad-acpi device attribute, and its current status can also be queried. enable: @@ -926,7 +929,7 @@ Sysfs notes: 1: enables WWAN card / WWAN card is enabled. Note: this interface will be probably be superseeded by the - generic rfkill class, so it is NOT to be considered stable yet. + generic rfkill class. Multiple Commands, Module Parameters ------------------------------------ diff --git a/trunk/Documentation/vm/slabinfo.c b/trunk/Documentation/vm/slabinfo.c index d4f21ffd1404..686a8e04a4f3 100644 --- a/trunk/Documentation/vm/slabinfo.c +++ b/trunk/Documentation/vm/slabinfo.c @@ -242,9 +242,6 @@ void decode_numa_list(int *numa, char *t) memset(numa, 0, MAX_NODES * sizeof(int)); - if (!t) - return; - while (*t == 'N') { t++; node = strtoul(t, &t, 10); @@ -262,17 +259,11 @@ void decode_numa_list(int *numa, char *t) void slab_validate(struct slabinfo *s) { - if (strcmp(s->name, "*") == 0) - return; - set_obj(s, "validate", 1); } void slab_shrink(struct slabinfo *s) { - if (strcmp(s->name, "*") == 0) - return; - set_obj(s, "shrink", 1); } @@ -395,9 +386,7 @@ void report(struct slabinfo *s) { if (strcmp(s->name, "*") == 0) return; - - printf("\nSlabcache: %-20s Aliases: %2d Order : %2d Objects: %d\n", - s->name, s->aliases, s->order, s->objects); + printf("\nSlabcache: %-20s Aliases: %2d Order : %2d\n", s->name, s->aliases, s->order); if (s->hwcache_align) printf("** Hardware cacheline aligned\n"); if (s->cache_dma) @@ -556,9 +545,6 @@ int slab_empty(struct slabinfo *s) void slab_debug(struct slabinfo *s) { - if (strcmp(s->name, "*") == 0) - return; - if (sanity && !s->sanity_checks) { set_obj(s, "sanity", 1); } @@ -805,11 +791,11 @@ void totals(void) store_size(b1, total_size);store_size(b2, total_waste); store_size(b3, total_waste * 100 / total_used); - printf("Memory used: %6s # Loss : %6s MRatio:%6s%%\n", b1, b2, b3); + printf("Memory used: %6s # Loss : %6s MRatio: %6s%%\n", b1, b2, b3); store_size(b1, total_objects);store_size(b2, total_partobj); store_size(b3, total_partobj * 100 / total_objects); - printf("# Objects : %6s # PartObj: %6s ORatio:%6s%%\n", b1, b2, b3); + printf("# Objects : %6s # PartObj: %6s ORatio: %6s%%\n", b1, b2, b3); printf("\n"); printf("Per Cache Average Min Max Total\n"); @@ -832,7 +818,7 @@ void totals(void) store_size(b1, avg_ppart);store_size(b2, min_ppart); store_size(b3, max_ppart); store_size(b4, total_partial * 100 / total_slabs); - printf("%%PartSlab%10s%% %10s%% %10s%% %10s%%\n", + printf("%%PartSlab %10s%% %10s%% %10s%% %10s%%\n", b1, b2, b3, b4); store_size(b1, avg_partobj);store_size(b2, min_partobj); @@ -844,7 +830,7 @@ void totals(void) store_size(b1, avg_ppartobj);store_size(b2, min_ppartobj); store_size(b3, max_ppartobj); store_size(b4, total_partobj * 100 / total_objects); - printf("%% PartObj%10s%% %10s%% %10s%% %10s%%\n", + printf("%% PartObj %10s%% %10s%% %10s%% %10s%%\n", b1, b2, b3, b4); store_size(b1, avg_size);store_size(b2, min_size); @@ -1114,8 +1100,6 @@ void output_slabs(void) ops(slab); else if (show_slab) slabcache(slab); - else if (show_report) - report(slab); } } diff --git a/trunk/Documentation/vm/slub.txt b/trunk/Documentation/vm/slub.txt index 1523320abd87..727c8d81aeaf 100644 --- a/trunk/Documentation/vm/slub.txt +++ b/trunk/Documentation/vm/slub.txt @@ -1,9 +1,13 @@ Short users guide for SLUB -------------------------- +First of all slub should transparently replace SLAB. If you enable +SLUB then everything should work the same (Note the word "should". +There is likely not much value in that word at this point). + The basic philosophy of SLUB is very different from SLAB. SLAB requires rebuilding the kernel to activate debug options for all -slab caches. SLUB always includes full debugging but it is off by default. +SLABS. SLUB always includes full debugging but its off by default. SLUB can enable debugging only for selected slabs in order to avoid an impact on overall system performance which may make a bug more difficult to find. @@ -72,28 +76,13 @@ of objects. Careful with tracing: It may spew out lots of information and never stop if used on the wrong slab. -Slab merging +SLAB Merging ------------ -If no debug options are specified then SLUB may merge similar slabs together +If no debugging is specified then SLUB may merge similar slabs together in order to reduce overhead and increase cache hotness of objects. slabinfo -a displays which slabs were merged together. -Slab validation ---------------- - -SLUB can validate all object if the kernel was booted with slub_debug. In -order to do so you must have the slabinfo tool. Then you can do - -slabinfo -v - -which will test all objects. Output will be generated to the syslog. - -This also works in a more limited way if boot was without slab debug. -In that case slabinfo -v simply tests all reachable objects. Usually -these are in the cpu slabs and the partial slabs. Full slabs are not -tracked by SLUB in a non debug situation. - Getting more performance ------------------------ @@ -102,9 +91,9 @@ list_lock once in a while to deal with partial slabs. That overhead is governed by the order of the allocation for each slab. The allocations can be influenced by kernel parameters: -slub_min_objects=x (default 4) +slub_min_objects=x (default 8) slub_min_order=x (default 0) -slub_max_order=x (default 1) +slub_max_order=x (default 4) slub_min_objects allows to specify how many objects must at least fit into one slab in order for the allocation order to be acceptable. @@ -120,107 +109,5 @@ longer be checked. This is useful to avoid SLUB trying to generate super large order pages to fit slub_min_objects of a slab cache with large object sizes into one high order page. -SLUB Debug output ------------------ - -Here is a sample of slub debug output: - -*** SLUB kmalloc-8: Redzone Active@0xc90f6d20 slab 0xc528c530 offset=3360 flags=0x400000c3 inuse=61 freelist=0xc90f6d58 - Bytes b4 0xc90f6d10: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ - Object 0xc90f6d20: 31 30 31 39 2e 30 30 35 1019.005 - Redzone 0xc90f6d28: 00 cc cc cc . -FreePointer 0xc90f6d2c -> 0xc90f6d58 -Last alloc: get_modalias+0x61/0xf5 jiffies_ago=53 cpu=1 pid=554 -Filler 0xc90f6d50: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ - [] dump_trace+0x63/0x1eb - [] show_trace_log_lvl+0x1a/0x2f - [] show_trace+0x12/0x14 - [] dump_stack+0x16/0x18 - [] object_err+0x143/0x14b - [] check_object+0x66/0x234 - [] __slab_free+0x239/0x384 - [] kfree+0xa6/0xc6 - [] get_modalias+0xb9/0xf5 - [] dmi_dev_uevent+0x27/0x3c - [] dev_uevent+0x1ad/0x1da - [] kobject_uevent_env+0x20a/0x45b - [] kobject_uevent+0xa/0xf - [] store_uevent+0x4f/0x58 - [] dev_attr_store+0x29/0x2f - [] sysfs_write_file+0x16e/0x19c - [] vfs_write+0xd1/0x15a - [] sys_write+0x3d/0x72 - [] sysenter_past_esp+0x5f/0x99 - [] 0xb7f7b410 - ======================= -@@@ SLUB kmalloc-8: Restoring redzone (0xcc) from 0xc90f6d28-0xc90f6d2b - - - -If SLUB encounters a corrupted object then it will perform the following -actions: - -1. Isolation and report of the issue - -This will be a message in the system log starting with - -*** SLUB : @ -offset= flags= -inuse= freelist= - -2. Report on how the problem was dealt with in order to ensure the continued -operation of the system. - -These are messages in the system log beginning with - -@@@ SLUB : - - -In the above sample SLUB found that the Redzone of an active object has -been overwritten. Here a string of 8 characters was written into a slab that -has the length of 8 characters. However, a 8 character string needs a -terminating 0. That zero has overwritten the first byte of the Redzone field. -After reporting the details of the issue encountered the @@@ SLUB message -tell us that SLUB has restored the redzone to its proper value and then -system operations continue. - -Various types of lines can follow the @@@ SLUB line: - -Bytes b4
: - Show a few bytes before the object where the problem was detected. - Can be useful if the corruption does not stop with the start of the - object. - -Object
: - The bytes of the object. If the object is inactive then the bytes - typically contain poisoning values. Any non-poison value shows a - corruption by a write after free. - -Redzone
: - The redzone following the object. The redzone is used to detect - writes after the object. All bytes should always have the same - value. If there is any deviation then it is due to a write after - the object boundary. - -Freepointer - The pointer to the next free object in the slab. May become - corrupted if overwriting continues after the red zone. - -Last alloc: -Last free: - Shows the address from which the object was allocated/freed last. - We note the pid, the time and the CPU that did so. This is usually - the most useful information to figure out where things went wrong. - Here get_modalias() did an kmalloc(8) instead of a kmalloc(9). - -Filler
: - Unused data to fill up the space in order to get the next object - properly aligned. In the debug case we make sure that there are - at least 4 bytes of filler. This allow for the detection of writes - before the object. - -Following the filler will be a stackdump. That stackdump describes the -location where the error was detected. The cause of the corruption is more -likely to be found by looking at the information about the last alloc / free. - -Christoph Lameter, , May 23, 2007 + +Christoph Lameter, , April 10, 2007 diff --git a/trunk/Documentation/volatile-considered-harmful.txt b/trunk/Documentation/volatile-considered-harmful.txt deleted file mode 100644 index 10c2e411cca8..000000000000 --- a/trunk/Documentation/volatile-considered-harmful.txt +++ /dev/null @@ -1,119 +0,0 @@ -Why the "volatile" type class should not be used ------------------------------------------------- - -C programmers have often taken volatile to mean that the variable could be -changed outside of the current thread of execution; as a result, they are -sometimes tempted to use it in kernel code when shared data structures are -being used. In other words, they have been known to treat volatile types -as a sort of easy atomic variable, which they are not. The use of volatile in -kernel code is almost never correct; this document describes why. - -The key point to understand with regard to volatile is that its purpose is -to suppress optimization, which is almost never what one really wants to -do. In the kernel, one must protect shared data structures against -unwanted concurrent access, which is very much a different task. The -process of protecting against unwanted concurrency will also avoid almost -all optimization-related problems in a more efficient way. - -Like volatile, the kernel primitives which make concurrent access to data -safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent -unwanted optimization. If they are being used properly, there will be no -need to use volatile as well. If volatile is still necessary, there is -almost certainly a bug in the code somewhere. In properly-written kernel -code, volatile can only serve to slow things down. - -Consider a typical block of kernel code: - - spin_lock(&the_lock); - do_something_on(&shared_data); - do_something_else_with(&shared_data); - spin_unlock(&the_lock); - -If all the code follows the locking rules, the value of shared_data cannot -change unexpectedly while the_lock is held. Any other code which might -want to play with that data will be waiting on the lock. The spinlock -primitives act as memory barriers - they are explicitly written to do so - -meaning that data accesses will not be optimized across them. So the -compiler might think it knows what will be in shared_data, but the -spin_lock() call, since it acts as a memory barrier, will force it to -forget anything it knows. There will be no optimization problems with -accesses to that data. - -If shared_data were declared volatile, the locking would still be -necessary. But the compiler would also be prevented from optimizing access -to shared_data _within_ the critical section, when we know that nobody else -can be working with it. While the lock is held, shared_data is not -volatile. When dealing with shared data, proper locking makes volatile -unnecessary - and potentially harmful. - -The volatile storage class was originally meant for memory-mapped I/O -registers. Within the kernel, register accesses, too, should be protected -by locks, but one also does not want the compiler "optimizing" register -accesses within a critical section. But, within the kernel, I/O memory -accesses are always done through accessor functions; accessing I/O memory -directly through pointers is frowned upon and does not work on all -architectures. Those accessors are written to prevent unwanted -optimization, so, once again, volatile is unnecessary. - -Another situation where one might be tempted to use volatile is -when the processor is busy-waiting on the value of a variable. The right -way to perform a busy wait is: - - while (my_variable != what_i_want) - cpu_relax(); - -The cpu_relax() call can lower CPU power consumption or yield to a -hyperthreaded twin processor; it also happens to serve as a memory barrier, -so, once again, volatile is unnecessary. Of course, busy-waiting is -generally an anti-social act to begin with. - -There are still a few rare situations where volatile makes sense in the -kernel: - - - The above-mentioned accessor functions might use volatile on - architectures where direct I/O memory access does work. Essentially, - each accessor call becomes a little critical section on its own and - ensures that the access happens as expected by the programmer. - - - Inline assembly code which changes memory, but which has no other - visible side effects, risks being deleted by GCC. Adding the volatile - keyword to asm statements will prevent this removal. - - - The jiffies variable is special in that it can have a different value - every time it is referenced, but it can be read without any special - locking. So jiffies can be volatile, but the addition of other - variables of this type is strongly frowned upon. Jiffies is considered - to be a "stupid legacy" issue (Linus's words) in this regard; fixing it - would be more trouble than it is worth. - - - Pointers to data structures in coherent memory which might be modified - by I/O devices can, sometimes, legitimately be volatile. A ring buffer - used by a network adapter, where that adapter changes pointers to - indicate which descriptors have been processed, is an example of this - type of situation. - -For most code, none of the above justifications for volatile apply. As a -result, the use of volatile is likely to be seen as a bug and will bring -additional scrutiny to the code. Developers who are tempted to use -volatile should take a step back and think about what they are truly trying -to accomplish. - -Patches to remove volatile variables are generally welcome - as long as -they come with a justification which shows that the concurrency issues have -been properly thought through. - - -NOTES ------ - -[1] http://lwn.net/Articles/233481/ -[2] http://lwn.net/Articles/233482/ - -CREDITS -------- - -Original impetus and research by Randy Dunlap -Written by Jonathan Corbet -Improvements via coments from Satyam Sharma, Johannes Stezenbach, Jesper - Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan - Richter. diff --git a/trunk/Documentation/watchdog/pcwd-watchdog.txt b/trunk/Documentation/watchdog/pcwd-watchdog.txt index 4f68052395c0..d9ee6336c1d4 100644 --- a/trunk/Documentation/watchdog/pcwd-watchdog.txt +++ b/trunk/Documentation/watchdog/pcwd-watchdog.txt @@ -1,5 +1,3 @@ -Last reviewed: 10/05/2007 - Berkshire Products PC Watchdog Card Support for ISA Cards Revision A and C Documentation and Driver by Ken Hollis @@ -16,8 +14,8 @@ Last reviewed: 10/05/2007 The Watchdog Driver will automatically find your watchdog card, and will attach a running driver for use with that card. After the watchdog - drivers have initialized, you can then talk to the card using a PC - Watchdog program. + drivers have initialized, you can then talk to the card using the PC + Watchdog program, available from http://ftp.bitgate.com/pcwd/. I suggest putting a "watchdog -d" before the beginning of an fsck, and a "watchdog -e -t 1" immediately after the end of an fsck. (Remember @@ -64,3 +62,5 @@ Last reviewed: 10/05/2007 -- Ken Hollis (kenji@bitgate.com) +(This documentation may be out of date. Check + http://ftp.bitgate.com/pcwd/ for the absolute latest additions.) diff --git a/trunk/Documentation/watchdog/watchdog-api.txt b/trunk/Documentation/watchdog/watchdog-api.txt index bb7cb1d31ec7..8d16f6f3c4ec 100644 --- a/trunk/Documentation/watchdog/watchdog-api.txt +++ b/trunk/Documentation/watchdog/watchdog-api.txt @@ -1,6 +1,3 @@ -Last reviewed: 10/05/2007 - - The Linux Watchdog driver API. Copyright 2002 Christer Weingel @@ -25,7 +22,7 @@ the system. If userspace fails (RAM error, kernel bug, whatever), the notifications cease to occur, and the hardware watchdog will reset the system (causing a reboot) after the timeout occurs. -The Linux watchdog API is a rather ad-hoc construction and different +The Linux watchdog API is a rather AD hoc construction and different drivers implement different, and sometimes incompatible, parts of it. This file is an attempt to document the existing usage and allow future driver writers to use it as a reference. @@ -49,16 +46,14 @@ some of the drivers support the configuration option "Disable watchdog shutdown on close", CONFIG_WATCHDOG_NOWAYOUT. If it is set to Y when compiling the kernel, there is no way of disabling the watchdog once it has been started. So, if the watchdog daemon crashes, the system -will reboot after the timeout has passed. Watchdog devices also usually -support the nowayout module parameter so that this option can be controlled -at runtime. +will reboot after the timeout has passed. -Drivers will not disable the watchdog, unless a specific magic character 'V' -has been sent /dev/watchdog just before closing the file. If the userspace -daemon closes the file without sending this special character, the driver -will assume that the daemon (and userspace in general) died, and will stop -pinging the watchdog without disabling it first. This will then cause a -reboot if the watchdog is not re-opened in sufficient time. +Some other drivers will not disable the watchdog, unless a specific +magic character 'V' has been sent /dev/watchdog just before closing +the file. If the userspace daemon closes the file without sending +this special character, the driver will assume that the daemon (and +userspace in general) died, and will stop pinging the watchdog without +disabling it first. This will then cause a reboot. The ioctl API: @@ -232,3 +227,218 @@ The following options are available: [FIXME -- better explanations] +Implementations in the current drivers in the kernel tree: + +Here I have tried to summarize what the different drivers support and +where they do strange things compared to the other drivers. + +acquirewdt.c -- Acquire Single Board Computer + + This driver has a hardcoded timeout of 1 minute + + Supports CONFIG_WATCHDOG_NOWAYOUT + + GETSUPPORT returns KEEPALIVEPING. GETSTATUS will return 1 if + the device is open, 0 if not. [FIXME -- isn't this rather + silly? To be able to use the ioctl, the device must be open + and so GETSTATUS will always return 1]. + +advantechwdt.c -- Advantech Single Board Computer + + Timeout that defaults to 60 seconds, supports SETTIMEOUT. + + Supports CONFIG_WATCHDOG_NOWAYOUT + + GETSUPPORT returns WDIOF_KEEPALIVEPING and WDIOF_SETTIMEOUT. + The GETSTATUS call returns if the device is open or not. + [FIXME -- silliness again?] + +booke_wdt.c -- PowerPC BookE Watchdog Timer + + Timeout default varies according to frequency, supports + SETTIMEOUT + + Watchdog cannot be turned off, CONFIG_WATCHDOG_NOWAYOUT + does not make sense + + GETSUPPORT returns the watchdog_info struct, and + GETSTATUS returns the supported options. GETBOOTSTATUS + returns a 1 if the last reset was caused by the + watchdog and a 0 otherwise. This watchdog cannot be + disabled once it has been started. The wdt_period kernel + parameter selects which bit of the time base changing + from 0->1 will trigger the watchdog exception. Changing + the timeout from the ioctl calls will change the + wdt_period as defined above. Finally if you would like to + replace the default Watchdog Handler you can implement the + WatchdogHandler() function in your own code. + +eurotechwdt.c -- Eurotech CPU-1220/1410 + + The timeout can be set using the SETTIMEOUT ioctl and defaults + to 60 seconds. + + Also has a module parameter "ev", event type which controls + what should happen on a timeout, the string "int" or anything + else that causes a reboot. [FIXME -- better description] + + Supports CONFIG_WATCHDOG_NOWAYOUT + + GETSUPPORT returns CARDRESET and WDIOF_SETTIMEOUT but + GETSTATUS is not supported and GETBOOTSTATUS just returns 0. + +i810-tco.c -- Intel 810 chipset + + Also has support for a lot of other i8x0 stuff, but the + watchdog is one of the things. + + The timeout is set using the module parameter "i810_margin", + which is in steps of 0.6 seconds where 2 + + Custom Linux Driver And Program Development + + +The following watchdog drivers are currently implemented: + + ICS WDT501-P + ICS WDT501-P (no fan tachometer) + ICS WDT500-P + Software Only + SA1100 Internal Watchdog + Berkshire Products PC Watchdog Revision A & C (by Ken Hollis) + + +All six interfaces provide /dev/watchdog, which when open must be written +to within a timeout or the machine will reboot. Each write delays the reboot +time another timeout. In the case of the software watchdog the ability to +reboot will depend on the state of the machines and interrupts. The hardware +boards physically pull the machine down off their own onboard timers and +will reboot from almost anything. + +A second temperature monitoring interface is available on the WDT501P cards +and some Berkshire cards. This provides /dev/temperature. This is the machine +internal temperature in degrees Fahrenheit. Each read returns a single byte +giving the temperature. + +The third interface logs kernel messages on additional alert events. + +Both software and hardware watchdog drivers are available in the standard +kernel. If you are using the software watchdog, you probably also want +to use "panic=60" as a boot argument as well. + +The wdt card cannot be safely probed for. Instead you need to pass +wdt=ioaddr,irq as a boot parameter - eg "wdt=0x240,11". + +The SA1100 watchdog module can be configured with the "sa1100_margin" +commandline argument which specifies timeout value in seconds. + +The i810 TCO watchdog modules can be configured with the "i810_margin" +commandline argument which specifies the counter initial value. The counter +is decremented every 0.6 seconds and default to 50 (30 seconds). Values can +range between 3 and 63. + +The i810 TCO watchdog driver also implements the WDIOC_GETSTATUS and +WDIOC_GETBOOTSTATUS ioctl()s. WDIOC_GETSTATUS returns the actual counter value +and WDIOC_GETBOOTSTATUS returns the value of TCO2 Status Register (see Intel's +documentation for the 82801AA and 82801AB datasheet). + +Features +-------- + WDT501P WDT500P Software Berkshire i810 TCO SA1100WD +Reboot Timer X X X X X X +External Reboot X X o o o X +I/O Port Monitor o o o X o o +Temperature X o o X o o +Fan Speed X o o o o o +Power Under X o o o o o +Power Over X o o o o o +Overheat X o o o o o + +The external event interfaces on the WDT boards are not currently supported. +Minor numbers are however allocated for it. + + +Example Watchdog Driver: see Documentation/watchdog/src/watchdog-simple.c + + +Contact Information + +People keep asking about the WDT watchdog timer hardware: The phone contacts +for Industrial Computer Source are: + +Industrial Computer Source +http://www.indcompsrc.com +ICS Advent, San Diego +6260 Sequence Dr. +San Diego, CA 92121-4371 +Phone (858) 677-0877 +FAX: (858) 677-0895 +> +ICS Advent Europe, UK +Oving Road +Chichester, +West Sussex, +PO19 4ET, UK +Phone: 00.44.1243.533900 + + +and please mention Linux when enquiring. + +For full information about the PCWD cards see the pcwd-watchdog.txt document. diff --git a/trunk/Documentation/watchdog/wdt.txt b/trunk/Documentation/watchdog/wdt.txt deleted file mode 100644 index 03fd756d976d..000000000000 --- a/trunk/Documentation/watchdog/wdt.txt +++ /dev/null @@ -1,43 +0,0 @@ -Last Reviewed: 10/05/2007 - - WDT Watchdog Timer Interfaces For The Linux Operating System - Alan Cox - - ICS WDT501-P - ICS WDT501-P (no fan tachometer) - ICS WDT500-P - -All the interfaces provide /dev/watchdog, which when open must be written -to within a timeout or the machine will reboot. Each write delays the reboot -time another timeout. In the case of the software watchdog the ability to -reboot will depend on the state of the machines and interrupts. The hardware -boards physically pull the machine down off their own onboard timers and -will reboot from almost anything. - -A second temperature monitoring interface is available on the WDT501P cards -This provides /dev/temperature. This is the machine internal temperature in -degrees Fahrenheit. Each read returns a single byte giving the temperature. - -The third interface logs kernel messages on additional alert events. - -The wdt card cannot be safely probed for. Instead you need to pass -wdt=ioaddr,irq as a boot parameter - eg "wdt=0x240,11". - -Features --------- - WDT501P WDT500P -Reboot Timer X X -External Reboot X X -I/O Port Monitor o o -Temperature X o -Fan Speed X o -Power Under X o -Power Over X o -Overheat X o - -The external event interfaces on the WDT boards are not currently supported. -Minor numbers are however allocated for it. - - -Example Watchdog Driver: see Documentation/watchdog/src/watchdog-simple.c - diff --git a/trunk/MAINTAINERS b/trunk/MAINTAINERS index 228a45b8dc62..68a56add73e3 100644 --- a/trunk/MAINTAINERS +++ b/trunk/MAINTAINERS @@ -30,11 +30,8 @@ trivial patch so apply some common sense. job the maintainers (and especially Linus) do is to keep things looking the same. Sometimes this means that the clever hack in your driver to get around a problem actually needs to become a - generalized kernel feature ready for next time. - - PLEASE check your patch with the automated style checker - (scripts/checkpatch.pl) to catch trival style violations. - See Documentation/CodingStyle for guidance here. + generalized kernel feature ready for next time. See + Documentation/CodingStyle for guidance here. PLEASE try to include any credit lines you want added with the patch. It avoids people being missed off by mistake and makes @@ -315,9 +312,10 @@ M: zippel@linux-m68k.org S: Maintained AGPGART DRIVER -P: David Airlie -M: airlied@linux.ie -T: git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git +P: Dave Jones +M: davej@codemonkey.org.uk +W: http://www.codemonkey.org.uk/projects/agp/ +T: git kernel.org:/pub/scm/linux/kernel/git/davej/agpgart.git S: Maintained AHA152X SCSI DRIVER @@ -334,9 +332,6 @@ L: linux-usb-devel@lists.sourceforge.net W: http://www.linux-usb.org/SpeedTouch/ S: Maintained -ALCHEMY AU1XX0 MMC DRIVER -S: Orphan - ALI1563 I2C DRIVER P: Rudolf Marek M: r.marek@assembler.cz @@ -423,12 +418,6 @@ P: Ian Molton M: spyro@f2s.com S: Maintained -ARM PRIMECELL MMCI PL180/1 DRIVER -P: Russell King -M: rmk@arm.linux.org.uk -L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only) -S: Maintained - ARM/ADI ROADRUNNER MACHINE SUPPORT P: Lennert Buytenhek M: kernel@wantstofly.org @@ -660,9 +649,6 @@ L: linux-atm-general@lists.sourceforge.net (subscribers-only) W: http://linux-atm.sourceforge.net S: Maintained -ATMEL AT91 MCI DRIVER -S: Orphan - ATMEL MACB ETHERNET DRIVER P: Haavard Skinnemoen M: hskinnemoen@atmel.com @@ -722,52 +708,42 @@ M: rpurdie@rpsys.net S: Maintained BLACKFIN ARCHITECTURE -P: Aubrey Li -M: aubrey.li@analog.com -P: Bernd Schmidt -M: bernd.schmidt@analog.com -P: Bryan Wu -M: bryan.wu@analog.com -P: Grace Pan -M: grace.pan@analog.com -P: Marc Hoffman -M: marc.hoffman@analog.com -P: Michael Hennerich -M: michael.hennerich@analog.com -P: Mike Frysinger -M: michael.frysinger@analog.com -P: Jerry Zeng -M: jerry.zeng@analog.com -P: Jie Zhang -M: jie.zhang@analog.com -P: Robin Getz -M: robin.getz@analog.com -P: Roy Huang -M: roy.huang@analog.com -P: Sonic Zhang -M: sonic.zhang@analog.com -P: Vivi Li -M: vivi.li@analog.com -P: Yi Li -M: yi.li@analog.com -L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only) -W: http://blackfin.uclinux.org -S: Supported - -BLACKFIN RTC DRIVER -P: Mike Frysinger -M: michael.frysinger@analog.com -M: vapier.adi@gmail.com -L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only) -W: http://blackfin.uclinux.org -S: Supported +P: Aubrey Li +M: aubrey.li@analog.com +P: Bernd Schmidt +M: bernd.schmidt@analog.com +P: Bryan Wu +M: bryan.wu@analog.com +P: Grace Pan +M: grace.pan@analog.com +P: Michael Hennerich +M: michael.hennerich@analog.com +P: Mike Frysinger +M: michael.frysinger@analog.com +P: Jane Lv +M: jane.lv@analog.com +P: Jerry Zeng +M: jerry.zeng@analog.com +P: Jie Zhang +M: jie.zhang@analog.com +P: Robin Getz +M: robin.getz@analog.com +P: Roy Huang +M: roy.huang@analog.com +P: Sonic Zhang +M: sonic.zhang@analog.com +P: Yi Li +M: yi.li@analog.com +L: uclinux-dist-devel@blackfin.uclinux.org +W: http://blackfin.uclinux.org +S: Supported BLACKFIN SERIAL DRIVER -P: Aubrey Li -M: aubrey.li@analog.com -L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only) -W: http://blackfin.uclinux.org -S: Supported +P: Aubrey Li +M: aubrey.li@analog.com +L: uclinux-dist-devel@blackfin.uclinux.org +W: http://blackfin.uclinux.org +S: Supported BAYCOM/HDLCDRV DRIVERS FOR AX.25 P: Thomas Sailer @@ -791,6 +767,11 @@ M: rathamahata@php4.ru L: linux-kernel@vger.kernel.org S: Maintained +BERKSHIRE PRODUCTS PC WATCHDOG DRIVER +P: Kenji Hollis +W: http://ftp.bitgate.com/pcwd/ +S: Maintained + BFS FILE SYSTEM P: Tigran A. Aivazian M: tigran@aivazian.fsnet.co.uk @@ -979,15 +960,6 @@ M: johannes@sipsolutions.net L: linux-wireless@vger.kernel.org S: Maintained -CHECKPATCH -P: Andy Whitcroft -M: apw@shadowen.org -P: Randy Dunlap -M: rdunlap@xenotime.net -P: Joel Schopp -M: jschopp@austin.ibm.com -S: Supported - COMMON INTERNET FILE SYSTEM (CIFS) P: Steve French M: sfrench@samba.org @@ -1491,13 +1463,6 @@ L: linux-usb-devel@lists.sourceforge.net L: linuxppc-embedded@ozlabs.org S: Maintained -FREESCALE QUICC ENGINE UCC ETHERNET DRIVER -P: Li Yang -M: leoli@freescale.com -L: netdev@vger.kernel.org -L: linuxppc-embedded@ozlabs.org -S: Maintained - FILE LOCKING (flock() and fcntl()/lockf()) P: Matthew Wilcox M: matthew@wil.cx @@ -1509,14 +1474,6 @@ P: Alexander Viro M: viro@zeniv.linux.org.uk S: Maintained -FIREWIRE SUBSYSTEM -P: Kristian Hoegsberg, Stefan Richter -M: krh@redhat.com, stefanr@s5r6.in-berlin.de -L: linux1394-devel@lists.sourceforge.net -W: http://www.linux1394.org/ -T: git kernel.org:/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git -S: Maintained - FIRMWARE LOADER (request_firmware) L: linux-kernel@vger.kernel.org S: Orphan @@ -1749,12 +1706,14 @@ T: http://www.harbaum.org/till/i2c_tiny_usb S: Maintained i386 BOOT CODE -P: H. Peter Anvin -M: hpa@zytor.com +P: Riley H. Williams +M: Riley@Williams.Name L: Linux-Kernel@vger.kernel.org S: Maintained i386 SETUP CODE / CPU ERRATA WORKAROUNDS +P: Dave Jones +M: davej@codemonkey.org.uk P: H. Peter Anvin M: hpa@zytor.com S: Maintained @@ -1855,7 +1814,7 @@ W: http://www.openib.org/ T: git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git S: Supported -INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN) DRIVERS +INPUT (KEYBOARD, MOUSE, JOYSTICK) DRIVERS P: Dmitry Torokhov M: dmitry.torokhov@gmail.com M: dtor@mail.ru @@ -2100,7 +2059,7 @@ S: Maintained KERNEL JANITORS P: Several -L: kernel-janitors@vger.kernel.org +L: kernel-janitors@lists.linux-foundation.org W: http://www.kerneljanitors.org/ S: Maintained @@ -2274,11 +2233,11 @@ M: khali@linux-fr.org L: lm-sensors@lm-sensors.org S: Maintained -LOGICAL DISK MANAGER SUPPORT (LDM, Windows 2000/XP/Vista Dynamic Disks) +LOGICAL DISK MANAGER SUPPORT (LDM, Windows 2000/XP Dynamic Disks) P: Richard Russon (FlatCap) M: ldm@flatcap.org -L: linux-ntfs-dev@lists.sourceforge.net -W: http://www.linux-ntfs.org/content/view/19/37/ +L: ldm-devel@lists.sourceforge.net +W: http://ldm.sourceforge.net S: Maintained LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) @@ -2365,7 +2324,7 @@ S: Maintained MEGARAID SCSI DRIVERS P: Neela Syam Kolli -M: megaraidlinux@lsi.com +M: Neela.Kolli@engenio.com S: linux-scsi@vger.kernel.org W: http://megaraid.lsilogic.com S: Maintained @@ -2423,13 +2382,6 @@ M: stelian@popies.net W: http://popies.net/meye/ S: Maintained -MOTOROLA IMX MMC/SD HOST CONTROLLER INTERFACE DRIVER -P: Pavel Pisa -M: ppisa@pikron.com -L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only) -W: http://mmc.drzeus.cx/wiki/Controllers/Freescale/SDHC -S: Maintained - MOUSE AND MISC DEVICES [GENERAL] P: Alessandro Rubini M: rubini@ipvvis.unipv.it @@ -2739,13 +2691,13 @@ L: i2c@lm-sensors.org S: Maintained PARALLEL PORT SUPPORT -L: linux-parport@lists.infradead.org (subscribers-only) +L: linux-parport@lists.infradead.org S: Orphan PARIDE DRIVERS FOR PARALLEL PORT IDE DEVICES P: Tim Waugh M: tim@cyberelk.net -L: linux-parport@lists.infradead.org (subscribers-only) +L: linux-parport@lists.infradead.org W: http://www.torque.net/linux-pp.html S: Maintained @@ -2813,6 +2765,11 @@ P: Kristen Carlson Accardi M: kristen.c.accardi@intel.com S: Supported +PCI HOTPLUG COMPAQ DRIVER +P: Greg Kroah-Hartman +M: greg@kroah.com +S: Maintained + PCIE HOTPLUG DRIVER P: Kristen Carlson Accardi M: kristen.c.accardi@intel.com @@ -2897,11 +2854,6 @@ P: Michal Ostrowski M: mostrows@speakeasy.net S: Maintained -PPP OVER L2TP -P: James Chapman -M: jchapman@katalix.com -S: Maintained - PREEMPTIBLE KERNEL P: Robert Love M: rml@tech9.net @@ -2911,8 +2863,8 @@ W: ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel S: Supported PRISM54 WIRELESS DRIVER -P: Luis R. Rodriguez -M: mcgrof@gmail.com +P: Prism54 Development Team +M: developers@islsm.org L: linux-wireless@vger.kernel.org W: http://prism54.org S: Maintained @@ -2929,13 +2881,6 @@ M: mikpe@it.uu.se L: linux-ide@vger.kernel.org S: Maintained -PS3 NETWORK SUPPORT -P: Masakazu Mokuno -M: mokuno@sm.sony.co.jp -L: netdev@vger.kernel.org -L: cbe-oss-dev@ozlabs.org -S: Supported - PS3 PLATFORM SUPPORT P: Geoff Levand M: geoffrey.levand@am.sony.com @@ -2957,9 +2902,6 @@ M: nico@cam.org L: linux-arm-kernel@lists.arm.linux.org.uk (subscribers-only) S: Maintained -PXA MMCI DRIVER -S: Orphan - QLOGIC QLA2XXX FC-SCSI DRIVER P: Andrew Vasquez M: linux-driver@qlogic.com @@ -3036,7 +2978,7 @@ S: Maintained REISERFS FILE SYSTEM P: Hans Reiser M: reiserfs-dev@namesys.com -L: reiserfs-devel@vger.kernel.org +L: reiserfs-list@namesys.com W: http://www.namesys.com S: Supported @@ -3055,16 +2997,6 @@ S: Maintained RISCOM8 DRIVER S: Orphan -RTL818X WIRELESS DRIVER -P: Michael Wu -M: flamingice@sourmilk.net -P: Andrea Merello -M: andreamrl@tiscali.it -L: linux-wireless@vger.kernel.org -W: http://linuxwireless.org/ -T: git kernel.org:/pub/scm/linux/kernel/git/mwu/mac80211-drivers.git -S: Maintained - S3 SAVAGE FRAMEBUFFER DRIVER P: Antonino Daplas M: adaplas@gmail.com @@ -3337,7 +3269,6 @@ W: http://tpmdd.sourceforge.net P: Marcel Selhorst M: tpm@selhorst.net W: http://www.prosec.rub.de/tpm/ -L: tpmdd-devel@lists.sourceforge.net S: Maintained Telecom Clock Driver for MCPL0010 @@ -3486,13 +3417,6 @@ P: Alex Dubov M: oakad@yahoo.com S: Maintained -TI OMAP MMC INTERFACE DRIVER -P: Carlos Aguiar, Anderson Briglia and Syed Khasim -M: linux-omap-open-source@linux.omap.com -W: http://linux.omap.com -W: http://www.muru.com/linux/omap/ -S: Maintained - TI OMAP RANDOM NUMBER GENERATOR SUPPORT P: Deepak Saxena M: dsaxena@plexity.net @@ -3573,7 +3497,7 @@ S: Maintained TULIP NETWORK DRIVER P: Valerie Henson -M: val@nmt.edu +M: val_henson@linux.intel.com L: tulip-users@lists.sourceforge.net W: http://sourceforge.net/projects/tulip/ S: Maintained @@ -3634,7 +3558,7 @@ W: http://www.kroah.com/linux-usb/ USB DAVICOM DM9601 DRIVER P: Peter Korsgaard M: jacmet@sunsite.dk -L: netdev@vger.kernel.org +L: linux-usb-devel@lists.sourceforge.net W: http://www.linux-usb.org/usbnet S: Maintained @@ -3718,8 +3642,8 @@ S: Maintained USB PEGASUS DRIVER P: Petko Manolov M: petkan@users.sourceforge.net +L: linux-usb-users@lists.sourceforge.net L: linux-usb-devel@lists.sourceforge.net -L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3733,8 +3657,8 @@ S: Maintained USB RTL8150 DRIVER P: Petko Manolov M: petkan@users.sourceforge.net +L: linux-usb-users@lists.sourceforge.net L: linux-usb-devel@lists.sourceforge.net -L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3845,7 +3769,7 @@ S: Maintained USB "USBNET" DRIVER FRAMEWORK P: David Brownell M: dbrownell@users.sourceforge.net -L: netdev@vger.kernel.org +L: linux-usb-devel@lists.sourceforge.net W: http://www.linux-usb.org/usbnet S: Maintained @@ -3925,6 +3849,10 @@ S: Maintained UCLINUX FOR NEC V850 P: Miles Bader +M: uclinux-v850@lsi.nec.co.jp +W: http://www.ic.nec.co.jp/micro/uclinux/eng/ +W: http://www.ee.nec.de/uclinux/ +S: Supported UCLINUX FOR RENESAS H8/300 P: Yoshinori Sato @@ -3933,10 +3861,10 @@ W: http://uclinux-h8.sourceforge.jp/ S: Supported UFS FILESYSTEM -P: Evgeniy Dushistov -M: dushistov@mail.ru -L: linux-kernel@vger.kernel.org -S: Maintained +P: Evgeniy Dushistov +M: dushistov@mail.ru +L: linux-kernel@vger.kernel.org +S: Maintained USB DIAMOND RIO500 DRIVER P: Cesar Miquel @@ -4038,11 +3966,11 @@ S: Supported XFS FILESYSTEM P: Silicon Graphics Inc -P: Tim Shimmin +P: Tim Shimmin, David Chatterton M: xfs-masters@oss.sgi.com L: xfs@oss.sgi.com W: http://oss.sgi.com/projects/xfs -T: git git://oss.sgi.com:8090/xfs/xfs-2.6.git +T: git git://oss.sgi.com:8090/xfs/xfs-2.6 S: Supported XILINX UARTLITE SERIAL DRIVER diff --git a/trunk/Makefile b/trunk/Makefile index de4f8f7d396c..e6990e2cdafc 100644 --- a/trunk/Makefile +++ b/trunk/Makefile @@ -1,8 +1,8 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 22 -EXTRAVERSION = -NAME = Holy Dancing Manatees, Batman! +EXTRAVERSION = -rc1 +NAME = Nocturnal Monster Puppy # *DOCUMENTATION* # To see a list of typical targets execute "make help" @@ -491,7 +491,7 @@ endif include $(srctree)/arch/$(ARCH)/Makefile ifdef CONFIG_FRAME_POINTER -CFLAGS += -fno-omit-frame-pointer $(call cc-option,-fno-optimize-sibling-calls,) +CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls else CFLAGS += -fomit-frame-pointer endif diff --git a/trunk/arch/alpha/Kconfig b/trunk/arch/alpha/Kconfig index 2a85dc33907c..770f717bd250 100644 --- a/trunk/arch/alpha/Kconfig +++ b/trunk/arch/alpha/Kconfig @@ -83,20 +83,22 @@ choice check out the Linux/Alpha FAQ, accessible on the WWW from . In summary: - Alcor/Alpha-XLT AS 600, AS 500, XL-300, XL-366 + Alcor/Alpha-XLT AS 600 Alpha-XL XL-233, XL-266 AlphaBook1 Alpha laptop Avanti AS 200, AS 205, AS 250, AS 255, AS 300, AS 400 Cabriolet AlphaPC64, AlphaPCI64 - DP264 DP264 / DS20 / ES40 / DS10 / DS10L + DP264 DP264 EB164 EB164 21164 evaluation board EB64+ EB64+ 21064 evaluation board EB66 EB66 21066 evaluation board EB66+ EB66+ 21066 evaluation board - Jensen DECpc 150, DEC 2000 models 300, 500 + Jensen DECpc 150, DEC 2000 model 300, + DEC 2000 model 500 LX164 AlphaPC164-LX Lynx AS 2100A - Miata Personal Workstation 433/500/600 a/au + Miata Personal Workstation 433a, 433au, 500a, + 500au, 600a, or 600au Marvel AlphaServer ES47 / ES80 / GS1280 Mikasa AS 1000 Noname AXPpci33, UDB (Multia) @@ -106,9 +108,9 @@ choice Ruffian RPX164-2, AlphaPC164-UX, AlphaPC164-BX SX164 AlphaPC164-SX Sable AS 2000, AS 2100 - Shark DS 20L - Takara Takara (OEM) - Titan AlphaServer ES45 / DS25 / DS15 + Shark DS 20L + Takara Takara + Titan AlphaServer ES45 / DS25 Wildfire AlphaServer GS 40/80/160/320 If you don't know what to do, choose "generic". @@ -327,9 +329,6 @@ config PCI_DOMAINS bool default y -config PCI_SYSCALL - def_bool PCI - config ALPHA_CORE_AGP bool depends on ALPHA_GENERIC || ALPHA_TITAN || ALPHA_MARVEL @@ -482,15 +481,6 @@ config ALPHA_BROKEN_IRQ_MASK depends on ALPHA_GENERIC || ALPHA_PC164 default y -config VGA_HOSE - bool - depends on ALPHA_GENERIC || ALPHA_TITAN || ALPHA_MARVEL || ALPHA_TSUNAMI - default y - help - Support VGA on an arbitrary hose; needed for several platforms - which always have multiple hoses, and whose consoles support it. - - config ALPHA_SRM bool "Use SRM as bootloader" if ALPHA_CABRIOLET || ALPHA_AVANTI_CH || ALPHA_EB64P || ALPHA_PC164 || ALPHA_TAKARA || ALPHA_EB164 || ALPHA_ALCOR || ALPHA_MIATA || ALPHA_LX164 || ALPHA_SX164 || ALPHA_NAUTILUS || ALPHA_NONAME default y if ALPHA_JENSEN || ALPHA_MIKASA || ALPHA_SABLE || ALPHA_LYNX || ALPHA_NORITAKE || ALPHA_DP264 || ALPHA_RAWHIDE || ALPHA_EIGER || ALPHA_WILDFIRE || ALPHA_TITAN || ALPHA_SHARK || ALPHA_MARVEL @@ -547,14 +537,10 @@ config HAVE_DEC_LOCK default y config NR_CPUS - int "Maximum number of CPUs (2-32)" - range 2 32 + int "Maximum number of CPUs (2-64)" + range 2 64 depends on SMP - default "32" if ALPHA_GENERIC || ALPHA_MARVEL - default "4" if !ALPHA_GENERIC && !ALPHA_MARVEL - help - MARVEL support can handle a maximum of 32 CPUs, all the others - with working support have a maximum of 4 CPUs. + default "64" config ARCH_DISCONTIGMEM_ENABLE bool "Discontiguous Memory Support (EXPERIMENTAL)" @@ -658,13 +644,6 @@ source "arch/alpha/oprofile/Kconfig" source "arch/alpha/Kconfig.debug" -# DUMMY_CONSOLE may be defined in drivers/video/console/Kconfig -# but we also need it if VGA_HOSE is set -config DUMMY_CONSOLE - bool - depends on VGA_HOSE - default y - source "security/Kconfig" source "crypto/Kconfig" diff --git a/trunk/arch/alpha/boot/tools/mkbb.c b/trunk/arch/alpha/boot/tools/mkbb.c index 632a7fd6d7dc..23c7190b047c 100644 --- a/trunk/arch/alpha/boot/tools/mkbb.c +++ b/trunk/arch/alpha/boot/tools/mkbb.c @@ -81,7 +81,7 @@ typedef union __bootblock { #define bootblock_label __u1.__label #define bootblock_checksum __u2.__checksum -int main(int argc, char ** argv) +main(int argc, char ** argv) { bootblock bootblock_from_disk; bootblock bootloader_image; diff --git a/trunk/arch/alpha/kernel/console.c b/trunk/arch/alpha/kernel/console.c index da711e37fc97..f313b34939bb 100644 --- a/trunk/arch/alpha/kernel/console.c +++ b/trunk/arch/alpha/kernel/console.c @@ -9,20 +9,16 @@ #include #include #include -#include #include #include -#include "pci_impl.h" - #ifdef CONFIG_VGA_HOSE -struct pci_controller *pci_vga_hose; -static struct resource alpha_vga = { - .name = "alpha-vga+", - .start = 0x3C0, - .end = 0x3DF -}; +/* + * Externally-visible vga hose bases + */ +unsigned long __vga_hose_io_base = 0; /* base for default hose */ +unsigned long __vga_hose_mem_base = 0; /* base for default hose */ static struct pci_controller * __init default_vga_hose_select(struct pci_controller *h1, struct pci_controller *h2) @@ -33,59 +29,37 @@ default_vga_hose_select(struct pci_controller *h1, struct pci_controller *h2) return h1; } +void __init +set_vga_hose(struct pci_controller *hose) +{ + if (hose) { + __vga_hose_io_base = hose->io_space->start; + __vga_hose_mem_base = hose->mem_space->start; + } +} + void __init locate_and_init_vga(void *(*sel_func)(void *, void *)) { struct pci_controller *hose = NULL; struct pci_dev *dev = NULL; - /* Default the select function */ if (!sel_func) sel_func = (void *)default_vga_hose_select; - /* Find the console VGA device */ for(dev=NULL; (dev=pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, dev));) { - if (!hose) - hose = dev->sysdata; - else - hose = sel_func(hose, dev->sysdata); + if (!hose) hose = dev->sysdata; + else hose = sel_func(hose, dev->sysdata); } - /* Did we already initialize the correct one? Is there one? */ - if (!hose || (conswitchp == &vga_con && pci_vga_hose == hose)) + /* Did we already inititialize the correct one? */ + if (conswitchp == &vga_con && + __vga_hose_io_base == hose->io_space->start && + __vga_hose_mem_base == hose->mem_space->start) return; - /* Create a new VGA ioport resource WRT the hose it is on. */ - alpha_vga.start += hose->io_space->start; - alpha_vga.end += hose->io_space->start; - request_resource(hose->io_space, &alpha_vga); - - /* Set the VGA hose and init the new console. */ - pci_vga_hose = hose; + /* Set the VGA hose and init the new console */ + set_vga_hose(hose); take_over_console(&vga_con, 0, MAX_NR_CONSOLES-1, 1); } -void __init -find_console_vga_hose(void) -{ - u64 *pu64 = (u64 *)((u64)hwrpb + hwrpb->ctbt_offset); - - if (pu64[7] == 3) { /* TERM_TYPE == graphics */ - struct pci_controller *hose; - int h = (pu64[30] >> 24) & 0xff; /* console hose # */ - - /* - * Our hose numbering DOES match the console's, so find - * the right one... - */ - for (hose = hose_head; hose; hose = hose->next) { - if (hose->index == h) break; - } - - if (hose) { - printk("Console graphics on hose %d\n", h); - pci_vga_hose = hose; - } - } -} - #endif diff --git a/trunk/arch/alpha/kernel/core_marvel.c b/trunk/arch/alpha/kernel/core_marvel.c index f10d2eddd2c3..7f6a98455e74 100644 --- a/trunk/arch/alpha/kernel/core_marvel.c +++ b/trunk/arch/alpha/kernel/core_marvel.c @@ -25,7 +25,6 @@ #include #include #include -#include #include "proto.h" #include "pci_impl.h" @@ -368,8 +367,9 @@ marvel_io7_present(gct6_node *node) } static void __init -marvel_find_console_vga_hose(void) +marvel_init_vga_hose(void) { +#ifdef CONFIG_VGA_HOSE u64 *pu64 = (u64 *)((u64)hwrpb + hwrpb->ctbt_offset); if (pu64[7] == 3) { /* TERM_TYPE == graphics */ @@ -403,6 +403,7 @@ marvel_find_console_vga_hose(void) pci_vga_hose = hose; } } +#endif /* CONFIG_VGA_HOSE */ } gct6_search_struct gct_wanted_node_list[] = { @@ -458,7 +459,7 @@ marvel_init_arch(void) marvel_init_io7(io7); /* Check for graphic console location (if any). */ - marvel_find_console_vga_hose(); + marvel_init_vga_hose(); } void @@ -683,6 +684,9 @@ __marvel_rtc_io(u8 b, unsigned long addr, int write) /* * IO map support. */ + +#define __marvel_is_mem_vga(a) (((a) >= 0xa0000) && ((a) <= 0xc0000)) + void __iomem * marvel_ioremap(unsigned long addr, unsigned long size) { @@ -694,9 +698,13 @@ marvel_ioremap(unsigned long addr, unsigned long size) unsigned long pfn; /* - * Adjust the address. + * Adjust the addr. */ - FIXUP_MEMADDR_VGA(addr); +#ifdef CONFIG_VGA_HOSE + if (pci_vga_hose && __marvel_is_mem_vga(addr)) { + addr += pci_vga_hose->mem_space->start; + } +#endif /* * Find the hose. @@ -773,9 +781,7 @@ marvel_ioremap(unsigned long addr, unsigned long size) return (void __iomem *) vaddr; } - /* Assume it was already a reasonable address */ - vaddr = baddr + hose->mem_space->start; - return (void __iomem *) vaddr; + return NULL; } void @@ -797,12 +803,21 @@ marvel_is_mmio(const volatile void __iomem *xaddr) return (addr & 0xFF000000UL) == 0; } +#define __marvel_is_port_vga(a) \ + (((a) >= 0x3b0) && ((a) < 0x3e0) && ((a) != 0x3b3) && ((a) != 0x3d3)) #define __marvel_is_port_kbd(a) (((a) == 0x60) || ((a) == 0x64)) #define __marvel_is_port_rtc(a) (((a) == 0x70) || ((a) == 0x71)) void __iomem *marvel_ioportmap (unsigned long addr) { - FIXUP_IOADDR_VGA(addr); + if (__marvel_is_port_rtc (addr) || __marvel_is_port_kbd(addr)) + ; +#ifdef CONFIG_VGA_HOSE + else if (__marvel_is_port_vga (addr) && pci_vga_hose) + addr += pci_vga_hose->io_space->start; +#endif + else + return NULL; return (void __iomem *)addr; } @@ -814,14 +829,8 @@ marvel_ioread8(void __iomem *xaddr) return 0; else if (__marvel_is_port_rtc(addr)) return __marvel_rtc_io(0, addr, 0); - else if (marvel_is_ioaddr(addr)) - return __kernel_ldbu(*(vucp)addr); else - /* this should catch other legacy addresses - that would normally fail on MARVEL, - because there really is nothing there... - */ - return ~0; + return __kernel_ldbu(*(vucp)addr); } void @@ -832,7 +841,7 @@ marvel_iowrite8(u8 b, void __iomem *xaddr) return; else if (__marvel_is_port_rtc(addr)) __marvel_rtc_io(b, addr, 1); - else if (marvel_is_ioaddr(addr)) + else __kernel_stb(b, *(vucp)addr); } diff --git a/trunk/arch/alpha/kernel/core_titan.c b/trunk/arch/alpha/kernel/core_titan.c index 819326627b96..3662fef7db9a 100644 --- a/trunk/arch/alpha/kernel/core_titan.c +++ b/trunk/arch/alpha/kernel/core_titan.c @@ -21,7 +21,6 @@ #include #include #include -#include #include "proto.h" #include "pci_impl.h" @@ -35,11 +34,6 @@ struct unsigned long tba[4]; } saved_config[4] __attribute__((common)); -/* - * Is PChip 1 present? No need to query it more than once. - */ -static int titan_pchip1_present; - /* * BIOS32-style PCI interface: */ @@ -350,17 +344,43 @@ titan_init_one_pachip_port(titan_pachip_port *port, int index) static void __init titan_init_pachips(titan_pachip *pachip0, titan_pachip *pachip1) { - titan_pchip1_present = TITAN_cchip->csc.csr & 1L<<14; + int pchip1_present = TITAN_cchip->csc.csr & 1L<<14; /* Init the ports in hose order... */ titan_init_one_pachip_port(&pachip0->g_port, 0); /* hose 0 */ - if (titan_pchip1_present) + if (pchip1_present) titan_init_one_pachip_port(&pachip1->g_port, 1);/* hose 1 */ titan_init_one_pachip_port(&pachip0->a_port, 2); /* hose 2 */ - if (titan_pchip1_present) + if (pchip1_present) titan_init_one_pachip_port(&pachip1->a_port, 3);/* hose 3 */ } +static void __init +titan_init_vga_hose(void) +{ +#ifdef CONFIG_VGA_HOSE + u64 *pu64 = (u64 *)((u64)hwrpb + hwrpb->ctbt_offset); + + if (pu64[7] == 3) { /* TERM_TYPE == graphics */ + struct pci_controller *hose; + int h = (pu64[30] >> 24) & 0xff; /* console hose # */ + + /* + * Our hose numbering matches the console's, so just find + * the right one... + */ + for (hose = hose_head; hose; hose = hose->next) { + if (hose->index == h) break; + } + + if (hose) { + printk("Console graphics on hose %d\n", hose->index); + pci_vga_hose = hose; + } + } +#endif /* CONFIG_VGA_HOSE */ +} + void __init titan_init_arch(void) { @@ -386,7 +406,6 @@ titan_init_arch(void) /* With multiple PCI busses, we play with I/O as physical addrs. */ ioport_resource.end = ~0UL; - iomem_resource.end = ~0UL; /* PCI DMA Direct Mapping is 1GB at 2GB. */ __direct_map_base = 0x80000000; @@ -396,7 +415,7 @@ titan_init_arch(void) titan_init_pachips(TITAN_pachip0, TITAN_pachip1); /* Check for graphic console location (if any). */ - find_console_vga_hose(); + titan_init_vga_hose(); } static void @@ -422,7 +441,9 @@ titan_kill_one_pachip_port(titan_pachip_port *port, int index) static void titan_kill_pachips(titan_pachip *pachip0, titan_pachip *pachip1) { - if (titan_pchip1_present) { + int pchip1_present = TITAN_cchip->csc.csr & 1L<<14; + + if (pchip1_present) { titan_kill_one_pachip_port(&pachip1->g_port, 1); titan_kill_one_pachip_port(&pachip1->a_port, 3); } @@ -441,14 +462,6 @@ titan_kill_arch(int mode) * IO map support. */ -void __iomem * -titan_ioportmap(unsigned long addr) -{ - FIXUP_IOADDR_VGA(addr); - return (void __iomem *)(addr + TITAN_IO_BIAS); -} - - void __iomem * titan_ioremap(unsigned long addr, unsigned long size) { @@ -462,12 +475,14 @@ titan_ioremap(unsigned long addr, unsigned long size) unsigned long pfn; /* - * Adjust the address and hose, if necessary. + * Adjust the addr. */ - if (pci_vga_hose && __is_mem_vga(addr)) { +#ifdef CONFIG_VGA_HOSE + if (pci_vga_hose && __titan_is_mem_vga(addr)) { h = pci_vga_hose->index; addr += pci_vga_hose->mem_space->start; } +#endif /* * Find the hose. @@ -506,10 +521,8 @@ titan_ioremap(unsigned long addr, unsigned long size) * Map it */ area = get_vm_area(size, VM_IOREMAP); - if (!area) { - printk("ioremap failed... no vm_area...\n"); + if (!area) return NULL; - } ptes = hose->sg_pci->ptes; for (vaddr = (unsigned long)area->addr; @@ -526,7 +539,7 @@ titan_ioremap(unsigned long addr, unsigned long size) if (__alpha_remap_area_pages(vaddr, pfn << PAGE_SHIFT, PAGE_SIZE, 0)) { - printk("FAILED to remap_area_pages...\n"); + printk("FAILED to map...\n"); vfree(area->addr); return NULL; } @@ -538,8 +551,7 @@ titan_ioremap(unsigned long addr, unsigned long size) return (void __iomem *) vaddr; } - /* Assume a legacy (read: VGA) address, and return appropriately. */ - return (void __iomem *)(addr + TITAN_MEM_BIAS); + return NULL; } void @@ -562,7 +574,6 @@ titan_is_mmio(const volatile void __iomem *xaddr) } #ifndef CONFIG_ALPHA_GENERIC -EXPORT_SYMBOL(titan_ioportmap); EXPORT_SYMBOL(titan_ioremap); EXPORT_SYMBOL(titan_iounmap); EXPORT_SYMBOL(titan_is_mmio); @@ -739,7 +750,6 @@ titan_agp_info(void) if (titan_query_agp(port)) hosenum = 2; if (hosenum < 0 && - titan_pchip1_present && titan_query_agp(port = &TITAN_pachip1->a_port)) hosenum = 3; diff --git a/trunk/arch/alpha/kernel/core_tsunami.c b/trunk/arch/alpha/kernel/core_tsunami.c index ef91e09590d4..ce623c6e55e1 100644 --- a/trunk/arch/alpha/kernel/core_tsunami.c +++ b/trunk/arch/alpha/kernel/core_tsunami.c @@ -19,7 +19,6 @@ #include #include -#include #include "proto.h" #include "pci_impl.h" @@ -350,26 +349,6 @@ tsunami_init_one_pchip(tsunami_pchip *pchip, int index) tsunami_pci_tbi(hose, 0, -1); } - -void __iomem * -tsunami_ioportmap(unsigned long addr) -{ - FIXUP_IOADDR_VGA(addr); - return (void __iomem *)(addr + TSUNAMI_IO_BIAS); -} - -void __iomem * -tsunami_ioremap(unsigned long addr, unsigned long size) -{ - FIXUP_MEMADDR_VGA(addr); - return (void __iomem *)(addr + TSUNAMI_MEM_BIAS); -} - -#ifndef CONFIG_ALPHA_GENERIC -EXPORT_SYMBOL(tsunami_ioportmap); -EXPORT_SYMBOL(tsunami_ioremap); -#endif - void __init tsunami_init_arch(void) { @@ -414,9 +393,6 @@ tsunami_init_arch(void) tsunami_init_one_pchip(TSUNAMI_pchip0, 0); if (TSUNAMI_cchip->csc.csr & 1L<<14) tsunami_init_one_pchip(TSUNAMI_pchip1, 1); - - /* Check for graphic console location (if any). */ - find_console_vga_hose(); } static void diff --git a/trunk/arch/alpha/kernel/entry.S b/trunk/arch/alpha/kernel/entry.S index debc8f03886c..c95e95e1ab04 100644 --- a/trunk/arch/alpha/kernel/entry.S +++ b/trunk/arch/alpha/kernel/entry.S @@ -391,10 +391,11 @@ $work_resched: bne $2, $work_resched $work_notifysig: - mov $sp, $16 - br $1, do_switch_stack mov $sp, $17 - mov $5, $18 + br $1, do_switch_stack + mov $5, $21 + mov $sp, $18 + mov $31, $16 jsr $26, do_notify_resume bsr $1, undo_switch_stack br restore_all diff --git a/trunk/arch/alpha/kernel/pci_iommu.c b/trunk/arch/alpha/kernel/pci_iommu.c index 6b07f89a72c7..6e7d1fe6e935 100644 --- a/trunk/arch/alpha/kernel/pci_iommu.c +++ b/trunk/arch/alpha/kernel/pci_iommu.c @@ -7,7 +7,6 @@ #include #include #include -#include #include #include @@ -54,7 +53,7 @@ size_for_memory(unsigned long max) { unsigned long mem = max_low_pfn << PAGE_SHIFT; if (mem < max) - max = roundup_pow_of_two(mem); + max = 1UL << ceil_log2(mem); return max; } @@ -207,10 +206,6 @@ iommu_arena_free(struct pci_iommu_arena *arena, long ofs, long n) p[i] = 0; } -/* True if the machine supports DAC addressing, and DEV can - make use of it given MASK. */ -static int pci_dac_dma_supported(struct pci_dev *hwdev, u64 mask); - /* Map a single buffer of the indicated size for PCI DMA in streaming mode. The 32-bit PCI bus mastering address to use is returned. Once the device is given the dma address, the device owns this memory @@ -901,7 +896,7 @@ iommu_unbind(struct pci_iommu_arena *arena, long pg_start, long pg_count) /* True if the machine supports DAC addressing, and DEV can make use of it given MASK. */ -static int +int pci_dac_dma_supported(struct pci_dev *dev, u64 mask) { dma64_addr_t dac_offset = alpha_mv.pci_dac_offset; @@ -921,6 +916,32 @@ pci_dac_dma_supported(struct pci_dev *dev, u64 mask) return ok; } +EXPORT_SYMBOL(pci_dac_dma_supported); + +dma64_addr_t +pci_dac_page_to_dma(struct pci_dev *pdev, struct page *page, + unsigned long offset, int direction) +{ + return (alpha_mv.pci_dac_offset + + __pa(page_address(page)) + + (dma64_addr_t) offset); +} +EXPORT_SYMBOL(pci_dac_page_to_dma); + +struct page * +pci_dac_dma_to_page(struct pci_dev *pdev, dma64_addr_t dma_addr) +{ + unsigned long paddr = (dma_addr & PAGE_MASK) - alpha_mv.pci_dac_offset; + return virt_to_page(__va(paddr)); +} +EXPORT_SYMBOL(pci_dac_dma_to_page); + +unsigned long +pci_dac_dma_to_offset(struct pci_dev *pdev, dma64_addr_t dma_addr) +{ + return (dma_addr & ~PAGE_MASK); +} +EXPORT_SYMBOL(pci_dac_dma_to_offset); /* Helper for generic DMA-mapping functions. */ diff --git a/trunk/arch/alpha/kernel/proto.h b/trunk/arch/alpha/kernel/proto.h index 708d5ca87782..95912ecc65e1 100644 --- a/trunk/arch/alpha/kernel/proto.h +++ b/trunk/arch/alpha/kernel/proto.h @@ -108,15 +108,6 @@ extern int wildfire_cpuid_to_nid(int); extern unsigned long wildfire_node_mem_start(int); extern unsigned long wildfire_node_mem_size(int); -/* console.c */ -#ifdef CONFIG_VGA_HOSE -extern void find_console_vga_hose(void); -extern void locate_and_init_vga(void *(*)(void *, void *)); -#else -static inline void find_console_vga_hose(void) { } -static inline void locate_and_init_vga(void *(*sel_func)(void *, void *)) { } -#endif - /* setup.c */ extern unsigned long srm_hae; extern int boot_cpuid; diff --git a/trunk/arch/alpha/kernel/setup.c b/trunk/arch/alpha/kernel/setup.c index bd5e68cd61e8..915f26345c45 100644 --- a/trunk/arch/alpha/kernel/setup.c +++ b/trunk/arch/alpha/kernel/setup.c @@ -43,7 +43,6 @@ #include #include #include -#include extern struct atomic_notifier_head panic_notifier_list; static int alpha_panic_event(struct notifier_block *, unsigned long, void *); @@ -1304,7 +1303,7 @@ external_cache_probe(int minsize, int width) long size = minsize, maxsize = MAX_BCACHE_SIZE * 2; if (maxsize > (max_low_pfn + 1) << PAGE_SHIFT) - maxsize = 1 << (ilog2(max_low_pfn + 1) + PAGE_SHIFT); + maxsize = 1 << (floor_log2(max_low_pfn + 1) + PAGE_SHIFT); /* Get the first block cached. */ read_mem_block(__va(0), stride, size); diff --git a/trunk/arch/alpha/kernel/signal.c b/trunk/arch/alpha/kernel/signal.c index 410af4f3140e..7f64aa767d5a 100644 --- a/trunk/arch/alpha/kernel/signal.c +++ b/trunk/arch/alpha/kernel/signal.c @@ -32,8 +32,8 @@ #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) asmlinkage void ret_from_sys_call(void); -static void do_signal(struct pt_regs *, struct switch_stack *, - unsigned long, unsigned long); +static int do_signal(sigset_t *, struct pt_regs *, struct switch_stack *, + unsigned long, unsigned long); /* @@ -146,9 +146,11 @@ sys_rt_sigaction(int sig, const struct sigaction __user *act, asmlinkage int do_sigsuspend(old_sigset_t mask, struct pt_regs *regs, struct switch_stack *sw) { + sigset_t oldset; + mask &= _BLOCKABLE; spin_lock_irq(¤t->sighand->siglock); - current->saved_sigmask = current->blocked; + oldset = current->blocked; siginitset(¤t->blocked, mask); recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); @@ -158,17 +160,19 @@ do_sigsuspend(old_sigset_t mask, struct pt_regs *regs, struct switch_stack *sw) regs->r0 = EINTR; regs->r19 = 1; - current->state = TASK_INTERRUPTIBLE; - schedule(); - set_thread_flag(TIF_RESTORE_SIGMASK); - return -ERESTARTNOHAND; + while (1) { + current->state = TASK_INTERRUPTIBLE; + schedule(); + if (do_signal(&oldset, regs, sw, 0, 0)) + return -EINTR; + } } asmlinkage int do_rt_sigsuspend(sigset_t __user *uset, size_t sigsetsize, struct pt_regs *regs, struct switch_stack *sw) { - sigset_t set; + sigset_t oldset, set; /* XXX: Don't preclude handling different sized sigset_t's. */ if (sigsetsize != sizeof(sigset_t)) @@ -178,7 +182,7 @@ do_rt_sigsuspend(sigset_t __user *uset, size_t sigsetsize, sigdelsetmask(&set, ~_BLOCKABLE); spin_lock_irq(¤t->sighand->siglock); - current->saved_sigmask = current->blocked; + oldset = current->blocked; current->blocked = set; recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); @@ -188,10 +192,12 @@ do_rt_sigsuspend(sigset_t __user *uset, size_t sigsetsize, regs->r0 = EINTR; regs->r19 = 1; - current->state = TASK_INTERRUPTIBLE; - schedule(); - set_thread_flag(TIF_RESTORE_SIGMASK); - return -ERESTARTNOHAND; + while (1) { + current->state = TASK_INTERRUPTIBLE; + schedule(); + if (do_signal(&oldset, regs, sw, 0, 0)) + return -EINTR; + } } asmlinkage int @@ -430,7 +436,7 @@ setup_sigcontext(struct sigcontext __user *sc, struct pt_regs *regs, return err; } -static int +static void setup_frame(int sig, struct k_sigaction *ka, sigset_t *set, struct pt_regs *regs, struct switch_stack * sw) { @@ -475,14 +481,13 @@ setup_frame(int sig, struct k_sigaction *ka, sigset_t *set, current->comm, current->pid, frame, regs->pc, regs->r26); #endif - return 0; + return; give_sigsegv: force_sigsegv(sig, current); - return -EFAULT; } -static int +static void setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info, sigset_t *set, struct pt_regs *regs, struct switch_stack * sw) { @@ -538,38 +543,34 @@ setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info, current->comm, current->pid, frame, regs->pc, regs->r26); #endif - return 0; + return; give_sigsegv: force_sigsegv(sig, current); - return -EFAULT; } /* * OK, we're invoking a handler. */ -static inline int +static inline void handle_signal(int sig, struct k_sigaction *ka, siginfo_t *info, sigset_t *oldset, struct pt_regs * regs, struct switch_stack *sw) { - int ret; - if (ka->sa.sa_flags & SA_SIGINFO) - ret = setup_rt_frame(sig, ka, info, oldset, regs, sw); + setup_rt_frame(sig, ka, info, oldset, regs, sw); else - ret = setup_frame(sig, ka, oldset, regs, sw); + setup_frame(sig, ka, oldset, regs, sw); - if (ret == 0) { - spin_lock_irq(¤t->sighand->siglock); - sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask); - if (!(ka->sa.sa_flags & SA_NODEFER)) - sigaddset(¤t->blocked,sig); - recalc_sigpending(); - spin_unlock_irq(¤t->sighand->siglock); - } + if (ka->sa.sa_flags & SA_RESETHAND) + ka->sa.sa_handler = SIG_DFL; - return ret; + spin_lock_irq(¤t->sighand->siglock); + sigorsets(¤t->blocked,¤t->blocked,&ka->sa.sa_mask); + if (!(ka->sa.sa_flags & SA_NODEFER)) + sigaddset(¤t->blocked,sig); + recalc_sigpending(); + spin_unlock_irq(¤t->sighand->siglock); } static inline void @@ -610,42 +611,30 @@ syscall_restart(unsigned long r0, unsigned long r19, * restart. "r0" is also used as an indicator whether we can restart at * all (if we get here from anything but a syscall return, it will be 0) */ -static void -do_signal(struct pt_regs * regs, struct switch_stack * sw, +static int +do_signal(sigset_t *oldset, struct pt_regs * regs, struct switch_stack * sw, unsigned long r0, unsigned long r19) { siginfo_t info; int signr; unsigned long single_stepping = ptrace_cancel_bpt(current); struct k_sigaction ka; - sigset_t *oldset; - if (test_thread_flag(TIF_RESTORE_SIGMASK)) - oldset = ¤t->saved_sigmask; - else + if (!oldset) oldset = ¤t->blocked; /* This lets the debugger run, ... */ signr = get_signal_to_deliver(&info, &ka, regs, NULL); - /* ... so re-check the single stepping. */ single_stepping |= ptrace_cancel_bpt(current); if (signr > 0) { /* Whee! Actually deliver the signal. */ - if (r0) - syscall_restart(r0, r19, regs, &ka); - if (handle_signal(signr, &ka, &info, oldset, regs, sw) == 0) { - /* A signal was successfully delivered, and the - saved sigmask was stored on the signal frame, - and will be restored by sigreturn. So we can - simply clear the restore sigmask flag. */ - if (test_thread_flag(TIF_RESTORE_SIGMASK)) - clear_thread_flag(TIF_RESTORE_SIGMASK); - } + if (r0) syscall_restart(r0, r19, regs, &ka); + handle_signal(signr, &ka, &info, oldset, regs, sw); if (single_stepping) ptrace_set_bpt(current); /* re-set bpt */ - return; + return 1; } if (r0) { @@ -665,22 +654,17 @@ do_signal(struct pt_regs * regs, struct switch_stack * sw, break; } } - - /* If there's no signal to deliver, we just restore the saved mask. */ - if (test_thread_flag(TIF_RESTORE_SIGMASK)) { - clear_thread_flag(TIF_RESTORE_SIGMASK); - sigprocmask(SIG_SETMASK, ¤t->saved_sigmask, NULL); - } - if (single_stepping) ptrace_set_bpt(current); /* re-set breakpoint */ + + return 0; } void -do_notify_resume(struct pt_regs *regs, struct switch_stack *sw, - unsigned long thread_info_flags, - unsigned long r0, unsigned long r19) +do_notify_resume(sigset_t *oldset, struct pt_regs *regs, + struct switch_stack *sw, unsigned long r0, + unsigned long r19, unsigned long thread_info_flags) { - if (thread_info_flags & (_TIF_SIGPENDING | _TIF_RESTORE_SIGMASK)) - do_signal(regs, sw, r0, r19); + if (thread_info_flags & _TIF_SIGPENDING) + do_signal(oldset, regs, sw, r0, r19); } diff --git a/trunk/arch/alpha/kernel/sys_dp264.c b/trunk/arch/alpha/kernel/sys_dp264.c index c71b0fd7a61f..85d2f933dd07 100644 --- a/trunk/arch/alpha/kernel/sys_dp264.c +++ b/trunk/arch/alpha/kernel/sys_dp264.c @@ -543,7 +543,6 @@ dp264_init_pci(void) { common_init_pci(); SMC669_Init(0); - locate_and_init_vga(NULL); } static void __init @@ -552,14 +551,6 @@ monet_init_pci(void) common_init_pci(); SMC669_Init(1); es1888_init(); - locate_and_init_vga(NULL); -} - -static void __init -clipper_init_pci(void) -{ - common_init_pci(); - locate_and_init_vga(NULL); } static void __init @@ -664,7 +655,7 @@ struct alpha_machine_vector clipper_mv __initmv = { .init_arch = tsunami_init_arch, .init_irq = clipper_init_irq, .init_rtc = common_init_rtc, - .init_pci = clipper_init_pci, + .init_pci = common_init_pci, .kill_arch = tsunami_kill_arch, .pci_map_irq = clipper_map_irq, .pci_swizzle = common_swizzle, diff --git a/trunk/arch/alpha/kernel/sys_marvel.c b/trunk/arch/alpha/kernel/sys_marvel.c index 0bcb968cb60a..e349f03b830e 100644 --- a/trunk/arch/alpha/kernel/sys_marvel.c +++ b/trunk/arch/alpha/kernel/sys_marvel.c @@ -22,7 +22,6 @@ #include #include #include -#include #include "proto.h" #include "err_impl.h" @@ -413,7 +412,10 @@ marvel_init_pci(void) pci_probe_only = 1; common_init_pci(); + +#ifdef CONFIG_VGA_HOSE locate_and_init_vga(NULL); +#endif /* Clear any io7 errors. */ for (io7 = NULL; (io7 = marvel_next_io7(io7)) != NULL; ) diff --git a/trunk/arch/alpha/kernel/sys_titan.c b/trunk/arch/alpha/kernel/sys_titan.c index 1d3c1398c428..f009b7bc0943 100644 --- a/trunk/arch/alpha/kernel/sys_titan.c +++ b/trunk/arch/alpha/kernel/sys_titan.c @@ -331,7 +331,9 @@ titan_init_pci(void) pci_probe_only = 1; common_init_pci(); SMC669_Init(0); +#ifdef CONFIG_VGA_HOSE locate_and_init_vga(NULL); +#endif } diff --git a/trunk/arch/alpha/kernel/systbls.S b/trunk/arch/alpha/kernel/systbls.S index 79de99e32c35..f6cfe8ce3f96 100644 --- a/trunk/arch/alpha/kernel/systbls.S +++ b/trunk/arch/alpha/kernel/systbls.S @@ -465,38 +465,6 @@ sys_call_table: .quad sys_inotify_init .quad sys_inotify_add_watch /* 445 */ .quad sys_inotify_rm_watch - .quad sys_fdatasync - .quad sys_kexec_load - .quad sys_migrate_pages - .quad sys_openat /* 450 */ - .quad sys_mkdirat - .quad sys_mknodat - .quad sys_fchownat - .quad sys_futimesat - .quad sys_fstatat64 /* 455 */ - .quad sys_unlinkat - .quad sys_renameat - .quad sys_linkat - .quad sys_symlinkat - .quad sys_readlinkat /* 460 */ - .quad sys_fchmodat - .quad sys_faccessat - .quad sys_pselect6 - .quad sys_ppoll - .quad sys_unshare /* 465 */ - .quad sys_set_robust_list - .quad sys_get_robust_list - .quad sys_splice - .quad sys_sync_file_range - .quad sys_tee /* 470 */ - .quad sys_vmsplice - .quad sys_move_pages - .quad sys_getcpu - .quad sys_epoll_pwait - .quad sys_utimensat /* 475 */ - .quad sys_signalfd - .quad sys_timerfd - .quad sys_eventfd .size sys_call_table, . - sys_call_table .type sys_call_table, @object diff --git a/trunk/arch/alpha/kernel/vmlinux.lds.S b/trunk/arch/alpha/kernel/vmlinux.lds.S index 449e76f118d3..cf1e6fc6c686 100644 --- a/trunk/arch/alpha/kernel/vmlinux.lds.S +++ b/trunk/arch/alpha/kernel/vmlinux.lds.S @@ -15,7 +15,7 @@ SECTIONS _text = .; /* Text and read-only data */ .text : { - TEXT_TEXT + *(.text) SCHED_TEXT LOCK_TEXT *(.fixup) @@ -89,7 +89,7 @@ SECTIONS _data = .; .data : { /* Data */ - DATA_DATA + *(.data) CONSTRUCTORS } diff --git a/trunk/arch/alpha/lib/Makefile b/trunk/arch/alpha/lib/Makefile index 266f78e13076..ea098f3b629f 100644 --- a/trunk/arch/alpha/lib/Makefile +++ b/trunk/arch/alpha/lib/Makefile @@ -37,8 +37,7 @@ lib-y = __divqu.o __remqu.o __divlu.o __remlu.o \ $(ev6-y)clear_page.o \ $(ev6-y)copy_page.o \ fpreg.o \ - callback_srm.o srm_puts.o srm_printk.o \ - fls.o + callback_srm.o srm_puts.o srm_printk.o lib-$(CONFIG_SMP) += dec_and_lock.o diff --git a/trunk/arch/alpha/lib/csum_ipv6_magic.S b/trunk/arch/alpha/lib/csum_ipv6_magic.S index 2c2acb96deb6..e09748dbf2ed 100644 --- a/trunk/arch/alpha/lib/csum_ipv6_magic.S +++ b/trunk/arch/alpha/lib/csum_ipv6_magic.S @@ -7,9 +7,6 @@ * __u32 len, * unsigned short proto, * unsigned int csum); - * - * Misalignment handling (which costs 16 instructions / 8 cycles) - * added by Ivan Kokshaysky */ .globl csum_ipv6_magic @@ -19,57 +16,37 @@ csum_ipv6_magic: .prologue 0 - ldq_u $0,0($16) # e0 : load src & dst addr words + ldq $0,0($16) # e0 : load src & dst addr words zapnot $20,15,$20 # .. e1 : zero extend incoming csum extqh $18,1,$4 # e0 : byte swap len & proto while we wait - ldq_u $21,7($16) # .. e1 : handle misalignment + ldq $1,8($16) # .. e1 : extbl $18,1,$5 # e0 : - ldq_u $1,8($16) # .. e1 : + ldq $2,0($17) # .. e1 : extbl $18,2,$6 # e0 : - ldq_u $22,15($16) # .. e1 : + ldq $3,8($17) # .. e1 : extbl $18,3,$18 # e0 : - ldq_u $2,0($17) # .. e1 : sra $4,32,$4 # e0 : - ldq_u $23,7($17) # .. e1 : - - extql $0,$16,$0 # e0 : - ldq_u $3,8($17) # .. e1 : - extqh $21,$16,$21 # e0 : - ldq_u $24,15($17) # .. e1 : - sll $5,16,$5 # e0 : - or $0,$21,$0 # .. e1 : 1st src word complete - extql $1,$16,$1 # e0 : addq $20,$0,$20 # .. e1 : begin summing the words - extqh $22,$16,$22 # e0 : - cmpult $20,$0,$0 # .. e1 : sll $6,8,$6 # e0 : - or $1,$22,$1 # .. e1 : 2nd src word complete - - extql $2,$17,$2 # e0 : + cmpult $20,$0,$0 # .. e1 : + extwh $19,7,$7 # e0 : or $4,$18,$18 # .. e1 : - extqh $23,$17,$23 # e0 : - or $5,$6,$5 # .. e1 : - - extql $3,$17,$3 # e0 : - or $2,$23,$2 # .. e1 : 1st dst word complete - extqh $24,$17,$24 # e0 : - or $18,$5,$18 # .. e1 : len complete - extwh $19,7,$7 # e0 : - or $3,$24,$3 # .. e1 : 2nd dst word complete extbl $19,1,$19 # e0 : - addq $20,$1,$20 # .. e1 : + or $5,$6,$5 # .. e1 : + or $18,$5,$18 # e0 : len complete + or $19,$7,$19 # .. e1 : - or $19,$7,$19 # e0 : - cmpult $20,$1,$1 # .. e1 : sll $19,48,$19 # e0 : - nop # .. e0 : - + addq $20,$1,$20 # .. e1 : sra $19,32,$19 # e0 : proto complete + cmpult $20,$1,$1 # .. e1 : + + nop # e0 : addq $20,$2,$20 # .. e1 : cmpult $20,$2,$2 # e0 : addq $20,$3,$20 # .. e1 : @@ -107,7 +84,7 @@ csum_ipv6_magic: extwl $0,2,$1 # e0 : fold 17-bit value zapnot $0,3,$0 # .. e1 : addq $0,$1,$0 # e0 : - not $0,$0 # .. e1 : and complement. + not $0,$0 # e1 : and complement. zapnot $0,3,$0 # e0 : ret # .. e1 : diff --git a/trunk/arch/alpha/lib/ev6-csum_ipv6_magic.S b/trunk/arch/alpha/lib/ev6-csum_ipv6_magic.S index fc0bc399f872..de1948a69118 100644 --- a/trunk/arch/alpha/lib/ev6-csum_ipv6_magic.S +++ b/trunk/arch/alpha/lib/ev6-csum_ipv6_magic.S @@ -46,10 +46,6 @@ * add the 3 low ushorts together, generating a uint * a final add of the 2 lower ushorts * truncating the result. - * - * Misalignment handling added by Ivan Kokshaysky - * The cost is 16 instructions (~8 cycles), including two extra loads which - * may cause additional delay in rare cases (load-load replay traps). */ .globl csum_ipv6_magic @@ -59,45 +55,25 @@ csum_ipv6_magic: .prologue 0 - ldq_u $0,0($16) # L : Latency: 3 + ldq $0,0($16) # L : Latency: 3 inslh $18,7,$4 # U : 0000000000AABBCC - ldq_u $1,8($16) # L : Latency: 3 + ldq $1,8($16) # L : Latency: 3 sll $19,8,$7 # U : U L U L : 0x00000000 00aabb00 - and $16,7,$6 # E : src misalignment - ldq_u $5,15($16) # L : Latency: 3 zapnot $20,15,$20 # U : zero extend incoming csum - ldq_u $2,0($17) # L : U L U L : Latency: 3 - - extql $0,$6,$0 # U : - extqh $1,$6,$22 # U : - ldq_u $3,8($17) # L : Latency: 3 - sll $19,24,$19 # U : U U L U : 0x000000aa bb000000 - - cmoveq $6,$31,$22 # E : src aligned? - ldq_u $23,15($17) # L : Latency: 3 + ldq $2,0($17) # L : Latency: 3 + sll $19,24,$19 # U : U L L U : 0x000000aa bb000000 inswl $18,3,$18 # U : 000000CCDD000000 - addl $19,$7,$19 # E : U L U L : bbaabb00 - or $0,$22,$0 # E : 1st src word complete - extql $1,$6,$1 # U : - or $18,$4,$18 # E : 000000CCDDAABBCC - extqh $5,$6,$5 # U : L U L U + ldq $3,8($17) # L : Latency: 3 + bis $18,$4,$18 # E : 000000CCDDAABBCC + addl $19,$7,$19 # E : bbaabb00 + nop # E : U L U L - and $17,7,$6 # E : dst misalignment - extql $2,$6,$2 # U : - or $1,$5,$1 # E : 2nd src word complete - extqh $3,$6,$22 # U : L U L U : - - cmoveq $6,$31,$22 # E : dst aligned? - extql $3,$6,$3 # U : addq $20,$0,$20 # E : begin summing the words - extqh $23,$6,$23 # U : L U L U : - srl $18,16,$4 # U : 0000000000CCDDAA - or $2,$22,$2 # E : 1st dst word complete zap $19,0x3,$19 # U : bbaa0000 - or $3,$23,$3 # E : U L U L : 2nd dst word complete + nop # E : L U U L cmpult $20,$0,$0 # E : addq $20,$1,$20 # E : diff --git a/trunk/arch/alpha/lib/fls.c b/trunk/arch/alpha/lib/fls.c deleted file mode 100644 index 7ad84ea0acf8..000000000000 --- a/trunk/arch/alpha/lib/fls.c +++ /dev/null @@ -1,38 +0,0 @@ -/* - * arch/alpha/lib/fls.c - */ - -#include -#include - -/* This is fls(x)-1, except zero is held to zero. This allows most - efficent input into extbl, plus it allows easy handling of fls(0)=0. */ - -const unsigned char __flsm1_tab[256] = -{ - 0, - 0, - 1, 1, - 2, 2, 2, 2, - 3, 3, 3, 3, 3, 3, 3, 3, - 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, - - 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, - 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, - - 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, - 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, - 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, - 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, - - 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, - 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, - 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, - 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, - 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, - 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, - 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, - 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, -}; - -EXPORT_SYMBOL(__flsm1_tab); diff --git a/trunk/arch/arm/Kconfig b/trunk/arch/arm/Kconfig index 482d33f9ce5b..e55bbd32dcac 100644 --- a/trunk/arch/arm/Kconfig +++ b/trunk/arch/arm/Kconfig @@ -287,7 +287,6 @@ config ARCH_IXP2000 config ARCH_IXP4XX bool "IXP4xx-based" depends on MMU - select GENERIC_GPIO select GENERIC_TIME select GENERIC_CLOCKEVENTS help @@ -531,9 +530,6 @@ config PCI information about which PCI hardware does work under Linux and which doesn't. -config PCI_SYSCALL - def_bool PCI - # Select the host bridge type config PCI_HOST_VIA82C505 bool diff --git a/trunk/arch/arm/boot/.gitignore b/trunk/arch/arm/boot/.gitignore index ce1c5ff746e7..171a0853caf8 100644 --- a/trunk/arch/arm/boot/.gitignore +++ b/trunk/arch/arm/boot/.gitignore @@ -1,5 +1,2 @@ Image zImage -xipImage -bootpImage -uImage diff --git a/trunk/arch/arm/boot/compressed/head.S b/trunk/arch/arm/boot/compressed/head.S index 680ea6ed77b8..2568d311be21 100644 --- a/trunk/arch/arm/boot/compressed/head.S +++ b/trunk/arch/arm/boot/compressed/head.S @@ -247,7 +247,7 @@ not_relocated: mov r0, #0 mov r3, r7 bl decompress_kernel - add r0, r0, #127 + 128 @ alignment + stack + add r0, r0, #127 bic r0, r0, #127 @ align the kernel length /* * r0 = decompressed kernel length @@ -269,7 +269,6 @@ not_relocated: mov r0, #0 stmia r1!, {r9 - r14} cmp r2, r3 blo 1b - add sp, r1, #128 @ relocate the stack bl cache_clean_flush add pc, r5, r0 @ call relocation code @@ -477,7 +476,6 @@ __common_mmu_cache_on: */ .align 5 reloc_start: add r9, r5, r0 - sub r9, r9, #128 @ do not copy the stack debug_reloc_start mov r1, r4 1: @@ -488,7 +486,6 @@ reloc_start: add r9, r5, r0 cmp r5, r9 blo 1b - add sp, r1, #128 @ relocate the stack debug_reloc_end call_kernel: bl cache_clean_flush @@ -836,7 +833,6 @@ memdump: mov r12, r0 mov pc, r10 #endif - .ltorg reloc_end: .align diff --git a/trunk/arch/arm/common/dmabounce.c b/trunk/arch/arm/common/dmabounce.c index b36b1e8a105d..6fbe7722aa44 100644 --- a/trunk/arch/arm/common/dmabounce.c +++ b/trunk/arch/arm/common/dmabounce.c @@ -6,7 +6,7 @@ * copy data to/from buffers located outside the DMA region. This * only works for systems in which DMA memory is at the bottom of * RAM, the remainder of memory is at the top and the DMA memory - * can be marked as ZONE_DMA. Anything beyond that such as discontiguous + * can be marked as ZONE_DMA. Anything beyond that such as discontigous * DMA windows will require custom implementations that reserve memory * areas at early bootup. * diff --git a/trunk/arch/arm/common/gic.c b/trunk/arch/arm/common/gic.c index 0c89bd35e06f..4deece5fbdf4 100644 --- a/trunk/arch/arm/common/gic.c +++ b/trunk/arch/arm/common/gic.c @@ -72,7 +72,7 @@ static inline unsigned int gic_irq(unsigned int irq) * unmask it, in the same way we need to unmask an interrupt when * we first enable it. * - * The GIC has a separate notion of "end of interrupt" to re-enable + * The GIC has a seperate notion of "end of interrupt" to re-enable * an interrupt after handling, in order to support hardware * prioritisation. * @@ -125,11 +125,12 @@ static void gic_set_cpu(unsigned int irq, cpumask_t mask_val) } #endif -static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc) +static void fastcall gic_handle_cascade_irq(unsigned int irq, + struct irq_desc *desc) { struct gic_chip_data *chip_data = get_irq_data(irq); struct irq_chip *chip = get_irq_chip(irq); - unsigned int cascade_irq, gic_irq; + unsigned int cascade_irq; unsigned long status; /* primary controller ack'ing */ @@ -139,15 +140,16 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc) status = readl(chip_data->cpu_base + GIC_CPU_INTACK); spin_unlock(&irq_controller_lock); - gic_irq = (status & 0x3ff); - if (gic_irq == 1023) + cascade_irq = (status & 0x3ff); + if (cascade_irq > 1020) goto out; - - cascade_irq = gic_irq + chip_data->irq_offset; - if (unlikely(gic_irq < 32 || gic_irq > 1020 || cascade_irq >= NR_IRQS)) + if (cascade_irq < 32 || cascade_irq >= NR_IRQS) { do_bad_IRQ(cascade_irq, desc); - else - generic_handle_irq(cascade_irq); + goto out; + } + + cascade_irq += chip_data->irq_offset; + generic_handle_irq(cascade_irq); out: /* primary controller unmasking */ diff --git a/trunk/arch/arm/common/locomo.c b/trunk/arch/arm/common/locomo.c index ae21755872ed..cfe6f4650bc9 100644 --- a/trunk/arch/arm/common/locomo.c +++ b/trunk/arch/arm/common/locomo.c @@ -60,9 +60,6 @@ struct locomo { unsigned int irq; spinlock_t lock; void __iomem *base; -#ifdef CONFIG_PM - void *saved_state; -#endif }; struct locomo_dev_info { @@ -568,7 +565,7 @@ static int locomo_suspend(struct platform_device *dev, pm_message_t state) if (!save) return -ENOMEM; - lchip->saved_state = save; + dev->dev.power.saved_state = (void *) save; spin_lock_irqsave(&lchip->lock, flags); @@ -608,8 +605,8 @@ static int locomo_resume(struct platform_device *dev) struct locomo_save_data *save; unsigned long r; unsigned long flags; - - save = lchip->saved_state; + + save = (struct locomo_save_data *) dev->dev.power.saved_state; if (!save) return 0; @@ -631,8 +628,6 @@ static int locomo_resume(struct platform_device *dev) locomo_writel(0x1, lchip->base + LOCOMO_KEYBOARD + LOCOMO_KCMD); spin_unlock_irqrestore(&lchip->lock, flags); - - lchip->saved_state = NULL; kfree(save); return 0; diff --git a/trunk/arch/arm/common/sa1111.c b/trunk/arch/arm/common/sa1111.c index eb06d0b2cb74..798bbfccafb7 100644 --- a/trunk/arch/arm/common/sa1111.c +++ b/trunk/arch/arm/common/sa1111.c @@ -51,9 +51,6 @@ struct sa1111 { int irq; spinlock_t lock; void __iomem *base; -#ifdef CONFIG_PM - void *saved_state; -#endif }; /* @@ -825,7 +822,7 @@ static int sa1111_suspend(struct platform_device *dev, pm_message_t state) save = kmalloc(sizeof(struct sa1111_save_data), GFP_KERNEL); if (!save) return -ENOMEM; - sachip->saved_state = save; + dev->dev.power.saved_state = save; spin_lock_irqsave(&sachip->lock, flags); @@ -881,7 +878,7 @@ static int sa1111_resume(struct platform_device *dev) unsigned long flags, id; void __iomem *base; - save = sachip->saved_state; + save = (struct sa1111_save_data *)dev->dev.power.saved_state; if (!save) return 0; @@ -926,7 +923,7 @@ static int sa1111_resume(struct platform_device *dev) spin_unlock_irqrestore(&sachip->lock, flags); - sachip->saved_state = NULL; + dev->dev.power.saved_state = NULL; kfree(save); return 0; @@ -961,8 +958,8 @@ static int sa1111_remove(struct platform_device *pdev) platform_set_drvdata(pdev, NULL); #ifdef CONFIG_PM - kfree(sachip->saved_state); - sachip->saved_state = NULL; + kfree(pdev->dev.power.saved_state); + pdev->dev.power.saved_state = NULL; #endif } diff --git a/trunk/arch/arm/common/sharpsl_param.c b/trunk/arch/arm/common/sharpsl_param.c index aad4d94ba8f5..c94864c5b1af 100644 --- a/trunk/arch/arm/common/sharpsl_param.c +++ b/trunk/arch/arm/common/sharpsl_param.c @@ -20,7 +20,7 @@ * typically including LCD parameters are loaded by the bootloader at the * address PARAM_BASE. As the kernel will overwrite them, we need to store * them early in the boot process, then pass them to the appropriate drivers. - * Not all devices use all parameters but the format is common to all. + * Not all devices use all paramaters but the format is common to all. */ #ifdef CONFIG_ARCH_SA1100 #define PARAM_BASE 0xe8ffc000 diff --git a/trunk/arch/arm/common/sharpsl_pm.c b/trunk/arch/arm/common/sharpsl_pm.c index 3bf3a927ae22..5972df2b9af4 100644 --- a/trunk/arch/arm/common/sharpsl_pm.c +++ b/trunk/arch/arm/common/sharpsl_pm.c @@ -153,7 +153,7 @@ static void sharpsl_battery_thread(struct work_struct *private_) sharpsl_pm.battstat.mainbat_percent = percent; } - dev_dbg(sharpsl_pm.dev, "Battery: voltage: %d, status: %d, percentage: %d, time: %ld\n", voltage, + dev_dbg(sharpsl_pm.dev, "Battery: voltage: %d, status: %d, percentage: %d, time: %d\n", voltage, sharpsl_pm.battstat.mainbat_status, sharpsl_pm.battstat.mainbat_percent, jiffies); /* If battery is low. limit backlight intensity to save power. */ @@ -291,7 +291,7 @@ static void sharpsl_chrg_full_timer(unsigned long data) } /* Charging Finished Interrupt (Not present on Corgi) */ -/* Can trigger at the same time as an AC status change so +/* Can trigger at the same time as an AC staus change so delay until after that has been processed */ irqreturn_t sharpsl_chrg_full_isr(int irq, void *dev_id) { @@ -625,7 +625,7 @@ static int sharpsl_fatal_check(void) } temp = get_select_val(buff); - dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check: acin: %d, discharge voltage: %d, no discharge: %ld\n", acin, temp, sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT)); + dev_dbg(sharpsl_pm.dev, "sharpsl_fatal_check: acin: %d, discharge voltage: %d, no discharge: %d\n", acin, temp, sharpsl_pm.machinfo->read_devdata(SHARPSL_BATT_VOLT)); if ((acin && (temp < sharpsl_pm.machinfo->fatal_acin_volt)) || (!acin && (temp < sharpsl_pm.machinfo->fatal_noacin_volt))) @@ -635,7 +635,7 @@ static int sharpsl_fatal_check(void) static int sharpsl_off_charge_error(void) { - dev_err(sharpsl_pm.dev, "Offline Charger: Error occurred.\n"); + dev_err(sharpsl_pm.dev, "Offline Charger: Error occured.\n"); sharpsl_pm.machinfo->charge(0); sharpsl_pm_led(SHARPSL_LED_ERROR); sharpsl_pm.charge_mode = CHRG_ERROR; @@ -691,14 +691,14 @@ static int sharpsl_off_charge_battery(void) time = RCNR; while(1) { - /* Check if any wakeup event had occurred */ + /* Check if any wakeup event had occured */ if (sharpsl_pm.machinfo->charger_wakeup() != 0) return 0; /* Check for timeout */ if ((RCNR - time) > SHARPSL_WAIT_CO_TIME) return 1; if (sharpsl_pm.machinfo->read_devdata(SHARPSL_STATUS_CHRGFULL)) { - dev_dbg(sharpsl_pm.dev, "Offline Charger: Charge full occurred. Retrying to check\n"); + dev_dbg(sharpsl_pm.dev, "Offline Charger: Charge full occured. Retrying to check\n"); sharpsl_pm.full_count++; sharpsl_pm.machinfo->charge(0); mdelay(SHARPSL_CHARGE_WAIT_TIME); @@ -714,7 +714,7 @@ static int sharpsl_off_charge_battery(void) time = RCNR; while(1) { - /* Check if any wakeup event had occurred */ + /* Check if any wakeup event had occured */ if (sharpsl_pm.machinfo->charger_wakeup() != 0) return 0; /* Check for timeout */ @@ -774,8 +774,6 @@ static struct pm_ops sharpsl_pm_ops = { static int __init sharpsl_pm_probe(struct platform_device *pdev) { - int ret; - if (!pdev->dev.platform_data) return -EINVAL; @@ -794,10 +792,8 @@ static int __init sharpsl_pm_probe(struct platform_device *pdev) sharpsl_pm.machinfo->init(); - ret = device_create_file(&pdev->dev, &dev_attr_battery_percentage); - ret |= device_create_file(&pdev->dev, &dev_attr_battery_voltage); - if (ret != 0) - dev_warn(&pdev->dev, "Failed to register attributes (%d)\n", ret); + device_create_file(&pdev->dev, &dev_attr_battery_percentage); + device_create_file(&pdev->dev, &dev_attr_battery_voltage); apm_get_power_status = sharpsl_apm_get_power_status; diff --git a/trunk/arch/arm/kernel/armksyms.c b/trunk/arch/arm/kernel/armksyms.c index f73d62e8ab60..9179e8220314 100644 --- a/trunk/arch/arm/kernel/armksyms.c +++ b/trunk/arch/arm/kernel/armksyms.c @@ -57,7 +57,7 @@ extern void fp_enter(void); #define EXPORT_SYMBOL_ALIAS(sym,orig) \ EXPORT_CRC_ALIAS(sym) \ static const struct kernel_symbol __ksymtab_##sym \ - __used __attribute__((section("__ksymtab"))) = \ + __attribute_used__ __attribute__((section("__ksymtab"))) = \ { (unsigned long)&orig, #sym }; /* diff --git a/trunk/arch/arm/kernel/asm-offsets.c b/trunk/arch/arm/kernel/asm-offsets.c index 3278e713c32a..3c078e346753 100644 --- a/trunk/arch/arm/kernel/asm-offsets.c +++ b/trunk/arch/arm/kernel/asm-offsets.c @@ -85,7 +85,7 @@ int main(void) DEFINE(S_OLD_R0, offsetof(struct pt_regs, ARM_ORIG_r0)); DEFINE(S_FRAME_SIZE, sizeof(struct pt_regs)); BLANK(); -#ifdef CONFIG_CPU_HAS_ASID +#if __LINUX_ARM_ARCH__ >= 6 DEFINE(MM_CONTEXT_ID, offsetof(struct mm_struct, context.id)); BLANK(); #endif diff --git a/trunk/arch/arm/kernel/calls.S b/trunk/arch/arm/kernel/calls.S index a98d0c933db0..ae89cdd82b16 100644 --- a/trunk/arch/arm/kernel/calls.S +++ b/trunk/arch/arm/kernel/calls.S @@ -350,17 +350,13 @@ CALL(sys_set_robust_list) CALL(sys_get_robust_list) /* 340 */ CALL(sys_splice) - CALL(sys_sync_file_range2) + CALL(sys_arm_sync_file_range) CALL(sys_tee) CALL(sys_vmsplice) CALL(sys_move_pages) /* 345 */ CALL(sys_getcpu) CALL(sys_ni_syscall) /* eventually epoll_pwait */ CALL(sys_kexec_load) - CALL(sys_utimensat) - CALL(sys_signalfd) -/* 350 */ CALL(sys_timerfd) - CALL(sys_eventfd) #ifndef syscalls_counted .equ syscalls_padding, ((NR_syscalls + 3) & ~3) - NR_syscalls #define syscalls_counted diff --git a/trunk/arch/arm/kernel/process.c b/trunk/arch/arm/kernel/process.c index 842361777d4e..5d6e6523598b 100644 --- a/trunk/arch/arm/kernel/process.c +++ b/trunk/arch/arm/kernel/process.c @@ -28,7 +28,6 @@ #include #include #include -#include #include #include @@ -200,19 +199,16 @@ void machine_restart(char * __unused) void __show_regs(struct pt_regs *regs) { - unsigned long flags; - char buf[64]; + unsigned long flags = condition_codes(regs); - printk("CPU: %d %s (%s %.*s)\n", - smp_processor_id(), print_tainted(), init_utsname()->release, - (int)strcspn(init_utsname()->version, " "), - init_utsname()->version); + printk("CPU: %d\n", smp_processor_id()); print_symbol("PC is at %s\n", instruction_pointer(regs)); print_symbol("LR is at %s\n", regs->ARM_lr); - printk("pc : [<%08lx>] lr : [<%08lx>] psr: %08lx\n" + printk("pc : [<%08lx>] lr : [<%08lx>] %s\n" "sp : %08lx ip : %08lx fp : %08lx\n", - regs->ARM_pc, regs->ARM_lr, regs->ARM_cpsr, - regs->ARM_sp, regs->ARM_ip, regs->ARM_fp); + instruction_pointer(regs), + regs->ARM_lr, print_tainted(), regs->ARM_sp, + regs->ARM_ip, regs->ARM_fp); printk("r10: %08lx r9 : %08lx r8 : %08lx\n", regs->ARM_r10, regs->ARM_r9, regs->ARM_r8); @@ -222,40 +218,37 @@ void __show_regs(struct pt_regs *regs) printk("r3 : %08lx r2 : %08lx r1 : %08lx r0 : %08lx\n", regs->ARM_r3, regs->ARM_r2, regs->ARM_r1, regs->ARM_r0); - - flags = regs->ARM_cpsr; - buf[0] = flags & PSR_N_BIT ? 'N' : 'n'; - buf[1] = flags & PSR_Z_BIT ? 'Z' : 'z'; - buf[2] = flags & PSR_C_BIT ? 'C' : 'c'; - buf[3] = flags & PSR_V_BIT ? 'V' : 'v'; - buf[4] = '\0'; - - printk("Flags: %s IRQs o%s FIQs o%s Mode %s%s Segment %s\n", - buf, interrupts_enabled(regs) ? "n" : "ff", + printk("Flags: %c%c%c%c", + flags & PSR_N_BIT ? 'N' : 'n', + flags & PSR_Z_BIT ? 'Z' : 'z', + flags & PSR_C_BIT ? 'C' : 'c', + flags & PSR_V_BIT ? 'V' : 'v'); + printk(" IRQs o%s FIQs o%s Mode %s%s Segment %s\n", + interrupts_enabled(regs) ? "n" : "ff", fast_interrupts_enabled(regs) ? "n" : "ff", processor_modes[processor_mode(regs)], thumb_mode(regs) ? " (T)" : "", get_fs() == get_ds() ? "kernel" : "user"); -#ifdef CONFIG_CPU_CP15 +#if CONFIG_CPU_CP15 { unsigned int ctrl; - - buf[0] = '\0'; + __asm__ ( + " mrc p15, 0, %0, c1, c0\n" + : "=r" (ctrl)); + printk("Control: %04X\n", ctrl); + } #ifdef CONFIG_CPU_CP15_MMU - { - unsigned int transbase, dac; - asm("mrc p15, 0, %0, c2, c0\n\t" - "mrc p15, 0, %1, c3, c0\n" - : "=r" (transbase), "=r" (dac)); - snprintf(buf, sizeof(buf), " Table: %08x DAC: %08x", - transbase, dac); - } -#endif - asm("mrc p15, 0, %0, c1, c0\n" : "=r" (ctrl)); - - printk("Control: %08x%s\n", ctrl, buf); + { + unsigned int transbase, dac; + __asm__ ( + " mrc p15, 0, %0, c2, c0\n" + " mrc p15, 0, %1, c3, c0\n" + : "=r" (transbase), "=r" (dac)); + printk("Table: %08X DAC: %08X\n", + transbase, dac); } #endif +#endif } void show_regs(struct pt_regs * regs) diff --git a/trunk/arch/arm/kernel/setup.c b/trunk/arch/arm/kernel/setup.c index 650eac1bc0a6..0453dcc757b4 100644 --- a/trunk/arch/arm/kernel/setup.c +++ b/trunk/arch/arm/kernel/setup.c @@ -918,7 +918,7 @@ static int c_show(struct seq_file *m, void *v) if ((processor_id & 0x0008f000) == 0x00000000) { /* pre-ARM7 */ - seq_printf(m, "CPU part\t: %07x\n", processor_id >> 4); + seq_printf(m, "CPU part\t\t: %07x\n", processor_id >> 4); } else { if ((processor_id & 0x0008f000) == 0x00007000) { /* ARM7 */ diff --git a/trunk/arch/arm/kernel/stacktrace.c b/trunk/arch/arm/kernel/stacktrace.c index ae31deb2d065..398d0c0511eb 100644 --- a/trunk/arch/arm/kernel/stacktrace.c +++ b/trunk/arch/arm/kernel/stacktrace.c @@ -1,4 +1,3 @@ -#include #include #include @@ -13,7 +12,7 @@ int walk_stackframe(unsigned long fp, unsigned long low, unsigned long high, /* * Check current frame pointer is within bounds */ - if (fp < (low + 12) || fp + 4 >= high) + if ((fp - 12) < low || fp + 4 >= high) break; frame = (struct stackframe *)(fp - 12); @@ -31,7 +30,6 @@ int walk_stackframe(unsigned long fp, unsigned long low, unsigned long high, return 0; } -EXPORT_SYMBOL(walk_stackframe); #ifdef CONFIG_STACKTRACE struct stack_trace_data { diff --git a/trunk/arch/arm/kernel/sys_arm.c b/trunk/arch/arm/kernel/sys_arm.c index 4d25e49a14f7..3d4fcbc16276 100644 --- a/trunk/arch/arm/kernel/sys_arm.c +++ b/trunk/arch/arm/kernel/sys_arm.c @@ -320,7 +320,7 @@ int kernel_execve(const char *filename, char *const argv[], char *const envp[]) EXPORT_SYMBOL(kernel_execve); /* - * Since loff_t is a 64 bit type we avoid a lot of ABI hassle + * Since loff_t is a 64 bit type we avoid a lot of ABI hastle * with a different argument ordering. */ asmlinkage long sys_arm_fadvise64_64(int fd, int advice, @@ -328,3 +328,16 @@ asmlinkage long sys_arm_fadvise64_64(int fd, int advice, { return sys_fadvise64_64(fd, offset, len, advice); } + +/* + * Yet more syscall fsckage - we can't fit sys_sync_file_range's + * arguments into the available registers with EABI. So, let's + * create an ARM specific syscall for this which has _sane_ + * arguments. (This incidentally also has an ABI-independent + * argument layout.) + */ +asmlinkage long sys_arm_sync_file_range(int fd, unsigned int flags, + loff_t offset, loff_t nbytes) +{ + return sys_sync_file_range(fd, offset, nbytes, flags); +} diff --git a/trunk/arch/arm/kernel/traps.c b/trunk/arch/arm/kernel/traps.c index 237f4999b9a1..10ff36e4e414 100644 --- a/trunk/arch/arm/kernel/traps.c +++ b/trunk/arch/arm/kernel/traps.c @@ -181,7 +181,9 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk) void dump_stack(void) { +#ifdef CONFIG_DEBUG_ERRORS __backtrace(); +#endif } EXPORT_SYMBOL(dump_stack); @@ -202,24 +204,12 @@ void show_stack(struct task_struct *tsk, unsigned long *sp) barrier(); } -#ifdef CONFIG_PREEMPT -#define S_PREEMPT " PREEMPT" -#else -#define S_PREEMPT "" -#endif -#ifdef CONFIG_SMP -#define S_SMP " SMP" -#else -#define S_SMP "" -#endif - static void __die(const char *str, int err, struct thread_info *thread, struct pt_regs *regs) { struct task_struct *tsk = thread->task; static int die_counter; - printk("Internal error: %s: %x [#%d]" S_PREEMPT S_SMP "\n", - str, err, ++die_counter); + printk("Internal error: %s: %x [#%d]\n", str, err, ++die_counter); print_modules(); __show_regs(regs); printk("Process %s (pid: %d, stack limit = 0x%p)\n", @@ -242,8 +232,6 @@ NORET_TYPE void die(const char *str, struct pt_regs *regs, int err) { struct thread_info *thread = current_thread_info(); - oops_enter(); - console_verbose(); spin_lock_irq(&die_lock); bust_spinlocks(1); @@ -251,13 +239,9 @@ NORET_TYPE void die(const char *str, struct pt_regs *regs, int err) bust_spinlocks(0); spin_unlock_irq(&die_lock); - if (in_interrupt()) - panic("Fatal exception in interrupt"); - if (panic_on_oops) panic("Fatal exception"); - oops_exit(); do_exit(SIGSEGV); } diff --git a/trunk/arch/arm/kernel/vmlinux.lds.S b/trunk/arch/arm/kernel/vmlinux.lds.S index 2b7a8f5d8cf2..e4156e7868ce 100644 --- a/trunk/arch/arm/kernel/vmlinux.lds.S +++ b/trunk/arch/arm/kernel/vmlinux.lds.S @@ -90,7 +90,7 @@ SECTIONS __exception_text_start = .; *(.exception.text) __exception_text_end = .; - TEXT_TEXT + *(.text) SCHED_TEXT LOCK_TEXT #ifdef CONFIG_MMU @@ -158,7 +158,7 @@ SECTIONS /* * and the usual data section */ - DATA_DATA + *(.data) CONSTRUCTORS _edata = .; diff --git a/trunk/arch/arm/lib/bitops.h b/trunk/arch/arm/lib/bitops.h index 2e787d40d599..542251021744 100644 --- a/trunk/arch/arm/lib/bitops.h +++ b/trunk/arch/arm/lib/bitops.h @@ -47,7 +47,7 @@ * @store: store instruction * * Note: we can trivially conditionalise the store instruction - * to avoid dirtying the data cache. + * to avoid dirting the data cache. */ .macro testop, instr, store add r1, r1, r0, lsr #3 diff --git a/trunk/arch/arm/mach-at91/board-carmeva.c b/trunk/arch/arm/mach-at91/board-carmeva.c index 76ec856cd4f9..b4518619063a 100644 --- a/trunk/arch/arm/mach-at91/board-carmeva.c +++ b/trunk/arch/arm/mach-at91/board-carmeva.c @@ -79,7 +79,7 @@ static struct at91_udc_data __initdata carmeva_udc_data = { .pullup_pin = AT91_PIN_PD9, }; -/* FIXME: user dependant */ +/* FIXME: user dependend */ // static struct at91_cf_data __initdata carmeva_cf_data = { // .det_pin = AT91_PIN_PB0, // .rst_pin = AT91_PIN_PC5, @@ -100,17 +100,17 @@ static struct spi_board_info carmeva_spi_devices[] = { .chip_select = 0, .max_speed_hz = 10 * 1000 * 1000, }, - { /* User accessible spi - cs1 (250KHz) */ + { /* User accessable spi - cs1 (250KHz) */ .modalias = "spi-cs1", .chip_select = 1, .max_speed_hz = 250 * 1000, }, - { /* User accessible spi - cs2 (1MHz) */ + { /* User accessable spi - cs2 (1MHz) */ .modalias = "spi-cs2", .chip_select = 2, .max_speed_hz = 1 * 1000 * 1000, }, - { /* User accessible spi - cs3 (10MHz) */ + { /* User accessable spi - cs3 (10MHz) */ .modalias = "spi-cs3", .chip_select = 3, .max_speed_hz = 10 * 1000 * 1000, diff --git a/trunk/arch/arm/mach-at91/board-dk.c b/trunk/arch/arm/mach-at91/board-dk.c index af497896a96c..6043c38c0a9e 100644 --- a/trunk/arch/arm/mach-at91/board-dk.c +++ b/trunk/arch/arm/mach-at91/board-dk.c @@ -132,7 +132,7 @@ static struct mtd_partition __initdata dk_nand_partition[] = { }, }; -static struct mtd_partition * __init nand_partitions(int size, int *num_partitions) +static struct mtd_partition *nand_partitions(int size, int *num_partitions) { *num_partitions = ARRAY_SIZE(dk_nand_partition); return dk_nand_partition; diff --git a/trunk/arch/arm/mach-at91/board-kb9202.c b/trunk/arch/arm/mach-at91/board-kb9202.c index 7d9b1a278fd6..76f6e1e553ea 100644 --- a/trunk/arch/arm/mach-at91/board-kb9202.c +++ b/trunk/arch/arm/mach-at91/board-kb9202.c @@ -96,7 +96,7 @@ static struct mtd_partition __initdata kb9202_nand_partition[] = { }, }; -static struct mtd_partition * __init nand_partitions(int size, int *num_partitions) +static struct mtd_partition *nand_partitions(int size, int *num_partitions) { *num_partitions = ARRAY_SIZE(kb9202_nand_partition); return kb9202_nand_partition; diff --git a/trunk/arch/arm/mach-at91/board-sam9261ek.c b/trunk/arch/arm/mach-at91/board-sam9261ek.c index 26ca8ab3f62a..1f0c8a400b3a 100644 --- a/trunk/arch/arm/mach-at91/board-sam9261ek.c +++ b/trunk/arch/arm/mach-at91/board-sam9261ek.c @@ -178,7 +178,7 @@ static struct mtd_partition __initdata ek_nand_partition[] = { }, }; -static struct mtd_partition * __init nand_partitions(int size, int *num_partitions) +static struct mtd_partition *nand_partitions(int size, int *num_partitions) { *num_partitions = ARRAY_SIZE(ek_nand_partition); return ek_nand_partition; diff --git a/trunk/arch/arm/mach-at91/board-sam9263ek.c b/trunk/arch/arm/mach-at91/board-sam9263ek.c index c164c8e58ae6..f57458559fb6 100644 --- a/trunk/arch/arm/mach-at91/board-sam9263ek.c +++ b/trunk/arch/arm/mach-at91/board-sam9263ek.c @@ -180,7 +180,7 @@ static struct mtd_partition __initdata ek_nand_partition[] = { }, }; -static struct mtd_partition * __init nand_partitions(int size, int *num_partitions) +static struct mtd_partition *nand_partitions(int size, int *num_partitions) { *num_partitions = ARRAY_SIZE(ek_nand_partition); return ek_nand_partition; diff --git a/trunk/arch/arm/mach-at91/board-sam9rlek.c b/trunk/arch/arm/mach-at91/board-sam9rlek.c index 9b61320f295a..30c79aca84d4 100644 --- a/trunk/arch/arm/mach-at91/board-sam9rlek.c +++ b/trunk/arch/arm/mach-at91/board-sam9rlek.c @@ -87,7 +87,7 @@ static struct mtd_partition __initdata ek_nand_partition[] = { }, }; -static struct mtd_partition * __init nand_partitions(int size, int *num_partitions) +static struct mtd_partition *nand_partitions(int size, int *num_partitions) { *num_partitions = ARRAY_SIZE(ek_nand_partition); return ek_nand_partition; diff --git a/trunk/arch/arm/mach-at91/clock.c b/trunk/arch/arm/mach-at91/clock.c index 848efb2a4ebf..06c9a0507d0d 100644 --- a/trunk/arch/arm/mach-at91/clock.c +++ b/trunk/arch/arm/mach-at91/clock.c @@ -364,14 +364,19 @@ static int at91_clk_show(struct seq_file *s, void *unused) { u32 scsr, pcsr, sr; struct clk *clk; + unsigned i; seq_printf(s, "SCSR = %8x\n", scsr = at91_sys_read(AT91_PMC_SCSR)); seq_printf(s, "PCSR = %8x\n", pcsr = at91_sys_read(AT91_PMC_PCSR)); + seq_printf(s, "MOR = %8x\n", at91_sys_read(AT91_CKGR_MOR)); seq_printf(s, "MCFR = %8x\n", at91_sys_read(AT91_CKGR_MCFR)); seq_printf(s, "PLLA = %8x\n", at91_sys_read(AT91_CKGR_PLLAR)); seq_printf(s, "PLLB = %8x\n", at91_sys_read(AT91_CKGR_PLLBR)); + seq_printf(s, "MCKR = %8x\n", at91_sys_read(AT91_PMC_MCKR)); + for (i = 0; i < 4; i++) + seq_printf(s, "PCK%d = %8x\n", i, at91_sys_read(AT91_PMC_PCKR(i))); seq_printf(s, "SR = %8x\n", sr = at91_sys_read(AT91_PMC_SR)); seq_printf(s, "\n"); diff --git a/trunk/arch/arm/mach-at91/pm.c b/trunk/arch/arm/mach-at91/pm.c index ddf9184d561d..ff8db29e989e 100644 --- a/trunk/arch/arm/mach-at91/pm.c +++ b/trunk/arch/arm/mach-at91/pm.c @@ -53,7 +53,7 @@ static suspend_state_t target_state; /* * Called after processes are frozen, but before we shutdown devices. */ -static int at91_pm_set_target(suspend_state_t state) +static int at91_pm_prepare(suspend_state_t state) { target_state = state; return 0; @@ -76,11 +76,12 @@ static int at91_pm_verify_clocks(void) pr_debug("AT91: PM - Suspend-to-RAM with USB still active\n"); return 0; } - } else if (cpu_is_at91sam9260() || cpu_is_at91sam9261() || cpu_is_at91sam9263()) { - if ((scsr & (AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP)) != 0) { - pr_debug("AT91: PM - Suspend-to-RAM with USB still active\n"); - return 0; - } + } else if (cpu_is_at91sam9260()) { +#warning "Check SAM9260 USB clocks" + } else if (cpu_is_at91sam9261()) { +#warning "Check SAM9261 USB clocks" + } else if (cpu_is_at91sam9263()) { +#warning "Check SAM9263 USB clocks" } #ifdef CONFIG_AT91_PROGRAMMABLE_CLOCKS @@ -201,7 +202,7 @@ static int at91_pm_enter(suspend_state_t state) static struct pm_ops at91_pm_ops ={ .valid = at91_pm_valid_state, - .set_target = at91_pm_set_target, + .prepare = at91_pm_prepare, .enter = at91_pm_enter, }; diff --git a/trunk/arch/arm/mach-footbridge/cats-pci.c b/trunk/arch/arm/mach-footbridge/cats-pci.c index 35eb232a649a..4f984fde7375 100644 --- a/trunk/arch/arm/mach-footbridge/cats-pci.c +++ b/trunk/arch/arm/mach-footbridge/cats-pci.c @@ -45,7 +45,7 @@ static struct hw_pci cats_pci __initdata = { .postinit = dc21285_postinit, }; -static int __init cats_pci_init(void) +static int cats_pci_init(void) { if (machine_is_cats()) pci_common_init(&cats_pci); diff --git a/trunk/arch/arm/mach-h720x/cpu-h7202.c b/trunk/arch/arm/mach-h720x/cpu-h7202.c index 0a1a25fb8ba8..82e420d6fd19 100644 --- a/trunk/arch/arm/mach-h720x/cpu-h7202.c +++ b/trunk/arch/arm/mach-h720x/cpu-h7202.c @@ -143,7 +143,7 @@ h7202_timer_interrupt(int irq, void *dev_id) } /* - * mask multiplexed timer IRQs + * mask multiplexed timer irq's */ static void inline mask_timerx_irq (u32 irq) { @@ -153,7 +153,7 @@ static void inline mask_timerx_irq (u32 irq) } /* - * unmask multiplexed timer IRQs + * unmask multiplexed timer irq's */ static void inline unmask_timerx_irq (u32 irq) { diff --git a/trunk/arch/arm/mach-imx/cpufreq.c b/trunk/arch/arm/mach-imx/cpufreq.c index 467d899fbe75..7e70e0b0b989 100644 --- a/trunk/arch/arm/mach-imx/cpufreq.c +++ b/trunk/arch/arm/mach-imx/cpufreq.c @@ -245,7 +245,7 @@ static int imx_set_target(struct cpufreq_policy *policy, if(mpctl0) { CSCR |= CSCR_MPLL_RESTART; - /* Wait until MPLL is stabilized */ + /* Wait until MPLL is stablized */ while( CSCR & CSCR_MPLL_RESTART ); imx_set_async_mode(); diff --git a/trunk/arch/arm/mach-imx/dma.c b/trunk/arch/arm/mach-imx/dma.c index bc6fb02d213b..6d50d85a618c 100644 --- a/trunk/arch/arm/mach-imx/dma.c +++ b/trunk/arch/arm/mach-imx/dma.c @@ -131,7 +131,7 @@ imx_dma_setup_sg_base(imx_dmach_t dma_ch, * The function setups DMA channel source and destination addresses for transfer * specified by provided parameters. The scatter-gather emulation is disabled, * because linear data block - * form the physical address range is transferred. + * form the physical address range is transfered. * Return value: if incorrect parameters are provided -%EINVAL. * Zero indicates success. */ @@ -192,7 +192,7 @@ imx_dma_setup_single(imx_dmach_t dma_ch, dma_addr_t dma_address, * @dmamode: DMA transfer mode, %DMA_MODE_READ from the device to the memory * or %DMA_MODE_WRITE from memory to the device * - * The function sets up DMA channel state and registers to be ready for transfer + * The function setups DMA channel state and registers to be ready for transfer * specified by provided parameters. The scatter-gather emulation is set up * according to the parameters. * @@ -212,7 +212,7 @@ imx_dma_setup_single(imx_dmach_t dma_ch, dma_addr_t dma_address, * * %CCR_SMOD_LINEAR | %CCR_SSIZ_32 | %CCR_DMOD_FIFO | %CCR_DSIZ_x * - * Be careful here and do not mistakenly mix source and target device + * Be carefull there and do not mistakenly mix source and target device * port sizes constants, they are really different: * %CCR_SSIZ_8, %CCR_SSIZ_16, %CCR_SSIZ_32, * %CCR_DSIZ_8, %CCR_DSIZ_16, %CCR_DSIZ_32 @@ -495,7 +495,7 @@ static irqreturn_t dma_err_handler(int irq, void *dev_id) /* * The cleaning of @sg field would be questionable * there, because its value can help to compute - * remaining/transferred bytes count in the handler + * remaining/transfered bytes count in the handler */ /*imx_dma_channels[i].sg = NULL;*/ diff --git a/trunk/arch/arm/mach-imx/generic.c b/trunk/arch/arm/mach-imx/generic.c index 1c474cf709ca..7a7fa51ec62c 100644 --- a/trunk/arch/arm/mach-imx/generic.c +++ b/trunk/arch/arm/mach-imx/generic.c @@ -201,6 +201,7 @@ void __init imx_set_mmc_info(struct imxmmc_platform_data *info) { imx_mmc_device.dev.platform_data = info; } +EXPORT_SYMBOL(imx_set_mmc_info); static struct imxfb_mach_info imx_fb_info; diff --git a/trunk/arch/arm/mach-integrator/Makefile b/trunk/arch/arm/mach-integrator/Makefile index 158daaf9e3b0..ebb255bdce8a 100644 --- a/trunk/arch/arm/mach-integrator/Makefile +++ b/trunk/arch/arm/mach-integrator/Makefile @@ -12,3 +12,4 @@ obj-$(CONFIG_LEDS) += leds.o obj-$(CONFIG_PCI) += pci_v3.o pci.o obj-$(CONFIG_CPU_FREQ_INTEGRATOR) += cpu.o obj-$(CONFIG_INTEGRATOR_IMPD1) += impd1.o +obj-$(CONFIG_SMP) += platsmp.o headsmp.o diff --git a/trunk/arch/arm/mach-integrator/core.c b/trunk/arch/arm/mach-integrator/core.c index e9c82deb791d..897c21c2fb5b 100644 --- a/trunk/arch/arm/mach-integrator/core.c +++ b/trunk/arch/arm/mach-integrator/core.c @@ -257,7 +257,23 @@ integrator_timer_interrupt(int irq, void *dev_id) */ writel(1, TIMER1_VA_BASE + TIMER_INTCLR); - timer_tick(); + /* + * the clock tick routines are only processed on the + * primary CPU + */ + if (hard_smp_processor_id() == 0) { + timer_tick(); +#ifdef CONFIG_SMP + smp_send_timer(); +#endif + } + +#ifdef CONFIG_SMP + /* + * this is the ARM equivalent of the APIC timer interrupt + */ + update_process_times(user_mode(get_irq_regs())); +#endif /* CONFIG_SMP */ write_sequnlock(&xtime_lock); diff --git a/trunk/arch/arm/mach-integrator/headsmp.S b/trunk/arch/arm/mach-integrator/headsmp.S new file mode 100644 index 000000000000..ceaa88e30d70 --- /dev/null +++ b/trunk/arch/arm/mach-integrator/headsmp.S @@ -0,0 +1,37 @@ +/* + * linux/arch/arm/mach-integrator/headsmp.S + * + * Copyright (c) 2003 ARM Limited + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include + + __INIT + +/* + * Integrator specific entry point for secondary CPUs. This provides + * a "holding pen" into which all secondary cores are held until we're + * ready for them to initialise. + */ +ENTRY(integrator_secondary_startup) + adr r4, 1f + ldmia r4, {r5, r6} + sub r4, r4, r5 + ldr r6, [r6, r4] +pen: ldr r7, [r6] + cmp r7, r0 + bne pen + + /* + * we've been released from the holding pen: secondary_stack + * should now contain the SVC stack for this core + */ + b secondary_startup + +1: .long . + .long phys_pen_release diff --git a/trunk/arch/arm/mach-integrator/pci_v3.c b/trunk/arch/arm/mach-integrator/pci_v3.c index d4d8134ce567..af9ebccac7c1 100644 --- a/trunk/arch/arm/mach-integrator/pci_v3.c +++ b/trunk/arch/arm/mach-integrator/pci_v3.c @@ -33,7 +33,6 @@ #include #include #include -#include #include diff --git a/trunk/arch/arm/mach-integrator/platsmp.c b/trunk/arch/arm/mach-integrator/platsmp.c new file mode 100644 index 000000000000..613b841a10f3 --- /dev/null +++ b/trunk/arch/arm/mach-integrator/platsmp.c @@ -0,0 +1,204 @@ +/* + * linux/arch/arm/mach-cintegrator/platsmp.c + * + * Copyright (C) 2002 ARM Ltd. + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +extern void integrator_secondary_startup(void); + +/* + * control for which core is the next to come out of the secondary + * boot "holding pen" + */ +volatile int __cpuinitdata pen_release = -1; +unsigned long __cpuinitdata phys_pen_release = 0; + +static DEFINE_SPINLOCK(boot_lock); + +void __cpuinit platform_secondary_init(unsigned int cpu) +{ + /* + * the primary core may have used a "cross call" soft interrupt + * to get this processor out of WFI in the BootMonitor - make + * sure that we are no longer being sent this soft interrupt + */ + smp_cross_call_done(cpumask_of_cpu(cpu)); + + /* + * if any interrupts are already enabled for the primary + * core (e.g. timer irq), then they will not have been enabled + * for us: do so + */ + secondary_scan_irqs(); + + /* + * let the primary processor know we're out of the + * pen, then head off into the C entry point + */ + pen_release = -1; + + /* + * Synchronise with the boot thread. + */ + spin_lock(&boot_lock); + spin_unlock(&boot_lock); +} + +int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle) +{ + unsigned long timeout; + + /* + * set synchronisation state between this boot processor + * and the secondary one + */ + spin_lock(&boot_lock); + + /* + * The secondary processor is waiting to be released from + * the holding pen - release it, then wait for it to flag + * that it has been released by resetting pen_release. + * + * Note that "pen_release" is the hardware CPU ID, whereas + * "cpu" is Linux's internal ID. + */ + pen_release = cpu; + flush_cache_all(); + + /* + * XXX + * + * This is a later addition to the booting protocol: the + * bootMonitor now puts secondary cores into WFI, so + * poke_milo() no longer gets the cores moving; we need + * to send a soft interrupt to wake the secondary core. + * Use smp_cross_call() for this, since there's little + * point duplicating the code here + */ + smp_cross_call(cpumask_of_cpu(cpu)); + + timeout = jiffies + (1 * HZ); + while (time_before(jiffies, timeout)) { + if (pen_release == -1) + break; + + udelay(10); + } + + /* + * now the secondary core is starting up let it run its + * calibrations, then wait for it to finish + */ + spin_unlock(&boot_lock); + + return pen_release != -1 ? -ENOSYS : 0; +} + +static void __init poke_milo(void) +{ + extern void secondary_startup(void); + + /* nobody is to be released from the pen yet */ + pen_release = -1; + + phys_pen_release = virt_to_phys(&pen_release); + + /* + * write the address of secondary startup into the system-wide + * flags register, then clear the bottom two bits, which is what + * BootMonitor is waiting for + */ +#if 1 +#define CINTEGRATOR_HDR_FLAGSS_OFFSET 0x30 + __raw_writel(virt_to_phys(integrator_secondary_startup), + (IO_ADDRESS(INTEGRATOR_HDR_BASE) + + CINTEGRATOR_HDR_FLAGSS_OFFSET)); +#define CINTEGRATOR_HDR_FLAGSC_OFFSET 0x34 + __raw_writel(3, + (IO_ADDRESS(INTEGRATOR_HDR_BASE) + + CINTEGRATOR_HDR_FLAGSC_OFFSET)); +#endif + + mb(); +} + +/* + * Initialise the CPU possible map early - this describes the CPUs + * which may be present or become present in the system. + */ +void __init smp_init_cpus(void) +{ + unsigned int i, ncores = get_core_count(); + + for (i = 0; i < ncores; i++) + cpu_set(i, cpu_possible_map); +} + +void __init smp_prepare_cpus(unsigned int max_cpus) +{ + unsigned int ncores = get_core_count(); + unsigned int cpu = smp_processor_id(); + int i; + + /* sanity check */ + if (ncores == 0) { + printk(KERN_ERR + "Integrator/CP: strange CM count of 0? Default to 1\n"); + + ncores = 1; + } + + if (ncores > NR_CPUS) { + printk(KERN_WARNING + "Integrator/CP: no. of cores (%d) greater than configured " + "maximum of %d - clipping\n", + ncores, NR_CPUS); + ncores = NR_CPUS; + } + + /* + * start with some more config for the Boot CPU, now that + * the world is a bit more alive (which was not the case + * when smp_prepare_boot_cpu() was called) + */ + smp_store_cpu_info(cpu); + + /* + * are we trying to boot more cores than exist? + */ + if (max_cpus > ncores) + max_cpus = ncores; + + /* + * Initialise the present map, which describes the set of CPUs + * actually populated at the present time. + */ + for (i = 0; i < max_cpus; i++) + cpu_set(i, cpu_present_map); + + /* + * Do we need any more CPUs? If so, then let them know where + * to start. Note that, on modern versions of MILO, the "poke" + * doesn't actually do anything until each individual core is + * sent a soft interrupt to get it out of WFI + */ + if (max_cpus > 1) + poke_milo(); +} diff --git a/trunk/arch/arm/mach-iop13xx/irq.c b/trunk/arch/arm/mach-iop13xx/irq.c index 69f07b25b3c9..5791addd436b 100644 --- a/trunk/arch/arm/mach-iop13xx/irq.c +++ b/trunk/arch/arm/mach-iop13xx/irq.c @@ -30,65 +30,77 @@ /* INTCTL0 CP6 R0 Page 4 */ -static u32 read_intctl_0(void) +static inline u32 read_intctl_0(void) { u32 val; asm volatile("mrc p6, 0, %0, c0, c4, 0":"=r" (val)); return val; } -static void write_intctl_0(u32 val) +static inline void write_intctl_0(u32 val) { asm volatile("mcr p6, 0, %0, c0, c4, 0"::"r" (val)); } /* INTCTL1 CP6 R1 Page 4 */ -static u32 read_intctl_1(void) +static inline u32 read_intctl_1(void) { u32 val; asm volatile("mrc p6, 0, %0, c1, c4, 0":"=r" (val)); return val; } -static void write_intctl_1(u32 val) +static inline void write_intctl_1(u32 val) { asm volatile("mcr p6, 0, %0, c1, c4, 0"::"r" (val)); } /* INTCTL2 CP6 R2 Page 4 */ -static u32 read_intctl_2(void) +static inline u32 read_intctl_2(void) { u32 val; asm volatile("mrc p6, 0, %0, c2, c4, 0":"=r" (val)); return val; } -static void write_intctl_2(u32 val) +static inline void write_intctl_2(u32 val) { asm volatile("mcr p6, 0, %0, c2, c4, 0"::"r" (val)); } /* INTCTL3 CP6 R3 Page 4 */ -static u32 read_intctl_3(void) +static inline u32 read_intctl_3(void) { u32 val; asm volatile("mrc p6, 0, %0, c3, c4, 0":"=r" (val)); return val; } -static void write_intctl_3(u32 val) +static inline void write_intctl_3(u32 val) { asm volatile("mcr p6, 0, %0, c3, c4, 0"::"r" (val)); } /* INTSTR0 CP6 R0 Page 5 */ -static void write_intstr_0(u32 val) +static inline u32 read_intstr_0(void) +{ + u32 val; + asm volatile("mrc p6, 0, %0, c0, c5, 0":"=r" (val)); + return val; +} +static inline void write_intstr_0(u32 val) { asm volatile("mcr p6, 0, %0, c0, c5, 0"::"r" (val)); } /* INTSTR1 CP6 R1 Page 5 */ +static inline u32 read_intstr_1(void) +{ + u32 val; + asm volatile("mrc p6, 0, %0, c1, c5, 0":"=r" (val)); + return val; +} static void write_intstr_1(u32 val) { asm volatile("mcr p6, 0, %0, c1, c5, 0"::"r" (val)); @@ -96,6 +108,12 @@ static void write_intstr_1(u32 val) /* INTSTR2 CP6 R2 Page 5 */ +static inline u32 read_intstr_2(void) +{ + u32 val; + asm volatile("mrc p6, 0, %0, c2, c5, 0":"=r" (val)); + return val; +} static void write_intstr_2(u32 val) { asm volatile("mcr p6, 0, %0, c2, c5, 0"::"r" (val)); @@ -103,6 +121,12 @@ static void write_intstr_2(u32 val) /* INTSTR3 CP6 R3 Page 5 */ +static inline u32 read_intstr_3(void) +{ + u32 val; + asm volatile("mrc p6, 0, %0, c3, c5, 0":"=r" (val)); + return val; +} static void write_intstr_3(u32 val) { asm volatile("mcr p6, 0, %0, c3, c5, 0"::"r" (val)); @@ -110,6 +134,12 @@ static void write_intstr_3(u32 val) /* INTBASE CP6 R0 Page 2 */ +static inline u32 read_intbase(void) +{ + u32 val; + asm volatile("mrc p6, 0, %0, c0, c2, 0":"=r" (val)); + return val; +} static void write_intbase(u32 val) { asm volatile("mcr p6, 0, %0, c0, c2, 0"::"r" (val)); @@ -117,6 +147,12 @@ static void write_intbase(u32 val) /* INTSIZE CP6 R2 Page 2 */ +static inline u32 read_intsize(void) +{ + u32 val; + asm volatile("mrc p6, 0, %0, c2, c2, 0":"=r" (val)); + return val; +} static void write_intsize(u32 val) { asm volatile("mcr p6, 0, %0, c2, c2, 0"::"r" (val)); diff --git a/trunk/arch/arm/mach-iop13xx/msi.c b/trunk/arch/arm/mach-iop13xx/msi.c index 63ef1124ca5c..2d2369302220 100644 --- a/trunk/arch/arm/mach-iop13xx/msi.c +++ b/trunk/arch/arm/mach-iop13xx/msi.c @@ -30,52 +30,52 @@ static DECLARE_BITMAP(msi_irq_in_use, IOP13XX_NUM_MSI_IRQS); /* IMIPR0 CP6 R8 Page 1 */ -static u32 read_imipr_0(void) +static inline u32 read_imipr_0(void) { u32 val; asm volatile("mrc p6, 0, %0, c8, c1, 0":"=r" (val)); return val; } -static void write_imipr_0(u32 val) +static inline void write_imipr_0(u32 val) { asm volatile("mcr p6, 0, %0, c8, c1, 0"::"r" (val)); } /* IMIPR1 CP6 R9 Page 1 */ -static u32 read_imipr_1(void) +static inline u32 read_imipr_1(void) { u32 val; asm volatile("mrc p6, 0, %0, c9, c1, 0":"=r" (val)); return val; } -static void write_imipr_1(u32 val) +static inline void write_imipr_1(u32 val) { asm volatile("mcr p6, 0, %0, c9, c1, 0"::"r" (val)); } /* IMIPR2 CP6 R10 Page 1 */ -static u32 read_imipr_2(void) +static inline u32 read_imipr_2(void) { u32 val; asm volatile("mrc p6, 0, %0, c10, c1, 0":"=r" (val)); return val; } -static void write_imipr_2(u32 val) +static inline void write_imipr_2(u32 val) { asm volatile("mcr p6, 0, %0, c10, c1, 0"::"r" (val)); } /* IMIPR3 CP6 R11 Page 1 */ -static u32 read_imipr_3(void) +static inline u32 read_imipr_3(void) { u32 val; asm volatile("mrc p6, 0, %0, c11, c1, 0":"=r" (val)); return val; } -static void write_imipr_3(u32 val) +static inline void write_imipr_3(u32 val) { asm volatile("mcr p6, 0, %0, c11, c1, 0"::"r" (val)); } @@ -190,5 +190,5 @@ int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc) write_msi_msg(irq, &msg); set_irq_chip_and_handler(irq, &iop13xx_msi_chip, handle_simple_irq); - return 0; + return irq; } diff --git a/trunk/arch/arm/mach-iop13xx/pci.c b/trunk/arch/arm/mach-iop13xx/pci.c index 9d63d7f260ca..1c9e94c38b7e 100644 --- a/trunk/arch/arm/mach-iop13xx/pci.c +++ b/trunk/arch/arm/mach-iop13xx/pci.c @@ -19,11 +19,10 @@ #include #include -#include + #include #include #include -#include #include #include @@ -145,7 +144,7 @@ void iop13xx_map_pci_memory(void) } } -static int iop13xx_atu_function(int atu) +static inline int iop13xx_atu_function(int atu) { int func = 0; /* the function number depends on the value of the @@ -260,7 +259,7 @@ static int iop13xx_atux_pci_status(int clear) * data. Note that the data dependency on %0 encourages an abort * to be detected before we return. */ -static u32 iop13xx_atux_read(unsigned long addr) +static inline u32 iop13xx_atux_read(unsigned long addr) { u32 val; @@ -388,7 +387,7 @@ static int iop13xx_atue_pci_status(int clear) return err; } -static int +static inline int __init iop13xx_pcie_map_irq(struct pci_dev *dev, u8 idsel, u8 pin) { WARN_ON(idsel != 0); @@ -402,7 +401,7 @@ iop13xx_pcie_map_irq(struct pci_dev *dev, u8 idsel, u8 pin) } } -static u32 iop13xx_atue_read(unsigned long addr) +static inline u32 iop13xx_atue_read(unsigned long addr) { u32 val; @@ -990,7 +989,7 @@ void __init iop13xx_pci_init(void) "imprecise external abort"); } -/* initialize the pci memory space. handle any combination of +/* intialize the pci memory space. handle any combination of * atue and atux enabled/disabled */ int iop13xx_pci_setup(int nr, struct pci_sys_data *sys) diff --git a/trunk/arch/arm/mach-iop32x/glantank.c b/trunk/arch/arm/mach-iop32x/glantank.c index 5776fd884115..45f4f13ae11b 100644 --- a/trunk/arch/arm/mach-iop32x/glantank.c +++ b/trunk/arch/arm/mach-iop32x/glantank.c @@ -75,7 +75,7 @@ void __init glantank_map_io(void) #define INTC IRQ_IOP32X_XINT2 #define INTD IRQ_IOP32X_XINT3 -static int __init +static inline int __init glantank_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { static int pci_irq_table[][4] = { diff --git a/trunk/arch/arm/mach-iop32x/iq31244.c b/trunk/arch/arm/mach-iop32x/iq31244.c index d4eefbea1fe6..7b21c6e13e59 100644 --- a/trunk/arch/arm/mach-iop32x/iq31244.c +++ b/trunk/arch/arm/mach-iop32x/iq31244.c @@ -104,7 +104,7 @@ void __init iq31244_map_io(void) /* * EP80219/IQ31244 PCI. */ -static int __init +static inline int __init ep80219_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { int irq; @@ -140,7 +140,7 @@ static struct hw_pci ep80219_pci __initdata = { .map_irq = ep80219_pci_map_irq, }; -static int __init +static inline int __init iq31244_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { int irq; diff --git a/trunk/arch/arm/mach-iop32x/iq80321.c b/trunk/arch/arm/mach-iop32x/iq80321.c index 8d9f49164a84..bc25fb91e7b9 100644 --- a/trunk/arch/arm/mach-iop32x/iq80321.c +++ b/trunk/arch/arm/mach-iop32x/iq80321.c @@ -72,7 +72,7 @@ void __init iq80321_map_io(void) /* * IQ80321 PCI. */ -static int __init +static inline int __init iq80321_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { int irq; diff --git a/trunk/arch/arm/mach-iop32x/irq.c b/trunk/arch/arm/mach-iop32x/irq.c index c971171c2905..82598dc18d80 100644 --- a/trunk/arch/arm/mach-iop32x/irq.c +++ b/trunk/arch/arm/mach-iop32x/irq.c @@ -21,12 +21,12 @@ static u32 iop32x_mask; -static void intctl_write(u32 val) +static inline void intctl_write(u32 val) { asm volatile("mcr p6, 0, %0, c0, c0, 0" : : "r" (val)); } -static void intstr_write(u32 val) +static inline void intstr_write(u32 val) { asm volatile("mcr p6, 0, %0, c4, c0, 0" : : "r" (val)); } diff --git a/trunk/arch/arm/mach-iop32x/n2100.c b/trunk/arch/arm/mach-iop32x/n2100.c index d55005d64781..5f07344d96f3 100644 --- a/trunk/arch/arm/mach-iop32x/n2100.c +++ b/trunk/arch/arm/mach-iop32x/n2100.c @@ -76,7 +76,7 @@ void __init n2100_map_io(void) /* * N2100 PCI. */ -static int __init +static inline int __init n2100_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { int irq; diff --git a/trunk/arch/arm/mach-iop33x/iq80331.c b/trunk/arch/arm/mach-iop33x/iq80331.c index 2b063180687a..376c932830be 100644 --- a/trunk/arch/arm/mach-iop33x/iq80331.c +++ b/trunk/arch/arm/mach-iop33x/iq80331.c @@ -55,7 +55,7 @@ static struct sys_timer iq80331_timer = { /* * IQ80331 PCI. */ -static int __init +static inline int __init iq80331_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { int irq; diff --git a/trunk/arch/arm/mach-iop33x/iq80332.c b/trunk/arch/arm/mach-iop33x/iq80332.c index 7889ce3cb08e..58c81496c6f6 100644 --- a/trunk/arch/arm/mach-iop33x/iq80332.c +++ b/trunk/arch/arm/mach-iop33x/iq80332.c @@ -55,7 +55,7 @@ static struct sys_timer iq80332_timer = { /* * IQ80332 PCI. */ -static int __init +static inline int __init iq80332_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) { int irq; diff --git a/trunk/arch/arm/mach-iop33x/irq.c b/trunk/arch/arm/mach-iop33x/irq.c index f09dd054b9c0..c65ea78a2427 100644 --- a/trunk/arch/arm/mach-iop33x/irq.c +++ b/trunk/arch/arm/mach-iop33x/irq.c @@ -22,32 +22,32 @@ static u32 iop33x_mask0; static u32 iop33x_mask1; -static void intctl0_write(u32 val) +static inline void intctl0_write(u32 val) { asm volatile("mcr p6, 0, %0, c0, c0, 0" : : "r" (val)); } -static void intctl1_write(u32 val) +static inline void intctl1_write(u32 val) { asm volatile("mcr p6, 0, %0, c1, c0, 0" : : "r" (val)); } -static void intstr0_write(u32 val) +static inline void intstr0_write(u32 val) { asm volatile("mcr p6, 0, %0, c2, c0, 0" : : "r" (val)); } -static void intstr1_write(u32 val) +static inline void intstr1_write(u32 val) { asm volatile("mcr p6, 0, %0, c3, c0, 0" : : "r" (val)); } -static void intbase_write(u32 val) +static inline void intbase_write(u32 val) { asm volatile("mcr p6, 0, %0, c12, c0, 0" : : "r" (val)); } -static void intsize_write(u32 val) +static inline void intsize_write(u32 val) { asm volatile("mcr p6, 0, %0, c13, c0, 0" : : "r" (val)); } diff --git a/trunk/arch/arm/mach-ixp2000/enp2611.c b/trunk/arch/arm/mach-ixp2000/enp2611.c index 9c49435d42c3..500e997ba7a4 100644 --- a/trunk/arch/arm/mach-ixp2000/enp2611.c +++ b/trunk/arch/arm/mach-ixp2000/enp2611.c @@ -198,7 +198,7 @@ subsys_initcall(enp2611_pci_init); /************************************************************************* - * ENP-2611 Machine Initialization + * ENP-2611 Machine Intialization *************************************************************************/ static struct flash_platform_data enp2611_flash_platform_data = { .map_name = "cfi_probe", diff --git a/trunk/arch/arm/mach-ixp2000/ixdp2400.c b/trunk/arch/arm/mach-ixp2000/ixdp2400.c index ce7c15c73004..0fdd03ab36e6 100644 --- a/trunk/arch/arm/mach-ixp2000/ixdp2400.c +++ b/trunk/arch/arm/mach-ixp2000/ixdp2400.c @@ -164,7 +164,7 @@ int __init ixdp2400_pci_init(void) subsys_initcall(ixdp2400_pci_init); -void __init ixdp2400_init_irq(void) +void ixdp2400_init_irq(void) { ixdp2x00_init_irq(IXDP2400_CPLD_INT_STAT, IXDP2400_CPLD_INT_MASK, IXDP2400_NR_IRQS); } diff --git a/trunk/arch/arm/mach-ixp2000/ixdp2800.c b/trunk/arch/arm/mach-ixp2000/ixdp2800.c index 14f09b80ab77..70d247f09a7e 100644 --- a/trunk/arch/arm/mach-ixp2000/ixdp2800.c +++ b/trunk/arch/arm/mach-ixp2000/ixdp2800.c @@ -279,7 +279,7 @@ int __init ixdp2800_pci_init(void) subsys_initcall(ixdp2800_pci_init); -void __init ixdp2800_init_irq(void) +void ixdp2800_init_irq(void) { ixdp2x00_init_irq(IXDP2800_CPLD_INT_STAT, IXDP2800_CPLD_INT_MASK, IXDP2800_NR_IRQS); } diff --git a/trunk/arch/arm/mach-ixp2000/ixdp2x00.c b/trunk/arch/arm/mach-ixp2000/ixdp2x00.c index 73c651e83d92..52b368b34346 100644 --- a/trunk/arch/arm/mach-ixp2000/ixdp2x00.c +++ b/trunk/arch/arm/mach-ixp2000/ixdp2x00.c @@ -145,7 +145,7 @@ static struct irq_chip ixdp2x00_cpld_irq_chip = { .unmask = ixdp2x00_irq_unmask }; -void __init ixdp2x00_init_irq(volatile unsigned long *stat_reg, volatile unsigned long *mask_reg, unsigned long nr_irqs) +void ixdp2x00_init_irq(volatile unsigned long *stat_reg, volatile unsigned long *mask_reg, unsigned long nr_irqs) { unsigned int irq; @@ -195,7 +195,7 @@ void __init ixdp2x00_map_io(void) * instances of the kernel. So far so good. Peers on the PCI bus running * Linux is a common design in telecom systems. The problem is that instead * of all the devices being controlled by a single host, different - * devices are controlled by different NPUs on the same bus, leading to + * devices are controlles by different NPUs on the same bus, leading to * multiple hosts on the bus. The exact bus layout looks like: * * Bus 0 @@ -211,7 +211,7 @@ void __init ixdp2x00_map_io(void) * | | | | | * ... Dev PMC Media Eth0 Eth1 ... * - * The master controls all but Eth1, which is controlled by the + * The master controlls all but Eth1, which is controlled by the * slave. What this means is that the both the master and the slave * have to scan the bus, but only one of them can enumerate the bus. * In addition, after the bus is scanned, each kernel must remove diff --git a/trunk/arch/arm/mach-ixp2000/ixdp2x01.c b/trunk/arch/arm/mach-ixp2000/ixdp2x01.c index d3d730d2fc2b..3084a5fa751c 100644 --- a/trunk/arch/arm/mach-ixp2000/ixdp2x01.c +++ b/trunk/arch/arm/mach-ixp2000/ixdp2x01.c @@ -276,7 +276,7 @@ static int __init ixdp2x01_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) /* Device is located after first MB bridge */ case 0x0008: if (tmp_bus == dev->bus) { - /* Device is located directly after first MB bridge */ + /* Device is located directy after first MB bridge */ switch (devpin) { case DEVPIN(1, 1): /* Onboard 82546 ch 0 */ if (machine_is_ixdp2401()) @@ -299,7 +299,7 @@ static int __init ixdp2x01_pci_map_irq(struct pci_dev *dev, u8 slot, u8 pin) break; case 0x0010: if (tmp_bus == dev->bus) { - /* Device is located directly after second MB bridge */ + /* Device is located directy after second MB bridge */ /* Secondary bus of second bridge */ switch (devpin) { case DEVPIN(0, 1): /* DB#0 */ @@ -348,7 +348,7 @@ int __init ixdp2x01_pci_init(void) subsys_initcall(ixdp2x01_pci_init); /************************************************************************* - * IXDP2x01 Machine Initialization + * IXDP2x01 Machine Intialization *************************************************************************/ static struct flash_platform_data ixdp2x01_flash_platform_data = { .map_name = "cfi_probe", diff --git a/trunk/arch/arm/mach-ixp2000/pci.c b/trunk/arch/arm/mach-ixp2000/pci.c index 03f4cf7f9dec..5a09a90c08fb 100644 --- a/trunk/arch/arm/mach-ixp2000/pci.c +++ b/trunk/arch/arm/mach-ixp2000/pci.c @@ -102,7 +102,7 @@ int ixp2000_pci_read_config(struct pci_bus *bus, unsigned int devfn, int where, } /* - * We don't do error checks by calling clear_master_aborts() b/c the + * We don't do error checks by callling clear_master_aborts() b/c the * assumption is that the caller did a read first to make sure a device * exists. */ diff --git a/trunk/arch/arm/mach-ixp23xx/core.c b/trunk/arch/arm/mach-ixp23xx/core.c index 16356ffc86ae..b644bbab7d0a 100644 --- a/trunk/arch/arm/mach-ixp23xx/core.c +++ b/trunk/arch/arm/mach-ixp23xx/core.c @@ -389,7 +389,7 @@ struct sys_timer ixp23xx_timer = { /************************************************************************* - * IXP23xx Platform Initialization + * IXP23xx Platform Initializaion *************************************************************************/ static struct resource ixp23xx_uart_resources[] = { { diff --git a/trunk/arch/arm/mach-ixp23xx/ixdp2351.c b/trunk/arch/arm/mach-ixp23xx/ixdp2351.c index c41a6b5a0acc..7a86a2516eaa 100644 --- a/trunk/arch/arm/mach-ixp23xx/ixdp2351.c +++ b/trunk/arch/arm/mach-ixp23xx/ixdp2351.c @@ -124,7 +124,7 @@ static struct irq_chip ixdp2351_intb_chip = { .unmask = ixdp2351_intb_unmask }; -void __init ixdp2351_init_irq(void) +void ixdp2351_init_irq(void) { int irq; diff --git a/trunk/arch/arm/mach-ixp23xx/pci.c b/trunk/arch/arm/mach-ixp23xx/pci.c index 227f808dc0ec..ac7d43d23c28 100644 --- a/trunk/arch/arm/mach-ixp23xx/pci.c +++ b/trunk/arch/arm/mach-ixp23xx/pci.c @@ -284,7 +284,7 @@ int ixp23xx_pci_setup(int nr, struct pci_sys_data *sys) return 1; } -void __init ixp23xx_pci_slave_init(void) +void ixp23xx_pci_slave_init(void) { ixp23xx_pci_common_init(); } diff --git a/trunk/arch/arm/mach-ixp23xx/roadrunner.c b/trunk/arch/arm/mach-ixp23xx/roadrunner.c index e35644961aa4..d06e21b70de5 100644 --- a/trunk/arch/arm/mach-ixp23xx/roadrunner.c +++ b/trunk/arch/arm/mach-ixp23xx/roadrunner.c @@ -110,7 +110,7 @@ static int __init roadrunner_map_irq(struct pci_dev *dev, u8 idsel, u8 pin) return NO_IRQ; } -static void __init roadrunner_pci_preinit(void) +static void roadrunner_pci_preinit(void) { set_irq_type(IRQ_ROADRUNNER_PCI_INTC, IRQT_LOW); set_irq_type(IRQ_ROADRUNNER_PCI_INTD, IRQT_LOW); diff --git a/trunk/arch/arm/mach-ixp4xx/Kconfig b/trunk/arch/arm/mach-ixp4xx/Kconfig index 060909870b50..9715ef506c24 100644 --- a/trunk/arch/arm/mach-ixp4xx/Kconfig +++ b/trunk/arch/arm/mach-ixp4xx/Kconfig @@ -104,6 +104,9 @@ config MACH_DSMG600 DSM-G600 RevA device. For more information on this platform, see http://www.nslu2-linux.org/wiki/DSMG600/HomePage +# +# Avila and IXDP share the same source for now. Will change in future +# config ARCH_IXDP4XX bool depends on ARCH_IXDP425 || MACH_IXDP465 || MACH_KIXRP435 diff --git a/trunk/arch/arm/mach-ixp4xx/common.c b/trunk/arch/arm/mach-ixp4xx/common.c index 8112f726ffa0..64685da1462d 100644 --- a/trunk/arch/arm/mach-ixp4xx/common.c +++ b/trunk/arch/arm/mach-ixp4xx/common.c @@ -283,7 +283,7 @@ static struct irqaction ixp4xx_timer_irq = { .handler = ixp4xx_timer_interrupt, }; -void __init ixp4xx_timer_init(void) +static void __init ixp4xx_timer_init(void) { /* Reset/disable counter */ *IXP4XX_OSRT1 = 0; diff --git a/trunk/arch/arm/mach-ixp4xx/coyote-pci.c b/trunk/arch/arm/mach-ixp4xx/coyote-pci.c index ad2e5b97966e..7bc94f3def1c 100644 --- a/trunk/arch/arm/mach-ixp4xx/coyote-pci.c +++ b/trunk/arch/arm/mach-ixp4xx/coyote-pci.c @@ -25,6 +25,10 @@ #include +extern void ixp4xx_pci_preinit(void); +extern int ixp4xx_setup(int nr, struct pci_sys_data *sys); +extern struct pci_bus *ixp4xx_scan_bus(int nr, struct pci_sys_data *sys); + void __init coyote_pci_preinit(void) { set_irq_type(IRQ_COYOTE_PCI_SLOT0, IRQT_LOW); diff --git a/trunk/arch/arm/mach-ixp4xx/dsmg600-setup.c b/trunk/arch/arm/mach-ixp4xx/dsmg600-setup.c index 1e75e105c4f7..1caff65e22cc 100644 --- a/trunk/arch/arm/mach-ixp4xx/dsmg600-setup.c +++ b/trunk/arch/arm/mach-ixp4xx/dsmg600-setup.c @@ -18,7 +18,6 @@ #include #include #include -#include static struct flash_platform_data dsmg600_flash_data = { .map_name = "cfi_probe", @@ -129,19 +128,6 @@ static void dsmg600_power_off(void) gpio_line_set(DSMG600_PO_GPIO, IXP4XX_GPIO_HIGH); } -static void __init dsmg600_timer_init(void) -{ - /* The xtal on this machine is non-standard. */ - ixp4xx_timer_freq = DSMG600_FREQ; - - /* Call standard timer_init function. */ - ixp4xx_timer_init(); -} - -static struct sys_timer dsmg600_timer = { - .init = dsmg600_timer_init, -}; - static void __init dsmg600_init(void) { ixp4xx_sys_init(); @@ -169,13 +155,21 @@ static void __init dsmg600_init(void) #endif } +static void __init dsmg600_fixup(struct machine_desc *desc, + struct tag *tags, char **cmdline, struct meminfo *mi) +{ + /* The xtal on this machine is non-standard. */ + ixp4xx_timer_freq = DSMG600_FREQ; +} + MACHINE_START(DSMG600, "D-Link DSM-G600 RevA") /* Maintainer: www.nslu2-linux.org */ .phys_io = IXP4XX_PERIPHERAL_BASE_PHYS, .io_pg_offst = ((IXP4XX_PERIPHERAL_BASE_VIRT) >> 18) & 0xFFFC, .boot_params = 0x00000100, + .fixup = dsmg600_fixup, .map_io = ixp4xx_map_io, .init_irq = ixp4xx_init_irq, - .timer = &dsmg600_timer, + .timer = &ixp4xx_timer, .init_machine = dsmg600_init, MACHINE_END diff --git a/trunk/arch/arm/mach-ixp4xx/gtwx5715-setup.c b/trunk/arch/arm/mach-ixp4xx/gtwx5715-setup.c index dc6725bda3c4..30f1300e0e21 100644 --- a/trunk/arch/arm/mach-ixp4xx/gtwx5715-setup.c +++ b/trunk/arch/arm/mach-ixp4xx/gtwx5715-setup.c @@ -1,7 +1,7 @@ /* * arch/arm/mach-ixp4xx/gtwx5715-setup.c * - * Gemtek GTWX5715 (Linksys WRV54G) board setup + * Gemtek GTWX5715 (Linksys WRV54G) board settup * * Copyright (C) 2004 George T. Joseph * Derived from Coyote diff --git a/trunk/arch/arm/mach-ixp4xx/ixdpg425-pci.c b/trunk/arch/arm/mach-ixp4xx/ixdpg425-pci.c index d1e75b7dc3b1..509a95a692a4 100644 --- a/trunk/arch/arm/mach-ixp4xx/ixdpg425-pci.c +++ b/trunk/arch/arm/mach-ixp4xx/ixdpg425-pci.c @@ -23,6 +23,10 @@ #include +extern void ixp4xx_pci_preinit(void); +extern int ixp4xx_setup(int nr, struct pci_sys_data *sys); +extern struct pci_bus *ixp4xx_scan_bus(int nr, struct pci_sys_data *sys); + void __init ixdpg425_pci_preinit(void) { set_irq_type(IRQ_IXP4XX_GPIO6, IRQT_LOW); diff --git a/trunk/arch/arm/mach-ixp4xx/nas100d-setup.c b/trunk/arch/arm/mach-ixp4xx/nas100d-setup.c index 78a17413ceca..9a31444d9214 100644 --- a/trunk/arch/arm/mach-ixp4xx/nas100d-setup.c +++ b/trunk/arch/arm/mach-ixp4xx/nas100d-setup.c @@ -155,8 +155,7 @@ static void __init nas100d_init(void) pm_power_off = nas100d_power_off; - /* - * This is only useful on a modified machine, but it is valuable + /* This is only useful on a modified machine, but it is valuable * to have it first in order to see debug messages, and so that * it does *not* get removed if platform_add_devices fails! */ diff --git a/trunk/arch/arm/mach-ixp4xx/nslu2-setup.c b/trunk/arch/arm/mach-ixp4xx/nslu2-setup.c index 9bf8ccbcaccf..162c266e5f8f 100644 --- a/trunk/arch/arm/mach-ixp4xx/nslu2-setup.c +++ b/trunk/arch/arm/mach-ixp4xx/nslu2-setup.c @@ -22,7 +22,6 @@ #include #include #include -#include static struct flash_platform_data nslu2_flash_data = { .map_name = "cfi_probe", @@ -50,26 +49,26 @@ static struct ixp4xx_i2c_pins nslu2_i2c_gpio_pins = { static struct resource nslu2_led_resources[] = { { .name = "ready", /* green led */ - .start = NSLU2_LED_GRN_GPIO, - .end = NSLU2_LED_GRN_GPIO, + .start = NSLU2_LED_GRN, + .end = NSLU2_LED_GRN, .flags = IXP4XX_GPIO_HIGH, }, { .name = "status", /* red led */ - .start = NSLU2_LED_RED_GPIO, - .end = NSLU2_LED_RED_GPIO, + .start = NSLU2_LED_RED, + .end = NSLU2_LED_RED, .flags = IXP4XX_GPIO_HIGH, }, { .name = "disk-1", - .start = NSLU2_LED_DISK1_GPIO, - .end = NSLU2_LED_DISK1_GPIO, + .start = NSLU2_LED_DISK1, + .end = NSLU2_LED_DISK1, .flags = IXP4XX_GPIO_LOW, }, { .name = "disk-2", - .start = NSLU2_LED_DISK2_GPIO, - .end = NSLU2_LED_DISK2_GPIO, + .start = NSLU2_LED_DISK2, + .end = NSLU2_LED_DISK2, .flags = IXP4XX_GPIO_LOW, }, }; @@ -158,21 +157,10 @@ static void nslu2_power_off(void) gpio_line_set(NSLU2_PO_GPIO, IXP4XX_GPIO_HIGH); } -static void __init nslu2_timer_init(void) -{ - /* The xtal on this machine is non-standard. */ - ixp4xx_timer_freq = NSLU2_FREQ; - - /* Call standard timer_init function. */ - ixp4xx_timer_init(); -} - -static struct sys_timer nslu2_timer = { - .init = nslu2_timer_init, -}; - static void __init nslu2_init(void) { + ixp4xx_timer_freq = NSLU2_FREQ; + ixp4xx_sys_init(); nslu2_flash_resource.start = IXP4XX_EXP_BUS_BASE(0); @@ -181,8 +169,7 @@ static void __init nslu2_init(void) pm_power_off = nslu2_power_off; - /* - * This is only useful on a modified machine, but it is valuable + /* This is only useful on a modified machine, but it is valuable * to have it first in order to see debug messages, and so that * it does *not* get removed if platform_add_devices fails! */ @@ -198,6 +185,6 @@ MACHINE_START(NSLU2, "Linksys NSLU2") .boot_params = 0x00000100, .map_io = ixp4xx_map_io, .init_irq = ixp4xx_init_irq, - .timer = &nslu2_timer, + .timer = &ixp4xx_timer, .init_machine = nslu2_init, MACHINE_END diff --git a/trunk/arch/arm/mach-lh7a40x/lcd-panel.h b/trunk/arch/arm/mach-lh7a40x/lcd-panel.h index df6e38ed425b..4fb2efc4950f 100644 --- a/trunk/arch/arm/mach-lh7a40x/lcd-panel.h +++ b/trunk/arch/arm/mach-lh7a40x/lcd-panel.h @@ -126,7 +126,7 @@ static struct clcd_panel_extra lcd_panel_extra = { */ -/* The full horizontal cycle (Th) is clock/360/400/450. */ +/* The full horozontal cycle (Th) is clock/360/400/450. */ /* The full vertical cycle (Tv) is line/251/262/280. */ #define PIX_CLOCK_TARGET (6300000) /* -/6.3/7 MHz */ @@ -162,7 +162,7 @@ static struct clcd_panel lcd_panel = { /* Logic Product Development LCD 6.4" VGA -10 */ /* Sharp PN LQ64D343 */ -/* The full horizontal cycle (Th) is clock/750/800/900. */ +/* The full horozontal cycle (Th) is clock/750/800/900. */ /* The full vertical cycle (Tv) is line/515/525/560. */ #define PIX_CLOCK_TARGET (28330000) @@ -243,7 +243,7 @@ static struct clcd_panel lcd_panel = { * (fdisk, e2fsck). And, at that speed the display may have a visible * flicker. */ -/* The full horizontal cycle (Th) is clock/832/1056/1395. */ +/* The full horozontal cycle (Th) is clock/832/1056/1395. */ #define PIX_CLOCK_TARGET (20000000) #define PIX_CLOCK_DIVIDER CLOCK_TO_DIV (PIX_CLOCK_TARGET, HCLK) diff --git a/trunk/arch/arm/mach-ns9xxx/time.c b/trunk/arch/arm/mach-ns9xxx/time.c index b97d0c54a388..dd257084441c 100644 --- a/trunk/arch/arm/mach-ns9xxx/time.c +++ b/trunk/arch/arm/mach-ns9xxx/time.c @@ -35,7 +35,7 @@ static unsigned long ns9xxx_timer_gettimeoffset(void) { /* return the microseconds which have passed since the last interrupt * was _serviced_. That is, if an interrupt is pending or the counter - * reloads, return one period more. */ + * reloads, return one periode more. */ u32 counter1 = SYS_TR(0); int pending = SYS_ISR & (1 << IRQ_TIMER0); diff --git a/trunk/arch/arm/mach-omap1/Kconfig b/trunk/arch/arm/mach-omap1/Kconfig index f6ecdd3a2478..856c681ebbbc 100644 --- a/trunk/arch/arm/mach-omap1/Kconfig +++ b/trunk/arch/arm/mach-omap1/Kconfig @@ -38,7 +38,7 @@ config MACH_OMAP_H2 config MACH_OMAP_H3 bool "TI H3 Support" depends on ARCH_OMAP1 && ARCH_OMAP16XX -# select GPIOEXPANDER_OMAP + select GPIOEXPANDER_OMAP help TI OMAP 1710 H3 board support. Say Y here if you have such a board. diff --git a/trunk/arch/arm/mach-omap1/board-osk.c b/trunk/arch/arm/mach-omap1/board-osk.c index e7130293a03f..7d0cf7af88ce 100644 --- a/trunk/arch/arm/mach-omap1/board-osk.c +++ b/trunk/arch/arm/mach-omap1/board-osk.c @@ -385,7 +385,7 @@ static void __init osk_init(void) /* Workaround for wrong CS3 (NOR flash) timing * There are some U-Boot versions out there which configure * wrong CS3 memory timings. This mainly leads to CRC - * or similar errors if you use NOR flash (e.g. with JFFS2) + * or similiar errors if you use NOR flash (e.g. with JFFS2) */ if (EMIFS_CCS(3) != EMIFS_CS3_VAL) EMIFS_CCS(3) = EMIFS_CS3_VAL; diff --git a/trunk/arch/arm/mach-omap1/board-palmte.c b/trunk/arch/arm/mach-omap1/board-palmte.c index 015824185629..4bc8a62909b9 100644 --- a/trunk/arch/arm/mach-omap1/board-palmte.c +++ b/trunk/arch/arm/mach-omap1/board-palmte.c @@ -7,7 +7,7 @@ * * Original version : Laurent Gonzalez * - * Maintainers : http://palmtelinux.sf.net + * Maintainters : http://palmtelinux.sf.net * palmtelinux-developpers@lists.sf.net * * This program is free software; you can redistribute it and/or modify diff --git a/trunk/arch/arm/mach-omap1/pm.c b/trunk/arch/arm/mach-omap1/pm.c index 5bb348e2e315..8caee68aa090 100644 --- a/trunk/arch/arm/mach-omap1/pm.c +++ b/trunk/arch/arm/mach-omap1/pm.c @@ -438,7 +438,7 @@ void omap_pm_suspend(void) omap_writew(0, ULPD_SOFT_DISABLE_REQ_REG); /* - * Re-enable interrupts + * Reenable interrupts */ local_irq_enable(); diff --git a/trunk/arch/arm/mach-omap2/clock.c b/trunk/arch/arm/mach-omap2/clock.c index 588adb5ab47f..5170481afeab 100644 --- a/trunk/arch/arm/mach-omap2/clock.c +++ b/trunk/arch/arm/mach-omap2/clock.c @@ -443,7 +443,7 @@ static long omap2_clk_round_rate(struct clk *clk, unsigned long rate) /* * Check the DLL lock state, and return tue if running in unlock mode. - * This is needed to compensate for the shifted DLL value in unlock mode. + * This is needed to compenste for the shifted DLL value in unlock mode. */ static u32 omap2_dll_force_needed(void) { diff --git a/trunk/arch/arm/mach-omap2/clock.h b/trunk/arch/arm/mach-omap2/clock.h index 4f791866b910..162978fd5359 100644 --- a/trunk/arch/arm/mach-omap2/clock.h +++ b/trunk/arch/arm/mach-omap2/clock.h @@ -338,7 +338,7 @@ struct prcm_config { /* * These represent optimal values for common parts, it won't work for all. * As long as you scale down, most parameters are still work, they just - * become sub-optimal. The RFR value goes in the opposite direction. If you + * become sub-optimal. The RFR value goes in the oppisite direction. If you * don't adjust it down as your clock period increases the refresh interval * will not be met. Setting all parameters for complete worst case may work, * but may cut memory performance by 2x. Due to errata the DLLs need to be @@ -384,7 +384,7 @@ struct prcm_config { * Filling in table based on H4 boards and 2430-SDPs variants available. * There are quite a few more rates combinations which could be defined. * - * When multiple values are defined the start up will try and choose the + * When multiple values are defiend the start up will try and choose the * fastest one. If a 'fast' value is defined, then automatically, the /2 * one should be included as it can be used. Generally having more that * one fast set does not make sense, as static timings need to be changed diff --git a/trunk/arch/arm/mach-pxa/corgi_lcd.c b/trunk/arch/arm/mach-pxa/corgi_lcd.c index 365b9435f748..a72476c24621 100644 --- a/trunk/arch/arm/mach-pxa/corgi_lcd.c +++ b/trunk/arch/arm/mach-pxa/corgi_lcd.c @@ -40,7 +40,7 @@ #define PICTRL_ADRS 0x06 #define POLCTRL_ADRS 0x07 -/* Register Bit Definitions */ +/* Resgister Bit Definitions */ #define RESCTL_QVGA 0x01 #define RESCTL_VGA 0x00 @@ -55,11 +55,11 @@ #define POWER0_COM_DCLK 0x01 /* COM Voltage DC Bias DAC Serial Data Clock */ #define POWER0_COM_DOUT 0x02 /* COM Voltage DC Bias DAC Serial Data Out */ #define POWER0_DAC_ON 0x04 /* DAC Power Supply ON */ -#define POWER0_COM_ON 0x08 /* COM Power Supply ON */ +#define POWER0_COM_ON 0x08 /* COM Powewr Supply ON */ #define POWER0_VCC5_ON 0x10 /* VCC5 Power Supply ON */ #define POWER0_DAC_OFF 0x00 /* DAC Power Supply OFF */ -#define POWER0_COM_OFF 0x00 /* COM Power Supply OFF */ +#define POWER0_COM_OFF 0x00 /* COM Powewr Supply OFF */ #define POWER0_VCC5_OFF 0x00 /* VCC5 Power Supply OFF */ #define PICTRL_INIT_STATE 0x01 @@ -145,7 +145,7 @@ static void lcdtg_set_common_voltage(u8 base_data, u8 data) lcdtg_i2c_send_stop(base_data); } -/* Set Phase Adjust */ +/* Set Phase Adjuct */ static void lcdtg_set_phadadj(int mode) { int adj; @@ -226,7 +226,7 @@ static void lcdtg_hw_init(int mode) /* Signals output enable */ corgi_ssp_lcdtg_send(PICTRL_ADRS, 0); - /* Set Phase Adjust */ + /* Set Phase Adjuct */ lcdtg_set_phadadj(mode); /* Initialize for Input Signals from ATI */ diff --git a/trunk/arch/arm/mach-pxa/corgi_ssp.c b/trunk/arch/arm/mach-pxa/corgi_ssp.c index 40dea3d5142b..ff6b4ee037f5 100644 --- a/trunk/arch/arm/mach-pxa/corgi_ssp.c +++ b/trunk/arch/arm/mach-pxa/corgi_ssp.c @@ -32,7 +32,7 @@ static struct corgissp_machinfo *ssp_machinfo; * There are three devices connected to the SSP interface: * 1. A touchscreen controller (TI ADS7846 compatible) * 2. An LCD contoller (with some Backlight functionality) - * 3. A battery monitoring IC (Maxim MAX1111) + * 3. A battery moinitoring IC (Maxim MAX1111) * * Each device uses a different speed/mode of communication. * diff --git a/trunk/arch/arm/mach-pxa/pxa27x.c b/trunk/arch/arm/mach-pxa/pxa27x.c index 1939acc3f9f7..c64bab49efc4 100644 --- a/trunk/arch/arm/mach-pxa/pxa27x.c +++ b/trunk/arch/arm/mach-pxa/pxa27x.c @@ -140,9 +140,9 @@ void pxa_cpu_pm_enter(suspend_state_t state) extern void pxa_cpu_resume(void); if (state == PM_SUSPEND_STANDBY) - CKEN = (1 << CKEN_MEMC) | (1 << CKEN_OSTIMER) | (1 << CKEN_LCD) | (1 << CKEN_PWM0); + CKEN = CKEN_MEMC | CKEN_OSTIMER | CKEN_LCD | CKEN_PWM0; else - CKEN = (1 << CKEN_MEMC) | (1 << CKEN_OSTIMER); + CKEN = CKEN_MEMC | CKEN_OSTIMER; /* ensure voltage-change sequencer not initiated, which hangs */ PCFR &= ~PCFR_FVC; diff --git a/trunk/arch/arm/mach-realview/localtimer.c b/trunk/arch/arm/mach-realview/localtimer.c index c7bdf04ab094..caf6b8bb6c95 100644 --- a/trunk/arch/arm/mach-realview/localtimer.c +++ b/trunk/arch/arm/mach-realview/localtimer.c @@ -30,7 +30,7 @@ static unsigned long mpcore_timer_rate; /* * local_timer_ack: checks for a local timer interrupt. * - * If a local timer interrupt has occurred, acknowledge and return 1. + * If a local timer interrupt has occured, acknowledge and return 1. * Otherwise, return 0. */ int local_timer_ack(void) diff --git a/trunk/arch/arm/mach-s3c2410/bast.h b/trunk/arch/arm/mach-s3c2410/bast.h new file mode 100644 index 000000000000..e98543742eb9 --- /dev/null +++ b/trunk/arch/arm/mach-s3c2410/bast.h @@ -0,0 +1,2 @@ +/* linux/arch/arm/mach-s3c2410/bast.h +extern void bast_init_irq(void); diff --git a/trunk/arch/arm/mach-s3c2410/mach-amlm5900.c b/trunk/arch/arm/mach-s3c2410/mach-amlm5900.c index 435adcce6482..bc308ceb91c3 100644 --- a/trunk/arch/arm/mach-s3c2410/mach-amlm5900.c +++ b/trunk/arch/arm/mach-s3c2410/mach-amlm5900.c @@ -160,7 +160,7 @@ static struct platform_device *amlm5900_devices[] __initdata = { #endif }; -static void __init amlm5900_map_io(void) +void __init amlm5900_map_io(void) { s3c24xx_init_io(amlm5900_iodesc, ARRAY_SIZE(amlm5900_iodesc)); s3c24xx_init_clocks(0); diff --git a/trunk/arch/arm/mach-s3c2410/mach-h1940.c b/trunk/arch/arm/mach-s3c2410/mach-h1940.c index 5c9bcea74767..5ccd0be23a33 100644 --- a/trunk/arch/arm/mach-s3c2410/mach-h1940.c +++ b/trunk/arch/arm/mach-s3c2410/mach-h1940.c @@ -17,7 +17,6 @@ #include #include #include -#include #include #include diff --git a/trunk/arch/arm/mach-s3c2410/mach-qt2410.c b/trunk/arch/arm/mach-s3c2410/mach-qt2410.c index d86e6f18bac9..9cc4253d7bbc 100644 --- a/trunk/arch/arm/mach-s3c2410/mach-qt2410.c +++ b/trunk/arch/arm/mach-s3c2410/mach-qt2410.c @@ -27,7 +27,6 @@ #include #include #include -#include #include #include #include diff --git a/trunk/arch/arm/mach-s3c2412/dma.c b/trunk/arch/arm/mach-s3c2412/dma.c index 668cccefe7b0..d0f4695c09d9 100644 --- a/trunk/arch/arm/mach-s3c2412/dma.c +++ b/trunk/arch/arm/mach-s3c2412/dma.c @@ -59,8 +59,8 @@ static struct s3c24xx_dma_map __initdata s3c2412_dma_mappings[] = { [DMACH_SPI1] = { .name = "spi1", .channels = MAP(S3C2412_DMAREQSEL_SPI1TX), - .hw_addr.to = S3C2410_PA_SPI + S3C2412_SPI1 + S3C2410_SPTDAT, - .hw_addr.from = S3C2410_PA_SPI + S3C2412_SPI1 + S3C2410_SPRDAT, + .hw_addr.to = S3C2410_PA_SPI + 0x20 + S3C2410_SPTDAT, + .hw_addr.from = S3C2410_PA_SPI + 0x20 + S3C2410_SPRDAT, }, [DMACH_UART0] = { .name = "uart0", diff --git a/trunk/arch/arm/mach-s3c2412/s3c2412.c b/trunk/arch/arm/mach-s3c2412/s3c2412.c index 782b5814ced2..aafe0bc593f1 100644 --- a/trunk/arch/arm/mach-s3c2412/s3c2412.c +++ b/trunk/arch/arm/mach-s3c2412/s3c2412.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include #include @@ -30,7 +29,6 @@ #include #include -#include #include #include @@ -39,8 +37,6 @@ #include #include #include -#include -#include #include #include @@ -78,14 +74,6 @@ void __init s3c2412_init_uarts(struct s3c2410_uartcfg *cfg, int no) s3c_device_sdi.name = "s3c2412-sdi"; s3c_device_lcd.name = "s3c2412-lcd"; s3c_device_nand.name = "s3c2412-nand"; - - /* spi channel related changes, s3c2412/13 specific */ - s3c_device_spi0.name = "s3c2412-spi"; - s3c_device_spi0.resource[0].end = S3C24XX_PA_SPI + 0x24; - s3c_device_spi1.name = "s3c2412-spi"; - s3c_device_spi1.resource[0].start = S3C24XX_PA_SPI + S3C2412_SPI1; - s3c_device_spi1.resource[0].end = S3C24XX_PA_SPI + S3C2412_SPI1 + 0x24; - } /* s3c2412_idle @@ -109,23 +97,6 @@ static void s3c2412_idle(void) cpu_do_idle(); } -static void s3c2412_hard_reset(void) -{ - /* errata "Watch-dog/Software Reset Problem" specifies that - * this reset must be done with the SYSCLK sourced from - * EXTCLK instead of FOUT to avoid a glitch in the reset - * mechanism. - * - * See the watchdog section of the S3C2412 manual for more - * information on this fix. - */ - - __raw_writel(0x00, S3C2412_CLKSRC); - __raw_writel(S3C2412_SWRST_RESET, S3C2412_SWRST); - - mdelay(1); -} - /* s3c2412_map_io * * register the standard cpu IO areas, and any passed in from the @@ -142,10 +113,6 @@ void __init s3c2412_map_io(struct map_desc *mach_desc, int mach_size) s3c24xx_idle = s3c2412_idle; - /* set custom reset hook */ - - s3c24xx_reset_hook = s3c2412_hard_reset; - /* register our io-tables */ iotable_init(s3c2412_iodesc, ARRAY_SIZE(s3c2412_iodesc)); diff --git a/trunk/arch/arm/mach-s3c2440/mach-anubis.c b/trunk/arch/arm/mach-s3c2440/mach-anubis.c index bff7ddd06a52..b5d387ef37e1 100644 --- a/trunk/arch/arm/mach-s3c2440/mach-anubis.c +++ b/trunk/arch/arm/mach-s3c2440/mach-anubis.c @@ -76,8 +76,8 @@ static struct map_desc anubis_iodesc[] __initdata = { .length = SZ_4K, .type = MT_DEVICE, }, { - .virtual = (u32)ANUBIS_VA_IDREG, - .pfn = __phys_to_pfn(ANUBIS_PA_IDREG), + .virtual = (u32)ANUBIS_VA_CTRL2, + .pfn = __phys_to_pfn(ANUBIS_PA_CTRL2), .length = SZ_4K, .type = MT_DEVICE, }, diff --git a/trunk/arch/arm/mach-s3c2440/mach-osiris.c b/trunk/arch/arm/mach-s3c2440/mach-osiris.c index 15811601f03d..324f5a237921 100644 --- a/trunk/arch/arm/mach-s3c2440/mach-osiris.c +++ b/trunk/arch/arm/mach-s3c2440/mach-osiris.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include @@ -46,7 +45,7 @@ #include #include -/* onboard perihperal map */ +/* onboard perihpheral map */ static struct map_desc osiris_iodesc[] __initdata = { /* ISA IO areas (may be over-written later) */ @@ -66,11 +65,6 @@ static struct map_desc osiris_iodesc[] __initdata = { /* CPLD control registers */ { - .virtual = (u32)OSIRIS_VA_CTRL0, - .pfn = __phys_to_pfn(OSIRIS_PA_CTRL0), - .length = SZ_16K, - .type = MT_DEVICE, - }, { .virtual = (u32)OSIRIS_VA_CTRL1, .pfn = __phys_to_pfn(OSIRIS_PA_CTRL1), .length = SZ_16K, @@ -80,11 +74,6 @@ static struct map_desc osiris_iodesc[] __initdata = { .pfn = __phys_to_pfn(OSIRIS_PA_CTRL2), .length = SZ_16K, .type = MT_DEVICE, - }, { - .virtual = (u32)OSIRIS_VA_IDREG, - .pfn = __phys_to_pfn(OSIRIS_PA_IDREG), - .length = SZ_16K, - .type = MT_DEVICE, }, }; @@ -206,13 +195,13 @@ static void osiris_nand_select(struct s3c2410_nand_set *set, int slot) pr_debug("osiris_nand: selecting slot %d (set %p,%p)\n", slot, set, set->nr_map); - tmp = __raw_readb(OSIRIS_VA_CTRL0); - tmp &= ~OSIRIS_CTRL0_NANDSEL; + tmp = __raw_readb(OSIRIS_VA_CTRL1); + tmp &= ~OSIRIS_CTRL1_NANDSEL; tmp |= slot; - pr_debug("osiris_nand: ctrl0 now %02x\n", tmp); + pr_debug("osiris_nand: ctrl1 now %02x\n", tmp); - __raw_writeb(tmp, OSIRIS_VA_CTRL0); + __raw_writeb(tmp, OSIRIS_VA_CTRL1); } static struct s3c2410_platform_nand osiris_nand_info = { @@ -246,45 +235,10 @@ static struct platform_device osiris_pcmcia = { .resource = osiris_pcmcia_resource, }; -/* Osiris power management device */ - -#ifdef CONFIG_PM -static unsigned char pm_osiris_ctrl0; - -static int osiris_pm_suspend(struct sys_device *sd, pm_message_t state) -{ - pm_osiris_ctrl0 = __raw_readb(OSIRIS_VA_CTRL0); - return 0; -} - -static int osiris_pm_resume(struct sys_device *sd) -{ - if (pm_osiris_ctrl0 & OSIRIS_CTRL0_FIX8) - __raw_writeb(OSIRIS_CTRL1_FIX8, OSIRIS_VA_CTRL1); - - return 0; -} - -#else -#define osiris_pm_suspend NULL -#define osiris_pm_resume NULL -#endif - -static struct sysdev_class osiris_pm_sysclass = { - set_kset_name("mach-osiris"), - .suspend = osiris_pm_suspend, - .resume = osiris_pm_resume, -}; - -static struct sys_device osiris_pm_sysdev = { - .cls = &osiris_pm_sysclass, -}; - /* Standard Osiris devices */ static struct platform_device *osiris_devices[] __initdata = { &s3c_device_i2c, - &s3c_device_wdt, &s3c_device_nand, &osiris_pcmcia, }; @@ -334,9 +288,6 @@ static void __init osiris_map_io(void) static void __init osiris_init(void) { - sysdev_class_register(&osiris_pm_sysclass); - sysdev_register(&osiris_pm_sysdev); - platform_add_devices(osiris_devices, ARRAY_SIZE(osiris_devices)); }; @@ -348,6 +299,5 @@ MACHINE_START(OSIRIS, "Simtec-OSIRIS") .map_io = osiris_map_io, .init_machine = osiris_init, .init_irq = s3c24xx_init_irq, - .init_machine = osiris_init, .timer = &s3c24xx_timer, MACHINE_END diff --git a/trunk/arch/arm/mach-s3c2440/mach-rx3715.c b/trunk/arch/arm/mach-s3c2440/mach-rx3715.c index 866ff71c01dd..c3cc4bf158f6 100644 --- a/trunk/arch/arm/mach-s3c2440/mach-rx3715.c +++ b/trunk/arch/arm/mach-s3c2440/mach-rx3715.c @@ -19,7 +19,6 @@ #include #include #include -#include #include #include #include diff --git a/trunk/arch/arm/mach-s3c2443/clock.c b/trunk/arch/arm/mach-s3c2443/clock.c index 58402948c47c..0b6e360aeae7 100644 --- a/trunk/arch/arm/mach-s3c2443/clock.c +++ b/trunk/arch/arm/mach-s3c2443/clock.c @@ -394,7 +394,7 @@ static int s3c2443_setrate_usbhost(struct clk *clk, unsigned long rate) return 0; } -static struct clk clk_usb_bus_host = { +struct clk clk_usb_bus_host = { .name = "usb-bus-host-parent", .id = -1, .parent = &clk_esysclk, @@ -746,24 +746,6 @@ static struct clk init_clocks[] = { .parent = &clk_h, .enable = s3c2443_clkcon_enable_h, .ctrlbit = S3C2443_HCLKCON_USBD, - }, { - .name = "hsmmc", - .id = -1, - .parent = &clk_h, - .enable = s3c2443_clkcon_enable_h, - .ctrlbit = S3C2443_HCLKCON_HSMMC, - }, { - .name = "cfc", - .id = -1, - .parent = &clk_h, - .enable = s3c2443_clkcon_enable_h, - .ctrlbit = S3C2443_HCLKCON_CFC, - }, { - .name = "ssmc", - .id = -1, - .parent = &clk_h, - .enable = s3c2443_clkcon_enable_h, - .ctrlbit = S3C2443_HCLKCON_SSMC, }, { .name = "timers", .id = -1, @@ -809,8 +791,7 @@ static struct clk init_clocks[] = { .name = "usb-bus-host", .id = -1, .parent = &clk_usb_bus_host, - }, { - .name = "ac97", + }, { .name = "ac97", .id = -1, .parent = &clk_p, .ctrlbit = S3C2443_PCLKCON_AC97, diff --git a/trunk/arch/arm/mach-s3c2443/mach-smdk2443.c b/trunk/arch/arm/mach-s3c2443/mach-smdk2443.c index b1eb709ee65a..b71ee53c2865 100644 --- a/trunk/arch/arm/mach-s3c2443/mach-smdk2443.c +++ b/trunk/arch/arm/mach-s3c2443/mach-smdk2443.c @@ -104,7 +104,6 @@ static struct s3c2410_uartcfg smdk2443_uartcfgs[] __initdata = { static struct platform_device *smdk2443_devices[] __initdata = { &s3c_device_wdt, &s3c_device_i2c, - &s3c_device_hsmmc, }; static void __init smdk2443_map_io(void) diff --git a/trunk/arch/arm/mach-s3c2443/s3c2443.c b/trunk/arch/arm/mach-s3c2443/s3c2443.c index 8d8117158d23..11b1d0b310c3 100644 --- a/trunk/arch/arm/mach-s3c2443/s3c2443.c +++ b/trunk/arch/arm/mach-s3c2443/s3c2443.c @@ -63,10 +63,6 @@ int __init s3c2443_init(void) s3c_device_nand.name = "s3c2412-nand"; - /* change WDT IRQ number */ - s3c_device_wdt.resource[1].start = IRQ_S3C2443_WDT; - s3c_device_wdt.resource[1].end = IRQ_S3C2443_WDT; - return sysdev_register(&s3c2443_sysdev); } diff --git a/trunk/arch/arm/mach-sa1100/neponset.c b/trunk/arch/arm/mach-sa1100/neponset.c index 3a0a1ee2542d..d7c038a0256b 100644 --- a/trunk/arch/arm/mach-sa1100/neponset.c +++ b/trunk/arch/arm/mach-sa1100/neponset.c @@ -139,12 +139,12 @@ static u_int neponset_get_mctrl(struct uart_port *port) return ret; } -static struct sa1100_port_fns neponset_port_fns __devinitdata = { +static struct sa1100_port_fns neponset_port_fns __initdata = { .set_mctrl = neponset_set_mctrl, .get_mctrl = neponset_get_mctrl, }; -static int __devinit neponset_probe(struct platform_device *dev) +static int neponset_probe(struct platform_device *dev) { sa1100_register_uart_fns(&neponset_port_fns); @@ -185,21 +185,28 @@ static int __devinit neponset_probe(struct platform_device *dev) /* * LDM power management. */ -static unsigned int neponset_saved_state; - static int neponset_suspend(struct platform_device *dev, pm_message_t state) { /* * Save state. */ - neponset_saved_state = NCR_0; + if (!dev->dev.power.saved_state) + dev->dev.power.saved_state = kmalloc(sizeof(unsigned int), GFP_KERNEL); + if (!dev->dev.power.saved_state) + return -ENOMEM; + + *(unsigned int *)dev->dev.power.saved_state = NCR_0; return 0; } static int neponset_resume(struct platform_device *dev) { - NCR_0 = neponset_saved_state; + if (dev->dev.power.saved_state) { + NCR_0 = *(unsigned int *)dev->dev.power.saved_state; + kfree(dev->dev.power.saved_state); + dev->dev.power.saved_state = NULL; + } return 0; } diff --git a/trunk/arch/arm/mach-sa1100/time.c b/trunk/arch/arm/mach-sa1100/time.c index 29cb0c1604ab..416e277054c2 100644 --- a/trunk/arch/arm/mach-sa1100/time.c +++ b/trunk/arch/arm/mach-sa1100/time.c @@ -25,7 +25,7 @@ static unsigned long __init sa1100_get_rtc_time(void) { /* * According to the manual we should be able to let RTTR be zero - * and then a default divisor for a 32.768KHz clock is used. + * and then a default diviser for a 32.768KHz clock is used. * Apparently this doesn't work, at least for my SA1110 rev 5. * If the clock divider is uninitialized then reset it to the * default value to get the 1Hz clock. diff --git a/trunk/arch/arm/mach-versatile/pci.c b/trunk/arch/arm/mach-versatile/pci.c index ca8290159432..ba58223f12be 100644 --- a/trunk/arch/arm/mach-versatile/pci.c +++ b/trunk/arch/arm/mach-versatile/pci.c @@ -117,10 +117,7 @@ static int versatile_read_config(struct pci_bus *bus, unsigned int devfn, int wh } else { switch (size) { case 1: - v = __raw_readl(addr); - if (where & 2) v >>= 16; - if (where & 1) v >>= 8; - v &= 0xff; + v = __raw_readb(addr); break; case 2: diff --git a/trunk/arch/arm/mm/Kconfig b/trunk/arch/arm/mm/Kconfig index e7904bc92c73..15f0284010ca 100644 --- a/trunk/arch/arm/mm/Kconfig +++ b/trunk/arch/arm/mm/Kconfig @@ -351,7 +351,6 @@ config CPU_V6 select CPU_CACHE_V6 select CPU_CACHE_VIPT select CPU_CP15_MMU - select CPU_HAS_ASID select CPU_COPY_V6 if MMU select CPU_TLB_V6 if MMU @@ -377,9 +376,8 @@ config CPU_V7 select CPU_CACHE_V7 select CPU_CACHE_VIPT select CPU_CP15_MMU - select CPU_HAS_ASID select CPU_COPY_V6 if MMU - select CPU_TLB_V7 if MMU + select CPU_TLB_V6 if MMU # Figure out what processor architecture version we should be using. # This defines the compiler instruction set which depends on the machine type. @@ -498,17 +496,8 @@ config CPU_TLB_V4WBI config CPU_TLB_V6 bool -config CPU_TLB_V7 - bool - endif -config CPU_HAS_ASID - bool - help - This indicates whether the CPU has the ASID register; used to - tag TLB and possibly cache entries. - config CPU_CP15 bool help diff --git a/trunk/arch/arm/mm/Makefile b/trunk/arch/arm/mm/Makefile index 762702765fc3..b5bd335ff14a 100644 --- a/trunk/arch/arm/mm/Makefile +++ b/trunk/arch/arm/mm/Makefile @@ -46,7 +46,6 @@ obj-$(CONFIG_CPU_TLB_V4WT) += tlb-v4.o obj-$(CONFIG_CPU_TLB_V4WB) += tlb-v4wb.o obj-$(CONFIG_CPU_TLB_V4WBI) += tlb-v4wbi.o obj-$(CONFIG_CPU_TLB_V6) += tlb-v6.o -obj-$(CONFIG_CPU_TLB_V7) += tlb-v7.o obj-$(CONFIG_CPU_ARM610) += proc-arm6_7.o obj-$(CONFIG_CPU_ARM710) += proc-arm6_7.o diff --git a/trunk/arch/arm/mm/alignment.c b/trunk/arch/arm/mm/alignment.c index 074b7cb07743..19ca333240ec 100644 --- a/trunk/arch/arm/mm/alignment.c +++ b/trunk/arch/arm/mm/alignment.c @@ -3,7 +3,7 @@ * * Copyright (C) 1995 Linus Torvalds * Modifications for ARM processor (c) 1995-2001 Russell King - * Thumb alignment fault fixups (c) 2004 MontaVista Software, Inc. + * Thumb aligment fault fixups (c) 2004 MontaVista Software, Inc. * - Adapted from gdb/sim/arm/thumbemu.c -- Thumb instruction emulation. * Copyright (C) 1996, Cygnus Software Technologies Ltd. * @@ -630,7 +630,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs) fs = get_fs(); set_fs(KERNEL_DS); - if (thumb_mode(regs)) { + if thumb_mode(regs) { fault = __get_user(tinstr, (u16 *)(instrptr & ~1)); if (!(fault)) instr = thumb2arm(tinstr); diff --git a/trunk/arch/arm/mm/ioremap.c b/trunk/arch/arm/mm/ioremap.c index f3ade18862aa..d6167ad4e011 100644 --- a/trunk/arch/arm/mm/ioremap.c +++ b/trunk/arch/arm/mm/ioremap.c @@ -346,7 +346,7 @@ void __iounmap(volatile void __iomem *addr) #ifndef CONFIG_SMP /* * If this is a section based mapping we need to handle it - * specially as the VM subsystem does not know how to handle + * specially as the VM subysystem does not know how to handle * such a beast. We need the lock here b/c we need to clear * all the mappings before the area can be reclaimed * by someone else. diff --git a/trunk/arch/arm/mm/mmap.c b/trunk/arch/arm/mm/mmap.c index 2728b0e7d2bb..2c4c2422cd1e 100644 --- a/trunk/arch/arm/mm/mmap.c +++ b/trunk/arch/arm/mm/mmap.c @@ -5,7 +5,7 @@ #include #include #include -#include + #include #define COLOUR_ALIGN(addr,pgoff) \ diff --git a/trunk/arch/arm/mm/mmu.c b/trunk/arch/arm/mm/mmu.c index 3b5e47dc0c97..2ba1530d1ce1 100644 --- a/trunk/arch/arm/mm/mmu.c +++ b/trunk/arch/arm/mm/mmu.c @@ -92,7 +92,7 @@ static struct cachepolicy cache_policies[] __initdata = { }; /* - * These are useful for identifying cache coherency + * These are useful for identifing cache coherency * problems by allowing the cache or the cache and * writebuffer to be turned off. (Note: the write * buffer should not be on and the cache off). @@ -527,9 +527,9 @@ void __init create_mapping(struct map_desc *md) return; } - addr = md->virtual & PAGE_MASK; + addr = md->virtual; phys = (unsigned long)__pfn_to_phys(md->pfn); - length = PAGE_ALIGN(md->length + (md->virtual & ~PAGE_MASK)); + length = PAGE_ALIGN(md->length); if (type->prot_l1 == 0 && ((addr | phys | length) & ~SECTION_MASK)) { printk(KERN_WARNING "BUG: map for 0x%08lx at 0x%08lx can not " diff --git a/trunk/arch/arm/mm/proc-v7.S b/trunk/arch/arm/mm/proc-v7.S index 718f4782ee8b..dd823dd4a374 100644 --- a/trunk/arch/arm/mm/proc-v7.S +++ b/trunk/arch/arm/mm/proc-v7.S @@ -256,7 +256,7 @@ __v7_proc_info: .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP .long cpu_v7_name .long v7_processor_functions - .long v7wbi_tlb_fns + .long v6wbi_tlb_fns .long v6_user_fns .long v7_cache_fns .size __v7_proc_info, . - __v7_proc_info diff --git a/trunk/arch/arm/mm/tlb-v7.S b/trunk/arch/arm/mm/tlb-v7.S deleted file mode 100644 index b56dda8052f7..000000000000 --- a/trunk/arch/arm/mm/tlb-v7.S +++ /dev/null @@ -1,88 +0,0 @@ -/* - * linux/arch/arm/mm/tlb-v7.S - * - * Copyright (C) 1997-2002 Russell King - * Modified for ARMv7 by Catalin Marinas - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * ARM architecture version 6 TLB handling functions. - * These assume a split I/D TLB. - */ -#include -#include -#include -#include -#include "proc-macros.S" - -/* - * v7wbi_flush_user_tlb_range(start, end, vma) - * - * Invalidate a range of TLB entries in the specified address space. - * - * - start - start address (may not be aligned) - * - end - end address (exclusive, may not be aligned) - * - vma - vma_struct describing address range - * - * It is assumed that: - * - the "Invalidate single entry" instruction will invalidate - * both the I and the D TLBs on Harvard-style TLBs - */ -ENTRY(v7wbi_flush_user_tlb_range) - vma_vm_mm r3, r2 @ get vma->vm_mm - mmid r3, r3 @ get vm_mm->context.id - dsb - mov r0, r0, lsr #PAGE_SHIFT @ align address - mov r1, r1, lsr #PAGE_SHIFT - asid r3, r3 @ mask ASID - orr r0, r3, r0, lsl #PAGE_SHIFT @ Create initial MVA - mov r1, r1, lsl #PAGE_SHIFT - vma_vm_flags r2, r2 @ get vma->vm_flags -1: - mcr p15, 0, r0, c8, c6, 1 @ TLB invalidate D MVA (was 1) - tst r2, #VM_EXEC @ Executable area ? - mcrne p15, 0, r0, c8, c5, 1 @ TLB invalidate I MVA (was 1) - add r0, r0, #PAGE_SZ - cmp r0, r1 - blo 1b - mov ip, #0 - mcr p15, 0, ip, c7, c5, 6 @ flush BTAC/BTB - dsb - mov pc, lr - -/* - * v7wbi_flush_kern_tlb_range(start,end) - * - * Invalidate a range of kernel TLB entries - * - * - start - start address (may not be aligned) - * - end - end address (exclusive, may not be aligned) - */ -ENTRY(v7wbi_flush_kern_tlb_range) - dsb - mov r0, r0, lsr #PAGE_SHIFT @ align address - mov r1, r1, lsr #PAGE_SHIFT - mov r0, r0, lsl #PAGE_SHIFT - mov r1, r1, lsl #PAGE_SHIFT -1: - mcr p15, 0, r0, c8, c6, 1 @ TLB invalidate D MVA - mcr p15, 0, r0, c8, c5, 1 @ TLB invalidate I MVA - add r0, r0, #PAGE_SZ - cmp r0, r1 - blo 1b - mov r2, #0 - mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB - dsb - isb - mov pc, lr - - .section ".text.init", #alloc, #execinstr - - .type v7wbi_tlb_fns, #object -ENTRY(v7wbi_tlb_fns) - .long v7wbi_flush_user_tlb_range - .long v7wbi_flush_kern_tlb_range - .long v6wbi_tlb_flags - .size v7wbi_tlb_fns, . - v7wbi_tlb_fns diff --git a/trunk/arch/arm/nwfpe/softfloat.h b/trunk/arch/arm/nwfpe/softfloat.h index 260fe29d73f5..0a3067452cd2 100644 --- a/trunk/arch/arm/nwfpe/softfloat.h +++ b/trunk/arch/arm/nwfpe/softfloat.h @@ -273,7 +273,4 @@ static inline flag float64_lt_nocheck(float64 a, float64 b) extern flag float32_is_nan( float32 a ); extern flag float64_is_nan( float64 a ); -extern int32 float64_to_uint32( struct roundingData *roundData, float64 a ); -extern int32 float64_to_uint32_round_to_zero( float64 a ); - #endif diff --git a/trunk/arch/arm/oprofile/op_model_mpcore.c b/trunk/arch/arm/oprofile/op_model_mpcore.c index 75bae067922d..898500718249 100644 --- a/trunk/arch/arm/oprofile/op_model_mpcore.c +++ b/trunk/arch/arm/oprofile/op_model_mpcore.c @@ -200,10 +200,8 @@ static int em_call_function(int (*fn)(void)) data.fn = fn; data.ret = 0; - preempt_disable(); smp_call_function(em_func, &data, 1, 1); em_func(&data); - preempt_enable(); return data.ret; } @@ -259,13 +257,8 @@ static void em_stop(void) */ static void em_route_irq(int irq, unsigned int cpu) { - struct irq_desc *desc = irq_desc + irq; - cpumask_t mask = cpumask_of_cpu(cpu); - - spin_lock_irq(&desc->lock); - desc->affinity = mask; - desc->chip->set_affinity(irq, mask); - spin_unlock_irq(&desc->lock); + irq_desc[irq].affinity = cpumask_of_cpu(cpu); + irq_desc[irq].chip->set_affinity(irq, cpumask_of_cpu(cpu)); } static int em_setup(void) diff --git a/trunk/arch/arm/plat-iop/pci.c b/trunk/arch/arm/plat-iop/pci.c index 2b5aa1135b11..e2744b7227c5 100644 --- a/trunk/arch/arm/plat-iop/pci.c +++ b/trunk/arch/arm/plat-iop/pci.c @@ -19,7 +19,6 @@ #include #include #include -#include #include #include #include @@ -86,10 +85,10 @@ static int iop3xx_pci_status(void) /* * Simply write the address register and read the configuration - * data. Note that the 4 nops ensure that we are able to handle + * data. Note that the 4 nop's ensure that we are able to handle * a delayed abort (in theory.) */ -static u32 iop3xx_read(unsigned long addr) +static inline u32 iop3xx_read(unsigned long addr) { u32 val; @@ -322,7 +321,7 @@ void __init iop3xx_atu_disable(void) /* Flag to determine whether the ATU is initialized and the PCI bus scanned */ int init_atu; -void __init iop3xx_pci_preinit(void) +void iop3xx_pci_preinit(void) { if (iop3xx_get_init_atu() == IOP3XX_INIT_ATU_ENABLE) { iop3xx_atu_disable(); diff --git a/trunk/arch/arm/plat-omap/common.c b/trunk/arch/arm/plat-omap/common.c index 7987aa6e95f8..dd8708ad0a71 100644 --- a/trunk/arch/arm/plat-omap/common.c +++ b/trunk/arch/arm/plat-omap/common.c @@ -73,7 +73,7 @@ static const void *get_config(u16 tag, size_t len, int skip, size_t *len_out) } if (info != NULL) { /* Check the length as a lame attempt to check for - * binary inconsistency. */ + * binary inconsistancy. */ if (len != NO_LENGTH_CHECK) { /* Word-align len */ if (len & 0x03) diff --git a/trunk/arch/arm/plat-omap/dma.c b/trunk/arch/arm/plat-omap/dma.c index 88d5b6d9f950..55a4d3be16b6 100644 --- a/trunk/arch/arm/plat-omap/dma.c +++ b/trunk/arch/arm/plat-omap/dma.c @@ -1172,7 +1172,7 @@ static void set_b1_regs(void) break; default: BUG(); - return; /* Suppress warning about uninitialized vars */ + return; /* Supress warning about uninitialized vars */ } if (omap_dma_in_1510_mode()) { diff --git a/trunk/arch/arm/plat-omap/sram.c b/trunk/arch/arm/plat-omap/sram.c index 1f23f0459e5f..bc46f33aede3 100644 --- a/trunk/arch/arm/plat-omap/sram.c +++ b/trunk/arch/arm/plat-omap/sram.c @@ -59,8 +59,8 @@ extern unsigned long omapfb_reserve_sram(unsigned long sram_pstart, /* * Depending on the target RAMFS firewall setup, the public usable amount of - * SRAM varies. The default accessible size for all device types is 2k. A GP - * device allows ARM11 but not other initiators for full size. This + * SRAM varies. The default accessable size for all device types is 2k. A GP + * device allows ARM11 but not other initators for full size. This * functionality seems ok until some nice security API happens. */ static int is_sram_locked(void) @@ -71,7 +71,7 @@ static int is_sram_locked(void) type = __raw_readl(VA_CONTROL_STAT) & TYPE_MASK; if (type == GP_DEVICE) { - /* RAMFW: R/W access to all initiators for all qualifier sets */ + /* RAMFW: R/W access to all initators for all qualifier sets */ if (cpu_is_omap242x()) { __raw_writel(0xFF, VA_REQINFOPERM0); /* all q-vects */ __raw_writel(0xCFDE, VA_READPERM0); /* all i-read */ diff --git a/trunk/arch/arm/plat-omap/usb.c b/trunk/arch/arm/plat-omap/usb.c index a5aedf964b88..25489aafb113 100644 --- a/trunk/arch/arm/plat-omap/usb.c +++ b/trunk/arch/arm/plat-omap/usb.c @@ -177,7 +177,7 @@ static u32 __init omap_usb0_init(unsigned nwires, unsigned is_device) /* NOTE: SPEED and SUSP aren't configured here. OTG hosts * may be able to use I2C requests to set those bits along - * with VBUS switching and overcurrent detection. + * with VBUS switching and overcurrent detction. */ if (cpu_class_is_omap1() && nwires != 6) diff --git a/trunk/arch/arm/plat-s3c24xx/common-smdk.c b/trunk/arch/arm/plat-s3c24xx/common-smdk.c index 7ed19b23ce56..908efa7d745f 100644 --- a/trunk/arch/arm/plat-s3c24xx/common-smdk.c +++ b/trunk/arch/arm/plat-s3c24xx/common-smdk.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include @@ -30,7 +29,6 @@ #include #include -#include #include #include #include @@ -194,9 +192,6 @@ void __init smdk_machine_init(void) s3c2410_gpio_setpin(S3C2410_GPF6, 1); s3c2410_gpio_setpin(S3C2410_GPF7, 1); - if (machine_is_smdk2443()) - smdk_nand_info.twrph0 = 50; - s3c_device_nand.dev.platform_data = &smdk_nand_info; platform_add_devices(smdk_devs, ARRAY_SIZE(smdk_devs)); diff --git a/trunk/arch/arm/plat-s3c24xx/devs.c b/trunk/arch/arm/plat-s3c24xx/devs.c index 5875da0ae0eb..0fe53b39cb2f 100644 --- a/trunk/arch/arm/plat-s3c24xx/devs.c +++ b/trunk/arch/arm/plat-s3c24xx/devs.c @@ -33,7 +33,6 @@ #include #include -#include /* Serial port registrations */ @@ -403,36 +402,6 @@ struct platform_device s3c_device_sdi = { EXPORT_SYMBOL(s3c_device_sdi); -/* High-speed MMC/SD */ - -static struct resource s3c_hsmmc_resource[] = { - [0] = { - .start = S3C2443_PA_HSMMC, - .end = S3C2443_PA_HSMMC + S3C2443_SZ_HSMMC - 1, - .flags = IORESOURCE_MEM, - }, - [1] = { - .start = IRQ_S3C2443_HSMMC, - .end = IRQ_S3C2443_HSMMC, - .flags = IORESOURCE_IRQ, - } -}; - -static u64 s3c_device_hsmmc_dmamask = 0xffffffffUL; - -struct platform_device s3c_device_hsmmc = { - .name = "s3c-sdhci", - .id = -1, - .num_resources = ARRAY_SIZE(s3c_hsmmc_resource), - .resource = s3c_hsmmc_resource, - .dev = { - .dma_mask = &s3c_device_hsmmc_dmamask, - .coherent_dma_mask = 0xffffffffUL - } -}; - - - /* SPI (0) */ static struct resource s3c_spi0_resource[] = { @@ -468,8 +437,8 @@ EXPORT_SYMBOL(s3c_device_spi0); static struct resource s3c_spi1_resource[] = { [0] = { - .start = S3C24XX_PA_SPI + S3C2410_SPI1, - .end = S3C24XX_PA_SPI + S3C2410_SPI1 + 0x1f, + .start = S3C24XX_PA_SPI + 0x20, + .end = S3C24XX_PA_SPI + 0x20 + 0x1f, .flags = IORESOURCE_MEM, }, [1] = { diff --git a/trunk/arch/arm/plat-s3c24xx/dma.c b/trunk/arch/arm/plat-s3c24xx/dma.c index 08d80f2f51f2..6f03c9370979 100644 --- a/trunk/arch/arm/plat-s3c24xx/dma.c +++ b/trunk/arch/arm/plat-s3c24xx/dma.c @@ -1153,7 +1153,7 @@ EXPORT_SYMBOL(s3c2410_dma_set_buffdone_fn); * * hwcfg: the value for xxxSTCn register, * bit 0: 0=increment pointer, 1=leave pointer - * bit 1: 0=source is AHB, 1=source is APB + * bit 1: 0=soucre is AHB, 1=soucre is APB * * devaddr: physical address of the source */ diff --git a/trunk/arch/arm/plat-s3c24xx/pm-simtec.c b/trunk/arch/arm/plat-s3c24xx/pm-simtec.c index cb0b3a4ccf1b..bd965f2feeca 100644 --- a/trunk/arch/arm/plat-s3c24xx/pm-simtec.c +++ b/trunk/arch/arm/plat-s3c24xx/pm-simtec.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include diff --git a/trunk/arch/arm/plat-s3c24xx/pm.c b/trunk/arch/arm/plat-s3c24xx/pm.c index 5692eccdf4d1..c6b03f8ab260 100644 --- a/trunk/arch/arm/plat-s3c24xx/pm.c +++ b/trunk/arch/arm/plat-s3c24xx/pm.c @@ -555,7 +555,7 @@ static int s3c2410_pm_enter(suspend_state_t state) __raw_writel(__raw_readl(S3C2410_INTPND), S3C2410_INTPND); __raw_writel(__raw_readl(S3C2410_SRCPND), S3C2410_SRCPND); - /* call cpu specific preparation */ + /* call cpu specific preperation */ pm_cpu_prep(); diff --git a/trunk/arch/arm/vfp/entry.S b/trunk/arch/arm/vfp/entry.S index 806ce26d5243..ca2a5ad19ea6 100644 --- a/trunk/arch/arm/vfp/entry.S +++ b/trunk/arch/arm/vfp/entry.S @@ -29,10 +29,6 @@ do_vfp: add r10, r10, #TI_VFPSTATE @ r10 = workspace ldr pc, [r4] @ call VFP entry point -ENTRY(vfp_null_entry) - mov pc, lr -ENDPROC(vfp_null_entry) - .LCvfp: .word vfp_vector diff --git a/trunk/arch/arm/vfp/vfpmodule.c b/trunk/arch/arm/vfp/vfpmodule.c index 1106b5f9cf19..f1e5951dc721 100644 --- a/trunk/arch/arm/vfp/vfpmodule.c +++ b/trunk/arch/arm/vfp/vfpmodule.c @@ -26,9 +26,8 @@ */ void vfp_testing_entry(void); void vfp_support_entry(void); -void vfp_null_entry(void); -void (*vfp_vector)(void) = vfp_null_entry; +void (*vfp_vector)(void) = vfp_testing_entry; union vfp_state *last_VFP_context[NR_CPUS]; /* @@ -322,10 +321,8 @@ static int __init vfp_init(void) * The handler is already setup to just log calls, so * we just need to read the VFPSID register. */ - vfp_vector = vfp_testing_entry; vfpsid = fmrx(FPSID); barrier(); - vfp_vector = vfp_null_entry; printk(KERN_INFO "VFP support v0.3: "); if (VFP_arch) { diff --git a/trunk/arch/arm26/kernel/vmlinux-arm26-xip.lds.in b/trunk/arch/arm26/kernel/vmlinux-arm26-xip.lds.in index 4ec715c25dea..046a85054018 100644 --- a/trunk/arch/arm26/kernel/vmlinux-arm26-xip.lds.in +++ b/trunk/arch/arm26/kernel/vmlinux-arm26-xip.lds.in @@ -64,7 +64,7 @@ SECTIONS .text : { /* Real text segment */ _text = .; /* Text and read-only data */ - TEXT_TEXT + *(.text) SCHED_TEXT LOCK_TEXT /* FIXME - borrowed from arm32 - check*/ *(.fixup) @@ -111,7 +111,7 @@ SECTIONS /* * and the usual data section */ - DATA_DATA + *(.data) CONSTRUCTORS *(.init.data) diff --git a/trunk/arch/arm26/kernel/vmlinux-arm26.lds.in b/trunk/arch/arm26/kernel/vmlinux-arm26.lds.in index 6c44f6a17bf7..1d2949e83be8 100644 --- a/trunk/arch/arm26/kernel/vmlinux-arm26.lds.in +++ b/trunk/arch/arm26/kernel/vmlinux-arm26.lds.in @@ -65,7 +65,7 @@ SECTIONS .text : { /* Real text segment */ _text = .; /* Text and read-only data */ - TEXT_TEXT + *(.text) SCHED_TEXT LOCK_TEXT *(.fixup) @@ -106,7 +106,7 @@ SECTIONS /* * and the usual data section */ - DATA_DATA + *(.data) CONSTRUCTORS _edata = .; diff --git a/trunk/arch/avr32/boards/atngw100/setup.c b/trunk/arch/avr32/boards/atngw100/setup.c index 6c4dc0a00e9f..9bc37d4f6687 100644 --- a/trunk/arch/avr32/boards/atngw100/setup.c +++ b/trunk/arch/avr32/boards/atngw100/setup.c @@ -94,6 +94,9 @@ static void __init set_hw_addr(struct platform_device *pdev) clk_put(pclk); } +struct platform_device *at32_usart_map[1]; +unsigned int at32_nr_usarts = 1; + void __init setup_board(void) { at32_map_usart(1, 0); /* USART 1: /dev/ttyS0, DB9 */ diff --git a/trunk/arch/avr32/boards/atstk1000/atstk1000.h b/trunk/arch/avr32/boards/atstk1000/atstk1000.h deleted file mode 100644 index 9a49ed036b72..000000000000 --- a/trunk/arch/avr32/boards/atstk1000/atstk1000.h +++ /dev/null @@ -1,15 +0,0 @@ -/* - * ATSTK1000 setup code: Daughterboard interface - * - * Copyright (C) 2007 Atmel Corporation - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ -#ifndef __ARCH_AVR32_BOARDS_ATSTK1000_ATSTK1000_H -#define __ARCH_AVR32_BOARDS_ATSTK1000_ATSTK1000_H - -extern struct atmel_lcdfb_info atstk1000_lcdc_data; - -#endif /* __ARCH_AVR32_BOARDS_ATSTK1000_ATSTK1000_H */ diff --git a/trunk/arch/avr32/boards/atstk1000/atstk1002.c b/trunk/arch/avr32/boards/atstk1000/atstk1002.c index e253e86a1a39..abe6ca203fa7 100644 --- a/trunk/arch/avr32/boards/atstk1000/atstk1002.c +++ b/trunk/arch/avr32/boards/atstk1000/atstk1002.c @@ -16,8 +16,6 @@ #include #include -#include