Sorry, it was a copy/paste error. I’ve corrected the post.
have my git corrected too…
is my guess right, that driver had only handled TX but not RX? so it have to be fixed in mainline
Yes, you are right. In FIFO mode were two problems. RX mode was never handled and, in this case the tx_buf pointer was NULL and caused an exception.
1 Like
Posted Patch to mainline,let’s wait for reactions
Nice, merged on first version (for 5.15)
1 Like
Great work! Meanwhile I will also add this to OpenWrt. Do you plan to backport that to 5.4 and 5.10?
Imho patch should work on 5.4 too…but i’ve missed stable-tag 
1 Like
Just created the PR for the backport, but I still have no BPI-R2, that makes testing complicated… xD
1 Like
i’ve send mail to stable-ML to have it included in older LTS kernels (at least 5.4 and 5.10)
https://lkml.org/lkml/2021/7/24/27
btw. it is already in 5.14 as it is a fix and already merged in linus torvald’s tree
1 Like
Nice, thanks. 
I accidentally wrote 5.15 kernel. ^^ I waiting for my BPI-R2! 
Spi fix is now queued for 4.9+ after a short conversation with stable maintainer (greg k h). 4.4 will need a backport,but as mtk uses their own source not up-to-date upstream 4.4 and most boards are not supported in 4.4 i have skipped 4.4
1 Like
The patch got a revert in Mailinglist as it breaks another device. Commit message says rx is normally handled by interrupt…but this seems not to be the case on r2…
https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/
Maybe interrupt is wrong? https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/mt7623.dtsi#L487
How can we find out?
I’ m working on it. I’ ll build a separate SPI slave device to test all specific SPI communications to enshure everything works proper.