Received-SPF: pass (google.com: domain of linux-kernel+bounces-110584-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 21 Mar 2024 20:22:05 +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: <89a01616-57c2-4338-b469-695bdc731dee@lunn.ch>
References: <20240320172008.2989693-1-enachman@marvell.com>
 <4104387a-d7b5-4029-b822-060ef478c6e3@lunn.ch>
 <BN9PR18MB42517F8E84C8C18078E45C37DB322@BN9PR18MB4251.namprd18.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BN9PR18MB42517F8E84C8C18078E45C37DB322@BN9PR18MB4251.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.

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?

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 a reset in order to load the firmware for /lib/firmware,
which might be newer than what it is already running?

That would imply the device has FLASH and has a copy of firmware in
it? And if that is true, i think that also implies you have no way to
upgrade the image in FLASH? Otherwise you would implement "devlink
flash" to allow it to be upgraded. You then would not need to load the
firmware on driver probe....

	Andrew