bcm-qspi: unstable bspi mode since the 345309fa7c0c ("spi: bcm-qspi: Fix bcm_qspi_bspi_read() performance")

[Rafał Miłecki <rafal.milecki@xxxxxxxxx>]

I use OpenWrt distribution running 4.14.48 kernel on Broadcom's Northstar
devices. For hardware description you can check bcm5301x.dtsi.

Some of my devices have SPI NOR flash connected to the Broadcom's SPI
controller. Reading flash content is handled using BSPI mode/controller.

The problem is that I randomly see BSPI timeouts like this:

[   15.637809] bcm_iproc 18029200.spi: timeout waiting for BSPI
[   15.643471] jffs2: error: (430) check_node_data: can not read 305 bytes from 0x008a1264, error code: -110.
[   15.653118] jffs2: error: (430) check_tn_node: check_node_data() returned error: -110.
[   15.661262] jffs2: error: (430) jffs2_do_read_inode_internal: CRC failed for read_inode of inode 6967 at physical location 0x8a1420
[   15.673065] jffs2: Returned error for crccheck of ino #6967. Expect badness...

[   15.997809] bcm_iproc 18029200.spi: timeout waiting for BSPI
[   16.003463] jffs2: error: (430) check_node_data: can not read 1840 bytes from 0x008abf04, error code: -110.
[   16.013192] jffs2: error: (430) check_tn_node: check_node_data() returned error: -110.
[   16.021882] jffs2: notice: (430) check_node_data: wrong data CRC in data node at 0x008ab81c: read 0x7b1aaf59, calculated 0xf66cce81.

[   16.173466] jffs2: error: (430) check_node_data: can not read 814 bytes from 0x0083da04, error code: -110.
[   16.183110] jffs2: error: (430) check_tn_node: check_node_data() returned error: -110.
[   16.191469] jffs2: notice: (430) check_node_data: wrong data CRC in data node at 0x0083d5e4: read 0xb9c58541, calculated 0xc4eede34.

This of course causes filesystem stability problems.

I spent a moment trying to debug this problem and it appears it didn't
occur before the 345309fa7c0c ("spi: bcm-qspi: Fix bcm_qspi_bspi_read()
performance"). Reverting all /recent/ bcm-qspi commits including above
ones brings back the stability for me.

Before above commit every time that bcm_qspi_bspi_lr_l2_isr() called
bcm_qspi_bspi_lr_l2_isr() it was resulting in bspi_rf_msg_len becoming
0.
With above commit it's not the case anymore so I suspect there may be
some bug around that code.

Can you see some possible problem related to the BSPI handling?

Kamal could you take a look at this, please?

________________________________

Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite.


This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html