| Message ID | CAOMZO5Acx8LoRcPFpcBiEf1cWMQ=+b3H1vZwOgig7jsrV+4sHQ@mail.gmail.com |
|---|---|
| State | RFC |
| Delegated to: | Tom Rini |
| Headers | show |
Fabio, On 4 November 2015 at 16:38, Fabio Estevam <festevam@gmail.com> wrote: > Hi Jagan, > > On Wed, Nov 4, 2015 at 8:47 AM, Fabio Estevam <festevam@gmail.com> wrote: >> On Wed, Nov 4, 2015 at 8:46 AM, Fabio Estevam <festevam@gmail.com> wrote: >>> Hi Tom, >>> >>> On Wed, Nov 4, 2015 at 1:45 AM, Fabio Estevam <festevam@gmail.com> wrote: >>>> On Tue, Nov 3, 2015 at 11:47 PM, Tom Rini <trini@konsulko.com> wrote: >>>> >>>>> NAK. >>>>> >>>>> So, this blows up badly for a lot of things when I do: >>>>> ./tools/buildman/buildman -b master --force-build --step 0 -Cdvel >>>>> 'blackfin|microblaze|m68k|nds32|x86|aarch64|sandbox|mips|avr32|arm|powerpc|sh4|sparc' >>>> >>>> It seems I missed to add bitops for avr32 and mips. Will work on it tomorrow. >>> >>> I don't see issues after applying the three attached patches. >> >> Ops, I do see a build issue in blackfin that didn't happen in previous >> versions. Will work on fixing it. > > When you reworked my series you missed to updated these functions: > > diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c > index 31c79c6..d832464 100644 > --- a/drivers/mtd/spi/sf_ops.c > +++ b/drivers/mtd/spi/sf_ops.c > @@ -652,7 +652,7 @@ int stm_is_locked(struct spi_flash *flash, u32 > ofs, size_t len) > * > * Returns negative on errors, 0 on success. > */ > -int stm_lock(struct spi_flash *flash, u32 ofs, u32 len) > +int stm_lock(struct spi_flash *flash, u32 ofs, size_t len) > { > u8 status_old, status_new; > u8 mask = SR_BP2 | SR_BP1 | SR_BP0; > @@ -703,7 +703,7 @@ int stm_lock(struct spi_flash *flash, u32 ofs, u32 len) > * > * Returns negative on errors, 0 on success. > */ > -int stm_unlock(struct spi_flash *flash, u32 ofs, u32 len) > +int stm_unlock(struct spi_flash *flash, u32 ofs, size_t len) Updated u32 to size_t as prototype uses the same. Does this break? it look OK? thanks!
Hi Jagan,
On Wed, Nov 4, 2015 at 9:17 AM, Jagan Teki <jteki@openedev.com> wrote:
> Updated u32 to size_t as prototype uses the same. Does this break? it look OK?
Here is the error I see on Blackfin:
Building bf518f-ezbrd board...
/home/fabio/.buildman-toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-size:
'./u-boot': No such file
drivers/mtd/spi/sf_ops.c:655:5: error: conflicting types for 'stm_lock'
drivers/mtd/spi/sf_ops.c:706:5: error: conflicting types for 'stm_unlock'
make[1]: *** [drivers/mtd/spi/sf_ops.o] Error 1
make: *** [drivers/mtd/spi] Error 2
drivers/mtd/spi/sf_ops.c:655:5: error: conflicting types for 'stm_lock'
drivers/mtd/spi/sf_internal.h:180:5: note: previous declaration of
'stm_lock' was here
drivers/mtd/spi/sf_ops.c:706:5: error: conflicting types for 'stm_unlock'
drivers/mtd/spi/sf_internal.h:183:5: note: previous declaration of
'stm_unlock' was here
make[1]: *** [drivers/mtd/spi/sf_ops.o] Error 1
By using size_t we fix this conflicting type error.
Regards,
Fabio Estevam
On 4 November 2015 at 16:51, Fabio Estevam <festevam@gmail.com> wrote: > Hi Jagan, > > On Wed, Nov 4, 2015 at 9:17 AM, Jagan Teki <jteki@openedev.com> wrote: > >> Updated u32 to size_t as prototype uses the same. Does this break? it look OK? > > Here is the error I see on Blackfin: > > Building bf518f-ezbrd board... > /home/fabio/.buildman-toolchains/gcc-4.6.3-nolibc/bfin-uclinux/bin/bfin-uclinux-size: > './u-boot': No such file > drivers/mtd/spi/sf_ops.c:655:5: error: conflicting types for 'stm_lock' > drivers/mtd/spi/sf_ops.c:706:5: error: conflicting types for 'stm_unlock' > make[1]: *** [drivers/mtd/spi/sf_ops.o] Error 1 > make: *** [drivers/mtd/spi] Error 2 > drivers/mtd/spi/sf_ops.c:655:5: error: conflicting types for 'stm_lock' > drivers/mtd/spi/sf_internal.h:180:5: note: previous declaration of > 'stm_lock' was here > drivers/mtd/spi/sf_ops.c:706:5: error: conflicting types for 'stm_unlock' > drivers/mtd/spi/sf_internal.h:183:5: note: previous declaration of > 'stm_unlock' was here > make[1]: *** [drivers/mtd/spi/sf_ops.o] Error 1 > > By using size_t we fix this conflicting type error. Yes true, stm_lock and stm_unlock should use size_t for len - Will update the same. With these all built fine? thanks!
On Wed, Nov 4, 2015 at 9:30 AM, Jagan Teki <jteki@openedev.com> wrote: > Yes true, stm_lock and stm_unlock should use size_t for len - Will > update the same. > > With these all built fine? After applying this size_t change plus the three attached bitops patches I sent you for mips, arc. avr32 I do not see any more build issues here. Also, when you apply the three patches to your tree, please make sure they are applied prior to the "compat: Remove is_power_of_2() definition" so that we keep bisectability. Thanks, Fabio Estevam
On Wed, Nov 4, 2015 at 9:35 AM, Fabio Estevam <festevam@gmail.com> wrote: > After applying this size_t change plus the three attached bitops > patches I sent you for mips, arc. avr32 I do not see any more build > issues here. > > Also, when you apply the three patches to your tree, please make sure > they are applied prior to the "compat: Remove is_power_of_2() > definition" so that we keep bisectability. Also, in the v5 I sent I split microblaze and sh changes as you pointed out. However, you seem to have picked the previous version: http://git.denx.de/?p=u-boot/u-boot-spi.git;a=commit;h=9918a2c36b10675f9f12e3e3dcfff8f41727b586
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c index 31c79c6..d832464 100644 --- a/drivers/mtd/spi/sf_ops.c +++ b/drivers/mtd/spi/sf_ops.c @@ -652,7 +652,7 @@ int stm_is_locked(struct spi_flash *flash, u32 ofs, size_t len) * * Returns negative on errors, 0 on success. */ -int stm_lock(struct spi_flash *flash, u32 ofs, u32 len) +int stm_lock(struct spi_flash *flash, u32 ofs, size_t len) { u8 status_old, status_new;