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: 
 <BN9PR18MB42519830967969DEA4E329EFDB462@BN9PR18MB4251.namprd18.prod.outlook.com>
Date: Tue, 6 Feb 2024 18:30:33 +0000
From: Elad Nachman <enachman@...vell.com>
To: Köry Maincent <kory.maincent@...tlin.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Taras Chornyi
	<taras.chornyi@...ision.eu>
CC: Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Miquel Raynal
	<miquel.raynal@...tlin.com>
Subject: RE: [EXT] Prestera driver fail to probe twice

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.

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

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?

Elad.

-----Original Message-----
From: Köry Maincent <kory.maincent@...tlin.com> 
Sent: Tuesday, February 6, 2024 5:54 PM
To: netdev@...r.kernel.org; Taras Chornyi <taras.chornyi@...ision.eu>
Cc: Thomas Petazzoni <thomas.petazzoni@...tlin.com>; Miquel Raynal <miquel.raynal@...tlin.com>
Subject: [EXT] Prestera driver fail to probe twice

External Email

----------------------------------------------------------------------
Hello,

It seems the prestera driver has never been tested as a module or in a probe defer case:

# insmod /mnt/prestera.ko
# insmod /mnt/prestera_pci.ko
[   87.927343] Prestera DX 0000:01:00.0: Loading mrvl/prestera/mvsw_prestera_fw-v4.1.img ...
[   87.935600] Prestera DX 0000:01:00.0: FW version '4.1.0'
[   91.556693] Prestera DX 0000:01:00.0: Prestera FW is ready
[   99.431226] Prestera DX 0000:01:00.0: using random base mac address
# rmmod /mnt/prestera_pci.ko
# insmod /mnt/prestera_pci.ko
[  122.938273] Prestera DX 0000:01:00.0: waiting for FW loader is timed out [  122.945163] prestera_pci_probe : 944, err -110 [  122.949704] Prestera DX: probe of 0000:01:00.0 failed with error -110

We have to find a way to detect if the firmware has already been flashed.
I am not familiar with this controller and don't have its datasheet.
Could someone handle it?

Thanks,
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=ttkSGM_1augs7U16EjsCCiDgsAPWM7GXv5u28w9zcStA49DC0bLarpXqDmoDngBu&s=9gSVvceZTEdo5VHefj6KdETqcGq-dFjEcSauSJ8OLi8&e= 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