spi-nand: GigaDevices Support; qca9560-spi Device-ID Byte-Shift Inconsistency

[Jeff Kletsky <lede@xxxxxxxxxxxx>]

I'm in the process of trying to use the spi-nand framework present in
Linux 4.19 with a QCA9563-based device that appears to use a
GigaDevices GD5F1GQ4UFxxG SPI NAND (GL.iNet AR750S) on the ath79 platform.

I've backported the two commits[1] I found on Linux 5.x related to the
GigaDevices SPI NAND but have two questions that I haven't been able
to resolve with only that single device in hand.


---


The first is that, at least with the SPI driver used by the QCA9563 on
that platform (`compatible = "qca,qca9560-spi", "qca,ar7100-spi";`)[2],
is that the results of the Read ID does not seem to need the byte
shift in `gigadevice.c`

   /*
    * For GD NANDs, There is an address byte needed to shift in before IDs
    * are read out, so the first byte in raw_id is dummy.
    */

`spi-nand spi0.1: unknown raw ID c8b148c8` is seen in dmesg. I have
confirmed the byte order. `c8:b1:48` matches the signature shown on
the datasheet[3] in Table 10-1 for the GD5F1GQ4UFxxG, without the byte
shift. Yes, I will need to implement the `b1` device variant, but
`gigadevice.c` is being short-circuted as `b1` is being checked
against the manufacturer's code, not `c8`.

While I can locally "hack" the code to not perform the byte shift, I
can't determine the extent of devices/drivers.

I did find a post to this list in February, 2017[4] that includes

  /*
   * read ID command format might be different for different manufactory
   * such as, Micron SPI NAND need extra one dummy byte after perform
   * read ID command but Giga device don't need.
[...]

so that this may have come up before.

Any additional information on this would be appreciated.


---


The second question relates to enabling the use of the GD5FxGQ4FxxG
series. It appears that I will need to implement

  _ooblayout_ecc()
  _ooblayout_free()

and the like. Though I've read through both the F-series data sheet[3]
as well as the E-series data sheet[5], it's not clear to me where the
ooblayout comes from.

Is this an implementation decision for Linux, or is there a section of
the two datasheets that could assist me in proper implementation of
the layout for the GD5F1GQ4UFxxG series?


(Information for _ecc_get_status() appears to be in the data sheet.)


Thanks,

Jeff




[1] linux$ git log --pretty=oneline -- drivers/mtd/nand/spi/gigadevice.c
c40c7a990a46 mtd: spinand: Add support for GigaDevice GD5F1GQ4UExxG
c93c613214ac mtd: spinand: add support for GigaDevice GD5FxGQ4xA

[2] ath79/dts/qca956x.dtsi

[3] <http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/>

[4] <http://lists.infradead.org/pipermail/linux-mtd/2017-February/072308.html>

[5] <http://www.gigadevice.com/datasheet/gd5f1gq4xexxg/>





______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/