[PATCH] RFC: mtd/spi-nor: add checking for the spi_nor_read

[Hou Zhiqiang]

Hello,

I want to add the 4-Byte addressing flashes support for the Freescale eSPI
controller dirver. Appreciate your suggestions.

Background:
In the Freescale eSPI controller dirver, if the transaction length exceed
64KiB, the contents of the transaction was touched to update the command 
with assumed the 3-Byte address width. It is a workaround, due to the 
Freescale eSPI controller have a hardware limit that the maximum one-time
transaction length is 64KiB, that isn't consistent with many other vendors'
SPI controllers, and so far the SPI flash driver assume the SPI controller
have the ability to complete the specified transaction length at one-time.
 
But this workaround is only suit for 3-Byte addressing slaves, as time goes
by, there are 4-Byte address width SPI flashes, so this assumption isn't 
correct and this workaround discombobulate the controller driver layer and
protocol driver layer. So, this workaround should be removed and the SPI
client driver should ensure the transaction completion.

There are two solutions:
1. In spi-nor framework, compare the retlen with the transaction length
specified, if the retlen less than the transaction length and with no error
number returned, re-initiate the transaction with the updated address.
Advantage: 
It won't affect other SPI controllers without this limit.
Disadvantage: 
It is not a systematic solution.

2. Add quirk support, something like i2c quirk.
Advantage: 
It is a systematic solution.
Disadvantage: 
The quirk mechanism is only useful for Freescale eSPI controller, but it will
affect whole SPI framework.


> -----Original Message-----
> From: Hou Zhiqiang-B48286
> Sent: 2015年7月31日 18:36
> To: Hou Zhiqiang-B48286; linux-mtd at lists.infradead.org;
> computersforpeace at gmail.com; dwmw2 at infradead.org; shijie.huang at intel.com
> Cc: Hu Mingkai-B21284
> Subject: RE: [PATCH] RFC: mtd/spi-nor: add checking for the spi_nor_read
> 
> Hi Shijie and Brian,
> 
> Do you have any comment?
> 
> > -----Original Message-----
> > From: Zhiqiang Hou [mailto:B48286 at freescale.com]
> > Sent: 2015年7月21日 19:57
> > To: linux-mtd at lists.infradead.org; computersforpeace at gmail.com;
> > dwmw2 at infradead.org
> > Cc: Hu Mingkai-B21284; Hou Zhiqiang-B48286
> > Subject: [PATCH] RFC: mtd/spi-nor: add checking for the spi_nor_read
> >
> > From: Hou Zhiqiang <B48286 at freescale.com>
> >
> > Compare the var retlen with len to ensure the read operation successful.
> >
> > There are some SPI controllers that have a maximum transfer length, e.g.
> > Freescale eSPI controller is able to transfer 0x10000 Bytes each time.
> > If the spi_nor_read diliver a transaction length that excced the
> > ability of the SPI controller, there should be multiple read operation
> > to make sure this transaction completion.
> >
> > Signed-off-by: Hou Zhiqiang <B48286 at freescale.com>
> > ---
> >  drivers/mtd/spi-nor/spi-nor.c | 14 ++++++++++++--
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-
> > nor.c index fbc5035..ec10cd1 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -715,6 +715,8 @@ static int spi_nor_read(struct mtd_info *mtd,
> > loff_t from, size_t len,  {
> >  	struct spi_nor *nor = mtd_to_spi_nor(mtd);
> >  	int ret;
> > +	size_t cnt = 0;
> > +	u_char *cur = buf;
> >
> >  	dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
> >
> > @@ -722,8 +724,16 @@ static int spi_nor_read(struct mtd_info *mtd,
> > loff_t from, size_t len,
> >  	if (ret)
> >  		return ret;
> >
> > -	ret = nor->read(nor, from, len, retlen, buf);
> > -
> > +	*retlen = 0;
> > +	while (len > 0) {
> > +		ret = nor->read(nor, from, len, &cnt, cur);
> > +		if (ret < 0)
> > +			break;
> > +		len -= cnt;
> > +		cur += cnt;
> > +		*retlen += cnt;
> > +		from += cnt;
> > +	}
> >  	spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_READ);
> >  	return ret;
> >  }
> > --
> > 2.1.0.27.g96db324
> 
> Thanks,
> Zhiqiang

Thanks,
Zhiqiang