(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)
