[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7659191688194f099cba22cc367c4eda@AcuMS.aculab.com>
Date: Fri, 2 Aug 2024 08:10:02 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Simon Horman' <horms@...nel.org>, Herve Codina <herve.codina@...tlin.com>
CC: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Christophe Leroy <christophe.leroy@...roup.eu>, "Andy
Shevchenko" <andriy.shevchenko@...ux.intel.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "linuxppc-dev@...ts.ozlabs.org"
<linuxppc-dev@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, "stable@...r.kernel.org"
<stable@...r.kernel.org>
Subject: RE: [PATCH net v1] net: wan: fsl_qmc_hdlc: Discard received CRC
From: Simon Horman
> Sent: 31 July 2024 09:45
>
> On Tue, Jul 30, 2024 at 08:31:33AM +0200, Herve Codina wrote:
> > Received frame from QMC contains the CRC.
> > Upper layers don't need this CRC and tcpdump mentioned trailing junk
> > data due to this CRC presence.
> >
> > As some other HDLC driver, simply discard this CRC.
>
> It might be nice to specifically site an example.
> But yes, I see this pattern in hdlc_rx_done().
Pretty much the only reason you'd want the received CRC is to do
error recovery assuming a single short error burst.
Not that I've ever seen a driver contain the required code.
'Back of envelope' calculation: 32bit crc, 2kbyte frame, so 18bits
of crc per data bit, sqrt for 'birthday paradox' - I bet you can
recover 8-bit error bursts.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists