* Re: [PATCH 3/9] stmmac: add MMC supports exported via debugfs.
From: Giuseppe CAVALLARO @ 2011-08-29 12:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110826.121222.1125604441814245954.davem@davemloft.net>
On 8/26/2011 6:12 PM, David Miller wrote:
> From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
> Date: Thu, 25 Aug 2011 10:00:23 +0200
>
>> This patch adds the MMC management counters support.
>> MMC module is an extension of the register address
>> space and all the hardware counters can be accessed
>> via debugfs.
>> Below an example of the output:
>
> This is not the appropriate way to expose internal chip counters.
>
> Please use ethtool statistics for this.
Yes I'll do that and resend all the patches again.
Thanks for the review.
Peppe
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* RE
From: Pepsi Bottling Company Plc @ 2011-08-29 11:04 UTC (permalink / raw)
You won £120,000
^ permalink raw reply
* Personal / Treat As Urgent
From: francis @ 2011-08-29 10:20 UTC (permalink / raw)
Dear Friend,
I know that this message will come to you as a surprise. I am the Auditing and Accounting section manager with African Development Bank, Ouagadougou Burkina faso. I Hope that you will not expose or betray this trust and confident that I am about to repose on you for the mutual benefit of our both families.
I need your urgent assistance in transferring the sum of($39.5)million to your account within 10 or 14 banking days. This money has been dormant for years in our Bank without claim.I want the bank to release the money to you as the nearest person to our deceased customer late George small. who died along with his supposed next of kin in an air crash since 31st October 1999.
I don't want the money to go into government treasury as an abandoned fund. So this is the reason why I am contacting you so that the bank can release the money to you as the next of kin to the deceased customer. Please I would like you to keep this proposal as atop secret and delete it if you are not interested.
Upon receipt of your reply, I will give you full details on how the business will be executed and also note that you will have 40% of the above mentioned sum if you agree to handle this business with me.
I am expecting your urgent response as soon as you receive my message.
Best Regard,
Mr Francis Kabore
^ permalink raw reply
* [net-next 10/10] ixgbe: clear RNBC only for 82598
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
RNBC (0x03FC0) is only for 82598 and has different meaning
on newer HW. Make sure to only clear it for 82598.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 90a04e2..91986af 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -225,8 +225,9 @@ s32 ixgbe_clear_hw_cntrs_generic(struct ixgbe_hw *hw)
IXGBE_READ_REG(hw, IXGBE_GORCH);
IXGBE_READ_REG(hw, IXGBE_GOTCL);
IXGBE_READ_REG(hw, IXGBE_GOTCH);
- for (i = 0; i < 8; i++)
- IXGBE_READ_REG(hw, IXGBE_RNBC(i));
+ if (hw->mac.type == ixgbe_mac_82598EB)
+ for (i = 0; i < 8; i++)
+ IXGBE_READ_REG(hw, IXGBE_RNBC(i));
IXGBE_READ_REG(hw, IXGBE_RUC);
IXGBE_READ_REG(hw, IXGBE_RFC);
IXGBE_READ_REG(hw, IXGBE_ROC);
--
1.7.6
^ permalink raw reply related
* [net-next 09/10] ixgbe: add check for supported modes
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
When setting advertised speed/duplex with ethtool.
Also cleaned up the comment since we also support 100/F.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 82d4244..9c12b35 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -324,12 +324,16 @@ static int ixgbe_set_settings(struct net_device *netdev,
if ((hw->phy.media_type == ixgbe_media_type_copper) ||
(hw->phy.multispeed_fiber)) {
- /* 10000/copper and 1000/copper must autoneg
- * this function does not support any duplex forcing, but can
- * limit the advertising of the adapter to only 10000 or 1000 */
+ /*
+ * this function does not support duplex forcing, but can
+ * limit the advertising of the adapter to the specified speed
+ */
if (ecmd->autoneg == AUTONEG_DISABLE)
return -EINVAL;
+ if (ecmd->advertising & ~ecmd->supported)
+ return -EINVAL;
+
old = hw->phy.autoneg_advertised;
advertised = 0;
if (ecmd->advertising & ADVERTISED_10000baseT_Full)
--
1.7.6
^ permalink raw reply related
* [net-next 08/10] ixgbe: fix ixgbe_fc_autoneg_fiber bug
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
A logic error in ixgbe_fc_autoneg_fiber() that treated a masked u32 as a
boolean would make it so we would never fall hit a error check case. So
now I force the u32 to a boolean value with '!!'.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index fc1375f..90a04e2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -2121,8 +2121,8 @@ static s32 ixgbe_fc_autoneg_fiber(struct ixgbe_hw *hw)
*/
linkstat = IXGBE_READ_REG(hw, IXGBE_PCS1GLSTA);
- if (((linkstat & IXGBE_PCS1GLSTA_AN_COMPLETE) == 0) ||
- ((linkstat & IXGBE_PCS1GLSTA_AN_TIMED_OUT) == 1)) {
+ if ((!!(linkstat & IXGBE_PCS1GLSTA_AN_COMPLETE) == 0) ||
+ (!!(linkstat & IXGBE_PCS1GLSTA_AN_TIMED_OUT) == 1)) {
ret_val = IXGBE_ERR_FC_NOT_NEGOTIATED;
goto out;
}
--
1.7.6
^ permalink raw reply related
* [net-next 07/10] ixgbe: cleanup feature flags in ixgbe_probe
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: Don Skidmore, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Don Skidmore <donald.c.skidmore@intel.com>
I'm removing NETIF_F_GRO from being initialed in the feature flags during
ixgbe_probe() bases on a comment from Michal Miroslaw
<mirq-linux@rere.qmqm.pl> that it is always set by network code now.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 3932cd0..a30f826 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7510,7 +7510,6 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
NETIF_F_HW_VLAN_FILTER |
NETIF_F_TSO |
NETIF_F_TSO6 |
- NETIF_F_GRO |
NETIF_F_RXHASH |
NETIF_F_RXCSUM;
--
1.7.6
^ permalink raw reply related
* [net-next 04/10] ixgbe: remove unneeded fdir pb alloc case
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, netdev, gospo
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: John Fastabend <john.r.fastabend@intel.com>
The packet buffer is correctly allocated by generic pb allocation
path in ixgbe_configure() there is no need to do the allocation
here as well.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 87 ------------------------
1 files changed, 0 insertions(+), 87 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index 34f30ec..f193fc2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -1108,79 +1108,6 @@ s32 ixgbe_reinit_fdir_tables_82599(struct ixgbe_hw *hw)
}
/**
- * ixgbe_set_fdir_rxpba_82599 - Initialize Flow Director Rx packet buffer
- * @hw: pointer to hardware structure
- * @pballoc: which mode to allocate filters with
- **/
-static s32 ixgbe_set_fdir_rxpba_82599(struct ixgbe_hw *hw, const u32 pballoc)
-{
- u32 fdir_pbsize = hw->mac.rx_pb_size << IXGBE_RXPBSIZE_SHIFT;
- u32 current_rxpbsize = 0;
- int i;
-
- /* reserve space for Flow Director filters */
- switch (pballoc) {
- case IXGBE_FDIR_PBALLOC_256K:
- fdir_pbsize -= 256 << IXGBE_RXPBSIZE_SHIFT;
- break;
- case IXGBE_FDIR_PBALLOC_128K:
- fdir_pbsize -= 128 << IXGBE_RXPBSIZE_SHIFT;
- break;
- case IXGBE_FDIR_PBALLOC_64K:
- fdir_pbsize -= 64 << IXGBE_RXPBSIZE_SHIFT;
- break;
- case IXGBE_FDIR_PBALLOC_NONE:
- default:
- return IXGBE_ERR_PARAM;
- }
-
- /* determine current RX packet buffer size */
- for (i = 0; i < 8; i++)
- current_rxpbsize += IXGBE_READ_REG(hw, IXGBE_RXPBSIZE(i));
-
- /* if there is already room for the filters do nothing */
- if (current_rxpbsize <= fdir_pbsize)
- return 0;
-
- if (current_rxpbsize > hw->mac.rx_pb_size) {
- /*
- * if rxpbsize is greater than max then HW max the Rx buffer
- * sizes are unconfigured or misconfigured since HW default is
- * to give the full buffer to each traffic class resulting in
- * the total size being buffer size 8x actual size
- *
- * This assumes no DCB since the RXPBSIZE registers appear to
- * be unconfigured.
- */
- IXGBE_WRITE_REG(hw, IXGBE_RXPBSIZE(0), fdir_pbsize);
- for (i = 1; i < 8; i++)
- IXGBE_WRITE_REG(hw, IXGBE_RXPBSIZE(i), 0);
- } else {
- /*
- * Since the Rx packet buffer appears to have already been
- * configured we need to shrink each packet buffer by enough
- * to make room for the filters. As such we take each rxpbsize
- * value and multiply it by a fraction representing the size
- * needed over the size we currently have.
- *
- * We need to reduce fdir_pbsize and current_rxpbsize to
- * 1/1024 of their original values in order to avoid
- * overflowing the u32 being used to store rxpbsize.
- */
- fdir_pbsize >>= IXGBE_RXPBSIZE_SHIFT;
- current_rxpbsize >>= IXGBE_RXPBSIZE_SHIFT;
- for (i = 0; i < 8; i++) {
- u32 rxpbsize = IXGBE_READ_REG(hw, IXGBE_RXPBSIZE(i));
- rxpbsize *= fdir_pbsize;
- rxpbsize /= current_rxpbsize;
- IXGBE_WRITE_REG(hw, IXGBE_RXPBSIZE(i), rxpbsize);
- }
- }
-
- return 0;
-}
-
-/**
* ixgbe_fdir_enable_82599 - Initialize Flow Director control registers
* @hw: pointer to hardware structure
* @fdirctrl: value to write to flow director control register
@@ -1227,13 +1154,6 @@ static void ixgbe_fdir_enable_82599(struct ixgbe_hw *hw, u32 fdirctrl)
**/
s32 ixgbe_init_fdir_signature_82599(struct ixgbe_hw *hw, u32 fdirctrl)
{
- s32 err;
-
- /* Before enabling Flow Director, verify the Rx Packet Buffer size */
- err = ixgbe_set_fdir_rxpba_82599(hw, fdirctrl);
- if (err)
- return err;
-
/*
* Continue setup of fdirctrl register bits:
* Move the flexible bytes to use the ethertype - shift 6 words
@@ -1258,13 +1178,6 @@ s32 ixgbe_init_fdir_signature_82599(struct ixgbe_hw *hw, u32 fdirctrl)
**/
s32 ixgbe_init_fdir_perfect_82599(struct ixgbe_hw *hw, u32 fdirctrl)
{
- s32 err;
-
- /* Before enabling Flow Director, verify the Rx Packet Buffer size */
- err = ixgbe_set_fdir_rxpba_82599(hw, fdirctrl);
- if (err)
- return err;
-
/*
* Continue setup of fdirctrl register bits:
* Turn perfect match filtering on
--
1.7.6
^ permalink raw reply related
* [net-next 06/10] ixgbe: PFC not cleared on X540 devices
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: John Fastabend <john.r.fastabend@intel.com>
X540 devices do not clear PFC before sets. This results in
the device possibly responding to PFC frames that the user
has disabled. Although it would also be wrong for the peer
to be transmitting these frames. Now we clear the register
before set.
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>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c | 4 +++-
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c
index ade9820..d64fb87 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c
@@ -252,8 +252,10 @@ s32 ixgbe_dcb_config_pfc_82599(struct ixgbe_hw *hw, u8 pfc_en)
reg &= ~IXGBE_MFLCN_RFCE;
reg |= IXGBE_MFLCN_RPFCE | IXGBE_MFLCN_DPF;
- if (hw->mac.type == ixgbe_mac_X540)
+ if (hw->mac.type == ixgbe_mac_X540) {
+ reg &= ~IXGBE_MFLCN_RPFCE_MASK;
reg |= pfc_en << IXGBE_MFLCN_RPFCE_SHIFT;
+ }
IXGBE_WRITE_REG(hw, IXGBE_MFLCN, reg);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index e0d970e..9f618ee 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -1834,6 +1834,7 @@ enum {
#define IXGBE_MFLCN_DPF 0x00000002 /* Discard Pause Frame */
#define IXGBE_MFLCN_RPFCE 0x00000004 /* Receive Priority FC Enable */
#define IXGBE_MFLCN_RFCE 0x00000008 /* Receive FC Enable */
+#define IXGBE_MFLCN_RPFCE_MASK 0x00000FE0 /* Receive FC Mask */
#define IXGBE_MFLCN_RPFCE_SHIFT 4
--
1.7.6
^ permalink raw reply related
* [net-next 05/10] ixgbe: consolidate, setup for multiple traffic classes
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: John Fastabend <john.r.fastabend@intel.com>
This consolidates setup code for multiple traffic classes in
the setup_tc routine.
Prep work to allow IEEE DCBX to optimize for number of traffic
classes. Also simplifies code paths.
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>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c | 46 ++---------------------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 30 +++++++++++---
2 files changed, 27 insertions(+), 49 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c
index da6d53e..0422e35 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c
@@ -118,49 +118,11 @@ static u8 ixgbe_dcbnl_set_state(struct net_device *netdev, u8 state)
if (!!state != !(adapter->flags & IXGBE_FLAG_DCB_ENABLED))
return err;
- if (state > 0) {
- /* Turn on DCB */
- if (!(adapter->flags & IXGBE_FLAG_MSIX_ENABLED)) {
- e_err(drv, "Enable failed, needs MSI-X\n");
- err = 1;
- goto out;
- }
-
- adapter->flags |= IXGBE_FLAG_DCB_ENABLED;
-
- switch (adapter->hw.mac.type) {
- case ixgbe_mac_82598EB:
- adapter->last_lfc_mode = adapter->hw.fc.current_mode;
- adapter->hw.fc.requested_mode = ixgbe_fc_none;
- break;
- case ixgbe_mac_82599EB:
- case ixgbe_mac_X540:
- adapter->flags &= ~IXGBE_FLAG_FDIR_HASH_CAPABLE;
- break;
- default:
- break;
- }
-
- ixgbe_setup_tc(netdev, MAX_TRAFFIC_CLASS);
- } else {
- /* Turn off DCB */
- adapter->hw.fc.requested_mode = adapter->last_lfc_mode;
- adapter->temp_dcb_cfg.pfc_mode_enable = false;
- adapter->dcb_cfg.pfc_mode_enable = false;
- adapter->flags &= ~IXGBE_FLAG_DCB_ENABLED;
- switch (adapter->hw.mac.type) {
- case ixgbe_mac_82599EB:
- case ixgbe_mac_X540:
- if (!(adapter->flags & IXGBE_FLAG_FDIR_PERFECT_CAPABLE))
- adapter->flags |= IXGBE_FLAG_FDIR_HASH_CAPABLE;
- break;
- default:
- break;
- }
- ixgbe_setup_tc(netdev, 0);
- }
+ if (state > 0)
+ err = ixgbe_setup_tc(netdev, MAX_TRAFFIC_CLASS);
+ else
+ err = ixgbe_setup_tc(netdev, 0);
-out:
return err;
}
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2b1bb60..3932cd0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7065,11 +7065,11 @@ int ixgbe_setup_tc(struct net_device *dev, u8 tc)
struct ixgbe_adapter *adapter = netdev_priv(dev);
struct ixgbe_hw *hw = &adapter->hw;
- /* If DCB is anabled do not remove traffic classes, multiple
- * traffic classes are required to implement DCB
- */
- if (!tc && (adapter->flags & IXGBE_FLAG_DCB_ENABLED))
- return 0;
+ /* Multiple traffic classes requires multiple queues */
+ if (!(adapter->flags & IXGBE_FLAG_MSIX_ENABLED)) {
+ e_err(drv, "Enable failed, needs MSI-X\n");
+ return -EINVAL;
+ }
/* Hardware supports up to 8 traffic classes */
if (tc > MAX_TRAFFIC_CLASS ||
@@ -7084,11 +7084,27 @@ int ixgbe_setup_tc(struct net_device *dev, u8 tc)
ixgbe_close(dev);
ixgbe_clear_interrupt_scheme(adapter);
- if (tc)
+ if (tc) {
netdev_set_num_tc(dev, tc);
- else
+ adapter->last_lfc_mode = adapter->hw.fc.current_mode;
+
+ adapter->flags |= IXGBE_FLAG_DCB_ENABLED;
+ adapter->flags &= ~IXGBE_FLAG_FDIR_HASH_CAPABLE;
+
+ if (adapter->hw.mac.type == ixgbe_mac_82598EB)
+ adapter->hw.fc.requested_mode = ixgbe_fc_none;
+ } else {
netdev_reset_tc(dev);
+ adapter->hw.fc.requested_mode = adapter->last_lfc_mode;
+
+ adapter->flags &= ~IXGBE_FLAG_DCB_ENABLED;
+ adapter->flags |= IXGBE_FLAG_FDIR_HASH_CAPABLE;
+
+ adapter->temp_dcb_cfg.pfc_mode_enable = false;
+ adapter->dcb_cfg.pfc_mode_enable = false;
+ }
+
ixgbe_init_interrupt_scheme(adapter);
ixgbe_validate_rtr(adapter, tc);
if (netif_running(dev))
--
1.7.6
^ permalink raw reply related
* [net-next 03/10] ixgbe: fixup remaining call sites for arbitrary TCs
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: John Fastabend <john.r.fastabend@intel.com>
One existing call sites still expect either 4 or 8 traffic
classes to be specified. This fixes this allowing arbitrary
values up to 8 to work as expected.
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>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index f095a3b..2b1bb60 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4481,7 +4481,7 @@ static void ixgbe_get_first_reg_idx(struct ixgbe_adapter *adapter, u8 tc,
break;
case ixgbe_mac_82599EB:
case ixgbe_mac_X540:
- if (num_tcs == 8) {
+ if (num_tcs > 4) {
if (tc < 3) {
*tx = tc << 5;
*rx = tc << 4;
@@ -4492,7 +4492,7 @@ static void ixgbe_get_first_reg_idx(struct ixgbe_adapter *adapter, u8 tc,
*tx = ((tc + 8) << 3);
*rx = tc << 4;
}
- } else if (num_tcs == 4) {
+ } else {
*rx = tc << 5;
switch (tc) {
case 0:
--
1.7.6
^ permalink raw reply related
* [net-next 02/10] ixgbe: Always tag VLAN tagged packets
From: Jeff Kirsher @ 2011-08-29 8:41 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This change is meant to fix the patch:
ixgbe: Cleanup FCOE and VLAN handling in xmit_frame_ring
And can be rolled into it if needed.
What this fixes is that VLAN tagged packets were not being tagged if they
were prio 7 which matches up with TC_PRIO_CONTROL. In order to fix it I am
just setting things up so that we always tag VLAN tagged packets.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index d587967..f095a3b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6762,7 +6762,8 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
}
if ((adapter->flags & IXGBE_FLAG_DCB_ENABLED) &&
- skb->priority != TC_PRIO_CONTROL) {
+ ((tx_flags & (IXGBE_TX_FLAGS_HW_VLAN | IXGBE_TX_FLAGS_SW_VLAN)) ||
+ (skb->priority != TC_PRIO_CONTROL))) {
tx_flags &= ~IXGBE_TX_FLAGS_VLAN_PRIO_MASK;
tx_flags |= tx_ring->dcb_tc <<
IXGBE_TX_FLAGS_VLAN_PRIO_SHIFT;
--
1.7.6
^ permalink raw reply related
* [net-next 01/10] ixgbe: Add support for setting CC bit when SR-IOV is enabled
From: Jeff Kirsher @ 2011-08-29 8:40 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, gospo, Jeff Kirsher
In-Reply-To: <1314607268-26958-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This change makes it so that the CC bit in the descriptor is set when
SR-IOV is enabled. This is needed in order to support offloading
functionality when passing traffic over the internal TX switch.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 ++++++++++++++-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index dc3b12e..58482fc 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -97,7 +97,8 @@
#define IXGBE_TX_FLAGS_IPV4 (u32)(1 << 4)
#define IXGBE_TX_FLAGS_FCOE (u32)(1 << 5)
#define IXGBE_TX_FLAGS_FSO (u32)(1 << 6)
-#define IXGBE_TX_FLAGS_MAPPED_AS_PAGE (u32)(1 << 7)
+#define IXGBE_TX_FLAGS_TXSW (u32)(1 << 7)
+#define IXGBE_TX_FLAGS_MAPPED_AS_PAGE (u32)(1 << 8)
#define IXGBE_TX_FLAGS_VLAN_MASK 0xffff0000
#define IXGBE_TX_FLAGS_VLAN_PRIO_MASK 0xe0000000
#define IXGBE_TX_FLAGS_VLAN_PRIO_SHIFT 29
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index bb54d3d..d587967 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6295,7 +6295,8 @@ static bool ixgbe_tx_csum(struct ixgbe_ring *tx_ring,
u32 type_tucmd = 0;
if (skb->ip_summed != CHECKSUM_PARTIAL) {
- if (!(tx_flags & IXGBE_TX_FLAGS_HW_VLAN))
+ if (!(tx_flags & IXGBE_TX_FLAGS_HW_VLAN) &&
+ !(tx_flags & IXGBE_TX_FLAGS_TXSW))
return false;
} else {
u8 l4_hdr = 0;
@@ -6398,6 +6399,13 @@ static __le32 ixgbe_tx_olinfo_status(u32 tx_flags, unsigned int paylen)
(1 << IXGBE_ADVTXD_IDX_SHIFT));
#endif
+ /*
+ * Check Context must be set if Tx switch is enabled, which it
+ * always is for case where virtual functions are running
+ */
+ if (tx_flags & IXGBE_TX_FLAGS_TXSW)
+ olinfo_status |= cpu_to_le32(IXGBE_ADVTXD_CC);
+
return olinfo_status;
}
@@ -6732,6 +6740,11 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
return NETDEV_TX_BUSY;
}
+#ifdef CONFIG_PCI_IOV
+ if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
+ tx_flags |= IXGBE_TX_FLAGS_TXSW;
+
+#endif
/* if we have a HW VLAN tag being added default to the HW one */
if (vlan_tx_tag_present(skb)) {
tx_flags |= vlan_tx_tag_get(skb) << IXGBE_TX_FLAGS_VLAN_SHIFT;
--
1.7.6
^ permalink raw reply related
* [net-next 00/10][pull request] Intel Wired LAN Driver Update
From: Jeff Kirsher @ 2011-08-29 8:40 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
The following series contains updates to ixgbe only. Many are cleanup's
and fixes.
The following are changes since commit 7ac2ed0ceeafa130f85aa947b271b571c68b9e75:
caif: Remove OOM messages, use kzalloc
and are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next master
Alexander Duyck (2):
ixgbe: Add support for setting CC bit when SR-IOV is enabled
ixgbe: Always tag VLAN tagged packets
Don Skidmore (2):
ixgbe: cleanup feature flags in ixgbe_probe
ixgbe: fix ixgbe_fc_autoneg_fiber bug
Emil Tantilov (2):
ixgbe: add check for supported modes
ixgbe: clear RNBC only for 82598
John Fastabend (4):
ixgbe: fixup remaining call sites for arbitrary TCs
ixgbe: remove unneeded fdir pb alloc case
ixgbe: consolidate, setup for multiple traffic classes
ixgbe: PFC not cleared on X540 devices
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 87 --------------------
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 9 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_nl.c | 46 +----------
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 10 ++-
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 53 +++++++++---
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
8 files changed, 63 insertions(+), 150 deletions(-)
--
1.7.6
^ permalink raw reply
* [PATCH] Always initialize fw_entry with NULL
From: Thomas Jarosch @ 2011-08-29 7:39 UTC (permalink / raw)
To: netdev
Otherwise the exit code path might try to release
a non-existing firmware object on an error condition.
Issue detected by cppcheck.
Resending to netdev as orionco-devel seems to be sleeping.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
---
drivers/net/wireless/orinoco/orinoco_usb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/orinoco/orinoco_usb.c
b/drivers/net/wireless/orinoco/orinoco_usb.c
index 811e87f..973a55f 100644
--- a/drivers/net/wireless/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/orinoco/orinoco_usb.c
@@ -1579,7 +1579,7 @@ static int ezusb_probe(struct usb_interface
*interface,
struct ezusb_priv *upriv = NULL;
struct usb_interface_descriptor *iface_desc;
struct usb_endpoint_descriptor *ep;
- const struct firmware *fw_entry;
+ const struct firmware *fw_entry = NULL;
int retval = 0;
int i;
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: David Miller @ 2011-08-29 6:34 UTC (permalink / raw)
To: stephen.hemminger
Cc: eric.dumazet, herbert, kaber, mirq-linux, therbert, jesse, netdev,
linux-kernel, yrl.pp-manager.tt, mitsuo.hayasaka.hu
In-Reply-To: <f6ded72b-346d-43af-af47-4edae5060406@tahiti.vyatta.com>
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Sun, 28 Aug 2011 23:06:28 -0700 (PDT)
> This was mostly typical of older hardware that did not have a PHY
> interrupt.
Many have to poll because the PHY interrupt is simply unreliable.
^ permalink raw reply
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: Eric Dumazet @ 2011-08-29 6:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Herbert Xu, Patrick McHardy, David S. Miller,
MichałMirosław, Tom Herbert, Jesse Gross, netdev,
linux-kernel, yrl pp-manager tt, HAYASAKA Mitsuo
In-Reply-To: <f6ded72b-346d-43af-af47-4edae5060406@tahiti.vyatta.com>
Le dimanche 28 août 2011 à 23:06 -0700, Stephen Hemminger a écrit :
>
> ----- Original Message -----
> > Le dimanche 28 août 2011 à 22:20 +0900, HAYASAKA Mitsuo a écrit :
> > > Hi Stephen and Herbert
> > >
> > > Thank you for your comments.
> > >
> > > (2011/08/26 15:08), Stephen Hemminger wrote:
> > > > I don't think this is the right way to solve the problem.
> > > >
> > > > The flags are supposed to propagate back from real device to vlan
> > > > via network notifications.
> > > >
> > > > Just doing this for ioctl is not enough, API's other than user
> > > > space depend on this.
> > > > Also the user may have manually set different flags on vlan than
> > > > on
> > > > the real device.
> > >
> > > I agreed.
> > > I will try another way to solve this problem, as you said.
> > >
> > >
> > > (2011/08/26 15:45), Herbert Xu wrote:
> > > > On Thu, Aug 25, 2011 at 11:08:59PM -0700, Stephen Hemminger
> > > > wrote:
> > > >> Just doing this for ioctl is not enough, API's other than user
> > > >> space depend on this.
> > > >> Also the user may have manually set different flags on vlan than
> > > >> on
> > > >> the real device.
> > > > Right, anything that tests netif_carrier_ok directly on the VLAN
> > > > device will still be delayed.
> > > >
> > > > Now I remember discussing this issue in Japan. However, I can't
> > > > recall the exact scenario in which the delay occured.
> > > >
> > > > Is the issue with the link status going down on the real device,
> > > > or the real device coming up?
> > > >
> > > > IIRC we already have mechanisms in place to ensure that down
> > > > events
> > > > are not delayed by linkwatch. Of course it is possible that this
> > > > isn't working for some reason, or some other part of the system
> > > > is
> > > > causing the delay.
> > > >
> > > > So please clarify the scenario for us Hayasaka-san. Also please
> > > > let us know how you measured the delay.
> > > >
> > > > Thanks,
> > >
> > > This issue happens when the link status is going down on the real
> > > device.
> > >
> > > ex) A cable is broken, or is unplugged from a NIC.
> > >
> > > I measured the delay using ioctl with SIOCGIFFLAGS from userspace
> > > in order to check if there is a time-lag of the flag between vlan
> > > and real devices.
> > >
> > > Also, you can check it using a script below.
> > >
> > > -------------------------
> > > #!/bin/sh
> > > t=0
> > > while :
> > > do
> > > echo $t; t=$((t+1))
> > > echo -n real; ifconfig RealDev | grep UP
> > > echo -n vlan; ifconfig VlanDev | grep UP
> > > sleep 0.2
> > > done
> > > -------------------------
> > >
> > > The result is shown as follows.
> > > It is observed that there is a time-lag of RUNNING status between
> > > real and vlan devices.
> > >
> > >
> >
> > Hi !
> >
> > This reminds me some work done in linkwatch
> >
> > Please take a look at commit e014debecd3ee3832e647 (linkwatch:
> > linkwatch_forget_dev() to speedup device dismantle)
> >
> > And more generally, code in net/core/link_watch.c
>
> Maybe the problem is specific to a ethernet driver. Some devices poll
> for link changes, and also do a manual check when ioctl was done.
> This was mostly typical of older hardware that did not have a PHY
> interrupt.
Hmm, I just tried the script on my laptop, and reproduced the problem
with a tg3 driver, considered as a reference one ;)
the 'carrier is on' event is immediately present on both devices, but
the 'carrier is off' is delayed by one second.
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M
Gigabit Ethernet PCI Express (rev 02)
Subsystem: Dell Device 01f9
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at f1ef0000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at <ignored> [disabled]
Capabilities: <access denied>
Kernel driver in use: tg3
Kernel modules: tg3
^ permalink raw reply
* Re: [PATCH net-next ] Fix time-lag of IFF_RUNNING flag consistency between vlan and real devices
From: Stephen Hemminger @ 2011-08-29 6:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Herbert Xu, Patrick McHardy, David S. Miller,
MichałMirosław, Tom Herbert, Jesse Gross, netdev,
linux-kernel, yrl pp-manager tt, HAYASAKA Mitsuo
In-Reply-To: <1314540589.3036.12.camel@edumazet-laptop>
----- Original Message -----
> Le dimanche 28 août 2011 à 22:20 +0900, HAYASAKA Mitsuo a écrit :
> > Hi Stephen and Herbert
> >
> > Thank you for your comments.
> >
> > (2011/08/26 15:08), Stephen Hemminger wrote:
> > > I don't think this is the right way to solve the problem.
> > >
> > > The flags are supposed to propagate back from real device to vlan
> > > via network notifications.
> > >
> > > Just doing this for ioctl is not enough, API's other than user
> > > space depend on this.
> > > Also the user may have manually set different flags on vlan than
> > > on
> > > the real device.
> >
> > I agreed.
> > I will try another way to solve this problem, as you said.
> >
> >
> > (2011/08/26 15:45), Herbert Xu wrote:
> > > On Thu, Aug 25, 2011 at 11:08:59PM -0700, Stephen Hemminger
> > > wrote:
> > >> Just doing this for ioctl is not enough, API's other than user
> > >> space depend on this.
> > >> Also the user may have manually set different flags on vlan than
> > >> on
> > >> the real device.
> > > Right, anything that tests netif_carrier_ok directly on the VLAN
> > > device will still be delayed.
> > >
> > > Now I remember discussing this issue in Japan. However, I can't
> > > recall the exact scenario in which the delay occured.
> > >
> > > Is the issue with the link status going down on the real device,
> > > or the real device coming up?
> > >
> > > IIRC we already have mechanisms in place to ensure that down
> > > events
> > > are not delayed by linkwatch. Of course it is possible that this
> > > isn't working for some reason, or some other part of the system
> > > is
> > > causing the delay.
> > >
> > > So please clarify the scenario for us Hayasaka-san. Also please
> > > let us know how you measured the delay.
> > >
> > > Thanks,
> >
> > This issue happens when the link status is going down on the real
> > device.
> >
> > ex) A cable is broken, or is unplugged from a NIC.
> >
> > I measured the delay using ioctl with SIOCGIFFLAGS from userspace
> > in order to check if there is a time-lag of the flag between vlan
> > and real devices.
> >
> > Also, you can check it using a script below.
> >
> > -------------------------
> > #!/bin/sh
> > t=0
> > while :
> > do
> > echo $t; t=$((t+1))
> > echo -n real; ifconfig RealDev | grep UP
> > echo -n vlan; ifconfig VlanDev | grep UP
> > sleep 0.2
> > done
> > -------------------------
> >
> > The result is shown as follows.
> > It is observed that there is a time-lag of RUNNING status between
> > real and vlan devices.
> >
> >
>
> Hi !
>
> This reminds me some work done in linkwatch
>
> Please take a look at commit e014debecd3ee3832e647 (linkwatch:
> linkwatch_forget_dev() to speedup device dismantle)
>
> And more generally, code in net/core/link_watch.c
Maybe the problem is specific to a ethernet driver. Some devices poll
for link changes, and also do a manual check when ioctl was done.
This was mostly typical of older hardware that did not have a PHY
interrupt.
^ permalink raw reply
* Re: [PATCH] net: relax PKTINFO non local ipv6 udp xmit check
From: David Miller @ 2011-08-29 1:06 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, ek, lorenzo
In-Reply-To: <1314570931-6233-1-git-send-email-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Sun, 28 Aug 2011 15:35:31 -0700
> From: Maciej Żenczykowski <maze@google.com>
>
> Allow transparent sockets to be less restrictive about
> the source ip of ipv6 udp packets being sent.
>
> Google-Bug-Id: 5018138
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
Applied, thanks a lot.
^ permalink raw reply
* [PATCH] net: relax PKTINFO non local ipv6 udp xmit check
From: Maciej Żenczykowski @ 2011-08-28 22:35 UTC (permalink / raw)
To: Maciej Żenczykowski, David S. Miller
Cc: netdev, Maciej Żenczykowski, Erik Kline, Lorenzo Colitti
In-Reply-To: <20110828.171154.1746224796788156557.davem@davemloft.net>
From: Maciej Żenczykowski <maze@google.com>
Allow transparent sockets to be less restrictive about
the source ip of ipv6 udp packets being sent.
Google-Bug-Id: 5018138
Signed-off-by: Maciej Żenczykowski <maze@google.com>
CC: "Erik Kline" <ek@google.com>
CC: "Lorenzo Colitti" <lorenzo@google.com>
---
include/net/transp_v6.h | 1 +
net/ipv6/datagram.c | 5 +++--
net/ipv6/ip6_flowlabel.c | 8 ++++----
net/ipv6/ipv6_sockglue.c | 2 +-
net/ipv6/raw.c | 4 ++--
net/ipv6/udp.c | 4 ++--
6 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/include/net/transp_v6.h b/include/net/transp_v6.h
index 5271a74..498433d 100644
--- a/include/net/transp_v6.h
+++ b/include/net/transp_v6.h
@@ -39,6 +39,7 @@ extern int datagram_recv_ctl(struct sock *sk,
struct sk_buff *skb);
extern int datagram_send_ctl(struct net *net,
+ struct sock *sk,
struct msghdr *msg,
struct flowi6 *fl6,
struct ipv6_txoptions *opt,
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 9ef1831..b46e9f8 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -599,7 +599,7 @@ int datagram_recv_ctl(struct sock *sk, struct msghdr *msg, struct sk_buff *skb)
return 0;
}
-int datagram_send_ctl(struct net *net,
+int datagram_send_ctl(struct net *net, struct sock *sk,
struct msghdr *msg, struct flowi6 *fl6,
struct ipv6_txoptions *opt,
int *hlimit, int *tclass, int *dontfrag)
@@ -658,7 +658,8 @@ int datagram_send_ctl(struct net *net,
if (addr_type != IPV6_ADDR_ANY) {
int strict = __ipv6_addr_src_scope(addr_type) <= IPV6_ADDR_SCOPE_LINKLOCAL;
- if (!ipv6_chk_addr(net, &src_info->ipi6_addr,
+ if (!inet_sk(sk)->transparent &&
+ !ipv6_chk_addr(net, &src_info->ipi6_addr,
strict ? dev : NULL, 0))
err = -EINVAL;
else
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index f3caf1b..5430394 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -322,8 +322,8 @@ static int fl6_renew(struct ip6_flowlabel *fl, unsigned long linger, unsigned lo
}
static struct ip6_flowlabel *
-fl_create(struct net *net, struct in6_flowlabel_req *freq, char __user *optval,
- int optlen, int *err_p)
+fl_create(struct net *net, struct sock *sk, struct in6_flowlabel_req *freq,
+ char __user *optval, int optlen, int *err_p)
{
struct ip6_flowlabel *fl = NULL;
int olen;
@@ -360,7 +360,7 @@ fl_create(struct net *net, struct in6_flowlabel_req *freq, char __user *optval,
msg.msg_control = (void*)(fl->opt+1);
memset(&flowi6, 0, sizeof(flowi6));
- err = datagram_send_ctl(net, &msg, &flowi6, fl->opt, &junk,
+ err = datagram_send_ctl(net, sk, &msg, &flowi6, fl->opt, &junk,
&junk, &junk);
if (err)
goto done;
@@ -528,7 +528,7 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
if (freq.flr_label & ~IPV6_FLOWLABEL_MASK)
return -EINVAL;
- fl = fl_create(net, &freq, optval, optlen, &err);
+ fl = fl_create(net, sk, &freq, optval, optlen, &err);
if (fl == NULL)
return err;
sfl1 = kmalloc(sizeof(*sfl1), GFP_KERNEL);
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 147ede38..2fbda5f 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -475,7 +475,7 @@ sticky_done:
msg.msg_controllen = optlen;
msg.msg_control = (void*)(opt+1);
- retv = datagram_send_ctl(net, &msg, &fl6, opt, &junk, &junk,
+ retv = datagram_send_ctl(net, sk, &msg, &fl6, opt, &junk, &junk,
&junk);
if (retv)
goto done;
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index f34902f..3486f62 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -817,8 +817,8 @@ static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk,
memset(opt, 0, sizeof(struct ipv6_txoptions));
opt->tot_len = sizeof(struct ipv6_txoptions);
- err = datagram_send_ctl(sock_net(sk), msg, &fl6, opt, &hlimit,
- &tclass, &dontfrag);
+ err = datagram_send_ctl(sock_net(sk), sk, msg, &fl6, opt,
+ &hlimit, &tclass, &dontfrag);
if (err < 0) {
fl6_sock_release(flowlabel);
return err;
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 35bbdc4..f4ca0a5 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1090,8 +1090,8 @@ do_udp_sendmsg:
memset(opt, 0, sizeof(struct ipv6_txoptions));
opt->tot_len = sizeof(*opt);
- err = datagram_send_ctl(sock_net(sk), msg, &fl6, opt, &hlimit,
- &tclass, &dontfrag);
+ err = datagram_send_ctl(sock_net(sk), sk, msg, &fl6, opt,
+ &hlimit, &tclass, &dontfrag);
if (err < 0) {
fl6_sock_release(flowlabel);
return err;
--
1.7.3.1
^ permalink raw reply related
* Re: [RFC PATCH] caif: Remove OOM messages, use kzalloc
From: David Miller @ 2011-08-28 21:16 UTC (permalink / raw)
To: joe; +Cc: akpm, sjur.brandeland, linux-kernel, eric.dumazet, netdev
In-Reply-To: <1314314545.4637.19.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Thu, 25 Aug 2011 16:22:24 -0700
> Remove per site OOM messages because they duplicate
> the generic mm subsystem OOM message.
>
> Use kzalloc instead of kmalloc/memset
> when next to the OOM message removals.
>
> Reduces object size (allyesconfig ~2%)
>
> $ size -t drivers/net/caif/built-in.o.old net/caif/built-in.o.old
> text data bss dec hex filename
> 32297 700 8224 41221 a105 drivers/net/caif/built-in.o.old
> 72159 1317 20552 94028 16f4c net/caif/built-in.o.old
> 104456 2017 28776 135249 21051 (TOTALS)
> $ size -t drivers/net/caif/built-in.o.new net/caif/built-in.o.new
> text data bss dec hex filename
> 31975 700 8184 40859 9f9b drivers/net/caif/built-in.o.new
> 70748 1317 20152 92217 16839 net/caif/built-in.o.new
> 102723 2017 28336 133076 207d4 (TOTALS)
>
> Signed-off-by: Joe Perches <joe@perches.com>
Looks good to me, applied, thanks Joe.
^ permalink raw reply
* Re: [patch net-next-2.6] benet: remove bogus "unlikely" on vlan check
From: David Miller @ 2011-08-28 21:14 UTC (permalink / raw)
To: jpirko
Cc: netdev, eric.dumazet, sathya.perla, subbu.seetharaman,
ajit.khaparde, ivecera
In-Reply-To: <1314276651-9138-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 25 Aug 2011 14:50:51 +0200
> Use of unlikely in this place is wrong. Remove it.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
I'll apply this, thanks Jiri.
^ permalink raw reply
* Re: [PATCH] net: relax PKTINFO non local ipv6 udp xmit check
From: David Miller @ 2011-08-28 21:11 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, yoshfuji, ek, lorenzo
In-Reply-To: <1314395788-20179-1-git-send-email-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Fri, 26 Aug 2011 14:56:28 -0700
> diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
> index f3caf1b..a896987 100644
> --- a/net/ipv6/ip6_flowlabel.c
> +++ b/net/ipv6/ip6_flowlabel.c
> @@ -360,7 +360,7 @@ fl_create(struct net *net, struct in6_flowlabel_req *freq, char __user *optval,
> msg.msg_control = (void*)(fl->opt+1);
> memset(&flowi6, 0, sizeof(flowi6));
>
> - err = datagram_send_ctl(net, &msg, &flowi6, fl->opt, &junk,
> + err = datagram_send_ctl(net, NULL, &msg, &flowi6, fl->opt, &junk,
> &junk, &junk);
> if (err)
> goto done;
There is a socket associated with this fl_create() request, please
pass it into fl_create() from it's caller, and thus down into
datagram_send_ctl(), instead of just passing NULL.
Then, since a valid sk is always passed in, you can elide the NULL
check on 'sk' down at the bottom of these code paths.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3 net-next] net: Define NETDEV_FCOE_WWNN, NETDEV_FCOE_WWPN only when CONFIG_LIBFCOE is enabled
From: David Miller @ 2011-08-28 21:09 UTC (permalink / raw)
To: mchan; +Cc: netdev, yi.zou, bprakash
In-Reply-To: <1314387941-2126-3-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 26 Aug 2011 12:45:41 -0700
> From: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
>
> bnx2fc driver calls netdev->netdev_ops->ndo_fcoe_get_wwn() and it may not
> be defined with the current Kconfig dependencies. ndo_fcoe_get_wwn is
> dependent on CONFIG_FCOE, but bnx2fc does not select CONFIG_FCOE, as it does
> not depend on fcoe driver. Since both fcoe and bnx2fc drivers select
> CONFIG_LIBFCOE, define NETDEV_FCOE_WWNN and NETDEV_FCOE_WWPN when
> CONFIG_LIBFCOE is defined.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3 net-next] cnic: Add timeout for ramrod replies.
From: David Miller @ 2011-08-28 21:08 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1314387941-2126-2-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 26 Aug 2011 12:45:40 -0700
> If the bnx2x device has encountered parity errors, the chip will not DMA
> any replies. Using wait_event_timeout() will allow us to make forward
> progress and let bnx2x reset the chip.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox