[PATCH v2 1/2] mtd: cfi: respect reg address length

[Nuno Sá]

On Mon, 2023-04-24 at 09:36 +0200, Stefan Roese wrote:
> On 4/24/23 09:13, Nuno Sá wrote:
> > On Mon, 2023-04-24 at 08:54 +0200, Stefan Roese wrote:
> > 
> > Hi Stefan,
> > 
> > 
> > > Hi Nuno Sá
> > > 
> > > On 4/18/23 15:07, Nuno Sá wrote:
> > > > flash_get_size() will get the flash size from the device itself and go
> > > > through all erase regions to read protection status. However, the device
> > > > mappable region (eg: devicetree reg property) might be lower than the
> > > > device full size which means that the above cycle will result in a data
> > > > bus exception. This change fixes it by reading the 'addr_size' during
> > > > probe() and also use that as one possible upper limit.
> > > > 
> > > > Signed-off-by: Nuno Sá <nuno.sa at analog.com>
> > > > ---
> > > > v2:
> > > >    * Fix compilation when CONFIG_CFI_FLASH is not set. Done by
> > > > redefining
> > > > cfi_flash_bank_size() when CONFIG_CFI_FLASH is set (by returning dts
> > > > size).
> > > 
> > > Unfortunately this does not work. Build fails on multiple targets.
> > > Here an example:
> > > 
> > > $ make qemu_arm64_defconfig
> > > $ make -sj
> > > drivers/mtd/cfi_flash.c:120:13: error: conflicting types for
> > > 'cfi_flash_bank_size'; have 'phys_size_t(int)' {aka 'long long unsigned
> > > int(int)'}
> > >     120 | phys_size_t cfi_flash_bank_size(int i)
> > >         |             ^~~~~~~~~~~~~~~~~~~
> > > In file included from drivers/mtd/cfi_flash.c:36:
> > > include/mtd/cfi_flash.h:178:15: note: previous declaration of
> > > 'cfi_flash_bank_size' with type 'long unsigned int(int)'
> > >     178 | unsigned long cfi_flash_bank_size(int i);
> > >         |               ^~~~~~~~~~~~~~~~~~~
> > > 
> > > Please run a world build next before sending out the next patchset
> > > version.
> > > 
> > 
> > Arghh, sorry for this!
> > 
> > I did run it for micoblaze_defconfig and integratorcp_cm926ejs_defconfig.
> > Should
> > I build it with V1 or something? Or is there somewhere where I can push my
> > patchset to trigger some CI and look for these kind of things myself before
> > sending v3?
> 
> I'm testing with a world build on Azure, Gitlab provides a similar
> infrastructure. Some docs should be available for this.
> 

I see, I just cloned the tree from https://source.denx.de/u-boot/u-boot.git. I
will fork from github and trigger those builds.

- Nuno Sá