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

[Arend van Spriel <arend.vanspriel@broadcom.com>]

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