[U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning

André Przywara andre.przywara at arm.com
Mon Nov 14 20:43:40 CET 2016


On 14/11/16 18:32, Siarhei Siamashka wrote:
> On Thu,  3 Nov 2016 00:58:12 +0000
> Andre Przywara <andre.przywara at arm.com> wrote:
> 
>> Somehow an int returning function without a return statement sneaked
>> in. Fix it.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
>> index 67c7edd..7502314 100644
>> --- a/drivers/mtd/spi/sunxi_spi_spl.c
>> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
>> @@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
>>  			     (1 << AHB_RESET_SPI0_SHIFT));
>>  }
>>  
>> -static int spi0_init(void)
>> +static void spi0_init(void)
>>  {
>>  	unsigned int pin_function = SUNXI_GPC_SPI0;
>> +
>>  	if (IS_ENABLED(CONFIG_MACH_SUN50I))
>>  		pin_function = SUN50I_GPC_SPI0;
>>  
> 

Hi Siarhei,

> Thanks for spotting and fixing this compilation warning.
> 
> This was a last minute change. Originally there was also a check for
> the pins state and the function returned an error code in the case if
> the pins are already configured for NAND. But I removed this code
> before sending the patch.

please, no need to apologize or explain, those things happen, especially
when shuffling around patches.

The only learning that we should take from it that at least those
compilation warnings should be spotted on a more automated base.
I think the problem here is that the feature is not enabled in any
defconfig atm, but I think I will enable it in my Opi PC 2 series.

On a related matter, I ran buildman on HEAD for armv8 today and GCC 6.2
found quite some issues (will send out the fixes ASAP).
So is there some buildbot somewhere that runs buildman? If yes, with
what compilers?

> The idea is that probing the SPI flash may be useful in the future even
> if booting from some other media. We may store some board-specific
> configuration in the on-board SPI flash (for example, the DRAM and
> CPU speed grade information). But this functionality definitely belongs
> to a separate patch and can be always contributed later. There is also
> the SPL size concern and we don't want to unnecessarily increase the
> code size.

Totally agree, and as I said: No worries. Actually thanks a lot for this
series, as booting from NOR flash is really a cool feature.

Cheers,
Andre.



More information about the U-Boot mailing list