buona giornata.

[hi]

come stai
si tratta di un negozio di elettronica
moto, chitarra, fotocamera, tv, ipad, orologio  consegna gratuita
www.  slooone .com

Re: [RESEND] Re: updating carl9170-1.fw in linux-firmware.git

[Lauri Kasanen]

On Tue, 03 May 2016 15:09:39 +0200
Christian Lamparter  wrote:

> On Thursday, April 21, 2016 03:22:15 PM Kalle Valo wrote:
> > Christian Lamparter  writes:
> > 
> > > Maintainers. So for those people reading the fw list:
> > >
> > > What would it take to update the carl9170-1.fw firmware file in your
> > > repository to the latest version?
> > 
> > Thanks for following up on this. It would be good to solve this finally.
> Well, this was almost two weeks and no update yet.
> Kalle, can you please apply the "[PATCH v2] carl9170: Clarify kconfig text"
> patch from "Lauri Kasanen " [0].
> 
> [0] 

Seems we missed 4.7?

- Lauri
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] brcm80211: simplify assignment

[Arend Van Spriel]

On 18-5-2016 2:57, Heinrich Schuchardt wrote:
> Simplify assignment in wlc_phy_rxcal_gainctrl_nphy_rev5.

Acked-by: Arend van Spriel 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
> index 99dac9b..b3aab2f 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
> @@ -27017,7 +27017,7 @@ wlc_phy_rxcal_gainctrl_nphy_rev5(struct brcms_phy 
> *pi, u8 rx_core,
>   tx_core = 1 - rx_core;
>  
>   num_samps = 1024;
> - desired_log2_pwr = (cal_type == 0) ? 13 : 13;
> + desired_log2_pwr = 13;
>  
>   wlc_phy_rx_iq_coeffs_nphy(pi, 0, &save_comp);
>   zero_comp.a0 = zero_comp.b0 = zero_comp.a1 = zero_comp.b1 = 0x0;
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wifi driver crashes openwrt device

[Sven Eckelmann]

On Monday 16 May 2016 14:46:07 Kalle Valo wrote:
[...]
> Didn't openwrt have a some sort ramoops facility to collect the last
> kernel logs before a crash? I don't recall the name right now but I'm
> pretty sure I used it with one of our APs few years back. That might
> help (or not).

He can just check if /sys/kernel/debug/crashlog exists after the device
crashed+rebooted.

I would also be good to have CONFIG_KERNEL_KALLSYMS=y set and compile the
kernel+modules with "KBUILD_CFLAGS  += -fno-optimize-sibling-calls" to get
a (slightly) readable calltrace on things like MIPS.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: next wireless workshop - poll

[Johannes Berg]

On Thu, 2016-04-28 at 15:26 +0200, Johannes Berg wrote:
> Hi,
> 
> Since I've been getting questions about the next possible workshop
> and
> its organisation, I decided to make a poll about it:
> 
> http://goo.gl/forms/iMcE8b4TYU
> 
> Please reply by
> 
>   May 16th
> 
> so I can aggregate/evaluate the responses and we can make a decision.
> 

I didn't get many responses, but only a single one preferring *only*
Tokyo, with a few others preferring Santa Fe.

So I'll look into the latter.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

[Coelho, Luciano]

Hi Emmanuel, Linus,


On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
> On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
>  wrote:
> > 
> > On Tue, May 17, 2016 at 12:11 PM, David Miller  > > wrote:
> > > 
> > > 
> > > Highlights:
> > Lowlights:
> > 
> >  1) the iwlwifi driver seems to be broken
> > 
> > My laptop that uses the intel 7680 iwlwifi module no longer
> > connects
> > to the network. It fails with a "Microcode SW error detected." and
> > spews out register state over and over again.
> Can we have the register state and the ASSERT / NMI / whatever that
> goes along with it?
> This clearly means that the firmware is crashing, but I don't know
> why,
> I copied here the lines that I need from another bug with another
> device with another firmware,
> but the log that we will still explain what I need:

I managed to reproduce this bug locally with Linus' master.  I'm
investigating the cause and I'll let you how it goes.

--
Cheers,
Luca.

[PATCH] iw: Change socket configuration to avoid buffer allocation error

[Tribush, Gil]

Move  nl_socket_set_buffer_size() to be called after genl_connect(),
otherwise nl_socket_set_buffer_size() always returns an NLE_BAD_SOCK
error because sk->s_fd is equal to -1 at that stage.

Signed-off-by: Gil Treibush 
---
iw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)


diff --git a/iw.c b/iw.c
index 0f511d9..e3742cd 100644
--- a/iw.c
+++ b/iw.c
@@ -54,14 +54,14 @@ static int nl80211_init(struct nl80211_state *state)
return -ENOMEM;
}
 
