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: 
 <BN9PR18MB4251F1904C5C56381FE976C4DB452@BN9PR18MB4251.namprd18.prod.outlook.com>
Date: Wed, 7 Feb 2024 12:24:16 +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 1:29 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 Wed, 7 Feb 2024 10:56:29 +0000
> Elad Nachman <enachman@...vell.com> wrote:
> 
> > > -----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.
> 
> I don't understand, why fixing the probe by not flashing the firmware if it is
> already flashed, will break compatibility?
> Do I miss something?

First, firmware is loaded to RAM and not flashed.
Second, there is a certain control loop which dictates when the firmware loader expects new firmware by ABI, and that can only happen when the previous firmware code has terminated.

> 
> 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=T44g75Yk0UF0uqOlZrOea036_lOrf
> eH5g4oVTTZABDLVL9Yb06pSSH8oxsRgmt7g&s=L3_zgzJvce6HESMAg1UWPecI-
> Hqu9uOGd8N0AaZ1Jwg&e=