[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc9cb634-2061-4933-839f-1298906ea189@gmx.net>
Date: Wed, 30 Apr 2025 16:27:44 +0200
From: Stefan Wahren <wahrenst@....net>
To: Andrew Lunn <andrew@...n.ch>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, netdev@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH net V2 4/4] net: vertexcom: mse102x: Fix RX error handling
Hi Andrew,
Am 30.04.25 um 15:47 schrieb Andrew Lunn:
> On Wed, Apr 30, 2025 at 03:30:43PM +0200, Stefan Wahren wrote:
>> In case the CMD_RTS got corrupted by interferences, the MSE102x
>> doesn't allow a retransmission of the command. Instead the Ethernet
>> frame must be shifted out of the SPI FIFO. Since the actual length is
>> unknown, assume the maximum possible value.
> I assume the SPI transfer won't get the beginning of the next frames
> to make up the shortfall of bytes when the frame is short?
Correct. The only possibility would be to triggered on the falling edge
/ low level of the SPI interrupt and try to cancel the possibly ongoing
SPI transfer.
I think this would introduce a lot complexity for an issue which is
actually caused by poor hardware design.
I think it's not worth the trouble.
Regards
>
>> Fixes: 2f207cbf0dd4 ("net: vertexcom: Add MSE102x SPI support")
>> Signed-off-by: Stefan Wahren <wahrenst@....net>
> Reviewed-by: Andrew Lunn <andrew@...n.ch>
>
> Andrew
Powered by blists - more mailing lists