[Skiboot] [PATCH v2 2/7] libflash: Reintroduce typesafety in lowlevel libflash calls

[Cyril Bur]

On Wed, 26 Aug 2015 10:25:14 +1000
Samuel Mendoza-Jonas <sam.mj at au1.ibm.com> wrote:

> On 24/08/15 16:08, Cyril Bur wrote:
> > Previous work did away with some typesafety when adding the
> > blocklevel_device abstraction, this has resulted in the ability to
> > accidently call libflash low level code with a blocklevel_device which has
> > not been initialised by the libflash backend.
> > 
> > The end result will not be good. Best to reintroduce that low level calls
> > be called with libflashes own structures.
> > 
> > Signed-off-by: Cyril Bur <cyril.bur at au1.ibm.com>
> > ---
> >  libflash/libflash.c | 6 ++----
> >  libflash/libflash.h | 4 ++--
> >  2 files changed, 4 insertions(+), 6 deletions(-)
> > 
> > diff --git a/libflash/libflash.c b/libflash/libflash.c
> > index 831bdd4..18357fb 100644
> > --- a/libflash/libflash.c
> > +++ b/libflash/libflash.c
> > @@ -267,9 +267,8 @@ static int flash_erase(struct blocklevel_device *bl, uint32_t dst, uint32_t size
> >  	return 0;
> >  }
> >  
> > -int flash_erase_chip(struct blocklevel_device *bl)
> > +int flash_erase_chip(struct flash_chip *c)
> >  {
> > -	struct flash_chip *c = container_of(bl, struct flash_chip, bl);
> >  	struct spi_flash_ctrl *ct = c->ctrl;
> >  	int rc;
> >  
> > @@ -692,9 +691,8 @@ static int flash_set_4b(struct flash_chip *c, bool enable)
> >  	return ct->cmd_wr(ct, enable ? CMD_EN4B : CMD_EX4B, false, 0, NULL, 0);
> >  }
> >  
> > -int flash_force_4b_mode(struct blocklevel_device *bl, bool enable_4b)
> > +int flash_force_4b_mode(struct flash_chip *c, bool enable_4b)
> >  {
> > -	struct flash_chip *c = container_of(bl, struct flash_chip, bl);
> >  	struct spi_flash_ctrl *ct = c->ctrl;
> >  	int rc;
> >  
> > diff --git a/libflash/libflash.h b/libflash/libflash.h
> > index fa5143a..82b38ca 100644
> > --- a/libflash/libflash.h
> > +++ b/libflash/libflash.h
> > @@ -52,7 +52,7 @@ void flash_exit(struct blocklevel_device *bl);
> >  /* libflash sets the 4b mode automatically based on the flash
> >   * size and controller capabilities but it can be overriden
> >   */
> > -int flash_force_4b_mode(struct blocklevel_device *bl, bool enable_4b);
> > +int flash_force_4b_mode(struct flash_chip *c, bool enable_4b);
> >  
> >  /*
> >   * This provides a wapper around flash_read() on ECCed data. All params are
> > @@ -90,6 +90,6 @@ int flash_smart_write_corrected(struct blocklevel_device *bl, uint32_t dst, cons
> >  /* chip erase may not be supported by all chips/controllers, get ready
> >   * for FLASH_ERR_CHIP_ER_NOT_SUPPORTED
> >   */
> > -int flash_erase_chip(struct blocklevel_device *bl);
> > +int flash_erase_chip(struct flash_chip *c);
> 
> I'm sure I'm guilty of this myself elsewhere, but this is going to break pflash between this patch
> and the next isn't it? Would it be neater to have 3/7 occur first (adding the arch calls), and then
> have a transition patch?
> 

Good point, there's a bit of rejigging but really not that much, I'll send a v3 

> >  
> >  #endif /* __LIBFLASH_H */
> > 
> 
>