---

yaml
---
r: 68307
b: refs/heads/master
c: 1ef7cbb
h: refs/heads/master
i:
  68305: 5a7f0b9
  68303: 3caac31
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: dcf397f037f52add9945eced57ca300ab6a4413c
+refs/heads/master: 1ef7cbbe2157274a7003e78ef60b7ad885a970b8

trunk/CREDITS

@@ -665,11 +665,6 @@ D: Minor updates to SCSI types, added /proc/pid/maps protection
 S: (ask for current address)
 S: USA
 
-N: Robin Cornelius
-E: robincornelius@users.sourceforge.net
-D: Ralink rt2x00 WLAN driver
-S: Cornwall, U.K.
-
 N: Mark Corner
 E: mcorner@umich.edu
 W: http://www.eecs.umich.edu/~mcorner/
@@ -684,11 +679,6 @@ D: Kernel module SMART utilities
 S: Santa Cruz, California
 S: USA
 
-N: Luis Correia
-E: lfcorreia@users.sf.net
-D: Ralink rt2x00 WLAN driver
-S: Belas, Portugal
-
 N: Alan Cox
 W: http://www.linux.org.uk/diary/
 D: Linux Networking (0.99.10->2.0.29)
@@ -843,12 +833,6 @@ S: Lancs
 S: PR4 6AX
 S: United Kingdom
 
-N: Ivo van Doorn
-E: IvDoorn@gmail.com
-W: http://www.mendiosus.nl
-D: Ralink rt2x00 WLAN driver
-S: Haarlem, The Netherlands
-
 N: John G Dorsey
 E: john+@cs.cmu.edu
 D: ARM Linux ports to Assabet/Neponset, Spot
@@ -3533,12 +3517,6 @@ S: Maastrichterweg 63
 S: 5554 GG Valkenswaard
 S: The Netherlands
 
-N: Mark Wallis
-E: mwallis@serialmonkey.com
-W: http://mark.serialmonkey.com
-D: Ralink rt2x00 WLAN driver
-S: Newcastle, Australia
-
 N: Peter Shaobo Wang
 E: pwang@mmdcorp.com
 W: http://www.mmdcorp.com/pw/linux
@@ -3673,15 +3651,6 @@ S: Alte Regensburger Str. 11a
 S: 93149 Nittenau
 S: Germany
 
-N: Gertjan van Wingerde
-E: gwingerde@home.nl
-D: Ralink rt2x00 WLAN driver
-D: Minix V2 file-system
-D: Misc fixes
-S: Geessinkweg 177
-S: 7544 TX Enschede
-S: The Netherlands
-
 N: Lars Wirzenius
 E: liw@iki.fi
 D: Linux System Administrator's Guide, author, former maintainer

trunk/Documentation/DMA-API.txt

@@ -68,9 +68,6 @@ size and dma_handle must all be the same as those passed into the
 consistent allocate.  cpu_addr must be the virtual address returned by
 the consistent allocate.
 
-Note that unlike their sibling allocation calls, these routines
-may only be called with IRQs enabled.
-
 
 Part Ib - Using small dma-coherent buffers
 ------------------------------------------

trunk/Documentation/DocBook/Makefile

@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
 	    procfs-guide.xml writing_usb_driver.xml \
 	    kernel-api.xml filesystems.xml lsm.xml usb.xml \
 	    gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-	    genericirq.xml s390-drivers.xml
+	    genericirq.xml
 
 ###
 # The build process is as follows (targets):

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -240,23 +240,17 @@ X!Ilib/string.c
      <sect1><title>Driver Support</title>
 !Enet/core/dev.c
 !Enet/ethernet/eth.c
-!Enet/sched/sch_generic.c
 !Iinclude/linux/etherdevice.h
-!Iinclude/linux/netdevice.h
-     </sect1>
-     <sect1><title>PHY Support</title>
 !Edrivers/net/phy/phy.c
 !Idrivers/net/phy/phy.c
 !Edrivers/net/phy/phy_device.c
 !Idrivers/net/phy/phy_device.c
 !Edrivers/net/phy/mdio_bus.c
 !Idrivers/net/phy/mdio_bus.c
-     </sect1>
 <!-- FIXME: Removed for now since no structured comments in source
-     <sect1><title>Wireless</title>
 X!Enet/core/wireless.c
-     </sect1>
 -->
+     </sect1>
      <sect1><title>Synchronous PPP</title>
 !Edrivers/net/wan/syncppp.c
      </sect1>

trunk/Documentation/MSI-HOWTO.txt

@@ -241,7 +241,68 @@ address space of the MSI-X table/MSI-X PBA. Otherwise, the PCI subsystem
 will fail enabling MSI-X on its hardware device when it calls the function
 pci_enable_msix().
 
