All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
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ł Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.

-- 
Kalle Valo

  reply	other threads:[~2017-02-21 11:46 UTC|newest]

Thread overview: 29+ 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  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 11:46           ` Kalle Valo
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  9:57         ` 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 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.