From: Kalle Valo <kvalo@codeaurora.org>
To: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
"Ming Lei" <ming.lei@canonical.com>,
"Luis R . Rodriguez" <mcgrof@kernel.org>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V3 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds
Date: Tue, 21 Feb 2017 13:46:34 +0200 [thread overview]
Message-ID: <87vas3daw5.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <9ac0557a-2746-bc61-7397-a7fa58a02787@broadcom.com> (Arend Van Spriel's message of "Tue, 21 Feb 2017 10:57:07 +0100")
Arend Van Spriel <arend.vanspriel@broadcom.com> writes:
> On 21-2-2017 10:47, Rafa=C5=82 Mi=C5=82ecki wrote:
>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>=20
>> Failing to load NVRAM file isn't critical if we manage to get platform
>> one in the fallback path. It means warnings like:
>> [ 10.801506] brcmfmac 0000:01:00.0: Direct firmware load for
>> brcm/brcmfmac43602-pcie.txt failed with error -2
>> are unnecessary & disturbing for people with platform NVRAM. This is
>> very common case for Broadcom home routers.
>>=20
>> So instead of printing warning immediately with the firmware subsystem
>> let's first try our fallback code. If that fails as well, then it's a
>> right moment to print an error.
>>=20
>> This should reduce amount of false reports from users seeing this
>> warning while having wireless working perfectly fine.
>
> I think FW_OPT_NO_WARN does not cover all warnings in firmware_class
> although I did not check. Anyway...
>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Feel free to this via some another tree.
--=20
Kalle Valo
next prev parent reply other threads:[~2017-02-21 11:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 22:29 [PATCH 1/2] firmware: add more flexible request_firmware_async function Rafał Miłecki
2017-02-15 22:29 ` [PATCH 2/2] brcmfmac: don't warn user if loading firmware file with NVRAM fails Rafał Miłecki
2017-02-16 1:19 ` Andy Shevchenko
2017-02-16 7:25 ` Rafał Miłecki
2017-02-16 7:26 ` [PATCH V2 1/2] firmware: add more flexible request_firmware_async function Rafał Miłecki
2017-02-16 7:26 ` [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds Rafał Miłecki
2017-02-16 8:38 ` Arend Van Spriel
2017-02-16 9:04 ` Rafał Miłecki
2017-02-16 9:18 ` Arend Van Spriel
2017-02-16 9:32 ` Rafał Miłecki
2017-02-16 10:17 ` Arend Van Spriel
2017-02-21 9:47 ` [PATCH V3 1/2] firmware: add more flexible request_firmware_async function Rafał Miłecki
2017-02-21 9:47 ` [PATCH V3 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds Rafał Miłecki
2017-02-21 9:57 ` Arend Van Spriel
2017-02-21 11:46 ` Kalle Valo [this message]
2017-02-21 18:04 ` [PATCH V3 1/2] firmware: add more flexible request_firmware_async function Luis R. Rodriguez
2017-02-23 18:30 ` [PATCH V4 " Rafał Miłecki
2017-02-23 18:30 ` [PATCH V4 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds Rafał Miłecki
2017-03-16 9:57 ` [PATCH V4 1/2] firmware: add more flexible request_firmware_async function Rafał Miłecki
2017-03-16 13:31 ` Greg KH
2017-03-16 13:55 ` Rafał Miłecki
2017-03-16 14:03 ` Greg KH
2017-03-17 17:29 ` Luis R. Rodriguez
2017-03-27 19:28 ` Luis R. Rodriguez
2017-02-21 18:02 ` [PATCH V2 " Luis R. Rodriguez
2017-02-21 17:59 ` [PATCH " Luis R. Rodriguez
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=87vas3daw5.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@codeaurora.org \
--cc=arend.vanspriel@broadcom.com \
--cc=brcm80211-dev-list.pdl@broadcom.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=ming.lei@canonical.com \
--cc=rafal@milecki.pl \
--cc=zajec5@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).