[RFC] net: vertexcom: mse102x: Fix SPI interrupt handling #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's hard to debug the SPI interrupt level, so implement the possibility to allocate the SPI interrupt as a GPIO. This allows to debug the current level with the common tools. Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
This allows to debug the SPI interrupt level. Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
Since the SPI implementation on the MSE102x MCU is in software, it cannot reply to SPI commands in busy state. So drop the scaring statistics about "invalid" command replies. Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
The MSE102x doesn't provide any SPI commands for interrupt handling. So in case the interrupt fired before the driver requests the IRQ, the interrupt will never fire again. In order to fix this always poll for pending packets after opening the interface. Fixes: 2f207cb ("net: vertexcom: Add MSE102x SPI support") Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
According to the MSE102x documentation the trigger type is a high level. Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
Since there is no protection in the SPI protocol against electrical interferences, the driver shouldn't blindly trust the length payload of CMD_RTS. So do at least a lower bounds check for incoming frames. Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
According to the MSE102x documentation the trigger type is a high level. Fixes: 2717566 ("dt-bindings: net: add Vertexcom MSE102x support") Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
Since mse102x_rx_pkt_spi is also used for polling and the SPI IRQ type is level based, there is actually no need for a retry mechanism within mse102x_rx_pkt_spi. So drop it and simplify the receive path. Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
The example of the initial DT binding of the Vertexcom MSE 102x suggested a IRQ_TYPE_EDGE_RISING, which is wrong. So warn everyone to fix their device tree. Signed-off-by: Stefan Wahren <stefan.wahren@chargebyte.com>
lategoodbye
force-pushed
the
v6.6.23-vertexcom_int
branch
from
658e45c to
f55250a
Compare
|
range check for CMD_RTS has been adjusted (no upper bounds check) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This series fixes the handling of the SPI interrupt in the MSE102x driver. The current solution is consider as a request for comments.
Additional it improves the related debug capabilites by introducing an optional DT property to use the interrupt line as GPIO (currently not intended for upstream).