Received-SPF: pass (google.com: domain of linux-kernel+bounces-117035-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Mon, 25 Mar 2024 13:45:37 +0100
From: Kory Maincent <kory.maincent@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Elad Nachman <enachman@marvell.com>, Taras Chornyi
 <taras.chornyi@plvision.eu>, "davem@davemloft.net" <davem@davemloft.net>,
 "edumazet@google.com" <edumazet@google.com>, "kuba@kernel.org"
 <kuba@kernel.org>, "pabeni@redhat.com" <pabeni@redhat.com>,
 "thomas.petazzoni@bootlin.com" <thomas.petazzoni@bootlin.com>,
 "miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
 "przemyslaw.kitszel@intel.com" <przemyslaw.kitszel@intel.com>,
 "dkirjanov@suse.de" <dkirjanov@suse.de>, "netdev@vger.kernel.org"
 <netdev@vger.kernel.org>, "linux-kernel@vger.kernel.org"
 <linux-kernel@vger.kernel.org>
Subject: Re: [EXTERNAL] Re: [PATCH v2 0/5] Fix prestera driver fail to probe
 twice
Message-ID: <20240325134537.1cc7560e@kmaincent-XPS-13-7390>
In-Reply-To: <6dae31dc-8c4f-4b8d-80e4-120619119326@lunn.ch>
References: <20240320172008.2989693-1-enachman@marvell.com>
	<4104387a-d7b5-4029-b822-060ef478c6e3@lunn.ch>
	<BN9PR18MB42517F8E84C8C18078E45C37DB322@BN9PR18MB4251.namprd18.prod.outlook.com>
	<89a01616-57c2-4338-b469-695bdc731dee@lunn.ch>
	<BL1PR18MB42488523A5E05291EA57D0AEDB372@BL1PR18MB4248.namprd18.prod.outlook.com>
	<6dae31dc-8c4f-4b8d-80e4-120619119326@lunn.ch>
Organization: bootlin
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 24 Mar 2024 16:25:28 +0100
Andrew Lunn <andrew@lunn.ch> wrote:

> > > > Originally, the pain point for Kory was the rmmod + insmod re-probi=
ng
> > > > failure, Which is only fixed by the first two commits, so I see lit=
tle
> > > > point in submitting 3-5 alone, Without fixing Kory's problem. =20
> > >=20
> > > I thought Kory's problem was actually EPROBE_DEFER? The resources nee=
ded
> > > for the PoE are not available, so probing the switch needs to happen =
again
> > > later, when PoE can get the resources it needs. =20
> >=20
> > No, the PoE is the general high level application where he noted the
> > problem. There is no PoE code nor special PoE resources in the Prestera
> > driver. =20
>=20
> So here is K=C3=B6ry email:
>=20
> https://lore.kernel.org/netdev/20240208101005.29e8c7f3@kmaincent-XPS-13-7=
390/T/#mb898bb2a4bf07776d79f1a19b6a8420716ecb4a3
>=20
> I don't see why the prestera needs to be involved in PoE itself. It is
> just a MAC. PoE happens much lower down in the network stack. Same as
> Prestera uses phylink, it does not need to know about the PHYs or the
> SFP modules, phylink manages them, not prestera.

Prestera is indeed not directly involved in PoE. I wrote a hack to be able =
to
get the PoE ports control, for testing my PoE patch series.

The aim in the future will be to add RJ45 port abstraction.
The Prestera will get the port abstraction which will get the PoE ports con=
trol.
The prestera driver then might receive an EPROBE_DEFER from it.

Regards,
--=20
K=C3=B6ry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com