aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-03-14net: mvneta: Fix spinlock usageGregory CLEMENT1-5/+6
In the previous patch, the spinlock was not initialized. While it didn't cause any trouble yet it could be a problem to use it uninitialized. The most annoying part was the critical section protected by the spinlock in mvneta_stop(). Some of the functions could sleep as pointed when activated CONFIG_DEBUG_ATOMIC_SLEEP. Actually, in mvneta_stop() we only need to protect the is_stopped flagged, indeed the code of the notifier for CPU online is protected by the same spinlock, so when we get the lock, the notifer work is done. Reported-by: Patrick Uiterwijk <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdictFlorian Westphal1-9/+7
Zefir Kurtisi reported kernel panic with an openwrt specific patch. However, it turns out that mainline has a similar bug waiting to happen. Once NF_HOOK() returns the skb is in undefined state and must not be used. Moreover, the okfn must consume the skb to support async processing (NF_QUEUE). Current okfn in this spot doesn't consume it and caller assumes that NF_HOOK return value tells us if skb was freed or not, but thats wrong. It "works" because no in-tree user registers a NFPROTO_BRIDGE hook at LOCAL_IN that returns STOLEN or NF_QUEUE verdicts. Once we add NF_QUEUE support for nftables bridge this will break -- NF_QUEUE holds the skb for async processing, caller will erronoulsy return RX_HANDLER_PASS and on reinject netfilter will access free'd skb. Fix this by pushing skb up the stack in the okfn instead. NB: It also seems dubious to use LOCAL_IN while bypassing PRE_ROUTING completely in this case but this is how its been forever so it seems preferable to not change this. Cc: Felix Fietkau <[email protected]> Cc: Zefir Kurtisi <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Tested-by: Zefir Kurtisi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14Merge branch 'for-upstream' of ↵David S. Miller12-24/+102
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2016-03-12 Here's the last bluetooth-next pull request for the 4.6 kernel. - New USB ID for AR3012 in btusb - New BCM2E55 ACPI ID - Buffer overflow fix for the Add Advertising command - Support for a new Bluetooth LE limited privacy mode - Fix for firmware activation in btmrvl_sdio - Cleanups to mac802154 & 6lowpan code Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-14Merge branch 'dsa-cleanups'David S. Miller14-48/+53
Andrew Lunn says: ==================== DSA cleanup and fixes The RFC patchset for re-architecturing DSA probing contains a few standalone patches, either clean up or fixes. This pulls them out for submission. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-14phy: fixed: Fix removal of phys.Andrew Lunn3-8/+12
The fixed phys delete function simply removed the fixed phy from the internal linked list and freed the memory. It however did not unregister the associated phy device. This meant it was still possible to find the phy device on the mdio bus. Make fixed_phy_del() an internal function and add a fixed_phy_unregister() to unregisters the phy device and then uses fixed_phy_del() to free resources. Modify DSA to use this new API function, so we don't leak phys. Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14dsa: dsa: Fix freeing of fixed-phys from user ports.Andrew Lunn1-3/+0
All ports types can have a fixed PHY associated with it. Remove the check which limits removal to only CPU and DSA ports. Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14dsa: Destroy fixed link phys after the phy has been disconnectedAndrew Lunn1-12/+12
The phy is disconnected from the slave in dsa_slave_destroy(). Don't destroy fixed link phys until after this, since there can be fixed linked phys connected to ports. Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14dsa: slave: Don't reference NULL pointer during phy_disconnectAndrew Lunn1-4/+8
When the phy is disconnected, the parent pointer to the netdev it was attached to is set to NULL. The code then tries to suspend the phy, but dsa_slave_fixed_link_update needs the parent pointer to determine which switch the phy is connected to. So it dereferenced a NULL pointer. Check for this condition. Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14dsa: Rename mv88e6123_61_65 to mv88e6123 to be consistentAndrew Lunn10-23/+23
All the drivers support multiple chips, but mv88e6123_61_65 is the only one that reflects this in its naming. Change it to be consistent with the other drivers. Signed-off-by: Andrew Lunn <[email protected]> Reviewed-by: Vivien Didelot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14Merge branch 'of_mdio-checks'David S. Miller1-5/+5
Sergei Shtylyov says: ==================== of_mdio: use IS_ERR_OR_NULL() and PTR_ERR_OR_ZERO() Here's the set of 3 patches against DaveM's 'net-next.git' repo. They deal with some error checks in the device tree MDIO code... ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-14of_mdio: use PTR_ERR_OR_ZERO()Sergei Shtylyov1-3/+3
PTR_ERR_OR_ZERO() is open coded in of_phy_register_fixed_link(), so just call it directly... Signed-off-by: Sergei Shtylyov <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14of_mdio: use IS_ERR_OR_NULL()Sergei Shtylyov1-1/+1
IS_ERR_OR_NULL() is open coded in of_mdiobus_register_phy(), so just call it directly... Signed-off-by: Sergei Shtylyov <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14of_mdio: mdio_device_create() never returns NULLSergei Shtylyov1-1/+1
mdio_device_create() never returns NULL, thus checking for it in of_mdiobus_register_device() is pointless... Suggested-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Sergei Shtylyov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14Merge branch 'thunderx-phy'David S. Miller8-281/+535
David Daney says: ==================== net/phy: Improvements to Cavium Thunder MDIO code. Changes from v1: - In 1/3 Add back check for non-OF objects in bgx_init_of_phy(). It is probably not necessary, but better safe than sorry... The firmware on many Cavium Thunder systems configures the MDIO bus hardware to be probed as a PCI device. In order to use the MDIO bus drivers in this configuration, we must add PCI probing to the driver. There are two parts to this set of three patches: 1) Cleanup the PHY probing code in thunder_bgx.c to handle the case where there is no PHY attached to a port, as well as being more robust in the face of driver loading order by use of -EPROBE_DEFER. 2) Split mdio-octeon.c into two drivers, one with platform probing, and the other with PCI probing. Common code is shared between the two. Tested on several different Thunder and OCTEON systems, also compile tested on x86_64. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-14phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.David Daney4-2/+225
The Cavium Thunder SoCs have multiple MIDO buses that are part of a single PCI device. To model this in the device tree we call the PCI parent device a "cavium,thunder-8890-mdio-nexus", it has several children, one for each MDIO bus. The MDIO bus hardware is identical to that found in the OCTEON SoCs, so we use that code for things that are not part of the PCI driver probe/remove Signed-off-by: David Daney <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14phy: mdio-octeon: Refactor into two files/modulesDavid Daney5-268/+292
A follow-on patch uses PCI probing to find the Thunder MDIO hardware. In preparation for this, split out the common code into a new file mdio-cavium.c, which will be used by both the existing OCTEON driver, and the new Thunder PCI based driver. As part of the refactoring simplify the struct cavium_mdiobus by removing fields that are only ever used in the probe function and can just as well be local variables. Use readq/writeq in preference to readq_relaxed/writeq_relaxed as the relaxed form was an optimization for an early chip revision, and the MDIO drivers are not performance bottlenecks that need optimization in the first place. Signed-off-by: David Daney <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: thunderx: Cleanup PHY probing code.David Daney1-11/+18
Remove the call to force the octeon-mdio driver to be loaded. Allow the standard driver loading mechanisms to load the PHY drivers, and use -EPROBE_DEFER to cause the BGX driver to be probed only after the PHY drivers are available. Reorder the setting of MAC addresses and PHY probing to allow BGX LMACs with no attached PHY to still be assigned a MAC address. Signed-off-by: David Daney <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: mvneta: Add missing hotplug notifier transitionAnna-Maria Gleixner1-0/+2
The mvneta_percpu_notifier() hotplug callback lacks handling of the CPU_DOWN_FAILED case. That means, if CPU_DOWN_PREPARE failes, the driver is not well configured on the CPU. Add handling for CPU_DOWN_FAILED[_FROZEN] hotplug notifier transition to setup the driver. Cc: Thomas Petazzoni <[email protected]> Cc: [email protected] Signed-off-by: Anna-Maria Gleixner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14fsl/fman: fix dtsec_set_tx_pause_framesIgal Liberman1-4/+3
Fix a bug introduced in e06a03b (fsl/fman: fix the pause_time test) When pause_time is set to '0' - pause frames are disabled and there's no need to apply dTSEC-A003 Errata workaround. Signed-off-by: Igal Liberman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14Documentation: networking: phy.txt: Add missing functionsFlorian Fainelli1-0/+10
Some new development in PHYLIB added new function pointers to the struct phy_driver, document these. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/InMartin KaFai Lau9-4/+34
Per RFC4898, they count segments sent/received containing a positive length data segment (that includes retransmission segments carrying data). Unlike tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments carrying no data (e.g. pure ack). The patch also updates the segs_in in tcp_fastopen_add_skb() so that segs_in >= data_segs_in property is kept. Together with retransmission data, tcpi_data_segs_out gives a better signal on the rxmit rate. v6: Rebase on the latest net-next v5: Eric pointed out that checking skb->len is still needed in tcp_fastopen_add_skb() because skb can carry a FIN without data. Hence, instead of open coding segs_in and data_segs_in, tcp_segs_in() helper is used. Comment is added to the fastopen case to explain why segs_in has to be reset and tcp_segs_in() has to be called before __skb_pull(). v4: Add comment to the changes in tcp_fastopen_add_skb() and also add remark on this case in the commit message. v3: Add const modifier to the skb parameter in tcp_segs_in() v2: Rework based on recent fix by Eric: commit a9d99ce28ed3 ("tcp: fix tcpi_segs_in after connection establishment") Signed-off-by: Martin KaFai Lau <[email protected]> Cc: Chris Rapier <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Marcelo Ricardo Leitner <[email protected]> Cc: Neal Cardwell <[email protected]> Cc: Yuchung Cheng <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14vmxnet3: fix lock imbalance in vmxnet3_tq_xmit()Arnd Bergmann1-4/+4
A recent bug fix rearranged the code in vmxnet3_tq_xmit() in a way that left the error handling for oversized headers unlock a lock that had not been taken yet. Gcc warns about the incorrect use of the 'flags' variable because of that: drivers/net/vmxnet3/vmxnet3_drv.c: In function 'vmxnet3_tq_xmit.constprop': include/linux/spinlock.h:246:3: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized] This changes the error handling path to 'goto' the end of the function beyond the lock/unlock pair. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: cec05562fb1d ("vmxnet3: avoid calling pskb_may_pull with interrupts disabled") Signed-off-by: David S. Miller <[email protected]>
2016-03-14Merge branch 'net-gcc60-fixes'David S. Miller5-9/+9
Arnd Bergmann says: ==================== net: gcc-6.0 warning fixes I've just installed gcc-6.0 to see what kinds of new warnings we get. It turns out that it's actually really useful once I disabled -Wunused-const-variable, and all of the warnings it found in network drivers seem valid. Sorry for the bad timing in the merge window, but I figured it would be better to send the fixes as I found the bugs rather than waiting for the next cycle. The first three look appropriate for stable backports. The other two only fix a gcc warning about incorrect whitespace, probably not worth backporting those. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: caif: fix misleading indentationArnd Bergmann1-1/+1
gcc points out code that is not indented the way it is interpreted: net/caif/cfpkt_skbuff.c: In function 'cfpkt_setlen': net/caif/cfpkt_skbuff.c:289:4: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] return cfpkt_getlen(pkt); ^~~~~~ net/caif/cfpkt_skbuff.c:286:3: note: ...this 'else' clause, but it is not else ^~~~ It is clear from the context that not returning here would be a bug, as we'd end up passing a negative length into a function that takes a u16 length, so it is not missing curly braces here, and I'm assuming that the indentation is the only part that's wrong about it. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14ath9k: fix misleading indentationArnd Bergmann1-2/+2
A cleanup patch in linux-3.18 moved around some code in the ath9k driver and left some code to be indented in a misleading way, made worse by the addition of some new code for p2p mode, as discovered by a new gcc-6 warning: drivers/net/wireless/ath/ath9k/init.c: In function 'ath9k_set_hw_capab': drivers/net/wireless/ath/ath9k/init.c:851:4: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation] hw->wiphy->iface_combinations = if_comb; ^~ drivers/net/wireless/ath/ath9k/init.c:847:3: note: ...this 'if' clause, but it is not if (ath9k_is_chanctx_enabled()) ^~ The code is in fact correct, but the indentation is not, so I'm reformatting it as it should have been after the original cleanup. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 499afaccf6f3 ("ath9k: Isolate ath9k_use_chanctx module parameter") Fixes: eb61f9f623f7 ("ath9k: advertise p2p dev support when chanctx") Signed-off-by: David S. Miller <[email protected]>
2016-03-14ath9k: fix buffer overrun for ar9287Arnd Bergmann1-4/+3
Code that was added back in 2.6.38 has an obvious overflow when accessing a static array, and at the time it was added only a code comment was put in front of it as a reminder to have it reviewed properly. This has not happened, but gcc-6 now points to the specific overflow: drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs': drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds] maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4]; ~~~~~~~~~~~~~~~~~~~~~~~~~^~~ It turns out that the correct array length exists in the local 'intercepts' variable of this function, so we can just use that instead of hardcoding '4', so this patch changes all three instances to use that variable. The other two instances were already correct, but it's more consistent this way. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs") Signed-off-by: David S. Miller <[email protected]>
2016-03-14farsync: fix off-by-one bug in fst_add_oneArnd Bergmann1-1/+1
gcc-6 finds an out of bounds access in the fst_add_one function when calculating the end of the mmio area: drivers/net/wan/farsync.c: In function 'fst_add_one': drivers/net/wan/farsync.c:418:53: error: index 2 denotes an offset greater than size of 'u8[2][8192] {aka unsigned char[2][8192]}' [-Werror=array-bounds] #define BUF_OFFSET(X) (BFM_BASE + offsetof(struct buf_window, X)) ^ include/linux/compiler-gcc.h:158:21: note: in definition of macro '__compiler_offsetof' __builtin_offsetof(a, b) ^ drivers/net/wan/farsync.c:418:37: note: in expansion of macro 'offsetof' #define BUF_OFFSET(X) (BFM_BASE + offsetof(struct buf_window, X)) ^~~~~~~~ drivers/net/wan/farsync.c:2519:36: note: in expansion of macro 'BUF_OFFSET' + BUF_OFFSET ( txBuffer[i][NUM_TX_BUFFER][0]); ^~~~~~~~~~ The warning is correct, but not critical because this appears to be a write-only variable that is set by each WAN driver but never accessed afterwards. I'm taking the minimal fix here, using the correct pointer by pointing 'mem_end' to the last byte inside of the register area as all other WAN drivers do, rather than the first byte outside of it. An alternative would be to just remove the mem_end member entirely. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14mlx4: add missing braces in verify_qp_parametersArnd Bergmann1-1/+2
The implementation of QP paravirtualization back in linux-3.7 included some code that looks very dubious, and gcc-6 has grown smart enough to warn about it: drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'verify_qp_parameters': drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3154:5: error: statement is indented as if it were guarded by... [-Werror=misleading-indentation] if (optpar & MLX4_QP_OPTPAR_ALT_ADDR_PATH) { ^~ drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3144:4: note: ...this 'if' clause, but it is not if (slave != mlx4_master_func_num(dev)) >From looking at the context, I'm reasonably sure that the indentation is correct but that it should have contained curly braces from the start, as the update_gid() function in the same patch correctly does. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 54679e148287 ("mlx4: Implement QP paravirtualization and maintain phys_pkey_cache for smp_snoop") Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: mediatek: check device_reset return codeArnd Bergmann1-1/+3
The device_reset() function may fail, so we have to check its return value, e.g. to make deferred probing work correctly. gcc warns about it because of the warn_unused_result attribute: drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function 'mtk_probe': drivers/net/ethernet/mediatek/mtk_eth_soc.c:1679:2: error: ignoring return value of 'device_reset', declared with attribute warn_unused_result [-Werror=unused-result] This adds the trivial error check to propagate the return value to the generic platform device probe code. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: mediatek: remove incorrect dma_mask assignmentArnd Bergmann1-3/+0
Device drivers should not mess with the DMA mask directly, but instead call dma_set_mask() etc if needed. In case of the mtk_eth_soc driver, the mask already gets set correctly when the device is created, and setting it again is against the documented API. This removes the incorrect setting. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: mediatek: use dma_addr_t correctlyArnd Bergmann1-1/+1
dma_alloc_coherent() expects a dma_addr_t pointer as its argument, not an 'unsigned int', and gcc correctly warns about broken code in the mtk_init_fq_dma function: drivers/net/ethernet/mediatek/mtk_eth_soc.c: In function 'mtk_init_fq_dma': drivers/net/ethernet/mediatek/mtk_eth_soc.c:463:13: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] This changes the type of the local variable to dma_addr_t. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: Fix use after free in the recvmmsg exit pathArnaldo Carvalho de Melo1-19/+19
The syzkaller fuzzer hit the following use-after-free: Call Trace: [<ffffffff8175ea0e>] __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:295 [<ffffffff851cc31a>] __sys_recvmmsg+0x6fa/0x7f0 net/socket.c:2261 [< inline >] SYSC_recvmmsg net/socket.c:2281 [<ffffffff851cc57f>] SyS_recvmmsg+0x16f/0x180 net/socket.c:2270 [<ffffffff86332bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 And, as Dmitry rightly assessed, that is because we can drop the reference and then touch it when the underlying recvmsg calls return some packets and then hit an error, which will make recvmmsg to set sock->sk->sk_err, oops, fix it. Reported-and-Tested-by: Dmitry Vyukov <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Kostya Serebryany <[email protected]> Cc: Sasha Levin <[email protected]> Fixes: a2e2725541fa ("net: Introduce recvmmsg socket syscall") http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14Merge branch 'thunderx-perf'David S. Miller2-29/+53
Sunil Goutham says: ==================== net: thunderx: Performance enhancement changes Below patches attempts to improve performance by reducing no of atomic operations while allocating new receive buffers and reducing cache misses by adjusting nicvf structure elements. Changes from v1: No changes, resubmitting a fresh as per David's suggestion. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: thunderx: Adjust nicvf structure to reduce cache missesSunil Goutham1-22/+30
Adjusted nicvf structure such that all elements used in hot path like napi, xmit e.t.c fall into same cache line. This reduced no of cache misses and resulted in ~2% increase in no of packets handled on a core. Also modified elements with :1 notation to boolean, to be consistent with other element definitions. Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: thunderx: Set recevie buffer page usage count in bulkSunil Goutham2-8/+24
Instead of calling get_page() for every receive buffer carved out of page, set page's usage count at the end, to reduce no of atomic calls. Signed-off-by: Sunil Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14tipc: make sure IPv6 header fits in skb headroomRichard Alpe1-1/+1
Expand headroom further in order to be able to fit the larger IPv6 header. Prior to this patch this caused a skb under panic for certain tipc packets when using IPv6 UDP bearer(s). Signed-off-by: Richard Alpe <[email protected]> Acked-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14Merge branch 'mvneta-hwbm'David S. Miller25-47/+1568
Gregory CLEMENT says: ==================== API set for HW Buffer management This is the sixth version of the API set for HW Buffer management (that was initially submitted here: http://thread.gmane.org/gmane.linux.kernel/2125152). This version is just a rebasing onto the last net-next. I also added the Tested-by flag from Sebastian Careba : "The patch set applies successfully and it works well, no more Samba issues any longer". For the record in the previous versions I made the following changes: v4 -> v5: - Add a field with the size of the buffer of the pool was added. It then allow to fix some misused size in the mvneta_bm code when using the new framework. - Add a new patch from Marcin for sram allowing to require non-bufferable access to the memory. It was needed for the hardware buffer management of the mvneta. - Fix the build issue notified by the 0-day builder when building the drivers as module. v3 -> v4 - Fix build issue when HWBM is not selected v2 -> v3 - Make a HWBM and a SWBM version of the mvneta_rx() function in order to reduce the the conditional code. Kept a condition inside the mvneta_poll because specializing this function would have means duplicating 95% of the code. - Put back the register_netdev() call at the end of the mvneta_probe() function. In order to have a unique ID for each port, just used a global variable in the driver. - Added a fix from Marcin in the "net: mvneta: bm: add support for hardware buffer management" patch: "when dropping packets, only buffer pointers passed from BM to descriptors have to be returned to the pool. In submitted version after closing the port and mvneta_rxq_deinit(), it was very likely that a lot of fake buffers are added to the pool, because all descriptors took part in iteration." - Removed the select MVNETA_BM from the Kconfig, it will let the user the choice to use not use it if they want. v1 -> v2 - The hardware buffer management helpers are no more built by default and now depend on a hidden config symbol which has to be selected by the driver if needed - The hwbm_pool_refill() and hwbm_pool_add() now receive a gfp_t as argument allowing the caller to specify the flag it needs. - buf_num is now tested to ensure there is no wrapping - A spinlock has been added to protect the hwbm_pool_add() function in SMP or irq context. - used pr_warn instead of pr_debug in case of errors. - fixed the mvneta implementation by returning the buffer to the pool at various place instead of ignoring it. - Squashed "bus: mvenus-mbus: Fix size test for mvebu_mbus_get_dram_win_info" into bus: mvebu-mbus: provide api for obtaining IO and DRAM window information. - Added my signed-otf-by on all the patches as submitter of the series. - Renamed the dts patches with the pattern "ARM: dts: platform:" - Removed the patch "ARM: mvebu: enable SRAM support in mvebu_v7_defconfig" of this series and already applied it - Modified the order of the patches. In order to ease the test the branch mvneta-BM-framework-v6 is available at [email protected]:MISL-EBU-System-SW/mainline-public.git. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: mvneta: Use the new hwbm frameworkGregory CLEMENT4-112/+49
Now that the hardware buffer management framework had been introduced, let's use it. Tested-by: Sebastian Careba <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: add a hardware buffer management helper APIGregory CLEMENT4-0/+119
This basic implementation allows to share code between driver using hardware buffer management. As the code is hardware agnostic, there is few helpers, most of the optimization brought by the an HW BM has to be done at driver level. Tested-by: Sebastian Careba <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14net: mvneta: bm: add support for hardware buffer managementMarcin Wojtas7-39/+1285
Buffer manager (BM) is a dedicated hardware unit that can be used by all ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX path by sparing DRAM access on refilling buffer pool, hardware-based filling of descriptor ring data and better memory utilization due to HW arbitration for using 'short' pools for small packets. Tests performed with A388 SoC working as a network bridge between two packet generators showed increase of maximum processed 64B packets by ~20k (~555k packets with BM enabled vs ~535 packets without BM). Also when pushing 1500B-packets with a line rate achieved, CPU load decreased from around 25% without BM to 20% with BM. BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which are called external BP pools - BPPE. Allocating and releasing buffer pointers (BP) to/from BPPE is performed indirectly by write/read access to a dedicated internal SRAM, where internal BP pools (BPPI) are placed. BM hardware controls status of BPPE automatically, as well as assigning proper buffers to RX descriptors. For more details please refer to Functional Specification of Armada XP or 38x SoC. In order to enable support for a separate hardware block, common for all ports, a new driver has to be implemented ('mvneta_bm'). It provides initialization sequence of address space, clocks, registers, SRAM, empty pools' structures and also obtaining optional configuration from DT (please refer to device tree binding documentation). mvneta_bm exposes also a necessary API to mvneta driver, as well as a dedicated structure with BM information (bm_priv), whose presence is used as a flag notifying of BM usage by port. It has to be ensured that mvneta_bm probe is executed prior to the ones in ports' driver. In case BM is not used or its probe fails, mvneta falls back to use software buffer management. A sequence executed in mvneta_probe function is modified in order to have an access to needed resources before possible port's BM initialization is done. According to port-pools mapping provided by DT appropriate registers are configured and the buffer pools are filled. RX path is modified accordingly. Becaues the hardware allows a wide variety of configuration options, following assumptions are made: * using BM mechanisms can be selectively disabled/enabled basing on DT configuration among the ports * 'long' pool's single buffer size is tied to port's MTU * using 'long' pool by port is obligatory and it cannot be shared * using 'short' pool for smaller packets is optional * one 'short' pool can be shared among all ports This commit enables hardware buffer management operation cooperating with existing mvneta driver. New device tree binding documentation is added and the one of mvneta is updated accordingly. [[email protected]: removed the suspend/resume part] Signed-off-by: Marcin Wojtas <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14bus: mvebu-mbus: provide api for obtaining IO and DRAM window informationMarcin Wojtas2-0/+55
This commit enables finding appropriate mbus window and obtaining its target id and attribute for given physical address in two separate routines, both for IO and DRAM windows. This functionality is needed for Armada XP/38x Network Controller's Buffer Manager and PnC configuration. [[email protected]: Fix size test for mvebu_mbus_get_dram_win_info] Signed-off-by: Marcin Wojtas <[email protected]> [DRAM window information reference in LKv3.10] Signed-off-by: Evan Wang <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14ARM: dts: armada-xp-openblocks-ax3-4: Add BM supportGregory CLEMENT1-1/+18
Allow Openblock AX3 using hardware buffer management with mvneta. Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14ARM: dts: armada-xp: enable buffer manager support on Armada XP boardsMarcin Wojtas2-2/+36
Since mvneta driver supports using hardware buffer management (BM), in order to use it, board files have to be adjusted accordingly. This commit enables BM on AXP-DB and AXP-GP in same manner - because number of ports on those boards is the same as number of possible pools, each port is supposed to use single pool for all kind of packets. Moreover appropriate entry is added to 'soc' node ranges, as well as "okay" status for 'bm' and 'bm-bppi' (internal SRAM) nodes. Signed-off-by: Marcin Wojtas <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14ARM: dts: armada-xp: add buffer manager nodesMarcin Wojtas1-0/+19
Armada XP network controller supports hardware buffer management (BM). Since it is now enabled in mvneta driver, appropriate nodes can be added to armada-xp.dtsi - for the actual common BM unit (bm@c0000) and its internal SRAM (bm-bppi), which is used for indirect access to buffer pointer ring residing in DRAM. Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional parameters are supposed to be set in board files. Signed-off-by: Marcin Wojtas <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14ARM: dts: armada-38x: enable buffer manager support on Armada 38x boardsMarcin Wojtas5-4/+71
Since mvneta driver supports using hardware buffer management (BM), in order to use it, board files have to be adjusted accordingly. This commit enables BM on: * A385-DB-AP - each port has its own pool for long and common pool for short packets, * A388-ClearFog - same as above, * A388-DB - to each port unique 'short' and 'long' pools are mapped, * A388-GP - same as above. Moreover appropriate entry is added to 'soc' node ranges, as well as "okay" status for 'bm' and 'bm-bppi' (internal SRAM) nodes. [[email protected]: add suppport for the ClearFog board] Signed-off-by: Marcin Wojtas <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Acked-by: Russell King <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14ARM: dts: armada-38x: add buffer manager nodesMarcin Wojtas1-0/+19
Armada 38x network controller supports hardware buffer management (BM). Since it is now enabled in mvneta driver, appropriate nodes can be added to armada-38x.dtsi - for the actual common BM unit (bm@c8000) and its internal SRAM (bm-bppi), which is used for indirect access to buffer pointer ring residing in DRAM. Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional parameters are supposed to be set in board files. Signed-off-by: Marcin Wojtas <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14misc: sram: add optional ioremap without write combiningMarcin Wojtas2-1/+9
Some SRAM users may require non-bufferable access to the memory, which is impossible, because devm_ioremap_wc() is used for setting sram->virt_base. This commit adds optional flag 'no-memory-wc', which allow to choose remap method, using DT property. Documentation is updated accordingly. Signed-off-by: Marcin Wojtas <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-14Merge tag 'wireless-drivers-next-for-davem-2016-03-14' of ↵David S. Miller38-719/+4419
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers patches for 4.6 Major changes: rtl8xxxu * add 8723bu support wl18xx * add radar_debug_mode debugfs file for DFS testing ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-13Merge branch 'ipv4-ipv6-csums'David S. Miller40-184/+137
Alexander Duyck says: ==================== Fix differences between IPv4 and IPv6 TCP/UDP checksum calculation This patch series is meant to address the differences that exist between IPv4 and IPv6 in terms of checksum calculation. Specifically the IPv6 function csum_ipv6_magic treated length as a value that could be greater than 64K, while csum_tcpudp_magic was truncating the length at 16 bits. After looking over the code and giving it some thought I decided it would be best to update the IPv4 function so that it worked the same way the IPv6 one did. This allows us to get the same results given the same inputs for both functions. As a result we can use the same processes to reverse the calculation in the event we need to do something like remove the length of the pseudo-header checksum. I also took the opportunity to standardize things so that the parameters for these functions all use the correct types. IPv4 addresses are __be32, length should always be __u32, and protocol is a __u8. With this change in place it corrects an issue with UDP tunnels in which we were getting a checksum that was off by 1 when performing fragmentation on inner UDP packets. ==================== Signed-off-by: David S. Miller <[email protected]>
2016-03-13GSO/UDP: Use skb->len instead of udph->len to determine length of original skbAlexander Duyck1-5/+10
It is possible for tunnels to end up generating IP or IPv6 datagrams that are larger than 64K and expecting to be segmented. As such we need to deal with length values greater than 64K. In order to accommodate this we need to update the code to work with a 32b length value instead of a 16b one. Signed-off-by: Alexander Duyck <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.