-   nl_socket_set_buffer_size(state->nl_sock, 8192, 8192);
-
if (genl_connect(state->nl_sock)) {
fprintf(stderr, "Failed to connect to generic netlink.\n");
err = -ENOLINK;
goto out_handle_destroy;
}
 
+   nl_socket_set_buffer_size(state->nl_sock, 8192, 8192);
+
state->nl80211_id = genl_ctrl_resolve(state->nl_sock, "nl80211");
if (state->nl80211_id < 0) {
fprintf(stderr, "nl80211 not found.\n");
--
1.9.1
-
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] rtlwifi: rtl8192ee: simplify coding

[Larry Finger]

On 05/17/2016 07:43 PM, Heinrich Schuchardt wrote:

Simplify _rtl92ee_phy_path_adda_on.

Signed-off-by: Heinrich Schuchardt 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 13 ++---
  1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
index 018340a..c2bf8d1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/phy.c
@@ -2414,19 +2414,10 @@ static void _rtl92ee_phy_reload_mac_registers(struct 
ieee80211_hw *hw,
  static void _rtl92ee_phy_path_adda_on(struct ieee80211_hw *hw, u32 *addareg,
  bool is_patha_on, bool is2t)
  {
-   u32 pathon;
u32 i;

-   pathon = is_patha_on ? 0x0fc01616 : 0x0fc01616;
-   if (!is2t) {
-   pathon = 0x0fc01616;
-   rtl_set_bbreg(hw, addareg[0], MASKDWORD, 0x0fc01616);
-   } else {
-   rtl_set_bbreg(hw, addareg[0], MASKDWORD, pathon);
-   }
-
-   for (i = 1; i < IQK_ADDA_REG_NUM; i++)
-   rtl_set_bbreg(hw, addareg[i], MASKDWORD, pathon);
+   for (i = 0; i < IQK_ADDA_REG_NUM; i++)
+   rtl_set_bbreg(hw, addareg[i], MASKDWORD, 0x0fc01616);
  }

  static void _rtl92ee_phy_mac_setting_calibration(struct ieee80211_hw *hw,


Initially the thought was that addareg[0] would need to be set differently for 
devices with 2 TX paths. For that reason, this routine was coded as shown. As 
that assumption is no longer valid, this change should be made.


Acked-by: Larry Finger 

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] rtlwifi: rtl8723be: avoid undefined behavior

[Larry Finger]

On 05/17/2016 05:46 PM, Heinrich Schuchardt wrote:

Do not return undefined value for transmission power
if the rate is invalid.

Signed-off-by: Heinrich Schuchardt 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c
index 445f681..c5ca9df 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c
@@ -1019,7 +1019,7 @@ static u8 _rtl8723be_get_txpower_index(struct 
ieee80211_hw *hw, u8 path,
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
u8 index = (channel - 1);
-   u8 txpower;
+   u8 txpower = 0;
u8 power_diff_byrate = 0;

if (channel > 14 || channel < 1) {


Did gcc give you a warning about this variable not being initialized? Mine does 
not. In any case, this change is appropriate.


Acked-by: Larry Finger 

Thanks,

Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

[Reinoud Koornstra]

On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
 wrote:
> Hi Emmanuel, Linus,
>
>
> On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
>> On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
>>  wrote:
>> >
>> > On Tue, May 17, 2016 at 12:11 PM, David Miller > > > wrote:
>> > >
>> > >
>> > > Highlights:
>> > Lowlights:
>> >
>> >  1) the iwlwifi driver seems to be broken
>> >
>> > My laptop that uses the intel 7680 iwlwifi module no longer
>> > connects
>> > to the network. It fails with a "Microcode SW error detected." and
>> > spews out register state over and over again.
>> Can we have the register state and the ASSERT / NMI / whatever that
>> goes along with it?
>> This clearly means that the firmware is crashing, but I don't know
>> why,
>> I copied here the lines that I need from another bug with another
>> device with another firmware,
>> but the log that we will still explain what I need:
>
> I managed to reproduce this bug locally with Linus' master.  I'm
> investigating the cause and I'll let you how it goes.

I did run the latest git code as well 4.6+
iwlwifi went pearshape in my case as well.
I just updated the microcode as well, it didn't matter.
4.6-rc7 works fine and no errors are reported with iwlwifi.

Here's output that might come in handy

[   17.436340] iwlwifi :04:00.0: loaded firmware version
16.242414.0 op_mode iwlmvm
[   17.714920] iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144

SNIP
[  114.837923] wlp4s0: authenticate with 00:30:44:1d:cf:2b
[  114.841365] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
[  114.842073] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 2/3)
[  115.041992] iwlwifi :04:00.0: Microcode SW error detected.
Restarting 0x200.
[  115.041995] iwlwifi :04:00.0: CSR values:
[  115.041996] iwlwifi :04:00.0: (2nd byte of CSR_INT_COALESCING
is CSR_INT_PERIODIC_REG)
[  115.042000] iwlwifi :04:00.0:CSR_HW_IF_CONFIG_REG: 0X40489204
[  115.042003] iwlwifi :04:00.0:  CSR_INT_COALESCING: 0X8040
[  115.042006] iwlwifi :04:00.0: CSR_INT: 0X
[  115.042009] iwlwifi :04:00.0:CSR_INT_MASK: 0X
[  115.042013] iwlwifi :04:00.0:   CSR_FH_INT_STATUS: 0X
[  115.042016] iwlwifi :04:00.0: CSR_GPIO_IN: 0X
[  115.042019] iwlwifi :04:00.0:   CSR_RESET: 0X
[  115.042022] iwlwifi :04:00.0:CSR_GP_CNTRL: 0X080403c5
[  115.042026] iwlwifi :04:00.0:  CSR_HW_REV: 0X0144
[  115.042029] iwlwifi :04:00.0:  CSR_EEPROM_REG: 0X
[  115.042032] iwlwifi :04:00.0:   CSR_EEPROM_GP: 0X8000
[  115.042035] iwlwifi :04:00.0:  CSR_OTP_GP_REG: 0X803a
[  115.042038] iwlwifi :04:00.0: CSR_GIO_REG: 0X001f0044
[  115.042042] iwlwifi :04:00.0:CSR_GP_UCODE_REG: 0X
[  115.042045] iwlwifi :04:00.0:   CSR_GP_DRIVER_REG: 0X
[  115.042048] iwlwifi :04:00.0:   CSR_UCODE_DRV_GP1: 0X
[  115.042051] iwlwifi :04:00.0:   CSR_UCODE_DRV_GP2: 0X
[  115.042054] iwlwifi :04:00.0: CSR_LED_REG: 0X0060
[  115.042058] iwlwifi :04:00.0:CSR_DRAM_INT_TBL_REG: 0X88035a74
[  115.042061] iwlwifi :04:00.0:CSR_GIO_CHICKEN_BITS: 0X27800200
[  115.042064] iwlwifi :04:00.0: CSR_ANA_PLL_CFG: 0Xd5d5
[  115.042067] iwlwifi :04:00.0:  CSR_MONITOR_STATUS_REG: 0X3d0801bd
[  115.042070] iwlwifi :04:00.0:   CSR_HW_REV_WA_REG: 0X0001001a
[  115.042074] iwlwifi :04:00.0:CSR_DBG_HPET_MEM_REG: 0X
[  115.042075] iwlwifi :04:00.0: FH register values:
[  115.042086] iwlwifi :04:00.0:
FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X455fd200
[  115.042097] iwlwifi :04:00.0:
FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X04556370
[  115.042108] iwlwifi :04:00.0:
FH_RSCSR_CHNL0_WPTR: 0X0078
[  115.042119] iwlwifi :04:00.0:
FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X00801114
[  115.042129] iwlwifi :04:00.0:
FH_MEM_RSSR_SHARED_CTRL_REG: 0X00fc
[  115.042140] iwlwifi :04:00.0:
FH_MEM_RSSR_RX_STATUS_REG: 0X0303
[  115.042151] iwlwifi :04:00.0:
FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X
[  115.042162] iwlwifi :04:00.0:
FH_TSSR_TX_STATUS_REG: 0X07ff0001
[  115.042173] iwlwifi :04:00.0:
FH_TSSR_TX_ERROR_REG: 0X
[  115.042278] iwlwifi :04:00.0: Start IWL Error Log Dump:
[  115.042279] iwlwifi :04:00.0: Status: 0x, count: 6
[  115.042280] iwlwifi :04:00.0: Loaded firmware version: 16.242414.0
[  115.042281] iwlwifi :04:00.0: 0x0034 | NMI_INTERRUPT_WDG
[  115.042282] iwlwifi :04:00.0: 0x059002A0 | trm_hw_status0
[  115.042283] iwlwifi :04:00.0: 0x | trm_hw_status1
[  115.042284] iwlwifi :04:00.0: 0x0B2C | branchlink2
[  115.042285] iwlwifi :04:00.0: 0x00016A90 | interruptlink

Re: [GIT] Networking

[Coelho, Luciano]

On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
> On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
>  wrote:
> > 
> > Hi Emmanuel, Linus,
> > 
> > 
> > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
> > > 
> > > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
> > >  wrote:
> > > > 
> > > > 
> > > > On Tue, May 17, 2016 at 12:11 PM, David Miller  > > > .net
> > > > > 
> > > > > wrote:
> > > > > 
> > > > > 
> > > > > Highlights:
> > > > Lowlights:
> > > > 
> > > >  1) the iwlwifi driver seems to be broken
> > > > 
> > > > My laptop that uses the intel 7680 iwlwifi module no longer
> > > > connects
> > > > to the network. It fails with a "Microcode SW error detected."
> > > > and
> > > > spews out register state over and over again.
> > > Can we have the register state and the ASSERT / NMI / whatever
> > > that
> > > goes along with it?
> > > This clearly means that the firmware is crashing, but I don't
> > > know
> > > why,
> > > I copied here the lines that I need from another bug with another
> > > device with another firmware,
> > > but the log that we will still explain what I need:
> > I managed to reproduce this bug locally with Linus' master.  I'm
> > investigating the cause and I'll let you how it goes.
> I did run the latest git code as well 4.6+
> iwlwifi went pearshape in my case as well.
> I just updated the microcode as well, it didn't matter.
> 4.6-rc7 works fine and no errors are reported with iwlwifi.
> 
> Here's output that might come in handy

