kernel.git/drivers/net/ethernet/sun, branch linux-3.17.y

vio: fix reuse of vio_dring slot

2014-11-21T17:23:08Z

[ Upstream commit d0aedcd4f14a22e23b313f42b7e6e6ebfc0fbc31 ] vio_dring_avail() will allow use of every dring entry, but when the last entry is allocated then dr->prod == dr->cons which is indistinguishable from the ring empty condition. This causes the next allocation to reuse an entry. When this happens in sunvdc, the server side vds driver begins nack'ing the messages and ends up resetting the ldc channel. This problem does not effect sunvnet since it checks for < 2. The fix here is to just never allocate the very last dring slot so that full and empty are not the same condition. The request start path was changed to check for the ring being full a bit earlier, and to stop the blk_queue if there is no space left. The blk_queue will be restarted once the ring is only half full again. The number of ring entries was increased to 512 which matches the sunvnet and Solaris vdc drivers, and greatly reduces the frequency of hitting the ring full condition and the associated blk_queue stop/starting. The checks in sunvent were adjusted to account for vio_dring_avail() returning 1 less. Orabug: 19441666 OraBZ: 14983 Signed-off-by: Dwight Engen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

sunvnet - add missing rmb() for sunvnet driver

2014-09-08T21:08:14Z

The sunvnet driver does not have an rmb() in the ring consumer corresponding to the wmb() in the producer. According to Documentation/memory-barriers.txt: "When dealing with CPU-CPU interactions, certain types of memory barrier should always be paired. A lack of appropriate pairing is almost certainly an error." In cases where an rmb() is not a no-op and a consumer is removing data from the ring while a producer is adding new entries, a load reorder would allow CPU1 CPU2 ---- ---- LOAD desc.size [e.g] STORE desc.size set desc.hdr.state = VIO_DESC_READY LOAD desc.hdr.state [because VIO_DESC_READY, use old desc.size, already loaded out of order] [CPU2 has reordered apparently unrelated LOADs] To ensure other desc fields are not loaded before checking VIO_DESC_READY, we need an rmb() between the check and desc data accesses. I've also moved the viodbg() call to after the rmb() so that it, too, has current descriptor data even with reordering, which has the side effect that it won't print anything for descriptors that are not VIO_DESC_READY as before. That's a) probably a good thing, since the fields are not necessarily set and, b) better than adding another rmb() just for viodbg(). This would not be possible if strict-ordering is enforced, but then the memory barriers should be no-ops in that case. Signed-off-by: David L Stevens Signed-off-by: David S. Miller

Merge tag 'pci-v3.17-changes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

2014-08-15T00:10:33Z

Pull DEFINE_PCI_DEVICE_TABLE removal from Bjorn Helgaas: "Part two of the PCI changes for v3.17: - Remove DEFINE_PCI_DEVICE_TABLE macro use (Benoit Taine) It's a mechanical change that removes uses of the DEFINE_PCI_DEVICE_TABLE macro. I waited until later in the merge window to reduce conflicts, but it's possible you'll still see a few" * tag 'pci-v3.17-changes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: Remove DEFINE_PCI_DEVICE_TABLE macro use

sunvnet: Schedule maybe_tx_wakeup() as a tasklet from ldc_rx path

2014-08-14T03:04:46Z

At the tail of vnet_event(), if we hit the maybe_tx_wakeup() condition, we try to take the netif_tx_lock() in the recv-interrupt-context and can deadlock with dev_watchdog(). vnet_event() should schedule maybe_tx_wakeup() as a tasklet to avoid this deadlock Signed-off-by: Sowmini Varadhan Signed-off-by: David S. Miller

sunvnet: Do not spin in an infinite loop when vio_ldc_send() returns EAGAIN

2014-08-14T03:04:46Z

ldc_rx -> vnet_rx -> .. -> vnet_walk_rx->vnet_send_ack should not spin into an infinite loop waiting EAGAIN to lift. The sender could have sent us a burst, and gone to lunch without doing any more ldc_read()'s. That should not cause the receiver to loop infinitely till soft-lockup kicks in. Similarly __vnet_tx_trigger should only loop on EAGAIN a finite number of times. The caller (vnet_start_xmit()) already has code to reset the dring state and bail on errors from __vnet_tx_trigger Signed-off-by: Sowmini Varadhan Acked-by: Raghuram Kothakota Signed-off-by: David S. Miller

sunvnet: Do not ask for an ACK for every dring transmit

2014-08-14T03:04:46Z

No need to ask for an ack with every vnet_start_xmit()- the single ACK with DRING_STOPPED is sufficient for the protocol, and we free the sk_buff in vnet_start_xmit itself, so we dont need an ACK back. Signed-off-by: Sowmini Varadhan Acked-by: Raghuram Kothakota Signed-off-by: David S. Miller

PCI: Remove DEFINE_PCI_DEVICE_TABLE macro use

2014-08-12T18:15:14Z

We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. This issue was reported by checkpatch. A simplified version of the semantic patch that makes this change is as follows (http://coccinelle.lip6.fr/): // @@ identifier i; declarer name DEFINE_PCI_DEVICE_TABLE; initializer z; @@ - DEFINE_PCI_DEVICE_TABLE(i) + const struct pci_device_id i[] = z; // [bhelgaas: add semantic patch] Signed-off-by: Benoit Taine Signed-off-by: Bjorn Helgaas

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2014-07-30T20:25:49Z

Signed-off-by: David S. Miller

sunvnet: only use connected ports when sending

2014-07-29T00:29:53Z

The sunvnet driver doesn't check whether or not a port is connected when transmitting packets, which results in failures if a port fails to connect (e.g., due to a version mismatch). The original code also assumes unnecessarily that the first port is up and a switch, even though there is a flag for switch ports. This patch only matches a port if it is connected, and otherwise uses the switch_port flag to send the packet to a switch port that is up. Signed-off-by: David L Stevens Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2014-07-22T07:44:59Z

Conflicts: drivers/infiniband/hw/cxgb4/device.c The cxgb4 conflict was simply overlapping changes. Signed-off-by: David S. Miller