[U-Boot] [PATCH] cmd_mem.c: Fix simple typoes, no functional changes.
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.
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.
*/ if ((size = cmd_get_data_size(argv[0], 4)) < 0)
- Defaults to long if no or incorrect specification.
@@ -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.
*/ if ((size = cmd_get_data_size(argv[0], 4)) < 0)
- Defaults to long if no or incorrect specification.
@@ -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 baseaddress and size of the region areselected 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.
*/ if ((size = cmd_get_data_size(argv[0], 4)) < 0)
- Defaults to long if no or incorrect specification.
.. 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
participants (3)
-
Jeroen Hofstee -
Robert P. J. Day -
Wolfgang Denk