public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/3] XPedite5370 board support
Date: Tue, 18 Nov 2008 16:39:49 -0600	[thread overview]
Message-ID: <1227047989.3065.73.camel@localhost.localdomain> (raw)
In-Reply-To: <20081118222038.5DC77832E89D@gemini.denx.de>

On Tue, 2008-11-18 at 23:20 +0100, Wolfgang Denk wrote:
> Dear Peter Tyser,
> 
> In message <1227046406.3065.49.camel@localhost.localdomain> you wrote:
> >
> > This information is very useful to a customer and doesn't add much as
> > far as output.  No newlines at least.  The output also prints
> > information which is configurable.  I think giving the user feedback
> > about how they have the board configured is useful.
> 
> You really need this level of detail only for board bring up and
> debugging. After that, this is a constand and never changes, right? Si
> it is normally enough to print the RAM size (and eventually some speed
> characteristics).

User's can change the DDR configuration with the "memctl_intlv_ctl" and
"ba_intlv_ctl".  I don't imagine they'll fuss with those variable much,
but they should certainly be aware if they do, or change one by
accident, etc.  Different board configs do/don't have ECC (same product,
different build options), so I think the ECC info is also useful to a
customer as they may have multiple boards with different configs.

> > We have the standard Freescale DDR printf's turned into debug as that is
> > much, much more verbose than the output above.
> 
> Indeed :-(
> 
> > > > +	flash_sel = !((pca953x_get_val(CONFIG_SYS_I2C_PCA953X_ADDR0) &
> > > > +			  CONFIG_SYS_PCA953X_C0_FLASH_PASS_CS));
> > > > +	printf("FLASH: Executed from FLASH%d\n", flash_sel ? 2 : 1);
> > > 
> > > Please be less noisy! s/printf/debug/
> > 
> > This information is also very useful to a customer.
> 
> Is it, really? well...
> 
> > > > +#define	CONFIG_EXTRA_ENV_SETTINGS				\
> > > > + "autoload=yes\0"						\
> ...
> > > > + "prog_fdt2="CONFIG_PROG_FDT2"\0"				\
> > > > + "bootcmd_net=run set_bootargs; "CONFIG_BOOT_OS_NET"\0"		\
> > > > + "bootcmd_flash1=run set_bootargs; bootm "CONFIG_OS1_FLASH_ADDR_STR" - "CONFIG_FDT1_FLASH_ADDR_STR"\0" \
> > > > + "bootcmd_flash2=run set_bootargs; bootm "CONFIG_OS2_FLASH_ADDR_STR" - "CONFIG_FDT2_FLASH_ADDR_STR"\0" \
> > > > + "bootcmd=run bootcmd_flash1\0"
> > > > +#endif	/* __CONFIG_H */
> > > 
> > > Alignment not by TAB, lines way too long.
> > 
> > What are you referring to as far as "Alignment not by TAB"?
> 
> You indent the lines by a single space, but they should be indented by
> a TAB.

Many boards I look at don't use TABS.  In particular Freescale reference
platforms.  Many boards even have different amounts of spaces:)  I don't
see the value of indentation in this case as it doesn't increase
readability and just makes already long lines even longer.

> > Everyone's config file breaks the 80 column rule, is this really
> > necessary to change?  I think splitting it up makes an already confusing
> > define even more confusing.
> 
> At least the ';' is a good place to split. And you might check if  it
> really  makes  sense  to  use  variable names with 25 characters like
> "CONFIG_OS2_FLASH_ADDR_STR" (no, it doesn't).

That define is no longer than the standard CONFIG_EXTRA_ENV_SETTINGS
define that its used in, or any number of other standard defines.  And
they aren't used anywhere other than this 40 line section of code in 1
file.  I thought the increase in clarity of long defines made up for
their ugliness.  I'll go ahead and split the lines on the ';' as you
suggested.

You have the final say, so if any of the above are sticking points to
getting the code accepted let me know and I'll change them as requested.

Thanks,
Peter

  reply	other threads:[~2008-11-18 22:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-23 22:23 [U-Boot] [PATCH 0/3] Support for XPedite5370 and misc GPIO Peter Tyser
2008-10-23 22:23 ` [U-Boot] [PATCH 1/3] Add support for PCA953x I2C gpio devices Peter Tyser
2008-10-23 22:23   ` [U-Boot] [PATCH 2/3] Add support for Maxim's DS4510 I2C device Peter Tyser
2008-10-23 22:23     ` [U-Boot] [PATCH 3/3] XPedite5370 board support Peter Tyser
2008-10-24 23:21       ` Andy Fleming
2008-10-25  0:30         ` Peter Tyser
2008-11-18 21:44       ` Wolfgang Denk
2008-11-18 22:13         ` Peter Tyser
2008-11-18 22:20           ` Wolfgang Denk
2008-11-18 22:39             ` Peter Tyser [this message]
2008-11-18 23:03               ` Wolfgang Denk
2008-11-19 17:29               ` Jon Loeliger
2008-11-19 18:00                 ` Peter Tyser
2008-11-18 21:37     ` [U-Boot] [PATCH 2/3] Add support for Maxim's DS4510 I2C device Wolfgang Denk
2008-11-18 21:57       ` Peter Tyser
2008-11-18 23:16         ` Wolfgang Denk
2008-11-18 21:33   ` [U-Boot] [PATCH 1/3] Add support for PCA953x I2C gpio devices Wolfgang Denk
2008-11-18 21:51     ` Peter Tyser
2008-11-18 23:11       ` Wolfgang Denk
2008-11-18 21:29 ` [U-Boot] [PATCH 0/3] Support for XPedite5370 and misc GPIO Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1227047989.3065.73.camel@localhost.localdomain \
    --to=ptyser@xes-inc.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox