- 02 Jun, 2014 40 commits
-
-
Ezequiel Garcia authored
The buffers for the TSO headers belong to a DMA coherent region which is allocated at ndo_open() time, and released at ndo_stop() time. Therefore, and contrary to the TSO payload descriptor buffers, the TSO header buffers don't need to be unmapped. This commit adds a check to detect a TSO header buffer and explicitly prevent the unmap. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ezequiel Garcia authored
After adding proper stop/wake thresholds, we can expect a queue to never be full and drop the NETDEV_TX_BUSY return path. In any case, if the queue cannot accommodate a TSO packet, the packet would be discarded. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ezequiel Garcia authored
Currently small MSS values may require too many TSO descriptors for the default queue size. This commit prevents this situation by fixing the maximum supported TSO number of segments to 100 and by setting a minimum Tx queue size. The minimum Tx queue size is set so that at least 2 worst-case skb can be accommodated. In addition, the queue stop and wake thresholds values are adjusted accordingly. The queue is stopped when there's room for only 1 worst-case skb and waked when the number of descriptors is half that value. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ezequiel Garcia authored
This commit fixes the current dropped packet count by doing it properly, increasing the count when a packet is discarded; i.e. the packet is not processed and the driver returns NETDEV_TX_OK. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ezequiel Garcia authored
The buffers for the TSO headers belong to a DMA coherent region which is allocated at ndo_open() time, and released at ndo_stop() time. Therefore, and contrary to the TSO payload descriptor buffers, the TSO header buffers don't need to be unmapped. This commit adds a check to detect a TSO header buffer and explicitly prevent the unmap. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ezequiel Garcia authored
The Tx descriptor release code currently calls dma_unmap_single() and dev_kfree_skb_any() if the descriptor is associated with a non-NULL skb. This is true only for the last fragment of the packet. This is wrong, however, since every descriptor buffer is DMA mapped and needs to be unmapped. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ezequiel Garcia authored
Currently small MSS values may require too many TSO descriptors for the default queue size. This commit prevents this situation by fixing the maximum supported TSO number of segments to 100 and by setting a minimum Tx queue size. The minimum Tx queue size is set so that at least 2 worst-case skb can be accommodated. In addition, the queue stop and wake thresholds values are adjusted accordingly. The queue is stopped when there's room for only 1 worst-case skb and waked when the number of descriptors is half that value. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ezequiel Garcia authored
This driver has no need for a custom NAPI weigth. Use the default one, which has the same value. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
dingtianhong authored
Add netpoll support to macvlan devices. Based on the netpoll support in the 802.1q vlan code. Tested and macvlan could work well with netconsole. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Bjørn Mork says: ==================== cdc_ncm: fixes and conversion to sysfs API After considering the comments received after the ethtool coalesce support was commited, I have ended up concluding that we should remove it again, while we can, before it hits a release. The idea was not well enough thought through, and all comments received pointed to advantages of using a sysfs based API instead. This series removes the ethtool coalesce support and replaces it with sysfs attributes in a driver specific group under the netdev. The first 3 patches are unrelated fixes: patch 1: reducing truesize as discussed patch 2: fixing a potentional buffer overrun when changing tx_max patch 3: prevent framing errors when changing rx_max Changes v2: - minor editorial changes to patch 8, as suggested by Peter Stuge ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Adding documentation for all the driver specific sysfs attributes. Cc: Peter Stuge <peter@stuge.se> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
The min_tx_pkt variable decides the cutoff point where the driver will stop padding out NTBs to maximum size. The padding is a tradeoff where we use some USB bus bandwidth to allow the device to receive fixed size buffers. Different devices will have different optimal settings, spanning from no padding at all to padding every NTB. There is no way to automatically figure out which setting is best for a specific device. The default value is a reasonable tradeoff, calculated based on the USB packet size and out NTB max size. This may have to be changed along with any tx_max changes. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
The mandatory GetNtbParameters control request is an important part of the host <-> device protocol negotiation in CDC NCM (and CDC MBIM). It gives device limits which the host must obey when configuring the protocol aggregation variables. The driver will enforce this by rejecting attempts to set any of the tunable variables to a value which is not supported by the device. Exporting the parameter block helps userspace decide which values are allowed without resorting to trial and error. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
The ethtool coalesce API is not applicable for this driver. Forcing it to fit the NCM aggregation redefined the API in a driver specific way, which is much worse than defining a clean new API. These ethtool coalesce functions have therefore been replaced by a new sysfs API. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Attach a driver specific sysfs group to the netdev, and use it for the rx/tx aggregation variables. The datagram aggregation defined by the CDC NCM specification is specific to this device class (including CDC MBIM). Using the ethtool interrupt coalesce API as an interface to the aggregation parameters redefined that API in a driver specific and confusing way. A sysfs group - makes it clear that this is a driver specific userspace API, and - allows us to export the real values instead of some translated version, and - lets us include more aggregation variables which were impossible to force into the ethtool API. Additionally, using sysfs allows tuning the driver on space constrained hosts where userspace tools like ethtool are undesired. Suggested-by: Peter Stuge <peter@stuge.se> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
It doesn't matter whether the buffer size goes up or down. We have to keep usbnet and device syncronized to be able to split transfers at the correct boundaries. The spec allow skipping short packets when using max sized transfers. If we don't tell usbnet about our new expected rx buffer size, then it will merge and/or split NTBs. The driver does not support this, and the result will be lots of framing errors. Fix by always reallocating usbnet rx buffers when the rx_max value changes. Fixes: 68864abf ("net: cdc_ncm: support rx_max/tx_max updates when running") Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
We are calling usbnet_start_xmit() to flush any remaining data, depending on the side effect that tx_curr_skb is set to NULL, ensuring a new allocation using the updated tx_max. But this side effect will only happen if there were any cached data ready to transmit. If not, then an empty tx_curr_skb is still allocated using the old tx_max size. Free it to avoid a buffer overrun. Fixes: 68864abf ("net: cdc_ncm: support rx_max/tx_max updates when running") Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
Cloning the big skbs we use for USB buffering chokes up TCP and SCTP because the socket memory limits are hitting earlier than they should. It is better to unconditionally copy the unwrapped packets to freshly allocated skbs. Reported-by: Jim Baxter <jim_baxter@mentor.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
dingtianhong authored
The macvlan dev should always have the same mac address like lowerdev when in the passthru mode, change the mac address alone will break the work mechanism, so when the lowerdev or macvlan mac address changes, we should propagate the changes to another dev. v1->v2: Allow macvlan dev to change mac address for passthru mode and propagate to lowerdev. v2->v3: Don't set the mac address to the lower dev's unicast address for passthru mode when mac address changes. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chen-Yu Tsai authored
The following patch moved device tree interrupt resolution into platform_get_irq_byname: ad69674e of/irq: do irq resolution in platform_get_irq_byname() As a result, the function no longer only return -ENXIO on error. This breaks DT based probing of stmmac, as seen in test runs of linux-next next-20140526 cubie2-sunxi_defconfig: http://lists.linaro.org/pipermail/kernel-build-reports/2014-May/003659.html This patch makes the stmmac_platform probe function properly handle error codes, such as returning for deferred probing, and other codes returned by of_irq_get_by_name. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-nextDavid S. Miller authored
John W. Linville says: ==================== pull request: wireless-next 2014-06-02 Please pull this remaining batch of updates intended for the 3.16 stream... For the mac80211 bits, Johannes says: "The remainder for -next right now is mostly fixes, and a handful of small new things like some CSA infrastructure, the regdb script mW/dBm conversion change and sending wiphy notifications." For the bluetooth bits, Gustavo says: "Some more patches for 3.16. There is nothing really special here, just a bunch of clean ups, fixes plus some small improvements. Please pull." For the nfc bits, Samuel says: "We have: - Felica (Type3) tags support for trf7970a - Type 4b tags support for port100 - st21nfca DTS typo fix - A few sparse warning fixes" For the atheros bits, Kalle says: "Ben added support for setting antenna configurations. Michal improved warm reset so that we would not need to fall back to cold reset that often, an issue where ath10k stripped protected flag while in monitor mode and made module initialisation asynchronous to fix the problems with firmware loading when the driver is linked to the kernel. Luca removed unused channel_switch_beacon callbacks both from ath9k and ath10k. Marek fixed Protected Management Frames (PMF) when using Action Frames. Also we had other small fixes everywhere in the driver." Along with that, there are a handful of updates to a variety of drivers. This includes updates to at76c50x-usb, ath9k, b43, brcmfmac, mwifiex, rsi, rtlwifi, and wil6210. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Ideally, we would need to generate IP ID using a per destination IP generator. linux kernels used inet_peer cache for this purpose, but this had a huge cost on servers disabling MTU discovery. 1) each inet_peer struct consumes 192 bytes 2) inetpeer cache uses a binary tree of inet_peer structs, with a nominal size of ~66000 elements under load. 3) lookups in this tree are hitting a lot of cache lines, as tree depth is about 20. 4) If server deals with many tcp flows, we have a high probability of not finding the inet_peer, allocating a fresh one, inserting it in the tree with same initial ip_id_count, (cf secure_ip_id()) 5) We garbage collect inet_peer aggressively. IP ID generation do not have to be 'perfect' Goal is trying to avoid duplicates in a short period of time, so that reassembly units have a chance to complete reassembly of fragments belonging to one message before receiving other fragments with a recycled ID. We simply use an array of generators, and a Jenkin hash using the dst IP as a key. ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it belongs (it is only used from this file) secure_ip_id() and secure_ipv6_id() no longer are needed. Rename ip_select_ident_more() to ip_select_ident_segs() to avoid unnecessary decrement/increment of the number of segments. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Mack authored
Make of_mdiobus_link_phydev externally available. This fixes CONFIG_OF_MDIO=m. Signed-off-by: Daniel Mack <zonque@gmail.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 86f6cf41 ("net: of_mdio: add of_mdiobus_link_phydev()") Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Mack authored
Use int rather than u32 to fix the following warning: drivers/of/of_mdio.c:147 of_mdiobus_register() warn: unsigned 'addr' is never less than zero. Signed-off-by: Daniel Mack <zonque@gmail.com> Fixes: 8f838288 ("net: of_mdio: factor out code to parse a phy's 'reg' property") Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Alexander Duyck says: ==================== Provide common means for device address sync The following series implements a means for synchronizing both unicast and multicast addresses on a device interface. The code is based on the original implementation of dev_uc_sync that was available for syncing a VLAN to the lower dev. The original reason for coming up for this patch is a driver that is still in the early stages of development. The nearest driver I could find that appeared to have the same limitations as the driver I was working on was the Cisco enic driver. For this reason I chose it as the first driver to make use of this interface publicly. However, I do not have a Cisco enic interface so I have only been able to compile test any changes made to the driver. I tried to keep this change as simple as possible to avoid any issues. Any help with testing would be greatly appreciated. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
This change updates the enic driver to make use of __dev_uc_sync and __dev_mc_sync calls. Previously the driver was doing its own list management by storing the mc_addr and uc_addr list in a 32 address array. With this change the sync data is stored in the netdev_addr_list structures and instead we just track how many addresses we have written to the device. When we encounter 32 we stop and print a message as occurred previously with the old approach. Other than the core change the only other bit needed was to propagate the constant attribute with the MAC address as there were several spots where is twas only passed as a u8 * instead of a const u8 *. This patch is meant to maintain the original functionality without the use of the mc_addr and uc_addr arrays. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Acked-by: Govindarajulu Varadarajan <_govind@gmx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
This change provides a function to be used in order to break the ndo_set_rx_mode call into a set of address add and remove calls. The code is based on the implementation of dev_uc_sync/dev_mc_sync. Since they essentially do the same thing but with only one dev I simply named my functions __dev_uc_sync/__dev_mc_sync. I also implemented an unsync version of the functions as well to allow for cleanup on close. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Alexander Aring says: ==================== 6lowpan: fragmentation fixes This patch series fix the 6LoWPAN fragmentation which are in two cases broken. The first case is if we have exactly two 6LoWPAN fragments only. This is fixed by patch "6lowpan_rtnl: fix fragmentation with two fragments". The second case is a off by one issue if we have payload which hits the fragment boundary. Both issues are introduced by commit d4b2816d ("6lowpan: fix fragmentation"). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Aring authored
This patch fix a off by one error while fragmentation. If the frag_cap value is equal to skb_unprocessed value we need to stop the fragmentation loop because the last fragment which has a size of skb_unprocessed fits into the frag capability size. This issue was introduced by commit d4b2816d ("6lowpan: fix fragmentation"). Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Aring authored
This patch fix the 6LoWPAN fragmentation for the case if we have exactly two fragments. The problem is that the (skb_unprocessed >= frag_cap) condition is always false on the second fragment after sending the first fragment. A fragmentation with only one fragment doesn't make any sense. The solution is that we use a do while loop here, that ensures we sending always a minimum of two fragments if we need a fragmentation. This issue was introduced by commit d4b2816d ("6lowpan: fix fragmentation"). Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Emil Goode authored
The following patch removed unnecessary spin_lock/unlock calls in ethtool_ops callback functions. In the second and final version of the patch one spin_lock call was left behind. commit cab6715c Author: Yang Wei <Wei.Yang@windriver.com> Date: Sun May 25 09:53:44 2014 +0800 net: driver: stmicro: Remove some useless the lock protection This introduced the following sparse warning: drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c:424:1: warning: context imbalance in 'stmmac_get_pauseparam' - different lock contexts for basic block Signed-off-by: Emil Goode <emilgoode@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Denis ChengRq authored
the local variable ops and n_ops were just read out from family, and not changed, hence no need to assign back. Validation functions should operate on const parameters and not change anything. Signed-off-by: Cheng Renquan <crquan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
John W. Linville authored
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
-
David S. Miller authored
This reverts commit 70a640d0. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Boyd authored
We shouldn't be using regulator_get_optional() here. These regulators are always present as part of the physical design and there isn't any way to use an internal regulator or change the source of the reference voltage via software. Given that the only users of this driver in the kernel are DT based, this change should be transparent to them even if they don't specify any supplies because the regulator framework will insert dummy supplies as needed. Cc: Nishanth Menon <nm@ti.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Mark Brown <broonie@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Daniel Borkmann says: ==================== BPF + test suite updates These are the last bigger BPF changes that I had in my todo queue for now. As the first two patches from this series contain additional test cases for the test suite, I have rebased them on top of current net-next with the set from [1] applied to avoid introducing any unnecessary merge conflicts. For details, please refer to the individual patches. Test suite runs fine with the set applied. [1] http://patchwork.ozlabs.org/patch/352599/ http://patchwork.ozlabs.org/patch/352600/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
Commit 9739eef1 ("net: filter: make BPF conversion more readable") started to introduce helper macros similar to BPF_STMT()/BPF_JUMP() macros from classic BPF. However, quite some statements in the filter conversion functions remained in the old style which gives a mixture of block macros and non block macros in the code. This patch makes the block macros itself more readable by using explicit member initialization, and converts the remaining ones where possible to remain in a more consistent state. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
This patch finally allows us to get rid of the BPF_S_* enum. Currently, the code performs unnecessary encode and decode workarounds in seccomp and filter migration itself when a filter is being attached in order to overcome BPF_S_* encoding which is not used anymore by the new interpreter resp. JIT compilers. Keeping it around would mean that also in future we would need to extend and maintain this enum and related encoders/decoders. We can get rid of all that and save us these operations during filter attaching. Naturally, also JIT compilers need to be updated by this. Before JIT conversion is being done, each compiler checks if A is being loaded at startup to obtain information if it needs to emit instructions to clear A first. Since BPF extensions are a subset of BPF_LD | BPF_{W,H,B} | BPF_ABS variants, case statements for extensions can be removed at that point. To ease and minimalize code changes in the classic JITs, we have introduced bpf_anc_helper(). Tested with test_bpf on x86_64 (JIT, int), s390x (JIT, int), arm (JIT, int), i368 (int), ppc64 (JIT, int); for sparc we unfortunately didn't have access, but changes are analogous to the rest. Joint work with Alexei Starovoitov. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Mircea Gherzan <mgherzan@gmail.com> Cc: Kees Cook <keescook@chromium.org> Acked-by: Chema Gonzalez <chemag@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
This check tests that overloading BPF_LD | BPF_ABS with an always invalid BPF extension, that is SKF_AD_MAX, fails to make sure classic BPF behaviour is correct in filter checker. Also, we add a test for loading at packet offset SKF_AD_OFF-1 which should pass the filter, but later on fail during runtime. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
Also add a test for the scratch memory store that first fills all slots and then sucessively reads all of them back adding up to A, and eventually returning A. This and the previous M[] test with alternating fill/spill will detect possible JIT errors on M[]. Suggested-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-