Thanks! That is helpful.

Since you say that 4.6-rc7 works but 4.6 doesn't, the prime suspect is
commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the
AMSDU len"), which is the only iwlwifi patch between those two
releases.

Could you try to revert that and see if the error is gone?

--
Cheers,
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [GIT] Networking

[Reinoud Koornstra]

On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano
 wrote:
> On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
>> On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
>>  wrote:
>> >
>> > Hi Emmanuel, Linus,
>> >
>> >
>> > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
>> > >
>> > > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
>> > >  wrote:
>> > > >
>> > > >
>> > > > On Tue, May 17, 2016 at 12:11 PM, David Miller > > > > .net
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > >
>> > > > > Highlights:
>> > > > Lowlights:
>> > > >
>> > > >  1) the iwlwifi driver seems to be broken
>> > > >
>> > > > My laptop that uses the intel 7680 iwlwifi module no longer
>> > > > connects
>> > > > to the network. It fails with a "Microcode SW error detected."
>> > > > and
>> > > > spews out register state over and over again.
>> > > Can we have the register state and the ASSERT / NMI / whatever
>> > > that
>> > > goes along with it?
>> > > This clearly means that the firmware is crashing, but I don't
>> > > know
>> > > why,
>> > > I copied here the lines that I need from another bug with another
>> > > device with another firmware,
>> > > but the log that we will still explain what I need:
>> > I managed to reproduce this bug locally with Linus' master.  I'm
>> > investigating the cause and I'll let you how it goes.
>> I did run the latest git code as well 4.6+
>> iwlwifi went pearshape in my case as well.
>> I just updated the microcode as well, it didn't matter.
>> 4.6-rc7 works fine and no errors are reported with iwlwifi.
>>
>> Here's output that might come in handy
>
> Thanks! That is helpful.
>
> Since you say that 4.6-rc7 works but 4.6 doesn't, the prime suspect is
> commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the
> AMSDU len"), which is the only iwlwifi patch between those two
> releases.
>
> Could you try to revert that and see if the error is gone?

