- 14 Feb, 2014 8 commits
-
-
Florian Fainelli authored
This patchs adds the bcmgenet.h header file which contains all the hardware definitions for the GENETv1 to v4 hardware blocks as well as the driver private structure and MIB counters. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
This patch adds support for the Broadcom BCM7xxx Set Top Box SoCs internal PHYs. This driver supports the following generation of SoCs: - BCM7366, BCM7439, BCM7445 (28nm process) - all 40nm and 65nm (older MIPS-based SoCs) The PHYs on these SoCs require a bunch of workarounds to operate correctly, both during configuration time and at suspend/resume time, the driver handles that for us. Signed-off-by:
-
Florian Fainelli authored
The Broadcom BCM54xx register definitions are shared between BCM54xx and BCM7xx internal PHYs for which we are adding support. Extract these register definitions and put them in include/linux/brcmphy.h for use by the BCM7xxx internal PHY driver. Signed-off-by:
-
Florian Fainelli authored
MoCA PHYs are using coaxial (BNC-like) connectors, update the transceiver port type when replying to ethtool. Signed-off-by:
-
Florian Fainelli authored
Some Ethernet MACs are connected to a MoCA PHY which will handle the low-level job of sending Ethernet frames on the coaxial cable, these Ethernet MACs need to know about it to be properly configured. Add a new PHY mode "moca" and update the Device Tree parsing logic to look for it. Signed-off-by:
-
Yang Yingliang authored
Replace some magic numbers which describe states of GE model loss generator with enumerate. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Yang Yingliang authored
In netem_change(), we have already get "struct netem_sched_data *q". Replace params of get_correlation() and other similar functions with "struct netem_sched_data *q". Signed-off-by:
-
Yang Yingliang authored
get_dist_table() and get_loss_clg() may be failed. These two functions should be called after setting the members of qdisc_priv(sch), or it will break the old settings while either of them is failed. Signed-off-by:
-
- 13 Feb, 2014 32 commits
-
-
Denis Kirjanov authored
Packets which have L2 address different from ours should be already filtered before entering into ip_forward(). Perform that check at the beginning to avoid processing such packets. Signed-off-by:
Denis Kirjanov <kda@linux-powerpc.org> Signed-off-by:
-
stephen hemminger authored
One of my pet coding style peeves is the practice of adding extra return; at the end of function. Kill several instances of this in network code. I suppose some coccinelle wizardy could do this automatically. Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Stanislav Fomichev authored
Commit 684bad11 "tcp: use PRR to reduce cwin in CWR state" removed all calls to min_cwnd, so we can safely remove it. Also, remove tcp_reno_min_cwnd because it was only used for min_cwnd. Signed-off-by:
Stanislav Fomichev <stfomichev@yandex-team.ru> Acked-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
Vasundhara Volam authored
Currently multi-channel configuration is read via the QUERY_FW_CONFIG cmd. This method has been deprecated by the Skyhawk-R FW. Instead, GET_PROFILE_CONFIG::port-desc must be used to query this configuration. This patch also: a) introduces a few macros to identify certain categories of multi-channel configs 2) re-factors the be_cmd_set_profile_config() code to be able to read any kind of desc (and not just the nic-desc.) Signed-off-by:
Vasundhara Volam <vasundhara.volam@emulex.com> Signed-off-by:
Sathya Perla <sathya.perla@emulex.com> Signed-off-by:
Somnath Kotur <somnath.kotur@emulex.com> Signed-off-by:
-
Vasundhara Volam authored
Signed-off-by:
-
Somnath Kotur authored
This patch logs a kernel message when a HW error(SLIPORT_ERROR in Lancer and UE in BEx/Skyhawk) is detected. The log message for BE3 was missing earlier. This patch also refactors the code by segregating error-detection and reporting code for Lancer and BEx/SH. Signed-off-by:
-
git://gitorious.org/linux-can/linux-can-nextDavid S. Miller authored
linux-can-next-for-3.15-20140212 Marc Kleine-Budde says: ==================== this is a pull request of eight patches for net-next/master. Florian Vaussard contributed a series that merged the sja1000 of_platform into the platform driver. The of_platform driver is finally removed. Stephane Grosjean supplied a patch to allocate CANFD skbs. In a patch by Uwe Kleine-König another missing copyright information was added to a userspace header. And a patch by Yoann DI RUZZA that adds listen only mode to the at91_can driver. ==================== Signed-off-by: -
Yang Yingliang authored
Prefer pr_*(...) to printk(KERN_* ...). Signed-off-by:
-
Sergei Shtylyov authored
The driver #define's and uses ETHERSMALL macro for the minimum Ethernet frame size for which we have a standard macro ETH_ZLEN. Use the latter instead of the home-grown one. Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
David S. Miller authored
Jon Maloy says: ==================== tipc: clean up media and bearer layer This commit series aims at facilitating future changes to the locking policy around nodes, links and bearers. Currently, we have a big read/write lock (net_lock) that is used for serializing all changes to the node, link and bearer lists, as well as to their mutual pointers and references. But, in order to allow for concurrent access to the contents of these structures, net_lock is only used in read mode by the data path code, and hence a finer granular locking policy must be applied inside the scope of net_lock: a spinlock (node_lock) for each node structure, and another one (bearer_lock) for protection of bearer structures. This locking policy has proved hard to maintain. We have several times encountered contention problems between node_lock and bearer_lock, and with the advent of the RCU locking mechanism we feel it is anyway obsolete and ripe for improvements. We now plan to replace net_lock with an RCU lock, as well as getting rid of bearer_lock altogether. This will both reduce data path overhead and make the code more manageable, while reducing the risk of future lock contention problems. Prior to these changes, we need to do some necessary cleanup and code consolidation. This is what we do with this commit series, before we finally remove bearer_lock. In a later series we will replace net_lock with an RCU lock. v2: - Re-inserted a removed kerneldoc entry in commit#5, based on feedback from D. Miller. ==================== Signed-off-by: -
Jon Paul Maloy authored
In an earlier commit, ("tipc: remove links list from bearer struct") we described three issues that need to be pre-emptively resolved before we can remove tipc_net_lock. Here we resolve issue a) described in that commit: "a) In access method #2, we access the link before taking the protecting node_lock. This will not work once net_lock is gone, so we will have to change the access order. We will deal with this in a later commit in this series." Here, we change that access order, by ensuring that the function link_find_link() returns only a safe reference for finding the link, i.e., a node pointer and an index into its 'links' array, not the link pointer itself. We also change all callers of this function to first take the node lock before they can check if there still is a valid link pointer at the returned index. Since the function now returns a node pointer rather than a link pointer, we rename it to the more appropriate 'tipc_link_find_owner(). Signed-off-by:Jon Maloy <jon.maloy@ericsson.com> Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Ying Xue authored
After the earlier commits ("tipc: remove 'links' list from tipc_bearer struct") and ("tipc: introduce new spinlock to protect struct link_req"), there is no longer any need to protect struct link_req or or any link list by use of bearer_lock. Furthermore, we have eliminated the need for using bearer_lock during downcalls (send) from the link to the bearer, since we have ensured that bearers always have a longer life cycle that their associated links, and always contain valid data. So, the only need now for a lock protecting bearers is for guaranteeing consistency of the bearer list itself. For this, it is sufficient, at least for the time being, to continue applying 'net_lock´ in write mode. By removing bearer_lock we also pre-empt introduction of issue b) descibed in the previous commit "tipc: remove 'links' list from tipc_bearer struct": "b) When the outer protection from net_lock is gone, taking bearer_lock and node_lock in opposite order of method 1) and 2) will become an obvious deadlock hazard". Therefore, we now eliminate the bearer_lock spinlock. Signed-off-by:Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Jon Paul Maloy authored
When a bearer is disabled, all its attached links are deleted. Ideally, we should do link failover to redundant links on other bearers, if there are any, in such cases. This would be consistent with current behavior when a link is reset, but not deleted. However, due to the complexity involved, and the (wrongly) perceived low demand for this feature, it was never implemented until now. We mark the doomed link for deletion with a new flag, but wait until the failover process is finished before we actually delete it. With the improved link tunnelling/failover code introduced earlier in this commit series, it is now easy to identify a spot in the code where the failover is finished and it is safe to delete the marked link. Moreover, the test for the flag and the deletion can be done synchronously, and outside the most time critical data path. Signed-off-by:
-
Jon Paul Maloy authored
We change the order of checking for destination users when processing incoming packets. By placing the checks for users that may potentially replace the processed buffer, i.e., CHANGEOVER_PROTOCOL and MSG_FRAGMENTER, in a separate step before we check for the true end users, we get rid of a label and a 'goto', at the same time making the code more comprehensible and easy to follow. This commit does not change any functionality, it is just a cosmetic code reshuffle. Signed-off-by:
-
Jon Paul Maloy authored
After the previous redesign of the tunnel reception algorithm and functions, we finalize it by renaming a couple of stack variables in tipc_tunnel_rcv(). This makes it more consistent with the naming scheme elsewhere in this part of the code. This change is purely cosmetic, with no functional changes. Signed-off-by:
-
Jon Paul Maloy authored
We simplify and slim down the code in function tipc_tunnel_rcv() No impact on the users of this function. Signed-off-by:
-
Jon Paul Maloy authored
After the earlier commits in this series related to the function tipc_link_tunnel_rcv(), we can now go further and simplify its signature. The function now consumes all DUPLICATE packets, and only returns such ORIGINAL packets that are ready for immediate delivery, i.e., no more link level protocol processing needs to be done by the caller. As a consequence, the the caller, tipc_rcv(), does not access the link pointer after call return, and it becomes unnecessary to pass a link pointer reference in the call. Instead, we now only pass it the tunnel link's owner node, which is sufficient to find the destination link for the tunnelled packet. Signed-off-by:
-
Jon Paul Maloy authored
When a link is reset, and there is a redundant link available, all sender sockets will steer their subsequent traffic through the remaining link. In order to guarantee preserved packet order and cardinality during the transition, we tunnel the failing link's send queue through the remaining link before we allow any sockets to use it. In this commit, we change the algorithm for receiving failover ("ORIGINAL_MSG") packets in tipc_link_tunnel_rcv(), at the same time delegating it to a new subfuncton, tipc_link_failover_rcv(). Instead of directly returning an extracted inner packet to the packet reception loop in tipc_rcv(), we first check if it is a message fragment, in which case we append it to the reset link's fragment chain. If the fragment chain is complete, we return the whole chain instead of the individual buffer, eliminating any need for the tipc_rcv() loop to do reassembly of tunneled packets. This change makes it possible to further simplify tipc_link_tunnel_rcv(), as well as the calling tipc_rcv() loop. We will do that in later commits. It also makes it possible to identify a single spot in the code where we can tell that a failover procedure is finished, something that is useful when we are deleting links after a failover. This will also be done in a later commit. Signed-off-by: -
Jon Paul Maloy authored
When a second link to a destination comes up, some sender sockets will steer their subsequent traffic through the new link. In order to guarantee preserved packet order and cardinality for those sockets, we tunnel a duplicate of the old link's send queue through the new link before we open it for regular traffic. The last arriving packet copy, on whichever link, will be dropped at the receiving end based on the original sequence number, to ensure that only one copy is delivered to the end receiver. In this commit, we change the algorithm for receiving DUPLICATE_MSG packets, at the same time delegating it to a new subfunction, tipc_link_dup_rcv(). Instead of returning an extracted inner packet to the packet reception loop in tipc_rcv(), we just add it to the receiving (new) link's deferred packet queue. The packet will then be processed by that link when it receives its first non-tunneled packet, i.e., at latest when the changeover procedure is finished. Because tipc_link_tunnel_rcv()/tipc_link_dup_rcv() now is consuming all packets of type DUPLICATE_MSG, the calling tipc_rcv() function can omit testing for this. This in turn means that the current conditional jump to the label 'protocol_check' becomes redundant, and we can remove that label. Signed-off-by:
-
Ying Xue authored
In our ongoing effort to simplify the TIPC locking structure, we see a need to remove the linked list for tipc_links in the bearer. This can be explained as follows. Currently, we have three different ways to access a link, via three different lists/tables: 1: Via a node hash table: Used by the time-critical outgoing/incoming data paths. (e.g. link_send_sections_fast() and tipc_recv_msg() ): grab net_lock(read) find node from node hash table grab node_lock select link grab bearer_lock send_msg() release bearer_lock release node lock release net_lock 2: Via a global linked list for nodes: Used by configuration commands (link_cmd_set_value()) grab net_lock(read) find node and link from global node list (using link name) grab node_lock update link release node lock release net_lock (Same locking order as above. No problem.) 3: Via the bearer's linked link list: Used by notifications from interface (e.g. tipc_disable_bearer() ) grab net_lock(write) grab bearer_lock get link ptr from bearer's link list get node from link grab node_lock delete link release node lock release bearer_lock release net_lock (Different order from above, but works because we grab the outer net_lock in write mode first, excluding all other access.) The first major goal in our simplification effort is to get rid of the "big" net_lock, replacing it with rcu-locks when accessing the node list and node hash array. This will come in a later patch series. But to get there we first need to rewrite access methods ##2 and 3, since removal of net_lock would introduce three major problems: a) In access method #2, we access the link before taking the protecting node_lock. This will not work once net_lock is gone, so we will have to change the access order. We will deal with this in a later commit in this series, "tipc: add node lock protection to link found by link_find_link()". b) When the outer protection from net_lock is gone, taking bearer_lock and node_lock in opposite order of method 1) and 2) will become an obvious deadlock hazard. This is fixed in the commit ("tipc: remove bearer_lock from tipc_bearer struct") later in this series. c) Similar to what is described in problem a), access method #3 starts with using a link pointer that is unprotected by node_lock, in order to via that pointer find the correct node struct and lock it. Before we remove net_lock, this access order must be altered. This is what we do with this commit. We can avoid introducing problem problem c) by even here using the global node list to find the node, before accessing its links. When we loop though the node list we use the own bearer identity as search criteria, thus easily finding the links that are associated to the resetting/disabling bearer. It should be noted that although this method is somewhat slower than the current list traversal, it is in no way time critical. This is only about resetting or deleting links, something that must be considered relatively infrequent events. As a bonus, we can get rid of the mutual pointers between links and bearers. After this commit, pointer dependency go in one direction only: from the link to the bearer. This commit pre-empts introduction of problem c) as described above. Signed-off-by: -
Ying Xue authored
Currently, the 'started' field in struct tipc_link represents only a binary state, 'started' or 'not started'. We need it to represent more link execution states in the coming commits in this series. Hence, we rename the field to 'flags', and define the current started/non-started state to be represented by the LSB bit of that field. Signed-off-by:
-
Ying Xue authored
We break out the code for deleting attached links in the function bearer_disable(), and define a new function named tipc_link_delete_list() to do this job. This commit incurs no functional changes, but makes the code of function bearer_disable() cleaner. It is also a preparation for a more important change to the bearer code, in a subsequent commit in this series. Signed-off-by:
-
Ying Xue authored
We break out the code for resetting attached links in the function tipc_reset_bearer(), and define a new function named tipc_link_reset_list() to do this job. This commit incurs no functional changes, but makes the code of function tipc_reset_bearer() cleaner. It is also a preparation for a more important change to the bearer code, in a subsequent commit in this series. Signed-off-by:
-
Jon Paul Maloy authored
The function tipc_link_recv_fragment(struct sk_buff **buf) currently leaves the value of the input buffer pointer undefined when it returns, except when the return code indicates that the reassembly is complete. This despite the fact that it always consumes the input buffer. Here, we enforce a stricter behavior by this function, ensuring that the returned buffer pointer is non-NULL if and only if the reassembly is complete. This makes it possible to test for the buffer pointer as criteria for successful reassembly. We also rename the function to tipc_link_frag_rcv(), which is both shorter and more in line with common naming practice in the network subsystem. Apart from the new name, these changes have no impact on current users of the function, but makes it more practical for use in some planned future commits. Signed-off-by:
-
Andreas Bofjäll authored
The inline functions in addr.h uses tipc_own_addr which is exported by core.h, but addr.h never actually includes it. It works because it is explicitly included where this is used, but it looks a bit strange. Include core.h in addr.h explicitly to make the dependency clearer. Signed-off-by:
Andreas Bofjäll <andreas.bofjall@ericsson.com> Reviewed-by:
-
dingtianhong authored
The dev_valid_name() will check the buffer length for input name, no need to check it twice. Cc: Jay Vosburgh <fubar@us.ibm.com> Cc: Veaceslav Falico <vfalico@redhat.com> Cc: Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
Ding Tianhong <dingtianhong@huawei.com> Reviewed-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
dingtianhong authored
The dev_set_mac_address() will check the dev->netdev_ops->ndo_set_mac_address, so no need to check it in bond_set_mac_address(). Cc: Jay Vosburgh <fubar@us.ibm.com> Cc: Veaceslav Falico <vfalico@redhat.com> Cc: Andy Gospodarek <andy@greyhouse.net> Signed-off-by:
-
WANG Cong authored
We are trying to mirror the local traffic from lo to eth0, allowing setting mac address of lo to eth0 would make the ether addresses in these packets correct, so that we don't have to modify the ether header again. Since usually no one cares about its mac address (all-zero), it is safe to allow those who care to set its mac address. Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Neil Horman <nhorman@tuxdriver.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: Eric Dumazet <edumazet@google.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
David S. Miller authored
Aaron Brown says: ==================== Intel Wired LAN Driver Updates This series contains updates to i40e and i40evf, primarily reset handling / refactoring along with a fair amount of minor cleanup. Jesse fixes some spelling, bumps the version and other trivial fixes. Akeem sets a bit that is needed before shutdown in the case of tx_timeout recovery failure. Mitch refactors reset handling along with a whole bunch of clean up. ==================== Signed-off-by: -
Mitch Williams authored
Respond better to a VF reset event. When a reset is signaled by the PF, or detected by the watchdog task, prevent the watchdog from processing admin queue requests, and schedule the reset task. In the reset task, wait first for the reset to start, then for it to complete, then reinit the driver. If the reset never appears to complete after a long, long time (>10 seconds is possible depending on what's going on with the PF driver), then set a flag to indicate that PF communications have failed. If this flag is set, check for the reset to complete in the watchdog, and attempt to do a full reinitialization of the driver from scratch. With these changes the VF driver correctly handles a PF reset event while running on bare metal, or in a VM. Also update copyrights. Change-ID: I93513efd0b50523a8345e7f6a33a5e4f8a2a5996 Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Sibai Li <sibai.li@intel.com> Signed-off-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
Mitch Williams authored
As pointed out by Dan Carpenter (from Oracle), the flags variable is declared as a 64-bit long but all of the flags are defined as u32, which may lead to unintended consequences. Fix this by declaring flags as u32 (since we don't need any more than about a dozen flags right now), and remove the volatile qualifier, since it's unnecessary and just makes checkpatch cry. Change-ID: I137d3bb1842bf7e9456b5929ca54e3b0ed45dcab Signed-off-by:
-
Mitch Williams authored
Since we store the traffic vector names in the queue vector struct, we don't need to maintain an array of strings for these names in the adapter structure. Replace this array with a single string and use it when allocating the misc irq vector. Also update copyrights. Change-ID: I664f096c3c008210d6a04a487163e8aa934fee5b Signed-off-by:
-
