* Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties
From: Rafał Miłecki @ 2016-12-30 21:37 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Martin Blumenstingl,
Felix Fietkau, Arnd Bergmann, devicetree@vger.kernel.org,
Rafał Miłecki
In-Reply-To: <86a22b00-1a04-25e7-9d31-2c1fd9d04e48@broadcom.com>
On 30 December 2016 at 21:20, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 29-12-16 10:43, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 29 December 2016 at 09:57, Arend van Spriel
>> <arend.vanspriel@broadcom.com> wrote:
>>> On 28-12-16 22:30, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>> On 28 December 2016 at 22:28, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.co=
m> wrote:
>>>>> On 28 December 2016 at 22:07, Arend van Spriel
>>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>> On 28-12-16 16:59, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>>>
>>>>>>> They allow specifying hardware limitations of supported channels. T=
his
>>>>>>> may be useful for specifying single band devices or devices that su=
pport
>>>>>>> only some part of the whole band.
>>>>>>> E.g. some tri-band routers have separated radios for lower and high=
er
>>>>>>> part of 5 GHz band.
>>>>>>>
>>>>>>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>>>> ---
>>>>>>> net/wireless/reg.c | 34 ++++++++++++++++++++++++++++++++++
>>>>>>> 1 file changed, 34 insertions(+)
>>>>>>>
>>>>>>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>>>>>>> index 5dbac37..35ba5c7 100644
>>>>>>> --- a/net/wireless/reg.c
>>>>>>> +++ b/net/wireless/reg.c
>>>>>>> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum nl80211_=
reg_initiator initiator)
>>>>>>> }
>>>>>>> EXPORT_SYMBOL(reg_initiator_name);
>>>>>>>
>>>>>>> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
>>>>>>> + struct ieee80211_channel *chan)
>>>>>>> +{
>>>>>>> + struct device_node *np =3D wiphy_dev(wiphy)->of_node;
>>>>>>> + u32 val;
>>>>>>> +
>>>>>>> + if (!np)
>>>>>>> + return true;
>>>>>>> +
>>>>>>> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", &v=
al) &&
>>>>>>> + chan->center_freq < KHZ_TO_MHZ(val))
>>>>>>> + return false;
>>>>>>> +
>>>>>>> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", &v=
al) &&
>>>>>>> + chan->center_freq > KHZ_TO_MHZ(val))
>>>>>>> + return false;
>>>>>>
>>>>>> I suspect these functions rely on CONFIG_OF. So might not build for
>>>>>> !CONFIG_OF.
>>>>>
>>>>> I compiled it with
>>>>> # CONFIG_OF is not set
>>>>>
>>>>> Can you test it and provide a non-working config if you see a
>>>>> compilation error, please?
>>>>
>>>> include/linux/of.h provides a lot of dummy static inline functions if
>>>> CONFIG_OF is not used (they also allow compiler to drop most of the
>>>> code).
>>>
>>> of_propeirty_read_u32 is static inline in of.h calling
>>> of_property_read_u32_array, which has a dummy variant in of.h returning
>>> -ENOSYS so -38. Pretty sure that is not what you want. At least it does
>>> not allow the compiler to drop any code so probably better to do:
>>>
>>> if (!IS_ENABLED(CONFIG_OF) || !np)
>>> return true;
>>
>> Please verify that using a compiler. If there is a problem I'll be
>> happy to work on it, but I need a proof it exists.
>
> I am on vacation right now so not having much more than email and web
> browser to use as review reference.
>
>> If compilers sees a:
>> if (!-ENOSYS && chan->center_freq < KHZ_TO_MHZ(val))
>> condition, it's pretty clear it can be dropped. With both conditional
>> blocks dropped function always returns "true" and... can be dropped.
>>
>> Let me see if I can convince you with the following test:
>
> No need to convince me. I made a mistake reviewing the code. Thanks for
> clarifying it.
>
>> $ grep -m 1 CONFIG_OF .config
>> # CONFIG_OF is not set
>> $ objdump --syms net/wireless/reg.o | grep -c reg_center_freq_of_valid
>> 0
>>
>> $ grep -m 1 CONFIG_OF .config
>> CONFIG_OF=3Dy
>> $ objdump --syms net/wireless/reg.o | grep -c reg_center_freq_of_valid
>> 1
>>
>>
>>> So with this patch you change the channel to DISABLED. I am not very
>>> familiar with reg.c so do you know if this is done before or after
>>> calling regulatory notifier in the driver. brcmfmac will enable channel=
s
>>> querying the device upon regulatory notifier call, which may undo the
>>> behavior introduced by your patch.
>>
>> I'm not regulatory export, so I hope someone will review this patch.
>> So far I can say it works for me after trying it on SR400ac with
>> BCM43602.
>
> But you probably do not have a mapping table for mapping country code
> received in notifier to firmware regulatory code/revision. Only if you
> have that, brcmfmac will update the channels in the bands.
Thanks, I'll redo my tests.
> Giving this some more consideration I am not sure if this is the proper
> place to handle this. ieee80211-(min|max)-center-freq is platform
> specific configuration allowing multiple cards to be used in different
> (sub)bands. This has nothing to do with regulatory. So probably better
> to move it to core.c or chan.c.
I can see point in this, I'll see if I can put this code in a more
proper place. Thanks for your comment!
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: reg: support ieee80211-(min|max)-center-freq DT properties
From: Arend van Spriel @ 2016-12-30 20:20 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Martin Blumenstingl,
Felix Fietkau, Arnd Bergmann, devicetree@vger.kernel.org,
Rafał Miłecki
In-Reply-To: <CACna6rwaUWEjpBdfXS6uJSxKXH_mCP7YMGd1KaJropNQgVS7PA@mail.gmail.com>
On 29-12-16 10:43, Rafał Miłecki wrote:
> On 29 December 2016 at 09:57, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 28-12-16 22:30, Rafał Miłecki wrote:
>>> On 28 December 2016 at 22:28, Rafał Miłecki <zajec5@gmail.com> wrote:
>>>> On 28 December 2016 at 22:07, Arend van Spriel
>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>> On 28-12-16 16:59, Rafał Miłecki wrote:
>>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>>
>>>>>> They allow specifying hardware limitations of supported channels. This
>>>>>> may be useful for specifying single band devices or devices that support
>>>>>> only some part of the whole band.
>>>>>> E.g. some tri-band routers have separated radios for lower and higher
>>>>>> part of 5 GHz band.
>>>>>>
>>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>>>> ---
>>>>>> net/wireless/reg.c | 34 ++++++++++++++++++++++++++++++++++
>>>>>> 1 file changed, 34 insertions(+)
>>>>>>
>>>>>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>>>>>> index 5dbac37..35ba5c7 100644
>>>>>> --- a/net/wireless/reg.c
>>>>>> +++ b/net/wireless/reg.c
>>>>>> @@ -1123,6 +1123,26 @@ const char *reg_initiator_name(enum nl80211_reg_initiator initiator)
>>>>>> }
>>>>>> EXPORT_SYMBOL(reg_initiator_name);
>>>>>>
>>>>>> +static bool reg_center_freq_of_valid(struct wiphy *wiphy,
>>>>>> + struct ieee80211_channel *chan)
>>>>>> +{
>>>>>> + struct device_node *np = wiphy_dev(wiphy)->of_node;
>>>>>> + u32 val;
>>>>>> +
>>>>>> + if (!np)
>>>>>> + return true;
>>>>>> +
>>>>>> + if (!of_property_read_u32(np, "ieee80211-min-center-freq", &val) &&
>>>>>> + chan->center_freq < KHZ_TO_MHZ(val))
>>>>>> + return false;
>>>>>> +
>>>>>> + if (!of_property_read_u32(np, "ieee80211-max-center-freq", &val) &&
>>>>>> + chan->center_freq > KHZ_TO_MHZ(val))
>>>>>> + return false;
>>>>>
>>>>> I suspect these functions rely on CONFIG_OF. So might not build for
>>>>> !CONFIG_OF.
>>>>
>>>> I compiled it with
>>>> # CONFIG_OF is not set
>>>>
>>>> Can you test it and provide a non-working config if you see a
>>>> compilation error, please?
>>>
>>> include/linux/of.h provides a lot of dummy static inline functions if
>>> CONFIG_OF is not used (they also allow compiler to drop most of the
>>> code).
>>
>> of_propeirty_read_u32 is static inline in of.h calling
>> of_property_read_u32_array, which has a dummy variant in of.h returning
>> -ENOSYS so -38. Pretty sure that is not what you want. At least it does
>> not allow the compiler to drop any code so probably better to do:
>>
>> if (!IS_ENABLED(CONFIG_OF) || !np)
>> return true;
>
> Please verify that using a compiler. If there is a problem I'll be
> happy to work on it, but I need a proof it exists.
I am on vacation right now so not having much more than email and web
browser to use as review reference.
> If compilers sees a:
> if (!-ENOSYS && chan->center_freq < KHZ_TO_MHZ(val))
> condition, it's pretty clear it can be dropped. With both conditional
> blocks dropped function always returns "true" and... can be dropped.
>
> Let me see if I can convince you with the following test:
No need to convince me. I made a mistake reviewing the code. Thanks for
clarifying it.
> $ grep -m 1 CONFIG_OF .config
> # CONFIG_OF is not set
> $ objdump --syms net/wireless/reg.o | grep -c reg_center_freq_of_valid
> 0
>
> $ grep -m 1 CONFIG_OF .config
> CONFIG_OF=y
> $ objdump --syms net/wireless/reg.o | grep -c reg_center_freq_of_valid
> 1
>
>
>> So with this patch you change the channel to DISABLED. I am not very
>> familiar with reg.c so do you know if this is done before or after
>> calling regulatory notifier in the driver. brcmfmac will enable channels
>> querying the device upon regulatory notifier call, which may undo the
>> behavior introduced by your patch.
>
> I'm not regulatory export, so I hope someone will review this patch.
> So far I can say it works for me after trying it on SR400ac with
> BCM43602.
But you probably do not have a mapping table for mapping country code
received in notifier to firmware regulatory code/revision. Only if you
have that, brcmfmac will update the channels in the bands.
Giving this some more consideration I am not sure if this is the proper
place to handle this. ieee80211-(min|max)-center-freq is platform
specific configuration allowing multiple cards to be used in different
(sub)bands. This has nothing to do with regulatory. So probably better
to move it to core.c or chan.c.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] cfg80211: Random local address for Public Action frame exchange
From: IgorMitsyanko @ 2016-12-30 19:55 UTC (permalink / raw)
To: jouni, Johannes Berg; +Cc: linux-wireless, vamsin
In-Reply-To: <1482266379-9723-1-git-send-email-jouni@qca.qualcomm.com>
On 12/20/2016 11:39 PM, Jouni Malinen wrote:
> From: vamsi krishna <vamsin-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
>
> Add support to use random local address (Address 2 = SA in transmit and
> the same address in receive functionality) for Public Action frames in
> order to improve privacy of WLAN clients. Applications fill the random
> source address in the frame buffer along with setting the
> NL80211_ATTR_RANDOM_SA flag when using the NL80211_CMD_FRAME command.
> This can be used only with the drivers that indicate support for random
> local address by setting the new NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA
> and/or NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA_CONNECTED in ext_features.
>
> The driver needs to configure receive behavior to accept frames to the
> specified random address during the time the frame exchange is pending
> and such frames need to be acknowledged similarly to frames sent to the
> local permanent address when this random address functionality is not
> used.
A (probably) silly question: how wireless drivers are supposed to use SA
in a frame? I think drivers are not concerned about source address, they
simply pass whatever there is already set by userspace in
cfg80211_mgmt_tx_params::buf into air on Tx.
And on Rx, they filter frames based on receiver address/BSSID, pass it
to upper layers and do not care what address is in DA (it is handled by
upper layers).
What can we use random_sa flag introduced in this patch for then?
>
> Signed-off-by: vamsi krishna <vamsin-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
> Signed-off-by: Jouni Malinen <jouni-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
> ---
> include/net/cfg80211.h | 6 ++++++
> include/uapi/linux/nl80211.h | 16 ++++++++++++++++
> net/wireless/mlme.c | 5 ++++-
> net/wireless/nl80211.c | 14 ++++++++++++++
> 4 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ca2ac1c..c442e4c 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2303,6 +2303,11 @@ struct cfg80211_update_ft_ies_params {
> * @dont_wait_for_ack: tells the low level not to wait for an ack
> * @n_csa_offsets: length of csa_offsets array
> * @csa_offsets: array of all the csa offsets in the frame
> + * @random_sa: indicates whether the source address is randomized. When this is
> + * true, the driver needs to transmit the management frame using the
> + * address specified in the SA field (Address 2) in the buffer and the
> + * driver needs to receive and acknowledge the response frame to this
> + * address instead of its permanent MAC address.
> */
> struct cfg80211_mgmt_tx_params {
> struct ieee80211_channel *chan;
> @@ -2314,6 +2319,7 @@ struct cfg80211_mgmt_tx_params {
> bool dont_wait_for_ack;
> int n_csa_offsets;
> const u16 *csa_offsets;
> + bool random_sa;
> };
>
> /**
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index d74e10b..cffc117 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -567,6 +567,9 @@
> * %NL80211_ATTR_CSA_C_OFFSETS_TX is an array of offsets to CSA
> * counters which will be updated to the current value. This attribute
> * is used during CSA period.
> + * When sending a Public Action frame, %NL80211_ATTR_MGMT_TX_RANDOM_SA can
> + * be used to indicate that random local address (SA) is used for the
> + * exchange.
> * @NL80211_CMD_FRAME_WAIT_CANCEL: When an off-channel TX was requested, this
> * command may be used with the corresponding cookie to cancel the wait
> * time if it is known that it is no longer necessary.
> @@ -1915,6 +1918,11 @@ enum nl80211_commands {
> * %NL80211_ATTR_IFTYPE, %NL80211_ATTR_EXT_CAPA,
> * %NL80211_ATTR_EXT_CAPA_MASK, to specify the extended capabilities per
> * interface type.
> + * @NL80211_ATTR_MGMT_TX_RANDOM_SA: A flag attribute indicating whether the
> + * source address is randomized in frames sent using %NL80211_CMD_FRAME.
> + * If this flag is not set, the source address field is verified to match
> + * local MAC address. Random SA can be used only with Public Action frames
> + * (e.g., GAS/ANQP).
> *
> * @NL80211_ATTR_MU_MIMO_GROUP_DATA: array of 24 bytes that defines a MU-MIMO
> * groupID for monitor mode.
> @@ -2386,6 +2394,8 @@ enum nl80211_attrs {
>
> NL80211_ATTR_BSSID,
>
> + NL80211_ATTR_MGMT_TX_RANDOM_SA,
> +
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> @@ -4697,6 +4707,10 @@ enum nl80211_feature_flags {
> * configuration (AP/mesh) with VHT rates.
> * @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
> * with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
> + * @NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA: This driver supports randomized SA
> + * in @NL80211_CMD_FRAME while not associated.
> + * @NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA_CONNECTED: This driver supports
> + * randomized SA in @NL80211_CMD_FRAME while associated.
> *
> * @NUM_NL80211_EXT_FEATURES: number of extended features.
> * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
> @@ -4712,6 +4726,8 @@ enum nl80211_ext_feature_index {
> NL80211_EXT_FEATURE_BEACON_RATE_HT,
> NL80211_EXT_FEATURE_BEACON_RATE_VHT,
> NL80211_EXT_FEATURE_FILS_STA,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA_CONNECTED,
>
> /* add new features before the definition below */
> NUM_NL80211_EXT_FEATURES,
> diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
> index 4646cf5..9568a72 100644
> --- a/net/wireless/mlme.c
> +++ b/net/wireless/mlme.c
> @@ -657,7 +657,10 @@ int cfg80211_mlme_mgmt_tx(struct cfg80211_registered_device *rdev,
> return err;
> }
>
> - if (!ether_addr_equal(mgmt->sa, wdev_address(wdev)))
> + if (!(params->random_sa &&
> + (ieee80211_is_action(mgmt->frame_control) &&
> + mgmt->u.action.category == WLAN_CATEGORY_PUBLIC)) &&
> + !ether_addr_equal(mgmt->sa, wdev_address(wdev)))
> return -EINVAL;
>
> /* Transmit the Action frame as requested by user space */
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 2369265..efced76 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -405,6 +405,7 @@ enum nl80211_multicast_groups {
> [NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
> [NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
> [NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
> + [NL80211_ATTR_MGMT_TX_RANDOM_SA] = { .type = NLA_FLAG },
> };
>
> /* policy for the key attributes */
> @@ -9209,6 +9210,19 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
> }
> }
>
> + params.random_sa = nla_get_flag(
> + info->attrs[NL80211_ATTR_MGMT_TX_RANDOM_SA]);
> + if (params.random_sa &&
> + ((!wdev->current_bss &&
> + !wiphy_ext_feature_isset(
> + &rdev->wiphy,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA)) ||
> + (wdev->current_bss &&
> + !wiphy_ext_feature_isset(
> + &rdev->wiphy,
> + NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA_CONNECTED))))
> + return -EINVAL;
> +
> if (!params.dont_wait_for_ack) {
> msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> if (!msg)
>
^ permalink raw reply
* [PATCH] mac80211: Fix invalid 'info' access in xmit-fast.
From: greearb @ 2016-12-30 18:49 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Ben Greear
From: Ben Greear <greearb@candelatech.com>
ieee80211_xmit_fast assigns info from the passed-in
skb, but then later it also checks for skb_shared(skb),
and may create a new skb based on that check.
But, the code did not re-assign 'info', so it pointed into
the old shared skb. This leads to all sorts of problems,
most obviously crashes since the new skb's info->hw_queue is not
properly initialized.
Bug was seen by sending pktgen packets on a bridge that
had an AP network interface in it. hw-queue was out of
range, which made it crash like this:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffffa0ad4672>] ieee80211_tx_frags+0x232/0x4c0 [mac80211]
PGD 0
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 1512 Comm: kpktgend_0 Tainted: G O 4.7.10+ #24
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
task: ffff8802132f3a00 ti: ffff8800362ac000 task.ti: ffff8800362ac000
RIP: 0010:[<ffffffffa0ad4672>] [<ffffffffa0ad4672>] ieee80211_tx_frags+0x232/0x4c0 [mac80211]
RSP: 0018:ffff8800362afa28 EFLAGS: 00010086
RAX: ffff8802130a22c0 RBX: ffff8802130a13a0 RCX: ffff880035ef2200
RDX: ffff880035ef2200 RSI: 0000000000000292 RDI: 0000000000000000
RBP: ffff8800362afa90 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000088 R11: 0000000000000001 R12: ffff880035ef2200
R13: ffff880035dabb90 R14: ffff8800362afb18 R15: 0000000000000cc0
FS: 0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000001e06000 CR4: 00000000001406f0
Stack:
0000000000000292 ffff880035daa880 ffff8802130a0b20 ffff8800d4f01808
00ff8800362afaa0 ffff8800362afb18 ffff8802130a13c0 ffff88021e20db68
ffff880035daa880 ffff8800362afb18 ffff880035ef2200 ffff88020f6ca300
Call Trace:
[<ffffffffa0ad9f63>] __ieee80211_subif_start_xmit+0xc13/0xc30 [mac80211]
[<ffffffff8113d2c5>] ? find_busiest_group+0x35/0x4a0
[<ffffffffa0ad9f8b>] ieee80211_subif_start_xmit+0xb/0x10 [mac80211]
[<ffffffff8177d40b>] dev_hard_start_xmit+0x9b/0x220
[<ffffffff817a3716>] sch_direct_xmit+0xd6/0x1a0
[<ffffffff8177da8e>] __dev_queue_xmit+0x3be/0x6c0
[<ffffffff81127f43>] ? finish_task_switch+0x73/0x1f0
[<ffffffff8177dd9d>] dev_queue_xmit+0xd/0x10
[<ffffffffa0b5fe85>] br_dev_queue_push_xmit+0x75/0x140 [bridge]
[<ffffffffa0b5ffc9>] br_forward_finish+0x29/0xa0 [bridge]
[<ffffffff8116db83>] ? del_timer_sync+0x43/0x50
[<ffffffffa0b600a2>] __br_deliver+0x62/0x130 [bridge]
[<ffffffff81175937>] ? __getnstimeofday64+0x37/0xd0
[<ffffffff811759d9>] ? getnstimeofday64+0x9/0x30
[<ffffffffa0b605b6>] br_deliver+0x56/0x60 [bridge]
[<ffffffffa0b5d472>] br_dev_xmit+0x1c2/0x250 [bridge]
[<ffffffffa137aa1c>] pktgen_thread_worker+0x174c/0x2471 [pktgen]
[<ffffffff8185087a>] ? __schedule+0x30a/0x7c0
[<ffffffff811446e0>] ? wake_atomic_t_function+0x60/0x60
[<ffffffffa13792d0>] ? pktgen_rem_all_ifs+0x80/0x80 [pktgen]
[<ffffffff81121c14>] kthread+0xc4/0xe0
[<ffffffff818551df>] ret_from_fork+0x1f/0x40
[<ffffffff81121b50>] ? kthread_worker_fn+0x180/0x180
Fix this by re-assigning info after creating new one.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
This patch is against 4.7.10+
net/mac80211/tx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 0573ab9..3da5f94 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3081,6 +3081,7 @@ static bool ieee80211_xmit_fast(struct ieee80211_sub_if_data *sdata,
if (!skb)
return true;
+ info = IEEE80211_SKB_CB(skb);
}
ieee80211_tx_stats(dev, skb->len + extra_head);
--
2.4.11
^ permalink raw reply related
* [PATCH][V3] rtlwifi: fix spelling mistake: "encrypiton" -> "encryption"
From: Colin King @ 2016-12-30 14:50 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
trivial fix to spelling mistake in RT_TRACE message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index ded1493..732de0a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1532,7 +1532,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
key_type = AESCMAC_ENCRYPTION;
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG, "alg:CMAC\n");
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
- "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
+ "HW don't support CMAC encryption, use software CMAC encryption\n");
err = -EOPNOTSUPP;
goto out_unlock;
default:
--
2.10.2
^ permalink raw reply related
* Re: [1/2] ath10k: add accounting for the extended peer statistics
From: Valo, Kalle @ 2016-12-30 14:47 UTC (permalink / raw)
To: Christian Lamparter
Cc: Mohammed Shafi Shajakhan, linux-wireless,
ath10k@lists.infradead.org
In-Reply-To: <CAAd0S9DcCM9XQOihZx1sVf_1=S3VvDye4k1gEMgWEmNWDaBk5Q@mail.gmail.com>
Christian Lamparter <chunkeey@googlemail.com> writes:
> On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo <kvalo@qca.qualcomm.com> wrot=
e:
>> Christian Lamparter <chunkeey@googlemail.com> wrote:
>>> The 10.4 firmware adds extended peer information to the
>>> firmware's statistics payload. This additional info is
>>> stored as a separate data field and the elements are
>>> stored in their own "peers_extd" list.
>>>
>>> These elements can pile up in the same way as the peer
>>> information elements. This is because the
>>> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
>>> pull the same amount (num_peer_stats) for every statistic
>>> data unit.
>>>
>>> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
>>> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
>>
>> My understanding is that I should skip this patch 1. Please let me know =
if
>> I misunderstood. But I'm still plannning to apply patch 2.
>
> I added Mohammed (I hope, he can reply to the open question when he
> returns), Since I'm not sure what he wants or not.
>
> As far as I'm aware, the "extended" boolean serves no purpose
> because it was only used in once place in debugfs_sta which was
> removed in the patch. ( "ath10k_sta_update_stats_rx_duration"
> and "ath10k_sta_update_extd_stats_rx_duration" have been unified).
I had problems following the discussion so the conclusion was not clear
for me.
>> Patch set to Changes Requested.
>
> Isn't there a: "Waiting for Maintainer" state as well?
> Otherwise, if nobody has any complains or question:
> can you please queue it for the next merge window?
There is a state called "Deferred" which I use whenever I need to
revisit a patch later time. I moved this patch to that state now:
https://patchwork.kernel.org/patch/9461631/
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH][V2] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: Kalle Valo @ 2016-12-30 14:35 UTC (permalink / raw)
To: Colin King
Cc: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, linux-media,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20161229213815.27890-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> writes:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in err message. Also change "don't" to
> "does not".
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
> drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Could you split the rtlwifi part to it's own patch? I can't apply
patches touching media drivers.
--
Kalle Valo
^ permalink raw reply
* Re: [1/2] ath10k: add accounting for the extended peer statistics
From: Christian Lamparter @ 2016-12-30 14:35 UTC (permalink / raw)
To: Kalle Valo, Mohammed Shafi Shajakhan; +Cc: linux-wireless, ath10k
In-Reply-To: <c3f99e7634384475b475b97ff46bec76@euamsexm01a.eu.qualcomm.com>
On Thu, Dec 29, 2016 at 3:11 PM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Christian Lamparter <chunkeey@googlemail.com> wrote:
>> The 10.4 firmware adds extended peer information to the
>> firmware's statistics payload. This additional info is
>> stored as a separate data field and the elements are
>> stored in their own "peers_extd" list.
>>
>> These elements can pile up in the same way as the peer
>> information elements. This is because the
>> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
>> pull the same amount (num_peer_stats) for every statistic
>> data unit.
>>
>> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
>> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
>
> My understanding is that I should skip this patch 1. Please let me know if
> I misunderstood. But I'm still plannning to apply patch 2.
I added Mohammed (I hope, he can reply to the open question when he
returns), Since I'm not sure what he wants or not.
As far as I'm aware, the "extended" boolean serves no purpose
because it was only used in once place in debugfs_sta which was
removed in the patch. ( "ath10k_sta_update_stats_rx_duration"
and "ath10k_sta_update_extd_stats_rx_duration" have been unified).
> Patch set to Changes Requested.
Isn't there a: "Waiting for Maintainer" state as well?
Otherwise, if nobody has any complains or question:
can you please queue it for the next merge window?
Regards,
Christian
> --
> https://patchwork.kernel.org/patch/9461631/
>
> Documentation about submitting wireless patches and checking status
> from patchwork:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
^ permalink raw reply
* [PATCH] ath9k: fix spelling mistake: "meaurement" -> "measurement"
From: Colin King @ 2016-12-30 14:06 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, linux-wireless, ath9k-devel,
netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in ath_err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index a35f78b..ac36873 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -731,7 +731,7 @@ u32 ar9003_get_pll_sqsum_dvc(struct ath_hw *ah)
udelay(100);
if (WARN_ON_ONCE(i >= 100)) {
- ath_err(common, "PLL4 meaurement not done\n");
+ ath_err(common, "PLL4 measurement not done\n");
break;
}
--
2.10.2
^ permalink raw reply related
* Re: brcmfmac: fix spelling mistakes on "Ivalid"
From: Kalle Valo @ 2016-12-30 13:59 UTC (permalink / raw)
To: Colin Ian King
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel
In-Reply-To: <20161223004322.7300-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fixes to spelling mistake "Ivalid" to "Invalid" in
> brcmf_err error messages.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
ad334bbb07b0 brcmfmac: fix spelling mistakes on "Ivalid"
--
https://patchwork.kernel.org/patch/9487009/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: fix spelling mistake: "contry" -> "country"
From: Kalle Valo @ 2016-12-30 13:57 UTC (permalink / raw)
To: Colin Ian King
Cc: Larry Finger, Chaoming Li, linux-wireless, netdev, linux-kernel
In-Reply-To: <20161229160029.22117-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> trivial fix to spelling mistake in RT_TRACE message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Patch applied to wireless-drivers-next.git, thanks.
3b1fc7680a0f rtlwifi: fix spelling mistake: "contry" -> "country"
--
https://patchwork.kernel.org/patch/9491293/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: Fix alignment issues
From: Kalle Valo @ 2016-12-30 13:57 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, Larry Finger, Stable
In-Reply-To: <20161228214004.6309-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> The addresses of Wlan NIC registers are natural alignment, but some
> drivers have bugs. These are evident on platforms that need natural
> alignment to access registers. This change contains the following:
> 1. Function _rtl8821ae_dbi_read() is used to read one byte from DBI,
> thus it should use rtl_read_byte().
> 2. Register 0x4C7 of 8192ee is single byte.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
40b368af4b75 rtlwifi: Fix alignment issues
--
https://patchwork.kernel.org/patch/9490651/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: libertas: constify cfg80211_ops structures
From: Kalle Valo @ 2016-12-30 13:56 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, libertas-dev, linux-wireless, netdev, linux-kernel,
Bhumika Goyal
In-Reply-To: <1482015444-28899-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> cfg80211_ops structures are only passed as an argument to the function
> wiphy_new. This argument is of type const, so cfg80211_ops strutures
> having this property can be declared as const.
> Done using Coccinelle
>
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct cfg80211_ops i@p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> @@
> wiphy_new(&i@p,...)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct cfg80211_ops i;
>
> File size before:
> text data bss dec hex filename
> 21225 1954 16 23195 5a9b wireless/marvell/libertas/cfg.o
>
> File size after:
> text data bss dec hex filename
> 22041 1154 16 23211 5aab wireless/marvell/libertas/cfg.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
26eb994d5239 libertas: constify cfg80211_ops structures
--
https://patchwork.kernel.org/patch/9479131/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [01/14,V2] rtlwifi: Replace local debug macro RT_ASSERT
From: Kalle Valo @ 2016-12-30 13:55 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Larry Finger, Ping-Ke Shih
In-Reply-To: <20161215182310.13713-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> This macro can be replaced with WARN_ONCE. In addition to using a
> standard debugging macro for these critical errors, we also get
> a stack dump.
>
> In rtl8821ae/hw.c, a senseless comment was removed, and an incorrect
> indentation was fixed.
>
> This patch also fixes two places in each of rtl8192ee, rtl8723be,
> and rtl8821ae where the logical condition was incorrect.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
14 patches applied to wireless-drivers-next.git, thanks.
531940f9644d rtlwifi: Replace local debug macro RT_ASSERT
b03d968b6644 rtlwifi: Remove RT_TRACE messages that use DBG_EMERG
004a1e167905 rtlwifi: rtl8821ae: Remove all instances of DBG_EMERG
4e2b4378f9d7 rtlwifi: rtl8723be: Remove all instances of DBG_EMERG
a67005bc46d9 rtlwifi: rtl8723ae: Remove all instances of DBG_EMERG
a44f59d60365 rtlwifi: rtl8192ee: Remove all instances of DBG_EMERG
c7532b87653b rtlwifi: rtl8723-common: Remove all instances of DBG_EMERG
2d15acac2354 rtlwifi: rtl8192se: Remove all instances of DBG_EMERG
b8c79f454880 rtlwifi: rtl8192de: Remove all instances of DBG_EMERG
c38af3f06af4 rtlwifi: rtl8192cu: Remove all instances of DBG_EMERG
e40a005652ad rtlwifi: rtl8192ce: Remove all instances of DBG_EMERG
0fc30e9350be rtlwifi: rtl8192c-common: Remove all instances of DBG_EMERG
02527a73beb3 rtlwifi: rtl8188ee: Remove all instances of DBG_EMERG
c93ac39da006 rtlwifi: Remove some redundant code
--
https://patchwork.kernel.org/patch/9476703/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 14/14 V2] rtlwifi: Remove some redundant code
From: Kalle Valo @ 2016-12-30 13:53 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Ping-Ke Shih
In-Reply-To: <20161215182310.13713-15-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> The symbol DBG_EMERG is no longer used and is removed.
>
> In a number of places, the code has redundant messages. For example, if
> the failure for the firmware to run is logged, it is not necessary to
> log that the firmware has been started. In addition, extraneous braces are
> removed.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
[...]
> --- wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/debug.h
> +++ wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/debug.h
> @@ -36,7 +36,7 @@
> *unexpected HW behavior, HW BUG
> *and so on.
> */
> -#define DBG_EMERG 0
> +/*#define DBG_EMERG 0 */
You are not really removing, just commenting it out :) But this is good
enough for me, if you really want to remove it submit a followup patch.
--
Kalle Valo
^ permalink raw reply
* Re: rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
From: Kalle Valo @ 2016-12-30 13:39 UTC (permalink / raw)
To: Larry Finger
Cc: Linus Torvalds, devel, linux-wireless, Larry Finger, linux-kernel,
driver-devel
In-Reply-To: <20161221171855.5056-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> These drivers need to be able to reference "struct ieee80211_hw" from
> the driver's private data, and vice versa. The USB driver failed to
> store the address of ieee80211_hw in the private data. Although this
> bug has been present for a long time, it was not exposed until
> commit ba9f93f82aba ("rtlwifi: Fix enter/exit power_save").
>
> Fixes: ba9f93f82aba ("rtlwifi: Fix enter/exit power_save")
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Patch applied to wireless-drivers.git, thanks.
60f59ce02785 rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
--
https://patchwork.kernel.org/patch/9483579/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/7] rtlwifi: btcoexist: Update routines for RTL8192EE
From: Kalle Valo @ 2016-12-30 13:12 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Ping-Ke Shih, Larry Finger
In-Reply-To: <20161203173207.17774-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> The btcoexist routines for the RTL8192EE have been extensively rewritten.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Dropped per Larry's request.
7 patches set to Changes Requested.
9459709 [1/7] rtlwifi: btcoexist: Update routines for RTL8192EE
9459711 [2/7] rtlwifi: btcoexist: Rewrite halbtc8723b1ant code
9459719 [3/7] rtlwifi: btcoexist: Rewrite of halbtc8723b2ant
9459717 [4/7] rtlwifi: btcoexist: Rewrite routine halbtc8821a1ant
9459721 [5/7] rtlwifi: btcoexist: Rewrite routine halbtc8821a2ant
9459713 [6/7] rtlwifi: Add btcoex record_pwr_mode
9459715 [7/7] rtlwifi: btcoexist control to enter/leave LPS
--
https://patchwork.kernel.org/patch/9459709/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [01/14] rtlwifi: Correct power save capability while init mac80211
From: Kalle Valo @ 2016-12-30 13:10 UTC (permalink / raw)
To: Larry Finger
Cc: devel, linux-wireless, Vincent Fann, Larry Finger, shaofu,
Ping-Ke Shih
In-Reply-To: <20161202014833.6856-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Set IEEE80211_HW_SUPPORTS_PS when driver is fwlps
> Because mac80211 control SW-LPS only, we add constraints to avoid errors.
>
> Signed-off-by: Vincent Fann <vincent_fann@realtek.com>
> Signed-off-by: shaofu <shaofu@realtek.com>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Dropped per Larry's request.
14 patches set to Changes Requested.
9457587 [01/14] rtlwifi: Correct power save capability while init mac80211
9457609 [02/14] rtlwifi: Fix programing CAM content sequence.
9457607 [03/14] rtlwifi: Set retry limit depends on vif type.
9457601 [03/14] rtlwifi: extend debug_comp to u64
9457613 [05/14] rtlwifi: Add TX report and disable key will wait until report acked.
9457611 [06/14] rtlwifi: rtl8723be: btcoexist: Add single_ant_path
9457589 [07/14] rtlwifi: move btcoex's ant_num declaration
9457603 [08/14] rtlwifi: rtl8723be: btcoex: add package_type function to btcoex
9457593 [09/14] rtlwifi: ibtcoex: move bt_type declaration
9457591 [10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
9457605 [11/14] rtlwifi: Add a new enumeration value to btc_set_type
9457595 [12/14] rtlwifi: btcoexist: Add vendor definition for new btcoexist
9457597 [13/14] rtlwifi: rtl8723be: fix ant_sel code
9457599 [14/14] rtlwifi: Add work queue for c2h cmd.
--
https://patchwork.kernel.org/patch/9457587/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: net: wireless: marvell: libertas: constify cfg80211_ops structures
From: Kalle Valo @ 2016-12-30 13:02 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, libertas-dev, linux-wireless, netdev, linux-kernel,
Bhumika Goyal
In-Reply-To: <1482015444-28899-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> cfg80211_ops structures are only passed as an argument to the function
> wiphy_new. This argument is of type const, so cfg80211_ops strutures
> having this property can be declared as const.
> Done using Coccinelle
>
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct cfg80211_ops i@p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> @@
> wiphy_new(&i@p,...)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct cfg80211_ops i;
>
> File size before:
> text data bss dec hex filename
> 21225 1954 16 23195 5a9b wireless/marvell/libertas/cfg.o
>
> File size after:
> text data bss dec hex filename
> 22041 1154 16 23211 5aab wireless/marvell/libertas/cfg.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
The prefix should be "libertas:", I can fix that before I commit.
--
https://patchwork.kernel.org/patch/9479131/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: net: wireless: ath: wil6210: constify cfg80211_ops structures
From: Kalle Valo @ 2016-12-30 13:01 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, qca_merez, linux-wireless, wil6210, netdev,
linux-kernel, Bhumika Goyal
In-Reply-To: <1482014667-27082-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> cfg80211_ops structures are only passed as an argument to the function
> wiphy_new. This argument is of type const, so cfg80211_ops strutures
> having this property can be declared as const.
> Done using Coccinelle
>
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct cfg80211_ops i@p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> @@
> wiphy_new(&i@p,...)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct cfg80211_ops i;
>
> File size before:
> text data bss dec hex filename
> 18133 6632 0 24765 60bd wireless/ath/wil6210/cfg80211.o
>
> File size after:
> text data bss dec hex filename
> 18933 5832 0 24765 60bd wireless/ath/wil6210/cfg80211.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
The prefix should be "wil6210:", I can fix that before I commit this.
--
https://patchwork.kernel.org/patch/9479127/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: orinoco: Use shash instead of ahash for MIC calculations
From: Kalle Valo @ 2016-12-30 12:15 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: linux-kernel, linux-usb, linux-wireless, Eric Biggers,
linux-crypto, Herbert Xu, Stephan Mueller
In-Reply-To: <87vau1k4ka.fsf@purkki.adurom.net>
Kalle Valo <kvalo@codeaurora.org> writes:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Andrew Lutomirski <luto@kernel.org> wrote:
>>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>>> at the stack.
>>>
>>> Fix it by switching from ahash to shash. The result should be
>>> simpler, faster, and more correct.
>>>
>>> Cc: stable@vger.kernel.org # 4.9 only
>>> Reported-by: Eric Biggers <ebiggers3@gmail.com>
>>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>>
>> 11 patches applied to wireless-drivers-next.git, thanks.
>>
>> 1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
>> a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
>> e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
>> a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
>> 8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
>> 8845254112ac rt2800: rename adjust_freq_offset function
>> bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
>> 24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
>> d96324703ffa rt2x00: merge agc and vco works with link tuner
>> eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
>> 31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
>
> Oh man, when I was applying rt2800 patches I did an off by one error
> with my patchwork script ('commit 2-12' vs 'commit 1-11') and
> accidentally applied this orinoco patch to wireless-drivers-next along
> with the 10 rt2800 patches above. And failed to spot that before pushing
> the tree :(
>
> As this orinoco patch is pretty important I'll cherry pick it manually
> to wireless-drivers also so that it goes to 4.10. This means that the
> patch is in both trees, but just with a different commit id.
This is the commit in wireless-drivers:
commit 570b90fa230b8021f51a67fab2245fe8df6fe37d
Author: Andrew Lutomirski <luto@kernel.org>
Date: Mon Dec 12 12:55:55 2016 -0800
orinoco: Use shash instead of ahash for MIC calculations
Eric Biggers pointed out that the orinoco driver pointed
scatterlists
at the stack.
Fix it by switching from ahash to shash. The result should be
simpler, faster, and more correct.
kvalo: cherry picked from commit
1fef293b8a9850cfa124a53c1d8878d355010403 as I
accidentally applied this patch to wireless-drivers-next when I was
supposed to
apply this wireless-drivers
Cc: stable@vger.kernel.org # 4.9 only
Reported-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 01/11] rt2800: make rx ampdu_factor depend on number of rx chains
From: Kalle Valo @ 2016-12-30 12:08 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa
In-Reply-To: <1482144777-16760-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> writes:
> Initalize max ampdu_factor supported by us based on rx chains, vendor
> driver do the same.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
When I was applying these patches I did an off by one error with my
patchwork script ('commit 2-12' vs 'commit 1-11') and accidentally
applied an orinoco patch to wireless-drivers-next along with these
rt2800 patches 1-10. I applied patch 11 separately and everything should
be in wireless-drivers-next now (as soon as I push it). But I would
appreciate if you could double check that everything is ok.
Sorry for the mess.
a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
8845254112ac rt2800: rename adjust_freq_offset function
bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
d96324703ffa rt2x00: merge agc and vco works with link tuner
eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
--
Kalle Valo
^ permalink raw reply
* Re: [11/11] rt2x00: add mutex to synchronize config and link tuner
From: Kalle Valo @ 2016-12-30 12:04 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Stanislaw Gruszka
In-Reply-To: <1482144777-16760-12-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Do not perform mac80211 config and link_tuner at the same time,
> this can possibly result in wrong RF or BBP configuration.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
c7d1c77781f4 rt2x00: add mutex to synchronize config and link tuner
--
https://patchwork.kernel.org/patch/9480071/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: orinoco: Use shash instead of ahash for MIC calculations
From: Kalle Valo @ 2016-12-30 12:02 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: linux-kernel, linux-usb, linux-wireless, Eric Biggers,
linux-crypto, Herbert Xu, Stephan Mueller
In-Reply-To: <20161230113451.C10ED614E4@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Andrew Lutomirski <luto@kernel.org> wrote:
>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>> at the stack.
>>
>> Fix it by switching from ahash to shash. The result should be
>> simpler, faster, and more correct.
>>
>> Cc: stable@vger.kernel.org # 4.9 only
>> Reported-by: Eric Biggers <ebiggers3@gmail.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>
> 11 patches applied to wireless-drivers-next.git, thanks.
>
> 1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
> a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
> e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
> a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
> 8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
> 8845254112ac rt2800: rename adjust_freq_offset function
> bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
> 24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
> d96324703ffa rt2x00: merge agc and vco works with link tuner
> eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
> 31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
Oh man, when I was applying rt2800 patches I did an off by one error
with my patchwork script ('commit 2-12' vs 'commit 1-11') and
accidentally applied this orinoco patch to wireless-drivers-next along
with the 10 rt2800 patches above. And failed to spot that before pushing
the tree :(
As this orinoco patch is pretty important I'll cherry pick it manually
to wireless-drivers also so that it goes to 4.10. This means that the
patch is in both trees, but just with a different commit id.
Sorry for the mess.
--
Kalle Valo
^ permalink raw reply
* Re: orinoco: Use shash instead of ahash for MIC calculations
From: Kalle Valo @ 2016-12-30 11:34 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: linux-kernel, linux-usb, linux-wireless, Eric Biggers,
linux-crypto, Herbert Xu, Stephan Mueller, Andy Lutomirski
In-Reply-To: <8818c45b9ec6a04d85fabf9bb437cf119fd23659.1481575835.git.luto@kernel.org>
Andrew Lutomirski <luto@kernel.org> wrote:
> Eric Biggers pointed out that the orinoco driver pointed scatterlists
> at the stack.
>
> Fix it by switching from ahash to shash. The result should be
> simpler, faster, and more correct.
>
> Cc: stable@vger.kernel.org # 4.9 only
> Reported-by: Eric Biggers <ebiggers3@gmail.com>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
11 patches applied to wireless-drivers-next.git, thanks.
1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
8845254112ac rt2800: rename adjust_freq_offset function
bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
d96324703ffa rt2x00: merge agc and vco works with link tuner
eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
--
https://patchwork.kernel.org/patch/9471353/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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