From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Fri, 24 Apr 2015 00:25:34 -0500
Subject: [U-Boot] [PATCH v5 2/3] mtd,
 nand: move common functions from cmd_nand.c to common place
In-Reply-To: <5539CD99.8000908@denx.de>
References: <1429508853-10139-1-git-send-email-hs@denx.de>
 <1429508853-10139-3-git-send-email-hs@denx.de>
 <1429742874.4352.138.camel@freescale.com> <553889C2.6050904@denx.de>
 <1429772150.16357.14.camel@freescale.com> <5538D38A.4090204@denx.de>
 <1429811305.16357.17.camel@freescale.com> <5539CD99.8000908@denx.de>
Message-ID: <1429853134.16357.34.camel@freescale.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Fri, 2015-04-24 at 06:59 +0200, Heiko Schocher wrote:
> Hello Scott,
> 
> Am 23.04.2015 19:48, schrieb Scott Wood:
> > On Thu, 2015-04-23 at 13:12 +0200, Heiko Schocher wrote:
> >> Hello Scott,
> >>
> >> Am 23.04.2015 08:55, schrieb Scott Wood:
> >>> On Thu, 2015-04-23 at 07:57 +0200, Heiko Schocher wrote:
> >>>> Hello Scott,
> >>>>
> >>>> Am 23.04.2015 00:47, schrieb Scott Wood:
> >>>>> On Mon, 2015-04-20 at 07:47 +0200, Heiko Schocher wrote:
> >>>>>> +int str2off(const char *p, loff_t *num);
> >>>>>> +int str2long(const char *p, ulong *num);
> >>>>>
> >>>>> These should be moved somewhere more generic, especially if they're no
> >>>>> longer file-local.
> >>>>
> >>>> Hmm... the code is currently in "drivers/mtd/mtd_uboot.c" ... maybe
> >>>> we add a "mtd_" prefix to them? I think these functions are mtd specific ...
> >>>
> >>> What is mtd-specific about them?
> >>
> >> Hmm... I thought:
> >>
> >> return *p != '\0' && *endptr == '\0';
> >>
> >> is more or less mtd specific ... but you are right, it is not really
> >> mtd specific ... so I move them to "./lib/vsprintf.c" ... Ok?
> >
> > OK.  Maybe change the return to bool while you're at it, to make it
> > clear that it isn't return-zero-on-success.
> 
> Hmm.. tried this, but I get:
> 
>    CC      common/cmd_test.o
> In file included from /home/hs/abb/imx6/u-boot/include/common.h:760:0,
>                   from /home/hs/abb/imx6/u-boot/common/cmd_test.c:17:
> /home/hs/abb/imx6/u-boot/include/vsprintf.h:176:1: error: unknown type name 'bool'
> /home/hs/abb/imx6/u-boot/include/vsprintf.h:177:1: error: unknown type name 'bool'
> /home/hs/abb/imx6/u-boot/scripts/Makefile.build:276: recipe for target 'common/cmd_test.o' failed
> make[2]: *** [common/cmd_test.o] Error 1
> /home/hs/abb/imx6/u-boot/Makefile:1156: recipe for target 'common' failed
> make[1]: *** [common] Error 2
> 
> reason is in common/cmd_test.c:
> 
> /*
>   * Define _STDBOOL_H here to avoid macro expansion of true and false.
>   * If the future code requires macro true or false, remove this define
>   * and undef true and false before U_BOOT_CMD. This define and comment
>   * shall be removed if change to U_BOOT_CMD is made to take string
>   * instead of stringifying it.
>   */
> #define _STDBOOL_H

Ugh.  Maybe add a variant of U_BOOT_CMD_COMPLETE that takes a string for
the user-visible name that is separate from the C-visible symbol used
for the ll entry.

Or you could either define bool manually, or do what the comment says
and undef true/false.

> #include <common.h>
> 
> Hmm... I tend to say, this is another patch changing the returntype
> from int to bool ...

It's related because you're moving it from being a local static function
to being an API exposed treewide, so higher standards apply.

Another option would be to convert it to returning zero on success and a
negative error code on error.

-Scott