On 2/7/2018 12:09 PM, Sergei Maksimenko wrote:
Qsr10g devices support loading firmware not only from the host over PCIe
but also from on-board flash.
Firmware start-up sequence and the following handshake are common for
PCIe and flash boot modes. They take much more
time (about 10 seconds) than the firmware upload process.
To make flash mode startup also asynchronous we can't use the existing
API such as request_firmware_nowait() as there is
no firmware to upload, and have to explicitly run the needed functions
in a work queue.
In my opinion it is more neat to have one firmware load function invoked
in a work queue for both modes than using
request_firmware_nowait() for one mode only.
I was taught "neat" is not a real argument ;-) I agree that if you need
the worker for async flashing it makes sense to use that for async
firmware loading as well. Missed that reading the patch itself.
On 06.02.2018 14:22, Arend van Spriel wrote:
On 2/5/2018 4:05 PM, Sergey Matyukevich wrote:
From: Sergei Maksimenko <smaksime...@quantenna.com>
In pci probe() function start firmware loading, protocol handshake
and driver core initialization, and not wait for completion.
The moving of the debugfs stuff makes this a drag to review, but I get
the gist. The thing is that the firmware api already provides an
asynchronous api, ie. request_firmware_nowait(), so why not use that.
This email, including its contents and any attachment(s), may contain
confidential information of Quantenna Communications, Inc. and is solely
for the intended recipient(s). If you may have received this in error,
please contact the sender and permanently delete this email, its
contents and any attachment(s).