[U-Boot] [PATCH v6 4/4] mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices

[Wolfgang Denk]

Dear "Moffett, Kyle D",

In message <DDD31591-33CD-49E4-B303-3477E00933BF at boeing.com> you wrote:
>
> I apparently cannot rely on the U-Boot *CODE* to understand what the
> U-Boot *CODING* style is.

You don't have to rely on the code.  It's clearly documented.

The README says:

	Coding Standards:
	-----------------

	All contributions to U-Boot should conform to the Linux kernel
	coding style; see the file "Documentation/CodingStyle" and the script
	"scripts/Lindent" in your Linux kernel source directory...

http://www.denx.de/wiki/U-Boot/CodingStyle  says the same.

And the referred document says:

			Chapter 2: Breaking long lines and strings
	 
	Coding style is all about readability and maintainability using
	commonly
	available tools.
	 
	The limit on the length of lines is 80 columns and this is a strongly
	preferred limit.
	 
	Statements longer than 80 columns will be broken into sensible chunks.

Now what exactly is unclear here?


And no, you are not the only one who is asked to fix his code beause
of "Line too long" errors. Here just a small collection from the last
4 months or so:

11/11 To:Xiangfu Liu     Re: [U-Boot] [PATCH 1/5] those files are jz4740 base files
      http://article.gmane.org/gmane.comp.boot-loaders.u-boot/88655
12/04 To:Luigi 'Comio'   Re: [U-Boot] [PATCH 5/6 v2] Enable bootstrap support for MIPS architecture.
      http://article.gmane.org/gmane.comp.boot-loaders.u-boot/90325
12/12 To:Macpaul Lin     Re: [U-Boot] [PATCH] ftgmac100: support of gigabit eth ftgmac100
      http://article.gmane.org/gmane.comp.boot-loaders.u-boot/90740
12/12 To:Macpaul Lin     Re: [U-Boot] [PATCH] ftgmac100: support of gigabit eth ftgmac100
      http://article.gmane.org/gmane.comp.boot-loaders.u-boot/90740
03/13 To:Heiko Schocher  Re: [U-Boot] [PATCH 01/20] keymile: rework headerfiles for keymile boards
      http://article.gmane.org/gmane.comp.boot-loaders.u-boot/95728


> But otherwise I see no valid reason I should waste any more of my time
> submitting patches which get torn apart out of hand over issues which are
> completely ignored for patches which come in from other maintainers.

This is simply not true. But I'm not sure if you are still listening
to any rational arguments. I can only ask you to calm down, and
eventually reconsider.  Sorry.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quote from a recent meeting:   "We are going to continue having these
meetings everyday until I find out why no work is getting done."