Re: [PATCH 5/6] qtnfmac: implement asynchronous firmware loading

[Arend van Spriel]

On 2/7/2018 12:09 PM, Sergei Maksimenko wrote:

Hi Arend,

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.


Regards,
Arend


Regards,
Sergei

On 06.02.2018 14:22, Arend van Spriel wrote:


External Email


On 2/5/2018 4:05 PM, Sergey Matyukevich wrote:

From: Sergei Maksimenko 

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.

Regards,
Arend




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).

Re: [PATCH 5/6] qtnfmac: implement asynchronous firmware loading

[Sergei Maksimenko]

Hi Arend,

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.

Regards,
Sergei

On 06.02.2018 14:22, Arend van Spriel wrote:


External Email


On 2/5/2018 4:05 PM, Sergey Matyukevich wrote:

From: Sergei Maksimenko 

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.

Regards,
Arend




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).

Re: [PATCH 5/6] qtnfmac: implement asynchronous firmware loading

[Arend van Spriel]

On 2/5/2018 4:05 PM, Sergey Matyukevich wrote:

From: Sergei Maksimenko 

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.


Regards,
Arend