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

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

Hello, 

I am just coming back to this series of fixes.
Indeed the 30s in case of probe defer are hard to accept but if it solves the
issue for now shouldn't we merge it? Andrew, Jakub what do you think?

If not, we could at least merge patches 3 to 5 which are unrelated.

Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>

Regards,


On Wed, 27 Mar 2024 17:27:41 +0000
Elad Nachman <enachman@marvell.com> wrote:

> Hi Andrew,
> 
> We have made internal technical review of the issues you have raised (return
> version API, try to get version API before starting to initialize and load
> the firmware, clear configuration API) versus the delay saved (almost 30
> seconds minus several seconds to perform and complete the API calls) - around
> 20 seconds or so.
> 
> Existing customers we have talked to seem to be able to cope with the
> existing delay.
> 
> Unfortunately, the amount of coding and testing involved with saving these 20
> seconds or so is beyond our available development manpower at this specific
> point in time.
> 
> Unfortunately, we will have to defer making the development you have
> requested to a later period in time.
> 
> Elad.
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Sunday, March 24, 2024 5:25 PM
> > To: Elad Nachman <enachman@marvell.com>
> > Cc: Taras Chornyi <taras.chornyi@plvision.eu>; davem@davemloft.net;
> > edumazet@google.com; kuba@kernel.org; pabeni@redhat.com;
> > kory.maincent@bootlin.com; thomas.petazzoni@bootlin.com;
> > miquel.raynal@bootlin.com; przemyslaw.kitszel@intel.com;
> > dkirjanov@suse.de; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [EXTERNAL] Re: [PATCH v2 0/5] Fix prestera driver fail to probe
> > twice
> >   
>  [...]  
> > problem.  
>  [...]  
> > >
> > > 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://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__lore.kernel.org_netdev_20240208101005.29e8c7f3-40kmaincent-2DXPS-
> > 2D13-2D7390_T_-
> > 23mb898bb2a4bf07776d79f1a19b6a8420716ecb4a3&d=DwIDAw&c=nKjWec2
> > b6R0mOyPaz7xtfQ&r=eTeNTLEK5-
> > TxXczjOcKPhANIFtlB9pP4lq9qhdlFrwQ&m=SD1MhKC11sFmp4Q8l76N_DgGdac
> > 4aMCTdPsa7Pofb73HEqAGtJ-1p0-
> > etIyyldC7&s=VWat9LPub52H3nUez4itmkpuMipnYD3Ngn-paFC9wd4&e=
> > 
> > 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.
> >   
> > > The problem was caused because the module exit was lacking the so
> > > called "switch HW reset" API call which would cause the firmware to
> > > exit to the firmware loader on the firmware CPU, and move to the state
> > > in the state machine when it can receive new firmware from the host
> > > CPU (running the Prestera switchDev driver).
> > >  
>  [...]  
>  [...]  
>  [...]  
> > >
> > > There is no existing API/ABI for that.  
> > 
> > Do you at least have the ability to determine if an API call exists or not?
> > It sounds like your firmware needs extending to support returning the
> > version. If the API is missing, you know it is 4.1 or older. If it does
> > exist, it will return 4.2 or higher.
> >   
>  [...]  
> > >
> > > Exactly.
> > >  
>  [...]  
> > >
> > > Right. And there is also the configuration. There is no telling what
> > > kind of Configuration the existing firmware is running. Just using the
> > > existing firmware Will lead to the situation where Linux kernel side
> > > will report certain configuration (via ip link / ip addr / tc , etc.) but
> > > the  
> > firmware configuration is completely different.
> > 
> > Well, during probe and -EPRODE_DEFER, linux has no configuration, since the
> > driver failed to probe. However, for a rmmod/modprobe, the firmware could
> > have stale configuration. However pretty much every device i've come across
> > has the concept of a software reset which clears out the configuration.
> > Seems to be something else your firmware is missing.
> > 
> > 	Andrew  



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