From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleksandr G Zhadan Date: Fri, 27 Mar 2015 12:09:21 -0400 Subject: [U-Boot] [PATCH 1/2] mpc85xx gpio related header files changes to compile common cmd_gpio.c In-Reply-To: <1427471186.13051.66.camel@transmode.se> References: <55147741.80406@arcturusnetworks.com> <1427415986.13051.48.camel@transmode.se> <55156E74.7080405@arcturusnetworks.com> <1427471186.13051.66.camel@transmode.se> Message-ID: <551580B1.7020904@arcturusnetworks.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Yes, here locally we have some additional changes/fixes in some places as well. And if talk about mpc85xx gpio support it's better to have driver in drivers/gpio vs static definitions in header file and I have it. But currently I need this minimal patch to be accepted to send our board support patch based on this one. Oleks On 03/27/2015 11:46 AM, Joakim Tjernlund wrote: > On Fri, 2015-03-27 at 10:51 -0400, Oleksandr G Zhadan wrote: >> Extra gpio bank argument at low level may be discussable, but IMPO we >> should not brake standard int gpio_set_value(unsigned gpio, int value) >> definition. >> >> And the reason of this patch is to fix: >> >> 1. Incompatibility in functions gpio_free() and gpio_set_value() >> definitions between and (void vs int) >> >> 2. Compilation error when build common/cmd_gpio.c for mpc85xx (p1020) > > Sure, when I saw "mpc85xx gpio .." I remembered seeing this flaw so I figured > I point it out before I forget again. > > This also makes me remember, drivers/spi/fsl_espi.c is broken for anything > but reading an EEPROM. > > Jocke >