From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: linux-wireless@vger.kernel.org,
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
Avinash Patil <avinashp@quantenna.com>,
Sergei Maksimenko <smaksimenko@quantenna.com>
Subject: Re: [PATCH 4/6] qtnfmac: fix rmmod for missing firmware
Date: Thu, 8 Feb 2018 10:21:04 +0100 [thread overview]
Message-ID: <5A7C1680.8030000@broadcom.com> (raw)
In-Reply-To: <20180208090601.ornrxzwqy3rtt2ge@bars>
On 2/8/2018 10:06 AM, Sergey Matyukevich wrote:
> Hello Arend,
>
> Thanks for review.
>
>>> Check that firmware exists prior to starting firmware download.
>>
>> Why would you do that? It seems expensive given that you obtain the
>> firmware and discard it immediately just to check it exists. Especially,
>> given that such a call can take 60 seconds to complete depending on
>> kernel config.
>>
>> Apart from that see minor comment below although I would seriously
>> reconsider this patch altogether.
>
> The idea behind this approach is simple: to quit early and to avoid starting
> asynchronous card boot if no firmware file exists. However I didn't realize that
> such a long delay may occur. What makes me worried is that the worst case
> scenario may happen if firmware actually exists: we make two calls of
> request_firmware, each of them taking long time.
The delay I mentioned here is when using FW_LOADER_USER_HELPER_FALLBACK
option is selected and user-space is not handling the firmware request.
This may happen when the driver is built-in and the user-space
application is not yet started.
> I agree that it makes a lot of sense to reimplement this approach requesting
> firmware only once. Will do for v2.
Regards,
Arend
next prev parent reply other threads:[~2018-02-08 9:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-05 15:05 [PATCH 0/6] qtnfmac: qsr10g pcie backend updates Sergey Matyukevich
2018-02-05 15:05 ` [PATCH 1/6] qtnfmac: fix releasing Tx/Rx data buffers Sergey Matyukevich
2018-02-05 15:05 ` [PATCH 2/6] qtnfmac: enable reloading of qtnfmac kernel modules Sergey Matyukevich
2018-02-05 15:05 ` [PATCH 3/6] qtnfmac: fix rmmod for firmware version mismatch Sergey Matyukevich
2018-02-05 15:05 ` [PATCH 4/6] qtnfmac: fix rmmod for missing firmware Sergey Matyukevich
2018-02-06 11:18 ` Arend van Spriel
2018-02-08 9:06 ` Sergey Matyukevich
2018-02-08 9:21 ` Arend van Spriel [this message]
2018-02-05 15:05 ` [PATCH 5/6] qtnfmac: implement asynchronous firmware loading Sergey Matyukevich
2018-02-06 11:22 ` Arend van Spriel
2018-02-07 11:09 ` Sergei Maksimenko
2018-02-08 9:51 ` Arend van Spriel
2018-02-05 15:05 ` [PATCH 6/6] qtnfmac: enable networked standby mode on device inactivity Sergey Matyukevich
2018-02-27 14:28 ` [PATCH 0/6] qtnfmac: qsr10g pcie backend updates Kalle Valo
2018-02-27 14:37 ` Sergey Matyukevich
2018-02-27 16:11 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5A7C1680.8030000@broadcom.com \
--to=arend.vanspriel@broadcom.com \
--cc=avinashp@quantenna.com \
--cc=igor.mitsyanko.os@quantenna.com \
--cc=linux-wireless@vger.kernel.org \
--cc=smaksimenko@quantenna.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.