Error handling in spi-nor and dealing with short reads/writes

Heiner Kallweit hkallweit1 at gmail.com
Wed Oct 7 12:41:37 PDT 2015


I stumbled across some missing error handling in spi-nor and when having a look at the
list archive I found some proposed patches and related discussions.
However it seems like there was no result, at least I didn't find accepted patches
dealing with this issue.

To summarize few issues:

1. I didn't find any clear definition how the read / write callbacks in spi_nor and mtd_info
   are supposed to handle the retlen argument (returning the actual length of the current
   transfer or adding it to the current value of *retlen).
   Maybe due to this missing specification there are different implementations of the read
   callback in spi_nor:
   m25p80_read: sets *retlen to the actual length of the current transfer
   nxp_spifi_read: adds it to *retlen
   fsl_qspi_read: adds it to *retlen
   Luckily this has no impact so far as mtd_read initializes *retlen to 0 before calling
   the _read callback (once).

2. The write callback in spi_nor is defined with a void return type and doesn't allow to
   handle the case of a failing transfer.

3. It's unclear at which layer incomplete reads/writes are acceptable (and therefore which
   layer can / should loop to assemble chunks).

My 2ct:

1. They should return the actual length of the current transfer in *retlen.
   In case of a partial transfer they should return an error (e.g. -EIO or -EMSGSIZE).
   This allows the caller to identify a partial transfer and the amount of
   bytes successfully transferred. Then the caller can decide whether he wants
   to retry for the failed part of the transfer and later assemble the chunks.

2. Make it return int (like _write in mtd_info).

3. I prefer to handle read chunks in spi_nor_read (submitted a related patch already).
   Not sure whether it would make sense to add chunk handling also for writes.
   I'm not aware of any controller which is not able to transfer at least a single page
   at once.

This is meant as a RfC. Also I may have missed important parts of the discussion.
Appreciate any hint or comment.



More information about the linux-mtd mailing list