* Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
From: Shajakhan, Mohammed Shafi (Mohammed Shafi) @ 2017-02-06 12:21 UTC (permalink / raw)
To: Michael Ney, Mohammed Shafi Shajakhan
Cc: Valo, Kalle, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <2DBE5232-FF3F-4B0E-8739-B6E82361316C@vorklift.com>
Hi,=0A=
=0A=
even with the below patch applied ?=0A=
https://patchwork.kernel.org/patch/9452265/=0A=
=0A=
regards=0A=
shafi=0A=
________________________________________=0A=
From: Michael Ney <neym@vorklift.com>=0A=
Sent: 06 February 2017 17:46=0A=
To: Mohammed Shafi Shajakhan=0A=
Cc: Valo, Kalle; linux-wireless@vger.kernel.org; ath10k@lists.infradead.org=
; Shajakhan, Mohammed Shafi (Mohammed Shafi)=0A=
Subject: Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware =
fails=0A=
=0A=
Symmetry is still broken on firmware crash (at least with 6174). ath10k_pci=
_hif_stop gets called twice, once from the driver restart (warm restart) an=
d once from ieee80211 start (cold restart), resulting in napi_synchrionize/=
napi_disable getting called twice and sticking the driver in an infinite wa=
it loop (napi_synchronize waits until NAPI_STATE_SCHED is off, while napi_d=
isable leaves NAPI_STATE_SCHED to on when leaving).=0A=
=0A=
=0A=
> On Feb 6, 2017, at 5:04 AM, Mohammed Shafi Shajakhan <mohammed@codeaurora=
.org> wrote:=0A=
>=0A=
> Hi Kalle,=0A=
>=0A=
> the change suggested by you helps, and the device probe, scan=0A=
> is successful as well. Still good to have this change part of your=0A=
> basic sanity and regression testing !=0A=
>=0A=
> regards,=0A=
> shafi=0A=
>=0A=
> On Wed, Jan 25, 2017 at 01:46:28PM +0000, Valo, Kalle wrote:=0A=
>> Kalle Valo <kvalo@qca.qualcomm.com> writes:=0A=
>>=0A=
>>> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:=0A=
>>>=0A=
>>>> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>=0A=
>>>>=0A=
>>>> This fixes the below crash when ath10k probe firmware fails,=0A=
>>>> NAPI polling tries to access a rx ring resource which was never=0A=
>>>> allocated, fix this by disabling NAPI right away once the probe=0A=
>>>> firmware fails by calling 'ath10k_hif_stop'. Its good to note=0A=
>>>> that the error is never propogated to 'ath10k_pci_probe' when=0A=
>>>> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup=0A=
>>>> PCI related things seems to be ok=0A=
>>>>=0A=
>>>> BUG: unable to handle kernel NULL pointer dereference at (null)=0A=
>>>> IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]=0A=
>>>> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]=0A=
>>>>=0A=
>>>> Call Trace:=0A=
>>>>=0A=
>>>> [<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90=0A=
>>>> [ath10k_core]=0A=
>>>> [<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0=0A=
>>>> [ath10k_core]=0A=
>>>> [<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80=0A=
>>>> [<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150=0A=
>>>> [<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]=0A=
>>>> [<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]=0A=
>>>> [<ffffffff817863af>] net_rx_action+0x20f/0x370=0A=
>>>>=0A=
>>>> Reported-by: Ben Greear <greearb@candelatech.com>=0A=
>>>> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")=0A=
>>>> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>=0A=
>>>=0A=
>>> Is there an easy way to reproduce this bug? I don't see it on my x86=0A=
>>> laptop with qca988x and I call rmmod all the time. I would like to test=
=0A=
>>> this myself.=0A=
>>>=0A=
>>>> --- a/drivers/net/wireless/ath/ath10k/core.c=0A=
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.c=0A=
>>>> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *a=
r)=0A=
>>>> ath10k_core_free_firmware_files(ar);=0A=
>>>>=0A=
>>>> err_power_down:=0A=
>>>> + ath10k_hif_stop(ar);=0A=
>>>> ath10k_hif_power_down(ar);=0A=
>>>>=0A=
>>>> return ret;=0A=
>>>=0A=
>>> This breaks the symmetry, we should not be calling ath10k_hif_stop() if=
=0A=
>>> we haven't called ath10k_hif_start() from the same function. This can=
=0A=
>>> just create a bigger mess later, for example with other bus support lik=
e=0A=
>>> sdio or usb. In theory it should enough that we call=0A=
>>> ath10k_hif_power_down() and pci.c does the rest correctly "behind the=
=0A=
>>> scenes".=0A=
>>>=0A=
>>> I investigated this a bit and I think the real cause is that we call=0A=
>>> napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from=0A=
>>> ath10k_pci_hif_stop(). Does anyone remember why?=0A=
>>>=0A=
>>> I was expecting that we would call napi_enable()/napi_disable() either=
=0A=
>>> in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not=0A=
>>> mixed like it's currently.=0A=
>>=0A=
>> So below is something I was thinking of, now napi_enable() is called=0A=
>> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would=
=0A=
>> that work?=0A=
>>=0A=
>> --- a/drivers/net/wireless/ath/ath10k/pci.c=0A=
>> +++ b/drivers/net/wireless/ath/ath10k/pci.c=0A=
>> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)=
=0A=
>>=0A=
>> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");=0A=
>>=0A=
>> + napi_enable(&ar->napi);=0A=
>> +=0A=
>> ath10k_pci_irq_enable(ar);=0A=
>> ath10k_pci_rx_post(ar);=0A=
>>=0A=
>> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *=
ar)=0A=
>> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);=
=0A=
>> goto err_ce;=0A=
>> }=0A=
>> - napi_enable(&ar->napi);=0A=
>>=0A=
>> return 0;=0A=
>>=0A=
>> --=0A=
>> Kalle Valo=0A=
>=0A=
> _______________________________________________=0A=
> ath10k mailing list=0A=
> ath10k@lists.infradead.org=0A=
> http://lists.infradead.org/mailman/listinfo/ath10k=0A=
=0A=
^ permalink raw reply
* Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e
From: Felix Fietkau @ 2017-02-06 11:52 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo
In-Reply-To: <20170206112508.GA9255@redhat.com>
On 2017-02-06 12:25, Stanislaw Gruszka wrote:
> On Thu, Feb 02, 2017 at 12:52:08PM +0100, Felix Fietkau wrote:
>> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> Driver looks great to me, though I think it could be better commented.
> I have some minor issues, but if they need to be fixed, it could be done
> by incremental patches after apply this one to the tree.
>
> Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Thanks for the review.
>> +enum dma_msg_port {
>> + WLAN_PORT,
>> + CPU_RX_PORT,
>> + CPU_TX_PORT,
>> + HOST_PORT,
>> + VIRTUAL_CPU_RX_PORT,
>> + VIRTUAL_CPU_TX_PORT,
>> + DISCARD,
>> +};
> Not used ?
Yeah, I guess it can be removed.
>> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev)
>> +{
>> + u8 ackto, sifs, slottime = dev->slottime;
>> +
>> + slottime += 3 * dev->coverage_class;
>> +
>> + sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG,
>> + MT_XIFS_TIME_CFG_OFDM_SIFS);
>> +
>> + ackto = slottime + sifs;
>> + mt76_rmw_field(dev, MT_TX_TIMEOUT_CFG,
>> + MT_TX_TIMEOUT_CFG_ACKTO, ackto);
>> +}
> Interesting, if this correct way to configure the TX_TIMEOUT_CFG_ACKTO
> we will also need this in rt2x00. Vendor drivers use 32 for this setting
> and do not change it.
I don't think vendor drivers even have support for coverage class.
> Note we have also EXP_ACT_TIME and EXP_CTS_TIME registers, which stay
> with default settings, but perhaps should be changed depending on
> channel properties as well.
>
>> +static u32
>> +mt76x2_tx_power_mask(u8 v1, u8 v2, u8 v3, u8 v4)
>> +{
>> + u32 val = 0;
>> +
>> + val |= (v1 & (BIT(6) - 1)) << 0;
>> + val |= (v2 & (BIT(6) - 1)) << 8;
>> + val |= (v3 & (BIT(6) - 1)) << 16;
>> + val |= (v4 & (BIT(6) - 1)) << 24;
>> + return val;
>> +}
> TX_PWR_CFG registers consist of eight 4bit entries, masking
> two entries with 0x3f does not seems to be correct.
No, these registers consist of four 6bit entries. Both the vendor driver
and the datasheet describe them this way.
>> + mt76_wr(dev, MT_TX_PWR_CFG_3,
>> + mt76x2_tx_power_mask(t.ht[12], t.ht[14], t.ht[0], t.ht[2]));
>> + mt76_wr(dev, MT_TX_PWR_CFG_4,
>> + mt76x2_tx_power_mask(t.ht[4], t.ht[6], 0, 0));
>> + mt76_wr(dev, MT_TX_PWR_CFG_7,
>> + mt76x2_tx_power_mask(t.ofdm[6], t.vht[8], t.ht[6], t.vht[8]));
>> + mt76_wr(dev, MT_TX_PWR_CFG_8,
>> + mt76x2_tx_power_mask(t.ht[14], t.vht[8], t.vht[8], 0));
>> + mt76_wr(dev, MT_TX_PWR_CFG_9,
>> + mt76x2_tx_power_mask(t.ht[6], t.vht[8], t.vht[8], 0));
> Looks like some of arguments instead of t.vht[x] accidentally become t.ht[x],
> for example t.vht[6] is never used.
There are not enough register fields for all rates individually, so they
overlap. This looks a bit confusing and random, but I did check it
carefully against the vendor driver and the datasheet.
>> +static void
>> +mt76x2_configure_tx_delay(struct mt76x2_dev *dev, enum nl80211_band band, u8 bw)
>> +{
>> + u32 cfg0, cfg1;
>> +
>> + if (mt76x2_ext_pa_enabled(dev, band)) {
>> + cfg0 = bw ? 0x000b0c01 : 0x00101101;
>> + cfg1 = 0x00011414;
>> + } else {
>> + cfg0 = bw ? 0x000b0b01 : 0x00101001;
>> + cfg1 = 0x00021414;
>> + }
>> + mt76_wr(dev, MT_TX_SW_CFG0, cfg0);
>> + mt76_wr(dev, MT_TX_SW_CFG1, cfg1);
>> +
>> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_CCK_SIFS,
>> + 13 + (bw ? 1 : 0));
>> +}
> SIFS for 2GHz should be 10us and for 5GHz 16us. Setting SIFS to 13
> or 14 looks wrong for 2GHz band. Can be correct for 5GHz assuming
> we have some internal delays configured on TX_SW_CFG registers.
This is a CCK-only SIFS value (there's a separate one for OFDM).
> But again this is interesting for rt2x00, where we stay with
> defaults, but looks we should configure XIFS_TIME_CFG based on
> channel.
I think many of these might be mt76x2 specific tweaks, so be careful
with applying any of that to rt2x00.
>> + if (chandef->width >= NL80211_CHAN_WIDTH_40)
>> + sifs++;
>> +
>> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_OFDM_SIFS, sifs);
> This probably should be set together with MT_XIFS_TIME_CFG_CCK_SIFS in
> mt76x2_configure_tx_delay().
Will look into that.
>> +static int mt76x2_insert_hdr_pad(struct sk_buff *skb)
>> +{
>> + int len = ieee80211_get_hdrlen_from_skb(skb);
>> + int ret;
>> +
>> + if (len % 4 == 0)
>> + return 0;
>> +
>> + if (skb_headroom(skb) < 2) {
>> + ret = pskb_expand_head(skb, 2, 0, GFP_ATOMIC);
>> + if (ret != 0)
>> + return ret;
> This should not be needed if hw->extra_tx_headroom is set properly.
Thanks, will send a follow-up cleanup patch if this one is accepted.
>> + if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
>> + qsel = 0;
> For better understating: qsel = MT_QSEL_MGMT;
Right.
>> +void mt76x2_pre_tbtt_tasklet(unsigned long arg)
>> +{
>> + struct mt76x2_dev *dev = (struct mt76x2_dev *) arg;
>> + struct mt76_queue *q = &dev->mt76.q_tx[MT_TXQ_PSD];
>> + struct beacon_bc_data data = {};
>> + struct sk_buff *skb;
>> + int i, nframes;
>> +
>> + data.dev = dev;
>> + __skb_queue_head_init(&data.q);
>> +
>> + ieee80211_iterate_active_interfaces_atomic(mt76_hw(dev),
> This symbol, not like most of other mac80211 symbols, is exported via
> EXPORT_SYMBOL_GPL(), so I'm not sure if it can be used on dual licensed
> file, perhaps licence of this file should be changed to GPL only.
Technically only the resulting binary will become GPL. I still want to
keep the source code of the entire driver ISC licensed to make it easier
for the BSDs to copy code from it.
- Felix
^ permalink raw reply
* Re: [PATCH 01/11 V2] rtlwifi: Fix programing CAM content sequence.
From: Kalle Valo @ 2017-02-06 11:50 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, shaofu
In-Reply-To: <20170120212716.29887-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> There is a potential race condition when the control byte of a CAM
> entry is written first. Write in reverse order to correct the condition.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: shaofu <shaofu@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> V2 - no changes
Weird, I don't see any of the v2 patches in patchwork:
https://patchwork.kernel.org/project/linux-wireless/list/?state=*&page=1
I do see other recent patches from you Larry, but not this set. Can you
resubmit, please?
--
Kalle Valo
^ permalink raw reply
* Submitted patches for 4.11 NOW
From: Kalle Valo @ 2017-02-06 11:41 UTC (permalink / raw)
To: linux-wireless
Hi,
Linus is hinting that he might release the final 4.10 next Sunday. So if
you want have patches with new features in 4.11 better post them NOW to
not the miss the merge window.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 3/3] mt76: add driver code for MT76x2e
From: Stanislaw Gruszka @ 2017-02-06 11:25 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <20170202115208.8614-4-nbd@nbd.name>
On Thu, Feb 02, 2017 at 12:52:08PM +0100, Felix Fietkau wrote:
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Driver looks great to me, though I think it could be better commented.
I have some minor issues, but if they need to be fixed, it could be done
by incremental patches after apply this one to the tree.
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
> +enum dma_msg_port {
> + WLAN_PORT,
> + CPU_RX_PORT,
> + CPU_TX_PORT,
> + HOST_PORT,
> + VIRTUAL_CPU_RX_PORT,
> + VIRTUAL_CPU_TX_PORT,
> + DISCARD,
> +};
Not used ?
> +void mt76x2_set_tx_ackto(struct mt76x2_dev *dev)
> +{
> + u8 ackto, sifs, slottime = dev->slottime;
> +
> + slottime += 3 * dev->coverage_class;
> +
> + sifs = mt76_get_field(dev, MT_XIFS_TIME_CFG,
> + MT_XIFS_TIME_CFG_OFDM_SIFS);
> +
> + ackto = slottime + sifs;
> + mt76_rmw_field(dev, MT_TX_TIMEOUT_CFG,
> + MT_TX_TIMEOUT_CFG_ACKTO, ackto);
> +}
Interesting, if this correct way to configure the TX_TIMEOUT_CFG_ACKTO
we will also need this in rt2x00. Vendor drivers use 32 for this setting
and do not change it.
Note we have also EXP_ACT_TIME and EXP_CTS_TIME registers, which stay
with default settings, but perhaps should be changed depending on
channel properties as well.
> +static u32
> +mt76x2_tx_power_mask(u8 v1, u8 v2, u8 v3, u8 v4)
> +{
> + u32 val = 0;
> +
> + val |= (v1 & (BIT(6) - 1)) << 0;
> + val |= (v2 & (BIT(6) - 1)) << 8;
> + val |= (v3 & (BIT(6) - 1)) << 16;
> + val |= (v4 & (BIT(6) - 1)) << 24;
> + return val;
> +}
TX_PWR_CFG registers consist of eight 4bit entries, masking
two entries with 0x3f does not seems to be correct.
> + mt76_wr(dev, MT_TX_PWR_CFG_3,
> + mt76x2_tx_power_mask(t.ht[12], t.ht[14], t.ht[0], t.ht[2]));
> + mt76_wr(dev, MT_TX_PWR_CFG_4,
> + mt76x2_tx_power_mask(t.ht[4], t.ht[6], 0, 0));
> + mt76_wr(dev, MT_TX_PWR_CFG_7,
> + mt76x2_tx_power_mask(t.ofdm[6], t.vht[8], t.ht[6], t.vht[8]));
> + mt76_wr(dev, MT_TX_PWR_CFG_8,
> + mt76x2_tx_power_mask(t.ht[14], t.vht[8], t.vht[8], 0));
> + mt76_wr(dev, MT_TX_PWR_CFG_9,
> + mt76x2_tx_power_mask(t.ht[6], t.vht[8], t.vht[8], 0));
Looks like some of arguments instead of t.vht[x] accidentally become t.ht[x],
for example t.vht[6] is never used.
> +static void
> +mt76x2_configure_tx_delay(struct mt76x2_dev *dev, enum nl80211_band band, u8 bw)
> +{
> + u32 cfg0, cfg1;
> +
> + if (mt76x2_ext_pa_enabled(dev, band)) {
> + cfg0 = bw ? 0x000b0c01 : 0x00101101;
> + cfg1 = 0x00011414;
> + } else {
> + cfg0 = bw ? 0x000b0b01 : 0x00101001;
> + cfg1 = 0x00021414;
> + }
> + mt76_wr(dev, MT_TX_SW_CFG0, cfg0);
> + mt76_wr(dev, MT_TX_SW_CFG1, cfg1);
> +
> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_CCK_SIFS,
> + 13 + (bw ? 1 : 0));
> +}
SIFS for 2GHz should be 10us and for 5GHz 16us. Setting SIFS to 13
or 14 looks wrong for 2GHz band. Can be correct for 5GHz assuming
we have some internal delays configured on TX_SW_CFG registers.
But again this is interesting for rt2x00, where we stay with
defaults, but looks we should configure XIFS_TIME_CFG based on
channel.
> + if (chandef->width >= NL80211_CHAN_WIDTH_40)
> + sifs++;
> +
> + mt76_rmw_field(dev, MT_XIFS_TIME_CFG, MT_XIFS_TIME_CFG_OFDM_SIFS, sifs);
This probably should be set together with MT_XIFS_TIME_CFG_CCK_SIFS in
mt76x2_configure_tx_delay().
> +static int mt76x2_insert_hdr_pad(struct sk_buff *skb)
> +{
> + int len = ieee80211_get_hdrlen_from_skb(skb);
> + int ret;
> +
> + if (len % 4 == 0)
> + return 0;
> +
> + if (skb_headroom(skb) < 2) {
> + ret = pskb_expand_head(skb, 2, 0, GFP_ATOMIC);
> + if (ret != 0)
> + return ret;
This should not be needed if hw->extra_tx_headroom is set properly.
> + if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
> + qsel = 0;
For better understating: qsel = MT_QSEL_MGMT;
> +void mt76x2_pre_tbtt_tasklet(unsigned long arg)
> +{
> + struct mt76x2_dev *dev = (struct mt76x2_dev *) arg;
> + struct mt76_queue *q = &dev->mt76.q_tx[MT_TXQ_PSD];
> + struct beacon_bc_data data = {};
> + struct sk_buff *skb;
> + int i, nframes;
> +
> + data.dev = dev;
> + __skb_queue_head_init(&data.q);
> +
> + ieee80211_iterate_active_interfaces_atomic(mt76_hw(dev),
This symbol, not like most of other mac80211 symbols, is exported via
EXPORT_SYMBOL_GPL(), so I'm not sure if it can be used on dual licensed
file, perhaps licence of this file should be changed to GPL only.
Stanislaw
^ permalink raw reply
* [PATCH v3 2/2] mac80211: aes-cmac: switch to shash CMAC driver
From: Ard Biesheuvel @ 2017-02-06 10:49 UTC (permalink / raw)
To: johannes, linux-wireless; +Cc: davem, netdev, jouni, Ard Biesheuvel
In-Reply-To: <1486378168-31028-1-git-send-email-ard.biesheuvel@linaro.org>
Instead of open coding the CMAC algorithm in the mac80211 driver using
byte wide xors and calls into the crypto layer for each block of data,
instantiate a cmac(aes) synchronous hash and pass all the data into it
directly. This does not only simplify the code, it also allows the use
of more efficient and more secure implementations, especially on
platforms where SIMD ciphers have a considerable setup cost.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/aes_cmac.c | 126 ++++----------------
net/mac80211/aes_cmac.h | 11 +-
net/mac80211/key.h | 2 +-
3 files changed, 32 insertions(+), 107 deletions(-)
diff --git a/net/mac80211/aes_cmac.c b/net/mac80211/aes_cmac.c
index d0bd5fff5f0a..2fb65588490c 100644
--- a/net/mac80211/aes_cmac.c
+++ b/net/mac80211/aes_cmac.c
@@ -22,126 +22,50 @@
#define CMAC_TLEN_256 16 /* CMAC TLen = 128 bits (16 octets) */
#define AAD_LEN 20
+static const u8 zero[CMAC_TLEN_256];
-void gf_mulx(u8 *pad)
-{
- int i, carry;
-
- carry = pad[0] & 0x80;
- for (i = 0; i < AES_BLOCK_SIZE - 1; i++)
- pad[i] = (pad[i] << 1) | (pad[i + 1] >> 7);
- pad[AES_BLOCK_SIZE - 1] <<= 1;
- if (carry)
- pad[AES_BLOCK_SIZE - 1] ^= 0x87;
-}
-
-void aes_cmac_vector(struct crypto_cipher *tfm, size_t num_elem,
- const u8 *addr[], const size_t *len, u8 *mac,
- size_t mac_len)
-{
- u8 cbc[AES_BLOCK_SIZE], pad[AES_BLOCK_SIZE];
- const u8 *pos, *end;
- size_t i, e, left, total_len;
-
- memset(cbc, 0, AES_BLOCK_SIZE);
-
- total_len = 0;
- for (e = 0; e < num_elem; e++)
- total_len += len[e];
- left = total_len;
-
- e = 0;
- pos = addr[0];
- end = pos + len[0];
-
- while (left >= AES_BLOCK_SIZE) {
- for (i = 0; i < AES_BLOCK_SIZE; i++) {
- cbc[i] ^= *pos++;
- if (pos >= end) {
- e++;
- pos = addr[e];
- end = pos + len[e];
- }
- }
- if (left > AES_BLOCK_SIZE)
- crypto_cipher_encrypt_one(tfm, cbc, cbc);
- left -= AES_BLOCK_SIZE;
- }
-
- memset(pad, 0, AES_BLOCK_SIZE);
- crypto_cipher_encrypt_one(tfm, pad, pad);
- gf_mulx(pad);
-
- if (left || total_len == 0) {
- for (i = 0; i < left; i++) {
- cbc[i] ^= *pos++;
- if (pos >= end) {
- e++;
- pos = addr[e];
- end = pos + len[e];
- }
- }
- cbc[left] ^= 0x80;
- gf_mulx(pad);
- }
-
- for (i = 0; i < AES_BLOCK_SIZE; i++)
- pad[i] ^= cbc[i];
- crypto_cipher_encrypt_one(tfm, pad, pad);
- memcpy(mac, pad, mac_len);
-}
-
-
-void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
+void ieee80211_aes_cmac(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
{
- const u8 *addr[3];
- size_t len[3];
- u8 zero[CMAC_TLEN];
+ SHASH_DESC_ON_STACK(desc, tfm);
+ u8 out[AES_BLOCK_SIZE];
- memset(zero, 0, CMAC_TLEN);
- addr[0] = aad;
- len[0] = AAD_LEN;
- addr[1] = data;
- len[1] = data_len - CMAC_TLEN;
- addr[2] = zero;
- len[2] = CMAC_TLEN;
+ desc->tfm = tfm;
- aes_cmac_vector(tfm, 3, addr, len, mic, CMAC_TLEN);
+ crypto_shash_init(desc);
+ crypto_shash_update(desc, aad, AAD_LEN);
+ crypto_shash_update(desc, data, data_len - CMAC_TLEN);
+ crypto_shash_finup(desc, zero, CMAC_TLEN, out);
+
+ memcpy(mic, out, CMAC_TLEN);
}
-void ieee80211_aes_cmac_256(struct crypto_cipher *tfm, const u8 *aad,
+void ieee80211_aes_cmac_256(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic)
{
- const u8 *addr[3];
- size_t len[3];
- u8 zero[CMAC_TLEN_256];
+ SHASH_DESC_ON_STACK(desc, tfm);
- memset(zero, 0, CMAC_TLEN_256);
- addr[0] = aad;
- len[0] = AAD_LEN;
- addr[1] = data;
- len[1] = data_len - CMAC_TLEN_256;
- addr[2] = zero;
- len[2] = CMAC_TLEN_256;
+ desc->tfm = tfm;
- aes_cmac_vector(tfm, 3, addr, len, mic, CMAC_TLEN_256);
+ crypto_shash_init(desc);
+ crypto_shash_update(desc, aad, AAD_LEN);
+ crypto_shash_update(desc, data, data_len - CMAC_TLEN_256);
+ crypto_shash_finup(desc, zero, CMAC_TLEN_256, mic);
}
-struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
- size_t key_len)
+struct crypto_shash *ieee80211_aes_cmac_key_setup(const u8 key[],
+ size_t key_len)
{
- struct crypto_cipher *tfm;
+ struct crypto_shash *tfm;
- tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
+ tfm = crypto_alloc_shash("cmac(aes)", 0, 0);
if (!IS_ERR(tfm))
- crypto_cipher_setkey(tfm, key, key_len);
+ crypto_shash_setkey(tfm, key, key_len);
return tfm;
}
-
-void ieee80211_aes_cmac_key_free(struct crypto_cipher *tfm)
+void ieee80211_aes_cmac_key_free(struct crypto_shash *tfm)
{
- crypto_free_cipher(tfm);
+ crypto_free_shash(tfm);
}
diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h
index 3702041f44fd..fef531f42003 100644
--- a/net/mac80211/aes_cmac.h
+++ b/net/mac80211/aes_cmac.h
@@ -10,13 +10,14 @@
#define AES_CMAC_H
#include <linux/crypto.h>
+#include <crypto/hash.h>
-struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
- size_t key_len);
-void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
+struct crypto_shash *ieee80211_aes_cmac_key_setup(const u8 key[],
+ size_t key_len);
+void ieee80211_aes_cmac(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic);
-void ieee80211_aes_cmac_256(struct crypto_cipher *tfm, const u8 *aad,
+void ieee80211_aes_cmac_256(struct crypto_shash *tfm, const u8 *aad,
const u8 *data, size_t data_len, u8 *mic);
-void ieee80211_aes_cmac_key_free(struct crypto_cipher *tfm);
+void ieee80211_aes_cmac_key_free(struct crypto_shash *tfm);
#endif /* AES_CMAC_H */
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 4aa20cef0859..ebdb80b85dc3 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -93,7 +93,7 @@ struct ieee80211_key {
} ccmp;
struct {
u8 rx_pn[IEEE80211_CMAC_PN_LEN];
- struct crypto_cipher *tfm;
+ struct crypto_shash *tfm;
u32 replays; /* dot11RSNAStatsCMACReplays */
u32 icverrors; /* dot11RSNAStatsCMACICVErrors */
} aes_cmac;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
From: Ard Biesheuvel @ 2017-02-06 10:49 UTC (permalink / raw)
To: johannes, linux-wireless; +Cc: davem, netdev, jouni, Ard Biesheuvel
In-Reply-To: <1486378168-31028-1-git-send-email-ard.biesheuvel@linaro.org>
Switch the FILS AEAD code to use a cmac(aes) shash instantiated by the
crypto API rather than reusing the open coded implementation in
aes_cmac_vector(). This makes the code more understandable, and allows
platforms to implement cmac(aes) in a more secure (*) and efficient way
than is typically possible when using the AES cipher directly.
So replace the crypto_cipher by a crypto_shash, and update the aes_s2v()
routine to call the shash interface directly.
* In particular, the generic table based AES implementation is sensitive
to known-plaintext timing attacks on the key, to which AES based MAC
algorithms are especially vulnerable, given that their plaintext is not
usually secret. Time invariant alternatives are available (e.g., based
on SIMD algorithms), but may incur a setup cost that is prohibitive when
operating on a single block at a time, which is why they don't usually
expose the cipher API.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/Kconfig | 1 +
net/mac80211/aes_cmac.h | 4 --
net/mac80211/fils_aead.c | 74 +++++++++-----------
3 files changed, 34 insertions(+), 45 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 3891cbd2adea..76e30f4797fb 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -6,6 +6,7 @@ config MAC80211
select CRYPTO_AES
select CRYPTO_CCM
select CRYPTO_GCM
+ select CRYPTO_CMAC
select CRC32
---help---
This option enables the hardware independent IEEE 802.11
diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h
index c827e1d5de8b..3702041f44fd 100644
--- a/net/mac80211/aes_cmac.h
+++ b/net/mac80211/aes_cmac.h
@@ -11,10 +11,6 @@
#include <linux/crypto.h>
-void gf_mulx(u8 *pad);
-void aes_cmac_vector(struct crypto_cipher *tfm, size_t num_elem,
- const u8 *addr[], const size_t *len, u8 *mac,
- size_t mac_len);
struct crypto_cipher *ieee80211_aes_cmac_key_setup(const u8 key[],
size_t key_len);
void ieee80211_aes_cmac(struct crypto_cipher *tfm, const u8 *aad,
diff --git a/net/mac80211/fils_aead.c b/net/mac80211/fils_aead.c
index 5c3af5eb4052..3cfb1e2ab7ac 100644
--- a/net/mac80211/fils_aead.c
+++ b/net/mac80211/fils_aead.c
@@ -9,66 +9,58 @@
#include <crypto/aes.h>
#include <crypto/algapi.h>
+#include <crypto/hash.h>
#include <crypto/skcipher.h>
#include "ieee80211_i.h"
#include "aes_cmac.h"
#include "fils_aead.h"
-static int aes_s2v(struct crypto_cipher *tfm,
+static void gf_mulx(u8 *pad)
+{
+ u64 a = get_unaligned_be64(pad);
+ u64 b = get_unaligned_be64(pad + 8);
+
+ put_unaligned_be64((a << 1) | (b >> 63), pad);
+ put_unaligned_be64((b << 1) ^ ((a >> 63) ? 0x87 : 0), pad + 8);
+}
+
+static int aes_s2v(struct crypto_shash *tfm,
size_t num_elem, const u8 *addr[], size_t len[], u8 *v)
{
- u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
+ u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE] = {};
+ SHASH_DESC_ON_STACK(desc, tfm);
size_t i;
- const u8 *data[2];
- size_t data_len[2], data_elems;
+
+ desc->tfm = tfm;
/* D = AES-CMAC(K, <zero>) */
- memset(tmp, 0, AES_BLOCK_SIZE);
- data[0] = tmp;
- data_len[0] = AES_BLOCK_SIZE;
- aes_cmac_vector(tfm, 1, data, data_len, d, AES_BLOCK_SIZE);
+ crypto_shash_digest(desc, tmp, AES_BLOCK_SIZE, d);
for (i = 0; i < num_elem - 1; i++) {
/* D = dbl(D) xor AES_CMAC(K, Si) */
gf_mulx(d); /* dbl */
- aes_cmac_vector(tfm, 1, &addr[i], &len[i], tmp,
- AES_BLOCK_SIZE);
+ crypto_shash_digest(desc, addr[i], len[i], tmp);
crypto_xor(d, tmp, AES_BLOCK_SIZE);
}
+ crypto_shash_init(desc);
+
if (len[i] >= AES_BLOCK_SIZE) {
/* len(Sn) >= 128 */
- size_t j;
- const u8 *pos;
-
/* T = Sn xorend D */
-
- /* Use a temporary buffer to perform xorend on Sn (addr[i]) to
- * avoid modifying the const input argument.
- */
- data[0] = addr[i];
- data_len[0] = len[i] - AES_BLOCK_SIZE;
- pos = addr[i] + data_len[0];
- for (j = 0; j < AES_BLOCK_SIZE; j++)
- tmp[j] = pos[j] ^ d[j];
- data[1] = tmp;
- data_len[1] = AES_BLOCK_SIZE;
- data_elems = 2;
+ crypto_shash_update(desc, addr[i], len[i] - AES_BLOCK_SIZE);
+ crypto_xor(d, addr[i] + len[i] - AES_BLOCK_SIZE,
+ AES_BLOCK_SIZE);
} else {
/* len(Sn) < 128 */
/* T = dbl(D) xor pad(Sn) */
gf_mulx(d); /* dbl */
- memset(tmp, 0, AES_BLOCK_SIZE);
- memcpy(tmp, addr[i], len[i]);
- tmp[len[i]] = 0x80;
- crypto_xor(d, tmp, AES_BLOCK_SIZE);
- data[0] = d;
- data_len[0] = sizeof(d);
- data_elems = 1;
+ crypto_xor(d, addr[i], len[i]);
+ d[len[i]] ^= 0x80;
}
/* V = AES-CMAC(K, T) */
- aes_cmac_vector(tfm, data_elems, data, data_len, v, AES_BLOCK_SIZE);
+ crypto_shash_finup(desc, d, AES_BLOCK_SIZE, v);
return 0;
}
@@ -80,7 +72,7 @@ static int aes_siv_encrypt(const u8 *key, size_t key_len,
size_t len[], u8 *out)
{
u8 v[AES_BLOCK_SIZE];
- struct crypto_cipher *tfm;
+ struct crypto_shash *tfm;
struct crypto_skcipher *tfm2;
struct skcipher_request *req;
int res;
@@ -95,14 +87,14 @@ static int aes_siv_encrypt(const u8 *key, size_t key_len,
/* S2V */
- tfm = crypto_alloc_cipher("aes", 0, 0);
+ tfm = crypto_alloc_shash("cmac(aes)", 0, 0);
if (IS_ERR(tfm))
return PTR_ERR(tfm);
/* K1 for S2V */
- res = crypto_cipher_setkey(tfm, key, key_len);
+ res = crypto_shash_setkey(tfm, key, key_len);
if (!res)
res = aes_s2v(tfm, num_elem, addr, len, v);
- crypto_free_cipher(tfm);
+ crypto_free_shash(tfm);
if (res)
return res;
@@ -157,7 +149,7 @@ static int aes_siv_decrypt(const u8 *key, size_t key_len,
size_t num_elem, const u8 *addr[], size_t len[],
u8 *out)
{
- struct crypto_cipher *tfm;
+ struct crypto_shash *tfm;
struct crypto_skcipher *tfm2;
struct skcipher_request *req;
struct scatterlist src[1], dst[1];
@@ -210,14 +202,14 @@ static int aes_siv_decrypt(const u8 *key, size_t key_len,
/* S2V */
- tfm = crypto_alloc_cipher("aes", 0, 0);
+ tfm = crypto_alloc_shash("cmac(aes)", 0, 0);
if (IS_ERR(tfm))
return PTR_ERR(tfm);
/* K1 for S2V */
- res = crypto_cipher_setkey(tfm, key, key_len);
+ res = crypto_shash_setkey(tfm, key, key_len);
if (!res)
res = aes_s2v(tfm, num_elem, addr, len, check);
- crypto_free_cipher(tfm);
+ crypto_free_shash(tfm);
if (res)
return res;
if (memcmp(check, frame_iv, AES_BLOCK_SIZE) != 0)
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/2] mac80211: use crypto shash for AES cmac
From: Ard Biesheuvel @ 2017-02-06 10:49 UTC (permalink / raw)
To: johannes, linux-wireless; +Cc: davem, netdev, jouni, Ard Biesheuvel
This is something I spotted while working on AES in various modes for
ARM and arm64.
The mac80211 aes_cmac code reimplements the CMAC algorithm based on the
core AES cipher, which is rather restrictive in how platforms can satisfy
the dependency on this algorithm. For instance, SIMD implementations may
have a considerable setup time, which cannot be amortized over the entire
input when calling into the crypto API one block at a time. Also, it prevents
the use of more secure fixed time implementations, since not all AES drivers
expose the cipher interface.
So switch aes_cmac to use a cmac(aes) shash. Before updating the aes_cmac code
in patch #2, the FILS AEAD code is moved to using a cmac(aes) shash supplied by
the crypto API so that we can remove the open coded version entirely in the
second patch.
v3: - use more idiomatic SHASH_DESC_ON_STACK to allocate the shash descriptors
- replace compound literal zero vectors with explicitly defined ones
- drop a redundant memcpy() in #2
Ard Biesheuvel (2):
mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
mac80211: aes-cmac: switch to shash CMAC driver
net/mac80211/Kconfig | 1 +
net/mac80211/aes_cmac.c | 126 ++++----------------
net/mac80211/aes_cmac.h | 15 +--
net/mac80211/fils_aead.c | 74 +++++-------
net/mac80211/key.h | 2 +-
5 files changed, 66 insertions(+), 152 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: rtlwifi: rtl8192c_common: "BUG: KASAN: slab-out-of-bounds"
From: Johannes Berg @ 2017-02-06 10:29 UTC (permalink / raw)
To: Larry Finger, Dmitry Osipenko, Chaoming Li
Cc: linux-wireless, Linux Kernel Mailing List
In-Reply-To: <edbcbe3f-9b5d-cead-5885-27bc55ef550b@lwfinger.net>
On Sat, 2017-02-04 at 12:41 -0600, Larry Finger wrote:
> On 02/04/2017 10:58 AM, Dmitry Osipenko wrote:
> > Seems the problem is caused by rtl92c_dm_*() casting .priv to
> > "struct
> > rtl_pci_priv", while it is "struct rtl_usb_priv".
>
> Those routines are shared by rtl8192ce and rtl8192cu, thus we need to
> make that
> difference in cast to be immaterial. I think we need to move "struct
> bt_coexist_info" to the beginning of both rtlpci_priv and
> rtl_usb_priv. Then it
> should not matter.
I think you really should consider putting a struct rtl_common into
that or something, and getting rid of all the casting that causes this
problem to start with?
johannes
^ permalink raw reply
* Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac
From: Ard Biesheuvel @ 2017-02-06 10:08 UTC (permalink / raw)
To: Malinen, Jouni
Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20170206100100.GA5905@jouni.qca.qualcomm.com>
On 6 February 2017 at 10:01, Malinen, Jouni <jouni@qca.qualcomm.com> wrote:
> On Sun, Feb 05, 2017 at 03:23:26PM +0000, Ard Biesheuvel wrote:
>> NOTE: Jouni has been so kind to test patch #2, and confirmed that it is working.
>> I have not tested patch #1 myself, mainly because the test methodology
>> requires downloading Ubuntu installer images, and I am currently on a
>> metered 3G connection (and will be for another couple of weeks)
>
> These v2 patches pass the test cases as well.
>
Thanks!
> (And you don't really need Ubuntu to run the hwsim test cases; any
> reasonably recent distribution that is capable of running kvm should
> work.)
>
Well, now that you have done my testing for me, I am not sure I will
get around to trying the VM.
Thanks,
Ard.
^ permalink raw reply
* Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
From: Mohammed Shafi Shajakhan @ 2017-02-06 10:04 UTC (permalink / raw)
To: Valo, Kalle
Cc: Shajakhan, Mohammed Shafi (Mohammed Shafi),
ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <871svr8d83.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
the change suggested by you helps, and the device probe, scan
is successful as well. Still good to have this change part of your
basic sanity and regression testing !
regards,
shafi
On Wed, Jan 25, 2017 at 01:46:28PM +0000, Valo, Kalle wrote:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
> > Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> >
> >> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >>
> >> This fixes the below crash when ath10k probe firmware fails,
> >> NAPI polling tries to access a rx ring resource which was never
> >> allocated, fix this by disabling NAPI right away once the probe
> >> firmware fails by calling 'ath10k_hif_stop'. Its good to note
> >> that the error is never propogated to 'ath10k_pci_probe' when
> >> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
> >> PCI related things seems to be ok
> >>
> >> BUG: unable to handle kernel NULL pointer dereference at (null)
> >> IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >>
> >> Call Trace:
> >>
> >> [<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
> >> [ath10k_core]
> >> [<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0
> >> [ath10k_core]
> >> [<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80
> >> [<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150
> >> [<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
> >> [<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
> >> [<ffffffff817863af>] net_rx_action+0x20f/0x370
> >>
> >> Reported-by: Ben Greear <greearb@candelatech.com>
> >> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> >> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> > Is there an easy way to reproduce this bug? I don't see it on my x86
> > laptop with qca988x and I call rmmod all the time. I would like to test
> > this myself.
> >
> >> --- a/drivers/net/wireless/ath/ath10k/core.c
> >> +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
> >> ath10k_core_free_firmware_files(ar);
> >>
> >> err_power_down:
> >> + ath10k_hif_stop(ar);
> >> ath10k_hif_power_down(ar);
> >>
> >> return ret;
> >
> > This breaks the symmetry, we should not be calling ath10k_hif_stop() if
> > we haven't called ath10k_hif_start() from the same function. This can
> > just create a bigger mess later, for example with other bus support like
> > sdio or usb. In theory it should enough that we call
> > ath10k_hif_power_down() and pci.c does the rest correctly "behind the
> > scenes".
> >
> > I investigated this a bit and I think the real cause is that we call
> > napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
> > ath10k_pci_hif_stop(). Does anyone remember why?
> >
> > I was expecting that we would call napi_enable()/napi_disable() either
> > in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
> > mixed like it's currently.
>
> So below is something I was thinking of, now napi_enable() is called
> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
> that work?
>
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>
> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>
> + napi_enable(&ar->napi);
> +
> ath10k_pci_irq_enable(ar);
> ath10k_pci_rx_post(ar);
>
> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
> goto err_ce;
> }
> - napi_enable(&ar->napi);
>
> return 0;
>
> --
> Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac
From: Malinen, Jouni @ 2017-02-06 10:01 UTC (permalink / raw)
To: ard.biesheuvel@linaro.org
Cc: johannes@sipsolutions.net, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <1486308208-3252-1-git-send-email-ard.biesheuvel@linaro.org>
On Sun, Feb 05, 2017 at 03:23:26PM +0000, Ard Biesheuvel wrote:
> NOTE: Jouni has been so kind to test patch #2, and confirmed that it is w=
orking.
> I have not tested patch #1 myself, mainly because the test methodol=
ogy
> requires downloading Ubuntu installer images, and I am currently on=
a
> metered 3G connection (and will be for another couple of weeks)
These v2 patches pass the test cases as well.
(And you don't really need Ubuntu to run the hwsim test cases; any
reasonably recent distribution that is capable of running kvm should
work.)
=20
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Re: [PATCH V2] mtd: bcm47xxsflash: use platform_(set|get)_drvdata
From: Boris Brezillon @ 2017-02-06 9:46 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Kalle Valo, linux-mtd, linux-wireless,
Hauke Mehrtens, Rafał Miłecki
In-Reply-To: <20170116162818.12094-1-zajec5@gmail.com>
On Mon, 16 Jan 2017 17:28:18 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> We have generic place & helpers for storing platform driver data so
> there is no reason for using custom priv pointer.
>
> This allows cleaning up struct bcma_sflash from unneeded fields.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Kalle: This is mtd focused patch, so I guess it should go through mtd tree. Do
> you find bcma change important enough to care to Ack it? :)
> ---
> drivers/mtd/devices/bcm47xxsflash.c | 6 +++---
> include/linux/bcma/bcma_driver_chipcommon.h | 3 ---
> 2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/devices/bcm47xxsflash.c b/drivers/mtd/devices/bcm47xxsflash.c
> index 514be04..4decd8c 100644
> --- a/drivers/mtd/devices/bcm47xxsflash.c
> +++ b/drivers/mtd/devices/bcm47xxsflash.c
> @@ -284,7 +284,6 @@ static int bcm47xxsflash_bcma_probe(struct platform_device *pdev)
> b47s = devm_kzalloc(dev, sizeof(*b47s), GFP_KERNEL);
> if (!b47s)
> return -ENOMEM;
> - sflash->priv = b47s;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> @@ -334,6 +333,8 @@ static int bcm47xxsflash_bcma_probe(struct platform_device *pdev)
> b47s->size = sflash->size;
> bcm47xxsflash_fill_mtd(b47s, &pdev->dev);
>
> + platform_set_drvdata(pdev, b47s);
> +
> err = mtd_device_parse_register(&b47s->mtd, probes, NULL, NULL, 0);
> if (err) {
> pr_err("Failed to register MTD device: %d\n", err);
> @@ -349,8 +350,7 @@ static int bcm47xxsflash_bcma_probe(struct platform_device *pdev)
>
> static int bcm47xxsflash_bcma_remove(struct platform_device *pdev)
> {
> - struct bcma_sflash *sflash = dev_get_platdata(&pdev->dev);
> - struct bcm47xxsflash *b47s = sflash->priv;
> + struct bcm47xxsflash *b47s = platform_get_drvdata(pdev);
>
> mtd_device_unregister(&b47s->mtd);
> iounmap(b47s->window);
> diff --git a/include/linux/bcma/bcma_driver_chipcommon.h b/include/linux/bcma/bcma_driver_chipcommon.h
> index b20e3d5..2f1c690 100644
> --- a/include/linux/bcma/bcma_driver_chipcommon.h
> +++ b/include/linux/bcma/bcma_driver_chipcommon.h
> @@ -593,9 +593,6 @@ struct bcma_sflash {
> u32 blocksize;
> u16 numblocks;
> u32 size;
> -
> - struct mtd_info *mtd;
> - void *priv;
> };
> #endif
>
^ permalink raw reply
* Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
From: Ard Biesheuvel @ 2017-02-06 9:08 UTC (permalink / raw)
To: Johannes Berg
Cc: Jouni Malinen, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, David S. Miller
In-Reply-To: <1486370872.14226.6.camel@sipsolutions.net>
On 6 February 2017 at 08:47, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> {
>> u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
>> + struct shash_desc *desc;
>> + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)]
>> CRYPTO_MINALIGN_ATTR;
I realised we have a more idiomatic SHASH_DESC_ON_STACK for this.
>> size_t i;
>> - const u8 *data[2];
>> - size_t data_len[2], data_elems;
>> +
>> + desc = (struct shash_desc *)buf;
>> + desc->tfm = tfm;
>>
>> + crypto_shash_digest(desc, (u8[AES_BLOCK_SIZE]){},
>> AES_BLOCK_SIZE, d);
>
> That's an interesting expression in there. Can we name it into a real
> variable? :)
>
Sure, if you prefer.
> I'm also slightly worried about stack usage now - do we know none of
> this goes into an sg list eventually?
>
Shashes do not usually use scatterlists: the shash API does not use
them, but uses u8[] arrays and lengths everywhere, and shashes are
explicitly synchronous, which means they are unsuitable for being
exposed on top of a high latency peripheral that uses DMA.
^ permalink raw reply
* Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
From: Johannes Berg @ 2017-02-06 9:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: Jouni Malinen, linux-wireless, Ard Biesheuvel
In-Reply-To: <20170206090039.GA9467@gondor.apana.org.au>
> The type and mask are used as follows when checking an algorithm:
>
> alg->type & mask == type & mask
>
> So to request a synchronous algorithm (that is, one with the
> CRYPTO_ALG_ASYNC bit set to zero), you would set type to 0 and
> mask to CRYPTO_ALG_ASYNC.
Ah. Ok, that makes sense, thanks for the explanation.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
From: Herbert Xu @ 2017-02-06 9:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jouni Malinen, linux-wireless, Ard Biesheuvel
In-Reply-To: <1486364077.14226.1.camel@sipsolutions.net>
On Mon, Feb 06, 2017 at 07:54:37AM +0100, Johannes Berg wrote:
> Hi,
>
> > The skcipher could have been of the async variant which may return
> > from skcipher_encrypt() with -EINPROGRESS after having queued the
> > request.
> > The FILS AEAD implementation here does not have code for dealing with
> > that possibility, so allocate a sync cipher explicitly to avoid
> > potential issues with hardware accelerators.
>
> > - tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, 0);
> > + tfm2 = crypto_alloc_skcipher("ctr(aes)", 0,
> > CRYPTO_ALG_ASYNC);
>
> I'll apply this, after having found some code elsewhere that does
> something similar, but I'll note that this is super confusing, since
> the only documentation mentioning this flag says:
>
> The mask flag restricts the type of cipher. The only allowed flag is
> CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
> asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.
The type and mask are used as follows when checking an algorithm:
alg->type & mask == type & mask
So to request a synchronous algorithm (that is, one with the
CRYPTO_ALG_ASYNC bit set to zero), you would set type to 0 and
mask to CRYPTO_ALG_ASYNC.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher
From: Johannes Berg @ 2017-02-06 8:47 UTC (permalink / raw)
To: Ard Biesheuvel, jouni, linux-wireless; +Cc: netdev, davem
In-Reply-To: <1486308208-3252-2-git-send-email-ard.biesheuvel@linaro.org>
> {
> u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
> + struct shash_desc *desc;
> + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)]
> CRYPTO_MINALIGN_ATTR;
> size_t i;
> - const u8 *data[2];
> - size_t data_len[2], data_elems;
> +
> + desc = (struct shash_desc *)buf;
> + desc->tfm = tfm;
>
> + crypto_shash_digest(desc, (u8[AES_BLOCK_SIZE]){},
> AES_BLOCK_SIZE, d);
That's an interesting expression in there. Can we name it into a real
variable? :)
I'm also slightly worried about stack usage now - do we know none of
this goes into an sg list eventually?
johannes
^ permalink raw reply
* pull-request: mac80211 2017-02-06
From: Johannes Berg @ 2017-02-06 8:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
I know it's super late, but I was travelling last week and the
whole FILS AEAD thing only played out over the weekend anyway.
Since the FILS code is all new in this cycle, it'd be good to
have the fixes, and the others are a bit older but still would
be good to fix sooner rather than later, I think.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 7892032cfe67f4bde6fc2ee967e45a8fbaf33756:
ip6_gre: fix ip6gre_err() invalid reads (2017-02-05 17:23:04 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-02-06
for you to fetch changes up to fd551bac4795854adaa87bad7e5136083719802b:
nl80211: Fix mesh HT operation check (2017-02-06 07:59:07 +0100)
----------------------------------------------------------------
A few simple fixes:
* fix FILS AEAD cipher usage to use the correct AAD vectors
and to use synchronous algorithms
* fix using mesh HT operation data from userspace
* fix adding mesh vendor elements to beacons & plink frames
----------------------------------------------------------------
Jouni Malinen (2):
mac80211: Fix FILS AEAD protection in Association Request frame
mac80211: Allocate a sync skcipher explicitly for FILS AEAD
Masashi Honma (1):
nl80211: Fix mesh HT operation check
Thorsten Horstmann (1):
mac80211: Fix adding of mesh vendor IEs
net/mac80211/fils_aead.c | 6 +++---
net/mac80211/mesh.c | 2 +-
net/wireless/nl80211.c | 1 +
3 files changed, 5 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH] nl80211: Fix mesh HT operation check
From: Johannes Berg @ 2017-02-06 7:00 UTC (permalink / raw)
To: Masashi Honma; +Cc: linux-wireless
In-Reply-To: <1485388573-4264-1-git-send-email-masashi.honma@gmail.com>
On Thu, 2017-01-26 at 08:56 +0900, Masashi Honma wrote:
> commit 9757235f451c27deaa88925399f070ff6fcea832 ('nl80211: correct
> checks for NL80211_MESHCONF_HT_OPMODE value') missed to mask a flag
> when replacing FILL_IN_MESH_PARAM_IF_SET with checking codes. This
> could drop the received HT operation value when called by
> nl80211_update_mesh_config().
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Fix adding of mesh vendor IEs
From: Johannes Berg @ 2017-02-06 6:57 UTC (permalink / raw)
To: Sven Eckelmann, linux-wireless
Cc: Thorsten Horstmann, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <20170203133829.3219-1-sven@narfation.org>
On Fri, 2017-02-03 at 14:38 +0100, Sven Eckelmann wrote:
> From: Thorsten Horstmann <thorsten@defutech.de>
>
> The function ieee80211_ie_split_vendor doesn't return 0 on errors.
> Instead
> it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found.
> The
> return value in mesh_add_vendor_ies must therefore be checked against
> ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
> WLAN_EID_VENDOR_SPECIFIC will be rejected.
>
> Fixes: 082ebb0c258d ("mac80211: fix mesh beacon format")
> Signed-off-by: Thorsten Horstmann <thorsten@defutech.de>
> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.
> de>
> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
> [sven@narfation.org: Add commit message]
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
I'm impressed by how many people signed this off without thinking about
a commit message ... :)
Anyway, applied.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Fix FILS AEAD protection in Association Request frame
From: Johannes Berg @ 2017-02-06 6:55 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, Ard Biesheuvel
In-Reply-To: <1486209562-23415-1-git-send-email-jouni@qca.qualcomm.com>
On Sat, 2017-02-04 at 13:59 +0200, Jouni Malinen wrote:
> Incorrect num_elem parameter value (1 vs. 5) was used in the
> aes_siv_encrypt() call. This resulted in only the first one of the
> five
> AAD vectors to SIV getting included in calculation. This does not
> protect all the contents correctly and would not interoperate with a
> standard compliant implementation.
>
> Fix this by using the correct number. A matching fix is needed in the
> AP
> side (hostapd) to get FILS authentication working properly.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Allocate a sync skcipher explicitly for FILS AEAD
From: Johannes Berg @ 2017-02-06 6:54 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, Ard Biesheuvel, Herbert Xu
In-Reply-To: <1486224522-26392-1-git-send-email-jouni@qca.qualcomm.com>
Hi,
> The skcipher could have been of the async variant which may return
> from skcipher_encrypt() with -EINPROGRESS after having queued the
> request.
> The FILS AEAD implementation here does not have code for dealing with
> that possibility, so allocate a sync cipher explicitly to avoid
> potential issues with hardware accelerators.
> - tfm2 = crypto_alloc_skcipher("ctr(aes)", 0, 0);
> + tfm2 = crypto_alloc_skcipher("ctr(aes)", 0,
> CRYPTO_ALG_ASYNC);
I'll apply this, after having found some code elsewhere that does
something similar, but I'll note that this is super confusing, since
the only documentation mentioning this flag says:
The mask flag restricts the type of cipher. The only allowed flag is
CRYPTO_ALG_ASYNC to restrict the cipher lookup function to
asynchronous ciphers. Usually, a caller provides a 0 for the mask flag.
(I have a vague feeling the first sentence was intended to be
documentation for the algorithm *implementation* specifying the flag,
and the second for a caller doing a lookup, or something strange?)
johannes
^ permalink raw reply
* Re: [PATCH v3] ath10k: Fix crash during rmmod when probe firmware fails
From: Mohammed Shafi Shajakhan @ 2017-02-06 6:02 UTC (permalink / raw)
To: Valo, Kalle
Cc: Shajakhan, Mohammed Shafi (Mohammed Shafi),
ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <871svr8d83.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
sorry for the delay
On Wed, Jan 25, 2017 at 01:46:28PM +0000, Valo, Kalle wrote:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
> > Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> >
> >> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >>
> >> This fixes the below crash when ath10k probe firmware fails,
> >> NAPI polling tries to access a rx ring resource which was never
> >> allocated, fix this by disabling NAPI right away once the probe
> >> firmware fails by calling 'ath10k_hif_stop'. Its good to note
> >> that the error is never propogated to 'ath10k_pci_probe' when
> >> ath10k_core_register fails, so calling 'ath10k_hif_stop' to cleanup
> >> PCI related things seems to be ok
> >>
> >> BUG: unable to handle kernel NULL pointer dereference at (null)
> >> IP: __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >> __ath10k_htt_rx_ring_fill_n+0x19/0x230 [ath10k_core]
> >>
> >> Call Trace:
> >>
> >> [<ffffffffa113ec62>] ath10k_htt_rx_msdu_buff_replenish+0x42/0x90
> >> [ath10k_core]
> >> [<ffffffffa113f393>] ath10k_htt_txrx_compl_task+0x433/0x17d0
> >> [ath10k_core]
> >> [<ffffffff8114406d>] ? __wake_up_common+0x4d/0x80
> >> [<ffffffff811349ec>] ? cpu_load_update+0xdc/0x150
> >> [<ffffffffa119301d>] ? ath10k_pci_read32+0xd/0x10 [ath10k_pci]
> >> [<ffffffffa1195b17>] ath10k_pci_napi_poll+0x47/0x110 [ath10k_pci]
> >> [<ffffffff817863af>] net_rx_action+0x20f/0x370
> >>
> >> Reported-by: Ben Greear <greearb@candelatech.com>
> >> Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
> >> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> > Is there an easy way to reproduce this bug? I don't see it on my x86
> > laptop with qca988x and I call rmmod all the time. I would like to test
> > this myself.
> >
> >> --- a/drivers/net/wireless/ath/ath10k/core.c
> >> +++ b/drivers/net/wireless/ath/ath10k/core.c
> >> @@ -2164,6 +2164,7 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
> >> ath10k_core_free_firmware_files(ar);
> >>
> >> err_power_down:
> >> + ath10k_hif_stop(ar);
> >> ath10k_hif_power_down(ar);
> >>
> >> return ret;
> >
> > This breaks the symmetry, we should not be calling ath10k_hif_stop() if
> > we haven't called ath10k_hif_start() from the same function. This can
> > just create a bigger mess later, for example with other bus support like
> > sdio or usb. In theory it should enough that we call
> > ath10k_hif_power_down() and pci.c does the rest correctly "behind the
> > scenes".
> >
> > I investigated this a bit and I think the real cause is that we call
> > napi_enable() from ath10k_pci_hif_power_up() and napi_disable() from
> > ath10k_pci_hif_stop(). Does anyone remember why?
> >
> > I was expecting that we would call napi_enable()/napi_disable() either
> > in ath10k_hif_power_up/down() or ath10k_hif_start()/stop(), but not
> > mixed like it's currently.
>
> So below is something I was thinking of, now napi_enable() is called
> from ath10k_hif_start() and napi_disable() from ath10k_hif_stop(). Would
> that work?
>
> --- a/drivers/net/wireless/ath/ath10k/pci.c
> +++ b/drivers/net/wireless/ath/ath10k/pci.c
> @@ -1648,6 +1648,8 @@ static int ath10k_pci_hif_start(struct ath10k *ar)
>
> ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot hif start\n");
>
> + napi_enable(&ar->napi);
> +
> ath10k_pci_irq_enable(ar);
> ath10k_pci_rx_post(ar);
>
> @@ -2532,7 +2534,6 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
> ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
> goto err_ce;
> }
> - napi_enable(&ar->napi);
>
> return 0;
>
[shafi] I think I tried this change some time back, but it had some regression
during device start up, let me check this once and get back to you.
regards,
shafi
^ permalink raw reply
* Re: Installing driver for Ubuntu 16.04 Intel(R) Wireless WiFi Link 4965AGN
From: Sedat Dilek @ 2017-02-06 6:01 UTC (permalink / raw)
To: Leopoldo; +Cc: linux-wireless
In-Reply-To: <ee13dae1-d01f-baff-a4d3-fe3e77fa85ec@leopoldosoria.com>
On Sun, Feb 5, 2017 at 6:31 PM, Leopoldo <info@leopoldosoria.com> wrote:
> Dear Sedat,
>
> Did you have the chance to have a look to this?
>
No.
If it was not clear said: I did not promise to look at it, I just said
sent the logs and people here can look at it.
- Sedat -
> Kind regards.
>
> Leopoldo
>
>
> El 16/01/17 a las 21:33, Leopoldo escribi=C3=B3:
>
> Dear Sedat,
>
> Please, find attached the requested 2 files.
>
> Thanking you invaluable collaboration.
>
> Leopoldo
>
>
> El 02/01/17 a las 20:39, Sedat Dilek escribi=C3=B3:
>
> On Mon, Jan 2, 2017 at 7:11 PM, <info@leopoldosoria.com> wrote:
>
> Dear Madam Sedat,
>
> Hehe, my family name is indeed a female first name - Sedat is male.
>
> Thank you for your answer.
>
> I already consulted Ubuntu Community but it is not so nice for a beginner
> like me. I tried several recomedations from them, but no way. So, I
> thought, it is better to ask to the source.
>
> Yes, I have the firmware you mention, but wifi doesn't work. The icon app=
ear
> in the top bar but it doesn't seem to be conected. It doesn't seach
> conections even when wifi is activated. The ligh of wifi simbol in the
> laptop lights some times but others it doesn't.
>
> It's difficult to answer without knowing anything about your hardware,
> your WLAN infrastructure and your WLAN setup on Ubuntu/xenial.
>
> It might be helpful if you attach your linux-config and dmesg output.
>
> $ cp -v /boot/config-$(uname -r) /tmp
> $ dmesg > /tmp/dmesg.txt
>
> Attach those two files from /tmp directory and people can look at this.
>
> - Sedat -
>
> Any help is welcome and I won't forget ladies next time, sorry.
>
> Thank you for your help and have a happy new year 2017 also.
>
> Regards,
> Leopoldo
>
>
>
>
> El 02-01-2017 15:06, Sedat Dilek escribi=C3=B3:
>
> On Mon, Jan 2, 2017 at 2:11 PM, <info@leopoldosoria.com> wrote:
>
> Dear Sirs,
> Which of the below drivers should I install for my Lenovo 3000 V200?
> I am runing Ubuntu 16.04
>
> Intel=C2=AE Wireless WiFi Link 4965AGN
> 2.6.24+ iwlwifi-4965-ucode-4.44.14.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.15.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.17.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.1.18.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.1.20.tgz
> 2.6.24+ iwlwifi-4965-ucode-228.57.1.21.tgz
> 2.6.28+ (?) iwlwifi-4965-ucode-228.57.2.21.tgz
> 2.6.28+ (?) iwlwifi-4965-ucode-228.57.2.23.tgz
> 2.6.28+ (?) iwlwifi-4965-ucode-228.61.2.24.tgz
>
> Ans how shoudl I proceed for intalling the right driver?
>
> Thank you
>
> [ What about the Ladies, Sir :-)? ]
>
> Happy new 2017!
>
> You need the linux-firmware [1] package.
> Normally, Ubuntu/xenial should ship it.
>
> Check if you have...
>
> /lib/firmware/iwlwifi-4965-2.ucode
>
> ...file.
>
> Not sure why you are asking or what is not working.
> AFAICS, Ubuntu should have some nice wikis explaining a WLAN setup.
> A good strategy will always be to consult your distro's help before askin=
g
> here.
>
> [3] as a gift.
>
> Regards,
> - Sedat -
>
> [1] http://packages.ubuntu.com/xenial/linux-firmware
> [2] http://packages.ubuntu.com/xenial/all/linux-firmware/filelist
> [3] http://www.catb.org/~esr/faqs/smart-questions.html
>
>
>
^ permalink raw reply
* Re: [PATCH V3 5/9] brcmfmac: pcie: store private pointer to struct brcmf_pub
From: Arend Van Spriel @ 2017-02-05 19:49 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170202213321.11591-5-zajec5@gmail.com>
On 2-2-2017 22:33, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Getting this pointer in PCIe code is not trivial and requires using
> dev_get_drvdata helper which adds extra line of code. Having access to
> this struct is useful for using generic stuff and e.g. improving logging
> messages.
It is actually by design that getting the pointer is not trivial. We
have made an effort to use struct device pointer as handle between
common and bus-specific code. So I have some reservations about the
approach in this patch series. I had a few days off so I want to look at
it in more detail tomorrow and probably give it a spin.
Regards,
Arend
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 6fae4cf3f6ab..8a3c6e2e4b38 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -265,6 +265,7 @@ struct brcmf_pciedev_info {
> void (*write_ptr)(struct brcmf_pciedev_info *devinfo, u32 mem_offset,
> u16 value);
> struct brcmf_mp_device *settings;
> + struct brcmf_pub *pub;
> };
>
> struct brcmf_pcie_ringbuf {
> @@ -1564,14 +1565,18 @@ static void brcmf_pcie_release_resource(struct brcmf_pciedev_info *devinfo)
>
> static int brcmf_pcie_attach_bus(struct brcmf_pciedev_info *devinfo)
> {
> + struct device *dev = &devinfo->pdev->dev;
> + struct brcmf_bus *bus = dev_get_drvdata(dev);
> int ret;
>
> /* Attach to the common driver interface */
> - ret = brcmf_attach(&devinfo->pdev->dev, devinfo->settings);
> + ret = brcmf_attach(dev, devinfo->settings);
> if (ret) {
> brcmf_err("brcmf_attach failed\n");
> } else {
> - ret = brcmf_bus_started(&devinfo->pdev->dev);
> + devinfo->pub = bus->drvr;
> +
> + ret = brcmf_bus_started(dev);
> if (ret)
> brcmf_err("dongle is not responding\n");
> }
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox