Received-SPF: pass (google.com: domain of linux-kernel+bounces-189098-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Piergiorgio Beruto <Pier.Beruto@onsemi.com>
To: Andrew Lunn <andrew@lunn.ch>,
        =?iso-8859-1?Q?Ram=F3n_Nordin_Rodriguez?=
	<ramon.nordin.rodriguez@ferroamp.se>
CC: "Parthiban.Veerasooran@microchip.com"
	<Parthiban.Veerasooran@microchip.com>,
        "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: 
 AQHakZAC89gsXFcqv0WhzhAN3HgiZLF8la6AgAAX2YCAANNtAIAAVU8AgATxiYCAAQbggIAAAp2AgAFdb4CABFWKgIAAWgJwgAr/2oCAAGnoAIAADcgAgAD6kwCAAq/cgIACWJOAgAuQEwCAAAVJgIAAAGDQ
Date: Fri, 24 May 2024 18:49:12 +0000
Message-ID: 
 <BY5PR02MB6786D2055597B136585E90A29DF52@BY5PR02MB6786.namprd02.prod.outlook.com>
References: <ae801fb9-09e0-49a3-a928-8975fe25a893@microchip.com>
 <fd5d0d2a-7562-4fb1-b552-6a11d024da2f@lunn.ch>
 <BY5PR02MB678683EADBC47A29A4F545A59D1C2@BY5PR02MB6786.namprd02.prod.outlook.com>
 <ZkG2Kb_1YsD8T1BF@minibuilder> <708d29de-b54a-40a4-8879-67f6e246f851@lunn.ch>
 <ZkIakC6ixYpRMiUV@minibuilder>
 <6e4207cd-2bd5-4f5b-821f-bc87c1296367@microchip.com>
 <ZkUtx1Pj6alRhYd6@minibuilder>
 <e75d1bbe-0902-4ee9-8fe9-e3b7fc9bf3cb@microchip.com>
 <ZlDYqoMNkb-ZieSZ@minibuilder> <7aaff08b-a770-4d93-b691-e89b4c40625e@lunn.ch>
In-Reply-To: <7aaff08b-a770-4d93-b691-e89b4c40625e@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?ZWKd1/pMdyjqtBsDDBJkrpSPw+XmxKb72RyETbrxinabMaoDDhW68HpLR+?=
 =?iso-8859-1?Q?IMm2inkBk7j269q8DqwHV4Cnbz9ofdNvhoRjY5HocvTQLilOtbA9LvMYv6?=
 =?iso-8859-1?Q?vEiDMC7ToVYKdokXlDU6Z7zbpAW+hEKPUzIHzZVF8klGX2T303Lr7qUhUF?=
 =?iso-8859-1?Q?TFkjXvjnlXfdUYBp94EEwRe5zmK+FhndipyBypj5pEzCQm3hv6KJyfPBhE?=
 =?iso-8859-1?Q?OTvYntrdaTwCVop5hxaTvPNlew8uiRwwUQJbhq7vmOJnye9/PpyenPOkfs?=
 =?iso-8859-1?Q?SObhbASYcU6Det9lXyjmbmnZt5keTCrNN6sG0R+fbS2Gf4qXTMQEHJGx+2?=
 =?iso-8859-1?Q?9dMOKNafOqrBFgZktmOqhH/ZPRBZDgQwPAIIvuwYBDLz5NfSjmbMX91+iH?=
 =?iso-8859-1?Q?kkrT1W51Fv1h0chzQhscuHOBSxzrG9aDGu9HDZKCNiJpdBCrTHYo43QmjG?=
 =?iso-8859-1?Q?+fJbAXMYQgnd211YGEDivmFgIMhadQ2Yu0oAv6/H1WAkxHrkJts5r7x+tg?=
 =?iso-8859-1?Q?Rzp4/tZYAOlBpVQ2q0TdlbdBsFzBeBUJSIfyZ9VP+b22iu4/QnWOdG04fL?=
 =?iso-8859-1?Q?e33Wx6wFM6ueGN1o4A0Wvb960b7i76oCpuYTdzmj2AwN6i/FPPkqze3JUm?=
 =?iso-8859-1?Q?ux20sdW5+3kO0hdi8JTkG0XWbXtYlQBX5ZunR30qPo3d52BvIjDuejke+S?=
 =?iso-8859-1?Q?4DQhoWaOq0GYgiXpUC3KI+1jzK+Gimj6nZDNvod1EQbOThMVNwnc0dK1wg?=
 =?iso-8859-1?Q?icMXuGso25iQKzloOK6Tjaoc/wn+3bIse3G6dPOdFcMyPwAaenHiIhToSi?=
 =?iso-8859-1?Q?C4nP6Iuc47R6mstKV50SmwgYP1VBwJ0kxVbrS1ThVPuQ+gaGn1iZ4LDusc?=
 =?iso-8859-1?Q?mBXdkZb5h+zY8Rn2ioa/GmdH8q69+uhVVbGUb9YqsaYNp3v/Alvr8cfws6?=
 =?iso-8859-1?Q?OrUemsKqYQJjH4xzu9ysGikUfVOKY4iSZqXdQblqsMs4fKu4NNiMViuPi3?=
 =?iso-8859-1?Q?PtwAa+LHnsHwcaxcYx+y6CxwJKZhGyx/zwgSNCnwhEStysD0JmLVWKY+4u?=
 =?iso-8859-1?Q?Dr3WmA/gx1DrdOSU56fCienJwNyaU3V8JfRXw+rU4z2vmZiO9woFMBxd+C?=
 =?iso-8859-1?Q?xpcz++N0hTriE4GFP9h8Mmn0mbCW2l8HNvmMm3doGUM1ZRivwShgSW6Apw?=
 =?iso-8859-1?Q?pjC42dqYaIDbSdYujIBNeT1BQlhm+JkogzBjCNhWxvOFYPNtmTBf1wgQNi?=
 =?iso-8859-1?Q?j5czHNa30PmdEZ8Av7QCSjBdGYmWHalhdKqAIe6W0urHWJQ8nY26DgJ/oA?=
 =?iso-8859-1?Q?RUDQUCGXuljgudBLBtmb3MALessBNVcPEoHhEYu1dN3YM2Wx61hnGT6UXp?=
 =?iso-8859-1?Q?sbSiKW+2Ez92rHC7PpyCWk15/eqVNxY1WyQvT33jd7TvlNOphUFPiaxUGA?=
 =?iso-8859-1?Q?ywRzyOolcEpdIQP0b6zaHFXou+4lk8h3NveerDV8AKaJ9Nw6eBd1K5F68j?=
 =?iso-8859-1?Q?cMir89hhhJL1J2SSnNjr8nncATRe2N0aIJ/8jzqp3K4bR95yTfDHHICMB/?=
 =?iso-8859-1?Q?4+hbLgSpUMWqTQIEc3mvXaWE+IEVhFQf3t+44ByVscur7TyDY+DNmeTaXF?=
 =?iso-8859-1?Q?KiR3PAzh+QN5mujhB769yUf6JIEX7p2u7n?=
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: e7c49969-edae-4396-6752-08dc7c22340e
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2024 18:49:12.3781
 (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: WygkUoJqu0hSe0qr08HVv5QsymO3+/G8eAHKql+C5dYW0dSPxp2+7yBHMvACKdjT0mxXrbPl8Lgic4ZFKvvTvA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR02MB8833
X-Proofpoint-GUID: OGgDni1e6rR_JlUvl4TnHAvvoeyWsQlk
X-Proofpoint-ORIG-GUID: OGgDni1e6rR_JlUvl4TnHAvvoeyWsQlk
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16
 definitions=2024-05-24_06,2024-05-24_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 clxscore=1011
 impostorscore=0 malwarescore=0 spamscore=0 priorityscore=1501
 lowpriorityscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2405170001
 definitions=main-2405240133

Hi all,
Just my two cents here...

Collision detection is a fundamental building block of the CSMA/CD mechanis=
m.
The PHY detects physical collisions and reports them to the MAC via the COL=
 pin.
The MAC is supposed to perform the normal back-off operation: stop the curr=
ent transmission and re-transmit at a later time following the exponentiall=
y increasing random algorithm (See IEEE 802.3 Clause 4).
** Therefore, collision detect shall NOT be brought up to the user. In a MA=
CPHY system it is supposed to be handled entirely by the PHY. **

With the introduction of PLCA, the PHY may report also "logical collisions"=
 to the MAC.  These are not real collisions as they don't happen on the lin=
e. They are part of the normal PLCA back-pressuring mechanism that allows t=
he PHY to send a frame only during a specific transmit opportunity. So once=
 more, this kind of collision shall not be reported to the user, it is just=
 normal behavior.

However, physical collisions (i.e., collisions that really happens on the l=
ine) are NOT supposed to happen when PLCA is enabled and configured correct=
ly.
For this reason we have a standard IEEE register (PCS Diagnostic 2) which s=
till captures physical collisions (not logical ones). This register is supp=
osed to be used as a diagnostic information to let the user know that somet=
hing is misconfigured.
Now, some PHYs can be configured to provide IRQs when this kind of collisio=
n happens, indicating a configuration problem.

Additionally, many PHYs allows the user to completely switch off the PHY ph=
ysical collision detection when PLCA is enabled. This is also recommended b=
y the OPEN Alliance specifications, although no standard register was defin=
ed to achieve that (maybe we should add it to the standard...).

I'm not sure I followed all this discussion, I just hope this clarification=
 might help in finding a good solution.
In short:

- Collisions are NOT to be reported to Linux. The MAC/PHY shall handle thos=
e internally.
- Physical collisions are still counted into a diagnostic register (could b=
e good to add it to ethtool MAC statistics)
- Disabling collision detection is allowed only when PLCA is enabled, but i=
t is not a standard feature, although automotive specs recommends it.

Thanks,
Piergiorgio

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch>=20
Sent: 24 May, 2024 20:32
To: Ram=F3n Nordin Rodriguez <ramon.nordin.rodriguez@ferroamp.se>
Cc: Parthiban.Veerasooran@microchip.com; Piergiorgio Beruto <Pier.Beruto@on=
semi.com>; davem@davemloft.net; edumazet@google.com; kuba@kernel.org; paben=
i@redhat.com; horms@kernel.org; saeedm@nvidia.com; anthony.l.nguyen@intel.c=
om; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; corbet@lwn.net; l=
inux-doc@vger.kernel.org; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro=
org; conor+dt@kernel.org; devicetree@vger.kernel.org; Horatiu.Vultur@micro=
chip.com; ruanjinjie@huawei.com; Steen.Hegelund@microchip.com; vladimir.olt=
ean@nxp.com; UNGLinuxDriver@microchip.com; Thorsten.Kummermehr@microchip.co=
m; Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>; Nicolas.Ferre@micr=
ochip.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.

> After a considerable ammount of headscratching it seems that disabling=20
> collision detection on the macphy is the only way of getting it stable.
> When PLCA is enabled it's expected that CD causes problems, when=20
> running in CSMA/CD mode it was unexpected (for me at least).

Now we are back to, why is your system different? What is triggering a coll=
ision for you, but not Parthiban?

There is nothing in the standard about reporting a collision. So this is a =
Microchip extension? So the framework is not doing anything when it happens=
, which will explain why it becomes a storm.... Until we do have a mechanis=
m to handle vendor specific interrupts, the frame work should disable them =
all, to avoid this storm.

Does the datasheet document what to do on a collision? How are you supposed=
 to clear the condition?

       Andrew