Will do, since git revert failed I'll revert manually and report back.

>
> --
> Cheers,
> Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: next wireless workshop - poll

[Jes Sorensen]

Johannes Berg  writes:
> On Thu, 2016-04-28 at 15:26 +0200, Johannes Berg wrote:
>> Hi,
>> 
>> Since I've been getting questions about the next possible workshop
>> and
>> its organisation, I decided to make a poll about it:
>> 
>> http://goo.gl/forms/iMcE8b4TYU
>> 
>> Please reply by
>> 
>>  May 16th
>> 
>> so I can aggregate/evaluate the responses and we can make a decision.
>> 
>
> I didn't get many responses, but only a single one preferring *only*
> Tokyo, with a few others preferring Santa Fe.
>
> So I'll look into the latter.

OK - let me know if you need any help with it.

Cheers,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

[Coelho, Luciano]

On Wed, 2016-05-18 at 06:51 -0600, Reinoud Koornstra wrote:
> On Wed, May 18, 2016 at 6:41 AM, Coelho, Luciano
>  wrote:
> > 
> > On Wed, 2016-05-18 at 06:20 -0600, Reinoud Koornstra wrote:
> > > 
> > > On Wed, May 18, 2016 at 4:51 AM, Coelho, Luciano
> > >  wrote:
> > > > 
> > > > 
> > > > Hi Emmanuel, Linus,
> > > > 
> > > > 
> > > > On Wed, 2016-05-18 at 06:37 +0300, Emmanuel Grumbach wrote:
> > > > > 
> > > > > 
> > > > > On Wed, May 18, 2016 at 4:00 AM, Linus Torvalds
> > > > >  wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Tue, May 17, 2016 at 12:11 PM, David Miller  > > > > > loft
> > > > > > .net
> > > > > > > 
> > > > > > > 
> > > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > Highlights:
> > > > > > Lowlights:
> > > > > > 
> > > > > >  1) the iwlwifi driver seems to be broken
> > > > > > 
> > > > > > My laptop that uses the intel 7680 iwlwifi module no longer
> > > > > > connects
> > > > > > to the network. It fails with a "Microcode SW error
> > > > > > detected."
> > > > > > and
> > > > > > spews out register state over and over again.
> > > > > Can we have the register state and the ASSERT / NMI /
> > > > > whatever
> > > > > that
> > > > > goes along with it?
> > > > > This clearly means that the firmware is crashing, but I don't
> > > > > know
> > > > > why,
> > > > > I copied here the lines that I need from another bug with
> > > > > another
> > > > > device with another firmware,
> > > > > but the log that we will still explain what I need:
> > > > I managed to reproduce this bug locally with Linus'
> > > > master.  I'm
> > > > investigating the cause and I'll let you how it goes.
> > > I did run the latest git code as well 4.6+
> > > iwlwifi went pearshape in my case as well.
> > > I just updated the microcode as well, it didn't matter.
> > > 4.6-rc7 works fine and no errors are reported with iwlwifi.
> > > 
> > > Here's output that might come in handy
> > Thanks! That is helpful.
> > 
> > Since you say that 4.6-rc7 works but 4.6 doesn't, the prime suspect
> > is
> > commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with
> > the
> > AMSDU len"), which is the only iwlwifi patch between those two
> > releases.
> > 
> > Could you try to revert that and see if the error is gone?
> Will do, since git revert failed I'll revert manually and report
> back.

