Re: [EXTERNAL] Re: [PATCH v2 0/5] Fix prestera driver fail to probe twice

[Kory Maincent <kory.maincent@bootlin.com>]

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-probing
> > > > failure, Which is only fixed by the first two commits, so I see little
> > > > point in submitting 3-5 alone, Without fixing Kory's problem.  
> > > 
> > > I thought Kory's problem was actually EPROBE_DEFER? The resources needed
> > > for the PoE are not available, so probing the switch needs to happen again
> > > later, when PoE can get the resources it needs.  
> > 
> > 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.  
> 
> So here is Köry email:
> 
> https://lore.kernel.org/netdev/20240208101005.29e8c7f3@kmaincent-XPS-13-7390/T/#mb898bb2a4bf07776d79f1a19b6a8420716ecb4a3
> 
> 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 control.
The prestera driver then might receive an EPROBE_DEFER from it.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com