netdev - Re: [EXT] 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: <20240207112231.2d555d3e@kmaincent-XPS-13-7390>
Date: Wed, 7 Feb 2024 11:22:31 +0100
From: Köry Maincent <kory.maincent@...tlin.com>
To: Elad Nachman <enachman@...vell.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Taras Chornyi
 <taras.chornyi@...ision.eu>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>, Miquel Raynal <miquel.raynal@...tlin.com>
Subject: Re: [EXT] Prestera driver fail to probe twice

On Tue, 6 Feb 2024 18:30:33 +0000
Elad Nachman <enachman@...vell.com> wrote:

> Sorry, that's not how this works.
> 
> The firmware CPU loader will only reload if the firmware crashed or exit.
> 
> Hence, insmod on the host side will fail, as the firmware side loader is not
> waiting For the host to send a new firmware, but first for the existing
> firmware to exit.

With the current implementation we can't rmmod/insmod the driver.
Also, in case of deferring probe the same problem appears and the driver will
never probe. I don't think this is a good behavior.

Isn't it possible to verify that the firmware has already been sent and is
working well at the probe time? Then we wouldn't try to flash it.

Or stop the firmware at remove time and in case of probe defer.

> By design, the way to load new firmware is by resetting both CPUs (this
> should be covered by CPLD).

Are you saying the only way to stop the firmware is to shutdown the CPU?
As ask above, can't we know if the firmware has already been load?

> Can you please explain:
> 
> 1. What kind of HW / board are you trying this on?
> 2. Who is the customer requesting  this?
> 3. What is the design purpose of this change?

I have no particular request for that.
I was debugging a PoE controller driver that the prestera was depending on, I
was playing with these in a module state to verify the kref free.

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