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: 
 <BN9PR18MB42510F2EA6F4091E5CA3B409DB452@BN9PR18MB4251.namprd18.prod.outlook.com>
Date: Wed, 7 Feb 2024 10:56:29 +0000
From: Elad Nachman <enachman@...vell.com>
To: Köry Maincent <kory.maincent@...tlin.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



> -----Original Message-----
> From: Köry Maincent <kory.maincent@...tlin.com>
> Sent: Wednesday, February 7, 2024 12:23 PM
> To: Elad Nachman <enachman@...vell.com>
> Cc: 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.

Everything is possible, but that is the way the firmware interface was initially designed.
Changing this will break compatibility with board already deployed in the field.

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

Yes, that is the current design.

> As ask above, can't we know if the firmware has already been load?

Once again, this will break compatibility with boards deployed on the field.

> 
> > 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__bootlin.com&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=eTeNTLEK5-
> TxXczjOcKPhANIFtlB9pP4lq9qhdlFrwQ&m=piWh4FT_ehOSBh66-
> WPooytouhKWszNmhcmZntCWpXSN-
> bUQK8Rts1fLTasbqFlu&s=F4Le7TOKKleZMOYJWQtVbUOZlXRh9TeK9JP_hLDDln
> c&e=