* [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi @ 2018-10-03 7:15 Kai-Heng Feng 2018-10-03 7:24 ` Luciano Coelho 0 siblings, 1 reply; 15+ messages in thread From: Kai-Heng Feng @ 2018-10-03 7:15 UTC (permalink / raw) To: linux-kernel Cc: Kai-Heng Feng, Johannes Berg, Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless, Kalle Valo, David S. Miller, linux-wireless, netdev 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> --- .../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> #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. */ + 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); -- 2.17.1 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 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 8:58 ` Kalle Valo 0 siblings, 2 replies; 15+ messages in thread From: Luciano Coelho @ 2018-10-03 7:24 UTC (permalink / raw) To: Kai-Heng Feng, linux-kernel Cc: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless, Kalle Valo, David S. Miller, linux-wireless, netdev 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? > .../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. > #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... -- Cheers, Luca. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 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 8:58 ` Kalle Valo 1 sibling, 1 reply; 15+ messages in thread From: Kai Heng Feng @ 2018-10-03 7:27 UTC (permalink / raw) To: Luciano Coelho Cc: lkml, Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless, Kalle Valo, David S. Miller, linux-wireless, netdev > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 2018-10-03 7:27 ` Kai Heng Feng @ 2018-10-03 7:29 ` Matt Chen 2018-10-03 7:38 ` Kai Heng Feng 0 siblings, 1 reply; 15+ messages in thread From: Matt Chen @ 2018-10-03 7:29 UTC (permalink / raw) To: kai.heng.feng Cc: luciano.coelho, LKML, johannes.berg, Grumbach, Emmanuel, linuxwifi, Kalle Valo, David Miller, linux-wireless, netdev 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. 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. > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 2018-10-03 7:29 ` Matt Chen @ 2018-10-03 7:38 ` Kai Heng Feng 2018-10-03 18:25 ` Marcel Holtmann 0 siblings, 1 reply; 15+ messages in thread From: Kai Heng Feng @ 2018-10-03 7:38 UTC (permalink / raw) To: Matt Chen Cc: Luciano Coelho, LKML, johannes.berg, Grumbach, Emmanuel, linuxwifi, Kalle Valo, David Miller, linux-wireless, netdev > 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. >> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 2018-10-03 7:38 ` Kai Heng Feng @ 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 0 siblings, 2 replies; 15+ messages in thread From: Marcel Holtmann @ 2018-10-03 18:25 UTC (permalink / raw) To: Kai Heng Feng Cc: Matt Chen, Luciano Coelho, LKML, Johannes Berg, Grumbach, Emmanuel, linuxwifi, Kalle Valo, David S. Miller, linux-wireless, netdev Hi Kai-Heng, >> 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. which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon. So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders. Regards Marcel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 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 1 sibling, 0 replies; 15+ messages in thread From: Kai Heng Feng @ 2018-10-05 8:30 UTC (permalink / raw) To: Marcel Holtmann Cc: Matt Chen, Luciano Coelho, LKML, Johannes Berg, Grumbach, Emmanuel, linuxwifi, Kalle Valo, David S. Miller, linux-wireless, netdev Hi Marcel, > On Oct 4, 2018, at 2:25 AM, Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Kai-Heng, > >>> 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. > > which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon. Here’s the dmesg | grep Bluetooth: [ 6.086600] Bluetooth: Core ver 2.22 [ 6.086618] Bluetooth: HCI device and connection manager initialized [ 6.086621] Bluetooth: HCI socket layer initialized [ 6.086625] Bluetooth: L2CAP socket layer initialized [ 6.086632] Bluetooth: SCO socket layer initialized [ 6.107794] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014 [ 6.112803] Bluetooth: hci0: Device revision is 5 [ 6.112805] Bluetooth: hci0: Secure boot is enabled [ 6.112805] Bluetooth: hci0: OTP lock is enabled [ 6.112806] Bluetooth: hci0: API lock is enabled [ 6.112807] Bluetooth: hci0: Debug lock is disabled [ 6.112808] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [ 6.115231] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi [ 6.210353] Bluetooth: hci0: Failed to send firmware data (-38) [ 8.153357] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 8.153358] Bluetooth: BNEP filters: protocol multicast [ 8.153362] Bluetooth: BNEP socket layer initialized [ 13.563790] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014 [ 13.568806] Bluetooth: hci0: Device revision is 5 [ 13.568808] Bluetooth: hci0: Secure boot is enabled [ 13.568809] Bluetooth: hci0: OTP lock is enabled [ 13.568810] Bluetooth: hci0: API lock is enabled [ 13.568811] Bluetooth: hci0: Debug lock is disabled [ 13.568813] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [ 13.569072] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi [ 15.220327] Bluetooth: hci0: Waiting for firmware download to complete [ 15.220805] Bluetooth: hci0: Firmware loaded in 1618764 usecs [ 15.220877] Bluetooth: hci0: Waiting for device to boot [ 15.233031] Bluetooth: hci0: Device booted in 11881 usecs [ 15.233274] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc [ 15.236794] Bluetooth: hci0: Applying Intel DDC parameters completed [ 17.232497] Bluetooth: RFCOMM TTY layer initialized [ 17.232505] Bluetooth: RFCOMM socket layer initialized [ 17.232510] Bluetooth: RFCOMM ver 1.11 I’ll file a Bugzilla if we need full dmesg as attachment. > > So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders. Apology for the hammer approach, which is the best way I can think of. Of course it’s much better if we can solve this without the ugly hack. Kai-Heng > > Regards > > Marcel > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 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 1 sibling, 2 replies; 15+ messages in thread From: João Paulo Rechi Vita @ 2018-11-09 0:08 UTC (permalink / raw) To: Marcel Holtmann Cc: João Paulo Rechi Vita, Kai-Heng Feng, Luca Coelho, Kalle Valo, Emmanuel Grumbach, Johannes Berg, David S. Miller, Intel Linux Wireless, linux-wireless, netdev, linux-kernel, linux, João Paulo Rechi Vita Hello Marcel, > On Oct 4, 2018, at 2:25 AM, Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Kai-Heng, > >>> 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. > > which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon. > > So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders. > I have a Lenovo Yoga 900 which presents this problem and has the same bootloader / firmware information as Kai-Heng already posted: [ 5.992426] Bluetooth: Core ver 2.22 [ 5.992438] Bluetooth: HCI device and connection manager initialized [ 5.992442] Bluetooth: HCI socket layer initialized [ 5.992444] Bluetooth: L2CAP socket layer initialized [ 5.992450] Bluetooth: SCO socket layer initialized [ 6.004941] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014 [ 6.010922] Bluetooth: hci0: Device revision is 5 [ 6.010923] Bluetooth: hci0: Secure boot is enabled [ 6.010924] Bluetooth: hci0: OTP lock is enabled [ 6.010925] Bluetooth: hci0: API lock is enabled [ 6.010926] Bluetooth: hci0: Debug lock is disabled [ 6.010927] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [ 6.014253] bluetooth hci0: firmware: direct-loading firmware intel/ibt-11-5.sfi [ 6.014256] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi [ 6.613961] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 6.613966] Bluetooth: BNEP filters: protocol multicast [ 6.613974] Bluetooth: BNEP socket layer initialized [ 6.983804] Bluetooth: hci0: Failed to send firmware data (-38) And the following product id and revision, from usb-devices: T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0a2b Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I understand the drawbacks with the approach presented here and lack of clear explanation of the problem, but I can confirm these patches work around the problem on my machine. Is there any extra info or test result I can provide to help debug this? I can also dedicate time to help write a different solution if some guidance is provided. Kai-Heng, did you end up filling a Bugzilla entry for this? Please CC-me on the replies as I'm not receiving emails from linux-bluetooth or linux-wireless anymore. Thanks, -- João Paulo Rechi Vita http://about.me/jprvita ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 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 1 sibling, 0 replies; 15+ messages in thread From: João Paulo Rechi Vita @ 2018-11-09 0:11 UTC (permalink / raw) To: Marcel Holtmann Cc: kai.heng.feng, Luca Coelho, Kalle Valo, Emmanuel Grumbach, Johannes Berg, David S. Miller, Intel Linux Wireless, linux-wireless, Network Development, LKML, linux, João Paulo Rechi Vita, linux-bluetooth + linux-bluetooth On Thu, Nov 8, 2018 at 4:08 PM João Paulo Rechi Vita <jprvita@gmail.com> wrote: > > Hello Marcel, > > > On Oct 4, 2018, at 2:25 AM, Marcel Holtmann <marcel@holtmann.org> wrote: > > > > Hi Kai-Heng, > > > >>> 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. > > > > which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon. > > > > So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders. > > > > I have a Lenovo Yoga 900 which presents this problem and has the same bootloader / firmware information as Kai-Heng already posted: > > [ 5.992426] Bluetooth: Core ver 2.22 > [ 5.992438] Bluetooth: HCI device and connection manager initialized > [ 5.992442] Bluetooth: HCI socket layer initialized > [ 5.992444] Bluetooth: L2CAP socket layer initialized > [ 5.992450] Bluetooth: SCO socket layer initialized > [ 6.004941] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014 > [ 6.010922] Bluetooth: hci0: Device revision is 5 > [ 6.010923] Bluetooth: hci0: Secure boot is enabled > [ 6.010924] Bluetooth: hci0: OTP lock is enabled > [ 6.010925] Bluetooth: hci0: API lock is enabled > [ 6.010926] Bluetooth: hci0: Debug lock is disabled > [ 6.010927] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 > [ 6.014253] bluetooth hci0: firmware: direct-loading firmware intel/ibt-11-5.sfi > [ 6.014256] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi > [ 6.613961] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 > [ 6.613966] Bluetooth: BNEP filters: protocol multicast > [ 6.613974] Bluetooth: BNEP socket layer initialized > [ 6.983804] Bluetooth: hci0: Failed to send firmware data (-38) > > And the following product id and revision, from usb-devices: > > T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=8087 ProdID=0a2b Rev=00.01 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > > I understand the drawbacks with the approach presented here and lack of clear explanation of the problem, but I can confirm these patches work around the problem on my machine. Is there any extra info or test result I can provide to help debug this? I can also dedicate time to help write a different solution if some guidance is provided. > > Kai-Heng, did you end up filling a Bugzilla entry for this? > > Please CC-me on the replies as I'm not receiving emails from linux-bluetooth or linux-wireless anymore. > > Thanks, > > -- > João Paulo Rechi Vita > http://about.me/jprvita ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 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> 1 sibling, 1 reply; 15+ messages in thread From: Marcel Holtmann @ 2018-11-09 7:49 UTC (permalink / raw) To: João Paulo Rechi Vita Cc: Kai-Heng Feng, Luca Coelho, Kalle Valo, Emmanuel Grumbach, Johannes Berg, David S. Miller, Intel Linux Wireless, open list:NFC SUBSYSTEM, netdev, linux-kernel, linux, João Paulo Rechi Vita Hi Joao Paulo, >>>> 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. >> >> which SKUs are these actually. What are the initial details about the boot loader. For the Bluetooth side, you should be able to grab them from dmesg or by running btmon. >> >> So I am not in favor of this kind of hack and creating dependencies between drivers. If you only have a hammer, then everything looks like a nail. And this is a massive hammer trying to squash everything. This problem needs to be debugged. And this starts by providing affected SKU information and firmware information. So get the details about the SKU and its Bluetooth and WiFi boot loaders. >> > > I have a Lenovo Yoga 900 which presents this problem and has the same bootloader / firmware information as Kai-Heng already posted: > > [ 5.992426] Bluetooth: Core ver 2.22 > [ 5.992438] Bluetooth: HCI device and connection manager initialized > [ 5.992442] Bluetooth: HCI socket layer initialized > [ 5.992444] Bluetooth: L2CAP socket layer initialized > [ 5.992450] Bluetooth: SCO socket layer initialized > [ 6.004941] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014 > [ 6.010922] Bluetooth: hci0: Device revision is 5 > [ 6.010923] Bluetooth: hci0: Secure boot is enabled > [ 6.010924] Bluetooth: hci0: OTP lock is enabled > [ 6.010925] Bluetooth: hci0: API lock is enabled > [ 6.010926] Bluetooth: hci0: Debug lock is disabled > [ 6.010927] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 > [ 6.014253] bluetooth hci0: firmware: direct-loading firmware intel/ibt-11-5.sfi > [ 6.014256] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi > [ 6.613961] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 > [ 6.613966] Bluetooth: BNEP filters: protocol multicast > [ 6.613974] Bluetooth: BNEP socket layer initialized > [ 6.983804] Bluetooth: hci0: Failed to send firmware data (-38) > > And the following product id and revision, from usb-devices: > > T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=8087 ProdID=0a2b Rev=00.01 > C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb > > I understand the drawbacks with the approach presented here and lack of clear explanation of the problem, but I can confirm these patches work around the problem on my machine. Is there any extra info or test result I can provide to help debug this? I can also dedicate time to help write a different solution if some guidance is provided. > > Kai-Heng, did you end up filling a Bugzilla entry for this? > > Please CC-me on the replies as I'm not receiving emails from linux-bluetooth or linux-wireless anymore. our hardware teams from the Bluetooth and WiFi side really need to look at this. An inter-dependency between the firmware loading of two otherwise independent drivers is really not what I want to see upstream. However I have no idea which boot loaders are affected or if this is something that might be even possible to be fixed in operational firmware. If you can create a binary btmon trace file with the error happening and getting really every single message from the boot we might get a bit further to understand where it goes wrong. Regards Marcel ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <CA+A7VXXfdyLWMpNaEzUzDe6PiktOKb5oJrufYrGeTyXyXChQfw@mail.gmail.com>]
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi [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 0 siblings, 1 reply; 15+ messages in thread From: João Paulo Rechi Vita @ 2018-12-05 19:27 UTC (permalink / raw) To: Marcel Holtmann Cc: Kai-Heng Feng, Luca Coelho, Kalle Valo, Emmanuel Grumbach, Johannes Berg, David S. Miller, Intel Linux Wireless, linux-wireless, Network Development, LKML, Linux Upstreaming Team, João Paulo Rechi Vita Hello Marcel, On Fri, Nov 9, 2018 at 4:36 PM João Paulo Rechi Vita <jprvita@gmail.com> wrote: > > Hello Marcel, > > On Thu, Nov 8, 2018 at 11:49 PM Marcel Holtmann <marcel@holtmann.org> wrote: > > > > our hardware teams from the Bluetooth and WiFi side really need to look at this. Were you able to get attention from the hardware teams with the logs I've provided? Are there any news or an idea of when / if we can expect this to be fixed in firmware? If not, do you have suggestions for an alternative solution? Thanks, -- João Paulo Rechi Vita http://about.me/jprvita ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 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 0 siblings, 1 reply; 15+ messages in thread From: João Paulo Rechi Vita @ 2019-01-09 0:26 UTC (permalink / raw) To: Marcel Holtmann Cc: Kai-Heng Feng, Luca Coelho, Kalle Valo, Emmanuel Grumbach, Johannes Berg, David S. Miller, Intel Linux Wireless, linux-wireless, Network Development, LKML, Linux Upstreaming Team, João Paulo Rechi Vita Hello Marcel, On Wed, Dec 5, 2018 at 11:27 AM João Paulo Rechi Vita <jprvita@gmail.com> wrote: > > Hello Marcel, > > On Fri, Nov 9, 2018 at 4:36 PM João Paulo Rechi Vita <jprvita@gmail.com> wrote: > > > > Hello Marcel, > > > > On Thu, Nov 8, 2018 at 11:49 PM Marcel Holtmann <marcel@holtmann.org> wrote: > > > > > > our hardware teams from the Bluetooth and WiFi side really need to look at this. > > Were you able to get attention from the hardware teams with the logs > I've provided? Are there any news or an idea of when / if we can > expect this to be fixed in firmware? If not, do you have suggestions > for an alternative solution? > Sorry to bother you again with this, but I'd really like to figure out some way forward here. Did you get any feedback from the hardware teams? Otherwise, I understand having an inter-dependency between the wifi and bt kernel modules is not desirable, so do you have any suggestion on how to solve this without adding this dependency? -- João Paulo Rechi Vita http://about.me/jprvita ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 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 0 siblings, 1 reply; 15+ messages in thread From: Emmanuel Grumbach @ 2019-01-09 18:39 UTC (permalink / raw) To: João Paulo Rechi Vita Cc: Marcel Holtmann, Kai-Heng Feng, Luca Coelho, Kalle Valo, Emmanuel Grumbach, Johannes Berg, David S. Miller, Intel Linux Wireless, linux-wireless, Network Development, LKML, Linux Upstreaming Team, João Paulo Rechi Vita Hello, > > > > > > > > our hardware teams from the Bluetooth and WiFi side really need to look at this. > > > > Were you able to get attention from the hardware teams with the logs > > I've provided? Are there any news or an idea of when / if we can > > expect this to be fixed in firmware? If not, do you have suggestions > > for an alternative solution? > > > > Sorry to bother you again with this, but I'd really like to figure out > some way forward here. Did you get any feedback from the hardware > teams? Otherwise, I understand having an inter-dependency between the > wifi and bt kernel modules is not desirable, so do you have any > suggestion on how to solve this without adding this dependency? > Have you tried the update the BT firmware with what is now available in mainline linux-firmware.git? I heard that this problem has now been resolved. After you update the BT firmware, you need a full power cycle. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 2019-01-09 18:39 ` Emmanuel Grumbach @ 2019-01-10 1:29 ` João Paulo Rechi Vita 0 siblings, 0 replies; 15+ messages in thread From: João Paulo Rechi Vita @ 2019-01-10 1:29 UTC (permalink / raw) To: Emmanuel Grumbach Cc: Marcel Holtmann, Kai-Heng Feng, Luca Coelho, Kalle Valo, Emmanuel Grumbach, Johannes Berg, David S. Miller, Intel Linux Wireless, linux-wireless, Network Development, LKML, Linux Upstreaming Team, João Paulo Rechi Vita On Wed, Jan 9, 2019 at 10:39 AM Emmanuel Grumbach <egrumbach@gmail.com> wrote: > > Hello, > > > > > > > > > > > our hardware teams from the Bluetooth and WiFi side really need to look at this. > > > > > > Were you able to get attention from the hardware teams with the logs > > > I've provided? Are there any news or an idea of when / if we can > > > expect this to be fixed in firmware? If not, do you have suggestions > > > for an alternative solution? > > > > > > > Sorry to bother you again with this, but I'd really like to figure out > > some way forward here. Did you get any feedback from the hardware > > teams? Otherwise, I understand having an inter-dependency between the > > wifi and bt kernel modules is not desirable, so do you have any > > suggestion on how to solve this without adding this dependency? > > > > Have you tried the update the BT firmware with what is now available in > mainline linux-firmware.git? > I heard that this problem has now been resolved. After you update the > BT firmware, you need a full power cycle. Thanks for the reply. The latest firmware files I see upstream are from commit c34a52ab7d, which are the same I had tested with previously. I'm still able to hit the problem, but after the firmware failed to load the Bluetooth adapter got disconnected from the USB bus and then re-connected. Since the iwlwifi firmware loading routine had already finished at this point, the Bluetooth firmware loaded successfully. I had seen this behavior a few times in my previous test, but not always (for example that behavior did not trigger on the test I had previously shared logs for). So, maybe that is the fix that has been implemented in the firmware? And perhaps some other changes in the kernel where preventing that behavior from triggering all the time? I'm pasting logs bellow where both modules where blacklisted and manually loaded with "modprobe iwlwifi & modprobe btusb": Jan 09 16:54:24 endless kernel: Bluetooth: Core ver 2.22 Jan 09 16:54:24 endless kernel: NET: Registered protocol family 31 Jan 09 16:54:24 endless kernel: Bluetooth: HCI device and connection manager initialized Jan 09 16:54:24 endless kernel: Bluetooth: HCI socket layer initialized Jan 09 16:54:24 endless kernel: Bluetooth: L2CAP socket layer initialized Jan 09 16:54:24 endless kernel: Bluetooth: SCO socket layer initialized Jan 09 16:54:24 endless kernel: cfg80211: Loading compiled-in X.509 certificates for regulatory database Jan 09 16:54:24 endless kernel: cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' Jan 09 16:54:24 endless kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 Jan 09 16:54:24 endless kernel: cfg80211: failed to load regulatory.db Jan 09 16:54:24 endless kernel: usbcore: registered new interface driver btusb Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014 Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Device revision is 5 Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Secure boot is enabled Jan 09 16:54:24 endless kernel: Bluetooth: hci0: OTP lock is enabled Jan 09 16:54:24 endless kernel: Bluetooth: hci0: API lock is enabled Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Debug lock is disabled Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Minimum firmware build 1 week 10 2014 Jan 09 16:54:24 endless kernel: Intel(R) Wireless WiFi driver for Linux Jan 09 16:54:24 endless kernel: Copyright(c) 2003- 2015 Intel Corporation Jan 09 16:54:24 endless kernel: Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi Jan 09 16:54:25 endless kernel: iwlwifi 0000:01:00.0: loaded firmware version 36.7596afd4.0 op_mode iwlmvm Jan 09 16:54:25 endless kernel: iwlwifi 0000:01:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208 Jan 09 16:54:25 endless kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Jan 09 16:54:25 endless kernel: Bluetooth: BNEP filters: protocol multicast Jan 09 16:54:25 endless kernel: Bluetooth: BNEP socket layer initialized Jan 09 16:54:25 endless kernel: Bluetooth: hci0: Failed to send firmware data (-38) Jan 09 16:54:25 endless kernel: iwlwifi 0000:01:00.0: base HW address: a4:34:d9:81:bf:a5 Jan 09 16:54:25 endless kernel: ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' Jan 09 16:54:25 endless kernel: thermal thermal_zone6: failed to read out thermal zone (-61) Jan 09 16:54:25 endless kernel: iwlwifi 0000:01:00.0 wlp1s0: renamed from wlan0 Jan 09 16:54:25 endless kernel: IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready Jan 09 16:54:25 endless kernel: IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready Jan 09 16:54:25 endless kernel: IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready Jan 09 16:54:31 endless kernel: usb 1-7: USB disconnect, device number 3 Jan 09 16:54:32 endless kernel: usb 1-7: new full-speed USB device number 7 using xhci_hcd Jan 09 16:54:32 endless kernel: usb 1-7: New USB device found, idVendor=8087, idProduct=0a2b, bcdDevice= 0.01 Jan 09 16:54:32 endless kernel: usb 1-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014 Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Device revision is 5 Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Secure boot is enabled Jan 09 16:54:32 endless kernel: Bluetooth: hci0: OTP lock is enabled Jan 09 16:54:32 endless kernel: Bluetooth: hci0: API lock is enabled Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Debug lock is disabled Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Minimum firmware build 1 week 10 2014 Jan 09 16:54:32 endless kernel: Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Waiting for firmware download to complete Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Firmware loaded in 1820173 usecs Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Waiting for device to boot Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Device booted in 11761 usecs Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-11-5.ddc Jan 09 16:54:34 endless kernel: Bluetooth: hci0: Applying Intel DDC parameters completed Jan 09 16:54:34 endless kernel: Bluetooth: RFCOMM TTY layer initialized Jan 09 16:54:34 endless kernel: Bluetooth: RFCOMM socket layer initialized Jan 09 16:54:34 endless kernel: Bluetooth: RFCOMM ver 1.11 -- João Paulo Rechi Vita http://about.me/jprvita ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi 2018-10-03 7:24 ` Luciano Coelho 2018-10-03 7:27 ` Kai Heng Feng @ 2018-10-03 8:58 ` Kalle Valo 1 sibling, 0 replies; 15+ messages in thread From: Kalle Valo @ 2018-10-03 8:58 UTC (permalink / raw) To: Luciano Coelho Cc: Kai-Heng Feng, linux-kernel, Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless, David S. Miller, linux-wireless, netdev Luciano Coelho <luciano.coelho@intel.com> writes: >> +#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. This looks like an ugly hack and the commit log tells nothing. This really needs strong justifications to even consider doing something like this. -- Kalle Valo ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-01-10 1:29 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).