[U-Boot] [PATCH v3 6/9] arc: add Arcangel4 board support

[Wolfgang Denk]

Dear Alexey,

In message <1391457010.2357.41.camel at abrodkin-8560l.internal.synopsys.com> you wrote:
> 
> On Mon, 2014-02-03 at 20:15 +0100, Wolfgang Denk wrote:
> > Dear Alexey Brodkin,
> > 
> > In message <1391445368-10545-7-git-send-email-abrodkin at synopsys.com> you wrote:
> > > Arcangel4 is a FPGA-based development board that is used for prototyping and
> > > verification of of both ARC hardware (CPUs) and software running upon CPU.
> > > 
> > > Prerequisite is http://patchwork.ozlabs.org/patch/300901/
> > 
> > Is this commentuseful in the commit message?
>
> Do you mean comment regarding Arcangel4 board itself?
> I upstreamed a number of drivers in both u-Boot and Linux kernel and
> each time I put a brief description of device I'm submitting sources for
> in commit message.

NO, I mean the comment about any prerequisites for this patch.  These
are only interesting for those to handle the patch, but once it's
applied (hopefully with all prerequisites in place), then this sentence
is meaningless.  So please move it to the comment section.

> > > +#define CONFIG_BAUDRATE			115200
> > > +#define CONFIG_SYS_BAUDRATE_TABLE	{9600, 19200, 38400, 57600, 115200}
> > 
> > This is standard, isn't it? So you can omit it.
>
> Indeed this is standard. But as I wrote earlier - since there's no
> guidance (or at least I didn't manage to find it) on how to use stuff in
> u-boot I went grepping through existing u-Boot sources and I saw how
> it's done.

You must have used old code as reference; please see

commit 26750c8aee2383a026e0cf89e9310628d3a5a6a0
Author: Tom Rini <trini at ti.com>
Date:   Tue Jun 19 12:54:34 2012 +0000

    CONFIG_SYS_BAUDRATE_TABLE: Add <config_fallbacks.h>, place there


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
A secure program has to be robust: it  must  be  able  to  deal  with
conditions  that "can't happen", whether user input, program error or
library/etc. This is basic damage  control.  Buffer  overflow  errors
have nothing to do with security, but everything with stupidity.
                 -- Wietse Venema in <5cnqm3$8r9 at spike.porcupine.org>