On 11.07.24 01:48, Jacob Keller wrote:
On 7/9/2024 12:58 PM, Ronald Wahl wrote:
From: Ronald Wahl ronald.wahl@raritan.com
The amount of TX space in the hardware buffer is tracked in the tx_space variable. The initial value is currently only set during driver probing.
After closing the interface and reopening it the tx_space variable has the last value it had before close. If it is smaller than the size of the first send packet after reopeing the interface the queue will be stopped. The queue is woken up after receiving a TX interrupt but this will never happen since we did not send anything.
This commit moves the initialization of the tx_space variable to the ks8851_net_open function right before starting the TX queue. Also query the value from the hardware instead of using a hard coded value.
Only the SPI chip variant is affected by this issue because only this driver variant actually depends on the tx_space variable in the xmit function.
I'm curious if this dependency could be removed?
I don't think so.
The driver must ensure not to write too much data to the hardware so we need a precise accounting of how much we can write. In the original driver code for the SPI variant this was broken and repaired in 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overrun"). Unfortunately we required some rounds of bug fixing to get it finally working without any issues. Hopefully this was the last change in that regard. :-)
If you ask why only the SPI version is affected then the answer is that for the parallel interface chip there is no internal driver queuing, i.e. it writes a single packet per xmit call. Not sure if this can also overrun the hardware buffer if the receiver throttles via flow control. Since I do not own this chip variant I cannot test this. In the end that could even mean that we would need the accounting for the parallel chip code as well.
- ron