- 12 Feb, 2011 7 commits
-
-
Ajit Khaparde authored
The PF needs to cleanup all the interface handles that it created for the VFs. Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ajit Khaparde authored
This is to avoid the completion processing for be_vf_eth_addr_config to consume the link status notification before netdev_register. Otherwise this causes the PF miss its first link status update. Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ajit Khaparde authored
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ajit Khaparde authored
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ajit Khaparde authored
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ajit Khaparde authored
While configuring QOS for VFs, the VF number should be translated to domain number correctly. Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
-
- 11 Feb, 2011 19 commits
-
-
Rafael J. Wysocki authored
The atl1 driver uses the legacy PCI power management, so it has to do some PCI-specific things in its ->suspend() and ->resume() callbacks, which isn't necessary and should better be done by the PCI subsystem-level power management code. Convert atl1 to the new PCI power management framework and make it let the PCI subsystem take care of all the PCI-specific aspects of device handling during system power transitions. Tested-by: Thomas Fjellstrom <thomas@fjellstrom.ca> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rafael J. Wysocki authored
The atl1c driver shouldn't call device_init_wakeup() in its probe routine with the second argument equal to 1, because for PCI devices the wakeup capability setting is initialized as appropriate by the PCI subsystem. Remove the potentially harmful call. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Rafael J. Wysocki authored
The tg3 driver uses device_init_wakeup() in such a way that the device's power.can_wakeup flag may be set even though the PCI subsystem cleared it before, in which case the device cannot wake up the system from sleep states. Modify the driver to only change the power.can_wakeup flag if the device is not capable of generating wakeup signals. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Atita Shirwaikar authored
Current driver does not show 100MB support in ethtool. Adding support for the same. Signed-off-by: Atita Shirwaikar <atita.shirwaikar@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Don Skidmore authored
The function ixgbe_init_mbx_params_pf isn't used unless CONFIG_PCI_IOV is defined. This is causing namespace warnings. So I wrapped its definition in CONFIG_PCI_IOV too. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Don Skidmore authored
We had a support function that just walked a few pointers to get from the ixgbe_hw struct to the netdev pointer. This was causing a namespace warning so I removed it and just reference the pointers directly. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Don Skidmore authored
We didn't need the prototype and it was causing namespace complaints so I made it static. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
John Fastabend authored
This consolidates hardware specifics to ixgbe_dcb.c this simplifies code that was previously branching based on hardware type. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
John Fastabend authored
This removes the RESET bit previously used to force a device reset when DCB bandwidth configurations were changed. This can now be done dynamically without a reset so the bit is no longer needed. The only remaining operations that force a device reset are DCB enable/disable and FCoE application priority changes. DCB enable/disable is a hardware requirement. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
John Fastabend authored
The 82599 and 82598 devices do not require hardware resets to configure CEE pg settings. This patch changes DCB configuration to set the CEE pg values directly from the dcbnl ops routine. This reduces the number of resets seen on the wire and allows LLDP to reach a steady state faster. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
John Fastabend authored
Implements 802.1Qaz support for ixgbe driver. Additionally, this adds IEEE_8021QAZ_TSA_{} defines to dcbnl.h this is to avoid having to use cryptic numeric codes for the TSA type. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
John Fastabend authored
Currently the routines that configure the HW for DCB require a ixgbe_dcb_config structure. This structure was designed to support the CEE standard and does not match the IEEE standard well. This patch changes the HW routines in ixgbe_dcb_8259x.{ch} to use raw pfc and bandwidth values. This requires some parsing of the DCB configuration but makes the HW routines independent of the data structure that contains the DCB configuration. The primary advantage to doing this is we can do HW setup directly from the 802.1Qaz ops without having to arbitrarily encapsulate this data into the CEE structure. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
John Fastabend authored
Remove round robin configuration code for 82598 parts it is not settable and is always false. If we need/want this in the future we can add it back properly. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
John Fastabend authored
If the FCoE priority is not changing do not set the RESET and APP_UPCHG bits. This causes unneeded HW resets and which can cause unneeded LLDP frames and negotiations. The current check is not sufficient because the FCoE priority can change twice during a negotiation which results in the bits being set. This occurs when the switch changes the priority or when the link is reset with switches that do not include the APP priority until after PFC has been negotiated. This results in set_app being called with the local APP priority. Then the negotiation completes and set_app is called again with the peer APP priority. The check fails so the device is reset and the above occurs again resulting in an endless loop of resets. By only resetting the device if the APP priority has really changed we short circuit the loop. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Carolyn Wyborny authored
This patch adds full support for SR-IOV by enabling the PF side. VF side has already been committed. Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Bruce Allan authored
...when invoked while interface is not up or when auto-negotiation is disabled as done by other drivers. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Bruce Allan authored
*e1000_gstrings_test is not the same size as e1000_gstrings_test. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Bruce Allan authored
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Matt Carlson authored
As a precautionary measure, expand the fix submitted in commit 4d163b75 entitled "tg3: Fix 5719 A0 tx completion bug" to apply to all 5719 revisions. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 10 Feb, 2011 4 commits
-
-
David S. Miller authored
If we didn't have a routing cache, we would not be able to properly propagate certain kinds of dynamic path attributes, for example PMTU information and redirects. The reason is that if we didn't have a routing cache, then there would be no way to lookup all of the active cached routes hanging off of sockets, tunnels, IPSEC bundles, etc. Consider the case where we created a cached route, but no inetpeer entry existed and also we were not asked to pre-COW the route metrics and therefore did not force the creation a new inetpeer entry. If we later get a PMTU message, or a redirect, and store this information in a new inetpeer entry, there is no way to teach that cached route about the newly existing inetpeer entry. The facilities implemented here handle this problem. First we create a generation ID. When we create a cached route of any kind, we remember the generation ID at the time of attachment. Any time we force-create an inetpeer entry in response to new path information, we bump that generation ID. The dst_ops->check() callback is where the knowledge of this event is propagated. If the global generation ID does not equal the one stored in the cached route, and the cached route has not attached to an inetpeer yet, we look it up and attach if one is found. Now that we've updated the cached route's information, we update the route's generation ID too. This clears the way for implementing PMTU and redirects directly in the inetpeer cache. There is absolutely no need to consult cached route information in order to maintain this information. At this point nothing bumps the inetpeer genids, that comes in the later changes which handle PMTUs and redirects using inetpeers. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Validity of the cached PMTU information is indicated by it's expiration value being non-zero, just as per dst->expires. The scheme we will use is that we will remember the pre-ICMP value held in the metrics or route entry, and then at expiration time we will restore that value. In this way PMTU expiration does not kill off the cached route as is done currently. Redirect information is permanent, or at least until another redirect is received. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Future changes will add caching information, and some of these new elements will be addresses. Since the family is implicit via the ->daddr.family member, replicating the family in ever address we store is entirely redundant. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xiaotian Feng authored
commit a512b92b adds sysfs entry for net device group, but before this commit, tun also uses group sysfs, so after this commit checkin, kernel warns like this: sysfs: cannot create duplicate filename '/devices/virtual/net/vnet0/group' Since tun has used this for years, rename sysfs under tun might break existing userspace, so rename group sysfs entry for net device group is a better choice. Signed-off-by: Xiaotian Feng <dfeng@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 09 Feb, 2011 6 commits
-
-
David S. Miller authored
Conflicts: drivers/net/e1000e/netdev.c
-
Tomoya authored
Currently, in case reload pch_can, pch_can not to be able to catch interrupt. The cause is bus-master is not set in pch_can. Thus, add enabling bus-master processing. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tomoya authored
Currently, when rmmod pch_can, kernel failure occurs. The cause is pci_iounmap executed before pch_can_reset. Thus pci_iounmap moves after pch_can_reset. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tomoya authored
Currently, 800k comms fails since prop_seg set zero. (EG20T PCH CAN register of prop_seg must be set more than 1) To prevent prop_seg set to zero, change tseg2_min 1 to 2. Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Nobody actually does anything in response to the event, so just kill it off. Signed-off-by: David S. Miller <davem@davemloft.net>
- 08 Feb, 2011 4 commits
-
-
David S. Miller authored
I simply missed this one when modifying the other dst metric interfaces earlier. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
In commit aa942104 ("net: init ingress queue") we moved the allocation and lock initialization of the queues into alloc_netdev_mq() since register_netdevice() is way too late. The problem is that dev->type is not setup until the setup() callback is invoked by alloc_netdev_mq(), and the dev->type is what determines the lockdep class to use for the locks in the queues. Fix this by doing the queue allocation after the setup() callback runs. This is safe because the setup() callback is not allowed to make any state changes that need to be undone on error (memory allocations, etc.). It may, however, make state changes that are undone by free_netdev() (such as netif_napi_add(), which is done by the ipoib driver's setup routine). The previous code also leaked a reference to the &init_net namespace object on RX/TX queue allocation failures. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
rtnl_link_ops->setup(), and the "setup" callback passed to alloc_netdev*(), cannot make state changes which need to be undone on failure. There is no cleanup mechanism available at this point. So we have to add the caif private instance to the global list once we are sure that register_netdev() has succedded in ->newlink(). Otherwise, if register_netdev() fails, the caller will invoke free_netdev() and we will have a reference to freed up memory on the chnl_net_list. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nicolas Dichtel authored
The Linux IPv4 AH stack aligns the AH header on a 64 bit boundary (like in IPv6). This is not RFC compliant (see RFC4302, Section 3.3.3.2.1), it should be aligned on 32 bits. For most of the authentication algorithms, the ICV size is 96 bits. The AH header alignment on 32 or 64 bits gives the same results. However for SHA-256-128 for instance, the wrong 64 bit alignment results in adding useless padding in IPv4 AH, which is forbidden by the RFC. To avoid breaking backward compatibility, we use a new flag (XFRM_STATE_ALIGN4) do change original behavior. Initial patch from Dang Hongwu <hongwu.dang@6wind.com> and Christophe Gouault <christophe.gouault@6wind.com>. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-