Received-SPF: pass (google.com: domain of linux-kernel+bounces-112726-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sun, 24 Mar 2024 16:25:28 +0100
From: Andrew Lunn <andrew@lunn.ch>
To: Elad Nachman <enachman@marvell.com>
Cc: 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>,
	"kory.maincent@bootlin.com" <kory.maincent@bootlin.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: <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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BL1PR18MB42488523A5E05291EA57D0AEDB372@BL1PR18MB4248.namprd18.prod.outlook.com>

> > > 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.

> 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).
> 
> > 
> > But if that is going to take 30 seconds, i'm not sure we can call EPROBE_DEFER
> > solved.
> > 
> > The later patches are pretty simple, don't need discussion, so could be
> > merged. However, i think we need to explore different possible solutions for
> > firmware {re}loading.
> > 
> > > The problem is not with the hardware, but with the existing firmware
> > > code on the Firmware cpu, most probably secure-boot protected, which
> > > lacks the ABIs to report to The kernel what is loaded, what version, what
> > state, etc.
> > 
> > Can you at least tell if it is running firmware?
> 
> 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.

> > Can you explain the boot in a bit more detail. Are you saying it could be
> > running an old firmware when the driver first loads? So you need to hit it with
> 
> Exactly.
> 
> > a reset in order to load the firmware for /lib/firmware, which might be newer
> > than what it is already running?
> 
> 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