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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