linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* what is the protocol for getting patches into the tree?
@ 2004-10-04 15:24 Robert P. J. Day
  2004-10-04 15:48 ` Matt Porter
  2004-10-05 15:02 ` Tom Rini
  0 siblings, 2 replies; 5+ messages in thread
From: Robert P. J. Day @ 2004-10-04 15:24 UTC (permalink / raw)
  To: Embedded PPC Linux list


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: what is the protocol for getting patches into the tree?
  2004-10-04 15:24 what is the protocol for getting patches into the tree? Robert P. J. Day
@ 2004-10-04 15:48 ` Matt Porter
  2004-10-04 16:11   ` Marius Groeger
  2004-10-05 15:02 ` Tom Rini
  1 sibling, 1 reply; 5+ messages in thread
From: Matt Porter @ 2004-10-04 15:48 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Embedded PPC Linux list

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".

<snip>

>    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@kernel.crashing.org
W:      http://www.penguinppc.org/
L:      linuxppc-embedded@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.

<snip>

> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: what is the protocol for getting patches into the tree?
  2004-10-04 15:48 ` Matt Porter
@ 2004-10-04 16:11   ` Marius Groeger
  2004-10-04 16:43     ` Matt Porter
  0 siblings, 1 reply; 5+ messages in thread
From: Marius Groeger @ 2004-10-04 16:11 UTC (permalink / raw)
  To: Matt Porter; +Cc: Embedded PPC Linux list

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 <mgroeger@sysgo.com>
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: what is the protocol for getting patches into the tree?
  2004-10-04 16:11   ` Marius Groeger
@ 2004-10-04 16:43     ` Matt Porter
  0 siblings, 0 replies; 5+ messages in thread
From: Matt Porter @ 2004-10-04 16:43 UTC (permalink / raw)
  To: Marius Groeger; +Cc: Embedded PPC Linux list

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: what is the protocol for getting patches into the tree?
  2004-10-04 15:24 what is the protocol for getting patches into the tree? Robert P. J. Day
  2004-10-04 15:48 ` Matt Porter
@ 2004-10-05 15:02 ` Tom Rini
  1 sibling, 0 replies; 5+ messages in thread
From: Tom Rini @ 2004-10-05 15:02 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Embedded PPC Linux list

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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-10-05 15:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-04 15:24 what is the protocol for getting patches into the tree? Robert P. J. Day
2004-10-04 15:48 ` Matt Porter
2004-10-04 16:11   ` Marius Groeger
2004-10-04 16:43     ` Matt Porter
2004-10-05 15:02 ` Tom Rini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).