From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 23 Jan 2020 16:12:04 -0500 Subject: [PATCH 1/1 v1] cmd: gpio: Correct do_gpio() return value In-Reply-To: References: <20200105191056.12571-1-luka.kovacic@sartura.hr> <20200105191056.12571-2-luka.kovacic@sartura.hr> <20200123123138.GA17003@bill-the-cat> Message-ID: <20200123211204.GC26536@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Thu, Jan 23, 2020 at 10:04:05PM +0100, Luka Kovačič wrote: > Hello Tom, > > thank you for feedback and review. I understand the implications. > Would it make sense to document this somewhere to avoid any future confusion? Yes, along with a standalone patch to update the document to use CMD_RET_SUCCESS NOT CMD_SUCCESS. Updating the gpio help text even to be clear what the return value is would be nice. Thanks! > > Thanks, > Luka > > On Thu, Jan 23, 2020 at 1:31 PM Tom Rini wrote: > > > > On Sun, Jan 05, 2020 at 08:10:56PM +0100, Luka Kovacic wrote: > > > > > Use the correct return value in function do_gpio() and update > > > commands documentation with the return values from command_ret_t enum. > > > > > > CMD_RET_SUCCESS is returned on command success and CMD_RET_FAILURE is > > > returned on command failure. > > > > > > The command was returning the pin value, which caused confusion when > > > debugging (#define DEBUG). > > > > > > Signed-off-by: Luka Kovacic > > > Tested-by: Robert Marko > > > > So, I think the problem is that despite this not being an optimal user > > interface, it's what we've had here for "forever". We can't just go > > change it now as there's scripts out in the world (and even > > include/configs/) that depend on the current behavior. Sorry, nak. > > > > -- > > Tom -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: