From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 7C56B2222C5 for ; Tue, 2 Jun 2026 14:07:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780409237; cv=none; b=Y/DrRW9Z/kXBA6HwAE6MfThnPMoNdZNiI92QiF9DqpNScS4aSYl2kqJ5HA1KYD2P+qBrv91UbpUeg0Rn6qlzXRilRBqTPwMPv7ngMByCx3MxNZ6kHE5HFtQhyYvQnd3t7mHnAEUZFBmjFHPPPHwK6ZqN8QyI3rNDysywS/DRz9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780409237; c=relaxed/simple; bh=llc5H9WBHGaxlcUbzKdk4lxBlagtHnWVxD05or7i6o0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=DoaJG7XJD8ZJ21T55EwRVV1FLaIkta4ioznJX5pmGsezDcxx16YkDmBNnNqwrE3fZo1eYMD3Y5mCW3K099TRSRrNiJBRMp73jR+bs+GbSLmGc7Q7CCm9NB6olhm9q41M1U3gYq2DdsH8M285j2DbxeKOBzC9FROBL3KUUfyETN8= 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=RbkPcLak; arc=none smtp.client-ip=209.85.128.48 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="RbkPcLak" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49068493267so66115895e9.1 for ; Tue, 02 Jun 2026 07:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780409235; x=1781014035; 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=ySKFRHOtwilW2CZ876p5LxsR0YIkNmJvgodgRlHIUfo=; b=RbkPcLakCPipOO7j1h1DnMZ4888DX4wyESYSAl5TjMk0uQ5400EuSAcXs4S82+NvFk 8uC79L/jKF6So23jtLL7Lq97W1jMIFqDLGG7gJJ5LC1aUCBLG9YPOmLD8/dcTkPS/HRz SK4XbIHl8q2HylV4ppb3afi6y3a4ZcMYBLd/YxiQiRveUtQZ0qR31vDQ9scSdMG2B2CI RcetsBPvNkxZJkRKruyhg6I0GdZRUFXD3C3bAUbRmL0mxoo4UtjojhqECaR2tpCj6q6N NQpZ36vdOGF1FEaHBYirp8Fo0Rt2dcfa7AtBstDaugMdN3e8TW8SZlpf5IOEpxOf2jwn vYiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780409235; x=1781014035; 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=ySKFRHOtwilW2CZ876p5LxsR0YIkNmJvgodgRlHIUfo=; b=ACdI8Im3ZvyJxJst3LMq7cciK41a0OTE82ihvz9zvdD4KKpZS+7+1VsuiAXv1hh3GW ApwppzmxcWTbMM1PhOdzBZXGr746N0RPUgBaXJHbMeaeAhWjh/VJvTOhLxoX0scpTac6 oHu/8IPA759lbCtSp4vYNFudXa6peJtOtQwsynEC++TYTDy7mnNNjOEE5RRPI3nq2NMY QN00ieqQlLps6Aqpa3HllAoLddCahzSR3ZIhllgykz7nx4wupNP5VCSxMf55RVoyyFY/ Ku2i3FMnHvWB+h9HI+zrstWd6FXai3bEPCLbueJnRxw5Nff7QCDAkvoxY919XI/Px9c5 M+iw== X-Forwarded-Encrypted: i=1; AFNElJ/QrXI6nF3JWCiojXYmrF0aXut29lkcLV1bO6ahjo9WU3zDranwAht/mi54U+VvwCVeOtVGbp7f3b7FpTg=@vger.kernel.org X-Gm-Message-State: AOJu0YywKoMKCM9aGWiK0PZv7qC+UyfGn4imgbbB9Icw3iEZ2aaF8QaV uQqoJAlqvHz/DsH0G7D6muSrYPziRysY/zrqOqf8x4JHbf9VyEVLHHM5 X-Gm-Gg: Acq92OHEdwux0aWNIWQ4SwZ5erY1j4u+svx+JB/plb725owdcqpSj2p9u4iLdWGOOUe rnyX6S7MCMvAgAm66D4fs16JPyi8hOI4AP4603gJMlfpBJXFMpGx2gtkZzEVackz15CUkTESf7Y peF6CaTtXIsGad5kfKSzFE9YTcrZU+dU8FQYmGDUU3O9O51+mvBfSBl9eyr05EgHXg6an/kKMbn Dt3XMLweXmh5ZeavZPcWrhg7PbHa4+vfLOAQqRo5dbKtnT8JS32nnG4Gxu2VFqiAuGUYowmk4/C WZmQbAgpJ+VfdrH3b1HmD7r6fpOus7pmL6wr6UZ59blfMNh+M0brO+Dk1iwbyN1Y9MMRnDkEHow jwaKxJX1sKnrh9Gzgtf0OyDH/g/Fyw+peliyLiz0k3Hft1LwZpg9vkCzLyXLETjoJ+nJfsIp9c/ iakUmTyehsOuymZHBN8+ErHDc4yMvLHhNrwNQ0vbUbkD1JcEZc7B2Cnl8NXWSVHTyS4Q0IpcU= X-Received: by 2002:a05:600c:2a8a:b0:490:44eb:c1ec with SMTP id 5b1f17b1804b1-490a293cf3bmr198249765e9.27.1780409234775; Tue, 02 Jun 2026 07:07:14 -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-45ef354bb62sm32057112f8f.19.2026.06.02.07.07.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 07:07:14 -0700 (PDT) Date: Tue, 2 Jun 2026 15:07:12 +0100 From: David Laight To: Andrew Lunn Cc: Selvamani Rajagopal , 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: <20260602150712.5b28d58b@pumpkin> In-Reply-To: References: 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 Sun, 31 May 2026 16:50:35 +0200 Andrew Lunn wrote: > On Fri, May 29, 2026 at 06:41:00PM +0000, Selvamani Rajagopal wrote: > > When MAC-PHY appends FCS to the incoming frame, FCS, > > it is removed from the frame before passing it to the stack. If the MAC appends the FCS to an incoming frame it must be removed before passing the frame into the stack. > > What is missing from this commit message is an answer to the question > "Why?". Does the stack do something wrong if there is a FCS at the end > of the frame? Unexpected padding ought to be an error. If anything tries to parse LLC frames (with a length not an ethertype) then padding is only expected on short frames. Even for IP a frame with an length that is otherwise too short might pick up the crc bytes as valid data instead of it being discarded as invalid. 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.) -- David > > Andrew >