what is the protocol for getting patches into the tree?

[Robert P. J. Day]

   (i emailed dan m. offline about this earlier, but i have no way of 
knowing if he's the right person to ask, so i'll post here and try to 
settle this once and for all.)

   *what* does it take to get a patch into the bk-managed kernel source 
tree at http://ppc.bkbits.net:8080/linuxppc-2.5.  originally, as i was 
learning the ropes here and started to make suggestions, i was told, 
in no uncertain terms, to "submit a patch".

   once i figured out what i wanted, i did indeed start submitting 
patches.  and, without exception (as far as i can tell), every one of 
them was discarded without acknowledgement or any reason for 
rejection.  at this point, i'm sure you can appreciate that the 
frustration level is starting to build.  it's not terribly productive 
to be told to submit patches, when whatever time i put into doing so 
turns out to be a complete waste of time.

   is this even the right place for such patches?  or should i be 
submitting to the LKML list proper?  or what?  i'm more than willing 
to follow the instructions for doing this the right way, i just need 
to know what the right way is.

   what follows is (for ... what ... the third time?), an attempt to 
just extend the smc_uart struct in commproc.h to add a relocation 
pointer.  there's no reason i can think of why this shouldn't be 
applied.  it can't possible break anything, it adds functionality, and 
it makes that struct consistent with the I2C and SPI structs that have 
analogous relocation pointers.  what's not to accept?  (it also makes 
an aesthetic change to that file to define reserved chunks of structs 
with a standard "char", rather than with the really hideous practice 
of using int, short or whatever size the reserved space happens to 
represent.  but if people are offended by that *change*, i'll be happy 
to take it out.  i just want the gosh-darned relocation pointer.)

   i can submit sizable patches that try to do several related things 
at once, or i can do it two lines at a time.  given the standard 
protocol over at LKML, am i expected to just keep submitting the same 
patch over and over, again and again, repeatedly, until it gets in? 
some guidance here would be appreciated.  is there a code word?  a 
secret handshake?  what?

   and now, the patch.  if there's a problem with this (format, 
functionality, whatever), can someone explain it so i can fix it and 
try again?  that's all i'm asking.  (this patch was generated by 
running "bk -r diffs -u".  if it should be done another way, i'd be 
happy to learn about that, too.)






--- linuxppc-2.5/include/asm-ppc/commproc.h	2004-09-16 13:08:12.000000000 -0400
+++ linuxppc-2.5-new/include/asm-ppc/commproc.h	2004-09-16 13:40:52.000000000 -0400
@@ -145,6 +145,8 @@
  	ushort	smc_brkec;	/* rcv'd break condition counter */
  	ushort	smc_brkcr;	/* xmt break count register */
  	ushort	smc_rmask;	/* Temporary bit mask */
+	char	res1[8];	/* Reserved */
+	ushort	smc_rpbase;	/* Relocation pointer */
  } smc_uart_t;

  /* Function code bits.
@@ -475,8 +477,7 @@
  */
  typedef struct scc_uart {
  	sccp_t	scc_genscc;
-	uint	scc_res1;	/* Reserved */
-	uint	scc_res2;	/* Reserved */
+	char	res1[8];	/* Reserved */
  	ushort	scc_maxidl;	/* Maximum idle chars */
  	ushort	scc_idlc;	/* temp idle counter */
  	ushort	scc_brkcr;	/* Break count register */
@@ -560,9 +561,9 @@
  	ushort	iic_tbptr;	/* Internal */
  	ushort	iic_tbc;	/* Internal */
  	uint	iic_txtmp;	/* Internal */
-	uint	iic_res;	/* reserved */
+	char	res1[4];	/* Reserved */
    	ushort	iic_rpbase;	/* Relocation pointer */
-	ushort	iic_res2;	/* reserved */
+	char	res2[2];	/* Reserved */
  } iic_t;

  #define BD_IIC_START		((ushort)0x0400)