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