- 14 Mar, 2016 40 commits
-
-
Eric Dumazet authored
On loaded TCP servers, looking at millions of sockets can hold cpu for many seconds, if the lookup condition is very narrow. (eg : ss dst 1.2.3.4 ) Better add a cond_resched() to allow other processes to access the cpu. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
The smc91x driver defines a macro that compares its argument to itself, apparently to get a true result while using its argument to avoid a warning about unused local variables. Unfortunately, this triggers a warning with gcc-6, as the comparison is obviously useless: drivers/net/ethernet/smsc/smc91x.c: In function 'smc_hardware_send_pkt': drivers/net/ethernet/smsc/smc91x.c:563:14: error: self-comparison always evaluates to true [-Werror=tautological-compare] if (!smc_special_trylock(&lp->lock, flags)) { This replaces the macro with another one that behaves similarly, with a cast to (void) to ensure the argument is used, and using a literal 'true' as its value. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
David S. Miller authored
Vivien Didelot says: ==================== net: dsa: finer bridging control This patchset renames the bridging routines of the DSA layer, make the unbridging routine return void, and rework the DSA netdev notifier handler, similar to what the Mellanox Spectrum driver does. Changes RFC -> v1: - drop unused NETDEV_PRECHANGEUPPER case - add Andrew's Tested-by tag ==================== Signed-off-by: -
Vivien Didelot authored
Rework the netdev event handler, similar to what the Mellanox Spectrum driver does, to easily welcome more events later (for example NETDEV_PRECHANGEUPPER) and use netdev helpers (such as netif_is_bridge_master). Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Acked-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Vivien Didelot authored
netdev_upper_dev_unlink() which notifies NETDEV_CHANGEUPPER, returns void, as well as del_nbp(). So there's no advantage to catch an eventual error from the port_bridge_leave routine at the DSA level. Make this routine void for the DSA layer and its existing drivers. Signed-off-by:
-
Vivien Didelot authored
Rename DSA port_join_bridge and port_leave_bridge routines to respectively port_bridge_join and port_bridge_leave in order to respect an implicit Port::Bridge namespace. Signed-off-by:
-
Maciej S. Szmigiero authored
According to figure 39 in PEB3086 data sheet, version 1.4 this indication replaces DR when layer 1 transition source state is F6. This fixes mISDN layer 1 getting stuck in F6 state in TE mode on Dialogic Diva 2.02 card (and possibly others) when NT deactivates it. Signed-off-by:
Maciej S. Szmigiero <mail@maciej.szmigiero.name> Acked-by:
Karsten Keil <keil@b1-systems.de> Signed-off-by:
-
Maciej S. Szmigiero authored
It looks like IPAC/ISAC chips register defines weren't in any particular order. Order them by their number to make it easier to spot holes. Signed-off-by:
-
Sergei Shtylyov authored
Some of the local variable intializers in the driver turned out to be pointless, kill 'em. Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
David S. Miller authored
Gregory CLEMENT says: ==================== Few mvneta fixes In this second version I split the last patch in two parts as requested. For the record the initial cover letter was: "here is a patch set of few fixes. Without the first one, a kernel configured with debug features ended to hang when the driver is built as a module and is removed. This is quite is annoying for debugging! The second patch fix a forgotten flag at the initial submission of the driver. The third patch is only really a cosmetic one so I have no problem to not apply it for 4.5 and wait for 4.6. I really would like to see the first one applied for 4.5 and for the second I let you judge if it something needed for now or that should wait the next release." ==================== Signed-off-by: -
Dmitri Epshtein authored
Some literal values are actually already defined by macros, so let's use them. [gregory.clement@free-electrons.com: split intial commit in two individual changes] Signed-off-by:
Dmitri Epshtein <dima@marvell.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Dmitri Epshtein authored
This commit corrects error printing when shutting down the port. [gregory.clement@free-electrons.com: split initial commit in two individual changes] Signed-off-by:
-
Dmitri Epshtein authored
Function eth_prepare_mac_addr_change() is called as part of MAC address change. This function check if interface is running. To enable change MAC address when interface is running: IFF_LIVE_ADDR_CHANGE flag must be set to dev->priv_flags field Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit") Cc: stable@vger.kernel.org Signed-off-by:
-
Gregory CLEMENT authored
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 <patrick@puiterwijk.org> Signed-off-by:
-
Florian Westphal authored
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 <nbd@openwrt.org> Cc: Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Tested-by:
Zefir Kurtisi <zefir.kurtisi@neratec.com> Signed-off-by:
-
David S. Miller authored
Merge branch 'for-upstream' of 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 authored
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: -
Andrew Lunn authored
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 <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
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 authored
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 authored
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 authored
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:
-
David S. Miller authored
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: -
Sergei Shtylyov authored
PTR_ERR_OR_ZERO() is open coded in of_phy_register_fixed_link(), so just call it directly... Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
Sergei Shtylyov authored
IS_ERR_OR_NULL() is open coded in of_mdiobus_register_phy(), so just call it directly... Signed-off-by:
-
Sergei Shtylyov authored
mdio_device_create() never returns NULL, thus checking for it in of_mdiobus_register_device() is pointless... Suggested-by:
-
David S. Miller authored
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 Daney authored
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 <david.daney@cavium.com> Signed-off-by:
-
David Daney authored
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 authored
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:
-
Anna-Maria Gleixner authored
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 <thomas.petazzoni@free-electrons.com> Cc: netdev@vger.kernel.org Signed-off-by:
Anna-Maria Gleixner <anna-maria@linutronix.de> Signed-off-by:
-
Igal Liberman authored
Fix a bug introduced in e06a03bd (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 <igal.liberman@freescale.com> Signed-off-by:
-
Florian Fainelli authored
Some new development in PHYLIB added new function pointers to the struct phy_driver, document these. Signed-off-by:
-
Martin KaFai Lau authored
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 a9d99ce2 ("tcp: fix tcpi_segs_in after connection establishment") Signed-off-by:
Martin KaFai Lau <kafai@fb.com> Cc: Chris Rapier <rapier@psc.edu> Cc: Eric Dumazet <edumazet@google.com> Cc: Marcelo Ricardo Leitner <mleitner@redhat.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Acked-by:
-
Arnd Bergmann authored
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:
-
David S. Miller authored
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: -
Arnd Bergmann authored
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 authored
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 authored
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 authored
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:
-
