Received-SPF: pass (google.com: domain of linux-kernel+bounces-169473-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: Piergiorgio Beruto <Pier.Beruto@onsemi.com>
To: Andrew Lunn <andrew@lunn.ch>,
        "Parthiban.Veerasooran@microchip.com"
	<Parthiban.Veerasooran@microchip.com>
CC: "ramon.nordin.rodriguez@ferroamp.se" <ramon.nordin.rodriguez@ferroamp.se>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "edumazet@google.com"
	<edumazet@google.com>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "horms@kernel.org"
	<horms@kernel.org>,
        "saeedm@nvidia.com" <saeedm@nvidia.com>,
        "anthony.l.nguyen@intel.com" <anthony.l.nguyen@intel.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "corbet@lwn.net" <corbet@lwn.net>,
        "linux-doc@vger.kernel.org"
	<linux-doc@vger.kernel.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>,
        "conor+dt@kernel.org" <conor+dt@kernel.org>,
        "devicetree@vger.kernel.org"
	<devicetree@vger.kernel.org>,
        "Horatiu.Vultur@microchip.com"
	<Horatiu.Vultur@microchip.com>,
        "ruanjinjie@huawei.com"
	<ruanjinjie@huawei.com>,
        "Steen.Hegelund@microchip.com"
	<Steen.Hegelund@microchip.com>,
        "vladimir.oltean@nxp.com"
	<vladimir.oltean@nxp.com>,
        "UNGLinuxDriver@microchip.com"
	<UNGLinuxDriver@microchip.com>,
        "Thorsten.Kummermehr@microchip.com"
	<Thorsten.Kummermehr@microchip.com>,
        Selvamani Rajagopal
	<Selvamani.Rajagopal@onsemi.com>,
        "Nicolas.Ferre@microchip.com"
	<Nicolas.Ferre@microchip.com>,
        "benjamin.bigler@bernformulastudent.ch"
	<benjamin.bigler@bernformulastudent.ch>
Subject: RE: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error
 interrupts unmasking
Thread-Topic: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error
 interrupts unmasking
Thread-Index: 
 AQHakZAC89gsXFcqv0WhzhAN3HgiZLF8la6AgAAX2YCAANNtAIAAVU8AgATxiYCAAQbggIAAAp2AgAFdb4CABFWKgIAAWgJw
Date: Mon, 6 May 2024 06:47:32 +0000
Message-ID: 
 <BY5PR02MB678683EADBC47A29A4F545A59D1C2@BY5PR02MB6786.namprd02.prod.outlook.com>
References: <20240418125648.372526-1-Parthiban.Veerasooran@microchip.com>
 <20240418125648.372526-6-Parthiban.Veerasooran@microchip.com>
 <Zi1Xbz7ARLm3HkqW@builder> <77d7d190-0847-4dc9-8fc5-4e33308ce7c8@lunn.ch>
 <Zi4czGX8jlqSdNrr@builder> <874654d4-3c52-4b0e-944a-dc5822f54a5d@lunn.ch>
 <ZjKJ93uPjSgoMOM7@builder>
 <b7c7aad7-3e93-4c57-82e9-cb3f9e7adf64@microchip.com>
 <ZjNorUP-sEyMCTG0@builder>
 <ae801fb9-09e0-49a3-a928-8975fe25a893@microchip.com>
 <fd5d0d2a-7562-4fb1-b552-6a11d024da2f@lunn.ch>
In-Reply-To: <fd5d0d2a-7562-4fb1-b552-6a11d024da2f@lunn.ch>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?iso-8859-1?Q?O6EAG7Pgl9Hkp+6DaMyZcbxunG/De5BH3aX1o25cb9XhhPY9RVc6zmotW3?=
 =?iso-8859-1?Q?GPwm1ivf3AJ9CSNLCVnp/YdYoRgDQrujxL4qhIehAKCT/U11Uy6X64uJji?=
 =?iso-8859-1?Q?w9+Lofb4spkYxbcYmxdECyp689BKLq/qetUmk8PgYyLJDyudxEG1Qdkd6u?=
 =?iso-8859-1?Q?lvgoe8P9cNpr/4USMVNdFG/zMcwtYRF4BfteKjIk8i3m/WLcsupCSBoXcs?=
 =?iso-8859-1?Q?b3gtTnmEW/QKgV7ErkVOQTG0CEdxRxNNk5ZVf9LMJU6GaV37fNBBFawq66?=
 =?iso-8859-1?Q?VwNpz3vRL5jAF+bXErYbrkCHnKOWLsnKyag81MmgK/lI6MAwwhuvX57cxu?=
 =?iso-8859-1?Q?dGv+xjSIGtupatpkoS1uU8P0qgIIdPwbSY/b3qMQ5luH/V8h2SkyboCSZT?=
 =?iso-8859-1?Q?qi1FCBX/J9CvYWel3smBCWpd/sKSjeaXiJ7vUPxEPAQ0W0untqs+Zt8ye6?=
 =?iso-8859-1?Q?8FfO1p4ZHKwY3EtOodRzHTHslJfcBFBh3SWllAfyi2J4Ce6qhgOebnAGHK?=
 =?iso-8859-1?Q?0Cph7ZTQRRQqh3QblyqxBLDUP6duWU5uNVQd9QK8/dCgWYHhMGZEDx12kS?=
 =?iso-8859-1?Q?9I2UjyzmMmY2SBJhKCZjYkgo7mDqWIMMnZCy8gizAMh0tx8TqWE6fEnjFC?=
 =?iso-8859-1?Q?n1xXGRPuaD9BeVDTRzw+SbUptUHjOrekDox6QVrN9WX1glvnBD9Wp030qy?=
 =?iso-8859-1?Q?mgAvi+YckwR4Xp6ZCCS60lraMEjZGN4mVkvDHMls7Gu1rxE1Xd5+Ftr+lO?=
 =?iso-8859-1?Q?Exu6kEEtzbEeenKxhNEAHDQnxGEpZAbqj5BNeK9f+myk/jYTWC2+8Bu9UW?=
 =?iso-8859-1?Q?BO0MSF4BCiBfhhNRXx8DC05sr/RBmwT3YG8FsWVUuyRZl3ocy4V1RVR35j?=
 =?iso-8859-1?Q?pioodvzMDMrTbWQN6oc1I+3FkUbwmVCpCczTyUfqGfiXHlmRxMwG+sha3L?=
 =?iso-8859-1?Q?w/y3XCtKkP2sJjLgEglEKs82FoGipVmtHubvnIaYcqfz1l/8iMJ0sH9O15?=
 =?iso-8859-1?Q?JF5c2Npy2wCfCgKxoCwvcbidKSrbR3+1zlkcvh5g4zsX/OUj0CAaLKqIkA?=
 =?iso-8859-1?Q?Z/I1yiKNHjNBEmMDJjyY0Wq5QwQNKlslB5zOO4bnocVZvr+k4SiJJDCtyT?=
 =?iso-8859-1?Q?csuK6HSP65NJD5hlh7DpivD1K7luEac9hHFRK9r7fmgFvrFDHFeWI16QPM?=
 =?iso-8859-1?Q?AFwcMeYgVoUiC04Xgip9eOu2IJ0K+vq+XMoAS1ft/xY9d0lqg5xVIhxUnj?=
 =?iso-8859-1?Q?+OBYhn7W57kpEmDE6Xomso9ZAfbTIGschax1fWOPbgkeT6b4VOt5mxvuJa?=
 =?iso-8859-1?Q?D5J1vN7NWeo7oAmYtklrURIpiw93ck0Zed8EIqqv4dlDSByLBI6qt4skyX?=
 =?iso-8859-1?Q?BbiJr/P0hvVsfE8+G/cmoxORCnymom1kX3MsnbofKXC5su/MW0SoUBM3FJ?=
 =?iso-8859-1?Q?UCbyHnezOQRzqY55mraWVLGJsKpr0n2J+0DHyRcFWL/+VcJsPYGXCuEjIo?=
 =?iso-8859-1?Q?plDO8U5HFu+cD3E1ZZ7yHtlByRzi39xDWX7pRKGfWQHFwhL652ny0uOjTF?=
 =?iso-8859-1?Q?UjfJ7pU8tfQQWzip9KI0B8dscVyRUekWd3YGilvGTAmoxISoxQx1vRvm3M?=
 =?iso-8859-1?Q?tSo+X7Rx7hA4OUmUNXg7qFN0nZXpTRptXS?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: onsemi.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR02MB6786.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ffd48f4-5a68-425b-6578-08dc6d986803
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2024 06:47:32.7027
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 04e1674b-7af5-4d13-a082-64fc6e42384c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bhyyBGGb6z2goelWfSJzICK9VSIha1p30w+WCQescI6QHXGVJBXa2HQS2K720c6OrvtOeVE0iDaWFKJtRMu6EQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR02MB9327
X-Proofpoint-GUID: RSfE5npXVMhGf6yxJ4O136p0PrBafcoF
X-Proofpoint-ORIG-GUID: RSfE5npXVMhGf6yxJ4O136p0PrBafcoF
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.650,FMLib:17.11.176.26
 definitions=2024-05-06_03,2024-05-03_02,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 bulkscore=0
 lowpriorityscore=0 suspectscore=0 mlxlogscore=999 phishscore=0
 malwarescore=0 mlxscore=0 impostorscore=0 priorityscore=1501 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2404010003
 definitions=main-2405060042

HI all,

The RXBOE is basically a warning, indicating that for some reason the SPI h=
ost is not fast enough in retrieving frames from the device.
In my experience, this is typically caused by excessive latency of the SPI =
driver, or if you have an unoptimized network driver for the MACPHY.

And no, you would certainly NOT drop a frame that is transferred over the S=
PI bus. It is the frame at the ingress of the device that will be dropped (=
ie the one at the end of the queue, not the beginning)..
Just my 0.2cent

Thanks,
Piergiorgio

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>=20
Sent: 6 May, 2024 03:21
To: Parthiban.Veerasooran@microchip.com
Cc: ramon.nordin.rodriguez@ferroamp.se; davem@davemloft.net; edumazet@googl=
e.com; kuba@kernel.org; pabeni@redhat.com; horms@kernel.org; saeedm@nvidia.=
com; anthony.l.nguyen@intel.com; netdev@vger.kernel.org; linux-kernel@vger.=
kernel.org; corbet@lwn.net; linux-doc@vger.kernel.org; robh+dt@kernel.org; =
krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org; devicetree@vger.ker=
nel.org; Horatiu.Vultur@microchip.com; ruanjinjie@huawei.com; Steen.Hegelun=
d@microchip.com; vladimir.oltean@nxp.com; UNGLinuxDriver@microchip.com; Tho=
rsten.Kummermehr@microchip.com; Piergiorgio Beruto <Pier.Beruto@onsemi.com>=
; Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>; Nicolas.Ferre@micro=
chip.com; benjamin.bigler@bernformulastudent.ch
Subject: Re: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement err=
or interrupts unmasking

[External Email]: This email arrived from an external source - Please exerc=
ise caution when opening any attachments or clicking on links.


> [  285.482275] LAN865X Rev.B0 Internal Phy spi0.0:00: attached PHY=20
> driver (mii_bus:phy_addr=3Dspi0.0:00, irq=3DPOLL) [  285.534760] lan865x=
=20
> spi0.0 eth1: Link is Up - 10Mbps/Half - flow control off [ =20
> 341.466221] eth1: Receive buffer overflow error [  345.730222] eth1:=20
> Receive buffer overflow error [  345.891126] eth1: Receive buffer=20
> overflow error [  346.074220] eth1: Receive buffer overflow error

Generally we only log real errors. Is a receive buffer overflow a real erro=
r? I would say not. But it would be good to count it.

There was also the open question, what exactly does a receive buffer overfl=
ow mean?

The spec says:

  9.2.8.11 RXBOE

  Receive Buffer Overflow Error. When set, this bit indicates that the
  receive buffer (from the network) has overflowed and receive frame
  data was lost.

Which is a bit ambiguous. I would hope it means the receiver has dropped th=
e packet. It will not be passed to the host. But other than maybe count it,=
 i don't think there is anything to do. But Ram=F3n was suggesting you actu=
ally drop the frame currently be transferred over the SPI bus?

	Andrew