- 09 Jul, 2014 27 commits
-
-
Russell King authored
Remove a useless status check in the transmit reap path - we have already checked that the BD_ENET_TX_READY bit is clear, and as the hardware only ever clears this bit, there is no way this test can ever be true. Acked-by:
Fugang Duan <B38611@freescale.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Russell King authored
When we timeout on transmit, it would be useful to dump the transmit ring, so we can see the ring state. This can be helpful to diagnose the cause of transmit timeouts. Acked-by:
-
Russell King authored
This allows us to merge two separate preprocessor conditionals together. Acked-by:
-
Russell King authored
Clear any pending receive interrupt before we process a pending packet. This helps to avoid any spurious interrupts being raised after we have fully cleaned the receive ring, while still allowing an interrupt to be raised if we receive another packet. The position of this is critical: we must do this prior to reading the next packet status to avoid potentially dropping an interrupt when a packet is still pending. Acked-by:
-
Russell King authored
As of "better implementation of iMX6 ERR006358 quirk", we no longer have a requirement for a delayed work. Moreover, the work is now only used for timeout purposes, so the timeout flag is also pointless - we set it each time we queue the work, and the work clears it. Replace the fec_enet_delayed_work struct with a standard work_struct, resulting in simplified timeout handling code. Acked-by:
-
Russell King authored
Using a (delayed) workqueue for ERR006358 is not correct - a work queue is a single-trigger device. Once the work queue has been scheduled, it can't be re-scheduled until it has been run. This can cause problems - with an appropriate packet timing, we can end up with packets queued, but not sent by the hardware, resulting in the transmit timeout firing. Re-implement this as per the workaround detailed in the ERR006358 documentation - if there are packets waiting to be sent when we service the transmit ring, and we see that the transmitter is not running, kick the transmitter to run the pending entries in the ring. Testing here with a 10Mbit half duplex link sees the resulting iperf TCP bandwidth increase from between 1 to 2Mbps to between 8 to 9Mbps. Acked-by:
-
david decotigny authored
After a bonding master reclaims the netpoll info struct, slaves could still hold a pointer to the reclaimed data. This patch fixes it: as soon as netpoll_async_cleanup is called for a slave (eg. when un-enslaved), we make sure that this slave doesn't point to the data. Signed-off-by:
David Decotigny <decot@googlers.com> Signed-off-by:
-
Zoltan Kiss authored
This patch adds debugfs capabilities to netback. There used to be a similar patch floating around for classic kernel, but it used procfs. It is based on a very similar blkback patch. It creates xen-netback/[vifname]/io_ring_q[queueno] files, reading them output various ring variables etc. Writing "kick" into it imitates an interrupt happened, it can be useful to check whether the ring is just stalled due to a missed interrupt. Signed-off-by:
Zoltan Kiss <zoltan.kiss@citrix.com> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org Signed-off-by:
-
Florian Fainelli authored
Commit cb1ce2ef ("ipv6: Implement automatic flow label generation on transmit") introduced ip6_make_flowlabel, while commit b73c3d0e ("net: Save TX flow hash in sock and set in skbuf on xmit") introduced ip6_set_txhash. ip6_set_tx_hash() uses sk_v6_daddr which references __sk_common.skc_v6_daddr from struct sock_common, which is gated with IS_ENABLED(CONFIG_IPV6). ip6_make_flowlabel() uses the ipv6 member from struct net which is also gated with IS_ENABLED(CONFIG_IPV6). When CONFIG_IPV6 is disabled, we will hit a build failure that looks like this when the compiler attempts inlining these functions: CC [M] drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.o In file included from include/net/inet_sock.h:27:0, from include/net/ip.h:30, from drivers/net/ethernet/broadcom/cnic.c:37: include/net/ipv6.h: In function 'ip6_set_txhash': include/net/sock.h:327:33: error: 'struct sock_common' has no member named 'skc_v6_daddr' #define sk_v6_daddr __sk_common.skc_v6_daddr ^ include/net/ipv6.h:696:49: note: in expansion of macro 'sk_v6_daddr' keys.dst = (__force __be32)ipv6_addr_hash(&sk->sk_v6_daddr); ^ In file included from include/net/inetpeer.h:15:0, from include/net/route.h:28, from include/net/ip.h:31, from drivers/net/ethernet/broadcom/cnic.c:37: include/net/ipv6.h: In function 'ip6_make_flowlabel': include/net/ipv6.h:706:37: error: 'struct net' has no member named 'ipv6' if (!flowlabel && (autolabel || net->ipv6.sysctl.auto_flowlabels)) { ^ Fixes: cb1ce2ef ("ipv6: Implement automatic flow label generation on transmit") Fixes: b73c3d0e ("net: Save TX flow hash in sock and set in skbuf on xmit") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== Freescale ethernet driver updates (part 2) Here's the second batch of patches for the Freescale FEC ethernet driver, based upon the previous set of patches. One further set of 7 patches remains. ==================== Signed-off-by: -
Russell King authored
Many places call fec_restart() with the second parameter being some kind of previously saved duplex value, but only two places call it with some other setting. This is at odds with how the other link settings are handled, and used to be racy before the rtnl locks were added to fec_restart()'s various call paths. Clean this up so all link capabilities are handled in the same way - saved into the fec_enet_private structure, and then fec_restart() acts on those settings. Acked-by:
-
Russell King authored
When the link goes down, the adjust_link method will be called, but there is no synchronisation to ensure that we won't be processing some last remaining packets via the NAPI handlers while performing a reset of the device. Add the necessary synchronisation to ensure that packet processing is complete before we stop and reset the FEC. Acked-by:
-
Russell King authored
Changing the features (receive checksumming) requires the hardware to be reprogrammed, and also changes the checks in the receive packet processing. The current implementation has a race - fec_set_features() changes the flags which alter the receive packet processing while the adapter is active, and potentially receiving frames. Only after we've modified the software flag do we shutdown and reconfigure the hardware. This can lead to packets being received and marked with a valid checksum (via CHECKSUM_UNNECESSARY) when the hardware checksum validation has not yet been enabled. We must quiesce the device, then change the software configuration for this feature, and then resume the device if it was previously running. The resulting code structure also allows us to add other configuration features in this path without having to quiesce and resume the network interface and device. Acked-by:
-
Russell King authored
fec_set_features() calls fec_stop() to stop the transmit ring while the transmit queue is still active. This can lead to the transmit ring being restarted by an intervening packet queued for transmission, or by the tx quirk timer expiring. Fix this by disabling NAPI (which ensures that the NAPI handlers are not running), and then take the transmit lock while we stop and restart the adapter (which prevents new packets being queued). Acked-by:
-
Russell King authored
fec_suspend() calls fec_stop() to stop the transmit ring while the transmit packet processing is still active. This can lead to the transmit queue being restarted by an intervening packet queued for transmission, or by the tx quirk timer expiring. Fix this by disabling NAPI first, which will ensure that the NAPI handlers are not running. Then, take the transmit lock before detaching the netif device. This ensures that there are no races with the transmit path - and also ensures that the watchdog won't fire. We can then safely stop the ethernet device itself, knowing that the rest of the driver is safely shut down. On resume, we bring the device back up in reverse order - we restart the device, reattach the device (under the tx lock), and then enable the NAPI handlers. We also need to adjust the close function to cope with this new sequence, so that it's possible to cleanly close down the driver after the hardware fails to resume (eg, due to the regulator_enable() or pinctrl calls in the resume path returning an error.) Acked-by:
-
Russell King authored
This is the second stage to "move calls to quiesce/resume packet processing out of fec_restart()", where we remove calls which are not appropriate to the call site. In the majority of cases, there is no need to detach and reattach the interface as we are holding the queue xmit lock across the reset. The exception to that is in fec_resume(), where we are already detached by the suspend function. Here, we can remove the call to detach the interface. We also do not need to stop the transmit queue. Holding the xmit lock is enough to ensure that the transmit packet processing is not running while we perform our task. However, since fec_restart() always cleans the rings, we call netif_wake_queue() (or netif_device_attach() in the case of resume) just before dropping the xmit lock. This prevents the watchdog firing. Lastly, always call napi_enable() after the device has been reattached in the resume path so that we know that the transmit packet processing is already in an enabled state, so we don't call netif_wake_queue() while detached. Acked-by:
-
Russell King authored
Move the calls to quiesce and resume packet processing out of fec_restart() to its call sites. This is the first step in a two stage clean up of this code, where we just move the calls out of fec_restart() without changing them. Not everywhere needs to issue these calls, and not everywhere needs all of these calls to be issued. Acked-by:
-
Russell King authored
Avoid calling fec_restart() or fec_stop() while the device is down or not present (iow suspended.) Although the ndo_timeout method will only be called if the device is present and running, we defer this to a work queue. The work queue can run independently, and so needs to repeat these checks to ensure that a restart doesn't occur after the device has been taken down or detached for suspend. In this case, we call fec_restart() in the resume path, so nothing is lost. For fec_set_features, we add a call to fec_restart() in fec_enet_open() to ensure that the hardware is appropriate programmed when the interface is opened. fec_set_features() call should not occur while we're suspended, so we don't have to worry about that case. The adjust_link needs similar treatment - this also is called from a work queue, which may be run independently after we have taken the device down and detached it. In this case, we just mark the link down and take no further action. We will reset things appropriately once the device is up and running again, at which point we will receive another adjust_link callback. Acked-by:
-
Russell King authored
When the FEC is suspended, the device is detached. Upon resume failure, the device is left in detached mode, possibly with some of the required clocks not running. We don't want to be poking the device in that state because as it may cause bus errors. If the device is marked detached, avoid calling fec_stop(). This depends upon: "net:fec: improve safety of suspend/resume paths" Acked-by:
-
Russell King authored
We should hold the rtnl lock while suspending, resuming or processing the transmit timeout to ensure that nothing will interfere while we bring up, take down or restart the hardware. The transmit timeout could run if we're preempted during suspend. Acked-by:
-
David S. Miller authored
Amir Vadai says: ==================== Mellanox driver update Jul-08-2014 This patch set introduce some small bug fixes. Most of the patches are small fixes to cornet case bugs. The patch by Noa ("Fix mac_hash database inconsistency") was sent in the past [1] and was droped because a fix to the bonding code was supposed to make it unnecessary. After a second look on the patch, it is still needed even after the direct access to dev_addr by the bonding will be fixed. Patches were applied and tested over commit bd4578b ("drivers/net/hyperv/netvsc.c: remove unnecessary null test before kfree") [1] - http://permalink.gmane.org/gmane.linux.network/315900 ==================== Signed-off-by: -
Noa Osherovich authored
Using a local copy of dev_addr in mlx4_en_set_mac() to prevent dev_addr from being modified during error flow or when dev_addr is modified in another context (which is another problem that is being discussed over the mailing list [1]). Also fixing bad naming of priv->prev_mac into priv->current_mac. [1] - http://patchwork.ozlabs.org/patch/351489/Reviewed-by:
Eyal Perry <eyalpe@mellanox.com> Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
Amir Vadai <amirv@mellanox.com> Signed-off-by:
-
Yishai Hadas authored
LLC/SNAP 8 bytes should not be added as part of header calculation. If used, payload will be decreased accordingly. For MTU of 1500 we'll set 1522 instead of 1523. Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Reviewed-by:
Liran Liss <liranl@mellanox.com> Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
-
Eugenia Emantayev authored
Promiscous mode is only for MACs. Should not disable/enable VLAN filter when entering/leaving promisuous mode. Signed-off-by:
Aviad Yehezkel <aviadye@mellanox.co.il> Signed-off-by:
-
Eugenia Emantayev authored
Verify port number to avoid crashes if port number is outside the range. Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
-
Eugenia Emantayev authored
Loopback can't work when port is down. Signed-off-by:
-
Eugenia Emantayev authored
In 40GE we can't use the default bw units for set ratelimit (100 Mbps) since the max is 255*100 Mbps = 25 Gbps (not suited for 40GE), thus we need 1 Gbps units. But for 10GE 1 Gbps units might be too bruit so we use the following solution. For user set ratelimit <= 25 Gbps: use 100 Mbps units * user_ratelimit (* 10). For user set ratelimit > 25 Gbps: use 1 Gbps units * user_ratelimit. For user set unlimited ratelimit (0 Gbps): use 1 Gbps units * MAX_RATELIMIT_DEFAULT (57) Note: any value > 58 will damage the FW ratelimit computation, so we allow a max and any higher value will be pulled down to 57. Signed-off-by:Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
-
- 08 Jul, 2014 13 commits
-
-
David S. Miller authored
Linus Lüssing says: ==================== bridge: multicast snooping exports #2 Some people pointed out to me that it might be helpful to add stubs for the newly added multicast exports. That way e.g. batman-adv should continue to be compile and useable without having to have a kernel compiled with bridge code in the future. This is what the first patch is supposed to do. The second patch adds a third multicast export for the bridge which e.g. batman-adv is supposed to use, too, soon: Just like the bridge disables its multicast snooping activities if no querier is present, batman-adv needs to do the same if bridges are involved. These three exports should be the final ones needed to marry the bridge multicast snooping with the batman-adv multicast optimizations recently added for the 3.15 kernel, allowing to use these optimzations in common setups having a bridge on top of e.g. bat0, too. So far these bridged setups would fall back to simple flooding through the batman-adv mesh network for any multicast packet entering bat0. More information about the batman-adv multicast optimizations currently implemented can be found here: http://www.open-mesh.org/projects/batman-adv/wiki/Basic-multicast-optimizations The integration on the batman-adv side could afterwards look like this, for instance (now including the third export): http://git.open-mesh.org/batman-adv.git/commitdiff/61e4f6af4b7a21ed4040f2e711d50c778e5b6d93?hp=6ae4281474675fbca5bedcf768972a32db586eb6 ====================
-
Linus Lüssing authored
With this patch other modules are able to ask the bridge whether an IGMP or MLD querier exists on the according, bridged link layer. Multicast snooping can only be performed if a valid, selected querier exists on a link. Just like the bridge only enables its multicast snooping if a querier exists, e.g. batman-adv too can only activate its multicast snooping in bridged scenarios if a querier is present. For instance this export avoids having to reimplement IGMP/MLD querier message snooping and parsing in e.g. batman-adv, when multicast optimizations for bridged scenarios are added in the future. Signed-off-by:
Linus Lüssing <linus.luessing@web.de> Signed-off-by:
-
Linus Lüssing authored
To make users (e.g. batman-adv soon) load- and runnable even if the bridge was compiled without snooping capabilities - or even if the kernel was compiled without any bridge code at all. Signed-off-by:
-
Erik Hugne authored
This fixes a regression bug caused by: 067608e9 ("tipc: introduce direct iovec to buffer chain fragmentation function") If data is sent on a nonblocking socket and the destination link is congested, the buffer chain is leaked. We fix this by freeing the chain in this case. Signed-off-by:
Erik Hugne <erik.hugne@ericsson.com> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Acked-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Maciej W. Rozycki authored
This fixes issues with debug printk calls across the driver, normally disabled; first compilation errors: drivers/net/fddi/defxx.c:676:1: error: pasting "(" and ""In dfx_bus_init...\n"" does not give a valid preprocessing token drivers/net/fddi/defxx.c:820:1: error: pasting "(" and ""In dfx_bus_uninit...\n"" does not give a valid preprocessing token and so on, and then warnings: drivers/net/fddi/defxx.c: In function 'dfx_driver_init': drivers/net/fddi/defxx.c:1132: warning: format '%0X' expects type 'unsigned int', but argument 4 has type 'dma_addr_t' drivers/net/fddi/defxx.c:1132: warning: format '%0X' expects type 'unsigned int', but argument 4 has type 'dma_addr_t' etc. Additionally casts are removed from virtual addresses and %p used. Signed-off-by:Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
-
David S. Miller authored
Maciej W. Rozycki says: ==================== defxx: Fixes for 64-bit host support This mini patch series addresses issues with 64-bit host support for FDDI interface boards supported by the defxx driver where DMA mapping synchronisation is required on swiotlb systems. While PDQ, the DMA engine chip used with these boards, supports 48-bit addressing that would normally suffice for typical 64-bit systems in existence, the host bus interface chips used by individual implementations have their limitations as follows: * DEFTA or DEC FDDIcontroller/TURBOchannel -- there's no host bus interface chip, the PDQ connects to TURBOchannel directly; TURBOchannel supports DMA addressing of up to 16GB (34-bit addressing), however no TURBOchannel system has ever been made that supports more than 1GB of RAM, so in reality no remapping is ever required, * DEFEA or DEC FDDIcontroller/EISA -- the ESIC EISA interface chip only supports 32-bit addressing, all accesses beyond 4GB have to be remapped, * DEFPA or DEC FDDIcontroller/PCI -- the PFI PCI interface chip rev. 1 & 2 only support 32-bit addressing, they have 32 AD lines only both on the PDQ and the PCI side, and consequently no Dual Address Cycle support, so all accesses beyond 4GB have to be remapped; the range of addressing supported by PFI rev. 3 is currently not certain, however the chip is backwards compatible with earlier revisions and will work with code that supports them. Some other issues discovered in the course of correcting 64-bit support have been fixed as well. Each of the patches is functionally self-contained and can be applied independentely, although there may be mechanical dependencies making it necessary to apply patches in order. The driver suffers from non-standard formatting and while I did my best with these bug fixes to follow our coding style, I found some pieces hopeless, checkpatch.pl will complain. I plan to reformat the whole driver, that will inevitably require factoring out some pieces into separate functions, but that's going to be a major effort and therefore I want to do this separately, with no functional changes made at the same time. If anyone has specific suggestions as to how to reformat any of the pieces submitted here for a better layout, then I'll be happy to take them into account. And last but not least many thanks to Robert Coerver, who was the most recent person to report this problem with the driver and was kind enough to patiently try a few revisions of the driver update on his system as I was finding and addressing issues. ==================== Signed-off-by: -
Maciej W. Rozycki authored
This adds DMA synchronisation calls needed in the receive path: 1. To retrieve the Receive Status word that is prepended by the PDQ DMA engine in the receive buffer, and provides information about the frame received, including its size and any errors. 2. To make data received available for copying in the small-frame case (size <= SKBUFF_RX_COPYBREAK) where the original DMA buffer will be returned to the receive descriptor ring and therefore its mapping retained. With DMA mapping error handling in place, added by the other patch, this may now also trigger where an attempt to map a newly allocated buffer for DMA has failed. In that case data from the original buffer will be copied out and the buffer returned to the DMA descriptor ring. These calls may do nothing when data is in the host DMA addressing range of the FDDI interface, such as always on 32-bit systems, however their absence makes frame reception stop functioning reliably on systems that have memory beyond the low 4GB of the address space. Reported-by:
Robert Coerver <Robert.Coerver@ll.mit.edu> Tested-by:
-
Maciej W. Rozycki authored
This adds error handling for DMA mapping requests; I think there isn't much else to say about it. A good side-effect is the mapping in the transmit path is now made with the board lock released. Also if DMA mapping fails for a newly allocated receive buffer, then data from the old buffer will be copied out (as is presently done for small frames only whose size does not exceed SKBUFF_RX_COPYBREAK) and the original buffer returned, with its mapping unchanged, to the DMA descriptor ring. Reported-by:
-
Maciej W. Rozycki authored
Switch the two remaining places across the driver that use dev_alloc_skb to netdev_alloc_skb. Another place has already been converted to use __netdev_alloc_skb, no idea why these two have been left behind. Reported-by:
-
Maciej W. Rozycki authored
Prearranged receive DMA bounce buffer mappings are not released in the card reboot/shutdown path. That does not affect frame reception, but probably explains the random segmentation fault I observed the other day on interface shutdown. Card is rebooted as required by the spec in the process of ring fault recovery when a PC Trace signal has been received. This change fixes the problem in an obvious manner. Reported-by:
-
Maciej W. Rozycki authored
Receive DMA maps are oversized, they include EISA legacy 128-byte alignment padding in size calculation whereas this padding is never used for data. Worse yet, if the skb's data area has been realigned indeed, then data beyond the end of the buffer will be synchronised from the receive DMA bounce buffer, possibly corrupting data structures residing in memory beyond the actual end of this data buffer. Therefore switch to using PI_RCV_DATA_K_SIZE_MAX rather than NEW_SKB_SIZE in DMA mapping, the value the former macro expands to is written to the receive ring DMA descriptor of the PDQ DMA chip and determines the maximum amount of data PDQ will ever transfer to the corresponding data buffer, including all headers and padding. Reported-by:
-
David S. Miller authored
David Laight says: ==================== net: sctp: Optimisations to sctp command queue code These 3 patches optimise the code that processes sctp's command queue. (A list of 'tasks' to be performed after the rest of the chunk processing.) 1) Inline all the functions from command.c 2) Remove the memset() calls used to zero a word-sized union. 3) Use pointers instead of array indexes. The combined changes reduce the code size (amd64) by a few kb. I'm not 100% convinced that the zeroing done in patch 2 is needed at all. On BE systems it is likely to generate more code than on LE ones. In fact it might be best to change the union to only contain 'long' sized items. Changes for v2: - Add some missing initialisers in patch 2/3 and delete them in 3/3. - Modify the commit message for 2/3 to point out that the union shouldn't need to be zeroed, but the patches aren't intended to change the behaviour even if the code is buggy. ==================== Signed-off-by: -
David Laight authored
Using pointers into sctp_cmd_seq_t.cmds[] lets the compiler generate much better code. Use the last entry first to optimise the overflow check. Signed-off-by:
David Laight <david.laight@aculab.com> Signed-off-by:
-
