- 26 Feb, 2014 25 commits
-
-
Arnd Bergmann authored
interruptible_sleep_on is racy and going away. In case of pcbit, the driver would run into a timeout if the card is initialized before we start waiting for it. This uses wait_event to fix the race. In order to do this, the state machine handling for the timeout case has to get trivially reorganized so we actually know whether the timeout has occorred or not. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Karsten Keil <isdn@linux-pingi.de> Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
interruptible_sleep_on is racy and going away. This replaces the one use in the firestream driver with the appropriate wait_event_interruptible variant. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Chas Williams <chas@cmf.nrl.navy.mil> Cc: linux-atm-general@lists.sourceforge.net Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Aaron Brown says: ==================== Intel Wired LAN Driver Updates This series contains updates to ixgbe, igb and documentation. The first four have been sent up as part of other series where 1 or more in the series were rejected and either dropped or still being worked on for reasons unrelated to these patches. Don makes recovery from a HW ECC error just schedule a reset as it turns out the previous behaviour of forcing the user to reload is not necessary. Mark adds WoL support to port 0 of a new device. Jacob removes a magic number from the ptp_caps.name and updates the SubmittingPatches documentation with details on the Fixed: tag. And Carolyn updates igb files to remove the FSF physical mail address. [ DaveM Note: SubmittingPatches change omitted, will go via LKML ] ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Carolyn Wyborny authored
This patch updates the license text to remove address of Free Software Foundation and refer users to www.gnu.org instead. This patch also updates the copyright dates in appropriate igb driver files. Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jeff Kirsher authored
Based on Stephen Hemminger's original patch. Make local functions static, and remove unused functions. Reported-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mark Rustad authored
Add WoL support for port 0 of a new 82599-based device. Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jacob Keller authored
Rather than using a magic size number, just use sizeof since that will work and is more robust to future changes. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Don Skidmore authored
Currently when we noticed a HW ECC error we would request the use reload the driver to force a reset of the part. This was done due to the mistaken believe that a normal reset would not be sufficient. Well it turns out it would be so now we just schedule a reset upon seeing the ECC. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hannes Frederic Sowa authored
This option has the same semantic as IP_PMTUDISC_OMIT for IPv4 which got recently introduced. It doesn't honor the path mtu discovered by the host but in contrary to IPV6_PMTUDISC_INTERFACE allows the generation of fragments if the packet size exceeds the MTU of the outgoing interface MTU. Fixes: 93b36cf3 ("ipv6: support IPV6_PMTU_INTERFACE on sockets") Cc: Florian Weimer <fweimer@redhat.com> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hannes Frederic Sowa authored
IP_PMTUDISC_INTERFACE has a design error: because it does not allow the generation of fragments if the interface mtu is exceeded, it is very hard to make use of this option in already deployed name server software for which I introduced this option. This patch adds yet another new IP_MTU_DISCOVER option to not honor any path mtu information and not accepting new icmp notifications destined for the socket this option is enabled on. But we allow outgoing fragmentation in case the packet size exceeds the outgoing interface mtu. As such this new option can be used as a drop-in replacement for IP_PMTUDISC_DONT, which is currently in use by most name server software making the adoption of this option very smooth and easy. The original advantage of IP_PMTUDISC_INTERFACE is still maintained: ignoring incoming path MTU updates and not honoring discovered path MTUs in the output path. Fixes: 482fc609 ("ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE") Cc: Florian Weimer <fweimer@redhat.com> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Hannes Frederic Sowa authored
ip_skb_dst_mtu mostly falls back to ip_dst_mtu_maybe_forward if no socket is attached to the skb (in case of forwarding) or determines the mtu like we do in ip_finish_output, which actually checks if we should branch to ip_fragment. Thus use the same function to determine the mtu here, too. This is important for the introduction of IP_PMTUDISC_OMIT, where we want the packets getting cut in pieces of the size of the outgoing interface mtu. IPv6 already does this correctly. Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Timo Teräs authored
iproute2 arpd seems to expect this as there's code and comments to handle netlink probes with NUD_PROBE set. It is used to flush the arpd cached mappings. opennhrp instead turns off unicast probes (so it can handle all neighbour discovery). Without this change it will not see NUD_PROBE probes and cannot reconfirm the mapping. Thus currently neigh entry will just fail and can cause few packets dropped until broadcast discovery is restarted. Earlier discussion on the subject: http://marc.info/?t=139305877100001&r=1&w=2Signed-off-by: Timo Teräs <timo.teras@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jean Sacren authored
The commit 8fad346f ("eee802154: add basic support for RF212 to at86rf230 driver") introduced the new function is_rf212() with some minor issues in declaration: 1) Fix the function type by changing it to bool as the function definition returns a boolean value. Additionally both callers of is_rf212() are expected to return a boolean value. 2) Fix the function specifier by deleting the inline keyword as the compiler takes care of that. Signed-off-by: Jean Sacren <sakiwit@gmail.com> Cc: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bjørn Mork authored
These info messages are rather pointless without any means to identify the source of the bogus packets. Logging the src and dst addresses and ports may help a bit. Cc: Joe Perches <joe@perches.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Amir Vadai says: ==================== net, net/mlx4: Add sysfs file for port number Modern distro's are using biosdevname to rename interface to a name based on slot/port number. biosdevname can't get the port number of devices that have multiple ports that share the same PCI function. This patch adds a sysfs file under: /sys/devices/.../net/<interface>/dev_port, that contains the port number (0 based) - to be used by biosdevname. Also, dev_id was wrongly used in mlx4_en driver - added a patch that fix it. This patch was tested and applied over commit 51adfcc "net: bcmgenet: remove unused bh_lock member" ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amir Vadai authored
dev_id should be set for multiple netdev's sharing the same MAC, which is not the case here. Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amir Vadai authored
Initialize dev_port with port number (0 based) to be accessed through sysfs from user space. Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amir Vadai authored
Add a sysfs file to enable user space to query the device port number used by a netdevice instance. This is needed for devices that have multiple ports on the same PCI function. Signed-off-by: Amir Vadai <amirv@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Michal Schmidt says: ==================== bnx2x: minimize RAM usage in kdump kdump kernels usually have only a small amount of memory reserved. bnx2x can be memory-hungry. Let's minimize its memory usage when running in kdump. I detect kdump by looking at the "reset_devices" flag. A couple of storage drivers (cciss, hpsa) use it for the same purpose. I am not sure this is the best way to solve the problem, but it works. Should it be made more generic by, say, looking at the total amount of lowmem instead? Not using TPA by default when lowmem is small and/or defaulting to fewer queues would help 32bit systems where a driver for a multi-function multi-queue NIC can consume a significant amount of available memory. Or do we want no such heuristics? Is this something to consider doing for other network drivers too? ==================== Acked-by: Ariel Elior <ariele@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michal Schmidt authored
When running in a kdump kernel, disable TPA. This saves memory, which tends to be scarce in kdump. TPA, being a receive acceleration, is unlikely to be useful for kdump, whose purpose is to send the memory image out. This saves additional 5 MB in the kdump environment. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michal Schmidt authored
When running in a kdump kernel, make sure to use only a single ethernet queue even if a num_queues option in /etc/modprobe.d/*.conf would specify otherwise. This saves memory, which tends to be scarce in kdump. This saves about 40 MB in the kdump environment on a setup with num_queues=8 in the config file. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michal Schmidt authored
Use the clamp() macro to make the calculation of the number of queues slightly easier to understand. It also avoids a crash when someone accidentally passes a negative value in num_queues= module parameter. Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
Three counters are added: - one to track when we went from non-zero to zero window - one to track the reverse - one counter incremented when we want to announce zero window, but can't because we would shrink current window. Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Florian Westphal <fw@strlen.de> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Neil Jerram authored
All ethertypes other than ETH_P_MPLS_UC, ETH_P_MPLS_MC and ETH_P_ATMMPOA were already ordered numerically. This commit moves those three ETH_P_... values into correct numerical order too. Signed-off-by: Neil Jerram <Neil.Jerram@metaswitch.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 25 Feb, 2014 15 commits
-
-
Joe Perches authored
BNX2X_ALLOC macros use "goto alloc_mem_err" so these labels appear unused in some functions. Expand these macros in-place via coccinelle and some typing. Update the macros to use statement expressions and remove the BNX2X_ALLOC macro. This adds some > 80 char lines. $ cat bnx2x_pci_alloc.cocci @@ expression e1; expression e2; expression e3; @@ - BNX2X_PCI_ALLOC(e1, e2, e3); + e1 = BNX2X_PCI_ALLOC(e2, e3); if (!e1) goto alloc_mem_err; @@ expression e1; expression e2; expression e3; @@ - BNX2X_PCI_FALLOC(e1, e2, e3); + e1 = BNX2X_PCI_FALLOC(e2, e3); if (!e1) goto alloc_mem_err; @@ expression e1; expression e2; @@ - BNX2X_ALLOC(e1, e2); + e1 = kzalloc(e2, GFP_KERNEL); if (!e1) goto alloc_mem_err; @@ expression e1; expression e2; expression e3; @@ - kzalloc(sizeof(e1) * e2, e3) + kcalloc(e2, sizeof(e1), e3) @@ expression e1; expression e2; expression e3; @@ - kzalloc(e1 * sizeof(e2), e3) + kcalloc(e1, sizeof(e2), e3) Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
bh_lock spinlock is unused, remove it from the private driver structure. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
This code is commented since it is unused, left-over from the very first time this driver was merged. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Drop all the checks on priv->phydev since we will refuse probing the driver if we cannot attach to a PHY device. Drop all checks on priv->phydev. This also fixes some smatch issues reported by Dan Carpenter. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Claudiu Manoil says: ==================== gianfar: Device reset and reconfig fixes These patches end up fixing some notable device reset & reconfig related problems. One issue is on-the-fly (Rx/Tx on) programming of interrupt coalescing (IC) registers on the processing path, against HW recommendation. This is an old issue that became visible after BQL introduction, as under certain conditions (low traffic) one TX interrupt gets lost and BQL fires Tx timeout as a result. Another notable issue is a race on the Tx path (xmit, clean_tx) during device reset (i.e. during Tx timeout watchdog firing) that leads to NULL access. Fixing the problematic on-thy-fly register writes (i.e. the IC regs) required the implementation of a MAC soft reset procedure. The race leading to NULL access was addressed by fixing the stop_gfar()/startup_gfar() pair (disable/enable napi a.s.o.) and adding the device state DOWN to sync with the TX path. v2: Refactored if() clauses from gfar_set_features(), PATCH 2. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
Programming the interrupt coalescing (IC) registers while the controller/DMA is on may incur the loss of one Tx confirmation interrupt, under certain conditions. This is a subtle hw race because it does not occur during a burst of Tx packets. It has been observed on p2020 devices that, if just one packet is being xmit'ed, the Tx confirmation doesn't trigger and BQL evetually blocks the Tx queues, followed by Tx timeout and an un-responsive device. This issue was not apparent prior to introducing BQL support, as a late Tx confirmation was not an issue back then and the next burst of Tx frames would have triggered the Tx confirmation/ Tx ring cleanup anyway. Bottom line, the hw specifications state that the IC registers should not be programmed while the Rx/Tx blocks (the DMA) are enabled. Further more, these registers are currently re-written with the same values on the processing path, over and over again. To fix this, rewriting the IC registers has been removed from the processing path (napi poll). A complete MAC reset procedure has been implemented for the ethtool -c option instead, to reliably update these registers while the controller is stopped. Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
The device reset procedure, stop_gfar()/startup_gfar(), has concurrency issues. "Kernel access of bad area" oopses show up during Tx timeout device reset or other reset cases (like changing MTU) that happen while the interface still has traffic. The oopses happen in start_xmit and clean_tx_ring when accessing tx_queue-> tx_skbuff which is NULL. The race comes from de-allocating the tx_skbuff while transmission and napi processing are still active. Though the Tx queues get temoprarily stopped when Tx timeout occurs, they get re-enabled as a result of Tx congestion handling inside the napi context (see clean_tx_ring()). Not disabling the napi during reset is also a bug, because clean_tx_ring() will try to access tx_skbuff while it is being de-alloc'ed and re-alloc'ed. To fix this, stop_gfar() needs to disable napi processing after stopping the Tx queues. However, in order to prevent clean_tx_ring() to re-enable the Tx queue before the napi gets disabled, the device state DOWN has been introduced. It prevents the Tx congestion management from re-enabling the de-congested Tx queue while the device is brought down. An additional locking state, RESETTING, has been introduced to prevent simultaneous resets or to prevent configuring the device while it is resetting. The bogus 'rxlock's (for each Rx queue) have been removed since their purpose is not justified, as they don't prevent nor are suited to prevent device reset/reconfig races (such as this one). Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
Resetting the device (stop_gfar()/startup_gfar()) should be fast and to the point, in order to timely recover from an error condition (like Tx timeout) or during device reconfig. The irq free/ request routines are just redundant here, and they should be part of the device close/ open routines instead. Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
The RCTRL and TCTRL registers should not be changed on-the-fly, while the controller is running, otherwise unexpected behaviour occurs. But that's exactly what gfar_vlan_mode() does, updating the VLAN acceleration bits inside RCTRL/TCTRL. The attempt to lock these operations doesn't help, but only adds to the confusion. There's also a dependency for Rx FCB insertion (activating /de-activating the TOE offload block on Rx) which might change the required rx buffer size. This makes matters worse as gfar_vlan_mode() ends up calling gfar_change_mtu(), though the MTU size remains the same. Note that there are other situations that may affect the required rx buffer size, like changing RXCSUM or rx hw timestamping, but errorneously the rx buffer size is not recomputed/ updated in the process. To fix this, do the vlan updates properly inside the MAC reset and reconfiguration procedure, which takes care of the rx buffer size dependecy and the rx TOE block (PRSDEP) activation/deactivation as well (in the correct order). As a consequence, MTU/ rx buff size updates are done now by the same MAC reset and reconfig procedure, so that out of context updates to MAXFRM, MRBLR, and MACCFG inside change_mtu() are no longer needed. The rx buffer size dependecy to Rx FCB is now handled for the other cases too (RXCSUM and rx hw timestamping). Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Claudiu Manoil authored
The main MAC config registers like: RCTRL/TCTRL, MRBLR, MAXFRM, RXIC/TXIC, most fields of MACCFG1/2, should not be changed on-the-fly, but at least after stopping the DMA and disabling the Rx/Tx blocks and, for increased reliability, after a MAC soft reset. Impelement a complete MAC soft reset and reconfig procedure following the latest HW advisories - gfar_mac_reset() - to replace gfar_mac_init() and (the confusing) init_registers() functions. Factor out separate config functions for RCTRL and TCTRL, insure programming order of the relevant config regs after MAC soft reset. Split gfar_hw_init() into gfar_mac_reset() and the remaining global regs that don't need to be reconfigured after MAC soft reset (FIFOCFG, ATTRELI, HW counters a.s.o). As gfar_hw_init() now makes all the register writes @probe() time, based on all the device flags and config options, it must be moved further down, just before register_netdev(), as the last config step when the config values are comitted to HW. Also, move netif_carrier_off() after register_netdev(), because it has no effect if called before. Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
Fabio Estevam authored
According to Documentation/driver-model/devres.txt, devm_request_and_ioremap() is deprecated, so use devm_ioremap_resource() instead. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
Convert the uses of memcpy to ether_addr_copy because for some architectures it is smaller and faster. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Joe Perches authored
Convert the more obvious uses of memcpy to ether_addr_copy. There are still uses of memcpy that could be converted but these addresses are __aligned(2). Convert a couple uses of 6 in gr_private.h to ETH_ALEN. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ben Hutchings authored
ethtool speed values are just numbers of megabits and there is no need to add SPEED_40000. To be consistent, use integer constants directly for all speeds. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-