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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <89a01616-57c2-4338-b469-695bdc731dee@lunn.ch>
Date: Thu, 21 Mar 2024 20:22:05 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Elad Nachman <enachman@...vell.com>
Cc: Taras Chornyi <taras.chornyi@...ision.eu>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"kory.maincent@...tlin.com" <kory.maincent@...tlin.com>,
	"thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
	"miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
	"przemyslaw.kitszel@...el.com" <przemyslaw.kitszel@...el.com>,
	"dkirjanov@...e.de" <dkirjanov@...e.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [EXTERNAL] Re: [PATCH v2 0/5] Fix prestera driver fail to probe
 twice

> 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