From: David Laight <david.laight.linux@gmail.com>
To: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Piergiorgio Beruto <Pier.Beruto@onsemi.com>,
"parthiban.veerasooran@microchip.com"
<parthiban.veerasooran@microchip.com>,
"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next v3 08/14] net: ethernet: oa_tc6: Remove FCS size in RX frame
Date: Tue, 2 Jun 2026 22:38:07 +0100 [thread overview]
Message-ID: <20260602223807.1ac76456@pumpkin> (raw)
In-Reply-To: <CY8PR02MB9249B26D4B4344064A582A3C83122@CY8PR02MB9249.namprd02.prod.outlook.com>
On Tue, 2 Jun 2026 15:37:06 +0000
Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com> wrote:
> > Subject: Re: [PATCH net-next v3 08/14] net: ethernet: oa_tc6: Remove FCS size in RX
> > frame
> >
> >
> [..]
>
>
> >
> > More of a question is why request the MAC append the FCS at all.
> > You can use it for error correction - but no one every does.
> > (A 2k frame has 32-14=18 crc bits for each bit offset which means
> > you have an 'average chance' of finding an 18bit error burst that
> > will fix every crc error. If you find an 8bit burst error that matches
> > the crc error there is a reasonable chance it is what caused the error.
> > Single error bursts are the most likely errors and easy to locate.)
>
> My understanding is that in TX side, MAC will pad FCS automatically.
TX pad is separate from the FCS.
The frames are padded to a minimum size so that collision detect works
on maximal length 10M coax segments.
(Or rather coax+link+coax+link+coax acting as a single collision domain.)
The same minimum frame length is used on modern networks which are all
physically point-to-point and all 'hubs' are store+forward where a minimum
packet length isn't strictly needed.
VLAN headers can give unexpected amounts of padding - VLAN didn't exist
when I was writing ethernet drivers!
> RX side, MAC may or may not strip FCS
> before passing to the host. I believe our MAC doesn't strip FCS in RX side.
>
> Here is what OPEN Alliance 10BASE-T1x MAC-PHY Serial Interface specification says
>
> 7.3 Data Transaction Protocol for Ethernet Frames
> [..]
> Ethernet frames are typically transferred from the SPI host to the MAC-PHY without any padding or frame
> check sequence (FCS). The MAC will automatically pad the Ethernet frame to the minimum frame size of 64
> bytes and append a computed FCS
> [..]
> Similarly, the MAC-PHY will typically strip the FCS from received Ethernet frames prior to transfer to the SPI
> host. However, the Ethernet specification allows the option for the Ethernet frame to be transferred to the
> MAC client with the FCS.
Is this an SPI interface to the ethernet MAC?
You might want to pass the FCS over the SPI link and then verify in software
before treating the frame as valid, deleting the FCS, and passing the frame to
the protocol stack.
This would give extra protection for errors on the SPI link that might not
otherwise be detected.
(Although if you distrust the SPI link you'd what to pass the TX FCS as well.)
Unless you are doing IP checksum offload the IP checksum will pick up TCP/UDP errors.
But if you are running ISO transport (which we did 30 years ago) there is
no other checksum. So if/when you have a VMEbus card that suffers ground
bounce when, for example, passing a repeated 0xff, 0xff, 0x00 sequence you
get corrupted files from any files transfer request.
-- David
>
>
> >
> > -- David
> >
> > >
> > > Andrew
> > >
>
next prev parent reply other threads:[~2026-06-02 21:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 18:41 [PATCH net-next v3 08/14] net: ethernet: oa_tc6: Remove FCS size in RX frame Selvamani Rajagopal
2026-05-31 14:50 ` Andrew Lunn
2026-06-02 2:40 ` Selvamani Rajagopal
2026-06-02 3:01 ` Qingfang Deng
2026-06-02 12:00 ` Andrew Lunn
2026-06-02 14:07 ` David Laight
2026-06-02 15:37 ` Selvamani Rajagopal
2026-06-02 21:38 ` David Laight [this message]
2026-06-02 22:24 ` Selvamani Rajagopal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260602223807.1ac76456@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=Pier.Beruto@onsemi.com \
--cc=Selvamani.Rajagopal@onsemi.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=parthiban.veerasooran@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox