---

yaml
---
r: 11461
b: refs/heads/master
c: 9f49758
h: refs/heads/master
i:
  11459: a78d2c0
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 14cf11af6cf608eb8c23e989ddb17a715ddce109
+refs/heads/master: 9f497581fda5fd804e9ebd7d8f6d80c3a0e9f883

trunk/Documentation/DocBook/kernel-hacking.tmpl

@@ -1105,7 +1105,7 @@ static struct block_device_operations opt_fops = {
     </listitem>
     <listitem>
      <para>
-      Function names as strings (__FUNCTION__).
+      Function names as strings (__func__).
      </para>
     </listitem>
     <listitem>

trunk/Documentation/sparse.txt

@@ -51,9 +51,9 @@ or you don't get any checking at all.
 Where to get sparse
 ~~~~~~~~~~~~~~~~~~~
 
-With git, you can just get it from
+With BK, you can just get it from
 
-        rsync://rsync.kernel.org/pub/scm/devel/sparse/sparse.git
+        bk://sparse.bkbits.net/sparse
 
 and DaveJ has tar-balls at
 

trunk/Documentation/usb/URB.txt

@@ -1,6 +1,5 @@
 Revised: 2000-Dec-05.
 Again:   2002-Jul-06
-Again:   2005-Sep-19
 
     NOTE:
 
@@ -19,8 +18,8 @@ called USB Request Block, or URB for short.
   and deliver the data and status back. 
 
 - Execution of an URB is inherently an asynchronous operation, i.e. the 
-  usb_submit_urb(urb) call returns immediately after it has successfully
-  queued the requested action.
+  usb_submit_urb(urb) call returns immediately after it has successfully queued 
+  the requested action. 
 
 - Transfers for one URB can be canceled with usb_unlink_urb(urb) at any time. 
 
@@ -95,9 +94,8 @@ To free an URB, use
 
 	void usb_free_urb(struct urb *urb)
 
-You may free an urb that you've submitted, but which hasn't yet been
-returned to you in a completion callback.  It will automatically be
-deallocated when it is no longer in use.
+You may not free an urb that you've submitted, but which hasn't yet been
+returned to you in a completion callback.
 
 
 1.4. What has to be filled in?
@@ -147,48 +145,48 @@ to get seamless ISO streaming.
 
 1.6. How to cancel an already running URB?
 
-There are two ways to cancel an URB you've submitted but which hasn't
-been returned to your driver yet.  For an asynchronous cancel, call
+For an URB which you've submitted, but which hasn't been returned to
+your driver by the host controller, call
 
 	int usb_unlink_urb(struct urb *urb)
 
 It removes the urb from the internal list and frees all allocated
-HW descriptors. The status is changed to reflect unlinking.  Note
-that the URB will not normally have finished when usb_unlink_urb()
-returns; you must still wait for the completion handler to be called.
+HW descriptors. The status is changed to reflect unlinking. After 
+usb_unlink_urb() returns with that status code, you can free the URB
+with usb_free_urb().
 
-To cancel an URB synchronously, call
-
-	void usb_kill_urb(struct urb *urb)
-
-It does everything usb_unlink_urb does, and in addition it waits
-until after the URB has been returned and the completion handler
-has finished.  It also marks the URB as temporarily unusable, so
-that if the completion handler or anyone else tries to resubmit it
-they will get a -EPERM error.  Thus you can be sure that when
-usb_kill_urb() returns, the URB is totally idle.
+There is also an asynchronous unlink mode.  To use this, set the
+the URB_ASYNC_UNLINK flag in urb->transfer flags before calling
+usb_unlink_urb().  When using async unlinking, the URB will not
+normally be unlinked when usb_unlink_urb() returns.  Instead, wait
+for the completion handler to be called.
 
 
 1.7. What about the completion handler?
 
 The handler is of the following type:
 
-	typedef void (*usb_complete_t)(struct urb *, struct pt_regs *)
+	typedef void (*usb_complete_t)(struct urb *);
 
-I.e., it gets the URB that caused the completion call, plus the
-register values at the time of the corresponding interrupt (if any).
+i.e. it gets just the URB that caused the completion call.
 In the completion handler, you should have a look at urb->status to
 detect any USB errors. Since the context parameter is included in the URB,
 you can pass information to the completion handler. 
 
 Note that even when an error (or unlink) is reported, data may have been
 transferred.  That's because USB transfers are packetized; it might take
 sixteen packets to transfer your 1KByte buffer, and ten of them might
-have transferred succesfully before the completion was called.
+have transferred succesfully before the completion is called.
 
 
 NOTE:  ***** WARNING *****
-NEVER SLEEP IN A COMPLETION HANDLER.  These are normally called
+Don't use urb->dev field in your completion handler; it's cleared
+as part of giving urbs back to drivers.  (Addressing an issue with
+ownership of periodic URBs, which was otherwise ambiguous.) Instead,
+use urb->context to hold all the data your driver needs.
+
+NOTE:  ***** WARNING *****
+Also, NEVER SLEEP IN A COMPLETION HANDLER.  These are normally called
 during hardware interrupt processing.  If you can, defer substantial
 work to a tasklet (bottom half) to keep system latencies low.  You'll
 probably need to use spinlocks to protect data structures you manipulate
@@ -231,10 +229,24 @@ ISO data with some other event stream.
 Interrupt transfers, like isochronous transfers, are periodic, and happen
 in intervals that are powers of two (1, 2, 4 etc) units.  Units are frames
 for full and low speed devices, and microframes for high speed ones.
+
+Currently, after you submit one interrupt URB, that urb is owned by the
+host controller driver until you cancel it with usb_unlink_urb().  You
+may unlink interrupt urbs in their completion handlers, if you need to.
+
+After a transfer completion is called, the URB is automagically resubmitted.
+THIS BEHAVIOR IS EXPECTED TO BE REMOVED!!
+
+Interrupt transfers may only send (or receive) the "maxpacket" value for
+the given interrupt endpoint; if you need more data, you will need to
+copy that data out of (or into) another buffer.  Similarly, you can't
+queue interrupt transfers.
+THESE RESTRICTIONS ARE EXPECTED TO BE REMOVED!!
+
+Note that this automagic resubmission model does make it awkward to use
+interrupt OUT transfers.  The portable solution involves unlinking those
+OUT urbs after the data is transferred, and perhaps submitting a final
+URB for a short packet.
+
 The usb_submit_urb() call modifies urb->interval to the implemented interval
 value that is less than or equal to the requested interval value.
-
-In Linux 2.6, unlike earlier versions, interrupt URBs are not automagically
-restarted when they complete.  They end when the completion handler is
-called, just like other URBs.  If you want an interrupt URB to be restarted,
-your completion handler must resubmit it.

trunk/MAINTAINERS

@@ -1063,6 +1063,8 @@ M:	wli@holomorphy.com
 S:	Maintained
 
 I2C SUBSYSTEM
+P:	Greg Kroah-Hartman
+M:	greg@kroah.com
 P:	Jean Delvare
 M:	khali@linux-fr.org
 L:	lm-sensors@lm-sensors.org
@@ -1402,18 +1404,6 @@ L:	linux-kernel@vger.kernel.org
 L:	fastboot@osdl.org
 S:	Maintained
 
-KPROBES
-P:	Prasanna S Panchamukhi
-M:	prasanna@in.ibm.com
-P:	Ananth N Mavinakayanahalli
-M:	ananth@in.ibm.com
-P:	Anil S Keshavamurthy
-M:	anil.s.keshavamurthy@intel.com
-P:	David S. Miller
-M:	davem@davemloft.net
-L:	linux-kernel@vger.kernel.org
-S:	Maintained
-
 LANMEDIA WAN CARD DRIVER
 P:	Andrew Stanley-Jones
 M:	asj@lanmedia.com
@@ -2276,12 +2266,6 @@ M:	kristen.c.accardi@intel.com
 L:	pcihpd-discuss@lists.sourceforge.net
 S:	Maintained
 
-SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
-P:	Stephen Hemminger
-M:	shemminger@osdl.org
-L:	netdev@vger.kernel.org
-S:	Maintained
-
 SPARC (sparc32):
 P:	William L. Irwin
 M:	wli@holomorphy.com

trunk/Makefile

@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 14
-EXTRAVERSION =-rc2
+EXTRAVERSION =-rc1
 NAME=Affluent Albatross
 
 # *DOCUMENTATION*

trunk/README

@@ -149,9 +149,6 @@ CONFIGURING the kernel:
 	"make gconfig"     X windows (Gtk) based configuration tool.
 	"make oldconfig"   Default all questions based on the contents of
 			   your existing ./.config file.
-	"make silentoldconfig"
-			   Like above, but avoids cluttering the screen
-			   with questions already answered.
 
 	NOTES on "make config":
 	- having unnecessary drivers will make the kernel bigger, and can
@@ -172,6 +169,9 @@ CONFIGURING the kernel:
 	  should probably answer 'n' to the questions for
           "development", "experimental", or "debugging" features.
 
+ - Check the top Makefile for further site-dependent configuration
+   (default SVGA mode etc). 
+
 COMPILING the kernel:
 
  - Make sure you have gcc 2.95.3 available.
@@ -199,9 +199,6 @@ COMPILING the kernel:
    are installing a new kernel with the same version number as your
    working kernel, make a backup of your modules directory before you
    do a "make modules_install".
-   Alternatively, before compiling, use the kernel config option
-   "LOCALVERSION" to append a unique suffix to the regular kernel version.
-   LOCALVERSION can be set in the "General Setup" menu.
 
  - In order to boot your new kernel, you'll need to copy the kernel
    image (e.g. .../linux/arch/i386/boot/bzImage after compilation)

trunk/arch/alpha/kernel/process.c

@@ -127,10 +127,6 @@ common_shutdown_1(void *generic_ptr)
 	/* If booted from SRM, reset some of the original environment. */
 	if (alpha_using_srm) {
 #ifdef CONFIG_DUMMY_CONSOLE
-		/* If we've gotten here after SysRq-b, leave interrupt
-		   context before taking over the console. */
-		if (in_interrupt())
-			irq_exit();
 		/* This has the effect of resetting the VGA video origin.  */
 		take_over_console(&dummy_con, 0, MAX_NR_CONSOLES-1, 1);
 #endif