- 06 Aug, 2015 17 commits
-
-
Guy Mishol authored
add option to dynamically configure the fw which debug traces to open Signed-off-by: Guy Mishol <guym@ti.com> Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Amitkumar Karwar authored
Preallocated event SKBs are getting reused for PCIe chipset. Their physical addresses are shared with firmware so that firmware can write data into them. This patch makes sure that SKB is cleared and length is set to default while submitting it to firmware. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Zhaoyang Liu <liuzy@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Zhaoyang Liu authored
System crash was observed if one of the driver initialisation commands is timed out. The reason is our timeout handler triggers firmware dump, meanwhile driver initialisation error paths have already freed the adapter structure. Firmware hasn't yet completely initialized. So collecting firmware dump is not needed in this case. Command timeout handler is modified in this patch to fix the crash issue. Signed-off-by: Zhaoyang Liu <liuzy@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Zhaoyang Liu authored
When WLAN interface is up and running, driver unload and load was causing command timeout error. We enable Rx data by updating RX ring read pointer in init_fw_port(). It should be done when FW is completely intialialised. Command timeout is fixed in this patch by moving init_fw_port() call to mwifiex_init_fw_complete(). Signed-off-by: Zhaoyang Liu <liuzy@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Xinming Hu authored
Variable pos is u8 here, so memcpy is needed to store u16 aid. At the same time, aid should be platform independent, upper layer utility(wpa_supplicant,etc.,) parse it as le16, so keep it le16 here. Signed-off-by: Xinming Hu <huxm@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Felix Fietkau authored
Use list_empty(&tid->list) instead Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Felix Fietkau authored
struct ath_atx_ac contains a list of active TIDs belonging to one WMM AC. This patch changes the code to track active station TIDs in the txq directly. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Janusz.Dziedzic@tieto.com authored
Setup rxfiler correctly for offchannel ctx. This fix problem we didn't configure rxfilter, next didn't receive probe requests and next failed p2p_find. This was seen when ath9k loaded with use_chanctx=1 Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Janusz.Dziedzic@tieto.com authored
While mac80211 setup this per HW, set same rxfilter configuration for all chanctx. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Janusz.Dziedzic@tieto.com authored
In case we will get ROC cancel from mac80211 we should not call ieee80211_remain_on_channel_expired(). In other case I hit such warning on MIPS and p2p negotiation failed (tested with use_chanctx=1). ath: phy0: Starting RoC period ath: phy0: Channel definition created: 2412 MHz ath: phy0: Assigned next_chan to 2412 MHz ath: phy0: Offchannel duration for chan 2412 MHz : 506632 ath: phy0: ath_chanctx_set_next: current: 2412 MHz, next: 2412 MHz ath: phy0: Stopping current chanctx: 2412 ath: phy0: Flush timeout: 200 ath: phy0: ath_chanctx_set_next: Set channel 2412 MHz ath: phy0: Set channel: 2412 MHz width: 0 ath: phy0: Reset to 2412 MHz, HT40: 0 fastcc: 0 ath: phy0: cur_chan: 2412 MHz, event: ATH_CHANCTX_EVENT_TSF_TIMER, state: ATH_CHANCTX_STATE_IDLE ath: phy0: ath_offchannel_channel_change: offchannel state: ATH_OFFCHANNEL_ROC_START ath: phy0: cur_chan: 2412 MHz, event: ATH_CHANCTX_EVENT_SWITCH, state: ATH_CHANCTX_STATE_IDLE ath: phy0: Cancel RoC ath: phy0: RoC aborted ath: phy0: RoC request on vif: 00:03:7f:4e:a0:cd, type: 1 duration: 500 ath: phy0: Starting RoC period ath: phy0: Channel definition created: 2412 MHz ath: phy0: Assigned next_chan to 2412 MHz ath: phy0: Offchannel duration for chan 2412 MHz : 506705 ath: phy0: ath_chanctx_set_next: current: 2412 MHz, next: 2412 MHz ath: phy0: ath_offchannel_channel_change: offchannel state: ATH_OFFCHANNEL_ROC_START ath: phy0: cur_chan: 2412 MHz, event: ATH_CHANCTX_EVENT_SWITCH, state: ATH_CHANCTX_STATE_IDLE ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3312 at drivers/net/wireless/ath/ath9k/main.c:2319 Modules linked in: ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Janusz.Dziedzic@tieto.com authored
Advertise p2p device support when ath9k loaded with use_chanctx=1. This will fix problem, when first interface is an AP and next we would like to run p2p_find. Before p2p find (scan phase) failed with EOPNOTSUPP. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Andreas Fenkart authored
600f5d90("mwifiex: cleanup ioctl wait queue and abstraction layer") introduced the wakeup_interruptible suppression in mwifiex_complete_cmd b1a47aa5("mwifiex: fix system hang issue in cmd timeout error case") then added wakup_interruptible to mwifiex_cmd_timeout_func the single place setting a status of ETIMEDOUT. Instead of doing extra work, using the standard call-chain will have the same effect: mwifiex_cancel_pending_ioctl -> mwifiex_recycle_cmd_node -> mwifiex_insert_cmd_to_free_q -> mwifiex_complete_cmd -> wake_up_interruptible The difference is that previously the condition was not set to true, but that's probably just an oversight in b1a47aa5 and shouldn't have any consequence Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Andreas Fenkart authored
CMD_F_CANCELED was used to abort mwifiex_process_cmdresp in case it already started or starts processing the cmd. But this was probably not working the way intended: - it is racy: mwifiex_process_cmdresp might already have passed that test and is continuing to use the cmd node being recycled - mwifiex_process_cmdresp repeatedly uses adapter->curr_cmd which we just set to NULL - mwifiex_recycle_cmd_node will clear the flag The reason why it probably works is that mwifiex_cancel_pending_ioctl is only called from mwifiex_cmd_timeout_func, where the there is little chance of a command response still arriving Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Andreas Fenkart authored
mwifiex_cancel_pending_ioctl is called only from mwifiex_cmd_timeout_func. There the wait_q status is set to -ETIMEDWAIT before calling this function. Whether we reset the status to -1 or leave it at -ETIMEDWAIT at end doesn't matter since both are != 0 hence mean failure Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Andreas Fenkart authored
standard call chain when releasing a cmd node: mwifiex_recycle_cmd_node -> mwifiex_insert_cmd_to_free_q -> mwifiex_complete_cmd, if wait_q_enabled calling mwifiex_complete_cmd explicitly and setting wait_q_enabled = false is redundant Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Andreas Fenkart authored
Since 1fb654fd("mmc: sdio: add reset callback to bus operations"), sdio cards can be power cycled using mmc_hw_reset. The use mmc_remove_host/mmc_add_host is discouraged, because these are internal functions to the mmc core and should only be used by mmc hosts Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 05 Aug, 2015 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next, they are: 1) A couple of cleanups for the netfilter core hook from Eric Biederman. 2) Net namespace hook registration, also from Eric. This adds a dependency with the rtnl_lock. This should be fine by now but we have to keep an eye on this because if we ever get the per-subsys nfnl_lock before rtnl we have may problems in the future. But we have room to remove this in the future by propagating the complexity to the clients, by registering hooks for the init netns functions. 3) Update nf_tables to use the new net namespace hook infrastructure, also from Eric. 4) Three patches to refine and to address problems from the new net namespace hook infrastructure. 5) Switch to alternate jumpstack in xtables iff the packet is reentering. This only applies to a very special case, the TEE target, but Eric Dumazet reports that this is slowing down things for everyone else. So let's only switch to the alternate jumpstack if the tee target is in used through a static key. This batch also comes with offline precalculation of the jumpstack based on the callchain depth. From Florian Westphal. 6) Minimal SCTP multihoming support for our conntrack helper, from Michal Kubecek. 7) Reduce nf_bridge_info per skbuff scratchpad area to 32 bytes, from Florian Westphal. 8) Fix several checkpatch errors in bridge netfilter, from Bernhard Thaler. 9) Get rid of useless debug message in ip6t_REJECT, from Subash Abhinov. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 04 Aug, 2015 10 commits
-
-
Subash Abhinov Kasiviswanathan authored
Make it similar to reject_tg() in ipt_REJECT. Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
-
David S. Miller authored
Hariprasad Shenai says: ==================== add meminfo, bist status and misc. fixes This patch series adds the following. Add support to dump memory address range of various hw modules Add support to dump edc bist status during ecc error Read correct bits of who am i register for T6 adapter and update T6 register range This patch series has been created against net-next tree and includes patches on cxgb4 and cxgb4vf driver. We have included all the maintainers of respective drivers. Kindly review the change and let us know in case of any review comments. V2: PATCH 3/4 ("cxgb4/cxgb4vf: read the correct bits of PL Who Am I register") Fix switch statement in get_chip_type() and some more style fixes based on review comment by Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hariprasad Shenai authored
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hariprasad Shenai authored
Read the correct bits of PL Who Am I for the Source PF field which has changed in T6 Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hariprasad Shenai authored
Add support to dump edc bist status for ECC data errors Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hariprasad Shenai authored
Add debug support to dump memory address ranges of various hardware modules of the adapter. Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Robert Shearman authored
In multiple locations there are checks for whether the label in hand is a reserved label or not using the arbritray value of 16. Factor this out into a #define for better maintainability and for documentation. Signed-off-by: Robert Shearman <rshearma@brocade.com> Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Robert Shearman says: ==================== lwtunnel: encap locally-generated ipv4 packets Locally-generated IPv4 packets, such as from applications running on the host or traceroute/ping currently don't have lwtunnel output redirected encap applied. However, they should do in the same way as for forwarded packets and this patch series addresses that. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Robert Shearman authored
lwtunnel encap is applied for forwarded packets, but not for locally-generated packets. This is because the output function is not overridden in __mkroute_output, unlike it is in __mkroute_input. The lwtunnel state is correctly set on the rth through the call to rt_set_nexthop, so all that needs to be done is to override the dst output function to be lwtunnel_output if there is lwtunnel state present and it requires output redirection. Signed-off-by: Robert Shearman <rshearma@brocade.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Robert Shearman authored
In the locally-generated packet path skb->protocol may not be set and this is required for the lwtunnel encap in order to get the lwtstate. This would otherwise have been set by ip_output or ip6_output so set skb->protocol prior to calling the lwtunnel encap function. Additionally set skb->dev in case it is needed further down the transmit path. Signed-off-by: Robert Shearman <rshearma@brocade.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 03 Aug, 2015 12 commits
-
-
Nikolay Aleksandrov authored
Instead of trying to access br->vlan_enabled directly use the provided helper br_vlan_enabled(). Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
Since the introduction of the BPF action in d23b8ad8 ("tc: add BPF based action"), late binding was not working as expected. I.e. setting the action part for a classifier only via 'bpf index <num>', where <num> is the index of an existing action, is being rejected by the kernel due to other missing parameters. It doesn't make sense to require these parameters such as BPF opcodes etc, as they are not going to be used anyway: in this case, they're just allocated/parsed and then freed again w/o doing anything meaningful. Instead, parse and verify the remaining parameters *after* the test on tcf_hash_check(), when we really know that we're dealing with creation of a new action or replacement of an existing one and where late binding is thus irrelevant. After patch, test case is now working: FOO="1,6 0 0 4294967295," tc actions add action bpf bytecode "$FOO" tc filter add dev foo parent 1: bpf bytecode "$FOO" flowid 1:1 action bpf index 1 tc actions show action bpf action order 0: bpf bytecode '1,6 0 0 4294967295' default-action pipe index 1 ref 2 bind 1 tc filter show dev foo filter protocol all pref 49152 bpf filter protocol all pref 49152 bpf handle 0x1 flowid 1:1 bytecode '1,6 0 0 4294967295' action order 1: bpf bytecode '1,6 0 0 4294967295' default-action pipe index 1 ref 2 bind 1 Late binding of a BPF action can be useful for preloading maps (e.g. before they hit traffic) in case of eBPF programs, or to share a single eBPF action with multiple classifiers. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vivien Didelot authored
At switch setup, _mv88e6xxx_stats_wait was called without holding the SMI mutex. Fix this by requesting the lock for this call. Also, return the _mv88e6xxx_stats_wait code, since it may fail. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Satish Ashok authored
Before this patch when a vid was not specified, the entry was added with vid 0 which is useless when vlan_filtering is enabled. This patch makes the entry to be added on all configured vlans when vlan filtering is enabled and respectively deleted from all, if the entry vid is 0. This is also closer to the way fdb works with regard to vid 0 and vlan filtering. Example: Setup: $ bridge vlan add vid 256 dev eth4 $ bridge vlan add vid 1024 dev eth4 $ bridge vlan add vid 64 dev eth3 $ bridge vlan add vid 128 dev eth3 $ bridge vlan port vlan ids eth3 1 PVID Egress Untagged 64 128 eth4 1 PVID Egress Untagged 256 1024 $ echo 1 > /sys/class/net/br0/bridge/vlan_filtering Before: $ bridge mdb add dev br0 port eth3 grp 239.0.0.1 $ bridge mdb dev br0 port eth3 grp 239.0.0.1 temp After: $ bridge mdb add dev br0 port eth3 grp 239.0.0.1 $ bridge mdb dev br0 port eth3 grp 239.0.0.1 temp vid 1 dev br0 port eth3 grp 239.0.0.1 temp vid 128 dev br0 port eth3 grp 239.0.0.1 temp vid 64 Signed-off-by: Satish Ashok <sashok@cumulusnetworks.com> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Toshiaki Makita says: ==================== Stacked vlan TSO for virtual devices Basically virtual devices do not need to segment double tagged packets. This patch set adds TSO feature for double tagged packets to several virtual devices, which can be realized by simply setting .ndo_features_check to passthru_features_check. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Toshiaki Makita authored
Tap devices don't need to segment multiple tagged packets. Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Toshiaki Makita authored
Bridge devices don't need to segment multiple tagged packets since thier ports can segment them. Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Toshiaki Makita authored
Veth devices don't need to segment multiple tagged packets. Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Toshiaki Makita authored
Macvlan/macvtap devices don't need to segment multiple tagged packets since the lower devices can segment them. Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Straightforward patch to add GRO processing to virtio_net. napi_complete_done() usage allows more aggressive aggregation, opted-in by setting /sys/class/net/xxx/gro_flush_timeout Tested: Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec, Rick Jones reported following results. One VM of each on a pair of OpenStack compute nodes with E5-2650Lv3 CPUs and Intel 82599ES-based NICs. So, two "before" and two "after" VMs. The OpenStack compute nodes were running OpenStack Kilo, with VxLAN encapsulation being used through OVS so no GRO coming-up the host stack. The compute nodes themselves were running a 3.14-based kernel. Single-stream netperf, CPU utilizations and thus service demands are based on intra-guest reported CPU. Throughput Mbit/s, bigger is better Min Median Average Max 4.2.0-rc3+ 1364 1686 1678 1938 4.2.0-rc3+flush1k 1824 2269 2275 2647 Send Service Demand, smaller is better Min Median Average Max 4.2.0-rc3+ 0.236 0.558 0.524 0.802 4.2.0-rc3+flush1k 0.176 0.503 0.471 0.738 Receive Service Demand, smaller is better. Min Median Average Max 4.2.0-rc3+ 1.906 2.188 2.191 2.531 4.2.0-rc3+flush1k 0.448 0.529 0.533 0.692 Signed-off-by: Eric Dumazet <edumazet@google.com> Tested-by: Rick Jones <rick.jones2@hp.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Suggested-by: Scott Feldman <sfeldma@gmail.com> Signed-off-by: Jiri Pirko <jiri@resnulli.us> Acked-by: Scott Feldman <sfeldma@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
rocker supports the transmission of scattered packets, so let the kernel know about it by setting the NETIF_F_SG bit in the device's features. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@resnulli.us> Acked-by: Scott Feldman <sfeldma@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-