linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kai Heng Feng <kai.heng.feng@canonical.com>
To: Matt Chen <mattsled@gmail.com>
Cc: Luciano Coelho <luciano.coelho@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	johannes.berg@intel.com, "Grumbach,
	Emmanuel" <emmanuel.grumbach@intel.com>,
	linuxwifi@intel.com, Kalle Valo <kvalo@codeaurora.org>,
	David Miller <davem@davemloft.net>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
Date: Wed, 3 Oct 2018 15:38:53 +0800	[thread overview]
Message-ID: <24BAAAAB-17E4-4820-A09A-50984B8EBA40@canonical.com> (raw)
In-Reply-To: <CALx5=V_0fyTcpTdYh=ZOLWL79cop1F=5GyMuK6S9QnP5qHKouQ@mail.gmail.com>



> On Oct 3, 2018, at 3:29 PM, Matt Chen <mattsled@gmail.com> wrote:
> 
> I think Canonical were facing some wifi fw load error from some 8260
> earlier module during the BT still loading the fw.
> I believe we had later 8260 sku that fixed this issue.

But there are already 8260 that is affected by this bug in the wild.

Search "Bluetooth: hci0: Failed to send firmware data (-38)” and there are lots of user are affected.

Kai-Heng

> 
> Hi Kai-Heng,
> 
> Can you check with OEM for which SKU they are reporting the issue ?
> Kai Heng Feng <kai.heng.feng@canonical.com> 於 2018年10月3日 週三 下午3:28寫道:
>> 
>> 
>> 
>>> On Oct 3, 2018, at 3:24 PM, Luciano Coelho <luciano.coelho@intel.com> wrote:
>>> 
>>> On Wed, 2018-10-03 at 15:15 +0800, Kai-Heng Feng wrote:
>>>> To avoid the firmware loading race between Bluetooth and WiFi on Intel
>>>> 8260, load firmware exclusively when BT_INTEL is enabled.
>>>> 
>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>>> ---
>>> 
>>> Where is this coming from? Can you explain what "the firmware loading
>>> race" is?
>> 
>> Looks like the patch is not correctly threaded. I’ll resend the series.
>> 
>>> 
>>> 
>>>> .../net/wireless/intel/iwlwifi/pcie/trans.c   | 37 ++++++++++++++++++-
>>>> 1 file changed, 36 insertions(+), 1 deletion(-)
>>>> 
>>>> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>>>> index cc8c53dc0ab6..c30d3989e2a8 100644
>>>> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>>>> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
>>>> @@ -71,6 +71,7 @@
>>>> #include <linux/vmalloc.h>
>>>> #include <linux/pm_runtime.h>
>>>> #include <linux/module.h>
>>>> +#include <linux/intel-wifi-bt.h>
>>> 
>>> I don't see this upstream.  Is it something that was recently added?
>>> Looks odd...
>>> 
>>> Regardless, this should also be protected on CONFIG_BT_INTEL.
>> 
>> Thanks, I’ll update this one.
>> 
>>> 
>>> 
>>>> #include "iwl-drv.h"
>>>> #include "iwl-trans.h"
>>>> @@ -1335,6 +1336,10 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>>>>     bool hw_rfkill;
>>>>     int ret;
>>>> 
>>>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>>>> +    void (*firmware_lock_func)(void);
>>>> +    void (*firmware_unlock_func)(void);
>>>> +#endif
>>>>     /* This may fail if AMT took ownership of the device */
>>>>     if (iwl_pcie_prepare_card_hw(trans)) {
>>>>             IWL_WARN(trans, "Exit HW not ready\n");
>>>> @@ -1394,6 +1399,7 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>>>>      * RF-Kill switch is toggled, we will find out after having loaded
>>>>      * the firmware and return the proper value to the caller.
>>>>      */
>>>> +
>>> 
>>> Stray empty line.
>>> 
>>>>     iwl_enable_fw_load_int(trans);
>>>> 
>>>>     /* really make sure rfkill handshake bits are cleared */
>>>> @@ -1401,8 +1407,37 @@ static int iwl_trans_pcie_start_fw(struct iwl_trans *trans,
>>>>     iwl_write32(trans, CSR_UCODE_DRV_GP1_CLR, CSR_UCODE_SW_BIT_RFKILL);
>>>> 
>>>>     /* Load the given image to the HW */
>>>> -    if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000)
>>>> +    if (trans->cfg->device_family >= IWL_DEVICE_FAMILY_8000) {
>>>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>>>> +            firmware_lock_func = symbol_request(btintel_firmware_lock);
>>>> +            firmware_unlock_func = symbol_request(btintel_firmware_unlock);
>>>> +            if (!firmware_lock_func || !firmware_unlock_func) {
>>>> +                    if (firmware_lock_func) {
>>>> +                            symbol_put(btintel_firmware_lock);
>>>> +                            firmware_lock_func = NULL;
>>>> +                    }
>>>> +
>>>> +                    if (firmware_unlock_func) {
>>>> +                            symbol_put(btintel_firmware_unlock);
>>>> +                            firmware_unlock_func = NULL;
>>>> +                    }
>>>> +            }
>>>> +
>>>> +            if (firmware_lock_func)
>>>> +                    firmware_lock_func();
>>>> +#endif
>>>>             ret = iwl_pcie_load_given_ucode_8000(trans, fw);
>>>> +
>>>> +#if IS_ENABLED(CONFIG_BT_INTEL)
>>>> +            if (firmware_unlock_func) {
>>>> +                    firmware_unlock_func();
>>>> +                    symbol_put(btintel_firmware_lock);
>>>> +                    firmware_lock_func = NULL;
>>>> +                    symbol_put(btintel_firmware_unlock);
>>>> +                    firmware_unlock_func = NULL;
>>>> +            }
>>>> +#endif
>>>> +    }
>>>>     else
>>>>             ret = iwl_pcie_load_given_ucode(trans, fw);
>>>> 
>>> 
>>> I'm not sure I like adding this BT-specific stuff here, especially not
>>> without a detailed explanation.
>>> 
>>> Did you also send the other patches in this series to linux-wireless? I
>>> can't see them…
>> 
>> I’ll resend one soon.
>> 
>> Thanks!
>> 
>> Kai-Heng
>> 
>>> 
>>> --
>>> Cheers,
>>> Luca.
>> 


  reply	other threads:[~2018-10-03  7:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03  7:15 [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi Kai-Heng Feng
2018-10-03  7:24 ` Luciano Coelho
2018-10-03  7:27   ` Kai Heng Feng
2018-10-03  7:29     ` Matt Chen
2018-10-03  7:38       ` Kai Heng Feng [this message]
2018-10-03 18:25         ` Marcel Holtmann
2018-10-05  8:30           ` Kai Heng Feng
2018-11-09  0:08           ` João Paulo Rechi Vita
2018-11-09  0:11             ` João Paulo Rechi Vita
2018-11-09  7:49             ` Marcel Holtmann
     [not found]               ` <CA+A7VXXfdyLWMpNaEzUzDe6PiktOKb5oJrufYrGeTyXyXChQfw@mail.gmail.com>
2018-12-05 19:27                 ` João Paulo Rechi Vita
2019-01-09  0:26                   ` João Paulo Rechi Vita
2019-01-09 18:39                     ` Emmanuel Grumbach
2019-01-10  1:29                       ` João Paulo Rechi Vita
2018-10-03  8:58   ` 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=24BAAAAB-17E4-4820-A09A-50984B8EBA40@canonical.com \
    --to=kai.heng.feng@canonical.com \
    --cc=davem@davemloft.net \
    --cc=emmanuel.grumbach@intel.com \
    --cc=johannes.berg@intel.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linuxwifi@intel.com \
    --cc=luciano.coelho@intel.com \
    --cc=mattsled@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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).