* Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload
From: Johannes Berg @ 2016-12-15 9:16 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1481781608-5181-2-git-send-email-vthiagar@qti.qualcomm.com>
> Drivers advertising this capability should also implement other
> functionalities which deal with 802.11 frame format like below
> - ADDBA/DELBA offload
This shouldn't be necessary.
> - Hardware rate control
Neither is this, if we find some API to do sampling. The existing rate
table API already allows setting the rates out of band, so the only
thing that you'd have to support out of band is sampling.
> - Powersave offload
That's ambiguous - you do need to handle sleeping stations (and PS-
Poll/U-APSD) in AP mode in the device with this, but I don't see a deep
technical reason to require it for client mode. OTOH, client mode is
almost always offloaded anyway.
I think you may have forgotten one important item,
- control port handling
?
> + * @IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP: Hardware/driver
> supports 802.11
> + * encap/decap for data frames. Supporting driver have to
> implement
> + * get_vif_80211_encap_decap_offload() to pass if 802.11
> encap/decap
> + * offload is supported for the vif.
I don't see why you need this, when you have the method - you can just
assume that the method returns false when it's not implemented.
> struct ieee80211_ops {
> void (*tx)(struct ieee80211_hw *hw,
> @@ -3639,6 +3651,10 @@ struct ieee80211_ops {
> void (*wake_tx_queue)(struct ieee80211_hw *hw,
> struct ieee80211_txq *txq);
> void (*sync_rx_queues)(struct ieee80211_hw *hw);
> +
> + int (*get_vif_80211_hdr_offload)(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + bool is_4addr, bool
> *supported);
Why are you not simply returning "supported"?
I don't like passing the vif pointer here. At this point, the vif
pointer isn't known to the driver yet (through drv_add_interface) so
it's a dead pointer as far as the sequencing is concerned.
Is there a possibility that drivers need to switch off ethernet format
handling entirely when an incompatible interface is added? For example,
if you add a mesh interface, is there a chance that the AP interface
might no longer be able to handle this?
I'd hope this doesn't happen because I think that would be extremely
complicated to handle safely.
johannes
^ permalink raw reply
* Re: ath10k: Avoid potential page alloc BUG_ON in tx free path
From: Kalle Valo @ 2016-12-15 9:18 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1481086832-17281-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc'
> have NULL pointer checks to avoid crash if they are called twice
> but this is as of now not sufficient as these pointers are not assigned
> to NULL once the contiguous DMA memory allocation is freed, fix this.
> Though this may not be hit with the explicity check of state variable
> 'tx_mem_allocated' check, good to have this addressed as well.
>
> Below BUG_ON is hit when the above scenario is simulated
> with kernel debugging enabled
>
> page:f6d09a00 count:0 mapcount:-127 mapping: (null)
> index:0x0
> flags: 0x40000000()
> page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)
> == 0)
> ------------[ cut here ]------------
> kernel BUG at ./include/linux/mm.h:445!
> invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
> EIP is at put_page_testzero.part.88+0xd/0xf
> Call Trace:
> [<c118a2cc>] __free_pages+0x3c/0x40
> [<c118a30e>] free_pages+0x3e/0x50
> [<c10222b4>] dma_generic_free_coherent+0x24/0x30
> [<f8c1d9a8>] ath10k_htt_tx_free_cont_txbuf+0xf8/0x140
>
> [<f8c1e2a9>] ath10k_htt_tx_destroy+0x29/0xa0
>
> [<f8c143e0>] ath10k_core_destroy+0x60/0x80 [ath10k_core]
> [<f8acd7e9>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
> [<c13ed7a8>] pci_device_remove+0x38/0xb0
> [<c14d3492>] __device_release_driver+0x72/0x100
> [<c14d36b7>] driver_detach+0x97/0xa0
> [<c14d29c0>] bus_remove_driver+0x40/0x80
> [<c14d427a>] driver_unregister+0x2a/0x60
> [<c13ec768>] pci_unregister_driver+0x18/0x70
> [<f8aced4f>] ath10k_pci_exit+0xd/0x2be [ath10k_pci]
> [<c1101e78>] SyS_delete_module+0x158/0x210
> [<c11b34f1>] ? __might_fault+0x41/0xa0
> [<c11b353b>] ? __might_fault+0x8b/0xa0
> [<c1001a4b>] do_fast_syscall_32+0x9b/0x1c0
> [<c178da34>] sysenter_past_esp+0x45/0x74
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
02a9e08d7374 ath10k: Avoid potential page alloc BUG_ON in tx free path
--
https://patchwork.kernel.org/patch/9463923/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
From: Johannes Berg @ 2016-12-15 9:29 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1481781608-5181-3-git-send-email-vthiagar@qti.qualcomm.com>
> There is a field, no_80211_encap, added to ieee80211_tx_info:control
> to mark if the 802.11 encapsulation is offloaded to driver.
> There is also a new callback for tx completion status indication
> to handle data frames using 802.11 encap offload.
I'm not sure I see the need for this? Maybe I'll find out in this patch
:)
> + /* XXX: This frame is not encaptulated with
> 802.11
> + * header. Should this be added to
> %IEEE80211_TX_CTRL_*
> + * flags?.
> + */
> + bool no_80211_encap;
> + /* 3 bytes free */
> } control;
probably - just to preserve more space.
> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
> + * implementing 802.11 encap/decap for data frames changed.
> */
> enum ieee80211_conf_changed {
> IEEE80211_CONF_CHANGE_SMPS = BIT(1),
> @@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
> IEEE80211_CONF_CHANGE_CHANNEL = BIT(6),
> IEEE80211_CONF_CHANGE_RETRY_LIMITS = BIT(7),
> IEEE80211_CONF_CHANGE_IDLE = BIT(8),
> + IEEE80211_CONF_CHANGE_80211_HDR_OFFL = BIT(9),
> };
Given the requirements (PN check, etc.) I'm not sure how this can
change dynamically?
> + * @encap_decap_80211_offloaded: Whether 802.11 header encap/decap
> offload
> + * is enabled
> */
> struct ieee80211_conf {
> u32 flags;
> @@ -1346,6 +1357,7 @@ struct ieee80211_conf {
> struct cfg80211_chan_def chandef;
> bool radar_enabled;
> enum ieee80211_smps_mode smps_mode;
> + bool encap_decap_80211_offloaded;
Please don't add anything here that's interface specific.
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -107,6 +107,10 @@ static int ieee80211_change_iface(struct wiphy
> *wiphy,
> }
> }
>
> + ieee80211_if_check_80211_hdr_offl(sdata,
> + params ? params->use_4addr
> : false,
> + true);
> +
> return 0;
> }
Wouldn't it be better to simply prohibit changing this while the
interface is up, and re-init it later when it goes up?
> +++ b/net/mac80211/ieee80211_i.h
> @@ -1373,6 +1373,8 @@ struct ieee80211_local {
> /* TDLS channel switch */
> struct work_struct tdls_chsw_work;
> struct sk_buff_head skb_queue_tdls_chsw;
> +
> + bool data_80211_hdr_offloaded;
Again, don't put interface specific things into device structures.
> +int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
> + struct sk_buff *skb,
> + struct sta_info **sta_out);
Return the sta_info pointer, and ERR_PTR() if needed.
> +++ b/net/mac80211/iface.c
> @@ -698,6 +698,11 @@ int ieee80211_do_open(struct wireless_dev *wdev,
> bool coming_up)
> rcu_assign_pointer(local->p2p_sdata, sdata);
> }
>
> + if (local->open_count == 0 && local-
> >data_80211_hdr_offloaded) {
> + local->hw.conf.encap_decap_80211_offloaded = true;
> + hw_reconf_flags |=
> IEEE80211_CONF_CHANGE_80211_HDR_OFFL;
> + }
I don't see how this helps anything, I think you should remove it.
> +void ieee80211_if_config_80211_hdr_offl(struct ieee80211_local
> *local,
> + bool enable_80211_hdr_offl)
> +{
> + struct ieee80211_sub_if_data *sdata;
> + unsigned long flags;
> + int n_acs = IEEE80211_NUM_ACS;
> + int ac;
> +
> + ASSERT_RTNL();
> +
> + if (!ieee80211_hw_check(&local->hw,
> SUPPORTS_80211_ENCAP_DECAP) ||
> + !(ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL)))
> + return;
> +
> + if (local->hw.wiphy->frag_threshold != (u32)-1 &&
> + !local->ops->set_frag_threshold)
> + return;
> +
> + mutex_lock(&local->iflist_mtx);
> +
> + list_for_each_entry(sdata, &local->interfaces, list) {
> + if (!sdata->dev)
> + continue;
> +
> + netif_tx_stop_all_queues(sdata->dev);
> +
> + if (enable_80211_hdr_offl)
> + sdata->dev->netdev_ops =
> &ieee80211_dataif_8023_ops;
> + else
> + sdata->dev->netdev_ops =
> &ieee80211_dataif_ops;
> + }
> +
> + mutex_unlock(&local->iflist_mtx);
> +
> + local->data_80211_hdr_offloaded = enable_80211_hdr_offl;
> +
> + if (local->started) {
> + if (enable_80211_hdr_offl)
> + local->hw.conf.encap_decap_80211_offloaded =
> true;
> + else
> + local->hw.conf.encap_decap_80211_offloaded =
> false;
> + ieee80211_hw_config(local,
> + IEEE80211_CONF_CHANGE_80211_HDR_
> OFFL);
> + }
> +
> + mutex_lock(&local->iflist_mtx);
> +
> + list_for_each_entry(sdata, &local->interfaces, list) {
> + if (!sdata->dev)
> + continue;
> +
> + if (local->hw.queues < IEEE80211_NUM_ACS)
> + n_acs = 1;
> +
> + spin_lock_irqsave(&local->queue_stop_reason_lock,
> flags);
> + if (sdata->vif.cab_queue == IEEE80211_INVAL_HW_QUEUE
> ||
> + (local->queue_stop_reasons[sdata->vif.cab_queue]
> == 0 &&
> + skb_queue_empty(&local->pending[sdata-
> >vif.cab_queue]))) {
> + for (ac = 0; ac < n_acs; ac++) {
> + int ac_queue = sdata-
> >vif.hw_queue[ac];
> +
> + if (local-
> >queue_stop_reasons[ac_queue] == 0 &&
> + skb_queue_empty(&local-
> >pending[ac_queue]))
> + netif_start_subqueue(sdata-
> >dev, ac);
> + }
> + }
> + spin_unlock_irqrestore(&local-
> >queue_stop_reason_lock, flags);
> + }
> +
> + mutex_unlock(&local->iflist_mtx);
> +}
I really would prefer we could simply avoid doing these manipulations
while the interface is UP and can have data queued.
> +++ b/net/mac80211/key.c
> @@ -208,13 +208,25 @@ static int ieee80211_key_enable_hw_accel(struct
> ieee80211_key *key)
> case WLAN_CIPHER_SUITE_GCMP_256:
> /* all of these we can do in software - if driver
> can */
> if (ret == 1)
> - return 0;
> + goto check_8023_txrx;
> if (ieee80211_hw_check(&key->local->hw,
> SW_CRYPTO_CONTROL))
> return -EINVAL;
> - return 0;
> + goto check_8023_txrx;
> default:
> return -EINVAL;
> }
> +
> +check_8023_txrx:
> + /* When sw crypto is enabled make sure data tx/rx happens
> + * in 802.11 format.
> + */
> + if (key->local->data_80211_hdr_offloaded) {
> + rtnl_lock();
> + ieee80211_if_config_80211_hdr_offl(key->local,
> false);
> + rtnl_unlock();
> + }
> +
> + return 0;
> }
Why not just refuse the key instead? It also seems wrong to do anything
with local-> here, it should be per interface.
> +++ b/net/mac80211/status.c
> @@ -506,12 +506,14 @@ static void ieee80211_report_used_skb(struct
> ieee80211_local *local,
> struct sk_buff *skb, bool
> dropped)
> {
> struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> - struct ieee80211_hdr *hdr = (void *)skb->data;
> + struct ieee80211_hdr *hdr;
> bool acked = info->flags & IEEE80211_TX_STAT_ACK;
>
> if (dropped)
> acked = false;
>
> + hdr = (void *)skb->data;
That change make no sense.
> if (info->flags & IEEE80211_TX_INTFL_MLME_CONN_TX) {
> struct ieee80211_sub_if_data *sdata;
>
> @@ -945,6 +947,85 @@ void ieee80211_tx_status(struct ieee80211_hw
> *hw, struct sk_buff *skb)
> }
> EXPORT_SYMBOL(ieee80211_tx_status);
>
> +void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct sk_buff *skb)
I think this could share some code with the 802.11 version?
> + /* XXX: Add a generic helper for this */
> + if (sdata->vif.type == NL80211_IFTYPE_AP ||
> + sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
> + sdata->vif.type == NL80211_IFTYPE_ADHOC)
> + ether_addr_copy(ra_addr, ehdr->h_dest);
nit, but the "A" in "RA" already means address ... :)
You also don't need to copy it - just keeping a pointer should be fine?
> + /* TODO: Handle frames requiring wifi tx status to be
> notified */
> + if (skb->sk && skb_shinfo(skb)->tx_flags &
> SKBTX_WIFI_STATUS)
> + goto out_free;
Surely you shouldn't free them, even if you don't handle the status?!
johannes
^ permalink raw reply
* Re: [RFC 3/3] mac80211: Add receive path for ethernet frame format
From: Johannes Berg @ 2016-12-15 9:38 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless
In-Reply-To: <1481781608-5181-4-git-send-email-vthiagar@qti.qualcomm.com>
> This rx path only checks if the driver has advertised
> it's support of 802.11 header encap/decap offload for
> data frames.
I'm not even sure I see the point in that? Other than that (and the
various other offload requirements), it seems that encap/decap could be
considered orthogonal.
> + * Adhoc interface depends on bssid to udpate last_rx.
type - update
> + if (!(status->flag & RX_FLAG_MCAST)) {
> + sta->rx_stats.last_rx = jiffies;
> + sta->rx_stats.last_rate =
> sta_stats_encode_rate(status);
> + }
You should probably rename that flag to something like
RX_FLAG_80211_MCAST since otherwise it's confusing with the next
multicast ether addr check:
> + if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> + !is_multicast_ether_addr(ehdr->h_dest))
> + ieee80211_sta_reset_conn_monitor(sdata);
But this could just also use the flag, since in station mode the two
are equivalent, and it'd be easier to figure out if this was "else if
(station mode)"?
> + memset(&rx, 0, sizeof(rx));
That seems a bit pointless?
> + rx.skb = skb;
> + rx.sdata = sdata;
> + rx.local = local;
> + rx.sta = sta;
> +
> + if (vif->type == NL80211_IFTYPE_AP_VLAN && sdata->bss &&
> + unlikely(ehdr->h_proto == sdata->control_port_protocol))
> {
> + sdata = container_of(sdata->bss, struct
> ieee80211_sub_if_data,
> + u.ap);
> + dev = sdata->dev;
> + rx.sdata = sdata;
> + }
> +
> + rx.skb->dev = dev;
> +
> + /* XXX: Since rx.seqno_idx is not available for decap
> offloaded frames
> + * rx msdu stats update at the seqno_idx in
> ieee80211_deliver_skb()
> + * will always be updated at index 0 and will not be very
> useful.
> + */
> + ieee80211_deliver_skb(&rx);
Yeah, that's not nice - perhaps we can provide the TID out of band? If
not, we'll have to disable those statistics *all the way*, i.e. not
even report them to userspace when filling sinfo.
> + return;
> +
> +mic_fail:
> + cfg80211_michael_mic_failure(sdata->dev, sta->addr,
> + (status->flag & RX_FLAG_MCAST)
> ?
> + NL80211_KEYTYPE_GROUP :
> + NL80211_KEYTYPE_PAIRWISE,
> + key ? key->conf.keyidx : -1,
> + NULL, GFP_ATOMIC);
Do we really want to handle that inline here? The driver probably has a
different check to even set RX_FLAG_MMIC_ERROR, so we could just ask it
to call cfg80211_michael_mic_failure() [or a wrapper to get sdata->dev]
instead? I guess this works too though, and might be easier to
understand.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: fix legacy and invalid rx-rate rpt
From: Johannes Berg @ 2016-12-15 9:54 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1481743838-20323-1-git-send-email-greearb@candelatech.com>
On Wed, 2016-12-14 at 11:30 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This fixes obtaining the rate info via sta_set_sinfo
> when the rx rate is invalid (for instance, on IBSS
> interface that has received no frames from one of its
> peers).
>
> This also fixes a more general issue with rinfo->flags
> not being properly initialized for legacy rates.
I'd say this is a bug in the ethtool code - everything assumes (and
everything else makes sure) the whole sinfo struct is initialized to 0
before getting passed to this function.
> +static int sta_set_rate_info_rx(struct sta_info *sta, struct
> rate_info *rinfo)
> {
> u16 rate = ACCESS_ONCE(sta_get_last_rx_stats(sta)-
> >last_rate);
> -
> - if (rate == STA_STATS_RATE_INVALID)
> - rinfo->flags = 0;
> - else
> + if (rate == STA_STATS_RATE_INVALID) {
> + return -EINVAL;
> + } else {
> sta_stats_decode_rate(sta->local, rate, rinfo);
> + return 0;
> + }
That's weird, I'll fix it.
Applied, with some fixupse.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: only alloc mem if a station doesnt exist yet
From: Johannes Berg @ 2016-12-15 9:57 UTC (permalink / raw)
To: Koen Vandeputte; +Cc: linux-wireless
In-Reply-To: <1481732939-8237-1-git-send-email-koen.vandeputte@ncentric.com>
On Wed, 2016-12-14 at 17:28 +0100, Koen Vandeputte wrote:
> This speeds up the function in case a station already exists by
> avoiding
> calling an expensive kzalloc just to free it again after the next
> check.
It's not like this is called often, but yeah - still makes sense.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 01/10] mac80211: minstrel_ht: move supported bitrate mask out of group data
From: Johannes Berg @ 2016-12-15 10:08 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: thomas.huehn
In-Reply-To: <20161214194703.33429-1-nbd@nbd.name>
That all looks good, applied.
johannes
^ permalink raw reply
* Re: [RFC 0/3] Add new data path for ethernet frame format
From: Thiagarajan, Vasanthakumar @ 2016-12-15 10:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1481792926.31776.1.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwMjozOCBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4gT24gVGh1LCAyMDE2LTEyLTE1IGF0IDExOjMwICswNTMwLCBWYXNhbnRoYWt1bWFyIFRo
aWFnYXJhamFuIHdyb3RlOg0KPj4gVGhpcyBwYXRjaCBzZXQgYWRkcyBhIG5ldyBkYXRhIHBhdGgg
dG8gb2ZmbG9hZCA4MDIuMTEgaGVhZGVyDQo+PiBlbmNhcC9kZWNhcCB0byBkcml2ZXIgb3IgaGFy
ZHdhcmUuIERyaXZlcnMgaGF2aW5nIHN1cHBvcnQNCj4+IGZvciBpZWVlODAyMTEgaGVhZGVyIGVu
Y2FwL2RlY2FwIGFuZCBvdGhlciBvZmZsb2FkIGZ1bmN0aW9uYWxpdGllcw0KPj4gd2hpY2ggY2Fu
J3QgYmUgZG9uZSBiZWZvcmUgZW5jYXAgb3IgYWZ0ZXIgZGVjYXAgY2FuIG1ha2UgdXNlIG9mDQo+
PiB0aGlzIG5ldyBkYXRhIHBhdGguIEN1cnJlbnRseSBpdCBpcyBpbXBsZW1lbnRlZCBmb3IgU1RB
IGFuZCBBUA0KPj4gaW50ZXJmYWNlIHR5cGUsIHRoaXMgY2FuIGJlIGV4dGVuZCBvdGhlciBpbnRl
cmZhY2UgdHlwZXMgbGlrZQ0KPj4gYWRob2MuDQo+DQo+IFRoYW5rcyBmb3IgcG9zdGluZyB0aGlz
IQ0KPg0KPj4gV2l0aCBhdGgxMGsgZHJpdmVyIGNoYW5nZXMgdXNpbmcgdGhpcyBuZXcgVHgvUngg
cGF0aCwgMTAgLSAxNSUNCj4+IENQVSB1c2FnZSBhbmQgdXB0byB+MjBNYnBzIFRDUCBwZXJmb3Jt
YW5jZSBpbXByb3ZlbWVudHMgYXJlDQo+PiBvYnNlcnZlZCB3aXRoIHRoaXMgZXRoZXJuZXQgZGF0
YSBwYXRoLg0KPg0KPiBJJ20gc3VyZSB0aGF0J3MgYmVjYXVzZSB5b3VyIENQVSBpcyBzZXZlcmVs
eSBsaW1pdGVkIDotKQ0KDQpSaWdodCwgbW9zdCBvZiB0aGUgdGltZSBJIHdhcyBvYnNlcnZpbmcg
bWF4IENQVSB1c2FnZS4NCg0KPg0KPj4gVGhpcyBwYXRjaCBzZXQgaXMNCj4+IHByZXBhcmVkIG9u
IGEgb2xkZXIgbWFjODAyMTEgY29kZSBiYXNlIG9uIHRvcCBvZg0KPj4gY29tbWl0IDdkMjdhMGJh
N2FkYyAoImNmZzgwMjExOiBBZGQgbWVzaCBwZWVyIEFJRCBzZXR0aW5nIEFQSSIpLg0KPj4gU29y
cnksIEkgY291bGQgbm90IGdldCBhIGNoYW5jZSB0byByZXdvcmsgaXQgb24gdG9wIG9mIGxhdGVz
dA0KPj4gbWFjODAyMTEgY29kZSBiYXNlLg0KPg0KPiBPay4gSSBndWVzcyB0aGF0IGRvZXNuJ3Qg
bWF0dGVyIG11Y2ggZm9yIHJldmlldyBub3cuDQo+DQo+PiAJLSBDb25zaWRlciBpZWVlODAxMSBo
ZWFkZXIgYW5kIGNpcGhlciBoZWFkZXIgc2l6ZSBhbHNvIHdoaWxlDQo+PiB1cGRhdGluZyB0eC9y
eCBzdGF0cyBmb3INCj4+IAkgIGV0aGVybmV0IGZyYW1lIGZvcm1hdC4NCj4NCj4gSSB3b25kZXIg
aWYgd2UgcmVhbGx5IHNob3VsZG4ndCBiZSBnb2luZyB0aGUgb3RoZXIgd2F5IGFyb3VuZCBpbnN0
ZWFkLA0KPiB0byBiZSBjbG9zZXIgdG8gd2hhdCBFdGhlcm5ldCBhbmQgbGlrZWx5IG90aGVyIGRy
aXZlcnMgZG8uDQoNCk9rLiBJIGNhcHR1cmVkIHRoYXQgYmVjYXVzZSByeC90eCBieXRlcyBzdGF0
cyB3aWxsIGJlIGluY29uc2lzdGVudCBiZXR3ZWVuIGV0aGVybmV0DQphbmQgODAyLjExIGZyYW1l
IGZvcm1hdC4NCg0KVmFzYW50aA==
^ permalink raw reply
* Re: [RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload
From: Thiagarajan, Vasanthakumar @ 2016-12-15 10:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1481793392.31776.3.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwMjo0NiBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4NCj4+IERyaXZlcnMgYWR2ZXJ0aXNpbmcgdGhpcyBjYXBhYmlsaXR5IHNob3VsZCBhbHNv
IGltcGxlbWVudCBvdGhlcg0KPj4gZnVuY3Rpb25hbGl0aWVzIHdoaWNoIGRlYWwgd2l0aCA4MDIu
MTEgZnJhbWUgZm9ybWF0IGxpa2UgYmVsb3cNCj4NCj4+IAktIEFEREJBL0RFTEJBIG9mZmxvYWQN
Cj4NCj4gVGhpcyBzaG91bGRuJ3QgYmUgbmVjZXNzYXJ5Lg0KDQpPay4gU2luY2UgZHJpdmVyL2h3
IG5lZWRzIHRvIGltcGxlbWVudCBUeC9SeCBhZ2dyZWdhdGlvbiByZWxhdGVkIGZ1bmN0aW9uYWxp
dGllcw0KSSB0aG91Z2h0IEFEREJBL0RFTEJBIHByb2Nlc3Npbmcgd2lsbCBiZSBsaXR0bGUgaW1w
b3J0YW50IHRvIG1hYzgwMjExLiBNYXkgYmUgSSdtDQptaXNzaW5nIHNvbWV0aGluZy4NCg0KPg0K
Pj4gCS0gSGFyZHdhcmUgcmF0ZSBjb250cm9sDQo+DQo+IE5laXRoZXIgaXMgdGhpcywgaWYgd2Ug
ZmluZCBzb21lIEFQSSB0byBkbyBzYW1wbGluZy4gVGhlIGV4aXN0aW5nIHJhdGUNCj4gdGFibGUg
QVBJIGFscmVhZHkgYWxsb3dzIHNldHRpbmcgdGhlIHJhdGVzIG91dCBvZiBiYW5kLCBzbyB0aGUg
b25seQ0KPiB0aGluZyB0aGF0IHlvdSdkIGhhdmUgdG8gc3VwcG9ydCBvdXQgb2YgYmFuZCBpcyBz
YW1wbGluZy4NCg0KT2suDQoNCj4NCj4+IAktIFBvd2Vyc2F2ZSBvZmZsb2FkDQo+DQo+IFRoYXQn
cyBhbWJpZ3VvdXMgLSB5b3UgZG8gbmVlZCB0byBoYW5kbGUgc2xlZXBpbmcgc3RhdGlvbnMgKGFu
ZCBQUy0NCj4gUG9sbC9VLUFQU0QpIGluIEFQIG1vZGUgaW4gdGhlIGRldmljZSB3aXRoIHRoaXMs
DQoNCkkgZGlkIG5vdCBkaWcgZGVlcCBpbnRvIFBTIHJlcXVpcmVtZW50IHdpdGggZXRoZXJuZXQg
ZnJhbWUgZm9ybWF0IGJlY2F1c2UNCmZyYW1lIGNvbnRyb2wgaXMgbm90IGF2YWlsYWJsZSB0byBt
YWM4MDIxMSwgc28gSSB0aG91Z2h0IHRvIG1lbnRpb24gUFMgb2ZmbG9hZA0KaXMgYSByZXF1aXJl
bWVudC4gTWF5IGJlIHRoZXJlIGlzIGFscmVhZHkgYW4gaW5mcmFzdHJ1Y3R1cmUgaW4gbWFjODAy
MTEgdG8NCmxlYXJuIFBTIHN0YXRlIG9mIGNsaWVudCB3aGljaCB3YXMgbm90aWZpZWQgaW4gdGhl
IGN1cnJlbnQgZGF0YSBmcmFtZSAob3RoZXINCnRoYW4gODAyLjExIGZyYW1lIGNvbnRyb2wpLg0K
DQogIGJ1dCBJIGRvbid0IHNlZSBhIGRlZXANCj4gdGVjaG5pY2FsIHJlYXNvbiB0byByZXF1aXJl
IGl0IGZvciBjbGllbnQgbW9kZS4gT1RPSCwgY2xpZW50IG1vZGUgaXMNCj4gYWxtb3N0IGFsd2F5
cyBvZmZsb2FkZWQgYW55d2F5Lg0KDQpPay4NCg0KPg0KPiBJIHRoaW5rIHlvdSBtYXkgaGF2ZSBm
b3Jnb3R0ZW4gb25lIGltcG9ydGFudCBpdGVtLA0KPg0KPiAJLSBjb250cm9sIHBvcnQgaGFuZGxp
bmcNCg0KSG1tbSwgSSdtIGdldHRpbmcgV1BBLVBTSyB3b3JraW5nIHdpdGggdGhpcy4gTWF5IGJl
IHRoZXJlIGFyZSBvdGhlcg0KY29udHJvbCBwb3J0IGhhbmRsaW5nIHdoaWNoIHdpbGwgbm90IHdv
cmsgd2l0aCBldGhlcm5ldCBmcmFtZSBmb3JtYXQ/DQoNCj4NCj4gPw0KPg0KPj4gKyAqIEBJRUVF
ODAyMTFfSFdfU1VQUE9SVFNfODAyMTFfRU5DQVBfREVDQVA6IEhhcmR3YXJlL2RyaXZlcg0KPj4g
c3VwcG9ydHMgODAyLjExDQo+PiArICoJZW5jYXAvZGVjYXAgZm9yIGRhdGEgZnJhbWVzLiBTdXBw
b3J0aW5nIGRyaXZlciBoYXZlIHRvDQo+PiBpbXBsZW1lbnQNCj4+ICsgKglnZXRfdmlmXzgwMjEx
X2VuY2FwX2RlY2FwX29mZmxvYWQoKSB0byBwYXNzIGlmIDgwMi4xMQ0KPj4gZW5jYXAvZGVjYXAN
Cj4+ICsgKglvZmZsb2FkCWlzIHN1cHBvcnRlZCBmb3IgdGhlIHZpZi4NCj4NCj4gSSBkb24ndCBz
ZWUgd2h5IHlvdSBuZWVkIHRoaXMsIHdoZW4geW91IGhhdmUgdGhlIG1ldGhvZCAtIHlvdSBjYW4g
anVzdA0KPiBhc3N1bWUgdGhhdCB0aGUgbWV0aG9kIHJldHVybnMgZmFsc2Ugd2hlbiBpdCdzIG5v
dCBpbXBsZW1lbnRlZC4NCg0KT2ssIEkgd2FzIHRyeWluZyBkZWZpbmUgYW4gaW50ZXJmYWNlIGZv
ciBkcml2ZXIgdG8gcmV0dXJuIHZpZiB0eXBlIGJhc2VkDQplbmNhcC9kZWNhcCBjYXBhYmlsaXR5
IHNvIHRoYXQgaW4gNC1hZGRyIGFuZCBNZXNoIHR5cGUgODAyLjExIGZyYW1lIGZvcm1hdA0KaXMg
dXNlZC4NCg0KPg0KPj4gICBzdHJ1Y3QgaWVlZTgwMjExX29wcyB7DQo+PiAgIAl2b2lkICgqdHgp
KHN0cnVjdCBpZWVlODAyMTFfaHcgKmh3LA0KPj4gQEAgLTM2MzksNiArMzY1MSwxMCBAQCBzdHJ1
Y3QgaWVlZTgwMjExX29wcyB7DQo+PiAgIAl2b2lkICgqd2FrZV90eF9xdWV1ZSkoc3RydWN0IGll
ZWU4MDIxMV9odyAqaHcsDQo+PiAgIAkJCSAgICAgIHN0cnVjdCBpZWVlODAyMTFfdHhxICp0eHEp
Ow0KPj4gICAJdm9pZCAoKnN5bmNfcnhfcXVldWVzKShzdHJ1Y3QgaWVlZTgwMjExX2h3ICpodyk7
DQo+PiArDQo+PiArCWludCAoKmdldF92aWZfODAyMTFfaGRyX29mZmxvYWQpKHN0cnVjdCBpZWVl
ODAyMTFfaHcgKmh3LA0KPj4gKwkJCQkJIHN0cnVjdCBpZWVlODAyMTFfdmlmICp2aWYsDQo+PiAr
CQkJCQkgYm9vbCBpc180YWRkciwgYm9vbA0KPj4gKnN1cHBvcnRlZCk7DQo+DQo+IFdoeSBhcmUg
eW91IG5vdCBzaW1wbHkgcmV0dXJuaW5nICJzdXBwb3J0ZWQiPw0KPg0KPiBJIGRvbid0IGxpa2Ug
cGFzc2luZyB0aGUgdmlmIHBvaW50ZXIgaGVyZS4gQXQgdGhpcyBwb2ludCwgdGhlIHZpZg0KPiBw
b2ludGVyIGlzbid0IGtub3duIHRvIHRoZSBkcml2ZXIgeWV0ICh0aHJvdWdoIGRydl9hZGRfaW50
ZXJmYWNlKSBzbw0KPiBpdCdzIGEgZGVhZCBwb2ludGVyIGFzIGZhciBhcyB0aGUgc2VxdWVuY2lu
ZyBpcyBjb25jZXJuZWQuDQo+DQo+IElzIHRoZXJlIGEgcG9zc2liaWxpdHkgdGhhdCBkcml2ZXJz
IG5lZWQgdG8gc3dpdGNoIG9mZiBldGhlcm5ldCBmb3JtYXQNCj4gaGFuZGxpbmcgZW50aXJlbHkg
d2hlbiBhbiBpbmNvbXBhdGlibGUgaW50ZXJmYWNlIGlzIGFkZGVkPyBGb3IgZXhhbXBsZSwNCj4g
aWYgeW91IGFkZCBhIG1lc2ggaW50ZXJmYWNlLCBpcyB0aGVyZSBhIGNoYW5jZSB0aGF0IHRoZSBB
UCBpbnRlcmZhY2UNCj4gbWlnaHQgbm8gbG9uZ2VyIGJlIGFibGUgdG8gaGFuZGxlIHRoaXM/DQog
Pg0KID4gSSdkIGhvcGUgdGhpcyBkb2Vzbid0IGhhcHBlbiBiZWNhdXNlIEkgdGhpbmsgdGhhdCB3
b3VsZCBiZSBleHRyZW1lbHkNCiA+IGNvbXBsaWNhdGVkIHRvIGhhbmRsZSBzYWZlbHkuDQoNClVu
Zm9ydHVuYXRlbHkgIltSRkMgMi8zXSBtYWM4MDIxMTogSW1wbGVtZW50IGRhdGEgeG1pdCBmb3Ig
ODAyLjExIGVuY2FwIG9mZmxvYWQiDQp0cmllcyB0byBpbXBsZW1lbnQgdGhpcyBidXQgbW9yZSBs
aWtlbHkgYnVnZ3kgOiguIFlvdSBhcmUgcmlnaHQsIGl0IGlzIHZlcnkNCmNvbXBsZXggdG8gZ2V0
IHRoYXQgcmlnaHQuIE1heSBiZSB3ZSBzaG91bGQgbm90IGFsbG93IGludGVyZmFjZSBuZWVkaW5n
DQpkeW5hbWljIHN3aXRjaD8NCg0KVmFzYW50aA==
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Malinen, Jouni @ 2016-12-15 11:06 UTC (permalink / raw)
To: Johannes Berg
Cc: Arend Van Spriel, Vamsi, Krishna, linux-wireless@vger.kernel.org
In-Reply-To: <1481644615.20412.25.camel@sipsolutions.net>
T24gVHVlLCBEZWMgMTMsIDIwMTYgYXQgMDQ6NTY6NTVQTSArMDEwMCwgSm9oYW5uZXMgQmVyZyB3
cm90ZToNCj4gUmVnYXJkaW5nIHJldXNpbmcgYXR0cmlidXRlcywgd2UgaGF2ZSAoZm9yIHRoZSBC
U1Mgc2VsZWN0aW9uIHRoaW5nKSB0aGUNCj4gYXR0cmlidXRlIE5MODAyMTFfQlNTX1NFTEVDVF9B
VFRSX1JTU0lfQURKVVNULCB3aGljaCBpcyByZWFsbHkgcXVpdGUNCj4gc2ltaWxhciB0byB5b3Vy
IG5ld8KgTkw4MDIxMV9BVFRSX1NDSEVEX1NDQU5fUkVMQVRJVkVfUlNTSV81R19QUkVGIHNpbmNl
DQo+IHdoaWxlIGNvbm5lY3RlZCAod2hpY2ggQlNTX1NFTEVDVF9BVFRSXyogYXNzdW1lcykgdGhl
IGN1cnJlbnQgQlNTIGlzDQo+IGFsd2F5cyBwYXJ0IG9mIHRoZSBjb25zaWRlcmVkIEJTU2VzLCBJ
J2QgdGhpbmsuDQoNCkl0IHNlZW1zIHRvIGhhdmUgc29tZXdoYXQgc2ltaWxhciBtZWFuaW5nLCBi
dXQgaXQgbG9va3MgbW9yZSBnZW5lcmljIGJ5DQpub3QgYmVpbmcgdGllZCB0byBqdXN0IHR3byBi
YW5kcyAoMi40IGFuZCA1KS4gQW5kIG5vdyB0aGF0IEkgYWN0dWFsbHkNCmxvb2tlZCBhZ2FpbiBh
dCB0aGlzLCBpdCBkb2VzIG5vdCBsb29rIGxpa2UNCk5MODAyMTFfQlNTX1NFTEVDVF9BVFRSX1JT
U0lfQURKVVNUIGFjdHVhbGx5IGFsbG93cyBtb3JlIHRoYW4gYSBzaW5nbGUNCmJhbmQsZGVsdGEg
cGFpciB0byBiZSBwcm92aWRlZCBhbmQgYXMgc3VjaCwgaXQgYWN0dWFsbHkgd291bGQgbm90IHdv
cmsNCnZlcnkgd2VsbCB3aXRoIG1vcmUgdGhhbiB0d28gYmFuZHMgZXZlbiBpZiBpdCBtaWdodCBi
ZSBhIGJpdCBtb3JlDQpnZW5lcmljIGJ5IGFsbG93aW5nIGJhbmQgdG8gYmUgc2V0IHRvIHNvbWV0
aGluZyBlbHNlIHRoYW4gMi40IG9yIDUuIEJ5DQp0aGUgd2F5LCBubDgwMjExLmggZG9lcyBub3Qg
c2VlbSB0byBkb2N1bWVudCB3aGF0IHZhbHVlcyBzdHJ1Y3QNCm5sODIwMTFfYnNzX3NlbGVjdF9y
c3NpX2FkanVzdCBiYW5kIHVzZXMuLiAgSXMgdGhpcyBlbnVtIG5sODAyMTFfYmFuZD8NCk5laXRo
ZXIgZG9lcyBpdCBzYXkgdGhhdCBkZWx0YSBpcyBpbiBkQiAoaXMgaXQ/KS4NCg0KPiBPVE9ILCB0
aGUgbmV3wqBOTDgwMjExX0FUVFJfU0NIRURfU0NBTl9SRUxBVElWRV9SU1NJXzVHX1BSRUYgZG9l
c24ndA0KPiBtYWtlIHRoaXMgcXVpdGUgY2xlYXIgLSBpcyB0aGUgY3VycmVudCBCU1MgdG8gYmUg
YWRqdXN0ZWQgYmVmb3JlDQo+IGNvbXBhcmluZywgaWYgaXQncyA1IEdIej8gSWYgc28sIHRoZSBz
ZW1hbnRpY3MgYXJlIGVxdWl2YWxlbnQuIElmIG5vdCwNCj4gaXQgZG9lc24ndCBhY3R1YWxseSBt
YWtlIG11Y2ggc2Vuc2UgOy0pDQoNCk1heWJlIHRoZSBubDgwMjExLmggZGVzY3JpcHRpb24gd2Fz
IG5vdCBjbGVhciBlbm91Z2gsIGJ1dCB0aGUgY29tbWVudHMNCmluIGNmZzgwMjExLmggc2hvdWxk
IGJlIHF1aXRlIGNsZWFyIG9uIGhvdyB0aGlzIHdhcyBkZXNpZ25lZCB0byB3b3JrIGF0DQp0aGUg
aW1wbGVtZW50YXRpb24gbGV2ZWw6DQoNCiJJZiB0aGUgY3VycmVudCBjb25uZWN0ZWQgQlNTIGlz
IGluIHRoZSAyLjQgR0h6IGJhbmQsIG90aGVyIEJTU3MgaW4gdGhlDQoyLjQgR0h6IGJhbmQgdG8g
YmUgcmVwb3J0ZWQgc2hvdWxkIGhhdmUgYmV0dGVyIFJTU0kgYnkgQHJlbGF0aXZlX3Jzc2kNCmFu
ZCBvdGhlciBCU1NzIGluIHRoZSA1IEdIeiBiYW5kIHRvIGJlIHJlcG9ydGVkIHNob3VsZCBoYXZl
IGJldHRlciBSU1NJDQpieSAoQHJlbGF0aXZlX3Jzc2kgLSBAcmVsYXRpdmVfcnNzaV81Z19wcmVm
KS4NCklmIHRoZSBjdXJyZW50IGNvbm5lY3RlZCBCU1MgaXMgaW4gdGhlIDUgR0h6IGJhbmQsIG90
aGVyIEJTU3MgaW4gdGhlDQoyLjQgR0h6IGJhbmQgdG8gYmUgcmVwb3J0ZWQgc2hvdWxkIGhhdmUg
YmV0dGVyIFJTU0kgYnkNCihAcmVsYXRpdmVfcnNzaSArIEByZWxhdGl2ZV9yc3NpXzVnX3ByZWYp
IGFuZCBvdGhlciBCU1NzIGluIHRoZSA1IEdIeg0KYmFuZCB0byBiZSByZXBvcnRlZCBzaG91bGQg
aGF2ZSBiZXR0ZXIgUlNTSSBieSBieSBAcmVsYXRpdmVfcnNzaS4iDQoNCkknbSBub3Qgc3VyZSBJ
J2QgZGVzY3JpYmUgdGhpcyBhcyBhZGp1c3RpbmcgdGhlIGN1cnJlbnQgQlNTIFJTU0ksIGJ1dA0K
bW9yZSBsaWtlIGFkanVzdGluZyB0aGUgUlNTSSB0aHJlc2hvbGQgdmFsdWUgaWYgcm9hbWluZyB3
b3VsZCBiZSBmcm9tDQpvbmUgYmFuZCB0byBhbm90aGVyIGFuZCBkb2luZyB0aGF0IGFkanVzdG1l
bnQgYnkgYWRkaW5nIG9yIGRlY3JlbWVudGluZw0KYmFzZWQgb24gd2hldGhlciB0aGUgcm9hbSB3
b3VsZCBiZSBmcm9tIDIuNCB0byA1IG9yIGZyb20gNSB0byAyLjQuDQoNCj4gU28gYXNzdW1pbmcg
dGhhdCBpdCBpcyBpbiBmYWN0IHRha2VuIGludG8gYWNjb3VudCBhZnRlciB0aGUgc2FtZQ0KPiBh
ZGp1c3RtZW50LCB0aGUgdHdvIGF0dHJpYnV0ZXMgYXJlIGVxdWl2YWxlbnQsIGFuZCB0aGVuIHBl
cmhhcHMgaXQNCj4gd291bGQgbWFrZSBzZW5zZSB0byB1c2Ugc3RydWN0IG5sODAyMTFfYnNzX3Nl
bGVjdF9yc3NpX2FkanVzdCBmb3IgdGhlDQo+IG5ldyBhdHRyaWJ1dGUuIElmIGEgZHJpdmVyIGRv
ZXNuJ3Qgc3VwcG9ydCBhcmJpdHJhcnkgYmFuZHMsIGJ1dCBqdXN0IDUNCj4gR0h6IGFzIGluIHlv
dXIgZXhhbXBsZSwgaXQgY2FuIGp1c3QgZmxpcCBpdCBhcm91bmQgdG8gMi40IEdIeiBieQ0KPiBz
d2l0Y2hpbmcgdGhlIHNpZ24uDQo+IA0KPiBQZXJoYXBzIHdlIHNob3VsZCBldmVuIGNvbnNpZGVy
IGRvaW5nIHRoYXQgaW4gY2ZnODAyMTEgYW5kIGFkanVzdGluZw0KPiB0aGUgaW50ZXJuYWwgQVBJ
IGZvciBib3RoIHRoYXQgd2F5Pw0KDQpJJ20gbm90IGNvbXBsZXRlbHkgc3VyZSBJIHVuZGVyc3Rv
b2QuIE9uZSB0aGluZyB0byBub3RlIGFib3V0DQpkaWZmZXJlbmNlcyBoZXJlIGlzIHRoYXQgTkw4
MDIxMV9CU1NfU0VMRUNUX0FUVFJfKiBzZWVtcyB0byBiZSBkZWZpbmluZw0Kc29tZSBwcmVmZXJl
bmNlcyBmb3IgQlNTIHNlbGVjdGlvbiBiYXNlZCBvbiBSU1NJIHdpdGggYW4gYWRkaXRpb25hbCBi
YW5kDQpwcmVmZXJlbmNlLCBidXQgaXQgZG9lcyBub3Qgc2VlbSB0byBkZWZpbmUgdGhlIHRocmVz
aG9sZCBieSBob3cgbWFueSBkQg0KdGhlIG5ldyBjYW5kaWRhdGUgQlNTIHNob3VsZCBiZSBiZXR0
ZXIuDQoNCkF0IG1pbmltdW0sIHdlIHdvdWxkIG5lZWQgdG8gY2xlYXJseSBkb2N1bWVudCBzdHJ1
Y3QNCm5sODAyMTFfYnNzX3NlbGVjdF9yc3NpX2FkanVzdCwgYnV0IGV2ZW4gaWYgd2UgZG8sIEkn
bSBub3Qgc3VyZSBpdA0KcmVhbGx5IGlzIGlkZWFsIG1lY2hhbmlzbSB0byBtb3ZlIHRvIG5vdyB0
aGF0IEkgcmVhbGl6ZWQgaXQgaXMgbm90IGFuDQphcnJheSwgYnV0IGEgc2luZ2xlIGJhbmQsZGVs
dGEgcGFpci4NCg0KQXJlbmQ6DQo+ID4gSSBhbSBub3Qgc2F5aW5nIGl0IHNob3VsZCBiZSBhdm9p
ZGVkLiBKdXN0IGxvb2tpbmcgYXQgaXQgY29uY2VwdHVhbGx5DQo+ID4gdGhlIHNjaGVkdWxlZCBz
Y2FuIHJlcXVlc3QgaG9sZHMgc28tY2FsbGVkIG1hdGNoc2V0cyB0aGF0IHNwZWNpZnkgdGhlDQo+
ID4gY29uc3RyYWludHMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgYSBCU1Mgd2FzIGZvdW5kIHRoYXQg
aXMgd29ydGgNCj4gPiBub3RpZnlpbmcgdGhlIGhvc3QvdXNlci1zcGFjZSBhYm91dC4gQXMgc3Vj
aCBJIHdvdWxkIGV4cGVjdCB0aGUNCj4gPiByZWxhdGl2ZSBSU1NJIGF0dHJpYnV0ZShzKSB0byBi
ZSBwYXJ0IG9mIHRoZSBtYXRjaHNldC4gVGhhdCB3YXkgeW91DQo+ID4gY2FuIHNwZWNpZnkgaXQg
dG9nZXRoZXIgd2l0aCB0aGUgY3VycmVudGx5IGNvbm5lY3RlZCBTU0lEIGluIGEgc2luZ2xlDQo+
ID4gbWF0Y2hzZXQuDQo+IA0KPiBJIHRoaW5rIHRoaXMgbWFrZXMgYSBsb3Qgb2Ygc2Vuc2UuDQoN
CklmIHdlIGFyZSB0YWxraW5nIG9ubHkgYWJvdXQgcm9hbWluZyB3aXRoaW4gYW4gRVNTIChhIHNp
bmdsZSBTU0lEKSwgdGhhdA0Kd291bGQgc291bmQgY2xlYXIsIGJ1dCB3aGljaCByZWxhdGl2ZSBS
U1NJIHJ1bGVzIHdvdWxkIGFwcGx5IGlmIHRoZXJlDQphcmUgbWF0Y2ggc2V0cyBmb3IgYm90aCB0
aGUgY3VycmVudGx5IGNvbm5lY3RlZCBTU0lEIGFuZCBhbm90aGVyIFNTSUQNCnRoYXQgdGhlIGNh
bmRpZGF0ZSBCU1MgaXMgZm9yPw0KDQo+IFdlIGFscmVhZHkgaGF2ZcKgTkw4MDIxMV9TQ0hFRF9T
Q0FOX01BVENIX0FUVFJfUlNTSSwgd2hpY2ggYXNrcyB0byBiZQ0KPiByZXBvcnRpbmcgb25seSBu
ZXR3b3JrcyB0aGF0IGhhdmUgYW4gKmFic29sdXRlKiBSU1NJIHZhbHVlIGFib3ZlIHRoZQ0KPiB2
YWx1ZSBvZiB0aGUgYXR0cmlidXRlIC0gYSBuZXcgYXR0cmlidXRlIHRvIG1ha2UgaXQgcmVsYXRp
dmUgdG8gdGhlDQo+IGN1cnJlbnQgbmV0d29yayBpbnN0ZWFkIHdvdWxkIG1ha2Ugc2Vuc2UuDQoN
CldoZW4geW91IHNheSAiY3VycmVudCBuZXR3b3JrIiwgZG8geW91IG1lYW4gdGhlIGN1cnJlbnQg
QlNTPyBUaGlzIGdldHMNCmNvbXBsZXggd2hlbiB0aGlua2luZyBhYm91dCBtdWx0aXBsZSBTU0lE
cyAod2hpY2ggc29tZSBjYWxsICJuZXR3b3JrcyIpDQphbmQgdGhlcmUgYmVpbmcgTkw4MDIxMV9T
Q0hFRF9TQ0FOX01BVENIX0FUVFJfU1NJRCBhbmQgbXVsdGlwbGUNCm1hdGNoIHNldHMuLg0KDQo+
IFRoYXQgd291bGQgaW5kZWVkIGJlIGVxdWl2YWxlbnQgdG8gTkw4MDIxMV9CU1NfU0VMRUNUX0FU
VFJfUlNTSSB0aGVuLg0KDQpOTDgwMjExX0JTU19TRUxFQ1RfQVRUUl9SU1NJIGlzIGEgZmxhZyBh
dHRyaWJ1dGUuLiBCU1Mgc2VsZWN0IG1lY2hhbmlzbQ0KZG9lcyBub3QgcHJvdmlkZSBhbiBhYnNv
bHV0ZSBSU1NJIHZhbHVlIG9yIHRocmVzaG9sZDsgaXQganVzdCBzZWVtcyB0bw0KaW5kaWNhdGUg
dXNlIG9mIFJTU0ktYmFzZWQgc2VsZWN0aW9uIG1lY2hhbmlzbSB3aXRob3V0IGRlZmluaW5nIHdo
YXQNCmV4YWN0bHkgaXMgYmV0dGVyLiBUaGVyZSBpcyBOTDgwMjExX0JTU19TRUxFQ1RfQVRUUl9C
QU5EX1BSRUYgdGhhdCBnaXZlcw0KYSBwcmVmZXJlbmNlIHRvIGEgc3BlY2lmaWMgYmFuZCAod2l0
aG91dCBkZWZpbmluZyB3aGF0IHRoYXQgcHJlZmVyZW5jZQ0KaXMpIGFuZCB0aGVuIHRoZSBOTDgw
MjExX0JTU19TRUxFQ1RfQVRUUl9SU1NJX0FESlVTVCB0aGF0IGNhbiBhY3R1YWxseQ0KZ2l2ZSBh
IHNwZWNpZmljIFJTU0kgYWRqdXN0bWVudCB2YWx1ZSAoaW4gZEI/KS4NCg0KPiBOb3csIGlmIHdl
IGNvbnNpZGVyIHRoaXMswqBOTDgwMjExX0FUVFJfU0NIRURfU0NBTl9SRUxBVElWRV9SU1NJDQo+
IGFjdHVhbGx5IGlzIGVxdWl2YWxlbnQgdG/CoE5MODAyMTFfQlNTX1NFTEVDVF9BVFRSX1JTU0kg
KGEgZmxhZw0KPiBhdHRyaWJ1dGUgaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5vdCBSU1NJLWJhc2Vk
IHNlbGVjdGlvbi9tYXRjaGluZyBpcw0KPiBkb25lKSBhbmTCoE5MODAyMTFfQVRUUl9TQ0hFRF9T
Q0FOX1JFTEFUSVZFX1JTU0lfNUdfUFJFRiBpcyBlcXVpdmFsZW50DQo+IHRvwqBOTDgwMjExX0JT
U19TRUxFQ1RfQVRUUl9SU1NJX0FESlVTVCwgYm90aCBuZWVkIHRvIGJlIGdpdmVuIHdpdGggdGhl
DQo+IGZsYWcgYW5kIGFmZmVjdCBvcGVyYXRpb24uDQoNCkhtbS4uIFNvIHlvdSBkaWQgbm90aWNl
IGl0IGlzIGEgZmxhZyBhdHRyaWJ1dGUuLiBTbyBob3cgd291bGQgdGhpcyBtYXRjaA0KTkw4MDIx
MV9BVFRSX1NDSEVEX1NDQU5fUkVMQVRJVkVfUlNTSSB3aGljaCBwcm92aWRlcyB0aGUgdGhyZXNo
b2xkIHZhbHVlDQpmb3IgaG93IG1hbnkgZEIgYmV0dGVyIHRoZSBuZXcgQlNTIG5lZWRzIHRvIGJl
IGZvciBpdCB0byBiZSByZXBvcnRlZD8NCg0KPiBTbywgaG93IGFib3V0IHdlIG1vdmUgdGhlc2Ug
aW50b8KgTkw4MDIxMV9TQ0hFRF9TQ0FOX01BVENIX0FUVFJfKiBhcw0KPiBzdWdnZXN0ZWQgYnkg
QXJlbmQsIGFuZCBkZWZpbmUgdGhlbSB3aXRoIHRoZSBzYW1lIGNvbnRlbnQgYXMgwqB0aGUNCj4g
Y29ycmVzcG9uZGluZyBOTDgwMjExX0JTU19TRUxFQ1RfQVRUUl8qPw0KDQpJIHRoaW5rIEknbSBt
aXNzaW5nIHNvbWV0aGluZyBoZXJlLi4gV2hlcmUgd291bGQgdGhlIHRocmVzaG9sZCB2YWx1ZQ0K
KGhvdyBtdWNoIGJldHRlciBuZXcgQlNTIG5lZWRzIHRvIGJlKSBiZSBzdG9yZWQ/IEFuZCBkbyB3
ZSByZWFsbHkgd2FudA0Kc29tZXRoaW5nIGxpa2UgdGhlIGNvbWJpbmF0aW9uIG9mIE5MODAyMTFf
QlNTX1NFTEVDVF9BVFRSX0JBTkRfUFJFRiBhbmQNCk5MODAyMTFfQlNTX1NFTEVDVF9BVFRSX1JT
U0lfQURKVVNUIHdoaWNoIHNlZW1zIHRvIGJlIHR3byBkaWZmZXJlbnQgd2F5cw0Kb2YgZG9pbmcg
YmFuZCBwcmVmZXJlbmNlICh0aGUgZm9ybWVyIHdpdGhvdXQgc3BlY2lmeWluZyBkZWx0YSBhbmQg
dGhlDQpsYXR0ZXIgd2l0aCBzcGVjaWZpYyBkZWx0YSk/IE9yIGFtIEkgc3RpbGwgbm90IHVuZGVy
c3RhbmRpbmcgaG93DQpOTDgwMjExX0JTU19TRUxFQ1RfQVRUUl8qIHJlYWxseSB3b3Jrcz8NCg0K
PiBJZiB0aGV5J3JlIHBhcnQgb2YgbWF0Y2ggYXR0cmlidXRlcywgd2UgbWlnaHQgZXZlbiByZW1v
dmUgdGhlIGZlYXR1cmUNCj4gZmxhZyBlbnRpcmVseSAtIHRob3NlIHdlcmUgYWx3YXlzIGRlZmlu
ZWQgdG8gYmUgb3B0aW9uYWwsIGJ1dCBpdCB2ZXJ5DQo+IHdlbGwgYmUgd29ydGh3aGlsZSBmb3Ig
dXNlcnNwYWNlIHRvIGtub3cgaWYgdGhleSdyZSBzdXBwb3J0ZWQgaWYgaXQNCj4gd2FudHMgdG8g
YmVoYXZlIGRpZmZlcmVudGx5IGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZXkncmUgc3VwcG9ydGVk
IG9yDQo+IG5vdCwgSSdsbCBsZWF2ZSB0aGF0IHVwIHRvIHlvdSBzaW5jZSBwcmVzdW1hYmx5IHlv
dSBrbm93IHRoZSB1c2Vyc3BhY2UNCj4gaW1wbGVtZW50YXRpb24gdGhhdCB5b3UncmUgcGxhbm5p
bmcgdG8gY3JlYXRlLg0KDQpUaGUgbWFpbiBjb25jZXJuIEkgaGF2ZSBmb3Igb3B0aW9uYWwgZmVh
dHVyZXMgd2l0aCBzY2hlZF9zY2FuIGlzIGluDQp3aGV0aGVyIHRoZSBkZXZpY2UgZW5kcyB1cCBi
ZWluZyB3b2tlbiB1cCBjb25zdGFudGx5IGlmIHRoZSBkcml2ZXIgZG9lcw0Kbm90IHVuZGVyc3Rh
bmQgYSBjb25zdHJhaW50IHRoYXQgdXNlciBzcGFjZSBpcyB0cnlpbmcgdG8gdXNlIHRvIGF2b2lk
DQpiZWluZyBub3RpZmllZCBhbGwgdGhlIHRpbWUuDQoNCi0tIA0KSm91bmkgTWFsaW5lbiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUEdQIGlkIEVGQzg5NUZB
^ permalink raw reply
* Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags
From: Greg Kroah-Hartman @ 2016-12-15 11:50 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Emmanuel Grumbach, Stanislaw Gruszka,
Gustavo Padovan, Arend van Spriel, Luca Coelho, devel,
Jakub Kicinski, Stefan Schmidt, linux-mediatek, wil6210,
linux-arm-kernel, Chris Snook, Wolfgang Grandegger, Jay Cliburn,
linux-wpan, Johan Hedberg, Johannes Berg, Intel Linux Wireless,
Alexander Aring, Marcel Holtmann, Hante Meuleman, linux-can,
Marc Kleine-Budde, Matthias Brugger, Kalle Valo, Franky Lin,
brcm80211-dev-list.pdl, Luis R. Rodriguez, linux-wireless,
Maya Erez, linux-bluetooth, Chaoming Li, netdev, nios2-dev,
Vince Bridgers, David S. Miller, Larry Finger
In-Reply-To: <1481778865-27667-9-git-send-email-mst@redhat.com>
On Thu, Dec 15, 2016 at 07:15:30AM +0200, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/bluetooth/Makefile | 2 --
> drivers/net/can/Makefile | 1 -
> drivers/net/ethernet/altera/Makefile | 1 -
> drivers/net/ethernet/atheros/alx/Makefile | 1 -
> drivers/net/ethernet/freescale/Makefile | 2 --
> drivers/net/wireless/ath/Makefile | 2 --
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
> drivers/net/wireless/intel/iwlegacy/Makefile | 2 --
> drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/dvm/Makefile | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/Makefile | 2 +-
> drivers/net/wireless/intersil/orinoco/Makefile | 3 ---
> drivers/net/wireless/mediatek/mt7601u/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile | 2 --
> drivers/net/wireless/ti/wl1251/Makefile | 2 --
> drivers/net/wireless/ti/wlcore/Makefile | 2 --
> drivers/staging/rtl8188eu/Makefile | 2 +-
> drivers/staging/rtl8192e/Makefile | 2 --
> drivers/staging/rtl8192e/rtl8192e/Makefile | 2 --
> net/bluetooth/Makefile | 2 --
> net/ieee802154/Makefile | 2 --
> net/mac80211/Makefile | 2 +-
> net/mac802154/Makefile | 2 --
> net/wireless/Makefile | 2 --
> 38 files changed, 5 insertions(+), 68 deletions(-)
For drivers/staging:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
From: Thiagarajan, Vasanthakumar @ 2016-12-15 12:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1481794142.31776.5.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMTUgRGVjZW1iZXIgMjAxNiAwMjo1OSBQTSwgSm9oYW5uZXMgQmVyZyB3cm90
ZToNCj4NCj4+IFRoZXJlIGlzIGEgZmllbGQsIG5vXzgwMjExX2VuY2FwLCBhZGRlZCB0byBpZWVl
ODAyMTFfdHhfaW5mbzpjb250cm9sDQo+PiB0byBtYXJrIGlmIHRoZSA4MDIuMTEgZW5jYXBzdWxh
dGlvbiBpcyBvZmZsb2FkZWQgdG8gZHJpdmVyLg0KPj4gVGhlcmUgaXMgYWxzbyBhIG5ldyBjYWxs
YmFjayBmb3IgdHggY29tcGxldGlvbiBzdGF0dXMgaW5kaWNhdGlvbg0KPj4gdG8gaGFuZGxlIGRh
dGEgZnJhbWVzIHVzaW5nIDgwMi4xMSBlbmNhcCBvZmZsb2FkLg0KPg0KPiBJJ20gbm90IHN1cmUg
SSBzZWUgdGhlIG5lZWQgZm9yIHRoaXM/IE1heWJlIEknbGwgZmluZCBvdXQgaW4gdGhpcyBwYXRj
aA0KPiA6KQ0KPg0KDQpJIHRoaW5rIHdlIG1heSBub3QgbmVlZCB0aGlzIGlmIHdlIG1ha2UgdGhl
IGRlc2lnbiBpbiBzdWNoIGEgd2F5IHRoYXQgYWxsDQp0aGUgaW50ZXJmYWNlcyB3aWxsIHVzZSB1
bmlmb3JtIGVuY2FwL2RlY2FwIG1vZGUgZm9yIHRoZSBkYXRhIHBhY2tldC4NCg0KPj4gKwkJCS8q
IFhYWDogVGhpcyBmcmFtZSBpcyBub3QgZW5jYXB0dWxhdGVkIHdpdGgNCj4+IDgwMi4xMQ0KPj4g
KwkJCSAqIGhlYWRlci4gU2hvdWxkIHRoaXMgYmUgYWRkZWQgdG8NCj4+ICVJRUVFODAyMTFfVFhf
Q1RSTF8qDQo+PiArCQkJICogZmxhZ3M/Lg0KPj4gKwkJCSAqLw0KPj4gKwkJCWJvb2wgbm9fODAy
MTFfZW5jYXA7DQo+PiArCQkJLyogMyBieXRlcyBmcmVlICovDQo+PiAgIAkJfSBjb250cm9sOw0K
Pg0KPiBwcm9iYWJseSAtIGp1c3QgdG8gcHJlc2VydmUgbW9yZSBzcGFjZS4NCg0KQ29ycmVjdC4N
Cg0KPg0KPj4gKyAqIEBJRUVFODAyMTFfQ09ORl9DSEFOR0VfODAyMTFfSERSX09GRkw6IE9mZmxv
YWQgY29uZmlndXJhdGlvbg0KPj4gKyAqCWltcGxlbWVudGluZyA4MDIuMTEgZW5jYXAvZGVjYXAg
Zm9yIGRhdGEgZnJhbWVzIGNoYW5nZWQuDQo+PiAgICAqLw0KPj4gICBlbnVtIGllZWU4MDIxMV9j
b25mX2NoYW5nZWQgew0KPj4gICAJSUVFRTgwMjExX0NPTkZfQ0hBTkdFX1NNUFMJCT0gQklUKDEp
LA0KPj4gQEAgLTEyNzksNiArMTI4Niw3IEBAIGVudW0gaWVlZTgwMjExX2NvbmZfY2hhbmdlZCB7
DQo+PiAgIAlJRUVFODAyMTFfQ09ORl9DSEFOR0VfQ0hBTk5FTAkJPSBCSVQoNiksDQo+PiAgIAlJ
RUVFODAyMTFfQ09ORl9DSEFOR0VfUkVUUllfTElNSVRTCT0gQklUKDcpLA0KPj4gICAJSUVFRTgw
MjExX0NPTkZfQ0hBTkdFX0lETEUJCT0gQklUKDgpLA0KPj4gKwlJRUVFODAyMTFfQ09ORl9DSEFO
R0VfODAyMTFfSERSX09GRkwJPSBCSVQoOSksDQo+PiAgIH07DQo+DQo+IEdpdmVuIHRoZSByZXF1
aXJlbWVudHMgKFBOIGNoZWNrLCBldGMuKSBJJ20gbm90IHN1cmUgaG93IHRoaXMgY2FuDQo+IGNo
YW5nZSBkeW5hbWljYWxseT8NCg0KSSBhZ3JlZS4gRHluYW1pYyBzd2l0Y2ggcGFydCBpcyBidWdn
eSwgd2UgY2FuIHN0YXJ0IHdpdGggbm90IGFsbG93aW5nDQppbnRlcmZhY2VzIHJlc3VsdGluZyBp
biBkeW5hbWljIHN3aXRjaC4NCg0KPg0KPj4gKyAqIEBlbmNhcF9kZWNhcF84MDIxMV9vZmZsb2Fk
ZWQ6IFdoZXRoZXIgODAyLjExIGhlYWRlciBlbmNhcC9kZWNhcA0KPj4gb2ZmbG9hZA0KPj4gKyAq
CWlzIGVuYWJsZWQNCj4+ICAgICovDQo+PiAgIHN0cnVjdCBpZWVlODAyMTFfY29uZiB7DQo+PiAg
IAl1MzIgZmxhZ3M7DQo+PiBAQCAtMTM0Niw2ICsxMzU3LDcgQEAgc3RydWN0IGllZWU4MDIxMV9j
b25mIHsNCj4+ICAgCXN0cnVjdCBjZmc4MDIxMV9jaGFuX2RlZiBjaGFuZGVmOw0KPj4gICAJYm9v
bCByYWRhcl9lbmFibGVkOw0KPj4gICAJZW51bSBpZWVlODAyMTFfc21wc19tb2RlIHNtcHNfbW9k
ZTsNCj4+ICsJYm9vbCBlbmNhcF9kZWNhcF84MDIxMV9vZmZsb2FkZWQ7DQo+DQo+IFBsZWFzZSBk
b24ndCBhZGQgYW55dGhpbmcgaGVyZSB0aGF0J3MgaW50ZXJmYWNlIHNwZWNpZmljLg0KDQpPaywg
dGhpcyBpcyBtYWlubHkgaHcgY29uZmlndXJhdGlvbiBvZiBlbmNhcC9kZWNhcCBtb2RlLCBub3QN
CnZpZiBzcGVjaWZpYyBwZXIgc2F5LiBBbnkgcG9pbnRlcnMgd2hlcmUgdGhpcyBzaG91bGQgYmVs
b25nIHRvPw0KDQo+DQo+PiAtLS0gYS9uZXQvbWFjODAyMTEvY2ZnLmMNCj4+ICsrKyBiL25ldC9t
YWM4MDIxMS9jZmcuYw0KPj4gQEAgLTEwNyw2ICsxMDcsMTAgQEAgc3RhdGljIGludCBpZWVlODAy
MTFfY2hhbmdlX2lmYWNlKHN0cnVjdCB3aXBoeQ0KPj4gKndpcGh5LA0KPj4gICAJCX0NCj4+ICAg
CX0NCj4+DQo+PiArCWllZWU4MDIxMV9pZl9jaGVja184MDIxMV9oZHJfb2ZmbChzZGF0YSwNCj4+
ICsJCQkJCSAgcGFyYW1zID8gcGFyYW1zLT51c2VfNGFkZHINCj4+IDogZmFsc2UsDQo+PiArCQkJ
CQkgIHRydWUpOw0KPj4gKw0KPj4gICAJcmV0dXJuIDA7DQo+PiAgIH0NCj4NCj4gV291bGRuJ3Qg
aXQgYmUgYmV0dGVyIHRvIHNpbXBseSBwcm9oaWJpdCBjaGFuZ2luZyB0aGlzIHdoaWxlIHRoZQ0K
PiBpbnRlcmZhY2UgaXMgdXAsIGFuZCByZS1pbml0IGl0IGxhdGVyIHdoZW4gaXQgZ29lcyB1cD8N
Cg0KSSBhZ3JlZS4NCg0KPg0KPj4gKysrIGIvbmV0L21hYzgwMjExL2llZWU4MDIxMV9pLmgNCj4+
IEBAIC0xMzczLDYgKzEzNzMsOCBAQCBzdHJ1Y3QgaWVlZTgwMjExX2xvY2FsIHsNCj4+ICAgCS8q
IFRETFMgY2hhbm5lbCBzd2l0Y2ggKi8NCj4+ICAgCXN0cnVjdCB3b3JrX3N0cnVjdCB0ZGxzX2No
c3dfd29yazsNCj4+ICAgCXN0cnVjdCBza19idWZmX2hlYWQgc2tiX3F1ZXVlX3RkbHNfY2hzdzsN
Cj4+ICsNCj4+ICsJYm9vbCBkYXRhXzgwMjExX2hkcl9vZmZsb2FkZWQ7DQo+DQo+IEFnYWluLCBk
b24ndCBwdXQgaW50ZXJmYWNlIHNwZWNpZmljIHRoaW5ncyBpbnRvIGRldmljZSBzdHJ1Y3R1cmVz
Lg0KDQpPaywgdGhpcyBpcyBhbHNvIGN1cnJlbnQgaHcgY29uZmlndXJhdGlvbiBvZiBlbmNhcC9k
ZWNhcCBtb2RlLCBub3QgdmlmDQpzcGVjaWZpYy4NCg0KPg0KPj4gK2ludCBpZWVlODAyMTFfbG9v
a3VwX3JhX3N0YShzdHJ1Y3QgaWVlZTgwMjExX3N1Yl9pZl9kYXRhICpzZGF0YSwNCj4+ICsJCQkg
ICAgc3RydWN0IHNrX2J1ZmYgKnNrYiwNCj4+ICsJCQkgICAgc3RydWN0IHN0YV9pbmZvICoqc3Rh
X291dCk7DQo+DQo+IFJldHVybiB0aGUgc3RhX2luZm8gcG9pbnRlciwgYW5kIEVSUl9QVFIoKSBp
ZiBuZWVkZWQuDQoNCkNvcnJlY3QsIHN0YV9vdXQgaXMgY2hlY2tlZCBmb3IgRVJSX1BUUigpIGFz
IHdlbGwgYmVmb3JlIHVzaW5nIGl0Lg0KDQo+DQo+PiArKysgYi9uZXQvbWFjODAyMTEvaWZhY2Uu
Yw0KPj4gQEAgLTY5OCw2ICs2OTgsMTEgQEAgaW50IGllZWU4MDIxMV9kb19vcGVuKHN0cnVjdCB3
aXJlbGVzc19kZXYgKndkZXYsDQo+PiBib29sIGNvbWluZ191cCkNCj4+ICAgCQlyY3VfYXNzaWdu
X3BvaW50ZXIobG9jYWwtPnAycF9zZGF0YSwgc2RhdGEpOw0KPj4gICAJfQ0KPj4NCj4+ICsJaWYg
KGxvY2FsLT5vcGVuX2NvdW50ID09IDAgJiYgbG9jYWwtDQo+Pj4gZGF0YV84MDIxMV9oZHJfb2Zm
bG9hZGVkKSB7DQo+PiArCQlsb2NhbC0+aHcuY29uZi5lbmNhcF9kZWNhcF84MDIxMV9vZmZsb2Fk
ZWQgPSB0cnVlOw0KPj4gKwkJaHdfcmVjb25mX2ZsYWdzIHw9DQo+PiBJRUVFODAyMTFfQ09ORl9D
SEFOR0VfODAyMTFfSERSX09GRkw7DQo+PiArCX0NCj4NCj4gSSBkb24ndCBzZWUgaG93IHRoaXMg
aGVscHMgYW55dGhpbmcsIEkgdGhpbmsgeW91IHNob3VsZCByZW1vdmUgaXQuDQoNClllYWgsIEkg
dGhpbmsgdGhpcyB3YXMgYWRkZWQgZm9yIGR5bmFtaWMgc3dpdGNoLg0KDQo+DQo+PiArdm9pZCBp
ZWVlODAyMTFfaWZfY29uZmlnXzgwMjExX2hkcl9vZmZsKHN0cnVjdCBpZWVlODAyMTFfbG9jYWwN
Cj4+ICpsb2NhbCwNCj4+ICsJCQkJCWJvb2wgZW5hYmxlXzgwMjExX2hkcl9vZmZsKQ0KPj4gK3sN
Cj4+ICsJc3RydWN0IGllZWU4MDIxMV9zdWJfaWZfZGF0YSAqc2RhdGE7DQo+PiArCXVuc2lnbmVk
IGxvbmcgZmxhZ3M7DQo+PiArCWludCBuX2FjcyA9IElFRUU4MDIxMV9OVU1fQUNTOw0KPj4gKwlp
bnQgYWM7DQo+PiArDQo+PiArCUFTU0VSVF9SVE5MKCk7DQo+PiArDQo+PiArCWlmICghaWVlZTgw
MjExX2h3X2NoZWNrKCZsb2NhbC0+aHcsDQo+PiBTVVBQT1JUU184MDIxMV9FTkNBUF9ERUNBUCkg
fHwNCj4+ICsJICAgICEoaWVlZTgwMjExX2h3X2NoZWNrKCZsb2NhbC0+aHcsIEhBU19SQVRFX0NP
TlRST0wpKSkNCj4+ICsJCXJldHVybjsNCj4+ICsNCj4+ICsJaWYgKGxvY2FsLT5ody53aXBoeS0+
ZnJhZ190aHJlc2hvbGQgIT0gKHUzMiktMSAmJg0KPj4gKwkgICAgIWxvY2FsLT5vcHMtPnNldF9m
cmFnX3RocmVzaG9sZCkNCj4+ICsJCXJldHVybjsNCj4+ICsNCj4+ICsJbXV0ZXhfbG9jaygmbG9j
YWwtPmlmbGlzdF9tdHgpOw0KPj4gKw0KPj4gKwlsaXN0X2Zvcl9lYWNoX2VudHJ5KHNkYXRhLCAm
bG9jYWwtPmludGVyZmFjZXMsIGxpc3QpIHsNCj4+ICsJCWlmICghc2RhdGEtPmRldikNCj4+ICsJ
CQljb250aW51ZTsNCj4+ICsNCj4+ICsJCW5ldGlmX3R4X3N0b3BfYWxsX3F1ZXVlcyhzZGF0YS0+
ZGV2KTsNCj4+ICsNCj4+ICsJCWlmIChlbmFibGVfODAyMTFfaGRyX29mZmwpDQo+PiArCQkJc2Rh
dGEtPmRldi0+bmV0ZGV2X29wcyA9DQo+PiAmaWVlZTgwMjExX2RhdGFpZl84MDIzX29wczsNCj4+
ICsJCWVsc2UNCj4+ICsJCQlzZGF0YS0+ZGV2LT5uZXRkZXZfb3BzID0NCj4+ICZpZWVlODAyMTFf
ZGF0YWlmX29wczsNCj4+ICsJfQ0KPj4gKw0KPj4gKwltdXRleF91bmxvY2soJmxvY2FsLT5pZmxp
c3RfbXR4KTsNCj4+ICsNCj4+ICsJbG9jYWwtPmRhdGFfODAyMTFfaGRyX29mZmxvYWRlZCA9IGVu
YWJsZV84MDIxMV9oZHJfb2ZmbDsNCj4+ICsNCj4+ICsJaWYgKGxvY2FsLT5zdGFydGVkKSB7DQo+
PiArCQlpZiAoZW5hYmxlXzgwMjExX2hkcl9vZmZsKQ0KPj4gKwkJCWxvY2FsLT5ody5jb25mLmVu
Y2FwX2RlY2FwXzgwMjExX29mZmxvYWRlZCA9DQo+PiB0cnVlOw0KPj4gKwkJZWxzZQ0KPj4gKwkJ
CWxvY2FsLT5ody5jb25mLmVuY2FwX2RlY2FwXzgwMjExX29mZmxvYWRlZCA9DQo+PiBmYWxzZTsN
Cj4+ICsJCWllZWU4MDIxMV9od19jb25maWcobG9jYWwsDQo+PiArCQkJCSAgICBJRUVFODAyMTFf
Q09ORl9DSEFOR0VfODAyMTFfSERSXw0KPj4gT0ZGTCk7DQo+PiArCX0NCj4+ICsNCj4+ICsJbXV0
ZXhfbG9jaygmbG9jYWwtPmlmbGlzdF9tdHgpOw0KPj4gKw0KPj4gKwlsaXN0X2Zvcl9lYWNoX2Vu
dHJ5KHNkYXRhLCAmbG9jYWwtPmludGVyZmFjZXMsIGxpc3QpIHsNCj4+ICsJCWlmICghc2RhdGEt
PmRldikNCj4+ICsJCQljb250aW51ZTsNCj4+ICsNCj4+ICsJCWlmIChsb2NhbC0+aHcucXVldWVz
IDwgSUVFRTgwMjExX05VTV9BQ1MpDQo+PiArCQkJbl9hY3MgPSAxOw0KPj4gKw0KPj4gKwkJc3Bp
bl9sb2NrX2lycXNhdmUoJmxvY2FsLT5xdWV1ZV9zdG9wX3JlYXNvbl9sb2NrLA0KPj4gZmxhZ3Mp
Ow0KPj4gKwkJaWYgKHNkYXRhLT52aWYuY2FiX3F1ZXVlID09IElFRUU4MDIxMV9JTlZBTF9IV19R
VUVVRQ0KPj4gfHwNCj4+ICsJCSAgICAobG9jYWwtPnF1ZXVlX3N0b3BfcmVhc29uc1tzZGF0YS0+
dmlmLmNhYl9xdWV1ZV0NCj4+ID09IDAgJiYNCj4+ICsJCSAgICAgc2tiX3F1ZXVlX2VtcHR5KCZs
b2NhbC0+cGVuZGluZ1tzZGF0YS0NCj4+PiB2aWYuY2FiX3F1ZXVlXSkpKSB7DQo+PiArCQkJZm9y
IChhYyA9IDA7IGFjIDwgbl9hY3M7IGFjKyspIHsNCj4+ICsJCQkJaW50IGFjX3F1ZXVlID0gc2Rh
dGEtDQo+Pj4gdmlmLmh3X3F1ZXVlW2FjXTsNCj4+ICsNCj4+ICsJCQkJaWYgKGxvY2FsLQ0KPj4+
IHF1ZXVlX3N0b3BfcmVhc29uc1thY19xdWV1ZV0gPT0gMCAmJg0KPj4gKwkJCQkgICAgc2tiX3F1
ZXVlX2VtcHR5KCZsb2NhbC0NCj4+PiBwZW5kaW5nW2FjX3F1ZXVlXSkpDQo+PiArCQkJCQluZXRp
Zl9zdGFydF9zdWJxdWV1ZShzZGF0YS0NCj4+PiBkZXYsIGFjKTsNCj4+ICsJCQl9DQo+PiArCQl9
DQo+PiArCQlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZsb2NhbC0NCj4+PiBxdWV1ZV9zdG9wX3Jl
YXNvbl9sb2NrLCBmbGFncyk7DQo+PiArCX0NCj4+ICsNCj4+ICsJbXV0ZXhfdW5sb2NrKCZsb2Nh
bC0+aWZsaXN0X210eCk7DQo+PiArfQ0KPg0KPiBJIHJlYWxseSB3b3VsZCBwcmVmZXIgd2UgY291
bGQgc2ltcGx5IGF2b2lkIGRvaW5nIHRoZXNlIG1hbmlwdWxhdGlvbnMNCj4gd2hpbGUgdGhlIGlu
dGVyZmFjZSBpcyBVUCBhbmQgY2FuIGhhdmUgZGF0YSBxdWV1ZWQuDQoNCkFncmVlZC4NCg0KPg0K
Pj4gKysrIGIvbmV0L21hYzgwMjExL2tleS5jDQo+PiBAQCAtMjA4LDEzICsyMDgsMjUgQEAgc3Rh
dGljIGludCBpZWVlODAyMTFfa2V5X2VuYWJsZV9od19hY2NlbChzdHJ1Y3QNCj4+IGllZWU4MDIx
MV9rZXkgKmtleSkNCj4+ICAgCWNhc2UgV0xBTl9DSVBIRVJfU1VJVEVfR0NNUF8yNTY6DQo+PiAg
IAkJLyogYWxsIG9mIHRoZXNlIHdlIGNhbiBkbyBpbiBzb2Z0d2FyZSAtIGlmIGRyaXZlcg0KPj4g
Y2FuICovDQo+PiAgIAkJaWYgKHJldCA9PSAxKQ0KPj4gLQkJCXJldHVybiAwOw0KPj4gKwkJCWdv
dG8gY2hlY2tfODAyM190eHJ4Ow0KPj4gICAJCWlmIChpZWVlODAyMTFfaHdfY2hlY2soJmtleS0+
bG9jYWwtPmh3LA0KPj4gU1dfQ1JZUFRPX0NPTlRST0wpKQ0KPj4gICAJCQlyZXR1cm4gLUVJTlZB
TDsNCj4+IC0JCXJldHVybiAwOw0KPj4gKwkJZ290byBjaGVja184MDIzX3R4cng7DQo+PiAgIAlk
ZWZhdWx0Og0KPj4gICAJCXJldHVybiAtRUlOVkFMOw0KPj4gICAJfQ0KPj4gKw0KPj4gK2NoZWNr
XzgwMjNfdHhyeDoNCj4+ICsJLyogV2hlbiBzdyBjcnlwdG8gaXMgZW5hYmxlZCBtYWtlIHN1cmUg
ZGF0YSB0eC9yeCBoYXBwZW5zDQo+PiArCSAqIGluIDgwMi4xMSBmb3JtYXQuDQo+PiArCSAqLw0K
Pj4gKwlpZiAoa2V5LT5sb2NhbC0+ZGF0YV84MDIxMV9oZHJfb2ZmbG9hZGVkKSB7DQo+PiArCQly
dG5sX2xvY2soKTsNCj4+ICsJCWllZWU4MDIxMV9pZl9jb25maWdfODAyMTFfaGRyX29mZmwoa2V5
LT5sb2NhbCwNCj4+IGZhbHNlKTsNCj4+ICsJCXJ0bmxfdW5sb2NrKCk7DQo+PiArCX0NCj4+ICsN
Cj4+ICsJcmV0dXJuIDA7DQo+PiAgIH0NCj4NCj4gV2h5IG5vdCBqdXN0IHJlZnVzZSB0aGUga2V5
IGluc3RlYWQ/IEl0IGFsc28gc2VlbXMgd3JvbmcgdG8gZG8gYW55dGhpbmcNCj4gd2l0aCBsb2Nh
bC0+IGhlcmUsIGl0IHNob3VsZCBiZSBwZXIgaW50ZXJmYWNlLg0KDQpDb3JyZWN0LiBIZXJlIGFs
c28gZW5jYXAvZGVjYXAgdHlwZSBzd2l0Y2ggaGFwcGVucywgdGhpcyBjYW4gYmUgYXZvaWRlZCBq
dXN0DQpyZWZ1c2luZyB0aGUga2V5Lg0KDQo+DQo+PiArKysgYi9uZXQvbWFjODAyMTEvc3RhdHVz
LmMNCj4+IEBAIC01MDYsMTIgKzUwNiwxNCBAQCBzdGF0aWMgdm9pZCBpZWVlODAyMTFfcmVwb3J0
X3VzZWRfc2tiKHN0cnVjdA0KPj4gaWVlZTgwMjExX2xvY2FsICpsb2NhbCwNCj4+ICAgCQkJCSAg
ICAgIHN0cnVjdCBza19idWZmICpza2IsIGJvb2wNCj4+IGRyb3BwZWQpDQo+PiAgIHsNCj4+ICAg
CXN0cnVjdCBpZWVlODAyMTFfdHhfaW5mbyAqaW5mbyA9IElFRUU4MDIxMV9TS0JfQ0Ioc2tiKTsN
Cj4+IC0Jc3RydWN0IGllZWU4MDIxMV9oZHIgKmhkciA9ICh2b2lkICopc2tiLT5kYXRhOw0KPj4g
KwlzdHJ1Y3QgaWVlZTgwMjExX2hkciAqaGRyOw0KPj4gICAJYm9vbCBhY2tlZCA9IGluZm8tPmZs
YWdzICYgSUVFRTgwMjExX1RYX1NUQVRfQUNLOw0KPj4NCj4+ICAgCWlmIChkcm9wcGVkKQ0KPj4g
ICAJCWFja2VkID0gZmFsc2U7DQo+Pg0KPj4gKwloZHIgPSAodm9pZCAqKXNrYi0+ZGF0YTsNCj4N
Cj4gVGhhdCBjaGFuZ2UgbWFrZSBubyBzZW5zZS4NCg0KWWVzLCBJIGZvcmdvdCB0byByZW1vdmUg
dGhpcy4NCg0KPg0KPj4gICAJaWYgKGluZm8tPmZsYWdzICYgSUVFRTgwMjExX1RYX0lOVEZMX01M
TUVfQ09OTl9UWCkgew0KPj4gICAJCXN0cnVjdCBpZWVlODAyMTFfc3ViX2lmX2RhdGEgKnNkYXRh
Ow0KPj4NCj4+IEBAIC05NDUsNiArOTQ3LDg1IEBAIHZvaWQgaWVlZTgwMjExX3R4X3N0YXR1cyhz
dHJ1Y3QgaWVlZTgwMjExX2h3DQo+PiAqaHcsIHN0cnVjdCBza19idWZmICpza2IpDQo+PiAgIH0N
Cj4+ICAgRVhQT1JUX1NZTUJPTChpZWVlODAyMTFfdHhfc3RhdHVzKTsNCj4+DQo+PiArdm9pZCBp
ZWVlODAyMTFfdHhfc3RhdHVzXzgwMjMoc3RydWN0IGllZWU4MDIxMV9odyAqaHcsDQo+PiArCQkJ
ICAgICAgc3RydWN0IGllZWU4MDIxMV92aWYgKnZpZiwNCj4+ICsJCQkgICAgICBzdHJ1Y3Qgc2tf
YnVmZiAqc2tiKQ0KPg0KPiBJIHRoaW5rIHRoaXMgY291bGQgc2hhcmUgc29tZSBjb2RlIHdpdGgg
dGhlIDgwMi4xMSB2ZXJzaW9uPw0KPg0KPj4gKwkvKiBYWFg6IEFkZCBhIGdlbmVyaWMgaGVscGVy
IGZvciB0aGlzICovDQo+PiArCWlmIChzZGF0YS0+dmlmLnR5cGUgPT0gTkw4MDIxMV9JRlRZUEVf
QVAgfHwNCj4+ICsJICAgIHNkYXRhLT52aWYudHlwZSA9PSBOTDgwMjExX0lGVFlQRV9BUF9WTEFO
IHx8DQo+PiArCSAgICBzZGF0YS0+dmlmLnR5cGUgPT0gTkw4MDIxMV9JRlRZUEVfQURIT0MpDQo+
PiArCQlldGhlcl9hZGRyX2NvcHkocmFfYWRkciwgZWhkci0+aF9kZXN0KTsNCj4NCj4gbml0LCBi
dXQgdGhlICJBIiBpbiAiUkEiIGFscmVhZHkgbWVhbnMgYWRkcmVzcyAuLi4gOikNCg0KU3VyZSwg
dGhhbmtzLg0KDQo+DQo+IFlvdSBhbHNvIGRvbid0IG5lZWQgdG8gY29weSBpdCAtIGp1c3Qga2Vl
cGluZyBhIHBvaW50ZXIgc2hvdWxkIGJlIGZpbmU/DQoNClJpZ2h0Lg0KDQo+DQo+PiArCS8qIFRP
RE86IEhhbmRsZSBmcmFtZXMgcmVxdWlyaW5nIHdpZmkgdHggc3RhdHVzIHRvIGJlDQo+PiBub3Rp
ZmllZCAqLw0KPj4gKwlpZiAoc2tiLT5zayAmJiBza2Jfc2hpbmZvKHNrYiktPnR4X2ZsYWdzICYN
Cj4+IFNLQlRYX1dJRklfU1RBVFVTKQ0KPj4gKwkJZ290byBvdXRfZnJlZTsNCj4NCj4gU3VyZWx5
IHlvdSBzaG91bGRuJ3QgZnJlZSB0aGVtLCBldmVuIGlmIHlvdSBkb24ndCBoYW5kbGUgdGhlIHN0
YXR1cz8hDQoNCkNvcnJlY3QsIEkgdGhpbmsgd2UgY2FuIHN0aWxsIHBhc3MgdGhlIGZyYW1lIHRv
IGdvIHRocm91Z2ggZXZlbiBpZiB0eCBzdGF0dXMNCmlzIG5vdCBoYW5kbGVkLg0KDQpWYXNhbnRo
DQo=
^ permalink raw reply
* Re: [PATCH 5/8] linux: drop __bitwise__ everywhere
From: Greg Kroah-Hartman @ 2016-12-15 11:51 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Russell King, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, Johannes Berg,
Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless, Kalle Valo,
Jiri Slaby, Lee Duncan, Chris Leech, James E.J. Bottomley,
Martin K. Petersen, Nicholas A. Bellinger, Jason Wang,
Alexander Aring, Stefan Schmidt, David S. Miller,
linux-arm-kernel, linux-samsung-soc, linux-raid, netdev,
linux-wireless, linux-mm, open-iscsi, linux-scsi, target-devel,
virtualization, linux-wpan
In-Reply-To: <1481778865-27667-6-git-send-email-mst@redhat.com>
On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/arm/plat-samsung/include/plat/gpio-cfg.h | 2 +-
> drivers/md/dm-cache-block-types.h | 6 +++---
> drivers/net/ethernet/sun/sunhme.h | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
> include/linux/mmzone.h | 2 +-
> include/linux/serial_core.h | 4 ++--
> include/linux/types.h | 4 ++--
> include/scsi/iscsi_proto.h | 2 +-
> include/target/target_core_base.h | 2 +-
> include/uapi/linux/virtio_types.h | 6 +++---
> net/ieee802154/6lowpan/6lowpan_i.h | 2 +-
> net/mac80211/ieee80211_i.h | 4 ++--
> 12 files changed, 20 insertions(+), 20 deletions(-)
for include/linux/serial_core.h:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
From: Felix Fietkau @ 2016-12-15 13:32 UTC (permalink / raw)
To: Thiagarajan, Vasanthakumar, Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <58528607.7090101@qti.qualcomm.com>
On 2016-12-15 13:01, Thiagarajan, Vasanthakumar wrote:
> On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote:
>>> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
>>> + * implementing 802.11 encap/decap for data frames changed.
>>> */
>>> enum ieee80211_conf_changed {
>>> IEEE80211_CONF_CHANGE_SMPS = BIT(1),
>>> @@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
>>> IEEE80211_CONF_CHANGE_CHANNEL = BIT(6),
>>> IEEE80211_CONF_CHANGE_RETRY_LIMITS = BIT(7),
>>> IEEE80211_CONF_CHANGE_IDLE = BIT(8),
>>> + IEEE80211_CONF_CHANGE_80211_HDR_OFFL = BIT(9),
>>> };
>>
>> Given the requirements (PN check, etc.) I'm not sure how this can
>> change dynamically?
>
> I agree. Dynamic switch part is buggy, we can start with not allowing
> interfaces resulting in dynamic switch.
Does this mean that when bringing up multiple interfaces, users would
need to figure out the 'magic' order that works?
- Felix
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload
From: Johannes Berg @ 2016-12-15 13:53 UTC (permalink / raw)
To: Felix Fietkau, Thiagarajan, Vasanthakumar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <85c98160-3ee9-07db-cb4c-9e300f0ba798@nbd.name>
> > I agree. Dynamic switch part is buggy, we can start with not
> > allowing interfaces resulting in dynamic switch.
>
> Does this mean that when bringing up multiple interfaces, users would
> need to figure out the 'magic' order that works?
I think we need to talk about hardware capabilities at this point.
I was assuming that it would actually be possible to run two interfaces
with different paths here concurrently - is that not true? If that's
not true, then we absolutely _need_ dynamic switching, I agree with
Felix, but then we have a pretty big complication to figure out. But we
can't let this optimisation affect user experience.
johannes
^ permalink raw reply
* [PATCH 1/3] nfc: nxp-nci: Remove unneeded linux/miscdevice.h include
From: Corentin Labbe @ 2016-12-15 14:22 UTC (permalink / raw)
To: clement.perrochaud, charles.gorand, lauro.venancio,
aloisio.almeida, sameo, linux-nfc, linux-wireless
Cc: linux-kernel, Corentin Labbe
drivers/nfc/nxp-nci/i2c.c does not use any miscdevice, so this patch
remove this unnecessary inclusion.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/nfc/nxp-nci/i2c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 36099e5..0356515 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -29,7 +29,6 @@
#include <linux/delay.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
-#include <linux/miscdevice.h>
#include <linux/module.h>
#include <linux/nfc.h>
#include <linux/gpio/consumer.h>
--
2.10.2
^ permalink raw reply related
* [PATCH 2/3] nfc: pn544: Remove unneeded linux/miscdevice.h include
From: Corentin Labbe @ 2016-12-15 14:22 UTC (permalink / raw)
To: clement.perrochaud, charles.gorand, lauro.venancio,
aloisio.almeida, sameo, linux-nfc, linux-wireless
Cc: linux-kernel, Corentin Labbe
In-Reply-To: <20161215142246.6153-1-clabbe.montjoie@gmail.com>
drivers/nfc/pn544/i2c.c does not use any miscdevice, so this
patch remove this unnecessary inclusion.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/nfc/pn544/i2c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index f837c39..7030a47 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -25,7 +25,6 @@
#include <linux/of_gpio.h>
#include <linux/of_irq.h>
#include <linux/acpi.h>
-#include <linux/miscdevice.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/nfc.h>
--
2.10.2
^ permalink raw reply related
* [PATCH 3/3] nfc: st21nfca: Remove unneeded linux/miscdevice.h include
From: Corentin Labbe @ 2016-12-15 14:22 UTC (permalink / raw)
To: clement.perrochaud, charles.gorand, lauro.venancio,
aloisio.almeida, sameo, linux-nfc, linux-wireless
Cc: linux-kernel, Corentin Labbe
In-Reply-To: <20161215142246.6153-1-clabbe.montjoie@gmail.com>
drivers/nfc/st21nfca/i2c.c does not use any miscdevice, so this patch
remove this unnecessary inclusion.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/nfc/st21nfca/i2c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
index 5a82f55..d16f58a 100644
--- a/drivers/nfc/st21nfca/i2c.c
+++ b/drivers/nfc/st21nfca/i2c.c
@@ -25,7 +25,6 @@
#include <linux/of_irq.h>
#include <linux/of_gpio.h>
#include <linux/acpi.h>
-#include <linux/miscdevice.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/nfc.h>
--
2.10.2
^ permalink raw reply related
* RE: ath10k firmware sends probes on DFS channels without radar detection
From: Jean-Pierre Tosoni @ 2016-12-15 15:22 UTC (permalink / raw)
To: 'Jouni Malinen'; +Cc: linux-wireless, ath10k
In-Reply-To: <20161214195805.GA15022@w1.fi>
Jouni,
Thanks for the suggestion, I already tried something like this in wmi.c,
with the same result:
- Before patching the firmware scans DFS channels actively (with probes).
- After patching, the firmware scans DFS channels passively *until* any
beacon is received on the DFS channel. When *any* beacon is seen, the
firmware decides to scan actively on its own, without any new IR/RADAR
info from the driver.
So, your patch is required but not sufficient.
Somehow I was able to overcome this by reloading the regulation domain
in the radio card before each scan request:
////// awful patch ahead ////////
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2842,7 +2842,9 @@ static int ath10k_update_channel_list(st
ch->chan_radar =
!!(channel->flags & IEEE80211_CHAN_RADAR);
- passive = channel->flags & IEEE80211_CHAN_NO_IR;
+ passive = channel->flags & (IEEE80211_CHAN_NO_IR |
+ IEEE80211_CHAN_RADAR);
+
ch->passive = passive;
ch->freq = channel->center_freq;
@@ -3548,6 +3550,9 @@ static int ath10k_start_scan(struct ath1
lockdep_assert_held(&ar->conf_mutex);
+ if (ar->state == ATH10K_STATE_ON)
+ ath10k_regd_update(ar);
+
ret = ath10k_wmi_start_scan(ar, arg);
if (ret)
return ret;
////////////////////////////////////////
...But this sets a terrible penalty on performance when applied to
background scan.
On 12/14/16 20:58 Jouni Malinen wrote:
>
> On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
> > This follows on the previous discussion
> > "Client station sends probes on DFS channels"
> >
> > Problem:
> > The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> > wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
> > 4.7; because they can send probes for 600s when no AP is around.
> >
> > Analysis:
> > The problem seems to lie in the firmware, which regards the presence
> > of *any* beacon as a proof that the channel is radar-clean for 600s.
>
> I don't think this is really firmware, but cfg80211 regulatory code and
> how it interacts with ath10k..
>
> > - there is no obvious fix working in ath10k.
> > - the issue does not show up with other mac80211 devices like ath9k.
> > - wpa_supplicant considers this is a kernel issue [2]
>
> There seems to be a difference between ath9k (mac80211-based Probe Request
> frame sending) and ath10k (firmware) in this area for active scanning.
> mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR while ath10k
> uses IEEE80211_CHAN_NO_IR. I'd assume this difference results in ath10k
> using cfg80211 beacon hints (etc.) to update the NO_IR flag and that might
> be behind the difference you see.
>
> Could you check whether the following change gets you the behavior you
> want to see here? I have not had a chance to test this yet, but based on
> code review, it looks like something that brings the same behavior to
> ath10k that ath9k has for this through mac80211.
>
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index aa545a1..758dbbd 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k
> *ar)
> ch->chan_radar =
> !!(channel->flags & IEEE80211_CHAN_RADAR);
>
> - passive = channel->flags & IEEE80211_CHAN_NO_IR;
> + passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> + IEEE80211_CHAN_RADAR);
> ch->passive = passive;
>
> ch->freq = channel->center_freq;
>
> --
> Jouni Malinen PGP id EFC895FA
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-12-15 15:33 UTC (permalink / raw)
To: Kalle Valo
Cc: Sebastian Reichel, Pavel Machek, Michal Kazior, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel, Luis R. Rodriguez
In-Reply-To: <87d1gtli57.fsf@purkki.adurom.net>
On Thu Dec 15 09:18:44 2016 Kalle Valo <kvalo@codeaurora.org> wrote:
> (Adding Luis because he has been working on request_firmware() lately)
>
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > > > So no, there is no argument against... request_firmware() in
> > > > fallback mode with userspace helper is by design blocking and
> > > > waiting for userspace. But waiting for some change in DTS in
> > > > kernel is just nonsense.
> > >
> > > I would just mark the wlan device with status = "disabled" and
> > > enable it in the overlay together with adding the NVS & MAC info.
> >
> > So if you think that this solution make sense, we can wait what net
> > wireless maintainers say about it...
> >
> > For me it looks like that solution can be:
> >
> > extending request_firmware() to use only userspace helper
>
> I haven't followed the discussion very closely but this is my preference
> what drivers should do:
>
> 1) First the driver should do try to get the calibration data and mac
> address from the device tree.
>
Ok, but there is no (dynamic, device specific) data in DTS for N900. So 1) is noop.
> 2) If they are not in DT the driver should retrieve the calibration data
> with request_firmware(). BUT with an option for user space to
> implement that with a helper script so that the data can be created
> dynamically, which I believe openwrt does with ath10k calibration
> data right now.
Currently there is flag for request_firmware() that it should fallback to user helper if direct VFS access not find needed firmware.
But this flag is not suitable as /lib/firmware already provides default (not device specific) calibration data.
So I would suggest to add another flag/function which will primary use user helper.
> > and load mac address also via request_firmware() either by appending
> > it into NVS data or via separate call
>
> I'm not really fan of the idea providing permanent mac address through
> request_firmware(). For example, how to handle multiple devices on the
> same host, would there be a need for some kind of bus ids encoded to the
> filename? And what about devices with multiple mac addresses?
For N900 there is only one wl1251 device. And... wl12xx is already using appended MAC address in calibration data read by request firmware. So reason why I prefer similar usage also for wl1251.
> I wish there would be a better way than request_firmware() to provide
> the permanent mac addresses from user space (if device tree is not
> available), I just don't know what that could be :) But if we would
> start to use request_firmware() for this at least there should be a
> wider concensus about that and it should be properly documented, just
> like the device tree bindings.
>
> --
> Kalle Valo
I do not know about any other, so reason why I'm asking :-) and there are my proposed solutions. If you (or any other) came up with better we can discuss about it :-)
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics
From: Mohammed Shafi Shajakhan @ 2016-12-15 16:26 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <1859306.unY1Rqbrx8@debian64>
Hello Christian,
On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote:
> On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> > > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > > > goto free;
> > > > > }
> > > > >
> > > > > + if (!list_empty(&stats.peers))
> > > >
> > > > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> > > > for normal 'peer stats' ? Is this the fix intended, i had started a build to
> > > > check your change and we will keep you posted, does this fix displaying
> > > > 'rx_duration' in ath10k fw_stats.
> > > The idea is not to queue any "extended peer stats" when there where no "peer stats" to
> > > begin with. Because otherwise, the function is still vulnerable to OOM since the
> > > extended peers stats will be queued unchecked (not that this is currently a problem).
> >
> > [shafi] list_splice_tail_init should still check for non-empty 'peers_extd' list
> > and append if required ? please let me know if i am still missing something
> Well, you can also count the entries in peers_extd and delete the old entries
> if they start to overflow. If you want to do it differently, please go ahead.
>
[shafi] sorry for the delay (got stuck up with something else), I will add some prints explicitly
and keep you posted ASAP. Since the extended peer stats gets updated periodically I
would like to confirm the debug linked list associated to the extended peer
stats does not overflows and potentially cause OOM.
regards,
shafi
^ permalink raw reply
* Re: ath10k firmware sends probes on DFS channels without radar detection
From: Ben Greear @ 2016-12-15 16:32 UTC (permalink / raw)
To: Jean-Pierre Tosoni, 'Jouni Malinen'; +Cc: linux-wireless, ath10k
In-Reply-To: <00f501d256e7$0f8d5380$2ea7fa80$@acksys.fr>
On 12/15/2016 07:22 AM, Jean-Pierre Tosoni wrote:
> Jouni,
>
> Thanks for the suggestion, I already tried something like this in wmi.c,
> with the same result:
>
> - Before patching the firmware scans DFS channels actively (with probes).
>
> - After patching, the firmware scans DFS channels passively *until* any
> beacon is received on the DFS channel. When *any* beacon is seen, the
> firmware decides to scan actively on its own, without any new IR/RADAR
> info from the driver.
>
> So, your patch is required but not sufficient.
>
> Somehow I was able to overcome this by reloading the regulation domain
> in the radio card before each scan request:
>
> ////// awful patch ahead ////////
>
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -2842,7 +2842,9 @@ static int ath10k_update_channel_list(st
> ch->chan_radar =
> !!(channel->flags & IEEE80211_CHAN_RADAR);
>
> - passive = channel->flags & IEEE80211_CHAN_NO_IR;
> + passive = channel->flags & (IEEE80211_CHAN_NO_IR |
> + IEEE80211_CHAN_RADAR);
So, should we add a new flag in firmware and driver that means 'really-no-IR', or
should the NO_IR flag here just always make the firmware never do IR when probing
regardless of whether it has seen beacons or not?
Thanks,
Ben
> +
> ch->passive = passive;
>
> ch->freq = channel->center_freq;
> @@ -3548,6 +3550,9 @@ static int ath10k_start_scan(struct ath1
>
> lockdep_assert_held(&ar->conf_mutex);
>
> + if (ar->state == ATH10K_STATE_ON)
> + ath10k_regd_update(ar);
> +
> ret = ath10k_wmi_start_scan(ar, arg);
> if (ret)
> return ret;
>
> ////////////////////////////////////////
>
> ...But this sets a terrible penalty on performance when applied to
> background scan.
>
>
> On 12/14/16 20:58 Jouni Malinen wrote:
>>
>> On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
>>> This follows on the previous discussion
>>> "Client station sends probes on DFS channels"
>>>
>>> Problem:
>>> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
>>> wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
>>> 4.7; because they can send probes for 600s when no AP is around.
>>>
>>> Analysis:
>>> The problem seems to lie in the firmware, which regards the presence
>>> of *any* beacon as a proof that the channel is radar-clean for 600s.
>>
>> I don't think this is really firmware, but cfg80211 regulatory code and
>> how it interacts with ath10k..
>>
>>> - there is no obvious fix working in ath10k.
>>> - the issue does not show up with other mac80211 devices like ath9k.
>>> - wpa_supplicant considers this is a kernel issue [2]
>>
>> There seems to be a difference between ath9k (mac80211-based Probe Request
>> frame sending) and ath10k (firmware) in this area for active scanning.
>> mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR while ath10k
>> uses IEEE80211_CHAN_NO_IR. I'd assume this difference results in ath10k
>> using cfg80211 beacon hints (etc.) to update the NO_IR flag and that might
>> be behind the difference you see.
>>
>> Could you check whether the following change gets you the behavior you
>> want to see here? I have not had a chance to test this yet, but based on
>> code review, it looks like something that brings the same behavior to
>> ath10k that ath9k has for this through mac80211.
>>
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index aa545a1..758dbbd 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k
>> *ar)
>> ch->chan_radar =
>> !!(channel->flags & IEEE80211_CHAN_RADAR);
>>
>> - passive = channel->flags & IEEE80211_CHAN_NO_IR;
>> + passive = channel->flags & (IEEE80211_CHAN_NO_IR |
>> + IEEE80211_CHAN_RADAR);
>> ch->passive = passive;
>>
>> ch->freq = channel->center_freq;
>>
>> --
>> Jouni Malinen PGP id EFC895FA
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC v2 11/11] ath10k: Added sdio support
From: Valo, Kalle @ 2016-12-15 16:40 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <1479496971-19174-12-git-send-email-erik.stromdahl@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> Initial HIF sdio/mailbox implementation.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
> ---
> drivers/net/wireless/ath/ath10k/Kconfig | 6 +
> drivers/net/wireless/ath/ath10k/Makefile | 3 +
> drivers/net/wireless/ath/ath10k/sdio.c | 1860 ++++++++++++++++++++++++=
++++++
> drivers/net/wireless/ath/ath10k/sdio.h | 276 +++++
> 4 files changed, 2145 insertions(+)
> create mode 100644 drivers/net/wireless/ath/ath10k/sdio.c
> create mode 100644 drivers/net/wireless/ath/ath10k/sdio.h
AFAIK the sdio firmware binary is different from pci and usb. And as all
the firmware images need to coexist in the same repository I suspect we
can't continue to use firmware-N.bin for both pcie and sdio (and in
future usb). So should we somehow rename the sdio firmware filename to
something else, like firmware-sdio-N.bin?
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics
From: Mohammed Shafi Shajakhan @ 2016-12-15 16:43 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <20161215162659.GA8030@atheros-ThinkPad-T61>
Hi Christian,
I am also thinking, as of now there is not much use in appending
the extended peer stats (which gets periodically ) to the linked list
'&ar->debug.fw_stats.peers_extd)' and should we get rid of the below
(and the required cleanup as well)
list_splice_tail_init(&stats.peers_extd,
&ar->debug.fw_stats.peers_extd);
since rx_duration is getting updated periodically to the per sta
information. Kindly let me know your thoughts about this.
regards,
shafi
On Thu, Dec 15, 2016 at 09:56:59PM +0530, Mohammed Shafi Shajakhan wrote:
> Hello Christian,
>
> On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote:
> > On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote:
> > > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan wrote:
> > > > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> > > > > > goto free;
> > > > > > }
> > > > > >
> > > > > > + if (!list_empty(&stats.peers))
> > > > >
> > > > > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
> > > > > for normal 'peer stats' ? Is this the fix intended, i had started a build to
> > > > > check your change and we will keep you posted, does this fix displaying
> > > > > 'rx_duration' in ath10k fw_stats.
> > > > The idea is not to queue any "extended peer stats" when there where no "peer stats" to
> > > > begin with. Because otherwise, the function is still vulnerable to OOM since the
> > > > extended peers stats will be queued unchecked (not that this is currently a problem).
> > >
> > > [shafi] list_splice_tail_init should still check for non-empty 'peers_extd' list
> > > and append if required ? please let me know if i am still missing something
> > Well, you can also count the entries in peers_extd and delete the old entries
> > if they start to overflow. If you want to do it differently, please go ahead.
> >
> [shafi] sorry for the delay (got stuck up with something else), I will add some prints explicitly
> and keep you posted ASAP. Since the extended peer stats gets updated periodically I
> would like to confirm the debug linked list associated to the extended peer
> stats does not overflows and potentially cause OOM.
>
> regards,
> shafi
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics
From: Christian Lamparter @ 2016-12-15 17:24 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <20161215164338.GB8030@atheros-ThinkPad-T61>
Hello Shafi,
On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote:
> I am also thinking, as of now there is not much use in appending
> the extended peer stats (which gets periodically ) to the linked list
> '&ar->debug.fw_stats.peers_extd)' and should we get rid of the below
> (and the required cleanup as well)
>
> list_splice_tail_init(&stats.peers_extd,
> &ar->debug.fw_stats.peers_extd);
>
>
> since rx_duration is getting updated periodically to the per sta
> information. Kindly let me know your thoughts about this.
Yes, of course. I see what your are trying to do and I think it's much better
to get rid of peers_extd and ath10k_fw_extd_stats_peers_free.
Regards,
Christian
^ 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