| Message ID | alpine.DEB.2.02.1302021102210.8724@oneiric |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
On 02/02/2013 05:04 PM, Robert P. J. Day wrote: > Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> > > --- > > based on perusal of entire file as i was reading code. undoubtedly > more of these file-wide proofreads coming if no objections ... > > diff --git a/common/cmd_mem.c b/common/cmd_mem.c > index 0f3ffc8..2568c04 100644 > --- a/common/cmd_mem.c > +++ b/common/cmd_mem.c > @@ -462,7 +462,7 @@ static int do_mem_loop(cmd_tbl_t *cmdtp, int flag, int argc, > if (argc < 3) > return CMD_RET_USAGE; > > - /* Check for a size spefication. > + /* Check for a size specification. > * Defaults to long if no or incorrect specification. > */ > if ((size = cmd_get_data_size(argv[0], 4)) < 0) > @@ -531,7 +531,7 @@ int do_mem_loopw (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) > if (argc < 4) > return CMD_RET_USAGE; > > - /* Check for a size spefication. > + /* Check for a size specification. > * Defaults to long if no or incorrect specification. > */ > if ((size = cmd_get_data_size(argv[0], 4)) < 0) > @@ -683,7 +683,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, > * Data line test: write a pattern to the first > * location, write the 1's complement to a 'parking' > * address (changes the state of the data bus so a > - * floating bus doen't give a false OK), and then > + * floating bus doesn't give a false OK), and then > * read the value back. Note that we read it back > * into a variable because the next time we read it, > * it might be right (been there, tough to explain to > @@ -747,7 +747,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, > * 1's test on the relevant bits of the > * address and checking for aliasing. > * This test will find single-bit > - * address failures such as stuck -high, > + * address failures such as stuck-high, > * stuck-low, and shorted pins. The base > * address and size of the region are > * selected by the caller. > nitpicking: the summary line should not end with a dot. multi line comments in u-boot are commonly /* * I span * multiple lines */ So while at it, you might want to add the empty opening line as well. Regards, Jeroen
On Sat, 2 Feb 2013, Jeroen Hofstee wrote: > On 02/02/2013 05:04 PM, Robert P. J. Day wrote: > > Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> > > > > --- > > > > based on perusal of entire file as i was reading code. undoubtedly > > more of these file-wide proofreads coming if no objections ... > > > > diff --git a/common/cmd_mem.c b/common/cmd_mem.c > > index 0f3ffc8..2568c04 100644 > > --- a/common/cmd_mem.c > > +++ b/common/cmd_mem.c > > @@ -462,7 +462,7 @@ static int do_mem_loop(cmd_tbl_t *cmdtp, int flag, int > > argc, > > if (argc < 3) > > return CMD_RET_USAGE; > > > > - /* Check for a size spefication. > > + /* Check for a size specification. > > * Defaults to long if no or incorrect specification. > > */ > > if ((size = cmd_get_data_size(argv[0], 4)) < 0) .. snip ... > nitpicking: the summary line should not end with a dot. point taken, i can resubmit. > multi line comments in u-boot are commonly > > /* > * I span > * multiple lines > */ > > So while at it, you might want to add the empty opening line as well. in cases like this, it's kind of a judgment call. if that's truly a strict standard, then sure. but i'm pretty sure there's a *lot* of the above type of comment in the source and when i'm just fixing comments, i prefer to make as unobtrusive a change as possible. i'll let wolfgang decide, and i'll go with whatever he chooses. note carefully that you used the phrase "commonly", without claiming that it's a hard and fast standard, which is why i left it alone. rday
Dear Robert, In message <alpine.DEB.2.02.1302030404210.5835@oneiric> you wrote: > > > multi line comments in u-boot are commonly > > > > /* > > * I span > > * multiple lines > > */ > > > > So while at it, you might want to add the empty opening line as well. > > in cases like this, it's kind of a judgment call. if that's truly a > strict standard, then sure. but i'm pretty sure there's a *lot* of > the above type of comment in the source and when i'm just fixing > comments, i prefer to make as unobtrusive a change as possible. If you are editing these, then please also fix the multi-line comment style as suggested. Thanks. Best regards, Wolfgang Denk
On Sun, 3 Feb 2013, Wolfgang Denk wrote: > Dear Robert, > > In message <alpine.DEB.2.02.1302030404210.5835@oneiric> you wrote: > > > > > multi line comments in u-boot are commonly > > > > > > /* > > > * I span > > > * multiple lines > > > */ > > > > > > So while at it, you might want to add the empty opening line as well. > > > > in cases like this, it's kind of a judgment call. if that's truly a > > strict standard, then sure. but i'm pretty sure there's a *lot* of > > the above type of comment in the source and when i'm just fixing > > comments, i prefer to make as unobtrusive a change as possible. > > If you are editing these, then please also fix the multi-line comment > style as suggested. Thanks. so what is the actual standard? besides the above, line space above? line space below? because i see all sorts of variations in the code, the most common of which is: ... snip ... static int mod_mem(cmd_tbl_t *, int, int, int, char * const []); /* Display values from last command. * Memory modify remembered values are different from display memory. */ static uint dp_last_addr, dp_last_size; ... snip ... which, as you can see, has a leading blank line but not a following one. so what's correct? is this written down somewhere? rday
Dear Robert, In message <alpine.DEB.2.02.1302030522480.6448@oneiric> you wrote: > > so what is the actual standard? besides the above, line space > above? line space below? because i see all sorts of variations in > the code, the most common of which is: The "standard" is the Linux CodingStyle: ------------------------- snip ---------------------- The preferred style for long (multi-line) comments is: /* * This is the preferred style for multi-line * comments in the Linux kernel source code. * Please use it consistently. * * Description: A column of asterisks on the left side, * with beginning and ending almost-blank lines. */ ------------------------- snip ---------------------- Regarding the space above and blow, I'm not aware of any "standard". Please apply common sense. > which, as you can see, has a leading blank line but not a following > one. so what's correct? is this written down somewhere? Not that I'm aware of. Best regards, Wolfgang Denk
diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 0f3ffc8..2568c04 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -462,7 +462,7 @@ static int do_mem_loop(cmd_tbl_t *cmdtp, int flag, int argc, if (argc < 3) return CMD_RET_USAGE; - /* Check for a size spefication. + /* Check for a size specification. * Defaults to long if no or incorrect specification. */ if ((size = cmd_get_data_size(argv[0], 4)) < 0) @@ -531,7 +531,7 @@ int do_mem_loopw (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (argc < 4) return CMD_RET_USAGE; - /* Check for a size spefication. + /* Check for a size specification. * Defaults to long if no or incorrect specification. */ if ((size = cmd_get_data_size(argv[0], 4)) < 0) @@ -683,7 +683,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, * Data line test: write a pattern to the first * location, write the 1's complement to a 'parking' * address (changes the state of the data bus so a - * floating bus doen't give a false OK), and then + * floating bus doesn't give a false OK), and then * read the value back. Note that we read it back * into a variable because the next time we read it, * it might be right (been there, tough to explain to @@ -747,7 +747,7 @@ static int do_mem_mtest(cmd_tbl_t *cmdtp, int flag, int argc, * 1's test on the relevant bits of the * address and checking for aliasing. * This test will find single-bit - * address failures such as stuck -high, + * address failures such as stuck-high, * stuck-low, and shorted pins. The base * address and size of the region are * selected by the caller.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> --- based on perusal of entire file as i was reading code. undoubtedly more of these file-wide proofreads coming if no objections ...