I can confirm that 4.6 contains the same bug.  And reverting the patch
I mentioned does solve the problem...

The same patch works fine in our internal tree.  I'll have to figure
out together with Emmanuel what the problem actually is.

--
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH 1/2] rtl8xxxu: Increase default polling timeout for firmware startup

[Jes Sorensen]

Daniel Lenski  writes:
> On Tue, May 17, 2016 at 8:35 PM, Jes Sorensen  wrote:
>> Dan Lenski  writes:
>>> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
>>> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
>>> index f2a1bac..39c6ce7 100644
>>> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
>>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
>>> @@ -49,7 +49,7 @@
>>>  #define TX_PAGE_NUM_NORM_PQ  0x02
>>>
>>>  #define RTL_FW_PAGE_SIZE 4096
>>> -#define RTL8XXXU_FIRMWARE_POLL_MAX   1000
>>> +#define RTL8XXXU_FIRMWARE_POLL_MAX   5000
>>
>> This is a long delay - how about 2000?
>
> I tried 2000 first, and it worked for me on only 1 out of 3 cold boots.

OK, lets go for 5000 then to be safe.

Cheers,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Make firmware startup polling timeout configurable, and increase default

[Jes Sorensen]

Daniel Lenski  writes:
> Jes Sorensen  writes:
>>
>> Dan Lenski  writes:
>> >
>> > This issue seems to occur because RTL8XXXU_FIRMWARE_POLL_MAX (1000) is
>> > too short, and the MCU fails to start up as quickly as expected.
>> >
>> > With a longer value (5000), the driver starts up consistently and
>> > successfully after cold-boot.
>>
>> I am not against increasing the maximum value here, however I would like
>> more details about the system where you see these problems. I have used
>> this driver extensively for a long time with my Lenovo Yoga 13 laptop
>> and not seen this issue.
>
> Mine is also a Yoga 13.

Interesting, I thought it might have been an ARM board and it could be
something else that wasn't happening correctly. So far I only know of
the Yogas and certain ARM boards that have the 8723au.

>> Second, I really don't think this warrants a module parameter. Bumping
>> the value should suffice.
>
> Okay. Adding a module parameter was useful for me in debugging, and I
> thought it might be a useful backup option for other end-users who may
> find that the default value doesn't suffice.
>
> It seems plausible to me that the delay is due to waiting for some
> kind of analog circuit to stabilize (PLL, maybe?) and that there could
> be a large variation among devices.

