From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A65B03A5E65 for ; Tue, 2 Jun 2026 21:38:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780436293; cv=none; b=gwCmoeod1rejCvxDHzO38VEjSkNycwR1K3ptj4lSeLdMMMeoDLLfftJf/VEC/MVEXdQFMZVYifgOuxrc003YNY7UaHnru4/s/tpdsq/YkOIaxET/i6V5839c2O7tkFeHBWT65fhQ9XWnsQUG8O3GUSn8+ENw878UjOV+DL1s+jo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780436293; c=relaxed/simple; bh=hftNYSMbSp1TuP7VpQO7lZ+O/m6etFx9lq2NRS3Ojp8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SyApyPlyAq8omDz+IvyTRuhNQ0wDeGx8NL1l/r/3sqMkWkXjvsPz0oYgPzU7AFuiDfJziogScdyS46UYyFBh5yC3mKmFatOTg484e+WSCi/dbMxSnAmYawLdH5le4CUuaOxGEqRkVC4wO9PRiirN7DNNjSQ/VD2UfiPdnYnmzIU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BVwjolxZ; arc=none smtp.client-ip=209.85.221.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BVwjolxZ" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-45ef372c58aso2423391f8f.0 for ; Tue, 02 Jun 2026 14:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780436290; x=1781041090; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=g/ap9qia9JYLeOpELZTf6TGNRq7FqU62AdQC2ibLAXw=; b=BVwjolxZVO3PX6BW0zSnxud2oCM4P1Dd/OsATphXdpG7ly5mkf1eu3ZG6nOOQwnGh4 vSa2It49zTfUXbv1exRMkgCBIgu6vbzFk85aTS4saZpYkpzHCskJyh2amkGMbx7pLkpr WIhxg2FJP/09enWYHow4FvTSaSfNkcmkWhPd/WXCspzLO98psoEngYsKKdH+7OFu/UYr N0WWsUn3lhfzl12C8MuLj8M960Nbw6tpP/4YMmNdvIPYJD7iheDtmXu88VDZa1wTlcSv u5xczpYUMjIzRDJF/LJ4omsVEqxo4TfJvrlyoXl+eB2bWXO0l1ECCxn+uMhjEDy1rA26 wlzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780436290; x=1781041090; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=g/ap9qia9JYLeOpELZTf6TGNRq7FqU62AdQC2ibLAXw=; b=oZ84cihAsOWC5jFhwF9V6kNlAqVh/YgfClSQV0sUdQWXEFATG/XAx4LWBIB07Hqx3Q 96Jdjgsxd8i4ILlISiQI6iE4L1ODX3NQwF8on11SKLZBfJiUlsKvCmSq+Oj64QyypJis iWTjFbnuT30LkW7igieWlcJ4QOjO/kat8KqsTLCjXiRPR/0Ml+it/zalliZKl9o8oZ8i XSDnjE0JsDjCMBOFMrXrnAXqcWLXLgwg31AfP6gI+zyeDFxewmG/7+sPcO3nqwj/NKzf 5D08PkCFLWgfUjR8QL1HOmUo9XF1807WXPjQvYoKZlC7o6wq26arCNz+S/4VW/q3dEgb ij1w== X-Forwarded-Encrypted: i=1; AFNElJ+y5BOYtc7C69BkYJrwL+evLIj6k75oWoNbSTsKz5jPXY9fQwAFQfInBu7JTNlDRdtPDYb7lboRKGnjYYU=@vger.kernel.org X-Gm-Message-State: AOJu0YxjLxOHsZKX7lSNcV4vuxr427UdrR8BlmTcrSIhcs4j6hw7ow7o Wacrwxer7LAQ0D1J+wMr7uFU4JLIxCQVA+oRpCBw1S6/fXGl9HtrfR+0 X-Gm-Gg: Acq92OHZcAtQyWGJWygakr9LxF7bBTPRLDAc/gI5QRLhVVEvjN9rxaqG/3wSXNg/mWn CNe0zGNANBxw/xHivlAhP6XXbHSt8vsU9y6jIaGrF9TABLcrS37xnETbLlPdwmb1xB0XNlUhi4v u2esYQw+McVDZHj/lVH+hqHEGVM5SkQtQKQp2wulCHamWf6frBFWA0U4H3U0ncaAExopY6+qJ6n jnYbsle20sMtAaeuwHzx4vNQsyY1d9RaQoRHqR0KWuOVOxgrb1+KU2uoHjgCcA+v3YV0m4aDrY4 Cn2ODqb10OYCM3MJ8sqeqNsAR7PsRzFoHXKWgHL8O3IXXm8r28noUfBGlJ+fEacNBXF494xreFC jy+nkqzjb/KXcM0vczKrzfVvYapA0Vgg01/22HtKEDC/Z54vgjA0LYTX/s2K3ET0jWQ/P1hF8Ft Rn8jd9r4Bm/j3n0pM7vtjJjqK60xKM5TtdI7M6gbOt4gDKe3ATCrk9USzNNHEnBTFS+AaBjCE= X-Received: by 2002:a05:6000:2905:b0:460:ff2:63e5 with SMTP id ffacd0b85a97d-4602181e60fmr331877f8f.18.1780436289783; Tue, 02 Jun 2026 14:38:09 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f3529e0sm2333502f8f.28.2026.06.02.14.38.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 14:38:09 -0700 (PDT) Date: Tue, 2 Jun 2026 22:38:07 +0100 From: David Laight To: Selvamani Rajagopal Cc: Andrew Lunn , Piergiorgio Beruto , "parthiban.veerasooran@microchip.com" , "andrew+netdev@lunn.ch" , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "netdev@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 Message-ID: <20260602223807.1ac76456@pumpkin> In-Reply-To: References: <20260602150712.5b28d58b@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 2 Jun 2026 15:37:06 +0000 Selvamani Rajagopal 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 > > > >