what is the protocol for getting patches into the tree?
On Mon, Oct 04, 2004 at 11:24:24AM -0400, Robert P. J. Day wrote: [snip] > 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. Is this the same patch / idea that I've seen both Wolfgang and Dan have a number of comments on, or something different? If it is the same, have their issues been cleared in this version of the patch? Thanks. -- Tom Rini http://gate.crashing.org/~trini/
what is the protocol for getting patches into the tree?
On Mon, 4 Oct 2004, Matt Porter wrote: > Yes, submit it over and over until there is some feedback. argue > or follow the feedback...eventually it will go in unless it's not > a desirable change. If no feedback, keep submitting until the > maintainer has time to look at it. Well, how about asking Russel to hand out the scripts for http://www.arm.linux.org.uk/developer/patches/ Would this help? Regards, Marius -- Marius Groeger SYSGO AG Embedded and Real-Time Software Voice: +49 6136 9948 0 FAX: +49 6136 9948 10 www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
what is the protocol for getting patches into the tree?
(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.0
-0400
+++ linuxppc-2.5-new/include/asm-ppc/commproc.h 2004-09-16 13:40:52.0
-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 */
+ charres1[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;
- uintscc_res1; /* Reserved */
- uintscc_res2; /* Reserved */
+ charres1[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 */
uintiic_txtmp; /* Internal */
- uintiic_res;/* reserved */
+ charres1[4];/* Reserved */
ushort iic_rpbase; /* Relocation pointer */
- ushort iic_res2; /* reserved */
+ charres2[2];/* Reserved */
} iic_t;
#define BD_IIC_START ((ushort)0x0400)
what is the protocol for getting patches into the tree?
On Mon, Oct 04, 2004 at 06:11:05PM +0200, Marius Groeger wrote: > On Mon, 4 Oct 2004, Matt Porter wrote: > > > Yes, submit it over and over until there is some feedback. argue > > or follow the feedback...eventually it will go in unless it's not > > a desirable change. If no feedback, keep submitting until the > > maintainer has time to look at it. > > Well, how about asking Russel to hand out the scripts for > >http://www.arm.linux.org.uk/developer/patches/ > > Would this help? No, it just provides a web-based interface to what is handled via mailing lists. It's just as easy for a maintainer to get busy and not ack a patch submission on a web-based system as well. I suspect that this is an 8xx-specific problem. The source of the problem is that 8xx has been undermaintained for some time and it only recently has gained a new maintainer. -Matt
what is the protocol for getting patches into the tree?
On Mon, Oct 04, 2004 at 11:24:24AM -0400, Robert P. J. Day wrote: >*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". >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. LKML has no interest in a patch which is only intended for a PPC-only tree (i.e. linuxppc-2.5) linuxppc-2.5/MAINTAINERS: LINUX FOR POWERPC EMBEDDED PPC8XX AND BOOT CODE P: Tom Rini M: trini at kernel.crashing.org W: http://www.penguinppc.org/ L: linuxppc-embedded at lists.linuxppc.org S: Maintained PPC embedded only patches belong here...yes these ML references should be updated to ozlabs.org. cc: Tom since he is the 8xx maintainer. > 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? Yes, submit it over and over until there is some feedback. argue or follow the feedback...eventually it will go in unless it's not a desirable change. If no feedback, keep submitting until the maintainer has time to look at it. -Matt