I am surprised your system is that different from mine, but I am fine
with bumping it. I don't really like to clutter the module parameters
unnecessarily, and if we bump this to 5000, I think it is unlikely
anyone else will hit this problem. If they do, I think there are other
issues at play.

>> Note that the patch should at least be relative to
>> wireless-drivers-next, or preferably my rtl8xxxu-devel tree. In both of
>> these trees, the rtl8xxxu driver has been split into multiple files and
>> your patch will not apply.
>>
>> Last, neither of the links you included for external bug reports work.
>
> Are you still unable to follow them in the second version of the patches that
> I submitted? (It appears that they were mangled by Gmane the first
> time I posted them.)
>
> Here they are again:
>
> http://ubuntuforums.org/showthread.php?t=2321756
>
> That is, thread #2321756 at ubuntuforums.org
>
> https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg4942468.html
>
> That is, Ubuntu bug #1574622

I found them from your second post.

Cheers,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iw: Fix -Wabsolute-value compiler warning in iw.c

[Aurimas Liutikas]

Hey there! Any thoughts on this patch?

Aurimas

On Thu, May 12, 2016 at 9:16 AM, Aurimas Liutikas  wrote:
> Signed-off-by: Aurimas Liutikas 
>
> diff --git a/iw.c b/iw.c
> index 2aabddb..a6efe5b 100644
> --- a/iw.c
> +++ b/iw.c
> @@ -516,7 +516,7 @@ int main(int argc, char **argv)
> const struct cmd *cmd = NULL;
>
> /* calculate command size including padding */
> -   cmd_size = abs((long)&__section_set - (long)&__section_get);
> +   cmd_size = labs((long)&__section_set - (long)&__section_get);
> /* strip off self */
> argc--;
> argv0 = *argv++;



-- 

 Aurimas Liutikas | Software Engineer | Chrome / Google
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] rtl8xxxu: increase polling timeout for firmware startup

[Dan Lenski]

Here is a patch to increase the polling timeout for rtl8xxxu firmware
startup.

This patch now applies cleanly to Jes Sorensen's rtl8xxxu-devel tree
(86c89dd4782030c4f9e0c82424a8b92f9fdb35aa).

The patch to make this a module parameter was removed.

Dan Lenski (1):
  rtl8xxxu: Increase default polling timeout for firmware startup

 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] rtl8xxxu: Increase default polling timeout for firmware startup

[Dan Lenski]

This patch increases the default value for the maximum number of polling
loops to wait for the rtl8xxxu MCU to start after the firmware is loaded
(from 1000 to 5000).

With RTL8723AU chipset, I frequently encounter "Firmware failed to start"
errors from rtl8xxxu after a cold boot.

It appears that other chipsets supported by the driver have the same
problem. Here are a couple of relevant bug reports:
- http://ubuntuforums.org/showthread.php?t=2321756
- https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg4942468.html

This issue seems to occur because RTL8XXXU_FIRMWARE_POLL_MAX (1000) is
too short, and the MCU fails to start up as quickly as expected.

With a longer value (5000), the driver starts up consistently and
successfully after cold-boot.

Signed-off-by: Dan Lenski 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 870c9cd..972767f 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -55,7 +55,7 @@
 #define TX_PAGE_NUM_NORM_PQ_8192E  0x00
 
 #define RTL_FW_PAGE_SIZE   4096
-#define RTL8XXXU_FIRMWARE_POLL_MAX 1000
+#define RTL8XXXU_FIRMWARE_POLL_MAX 5000
 
 #define RTL8723A_CHANNEL_GROUPS3
 #define RTL8723A_MAX_RF_PATHS  2
-- 
2.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

[Linus Torvalds]

On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
 wrote:
>
> I can confirm that 4.6 contains the same bug.  And reverting the patch
> I mentioned does solve the problem...
>
> The same patch works fine in our internal tree.  I'll have to figure
> out together with Emmanuel what the problem actually is.

Hmm.

>From what I can tell, there's a merge bug in commit 909b27f70643,
where David seems to have lost some of the changes to
iwl_mvm_set_tx_cmd().

The reason seems to be a conflict with d8fe484470dd, where David
missed the fact that "info->driver_data[0]" had become
"skb_info->driver_data[0]", and then he removed the skb_info because
it was unused.

I do not know if that's the reason for the problem I see. But I will test.

David, do you happen to recall that merge conflict? I think you must
have removed that "skb_info" variable declaration and initialization
manually (due to the "unused variable" warning, which in turn was due
to the incorrect merge of the actual conflict), because I think git
would have merged that line into the result.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

[Coelho, Luciano]