-5.3.2 API pci_enable_msix
+5.3.2 Handling MSI-X allocation
+
+Determining the number of MSI-X vectors allocated to a function is
+dependent on the number of MSI capable devices and MSI-X capable
+devices populated in the system. The policy of allocating MSI-X
+vectors to a function is defined as the following:
+
+#of MSI-X vectors allocated to a function = (x - y)/z where
+
+x = 	The number of available PCI vector resources by the time
+	the device driver calls pci_enable_msix(). The PCI vector
+	resources is the sum of the number of unassigned vectors
+	(new) and the number of released vectors when any MSI/MSI-X
+	device driver switches its hardware device back to a legacy
+	mode or is hot-removed.	The number of unassigned vectors
+	may exclude some vectors reserved, as defined in parameter
+	NR_HP_RESERVED_VECTORS, for the case where the system is
+	capable of supporting hot-add/hot-remove operations. Users
+	may change the value defined in NR_HR_RESERVED_VECTORS to
+	meet their specific needs.
+
+y =	The number of MSI capable devices populated in the system.
+	This policy ensures that each MSI capable device has its
+	vector reserved to avoid the case where some MSI-X capable
+	drivers may attempt to claim all available vector resources.
+
+z =	The number of MSI-X capable devices populated in the system.
+	This policy ensures that maximum (x - y) is distributed
+	evenly among MSI-X capable devices.
+
+Note that the PCI subsystem scans y and z during a bus enumeration.
+When the PCI subsystem completes configuring MSI/MSI-X capability
+structure of a device as requested by its device driver, y/z is
+decremented accordingly.
+
+5.3.3 Handling MSI-X shortages
+
+For the case where fewer MSI-X vectors are allocated to a function
+than requested, the function pci_enable_msix() will return the
+maximum number of MSI-X vectors available to the caller. A device
+driver may re-send its request with fewer or equal vectors indicated
+in the return. For example, if a device driver requests 5 vectors, but
+the number of available vectors is 3 vectors, a value of 3 will be
+returned as a result of pci_enable_msix() call. A function could be
+designed for its driver to use only 3 MSI-X table entries as
+different combinations as ABC--, A-B-C, A--CB, etc. Note that this
+patch does not support multiple entries with the same vector. Such
+attempt by a device driver to use 5 MSI-X table entries with 3 vectors
+as ABBCC, AABCC, BCCBA, etc will result as a failure by the function
+pci_enable_msix(). Below are the reasons why supporting multiple
+entries with the same vector is an undesirable solution.
+
+	- The PCI subsystem cannot determine the entry that
+	  generated the message to mask/unmask MSI while handling
+	  software driver ISR. Attempting to walk through all MSI-X
+	  table entries (2048 max) to mask/unmask any match vector
+	  is an undesirable solution.
+
+	- Walking through all MSI-X table entries (2048 max) to handle
+	  SMP affinity of any match vector is an undesirable solution.
+
+5.3.4 API pci_enable_msix
 
 int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
 
@@ -278,7 +339,7 @@ a failure. This failure may be a result of duplicate entries
 specified in second argument, or a result of no available vector,
 or a result of failing to initialize MSI-X table entries.
 
-5.3.3 API pci_disable_msix
+5.3.5 API pci_disable_msix
 
 void pci_disable_msix(struct pci_dev *dev)
 
@@ -288,7 +349,7 @@ always call free_irq() on all MSI-X vectors it has done request_irq()
 on before calling this API. Failure to do so results in a BUG_ON() and
 a device will be left with MSI-X enabled and leaks its vectors.
 
-5.3.4 MSI-X mode vs. legacy mode diagram
+5.3.6 MSI-X mode vs. legacy mode diagram
 
 The below diagram shows the events which switch the interrupt
 mode on the MSI-X capable device function between MSI-X mode and
@@ -346,7 +407,7 @@ between MSI mod MSI-X mode during a run-time.
 MSI/MSI-X support requires support from both system hardware and
 individual hardware device functions.
 
-5.5.1 Required x86 hardware support
+5.5.1 System hardware support
 
 Since the target of MSI address is the local APIC CPU, enabling
 MSI/MSI-X support in the Linux kernel is dependent on whether existing

trunk/Documentation/block/biodoc.txt

@@ -477,9 +477,9 @@ With this multipage bio design:
   the same bi_io_vec array, but with the index and size accordingly modified)
 - A linked list of bios is used as before for unrelated merges (*) - this
   avoids reallocs and makes independent completions easier to handle.
-- Code that traverses the req list can find all the segments of a bio
-  by using rq_for_each_segment.  This handles the fact that a request
-  has multiple bios, each of which can have multiple segments.
+- Code that traverses the req list needs to make a distinction between
+  segments of a request (bio_for_each_segment) and the distinct completion
+  units/bios (rq_for_each_bio).
 - Drivers which can't process a large bio in one shot can use the bi_idx
   field to keep track of the next bio_vec entry to process.
   (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
@@ -664,14 +664,14 @@ in lvm or md.
 
 3.2.1 Traversing segments and completion units in a request
 
-The macro rq_for_each_segment() should be used for traversing the bios
-in the request list (drivers should avoid directly trying to do it
-themselves). Using these helpers should also make it easier to cope
-with block changes in the future.
+The macros bio_for_each_segment() and rq_for_each_bio() should be used for
+traversing the bios in the request list (drivers should avoid directly
+trying to do it themselves). Using these helpers should also make it easier
+to cope with block changes in the future.
 
-	struct req_iterator iter;
-	rq_for_each_segment(bio_vec, rq, iter)
-		/* bio_vec is now current segment */
+	rq_for_each_bio(bio, rq)
+		bio_for_each_segment(bio_vec, bio, i)
+			/* bio_vec is now current segment */
 
 I/O completion callbacks are per-bio rather than per-segment, so drivers
 that traverse bio chains on completion need to keep that in mind. Drivers