diff --git a/[refs] b/[refs] index 19cec40658de..9ec3b828057e 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 8abfc6e7a45eb74e51904bbae676fae008b11366 +refs/heads/master: 0da2f50944976e890ccc9436ab88c0da87788d02 diff --git a/trunk/CREDITS b/trunk/CREDITS index 41d8e63d5165..72b487869788 100644 --- a/trunk/CREDITS +++ b/trunk/CREDITS @@ -3554,12 +3554,12 @@ E: cvance@nai.com D: portions of the Linux Security Module (LSM) framework and security modules N: Petr Vandrovec -E: petr@vandrovec.name +E: vandrove@vc.cvut.cz D: Small contributions to ncpfs D: Matrox framebuffer driver -S: 21513 Conradia Ct -S: Cupertino, CA 95014 -S: USA +S: Chudenicka 8 +S: 10200 Prague 10, Hostivar +S: Czech Republic N: Thibaut Varene E: T-Bone@parisc-linux.org diff --git a/trunk/Documentation/ABI/testing/sysfs-ata b/trunk/Documentation/ABI/testing/sysfs-ata deleted file mode 100644 index 0a932155cbba..000000000000 --- a/trunk/Documentation/ABI/testing/sysfs-ata +++ /dev/null @@ -1,99 +0,0 @@ -What: /sys/class/ata_... -Date: August 2008 -Contact: Gwendal Grignou -Description: - -Provide a place in sysfs for storing the ATA topology of the system. This allows -retrieving various information about ATA objects. - -Files under /sys/class/ata_port -------------------------------- - - For each port, a directory ataX is created where X is the ata_port_id of - the port. The device parent is the ata host device. - -idle_irq (read) - - Number of IRQ received by the port while idle [some ata HBA only]. - -nr_pmp_links (read) - - If a SATA Port Multiplier (PM) is connected, number of link behind it. - -Files under /sys/class/ata_link -------------------------------- - - Behind each port, there is a ata_link. If there is a SATA PM in the - topology, 15 ata_link objects are created. - - If a link is behind a port, the directory name is linkX, where X is - ata_port_id of the port. - If a link is behind a PM, its name is linkX.Y where X is ata_port_id - of the parent port and Y the PM port. - -hw_sata_spd_limit - - Maximum speed supported by the connected SATA device. - -sata_spd_limit - - Maximum speed imposed by libata. - -sata_spd - - Current speed of the link [1.5, 3Gps,...]. - -Files under /sys/class/ata_device ---------------------------------- - - Behind each link, up to two ata device are created. - The name of the directory is devX[.Y].Z where: - - X is ata_port_id of the port where the device is connected, - - Y the port of the PM if any, and - - Z the device id: for PATA, there is usually 2 devices [0,1], - only 1 for SATA. - -class - Device class. Can be "ata" for disk, "atapi" for packet device, - "pmp" for PM, or "none" if no device was found behind the link. - -dma_mode - - Transfer modes supported by the device when in DMA mode. - Mostly used by PATA device. - -pio_mode - - Transfer modes supported by the device when in PIO mode. - Mostly used by PATA device. - -xfer_mode - - Current transfer mode. - -id - - Cached result of IDENTIFY command, as described in ATA8 7.16 and 7.17. - Only valid if the device is not a PM. - -gscr - - Cached result of the dump of PM GSCR register. - Valid registers are: - 0: SATA_PMP_GSCR_PROD_ID, - 1: SATA_PMP_GSCR_REV, - 2: SATA_PMP_GSCR_PORT_INFO, - 32: SATA_PMP_GSCR_ERROR, - 33: SATA_PMP_GSCR_ERROR_EN, - 64: SATA_PMP_GSCR_FEAT, - 96: SATA_PMP_GSCR_FEAT_EN, - 130: SATA_PMP_GSCR_SII_GPIO - Only valid if the device is a PM. - -spdn_cnt - - Number of time libata decided to lower the speed of link due to errors. - -ering - - Formatted output of the error ring of the device. diff --git a/trunk/Documentation/ABI/testing/sysfs-devices-power b/trunk/Documentation/ABI/testing/sysfs-devices-power index 7628cd1bc36a..6123c523bfd7 100644 --- a/trunk/Documentation/ABI/testing/sysfs-devices-power +++ b/trunk/Documentation/ABI/testing/sysfs-devices-power @@ -77,91 +77,3 @@ Description: devices this attribute is set to "enabled" by bus type code or device drivers and in that cases it should be safe to leave the default value. - -What: /sys/devices/.../power/wakeup_count -Date: September 2010 -Contact: Rafael J. Wysocki -Description: - The /sys/devices/.../wakeup_count attribute contains the number - of signaled wakeup events associated with the device. This - attribute is read-only. If the device is not enabled to wake up - the system from sleep states, this attribute is empty. - -What: /sys/devices/.../power/wakeup_active_count -Date: September 2010 -Contact: Rafael J. Wysocki -Description: - The /sys/devices/.../wakeup_active_count attribute contains the - number of times the processing of wakeup events associated with - the device was completed (at the kernel level). This attribute - is read-only. If the device is not enabled to wake up the - system from sleep states, this attribute is empty. - -What: /sys/devices/.../power/wakeup_hit_count -Date: September 2010 -Contact: Rafael J. Wysocki -Description: - The /sys/devices/.../wakeup_hit_count attribute contains the - number of times the processing of a wakeup event associated with - the device might prevent the system from entering a sleep state. - This attribute is read-only. If the device is not enabled to - wake up the system from sleep states, this attribute is empty. - -What: /sys/devices/.../power/wakeup_active -Date: September 2010 -Contact: Rafael J. Wysocki -Description: - The /sys/devices/.../wakeup_active attribute contains either 1, - or 0, depending on whether or not a wakeup event associated with - the device is being processed (1). This attribute is read-only. - If the device is not enabled to wake up the system from sleep - states, this attribute is empty. - -What: /sys/devices/.../power/wakeup_total_time_ms -Date: September 2010 -Contact: Rafael J. Wysocki -Description: - The /sys/devices/.../wakeup_total_time_ms attribute contains - the total time of processing wakeup events associated with the - device, in milliseconds. This attribute is read-only. If the - device is not enabled to wake up the system from sleep states, - this attribute is empty. - -What: /sys/devices/.../power/wakeup_max_time_ms -Date: September 2010 -Contact: Rafael J. Wysocki -Description: - The /sys/devices/.../wakeup_max_time_ms attribute contains - the maximum time of processing a single wakeup event associated - with the device, in milliseconds. This attribute is read-only. - If the device is not enabled to wake up the system from sleep - states, this attribute is empty. - -What: /sys/devices/.../power/wakeup_last_time_ms -Date: September 2010 -Contact: Rafael J. Wysocki -Description: - The /sys/devices/.../wakeup_last_time_ms attribute contains - the value of the monotonic clock corresponding to the time of - signaling the last wakeup event associated with the device, in - milliseconds. This attribute is read-only. If the device is - not enabled to wake up the system from sleep states, this - attribute is empty. - -What: /sys/devices/.../power/autosuspend_delay_ms -Date: September 2010 -Contact: Alan Stern -Description: - The /sys/devices/.../power/autosuspend_delay_ms attribute - contains the autosuspend delay value (in milliseconds). Some - drivers do not want their device to suspend as soon as it - becomes idle at run time; they want the device to remain - inactive for a certain minimum period of time first. That - period is called the autosuspend delay. Negative values will - prevent the device from being suspended at run time (similar - to writing "on" to the power/control attribute). Values >= - 1000 will cause the autosuspend timer expiration to be rounded - up to the nearest second. - - Not all drivers support this attribute. If it isn't supported, - attempts to read or write it will yield I/O errors. diff --git a/trunk/Documentation/ABI/testing/sysfs-power b/trunk/Documentation/ABI/testing/sysfs-power index 194ca446ac28..2875f1f74a07 100644 --- a/trunk/Documentation/ABI/testing/sysfs-power +++ b/trunk/Documentation/ABI/testing/sysfs-power @@ -99,38 +99,9 @@ Description: dmesg -s 1000000 | grep 'hash matches' - If you do not get any matches (or they appear to be false - positives), it is possible that the last PM event point - referred to a device created by a loadable kernel module. In - this case cat /sys/power/pm_trace_dev_match (see below) after - your system is started up and the kernel modules are loaded. - CAUTION: Using it will cause your machine's real-time (CMOS) clock to be set to a random invalid time after a resume. -What; /sys/power/pm_trace_dev_match -Date: October 2010 -Contact: James Hogan -Description: - The /sys/power/pm_trace_dev_match file contains the name of the - device associated with the last PM event point saved in the RTC - across reboots when pm_trace has been used. More precisely it - contains the list of current devices (including those - registered by loadable kernel modules since boot) which match - the device hash in the RTC at boot, with a newline after each - one. - - The advantage of this file over the hash matches printed to the - kernel log (see /sys/power/pm_trace), is that it includes - devices created after boot by loadable kernel modules. - - Due to the small hash size necessary to fit in the RTC, it is - possible that more than one device matches the hash, in which - case further investigation is required to determine which - device is causing the problem. Note that genuine RTC clock - values (such as when pm_trace has not been used), can still - match a device and output it's name here. - What: /sys/power/pm_async Date: January 2009 Contact: Rafael J. Wysocki diff --git a/trunk/Documentation/DocBook/device-drivers.tmpl b/trunk/Documentation/DocBook/device-drivers.tmpl index feca0758391e..ecd35e9d4410 100644 --- a/trunk/Documentation/DocBook/device-drivers.tmpl +++ b/trunk/Documentation/DocBook/device-drivers.tmpl @@ -46,6 +46,7 @@ Atomic and pointer manipulation !Iarch/x86/include/asm/atomic.h +!Iarch/x86/include/asm/unaligned.h Delaying, scheduling, and timer routines diff --git a/trunk/Documentation/DocBook/drm.tmpl b/trunk/Documentation/DocBook/drm.tmpl index 2861055afd7a..910c923a9b86 100644 --- a/trunk/Documentation/DocBook/drm.tmpl +++ b/trunk/Documentation/DocBook/drm.tmpl @@ -136,7 +136,6 @@ #ifdef CONFIG_COMPAT .compat_ioctl = i915_compat_ioctl, #endif - .llseek = noop_llseek, }, .pci_driver = { .name = DRIVER_NAME, diff --git a/trunk/Documentation/DocBook/genericirq.tmpl b/trunk/Documentation/DocBook/genericirq.tmpl index fb10fd08c05c..1448b33fd222 100644 --- a/trunk/Documentation/DocBook/genericirq.tmpl +++ b/trunk/Documentation/DocBook/genericirq.tmpl @@ -28,7 +28,7 @@ - 2005-2010 + 2005-2006 Thomas Gleixner @@ -100,10 +100,6 @@ Edge type Simple type - During the implementation we identified another type: - - Fast EOI type - In the SMP world of the __do_IRQ() super-handler another type was identified: @@ -157,7 +153,6 @@ is still available. This leads to a kind of duality for the time being. Over time the new model should be used in more and more architectures, as it enables smaller and cleaner IRQ subsystems. - It's deprecated for three years now and about to be removed. @@ -222,7 +217,6 @@ handle_level_irq handle_edge_irq - handle_fasteoi_irq handle_simple_irq handle_percpu_irq @@ -239,33 +233,33 @@ are used by the default flow implementations. The following helper functions are implemented (simplified excerpt): -default_enable(struct irq_data *data) +default_enable(irq) { - desc->chip->irq_unmask(data); + desc->chip->unmask(irq); } -default_disable(struct irq_data *data) +default_disable(irq) { - if (!delay_disable(data)) - desc->chip->irq_mask(data); + if (!delay_disable(irq)) + desc->chip->mask(irq); } -default_ack(struct irq_data *data) +default_ack(irq) { - chip->irq_ack(data); + chip->ack(irq); } -default_mask_ack(struct irq_data *data) +default_mask_ack(irq) { - if (chip->irq_mask_ack) { - chip->irq_mask_ack(data); + if (chip->mask_ack) { + chip->mask_ack(irq); } else { - chip->irq_mask(data); - chip->irq_ack(data); + chip->mask(irq); + chip->ack(irq); } } -noop(struct irq_data *data)) +noop(irq) { } @@ -284,27 +278,12 @@ noop(struct irq_data *data)) The following control flow is implemented (simplified excerpt): -desc->chip->irq_mask(); -handle_IRQ_event(desc->action); -desc->chip->irq_unmask(); - - - - - Default Fast EOI IRQ flow handler - - handle_fasteoi_irq provides a generic implementation - for interrupts, which only need an EOI at the end of - the handler - - - The following control flow is implemented (simplified excerpt): - +desc->chip->start(); handle_IRQ_event(desc->action); -desc->chip->irq_eoi(); +desc->chip->end(); - + Default Edge IRQ flow handler @@ -315,19 +294,20 @@ desc->chip->irq_eoi(); The following control flow is implemented (simplified excerpt): if (desc->status & running) { - desc->chip->irq_mask(); + desc->chip->hold(); desc->status |= pending | masked; return; } -desc->chip->irq_ack(); +desc->chip->start(); desc->status |= running; do { if (desc->status & masked) - desc->chip->irq_unmask(); + desc->chip->enable(); desc->status &= ~pending; handle_IRQ_event(desc->action); } while (status & pending); desc->status &= ~running; +desc->chip->end(); @@ -362,9 +342,9 @@ handle_IRQ_event(desc->action); The following control flow is implemented (simplified excerpt): +desc->chip->start(); handle_IRQ_event(desc->action); -if (desc->chip->irq_eoi) - desc->chip->irq_eoi(); +desc->chip->end(); @@ -395,7 +375,8 @@ if (desc->chip->irq_eoi) mechanism. (It's necessary to enable CONFIG_HARDIRQS_SW_RESEND when you want to use the delayed interrupt disable feature and your hardware is not capable of retriggering an interrupt.) - The delayed interrupt disable is not configurable. + The delayed interrupt disable can be runtime enabled, per interrupt, + by setting the IRQ_DELAYED_DISABLE flag in the irq_desc status field. @@ -406,13 +387,13 @@ if (desc->chip->irq_eoi) contains all the direct chip relevant functions, which can be utilized by the irq flow implementations. - irq_ack() - irq_mask_ack() - Optional, recommended for performance - irq_mask() - irq_unmask() - irq_retrigger() - Optional - irq_set_type() - Optional - irq_set_wake() - Optional + ack() + mask_ack() - Optional, recommended for performance + mask() + unmask() + retrigger() - Optional + set_type() - Optional + set_wake() - Optional These primitives are strictly intended to mean what they say: ack means ACK, masking means masking of an IRQ line, etc. It is up to the flow @@ -477,7 +458,6 @@ if (desc->chip->irq_eoi) This chapter contains the autogenerated documentation of the internal functions. -!Ikernel/irq/irqdesc.c !Ikernel/irq/handle.c !Ikernel/irq/chip.c diff --git a/trunk/Documentation/DocBook/kernel-api.tmpl b/trunk/Documentation/DocBook/kernel-api.tmpl index 6899f471fb15..a20c6f6fffc3 100644 --- a/trunk/Documentation/DocBook/kernel-api.tmpl +++ b/trunk/Documentation/DocBook/kernel-api.tmpl @@ -57,6 +57,7 @@ String Conversions +!Ilib/vsprintf.c !Elib/vsprintf.c String Manipulation diff --git a/trunk/Documentation/DocBook/kernel-locking.tmpl b/trunk/Documentation/DocBook/kernel-locking.tmpl index f66f4df18690..0b1a3f97f285 100644 --- a/trunk/Documentation/DocBook/kernel-locking.tmpl +++ b/trunk/Documentation/DocBook/kernel-locking.tmpl @@ -1645,9 +1645,7 @@ the amount of locking which needs to be done. all the readers who were traversing the list when we deleted the element are finished. We use call_rcu() to register a callback which will actually destroy the object once - all pre-existing readers are finished. Alternatively, - synchronize_rcu() may be used to block until - all pre-existing are finished. + the readers are finished. But how does Read Copy Update know when the readers are @@ -1716,7 +1714,7 @@ the amount of locking which needs to be done. - object_put(obj); + list_del_rcu(&obj->list); cache_num--; -+ call_rcu(&obj->rcu, cache_delete_rcu); ++ call_rcu(&obj->rcu, cache_delete_rcu, obj); } /* Must be holding cache_lock */ @@ -1727,6 +1725,14 @@ the amount of locking which needs to be done. if (++cache_num > MAX_CACHE_SIZE) { struct object *i, *outcast = NULL; list_for_each_entry(i, &cache, list) { +@@ -85,6 +94,7 @@ + obj->popularity = 0; + atomic_set(&obj->refcnt, 1); /* The cache holds a reference */ + spin_lock_init(&obj->lock); ++ INIT_RCU_HEAD(&obj->rcu); + + spin_lock_irqsave(&cache_lock, flags); + __cache_add(obj); @@ -104,12 +114,11 @@ struct object *cache_find(int id) { @@ -1955,12 +1961,6 @@ machines due to caching. - - Mutex API reference -!Iinclude/linux/mutex.h -!Ekernel/mutex.c - - Further reading diff --git a/trunk/Documentation/DocBook/tracepoint.tmpl b/trunk/Documentation/DocBook/tracepoint.tmpl index b57a9ede3224..e8473eae2a20 100644 --- a/trunk/Documentation/DocBook/tracepoint.tmpl +++ b/trunk/Documentation/DocBook/tracepoint.tmpl @@ -104,9 +104,4 @@ Block IO !Iinclude/trace/events/block.h - - - Workqueue -!Iinclude/trace/events/workqueue.h - diff --git a/trunk/Documentation/RCU/checklist.txt b/trunk/Documentation/RCU/checklist.txt index 0c134f8afc6f..790d1a812376 100644 --- a/trunk/Documentation/RCU/checklist.txt +++ b/trunk/Documentation/RCU/checklist.txt @@ -218,22 +218,13 @@ over a rather long period of time, but improvements are always welcome! include: a. Keeping a count of the number of data-structure elements - used by the RCU-protected data structure, including - those waiting for a grace period to elapse. Enforce a - limit on this number, stalling updates as needed to allow - previously deferred frees to complete. Alternatively, - limit only the number awaiting deferred free rather than - the total number of elements. - - One way to stall the updates is to acquire the update-side - mutex. (Don't try this with a spinlock -- other CPUs - spinning on the lock could prevent the grace period - from ever ending.) Another way to stall the updates - is for the updates to use a wrapper function around - the memory allocator, so that this wrapper function - simulates OOM when there is too much memory awaiting an - RCU grace period. There are of course many other - variations on this theme. + used by the RCU-protected data structure, including those + waiting for a grace period to elapse. Enforce a limit + on this number, stalling updates as needed to allow + previously deferred frees to complete. + + Alternatively, limit only the number awaiting deferred + free rather than the total number of elements. b. Limiting update rate. For example, if updates occur only once per hour, then no explicit rate limiting is required, @@ -374,26 +365,3 @@ over a rather long period of time, but improvements are always welcome! and the compiler to freely reorder code into and out of RCU read-side critical sections. It is the responsibility of the RCU update-side primitives to deal with this. - -17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and - the __rcu sparse checks to validate your RCU code. These - can help find problems as follows: - - CONFIG_PROVE_RCU: check that accesses to RCU-protected data - structures are carried out under the proper RCU - read-side critical section, while holding the right - combination of locks, or whatever other conditions - are appropriate. - - CONFIG_DEBUG_OBJECTS_RCU_HEAD: check that you don't pass the - same object to call_rcu() (or friends) before an RCU - grace period has elapsed since the last time that you - passed that same object to call_rcu() (or friends). - - __rcu sparse checks: tag the pointer to the RCU-protected data - structure with __rcu, and sparse will warn you if you - access that pointer without the services of one of the - variants of rcu_dereference(). - - These debugging aids can help you find problems that are - otherwise extremely difficult to spot. diff --git a/trunk/Documentation/RCU/stallwarn.txt b/trunk/Documentation/RCU/stallwarn.txt index 862c08ef1fde..44c6dcc93d6d 100644 --- a/trunk/Documentation/RCU/stallwarn.txt +++ b/trunk/Documentation/RCU/stallwarn.txt @@ -80,24 +80,6 @@ o A CPU looping with bottom halves disabled. This condition can o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel without invoking schedule(). -o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might - happen to preempt a low-priority task in the middle of an RCU - read-side critical section. This is especially damaging if - that low-priority task is not permitted to run on any other CPU, - in which case the next RCU grace period can never complete, which - will eventually cause the system to run out of memory and hang. - While the system is in the process of running itself out of - memory, you might see stall-warning messages. - -o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that - is running at a higher priority than the RCU softirq threads. - This will prevent RCU callbacks from ever being invoked, - and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent - RCU grace periods from ever completing. Either way, the - system will eventually run out of memory and hang. In the - CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning - messages. - o A bug in the RCU implementation. o A hardware failure. This is quite unlikely, but has occurred diff --git a/trunk/Documentation/RCU/trace.txt b/trunk/Documentation/RCU/trace.txt index a851118775d8..efd8cc95c06b 100644 --- a/trunk/Documentation/RCU/trace.txt +++ b/trunk/Documentation/RCU/trace.txt @@ -125,17 +125,6 @@ o "b" is the batch limit for this CPU. If more than this number of RCU callbacks is ready to invoke, then the remainder will be deferred. -o "ci" is the number of RCU callbacks that have been invoked for - this CPU. Note that ci+ql is the number of callbacks that have - been registered in absence of CPU-hotplug activity. - -o "co" is the number of RCU callbacks that have been orphaned due to - this CPU going offline. - -o "ca" is the number of RCU callbacks that have been adopted due to - other CPUs going offline. Note that ci+co-ca+ql is the number of - RCU callbacks registered on this CPU. - There is also an rcu/rcudata.csv file with the same information in comma-separated-variable spreadsheet format. @@ -191,7 +180,7 @@ o "s" is the "signaled" state that drives force_quiescent_state()'s o "jfq" is the number of jiffies remaining for this grace period before force_quiescent_state() is invoked to help push things - along. Note that CPUs in dyntick-idle mode throughout the grace + along. Note that CPUs in dyntick-idle mode thoughout the grace period will not report on their own, but rather must be check by some other CPU via force_quiescent_state(). diff --git a/trunk/Documentation/arm/00-INDEX b/trunk/Documentation/arm/00-INDEX index ecf7d04bca26..7f5fc3ba9c91 100644 --- a/trunk/Documentation/arm/00-INDEX +++ b/trunk/Documentation/arm/00-INDEX @@ -6,8 +6,6 @@ Interrupts - ARM Interrupt subsystem documentation IXP2000 - Release Notes for Linux on Intel's IXP2000 Network Processor -msm - - MSM specific documentation Netwinder - Netwinder specific documentation Porting diff --git a/trunk/Documentation/arm/msm/gpiomux.txt b/trunk/Documentation/arm/msm/gpiomux.txt deleted file mode 100644 index 67a81620adf6..000000000000 --- a/trunk/Documentation/arm/msm/gpiomux.txt +++ /dev/null @@ -1,176 +0,0 @@ -This document provides an overview of the msm_gpiomux interface, which -is used to provide gpio pin multiplexing and configuration on mach-msm -targets. - -History -======= - -The first-generation API for gpio configuration & multiplexing on msm -is the function gpio_tlmm_config(). This function has a few notable -shortcomings, which led to its deprecation and replacement by gpiomux: - -The 'disable' parameter: Setting the second parameter to -gpio_tlmm_config to GPIO_CFG_DISABLE tells the peripheral -processor in charge of the subsystem to perform a look-up into a -low-power table and apply the low-power/sleep setting for the pin. -As the msm family evolved this became problematic. Not all pins -have sleep settings, not all peripheral processors will accept requests -to apply said sleep settings, and not all msm targets have their gpio -subsystems managed by a peripheral processor. In order to get consistent -behavior on all targets, drivers are forced to ignore this parameter, -rendering it useless. - -The 'direction' flag: for all mux-settings other than raw-gpio (0), -the output-enable bit of a gpio is hard-wired to a known -input (usually VDD or ground). For those settings, the direction flag -is meaningless at best, and deceptive at worst. In addition, using the -direction flag to change output-enable (OE) directly can cause trouble in -gpiolib, which has no visibility into gpio direction changes made -in this way. Direction control in gpio mode should be made through gpiolib. - -Key Features of gpiomux -======================= - -- A consistent interface across all generations of msm. Drivers can expect -the same results on every target. -- gpiomux plays nicely with gpiolib. Functions that should belong to gpiolib -are left to gpiolib and not duplicated here. gpiomux is written with the -intent that gpio_chips will call gpiomux reference-counting methods -from their request() and free() hooks, providing full integration. -- Tabular configuration. Instead of having to call gpio_tlmm_config -hundreds of times, gpio configuration is placed in a single table. -- Per-gpio sleep. Each gpio is individually reference counted, allowing only -those lines which are in use to be put in high-power states. -- 0 means 'do nothing': all flags are designed so that the default memset-zero -equates to a sensible default of 'no configuration', preventing users -from having to provide hundreds of 'no-op' configs for unused or -unwanted lines. - -Usage -===== - -To use gpiomux, provide configuration information for relevant gpio lines -in the msm_gpiomux_configs table. Since a 0 equates to "unconfigured", -only those lines to be managed by gpiomux need to be specified. Here -is a completely fictional example: - -struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = { - [12] = { - .active = GPIOMUX_VALID | GPIOMUX_DRV_8MA | GPIOMUX_FUNC_1, - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, - [34] = { - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, -}; - -To indicate that a gpio is in use, call msm_gpiomux_get() to increase -its reference count. To decrease the reference count, call msm_gpiomux_put(). - -The effect of this configuration is as follows: - -When the system boots, gpios 12 and 34 will be initialized with their -'suspended' configurations. All other gpios, which were left unconfigured, -will not be touched. - -When msm_gpiomux_get() is called on gpio 12 to raise its reference count -above 0, its active configuration will be applied. Since no other gpio -line has a valid active configuration, msm_gpiomux_get() will have no -effect on any other line. - -When msm_gpiomux_put() is called on gpio 12 or 34 to drop their reference -count to 0, their suspended configurations will be applied. -Since no other gpio line has a valid suspended configuration, no other -gpio line will be effected by msm_gpiomux_put(). Since gpio 34 has no valid -active configuration, this is effectively a no-op for gpio 34 as well, -with one small caveat, see the section "About Output-Enable Settings". - -All of the GPIOMUX_VALID flags may seem like unnecessary overhead, but -they address some important issues. As unused entries (all those -except 12 and 34) are zero-filled, gpiomux needs a way to distinguish -the used fields from the unused. In addition, the all-zero pattern -is a valid configuration! Therefore, gpiomux defines an additional bit -which is used to indicate when a field is used. This has the pleasant -side-effect of allowing calls to msm_gpiomux_write to use '0' to indicate -that a value should not be changed: - - msm_gpiomux_write(0, GPIOMUX_VALID, 0); - -replaces the active configuration of gpio 0 with an all-zero configuration, -but leaves the suspended configuration as it was. - -Static Configurations -===================== - -To install a static configuration, which is applied at boot and does -not change after that, install a configuration with a suspended component -but no active component, as in the previous example: - - [34] = { - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, - -The suspended setting is applied during boot, and the lack of any valid -active setting prevents any other setting from being applied at runtime. -If other subsystems attempting to access the line is a concern, one could -*really* anchor the configuration down by calling msm_gpiomux_get on the -line at initialization to move the line into active mode. With the line -held, it will never be re-suspended, and with no valid active configuration, -no new configurations will be applied. - -But then, if having other subsystems grabbing for the line is truly a concern, -it should be reserved with gpio_request instead, which carries an implicit -msm_gpiomux_get. - -gpiomux and gpiolib -=================== - -It is expected that msm gpio_chips will call msm_gpiomux_get() and -msm_gpiomux_put() from their request and free hooks, like this fictional -example: - -static int request(struct gpio_chip *chip, unsigned offset) -{ - return msm_gpiomux_get(chip->base + offset); -} - -static void free(struct gpio_chip *chip, unsigned offset) -{ - msm_gpiomux_put(chip->base + offset); -} - - ...somewhere in a gpio_chip declaration... - .request = request, - .free = free, - -This provides important functionality: -- It guarantees that a gpio line will have its 'active' config applied - when the line is requested, and will not be suspended while the line - remains requested; and -- It guarantees that gpio-direction settings from gpiolib behave sensibly. - See "About Output-Enable Settings." - -This mechanism allows for "auto-request" of gpiomux lines via gpiolib -when it is suitable. Drivers wishing more exact control are, of course, -free to also use msm_gpiomux_set and msm_gpiomux_get. - -About Output-Enable Settings -============================ - -Some msm targets do not have the ability to query the current gpio -configuration setting. This means that changes made to the output-enable -(OE) bit by gpiolib cannot be consistently detected and preserved by gpiomux. -Therefore, when gpiomux applies a configuration setting, any direction -settings which may have been applied by gpiolib are lost and the default -input settings are re-applied. - -For this reason, drivers should not assume that gpio direction settings -continue to hold if they free and then re-request a gpio. This seems like -common sense - after all, anybody could have obtained the line in the -meantime - but it needs saying. - -This also means that calls to msm_gpiomux_write will reset the OE bit, -which means that if the gpio line is held by a client of gpiolib and -msm_gpiomux_write is called, the direction setting has been lost and -gpiolib's internal state has been broken. -Release gpio lines before reconfiguring them. diff --git a/trunk/Documentation/block/cfq-iosched.txt b/trunk/Documentation/block/cfq-iosched.txt deleted file mode 100644 index e578feed6d81..000000000000 --- a/trunk/Documentation/block/cfq-iosched.txt +++ /dev/null @@ -1,45 +0,0 @@ -CFQ ioscheduler tunables -======================== - -slice_idle ----------- -This specifies how long CFQ should idle for next request on certain cfq queues -(for sequential workloads) and service trees (for random workloads) before -queue is expired and CFQ selects next queue to dispatch from. - -By default slice_idle is a non-zero value. That means by default we idle on -queues/service trees. This can be very helpful on highly seeky media like -single spindle SATA/SAS disks where we can cut down on overall number of -seeks and see improved throughput. - -Setting slice_idle to 0 will remove all the idling on queues/service tree -level and one should see an overall improved throughput on faster storage -devices like multiple SATA/SAS disks in hardware RAID configuration. The down -side is that isolation provided from WRITES also goes down and notion of -IO priority becomes weaker. - -So depending on storage and workload, it might be useful to set slice_idle=0. -In general I think for SATA/SAS disks and software RAID of SATA/SAS disks -keeping slice_idle enabled should be useful. For any configurations where -there are multiple spindles behind single LUN (Host based hardware RAID -controller or for storage arrays), setting slice_idle=0 might end up in better -throughput and acceptable latencies. - -CFQ IOPS Mode for group scheduling -=================================== -Basic CFQ design is to provide priority based time slices. Higher priority -process gets bigger time slice and lower priority process gets smaller time -slice. Measuring time becomes harder if storage is fast and supports NCQ and -it would be better to dispatch multiple requests from multiple cfq queues in -request queue at a time. In such scenario, it is not possible to measure time -consumed by single queue accurately. - -What is possible though is to measure number of requests dispatched from a -single queue and also allow dispatch from multiple cfq queue at the same time. -This effectively becomes the fairness in terms of IOPS (IO operations per -second). - -If one sets slice_idle=0 and if storage supports NCQ, CFQ internally switches -to IOPS mode and starts providing fairness in terms of number of requests -dispatched. Note that this mode switching takes effect only for group -scheduling. For non-cgroup users nothing should change. diff --git a/trunk/Documentation/cgroups/blkio-controller.txt b/trunk/Documentation/cgroups/blkio-controller.txt index d6da611f8f63..48e0b21b0059 100644 --- a/trunk/Documentation/cgroups/blkio-controller.txt +++ b/trunk/Documentation/cgroups/blkio-controller.txt @@ -8,17 +8,12 @@ both at leaf nodes as well as at intermediate nodes in a storage hierarchy. Plan is to use the same cgroup based management interface for blkio controller and based on user options switch IO policies in the background. -Currently two IO control policies are implemented. First one is proportional -weight time based division of disk policy. It is implemented in CFQ. Hence -this policy takes effect only on leaf nodes when CFQ is being used. The second -one is throttling policy which can be used to specify upper IO rate limits -on devices. This policy is implemented in generic block layer and can be -used on leaf nodes as well as higher level logical devices like device mapper. +In the first phase, this patchset implements proportional weight time based +division of disk policy. It is implemented in CFQ. Hence this policy takes +effect only on leaf nodes when CFQ is being used. HOWTO ===== -Proportional Weight division of bandwidth ------------------------------------------ You can do a very simple testing of running two dd threads in two different cgroups. Here is what you can do. @@ -60,35 +55,6 @@ cgroups. Here is what you can do. group dispatched to the disk. We provide fairness in terms of disk time, so ideally io.disk_time of cgroups should be in proportion to the weight. -Throttling/Upper Limit policy ------------------------------ -- Enable Block IO controller - CONFIG_BLK_CGROUP=y - -- Enable throttling in block layer - CONFIG_BLK_DEV_THROTTLING=y - -- Mount blkio controller - mount -t cgroup -o blkio none /cgroup/blkio - -- Specify a bandwidth rate on particular device for root group. The format - for policy is ": ". - - echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device - - Above will put a limit of 1MB/second on reads happening for root group - on device having major/minor number 8:16. - -- Run dd to read a file and see if rate is throttled to 1MB/s or not. - - # dd if=/mnt/common/zerofile of=/dev/null bs=4K count=1024 - # iflag=direct - 1024+0 records in - 1024+0 records out - 4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s - - Limits for writes can be put using blkio.write_bps_device file. - Various user visible config options =================================== CONFIG_BLK_CGROUP @@ -102,13 +68,8 @@ CONFIG_CFQ_GROUP_IOSCHED - Enables group scheduling in CFQ. Currently only 1 level of group creation is allowed. -CONFIG_BLK_DEV_THROTTLING - - Enable block device throttling support in block layer. - Details of cgroup files ======================= -Proportional weight policy files --------------------------------- - blkio.weight - Specifies per cgroup weight. This is default weight of the group on all the devices until and unless overridden by per device rule. @@ -249,67 +210,6 @@ Proportional weight policy files and minor number of the device and third field specifies the number of times a group was dequeued from a particular device. -Throttling/Upper limit policy files ------------------------------------ -- blkio.throttle.read_bps_device - - Specifies upper limit on READ rate from the device. IO rate is - specified in bytes per second. Rules are per deivce. Following is - the format. - - echo ": " > /cgrp/blkio.read_bps_device - -- blkio.throttle.write_bps_device - - Specifies upper limit on WRITE rate to the device. IO rate is - specified in bytes per second. Rules are per deivce. Following is - the format. - - echo ": " > /cgrp/blkio.write_bps_device - -- blkio.throttle.read_iops_device - - Specifies upper limit on READ rate from the device. IO rate is - specified in IO per second. Rules are per deivce. Following is - the format. - - echo ": " > /cgrp/blkio.read_iops_device - -- blkio.throttle.write_iops_device - - Specifies upper limit on WRITE rate to the device. IO rate is - specified in io per second. Rules are per deivce. Following is - the format. - - echo ": " > /cgrp/blkio.write_iops_device - -Note: If both BW and IOPS rules are specified for a device, then IO is - subjectd to both the constraints. - -- blkio.throttle.io_serviced - - Number of IOs (bio) completed to/from the disk by the group (as - seen by throttling policy). These are further divided by the type - of operation - read or write, sync or async. First two fields specify - the major and minor number of the device, third field specifies the - operation type and the fourth field specifies the number of IOs. - - blkio.io_serviced does accounting as seen by CFQ and counts are in - number of requests (struct request). On the other hand, - blkio.throttle.io_serviced counts number of IO in terms of number - of bios as seen by throttling policy. These bios can later be - merged by elevator and total number of requests completed can be - lesser. - -- blkio.throttle.io_service_bytes - - Number of bytes transferred to/from the disk by the group. These - are further divided by the type of operation - read or write, sync - or async. First two fields specify the major and minor number of the - device, third field specifies the operation type and the fourth field - specifies the number of bytes. - - These numbers should roughly be same as blkio.io_service_bytes as - updated by CFQ. The difference between two is that - blkio.io_service_bytes will not be updated if CFQ is not operating - on request queue. - -Common files among various policies ------------------------------------ - blkio.reset_stats - Writing an int to this file will result in resetting all the stats for that cgroup. @@ -317,7 +217,6 @@ Common files among various policies CFQ sysfs tunable ================= /sys/block//queue/iosched/group_isolation ------------------------------------------------ If group_isolation=1, it provides stronger isolation between groups at the expense of throughput. By default group_isolation is 0. In general that @@ -344,33 +243,6 @@ By default one should run with group_isolation=0. If that is not sufficient and one wants stronger isolation between groups, then set group_isolation=1 but this will come at cost of reduced throughput. -/sys/block//queue/iosched/slice_idle ------------------------------------------- -On a faster hardware CFQ can be slow, especially with sequential workload. -This happens because CFQ idles on a single queue and single queue might not -drive deeper request queue depths to keep the storage busy. In such scenarios -one can try setting slice_idle=0 and that would switch CFQ to IOPS -(IO operations per second) mode on NCQ supporting hardware. - -That means CFQ will not idle between cfq queues of a cfq group and hence be -able to driver higher queue depth and achieve better throughput. That also -means that cfq provides fairness among groups in terms of IOPS and not in -terms of disk time. - -/sys/block//queue/iosched/group_idle ------------------------------------------- -If one disables idling on individual cfq queues and cfq service trees by -setting slice_idle=0, group_idle kicks in. That means CFQ will still idle -on the group in an attempt to provide fairness among groups. - -By default group_idle is same as slice_idle and does not do anything if -slice_idle is enabled. - -One can experience an overall throughput drop if you have created multiple -groups and put applications in that group which are not driving enough -IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle -on individual groups and throughput should improve. - What works ========== - Currently only sync IO queues are support. All the buffered writes are diff --git a/trunk/Documentation/cputopology.txt b/trunk/Documentation/cputopology.txt index 902d3151f527..f1c5c4bccd3e 100644 --- a/trunk/Documentation/cputopology.txt +++ b/trunk/Documentation/cputopology.txt @@ -14,39 +14,25 @@ to /proc/cpuinfo. identifier (rather than the kernel's). The actual value is architecture and platform dependent. -3) /sys/devices/system/cpu/cpuX/topology/book_id: - - the book ID of cpuX. Typically it is the hardware platform's - identifier (rather than the kernel's). The actual value is - architecture and platform dependent. - -4) /sys/devices/system/cpu/cpuX/topology/thread_siblings: +3) /sys/devices/system/cpu/cpuX/topology/thread_siblings: internel kernel map of cpuX's hardware threads within the same core as cpuX -5) /sys/devices/system/cpu/cpuX/topology/core_siblings: +4) /sys/devices/system/cpu/cpuX/topology/core_siblings: internal kernel map of cpuX's hardware threads within the same physical_package_id. -6) /sys/devices/system/cpu/cpuX/topology/book_siblings: - - internal kernel map of cpuX's hardware threads within the same - book_id. - To implement it in an architecture-neutral way, a new source file, -drivers/base/topology.c, is to export the 4 or 6 attributes. The two book -related sysfs files will only be created if CONFIG_SCHED_BOOK is selected. +drivers/base/topology.c, is to export the 4 attributes. For an architecture to support this feature, it must define some of these macros in include/asm-XXX/topology.h: #define topology_physical_package_id(cpu) #define topology_core_id(cpu) -#define topology_book_id(cpu) #define topology_thread_cpumask(cpu) #define topology_core_cpumask(cpu) -#define topology_book_cpumask(cpu) The type of **_id is int. The type of siblings is (const) struct cpumask *. @@ -59,9 +45,6 @@ not defined by include/asm-XXX/topology.h: 3) thread_siblings: just the given CPU 4) core_siblings: just the given CPU -For architectures that don't support books (CONFIG_SCHED_BOOK) there are no -default definitions for topology_book_id() and topology_book_cpumask(). - Additionally, CPU topology information is provided under /sys/devices/system/cpu and includes these files. The internal source for the output is in brackets ("[]"). diff --git a/trunk/Documentation/feature-removal-schedule.txt b/trunk/Documentation/feature-removal-schedule.txt index 5e2bc4ab897a..842aa9de84a6 100644 --- a/trunk/Documentation/feature-removal-schedule.txt +++ b/trunk/Documentation/feature-removal-schedule.txt @@ -386,6 +386,34 @@ Who: Tejun Heo ---------------------------- +What: Support for VMware's guest paravirtuliazation technique [VMI] will be + dropped. +When: 2.6.37 or earlier. +Why: With the recent innovations in CPU hardware acceleration technologies + from Intel and AMD, VMware ran a few experiments to compare these + techniques to guest paravirtualization technique on VMware's platform. + These hardware assisted virtualization techniques have outperformed the + performance benefits provided by VMI in most of the workloads. VMware + expects that these hardware features will be ubiquitous in a couple of + years, as a result, VMware has started a phased retirement of this + feature from the hypervisor. We will be removing this feature from the + Kernel too. Right now we are targeting 2.6.37 but can retire earlier if + technical reasons (read opportunity to remove major chunk of pvops) + arise. + + Please note that VMI has always been an optimization and non-VMI kernels + still work fine on VMware's platform. + Latest versions of VMware's product which support VMI are, + Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence + releases for these products will continue supporting VMI. + + For more details about VMI retirement take a look at this, + http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html + +Who: Alok N Kataria + +---------------------------- + What: Support for lcd_switch and display_get in asus-laptop driver When: March 2010 Why: These two features use non-standard interfaces. There are the diff --git a/trunk/Documentation/filesystems/ocfs2.txt b/trunk/Documentation/filesystems/ocfs2.txt index 5393e6611691..1f7ae144f6d8 100644 --- a/trunk/Documentation/filesystems/ocfs2.txt +++ b/trunk/Documentation/filesystems/ocfs2.txt @@ -87,10 +87,3 @@ dir_resv_level= (*) By default, directory reservations will scale with file reservations - users should rarely need to change this value. If allocation reservations are turned off, this option will have no effect. -coherency=full (*) Disallow concurrent O_DIRECT writes, cluster inode - lock will be taken to force other nodes drop cache, - therefore full cluster coherency is guaranteed even - for O_DIRECT writes. -coherency=buffered Allow concurrent O_DIRECT writes without EX lock among - nodes, which gains high performance at risk of getting - stale data on other nodes. diff --git a/trunk/Documentation/gpio.txt b/trunk/Documentation/gpio.txt index 9633da01ff46..d96a6dba5748 100644 --- a/trunk/Documentation/gpio.txt +++ b/trunk/Documentation/gpio.txt @@ -109,19 +109,17 @@ use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders. If you want to initialize a structure with an invalid GPIO number, use some negative number (perhaps "-EINVAL"); that will never be valid. To -test if such number from such a structure could reference a GPIO, you -may use this predicate: +test if a number could reference a GPIO, you may use this predicate: int gpio_is_valid(int number); A number that's not valid will be rejected by calls which may request or free GPIOs (see below). Other numbers may also be rejected; for -example, a number might be valid but temporarily unused on a given board. +example, a number might be valid but unused on a given board. + +Whether a platform supports multiple GPIO controllers is currently a +platform-specific implementation issue. -Whether a platform supports multiple GPIO controllers is a platform-specific -implementation issue, as are whether that support can leave "holes" in the space -of GPIO numbers, and whether new controllers can be added at runtime. Such issues -can affect things including whether adjacent GPIO numbers are both valid. Using GPIOs ----------- @@ -482,16 +480,12 @@ To support this framework, a platform's Kconfig will "select" either ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB and arrange that its includes and defines three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep(). +They may also want to provide a custom value for ARCH_NR_GPIOS. -It may also provide a custom value for ARCH_NR_GPIOS, so that it better -reflects the number of GPIOs in actual use on that platform, without -wasting static table space. (It should count both built-in/SoC GPIOs and -also ones on GPIO expanders. - -ARCH_REQUIRE_GPIOLIB means that the gpiolib code will always get compiled +ARCH_REQUIRE_GPIOLIB means that the gpio-lib code will always get compiled into the kernel on that architecture. -ARCH_WANT_OPTIONAL_GPIOLIB means the gpiolib code defaults to off and the user +ARCH_WANT_OPTIONAL_GPIOLIB means the gpio-lib code defaults to off and the user can enable it and build it into the kernel optionally. If neither of these options are selected, the platform does not support diff --git a/trunk/Documentation/hwmon/sysfs-interface b/trunk/Documentation/hwmon/sysfs-interface index 48ceabedf55d..ff45d1f837c8 100644 --- a/trunk/Documentation/hwmon/sysfs-interface +++ b/trunk/Documentation/hwmon/sysfs-interface @@ -91,11 +91,12 @@ name The chip name. I2C devices get this attribute created automatically. RO -update_interval The interval at which the chip will update readings. +update_rate The rate at which the chip will update readings. Unit: millisecond RW - Some devices have a variable update rate or interval. - This attribute can be used to change it to the desired value. + Some devices have a variable update rate. This attribute + can be used to change the update rate to the desired + frequency. ************ diff --git a/trunk/Documentation/kernel-doc-nano-HOWTO.txt b/trunk/Documentation/kernel-doc-nano-HOWTO.txt index 3d8a97747f77..27a52b35d55b 100644 --- a/trunk/Documentation/kernel-doc-nano-HOWTO.txt +++ b/trunk/Documentation/kernel-doc-nano-HOWTO.txt @@ -345,10 +345,5 @@ documentation, in , for the functions listed. section titled
from . Spaces are allowed in
; do not quote the
. -!C is replaced by nothing, but makes the tools check that -all DOC: sections and documented functions, symbols, etc. are used. -This makes sense to use when you use !F/!P only and want to verify -that all documentation is included. - Tim. */ diff --git a/trunk/Documentation/kernel-parameters.txt b/trunk/Documentation/kernel-parameters.txt index 02f21d9220ce..2c85c0692b01 100644 --- a/trunk/Documentation/kernel-parameters.txt +++ b/trunk/Documentation/kernel-parameters.txt @@ -455,7 +455,7 @@ and is between 256 and 4096 characters. It is defined in the file [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2, pxa_timer,timer3,32k_counter,timer0_1 [AVR32] avr32 - [X86-32] pit,hpet,tsc; + [X86-32] pit,hpet,tsc,vmi-timer; scx200_hrt on Geode; cyclone on IBM x440 [MIPS] MIPS [PARISC] cr16 @@ -1974,18 +1974,15 @@ and is between 256 and 4096 characters. It is defined in the file force Enable ASPM even on devices that claim not to support it. WARNING: Forcing ASPM on may cause system lockups. - pcie_ports= [PCIE] PCIe ports handling: - auto Ask the BIOS whether or not to use native PCIe services - associated with PCIe ports (PME, hot-plug, AER). Use - them only if that is allowed by the BIOS. - native Use native PCIe services associated with PCIe ports - unconditionally. - compat Treat PCIe ports as PCI-to-PCI bridges, disable the PCIe - ports driver. - pcie_pme= [PCIE,PM] Native PCIe PME signaling options: + Format: {auto|force}[,nomsi] + auto Use native PCIe PME signaling if the BIOS allows the + kernel to control PCIe config registers of root ports. + force Use native PCIe PME signaling even if the BIOS refuses + to allow the kernel to control the relevant PCIe config + registers. nomsi Do not use MSI for native PCIe PME signaling (this makes - all PCIe root ports use INTx for all services). + all PCIe root ports use INTx for everything). pcmv= [HW,PCMCIA] BadgePAD 4 @@ -2153,11 +2150,6 @@ and is between 256 and 4096 characters. It is defined in the file Reserves a hole at the top of the kernel virtual address space. - reservelow= [X86] - Format: nn[K] - Set the amount of memory to reserve for BIOS at - the bottom of the address space. - reset_devices [KNL] Force drivers to reset the underlying device during initialization. @@ -2170,11 +2162,6 @@ and is between 256 and 4096 characters. It is defined in the file in units (needed only for swap files). See Documentation/power/swsusp-and-swap-files.txt - hibernate= [HIBERNATION] - noresume Don't check if there's a hibernation image - present during boot. - nocompress Don't compress/decompress hibernation images. - retain_initrd [RAM] Keep initrd memory after extraction rhash_entries= [KNL,NET] @@ -2445,10 +2432,6 @@ and is between 256 and 4096 characters. It is defined in the file disables clocksource verification at runtime. Used to enable high-resolution timer mode on older hardware, and in virtualized environment. - [x86] noirqtime: Do not use TSC to do irq accounting. - Used to run time disable IRQ_TIME_ACCOUNTING on any - platforms where RDTSC is slow and this accounting - can add overhead. turbografx.map[2|3]= [HW,JOY] TurboGraFX parallel port interface @@ -2646,10 +2629,8 @@ and is between 256 and 4096 characters. It is defined in the file aux-ide-disks -- unplug non-primary-master IDE devices nics -- unplug network devices all -- unplug all emulated devices (NICs and IDE disks) - unnecessary -- unplugging emulated devices is - unnecessary even if the host did not respond to - the unplug protocol - never -- do not unplug even if version check succeeds + ignore -- continue loading the Xen platform PCI driver even + if the version check failed xirc2ps_cs= [NET,PCMCIA] Format: diff --git a/trunk/Documentation/kprobes.txt b/trunk/Documentation/kprobes.txt index 741fe66d6eca..1762b81fcdf2 100644 --- a/trunk/Documentation/kprobes.txt +++ b/trunk/Documentation/kprobes.txt @@ -542,11 +542,9 @@ Kprobes does not use mutexes or allocate memory except during registration and unregistration. Probe handlers are run with preemption disabled. Depending on the -architecture and optimization state, handlers may also run with -interrupts disabled (e.g., kretprobe handlers and optimized kprobe -handlers run without interrupt disabled on x86/x86-64). In any case, -your handler should not yield the CPU (e.g., by attempting to acquire -a semaphore). +architecture, handlers may also run with interrupts disabled. In any +case, your handler should not yield the CPU (e.g., by attempting to +acquire a semaphore). Since a return probe is implemented by replacing the return address with the trampoline's address, stack backtraces and calls diff --git a/trunk/Documentation/lguest/Makefile b/trunk/Documentation/lguest/Makefile index bebac6b4f332..28c8cdfcafd8 100644 --- a/trunk/Documentation/lguest/Makefile +++ b/trunk/Documentation/lguest/Makefile @@ -1,6 +1,5 @@ # This creates the demonstration utility "lguest" which runs a Linux guest. -# Missing headers? Add "-I../../include -I../../arch/x86/include" -CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE +CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE all: lguest diff --git a/trunk/Documentation/lguest/lguest.c b/trunk/Documentation/lguest/lguest.c index 8a6a8c6d4980..e9ce3c554514 100644 --- a/trunk/Documentation/lguest/lguest.c +++ b/trunk/Documentation/lguest/lguest.c @@ -39,14 +39,14 @@ #include #include #include -#include -#include -#include -#include -#include -#include -#include -#include "../../include/linux/lguest_launcher.h" +#include "linux/lguest_launcher.h" +#include "linux/virtio_config.h" +#include "linux/virtio_net.h" +#include "linux/virtio_blk.h" +#include "linux/virtio_console.h" +#include "linux/virtio_rng.h" +#include "linux/virtio_ring.h" +#include "asm/bootparam.h" /*L:110 * We can ignore the 42 include files we need for this program, but I do want * to draw attention to the use of kernel-style types. @@ -1447,15 +1447,14 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name) static void configure_device(int fd, const char *tapif, u32 ipaddr) { struct ifreq ifr; - struct sockaddr_in sin; + struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr; memset(&ifr, 0, sizeof(ifr)); strcpy(ifr.ifr_name, tapif); /* Don't read these incantations. Just cut & paste them like I did! */ - sin.sin_family = AF_INET; - sin.sin_addr.s_addr = htonl(ipaddr); - memcpy(&ifr.ifr_addr, &sin, sizeof(sin)); + sin->sin_family = AF_INET; + sin->sin_addr.s_addr = htonl(ipaddr); if (ioctl(fd, SIOCSIFADDR, &ifr) != 0) err(1, "Setting %s interface address", tapif); ifr.ifr_flags = IFF_UP; diff --git a/trunk/Documentation/mutex-design.txt b/trunk/Documentation/mutex-design.txt index 38c10fd7f411..c91ccc0720fa 100644 --- a/trunk/Documentation/mutex-design.txt +++ b/trunk/Documentation/mutex-design.txt @@ -9,7 +9,7 @@ firstly, there's nothing wrong with semaphores. But if the simpler mutex semantics are sufficient for your code, then there are a couple of advantages of mutexes: - - 'struct mutex' is smaller on most architectures: E.g. on x86, + - 'struct mutex' is smaller on most architectures: .e.g on x86, 'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes. A smaller structure size means less RAM footprint, and better CPU-cache utilization. @@ -136,4 +136,3 @@ the APIs of 'struct mutex' have been streamlined: void mutex_lock_nested(struct mutex *lock, unsigned int subclass); int mutex_lock_interruptible_nested(struct mutex *lock, unsigned int subclass); - int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock); diff --git a/trunk/Documentation/networking/e1000.txt b/trunk/Documentation/networking/e1000.txt index d9271e74e488..2df71861e578 100644 --- a/trunk/Documentation/networking/e1000.txt +++ b/trunk/Documentation/networking/e1000.txt @@ -1,35 +1,82 @@ Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters =============================================================== -Intel Gigabit Linux driver. -Copyright(c) 1999 - 2010 Intel Corporation. +September 26, 2006 + Contents ======== +- In This Release - Identifying Your Adapter +- Building and Installation - Command Line Parameters - Speed and Duplex Configuration - Additional Configurations +- Known Issues - Support + +In This Release +=============== + +This file describes the Linux* Base Driver for the Intel(R) PRO/1000 Family +of Adapters. This driver includes support for Itanium(R)2-based systems. + +For questions related to hardware requirements, refer to the documentation +supplied with your Intel PRO/1000 adapter. All hardware requirements listed +apply to use with Linux. + +The following features are now available in supported kernels: + - Native VLANs + - Channel Bonding (teaming) + - SNMP + +Channel Bonding documentation can be found in the Linux kernel source: +/Documentation/networking/bonding.txt + +The driver information previously displayed in the /proc filesystem is not +supported in this release. Alternatively, you can use ethtool (version 1.6 +or later), lspci, and ifconfig to obtain the same information. + +Instructions on updating ethtool can be found in the section "Additional +Configurations" later in this document. + +NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100 +support. + + Identifying Your Adapter ======================== For more information on how to identify your adapter, go to the Adapter & Driver ID Guide at: - http://support.intel.com/support/go/network/adapter/idguide.htm + http://support.intel.com/support/network/adapter/pro100/21397.htm For the latest Intel network drivers for Linux, refer to the following website. In the search field, enter your adapter name or type, or use the networking link on the left to search for your adapter: - http://support.intel.com/support/go/network/adapter/home.htm + http://downloadfinder.intel.com/scripts-df/support_intel.asp + Command Line Parameters ======================= +If the driver is built as a module, the following optional parameters +are used by entering them on the command line with the modprobe command +using this syntax: + + modprobe e1000 [