On Wed, 2016-05-18 at 11:45 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 7:23 AM, Coelho, Luciano
>  wrote:
> > 
> > 
> > I can confirm that 4.6 contains the same bug.  And reverting the
> > patch
> > I mentioned does solve the problem...
> > 
> > The same patch works fine in our internal tree.  I'll have to
> > figure
> > out together with Emmanuel what the problem actually is.
> Hmm.
> 
> From what I can tell, there's a merge bug in commit 909b27f70643,
> where David seems to have lost some of the changes to
> iwl_mvm_set_tx_cmd().
> 
> The reason seems to be a conflict with d8fe484470dd, where David
> missed the fact that "info->driver_data[0]" had become
> "skb_info->driver_data[0]", and then he removed the skb_info because
> it was unused.
> 
> I do not know if that's the reason for the problem I see. But I will
> test.
> 
> David, do you happen to recall that merge conflict? I think you must
> have removed that "skb_info" variable declaration and initialization
> manually (due to the "unused variable" warning, which in turn was due
> to the incorrect merge of the actual conflict), because I think git
> would have merged that line into the result.

Actually I just tested it and indeed it seems to be the merge damage
(which we discussed extensively in the linux-wireless mailing list)
that causes this problem.  The "4.6 doesn't work either" thing was a
false alarm.

If the merge damage is fixed this way, the problem is gone:

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index b5f7c36..ae2ecf6 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,6 +211,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct
sk_buff *skb,
struct iwl_tx_cmd *tx_cmd,
struct ieee80211_tx_info *info, u8 sta_id)
 {
+   struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -294,7 +295,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct
sk_buff *skb,
tx_cmd->tx_flags = cpu_to_le32(tx_flags);
/* Total # bytes to be transmitted */
tx_cmd->len = cpu_to_le16((u16)skb->len +
-   (uintptr_t)info->driver_data[0]);
+   (uintptr_t)skb_info->driver_data[0]);
tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
tx_cmd->sta_id = sta_id;


Kalle, David, what is the status with the fix that is on the way via
your trees?

--
Cheers,
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [GIT] Networking

[Linus Torvalds]

On Wed, May 18, 2016 at 11:45 AM, Linus Torvalds
 wrote:
>
> From what I can tell, there's a merge bug in commit 909b27f70643,
> where David seems to have lost some of the changes to
> iwl_mvm_set_tx_cmd().
>
> I do not know if that's the reason for the problem I see. But I will test.

Yes. The attached patch that fixes the incorrect merge seems to fix
things for me.

That should mean that the assumption that this problem existed in v4.6
too was wrong, because the incorrect merge came in later. I think
Luciano mis-understood "v4.6+" to mean plain v4.6.

Reinoud Koornstra, does this patch fix things for you too?

   Linus
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 880210917a6f..c53aa0f220e0 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,6 +211,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff 
*skb,
struct iwl_tx_cmd *tx_cmd,
struct ieee80211_tx_info *info, u8 sta_id)
 {
+   struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -294,7 +295,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff 
*skb,
tx_cmd->tx_flags = cpu_to_le32(tx_flags);
/* Total # bytes to be transmitted */
tx_cmd->len = cpu_to_le16((u16)skb->len +
-   (uintptr_t)info->driver_data[0]);
+   (uintptr_t)skb_info->driver_data[0]);
tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
tx_cmd->sta_id = sta_id;
 

Re: [GIT] Networking

[Kalle Valo]

"Coelho, Luciano"  writes:

> Kalle, David, what is the status with the fix that is on the way via
> your trees?

It would be best if you could send a patch either directly to Dave or
Linus to resolve this quickly.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] iwlwifi: mvm: fix merge damage in tx.c

[Luca Coelho]

From: Luca Coelho 

During the merge in commit 909b27f70643 ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net"), there was a
small merge damage where one instance of info was not converted into
skb_info.  Fix this.

Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 8802109..c53aa0f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -211,6 +211,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff 
*skb,
struct iwl_tx_cmd *tx_cmd,
struct ieee80211_tx_info *info, u8 sta_id)
 {
+   struct ieee80211_tx_info *skb_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
u32 tx_flags = le32_to_cpu(tx_cmd->tx_flags);
@@ -294,7 +295,7 @@ void iwl_mvm_set_tx_cmd(struct iwl_mvm *mvm, struct sk_buff 
*skb,
tx_cmd->tx_flags = cpu_to_le32(tx_flags);
/* Total # bytes to be transmitted */
tx_cmd->len = cpu_to_le16((u16)skb->len +
-   (uintptr_t)info->driver_data[0]);
+   (uintptr_t)skb_info->driver_data[0]);
tx_cmd->life_time = cpu_to_le32(TX_CMD_LIFE_TIME_INFINITE);
tx_cmd->sta_id = sta_id;
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

[Linus Torvalds]

On Wed, May 18, 2016 at 11:58 AM, Kalle Valo  wrote:
>
> It would be best if you could send a patch either directly to Dave or
> Linus to resolve this quickly.

I'm committing my patch myself right now, since this bug makes my
laptop useless, and I will take credit for finding and testing it on
my own even if it was apparently also discussed independently on the
networking list ;)

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

[Coelho, Luciano]

On Wed, 2016-05-18 at 12:00 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2016 at 11:58 AM, Kalle Valo 
> wrote:
> > 
> > 
> > It would be best if you could send a patch either directly to Dave
> > or
> > Linus to resolve this quickly.
> I'm committing my patch myself right now, since this bug makes my
> laptop useless, and I will take credit for finding and testing it on
> my own even if it was apparently also discussed independently on the
> networking list ;)

Great! :)

You beat me by a few minutes, even though I had the whole day to play
with it. :\

--
Cheers,
Luca.N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [GIT] Networking

[Kalle Valo]

Linus Torvalds  writes:

> On Wed, May 18, 2016 at 11:58 AM, Kalle Valo  wrote:
>>
>> It would be best if you could send a patch either directly to Dave or
>> Linus to resolve this quickly.
>
> I'm committing my patch myself right now, since this bug makes my
> laptop useless, and I will take credit for finding and testing it on
> my own

Kiitti :)

> even if it was apparently also discussed independently on the
> networking list ;)

Yeah, sorry about taking this too long.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rtl8xxxu: increase polling timeout for firmware startup

[Jes Sorensen]

Dan Lenski  writes:
> Here is a patch to increase the polling timeout for rtl8xxxu firmware
> startup.
>
> This patch now applies cleanly to Jes Sorensen's rtl8xxxu-devel tree
> (86c89dd4782030c4f9e0c82424a8b92f9fdb35aa).
>
> The patch to make this a module parameter was removed.
>
> Dan Lenski (1):
>   rtl8xxxu: Increase default polling timeout for firmware startup
>
>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Dan,

Thanks for the patch, I'll apply it shortly.

Cheers,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mwifiex: fix racing condition when downloading firmware

[Wei-Ning Huang]

The action 'check for winner' and 'download firmware' should be an
atomic action. This is true for btmrvl driver but not mwmfiex, which
cause firmware download to fail when the following senerio happens:

1) mwifiex check winner status: true
2) btmrvl check winner status: true, and start downloading firmware
3) mwfieix tries to download firmware, but failed because btmrvl is
already downloading.

This won't happen if 1) and 3) is an atomic action. This patch adds
sdio_claim/release_host call around those two actions to make sure it's
atomic.

Signed-off-by: Wei-Ning Huang 
---
 drivers/net/wireless/marvell/mwifiex/main.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 8b67a55..2b65334 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -21,6 +21,7 @@
 #include "wmm.h"
 #include "cfg80211.h"
 #include "11n.h"
+#include "sdio.h"
 
 #define VERSION"1.0"
 
@@ -514,6 +515,7 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, 
void *context)
struct semaphore *sem = adapter->card_sem;
bool init_failed = false;
struct wireless_dev *wdev;
+   struct sdio_mmc_card *card = adapter->card;
 
if (!firmware) {
mwifiex_dbg(adapter, ERROR,
@@ -526,10 +528,16 @@ static void mwifiex_fw_dpc(const struct firmware 
*firmware, void *context)
fw.fw_buf = (u8 *) adapter->firmware->data;
fw.fw_len = adapter->firmware->size;
 
-   if (adapter->if_ops.dnld_fw)
+   if (adapter->if_ops.dnld_fw) {
ret = adapter->if_ops.dnld_fw(adapter, &fw);
-   else
+   } else {
+   if (adapter->iface_type == MWIFIEX_SDIO)
+   sdio_claim_host(card->func);
ret = mwifiex_dnld_fw(adapter, &fw);
+   if (adapter->iface_type == MWIFIEX_SDIO)
+   sdio_release_host(card->func);
+   }
+
if (ret == -1)
goto err_dnld_fw;
 
-- 
2.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT] Networking

[David Miller]

From: Linus Torvalds 
Date: Wed, 18 May 2016 11:45:06 -0700

> David, do you happen to recall that merge conflict? I think you must
> have removed that "skb_info" variable declaration and initialization
> manually (due to the "unused variable" warning, which in turn was due
> to the incorrect merge of the actual conflict), because I think git
> would have merged that line into the result.

Yes, I know I buggered this merge conflict and Kalle said he'd have
a fix coming my way ASAP.

Sorry, I was travelling today, so I'll catch up with this tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html