* [net-next v2 14/14] i40e and i40evf: Bump driver versions
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Catherine Sullivan, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Catherine Sullivan <catherine.sullivan@intel.com>
Update the driver versions.
Change-ID: I3fe23024d17da0e614ce126edb365bb2c428d482
Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 0d340d2..53f3ed2 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -38,7 +38,7 @@ static const char i40e_driver_string[] =
#define DRV_VERSION_MAJOR 0
#define DRV_VERSION_MINOR 3
-#define DRV_VERSION_BUILD 31
+#define DRV_VERSION_BUILD 32
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) DRV_KERN
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 1e0171c..b2c03bc 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -31,7 +31,7 @@ char i40evf_driver_name[] = "i40evf";
static const char i40evf_driver_string[] =
"Intel(R) XL710 X710 Virtual Function Network Driver";
-#define DRV_VERSION "0.9.12"
+#define DRV_VERSION "0.9.13"
const char i40evf_driver_version[] = DRV_VERSION;
static const char i40evf_copyright[] =
"Copyright (c) 2013 - 2014 Intel Corporation.";
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 11/14] i40e: remove unnecessary delay
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
Ain't nothing gonna break my stride, nobody's gonna slow me down,
oh no. I got to keep on moving.
This was originally put in for debugging just-in-case purposes
and never removed.
Change-ID: Ic12c2e179c3923f54e6ba0a9e4ab05d25c3bab29
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 7d133fa..189e250 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -671,7 +671,6 @@ void i40e_reset_vf(struct i40e_vf *vf, bool flr)
complete_reset:
/* reallocate vf resources to reset the VSI state */
i40e_free_vf_res(vf);
- mdelay(10);
i40e_alloc_vf_res(vf);
i40e_enable_vf_mappings(vf);
set_bit(I40E_VF_STAT_ACTIVE, &vf->vf_states);
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 10/14] i40evf: remove errant space
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem; +Cc: Mitch A Williams, netdev, gospo, sassmann, Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch A Williams <mitch.a.williams@intel.com>
Remove a bogus space.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h b/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
index f7cea1b..97662b6 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
@@ -1229,7 +1229,7 @@ struct i40e_aqc_add_remove_cloud_filters_element_data {
#define I40E_AQC_ADD_CLOUD_TNL_TYPE_NGE 2
#define I40E_AQC_ADD_CLOUD_TNL_TYPE_IP 3
- __le32 tenant_id ;
+ __le32 tenant_id;
u8 reserved[4];
__le16 queue_number;
#define I40E_AQC_ADD_CLOUD_QUEUE_SHIFT 0
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 08/14] i40evf: store ring size in ring structs
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
Keep the descriptor ring size in the actual ring structs instead of in
the adapter struct. This enables us to use common tx and rx code with
the i40e PF driver.
Also update copyrights.
Change-ID: I2861e599b2b4c76441c062ea14400f4750f54d0e
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf.h | 2 --
drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 13 ++++++++-----
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 ---
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf.h b/drivers/net/ethernet/intel/i40evf/i40evf.h
index c9a5056..ccb43d3 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf.h
+++ b/drivers/net/ethernet/intel/i40evf/i40evf.h
@@ -196,8 +196,6 @@ struct i40evf_adapter {
/* RX */
struct i40e_ring *rx_rings[I40E_MAX_VSI_QP];
- int txd_count;
- int rxd_count;
u64 hw_csum_rx_error;
int num_msix_vectors;
struct msix_entry *msix_entries;
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
index b0b1f4b..8b0db1c 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c
@@ -1,7 +1,7 @@
/*******************************************************************************
*
* Intel Ethernet Controller XL710 Family Linux Virtual Function Driver
- * Copyright(c) 2013 Intel Corporation.
+ * Copyright(c) 2013 - 2014 Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -241,6 +241,7 @@ static int i40evf_set_ringparam(struct net_device *netdev,
{
struct i40evf_adapter *adapter = netdev_priv(netdev);
u32 new_rx_count, new_tx_count;
+ int i;
if ((ring->rx_mini_pending) || (ring->rx_jumbo_pending))
return -EINVAL;
@@ -256,12 +257,14 @@ static int i40evf_set_ringparam(struct net_device *netdev,
new_rx_count = ALIGN(new_rx_count, I40EVF_REQ_DESCRIPTOR_MULTIPLE);
/* if nothing to do return success */
- if ((new_tx_count == adapter->txd_count) &&
- (new_rx_count == adapter->rxd_count))
+ if ((new_tx_count == adapter->tx_rings[0]->count) &&
+ (new_rx_count == adapter->rx_rings[0]->count))
return 0;
- adapter->txd_count = new_tx_count;
- adapter->rxd_count = new_rx_count;
+ for (i = 0; i < adapter->vsi_res->num_queue_pairs; i++) {
+ adapter->tx_rings[0]->count = new_tx_count;
+ adapter->rx_rings[0]->count = new_rx_count;
+ }
if (netif_running(netdev))
i40evf_reinit_locked(adapter);
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 40a5e78..d05d5c1 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -2025,9 +2025,6 @@ static void i40evf_init_task(struct work_struct *work)
adapter->flags |= I40EVF_FLAG_RX_CSUM_ENABLED;
- adapter->txd_count = I40EVF_DEFAULT_TXD;
- adapter->rxd_count = I40EVF_DEFAULT_RXD;
-
netdev->netdev_ops = &i40evf_netdev_ops;
i40evf_set_ethtool_ops(netdev);
netdev->watchdog_timeo = 5 * HZ;
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 09/14] i40evf: update version and copyright date
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
A bunch of changes merit a new version number, and since these were
made in the new year, update the copyright date.
Change-ID: Ic3f282bf0c20679b9fb06860211afa7c78055bc2
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index d05d5c1..c4185f0 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -31,10 +31,10 @@ char i40evf_driver_name[] = "i40evf";
static const char i40evf_driver_string[] =
"Intel(R) XL710 X710 Virtual Function Network Driver";
-#define DRV_VERSION "0.9.11"
+#define DRV_VERSION "0.9.12"
const char i40evf_driver_version[] = DRV_VERSION;
static const char i40evf_copyright[] =
- "Copyright (c) 2013 Intel Corporation.";
+ "Copyright (c) 2013 - 2014 Intel Corporation.";
/* i40evf_pci_tbl - PCI Device ID Table
*
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 12/14] i40e: tighten up ring enable/disable flow
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
Change the do/while to a for loop, so we don't hit the delay each
time, even when the register is ready for action.
Don't bother to set or clear the QENA_STAT bit as it is
read-only.
Change-ID: Ie464718804dd79f6d726f291caa9b0c872b49978
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 32 ++++++++++++++---------------
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 3116861..5259a60 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -3108,13 +3108,13 @@ static int i40e_vsi_control_tx(struct i40e_vsi *vsi, bool enable)
pf_q = vsi->base_queue;
for (i = 0; i < vsi->num_queue_pairs; i++, pf_q++) {
- j = 1000;
- do {
- usleep_range(1000, 2000);
+ for (j = 0; j < 50; j++) {
tx_reg = rd32(hw, I40E_QTX_ENA(pf_q));
- } while (j-- && ((tx_reg >> I40E_QTX_ENA_QENA_REQ_SHIFT)
- ^ (tx_reg >> I40E_QTX_ENA_QENA_STAT_SHIFT)) & 1);
-
+ if (((tx_reg >> I40E_QTX_ENA_QENA_REQ_SHIFT) & 1) ==
+ ((tx_reg >> I40E_QTX_ENA_QENA_STAT_SHIFT) & 1))
+ break;
+ usleep_range(1000, 2000);
+ }
/* Skip if the queue is already in the requested state */
if (enable && (tx_reg & I40E_QTX_ENA_QENA_STAT_MASK))
continue;
@@ -3124,8 +3124,7 @@ static int i40e_vsi_control_tx(struct i40e_vsi *vsi, bool enable)
/* turn on/off the queue */
if (enable) {
wr32(hw, I40E_QTX_HEAD(pf_q), 0);
- tx_reg |= I40E_QTX_ENA_QENA_REQ_MASK |
- I40E_QTX_ENA_QENA_STAT_MASK;
+ tx_reg |= I40E_QTX_ENA_QENA_REQ_MASK;
} else {
tx_reg &= ~I40E_QTX_ENA_QENA_REQ_MASK;
}
@@ -3172,12 +3171,13 @@ static int i40e_vsi_control_rx(struct i40e_vsi *vsi, bool enable)
pf_q = vsi->base_queue;
for (i = 0; i < vsi->num_queue_pairs; i++, pf_q++) {
- j = 1000;
- do {
- usleep_range(1000, 2000);
+ for (j = 0; j < 50; j++) {
rx_reg = rd32(hw, I40E_QRX_ENA(pf_q));
- } while (j-- && ((rx_reg >> I40E_QRX_ENA_QENA_REQ_SHIFT)
- ^ (rx_reg >> I40E_QRX_ENA_QENA_STAT_SHIFT)) & 1);
+ if (((rx_reg >> I40E_QRX_ENA_QENA_REQ_SHIFT) & 1) ==
+ ((rx_reg >> I40E_QRX_ENA_QENA_STAT_SHIFT) & 1))
+ break;
+ usleep_range(1000, 2000);
+ }
if (enable) {
/* is STAT set ? */
@@ -3191,11 +3191,9 @@ static int i40e_vsi_control_rx(struct i40e_vsi *vsi, bool enable)
/* turn on/off the queue */
if (enable)
- rx_reg |= I40E_QRX_ENA_QENA_REQ_MASK |
- I40E_QRX_ENA_QENA_STAT_MASK;
+ rx_reg |= I40E_QRX_ENA_QENA_REQ_MASK;
else
- rx_reg &= ~(I40E_QRX_ENA_QENA_REQ_MASK |
- I40E_QRX_ENA_QENA_STAT_MASK);
+ rx_reg &= ~I40E_QRX_ENA_QENA_REQ_MASK;
wr32(hw, I40E_QRX_ENA(pf_q), rx_reg);
/* wait for the change to finish */
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 13/14] i40e: Change MSIX to MSI-X
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Catherine Sullivan, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Catherine Sullivan <catherine.sullivan@intel.com>
Fix inconsistent use of MSIX and MSI-X in messages.
Change-ID: Iae9ffb42819677c34544719044ed77632e06147d
Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 9 +++++----
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 3 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 5259a60..0d340d2 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -5925,7 +5925,7 @@ static int i40e_init_msix(struct i40e_pf *pf)
} else if (vec == I40E_MIN_MSIX) {
/* Adjust for minimal MSIX use */
- dev_info(&pf->pdev->dev, "Features disabled, not enough MSIX vectors\n");
+ dev_info(&pf->pdev->dev, "Features disabled, not enough MSI-X vectors\n");
pf->flags &= ~I40E_FLAG_VMDQ_ENABLED;
pf->num_vmdq_vsis = 0;
pf->num_vmdq_qps = 0;
@@ -6054,7 +6054,7 @@ static void i40e_init_interrupt_scheme(struct i40e_pf *pf)
if (!(pf->flags & I40E_FLAG_MSIX_ENABLED) &&
(pf->flags & I40E_FLAG_MSI_ENABLED)) {
- dev_info(&pf->pdev->dev, "MSIX not available, trying MSI\n");
+ dev_info(&pf->pdev->dev, "MSI-X not available, trying MSI\n");
err = pci_enable_msi(pf->pdev);
if (err) {
dev_info(&pf->pdev->dev, "MSI init failed - %d\n", err);
@@ -6063,7 +6063,7 @@ static void i40e_init_interrupt_scheme(struct i40e_pf *pf)
}
if (!(pf->flags & (I40E_FLAG_MSIX_ENABLED | I40E_FLAG_MSI_ENABLED)))
- dev_info(&pf->pdev->dev, "MSIX and MSI not available, falling back to Legacy IRQ\n");
+ dev_info(&pf->pdev->dev, "MSI-X and MSI not available, falling back to Legacy IRQ\n");
/* track first vector for misc interrupts */
err = i40e_get_lump(pf, pf->irq_pile, 1, I40E_PILE_VALID_BIT-1);
@@ -6090,7 +6090,8 @@ static int i40e_setup_misc_vector(struct i40e_pf *pf)
i40e_intr, 0, pf->misc_int_name, pf);
if (err) {
dev_info(&pf->pdev->dev,
- "request_irq for msix_misc failed: %d\n", err);
+ "request_irq for %s failed: %d\n",
+ pf->misc_int_name, err);
return -EFAULT;
}
}
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index c4185f0..1e0171c 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -524,7 +524,8 @@ static int i40evf_request_misc_irq(struct i40evf_adapter *adapter)
adapter->misc_vector_name, netdev);
if (err) {
dev_err(&adapter->pdev->dev,
- "request_irq for msix_aq failed: %d\n", err);
+ "request_irq for %s failed: %d\n",
+ adapter->misc_vector_name, err);
free_irq(adapter->msix_entries[0].vector, netdev);
}
return err;
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 07/14] i40evf: don't guess device name
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
We don't need to set an interface name here; the net core will do
that, and then it will get renamed by udev anyway.
Change-ID: I839a17837d19bedd1f490bff32ac5b85b4bfd97f
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 1bb9deb..40a5e78 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -2084,8 +2084,6 @@ static void i40evf_init_task(struct work_struct *work)
netif_carrier_off(netdev);
- strcpy(netdev->name, "eth%d");
-
adapter->vsi.id = adapter->vsi_res->vsi_id;
adapter->vsi.seid = adapter->vsi_res->vsi_id; /* dummy */
adapter->vsi.back = adapter;
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 06/14] i40evf: remove bogus comment
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
This comment is simply not true.
Change-ID: If006b02b60984601a24257a951ae873dff568008
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index db37ac4..1bb9deb 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -2048,7 +2048,6 @@ static void i40evf_init_task(struct work_struct *work)
NETIF_F_HW_VLAN_CTAG_FILTER;
}
- /* The HW MAC address was set and/or determined in sw_init */
if (!is_valid_ether_addr(adapter->hw.mac.addr)) {
dev_info(&pdev->dev, "Invalid MAC address %pMAC, using random\n",
adapter->hw.mac.addr);
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 04/14] i40evf: get rid of pci_using_dac
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
PCI DAC doesn't really mean much on a virtualized PCI Express part, so
get rid of that check and just always set the HIGHDMA flag in the net
device.
Change-ID: I2040272be0e7934323f470c2bc73fbdd4f93e2b6
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index e0eb27d..e9da5d5 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -2034,8 +2034,8 @@ static void i40evf_init_task(struct work_struct *work)
netdev->netdev_ops = &i40evf_netdev_ops;
i40evf_set_ethtool_ops(netdev);
netdev->watchdog_timeo = 5 * HZ;
-
- netdev->features |= NETIF_F_SG |
+ netdev->features |= NETIF_F_HIGHDMA |
+ NETIF_F_SG |
NETIF_F_IP_CSUM |
NETIF_F_SCTP_CSUM |
NETIF_F_IPV6_CSUM |
@@ -2180,20 +2180,18 @@ static int i40evf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
struct net_device *netdev;
struct i40evf_adapter *adapter = NULL;
struct i40e_hw *hw = NULL;
- int err, pci_using_dac;
+ int err;
err = pci_enable_device(pdev);
if (err)
return err;
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))) {
- pci_using_dac = true;
/* coherent mask for the same size will always succeed if
* dma_set_mask does
*/
dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
} else if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(32))) {
- pci_using_dac = false;
dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
} else {
dev_err(&pdev->dev, "%s: DMA configuration failed: %d\n",
@@ -2224,8 +2222,6 @@ static int i40evf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, netdev);
adapter = netdev_priv(netdev);
- if (pci_using_dac)
- netdev->features |= NETIF_F_HIGHDMA;
adapter->netdev = netdev;
adapter->pdev = pdev;
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 03/14] i40evf: fix multiple crashes on remove
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
Depending upon the state of the driver, there are several potential
pitfalls on remove. Kill the watchdog task so rmmod doesn't hang.
Check the adapter->msix_entries field, not the num_msix_vectors field,
which is never cleared.
Change-ID: I0546048477f09fc19e481bd37efa30daae4faa88
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 75a2c6f..e0eb27d 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -215,6 +215,9 @@ static void i40evf_irq_disable(struct i40evf_adapter *adapter)
int i;
struct i40e_hw *hw = &adapter->hw;
+ if (!adapter->msix_entries)
+ return;
+
for (i = 1; i < adapter->num_msix_vectors; i++) {
wr32(hw, I40E_VFINT_DYN_CTLN1(i - 1), 0);
synchronize_irq(adapter->msix_entries[i].vector);
@@ -2372,17 +2375,15 @@ static void i40evf_remove(struct pci_dev *pdev)
}
adapter->state = __I40EVF_REMOVE;
- if (adapter->num_msix_vectors) {
+ if (adapter->msix_entries) {
i40evf_misc_irq_disable(adapter);
- del_timer_sync(&adapter->watchdog_timer);
-
- flush_scheduled_work();
-
i40evf_free_misc_irq(adapter);
-
i40evf_reset_interrupt_capability(adapter);
}
+ del_timer_sync(&adapter->watchdog_timer);
+ flush_scheduled_work();
+
if (hw->aq.asq.count)
i40evf_shutdown_adminq(hw);
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 02/14] i40evf: remove VLAN filters on close
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
We remove all the MAC filters, so remove the VLAN filters, too.
Change-ID: I4f7559acdf005dc3f359bf6460ce32d183c8878b
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 1629b73..75a2c6f 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -972,9 +972,14 @@ void i40evf_down(struct i40evf_adapter *adapter)
list_for_each_entry(f, &adapter->mac_filter_list, list) {
f->remove = true;
}
+ /* remove all VLAN filters */
+ list_for_each_entry(f, &adapter->vlan_filter_list, list) {
+ f->remove = true;
+ }
if (!(adapter->flags & I40EVF_FLAG_PF_COMMS_FAILED) &&
adapter->state != __I40EVF_RESETTING) {
adapter->aq_required |= I40EVF_FLAG_AQ_DEL_MAC_FILTER;
+ adapter->aq_required |= I40EVF_FLAG_AQ_DEL_VLAN_FILTER;
/* disable receives */
adapter->aq_required |= I40EVF_FLAG_AQ_DISABLE_QUEUES;
mod_timer_pending(&adapter->watchdog_timer, jiffies + 1);
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 05/14] i40evf: fix up strings in init task
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
Make sure errors are reported at the correct log level, quit printing
the function name every time, and make the messages more consistent in
format.
v2: Removed unnecessary periods and redundant OOM message.
Change-ID: I50e443467519ad3850def131d84626c50612c611
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 36 +++++++++++--------------
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index e9da5d5..db37ac4 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -1939,14 +1939,14 @@ static void i40evf_init_task(struct work_struct *work)
adapter->flags &= ~I40EVF_FLAG_RESET_PENDING;
err = i40e_set_mac_type(hw);
if (err) {
- dev_info(&pdev->dev, "%s: set_mac_type failed: %d\n",
- __func__, err);
+ dev_err(&pdev->dev, "Failed to set MAC type (%d)\n",
+ err);
goto err;
}
err = i40evf_check_reset_complete(hw);
if (err) {
- dev_info(&pdev->dev, "%s: device is still in reset (%d).\n",
- __func__, err);
+ dev_err(&pdev->dev, "Device is still in reset (%d)\n",
+ err);
goto err;
}
hw->aq.num_arq_entries = I40EVF_AQ_LEN;
@@ -1956,14 +1956,14 @@ static void i40evf_init_task(struct work_struct *work)
err = i40evf_init_adminq(hw);
if (err) {
- dev_info(&pdev->dev, "%s: init_adminq failed: %d\n",
- __func__, err);
+ dev_err(&pdev->dev, "Failed to init Admin Queue (%d)\n",
+ err);
goto err;
}
err = i40evf_send_api_ver(adapter);
if (err) {
- dev_info(&pdev->dev, "%s: unable to send to PF (%d)\n",
- __func__, err);
+ dev_err(&pdev->dev, "Unable to send to PF (%d)\n",
+ err);
i40evf_shutdown_adminq(hw);
goto err;
}
@@ -1977,13 +1977,13 @@ static void i40evf_init_task(struct work_struct *work)
/* aq msg sent, awaiting reply */
err = i40evf_verify_api_ver(adapter);
if (err) {
- dev_err(&pdev->dev, "Unable to verify API version, error %d\n",
+ dev_err(&pdev->dev, "Unable to verify API version (%d)\n",
err);
goto err;
}
err = i40evf_send_vf_config_msg(adapter);
if (err) {
- dev_err(&pdev->dev, "Unable send config request, error %d\n",
+ dev_err(&pdev->dev, "Unable send config request (%d)\n",
err);
goto err;
}
@@ -1997,18 +1997,15 @@ static void i40evf_init_task(struct work_struct *work)
(I40E_MAX_VF_VSI *
sizeof(struct i40e_virtchnl_vsi_resource));
adapter->vf_res = kzalloc(bufsz, GFP_KERNEL);
- if (!adapter->vf_res) {
- dev_err(&pdev->dev, "%s: unable to allocate memory\n",
- __func__);
+ if (!adapter->vf_res)
goto err;
- }
}
err = i40evf_get_vf_config(adapter);
if (err == I40E_ERR_ADMIN_QUEUE_NO_WORK)
goto restart;
if (err) {
- dev_info(&pdev->dev, "%s: unable to get VF config (%d)\n",
- __func__, err);
+ dev_err(&pdev->dev, "Unable to get VF config (%d)\n",
+ err);
goto err_alloc;
}
adapter->state = __I40EVF_INIT_SW;
@@ -2022,7 +2019,7 @@ static void i40evf_init_task(struct work_struct *work)
adapter->vsi_res = &adapter->vf_res->vsi_res[i];
}
if (!adapter->vsi_res) {
- dev_info(&pdev->dev, "%s: no LAN VSI found\n", __func__);
+ dev_err(&pdev->dev, "No LAN VSI found\n");
goto err_alloc;
}
@@ -2053,9 +2050,8 @@ static void i40evf_init_task(struct work_struct *work)
/* The HW MAC address was set and/or determined in sw_init */
if (!is_valid_ether_addr(adapter->hw.mac.addr)) {
- dev_info(&pdev->dev,
- "Invalid MAC address %pMAC, using random\n",
- adapter->hw.mac.addr);
+ dev_info(&pdev->dev, "Invalid MAC address %pMAC, using random\n",
+ adapter->hw.mac.addr);
random_ether_addr(adapter->hw.mac.addr);
}
memcpy(netdev->dev_addr, adapter->hw.mac.addr, netdev->addr_len);
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 01/14] i40evf: request reset on tx hang
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem
Cc: Mitch Williams, netdev, gospo, sassmann, Jesse Brandeburg,
Aaron Brown
In-Reply-To: <1392953358-23908-1-git-send-email-aaron.f.brown@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
If the kernel watchdog bites us, ask the PF to reset us and attempt to
reinit the driver.
Change-ID: Ic97665aeeed71ce712b9c4f057e78ff8372522b9
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf.h | 1 +
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 10 +++++++---
drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c | 12 ++++++++++++
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf.h b/drivers/net/ethernet/intel/i40evf/i40evf.h
index ef7ce65..c9a5056 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf.h
+++ b/drivers/net/ethernet/intel/i40evf/i40evf.h
@@ -287,6 +287,7 @@ void i40evf_add_vlans(struct i40evf_adapter *adapter);
void i40evf_del_vlans(struct i40evf_adapter *adapter);
void i40evf_set_promiscuous(struct i40evf_adapter *adapter, int flags);
void i40evf_request_stats(struct i40evf_adapter *adapter);
+void i40evf_request_reset(struct i40evf_adapter *adapter);
void i40evf_virtchnl_completion(struct i40evf_adapter *adapter,
enum i40e_virtchnl_ops v_opcode,
i40e_status v_retval, u8 *msg, u16 msglen);
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index fe2271e..1629b73 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -167,9 +167,13 @@ static void i40evf_tx_timeout(struct net_device *netdev)
struct i40evf_adapter *adapter = netdev_priv(netdev);
adapter->tx_timeout_count++;
-
- /* Do the reset outside of interrupt context */
- schedule_work(&adapter->reset_task);
+ dev_info(&adapter->pdev->dev, "TX timeout detected.\n");
+ if (!(adapter->flags & I40EVF_FLAG_RESET_PENDING)) {
+ dev_info(&adapter->pdev->dev, "Requesting reset from PF\n");
+ i40evf_request_reset(adapter);
+ adapter->flags |= I40EVF_FLAG_RESET_PENDING;
+ schedule_work(&adapter->reset_task);
+ }
}
/**
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c b/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c
index 93891a1..e294f01 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c
@@ -654,6 +654,18 @@ void i40evf_request_stats(struct i40evf_adapter *adapter)
/* if the request failed, don't lock out others */
adapter->current_op = I40E_VIRTCHNL_OP_UNKNOWN;
}
+/**
+ * i40evf_request_reset
+ * @adapter: adapter structure
+ *
+ * Request that the PF reset this VF. No response is expected.
+ **/
+void i40evf_request_reset(struct i40evf_adapter *adapter)
+{
+ /* Don't check CURRENT_OP - this is always higher priority */
+ i40evf_send_pf_msg(adapter, I40E_VIRTCHNL_OP_RESET_VF, NULL, 0);
+ adapter->current_op = I40E_VIRTCHNL_OP_UNKNOWN;
+}
/**
* i40evf_virtchnl_completion
--
1.8.5.GIT
^ permalink raw reply related
* [net-next v2 00/14] Intel Wired LAN Driver Updates
From: Aaron Brown @ 2014-02-21 3:29 UTC (permalink / raw)
To: davem; +Cc: Aaron Brown, netdev, gospo, sassmann
This series contains updates to i40e and (mostly to) i40evf.
Mitch provides most the work for this series. For the vf driver he
requests a reset on a tx hang, removes vlan filtes on close since we
already remove the MAC filters, fixes some crashes, gets rid of PCI DAC
as it does not mean much on virtualized PCIe parts, skips assigning the
device name that just gets renamed anyway, stores the descriptor ring
size in a manner that allows the use of common tx and rx code with the
PF driver and makes a handful of cosmetic fixes. For i40e he removes
a delay left over from debugging and changes a do/while loop to a for
loop to avoid hitting another delay each time.
Catherine fixes inconsistent MSI and MSI-X messages and bumps the
driver version.
v2: Removed unnecessary periods and redundant OOM message.
Mitch Williams (12):
i40evf: request reset on tx hang
i40evf: remove VLAN filters on close
i40evf: fix multiple crashes on remove
i40evf: get rid of pci_using_dac
i40evf: fix up strings in init task
i40evf: remove bogus comment
i40evf: don't guess device name
i40evf: store ring size in ring structs
i40evf: update version and copyright date
i40evf: remove errant space
i40e: remove unnecessary delay
i40e: tighten up ring enable/disable flow
Catherine Sullivan (2):
i40e: Change MSIX to MSI-X
i40e and i40evf: Bump driver versions
drivers/net/ethernet/intel/i40e/i40e_main.c | 43 ++++++-----
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 1 -
.../net/ethernet/intel/i40evf/i40e_adminq_cmd.h | 2 +-
drivers/net/ethernet/intel/i40evf/i40evf.h | 3 +-
drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 13 ++--
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 87 +++++++++++-----------
.../net/ethernet/intel/i40evf/i40evf_virtchnl.c | 12 +++
7 files changed, 85 insertions(+), 76 deletions(-)
--
1.8.5.GIT
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2014-02-21 2:49 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Nicolas Dichtel, WANG Cong
[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/ipv6/sit.c between commit cf71d2bc0b8a ("sit: fix panic with route
cache in ip tunnels") from the tree and commit 1c213bd24ad0 ("net:
introduce netdev_alloc_pcpu_stats() for drivers") from the net-next tree.
I fixed it up (I think ... see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/ipv6/sit.c
index b4d74c86586c,958027be0e94..000000000000
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@@ -1376,18 -1368,6 +1375,12 @@@ static int ipip6_tunnel_init(struct net
if (!dev->tstats)
return -ENOMEM;
- for_each_possible_cpu(i) {
- struct pcpu_sw_netstats *ipip6_tunnel_stats;
- ipip6_tunnel_stats = per_cpu_ptr(dev->tstats, i);
- u64_stats_init(&ipip6_tunnel_stats->syncp);
- }
-
+ tunnel->dst_cache = alloc_percpu(struct ip_tunnel_dst);
+ if (!tunnel->dst_cache) {
+ free_percpu(dev->tstats);
+ return -ENOMEM;
+ }
+
return 0;
}
@@@ -1412,18 -1391,6 +1404,12 @@@ static int __net_init ipip6_fb_tunnel_i
if (!dev->tstats)
return -ENOMEM;
- for_each_possible_cpu(i) {
- struct pcpu_sw_netstats *ipip6_fb_stats;
- ipip6_fb_stats = per_cpu_ptr(dev->tstats, i);
- u64_stats_init(&ipip6_fb_stats->syncp);
- }
-
+ tunnel->dst_cache = alloc_percpu(struct ip_tunnel_dst);
+ if (!tunnel->dst_cache) {
+ free_percpu(dev->tstats);
+ return -ENOMEM;
+ }
+
dev_hold(dev);
rcu_assign_pointer(sitn->tunnels_wc[0], tunnel);
return 0;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the wireless tree
From: Stephen Rothwell @ 2014-02-21 2:34 UTC (permalink / raw)
To: David Miller, netdev, John W. Linville
Cc: linux-next, linux-kernel, Amitkumar Karwar, Aaron Durbin
[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/wireless/mwifiex/pcie.c between commit bb8e6a1ee881
("mwifiex: add NULL check for PCIe Rx skb") from the tree and commit
dbccc92b5d54 ("mwifiex: balance dma map/unmap sizes") from the net-next
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/mwifiex/pcie.c
index 7fe7b53fb17a,d11d4acf0890..000000000000
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@@ -1211,15 -1217,7 +1217,13 @@@ static int mwifiex_pcie_process_recv_da
rd_index = card->rxbd_rdptr & reg->rx_mask;
skb_data = card->rx_buf_list[rd_index];
+ /* If skb allocation was failed earlier for Rx packet,
+ * rx_buf_list[rd_index] would have been left with a NULL.
+ */
+ if (!skb_data)
+ return -ENOMEM;
+
- MWIFIEX_SKB_PACB(skb_data, &buf_pa);
- pci_unmap_single(card->dev, buf_pa, MWIFIEX_RX_DATA_BUF_SIZE,
- PCI_DMA_FROMDEVICE);
+ mwifiex_unmap_pci_memory(adapter, skb_data, PCI_DMA_FROMDEVICE);
card->rx_buf_list[rd_index] = NULL;
/* Get data length from interface header -
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH net] ipv6: reuse ip6_frag_id from ip6_ufo_append_data
From: Hannes Frederic Sowa @ 2014-02-21 1:55 UTC (permalink / raw)
To: netdev
Currently we generate a new fragmentation id on UFO segmentation. It
is pretty hairy to identify the correct net namespace and dst there.
Especially tunnels use IFF_XMIT_DST_RELEASE and thus have no skb_dst
available at all.
This causes unreliable or very predictable ipv6 fragmentation id
generation while segmentation.
Luckily we already have pregenerated the ip6_frag_id in
ip6_ufo_append_data and can use it here.
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/udp_offload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index e7359f9..b261ee8 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -113,7 +113,7 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
fptr = (struct frag_hdr *)(skb_network_header(skb) + unfrag_ip6hlen);
fptr->nexthdr = nexthdr;
fptr->reserved = 0;
- ipv6_select_ident(fptr, (struct rt6_info *)skb_dst(skb));
+ fptr->identification = skb_shinfo(skb)->ip6_frag_id;
/* Fragment the skb. ipv6 header and the remaining fields of the
* fragment header are updated in ipv6_gso_segment()
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
From: Chen-Yu Tsai @ 2014-02-21 1:55 UTC (permalink / raw)
To: Stephen Warren
Cc: Heikki Krogerus, Johannes Berg, David S. Miller, Rhyland Klein,
linux-wireless, netdev, linux-kernel, Arnd Bergmann,
Linus Walleij, Alexandre Courbot
In-Reply-To: <53062F97.3050407@wwwdotorg.org>
Hi,
On Fri, Feb 21, 2014 at 12:38 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 02/20/2014 05:51 AM, Heikki Krogerus wrote:
>> There is no use for them in this driver. This will fix a
>> static checker warning..
>
> Didn't you remove the use:
>
> - gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0);
> + gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0);
>
> doesn't that parameter get put into the sysfs GPIO debug file, so people
> can see which GPIOs are used for what?
That's correct. However using con_id to pass this results in different
behavior across DT and ACPI. A better way is to export the labeling
function so consumers can set meaningful labels themselves.
Cheers
ChenYu
^ permalink raw reply
* Re: linux 3.13: problems with isatap tunnel device and UFO
From: Hannes Frederic Sowa @ 2014-02-21 1:19 UTC (permalink / raw)
To: Cong Wang; +Cc: Wolfgang Walter, Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <CAM_iQpW0ai2NMyVV1FGpDn5qKDUxYoqsXZ-GutfccQp92SyKwQ@mail.gmail.com>
On Thu, Feb 20, 2014 at 04:43:41PM -0800, Cong Wang wrote:
> On Wed, Feb 19, 2014 at 6:44 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Mon, Feb 17, 2014 at 05:09:16PM +0100, Hannes Frederic Sowa wrote:
> >> [+Cc Cong Wang]
> >>
> >> Hi Cong!
> >>
> >> In commit d949d826c09fb ("ipv6: Add generic UDP Tunnel segmentation") you
> >> patched ip6_offload.c:
> >>
> >> @@ -126,7 +128,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
> >> ipv6h = ipv6_hdr(skb);
> >> ipv6h->payload_len = htons(skb->len - skb->mac_len -
> >> sizeof(*ipv6h));
> >> - if (proto == IPPROTO_UDP) {
> >> + if (!tunnel && proto == IPPROTO_UDP) {
> >> unfrag_ip6hlen = ip6_find_1stfragopt(skb, &prevhdr);
> >> fptr = (struct frag_hdr *)(skb_network_header(skb) +
> >> unfrag_ip6hlen);
> >>
> >>
> >> I wonder about the !tunnel exception. This now seems to be a problem in sit
> >> ufo output path, where we don't update fragmentation offsets any more thus
> >> generating invalid frames.
> >>
> >> I am not too firm with segmentation in case of tunnels but don't we need to
> >> always update the fragmentation offset no matter what, if upper gso callback
> >> produced more segments?
> >
> > Not perfect nor clean (well, I don't know).
> >
> > The idea is to have the segmentation at the first guessed tunnel
> > header cut. I don't know how to deal with stacked tunnels yet, I guess
> > we need to have a bit more state in the skb. Just to maybe keep the discussion
> > going...
>
> Does the following patch help?
> diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
> index 1e8683b..516b889 100644
> --- a/net/ipv6/ip6_offload.c
> +++ b/net/ipv6/ip6_offload.c
> @@ -89,7 +89,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
> unsigned int unfrag_ip6hlen;
> u8 *prevhdr;
> int offset = 0;
> - bool tunnel;
> + bool udpfrag, encap;
> int nhoff;
>
> if (unlikely(skb_shinfo(skb)->gso_type &
> @@ -110,8 +110,8 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
> if (unlikely(!pskb_may_pull(skb, sizeof(*ipv6h))))
> goto out;
>
> - tunnel = SKB_GSO_CB(skb)->encap_level > 0;
> - if (tunnel)
> + encap = SKB_GSO_CB(skb)->encap_level > 0;
> + if (encap)
> features = skb->dev->hw_enc_features & netif_skb_features(skb);
> SKB_GSO_CB(skb)->encap_level += sizeof(*ipv6h);
>
> @@ -130,16 +130,17 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
> if (IS_ERR(segs))
> goto out;
>
> + udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP;
The problem in general is that skb->encapsulation does not get reset as in GRE
or UDP_TUNNEL gso handler when traversing up the gso stack (e.g. from
another ipv6_gso_segment or inet_gso_segment.
skb->encapsulation is unreliable here.
Btw. IPv4 has the same problem and does not update fragment offsets,
so we cannot adapt the code from there.
Either we track inner_network_protocol in SKB_GSO_CB or try my proposal.
> for (skb = segs; skb; skb = skb->next) {
> ipv6h = (struct ipv6hdr *)(skb_mac_header(skb) + nhoff);
> ipv6h->payload_len = htons(skb->len - nhoff - sizeof(*ipv6h));
> - if (tunnel) {
> + if (encap) {
> skb_reset_inner_headers(skb);
> skb->encapsulation = 1;
> }
> skb->network_header = (u8 *)ipv6h - skb->head;
>
> - if (!tunnel && proto == IPPROTO_UDP) {
> + if (udpfrag) {
> unfrag_ip6hlen = ip6_find_1stfragopt(skb, &prevhdr);
> fptr = (struct frag_hdr *)((u8 *)ipv6h + unfrag_ip6hlen);
> fptr->frag_off = htons(offset);
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v5 1/9] xen-netback: Introduce TX grant map definitions
From: Zoltan Kiss @ 2014-02-21 1:19 UTC (permalink / raw)
To: Ian Campbell; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <1392888808.22494.21.camel@kazak.uk.xensource.com>
On 20/02/14 09:33, Ian Campbell wrote:
> On Wed, 2014-02-19 at 19:54 +0000, Zoltan Kiss wrote:
>> On 19/02/14 10:05, Ian Campbell wrote:
>>> On Tue, 2014-02-18 at 20:36 +0000, Zoltan Kiss wrote:
>>>> On 18/02/14 17:06, Ian Campbell wrote:
>>>>> On Mon, 2014-01-20 at 21:24 +0000, Zoltan Kiss wrote:
>>>>>> This patch contains the new definitions necessary for grant mapping.
>>>>> Is this just adding a bunch of (currently) unused functions? That's a
>>>>> slightly odd way to structure a series. They don't seem to be "generic
>>>>> helpers" or anything so it would be more normal to introduce these as
>>>>> they get used -- it's a bit hard to review them out of context.
>>>> I've created two patches because they are quite huge even now,
>>>> separately. Together they would be a ~500 line change. That was the best
>>>> I could figure out keeping in mind that bisect should work. But as I
>>>> wrote in the first email, I welcome other suggestions. If you and Wei
>>>> prefer this two patch in one big one, I merge them in the next version.
>>> I suppose it is hard to split a change like this up in a sensible way,
>>> but it is rather hard to review something which is split in two parts
>>> sensibly.
>>>
>>> If the combined patch too large to fit on the lists?
>> Well, it's ca. 30 kb, ~500 lines changed. I guess it's possible. It's up
>> to you and Wei, if you would like them to be merged, I can do that.
> 30kb doesn't sound too bad to me.
>
> Patches #1 and #2 are, respectively:
>
> drivers/net/xen-netback/common.h | 30 ++++++-
> drivers/net/xen-netback/interface.c | 1 +
> drivers/net/xen-netback/netback.c | 161 +++++++++++++++++++++++++++++++++++
> 3 files changed, 191 insertions(+), 1 deletion(-)
>
> drivers/net/xen-netback/interface.c | 63 ++++++++-
> drivers/net/xen-netback/netback.c | 254 ++++++++++++++---------------------
> 2 files changed, 160 insertions(+), 157 deletions(-)
>
> I don't think combining those would be terrible, although I'm willing to
> be proven wrong ;-)
Ok, if noone comes up with any better argument before I send in the next
version, I'll merge the 2 patches.
>
>>>>>> + vif->dealloc_prod++;
>>>>> What happens if the dealloc ring becomes full, will this wrap and cause
>>>>> havoc?
>>>> Nope, if the dealloc ring is full, the value of the last increment won't
>>>> be used to index the dealloc ring again until some space made available.
>>> I don't follow -- what makes this the case?
>> The dealloc ring has the same size as the pending ring, and you can only
>> add slots to it which are already on the pending ring (the pending_idx
>> comes from ubuf->desc), as you are essentially free up slots here on the
>> pending ring.
>> So if the dealloc ring becomes full, vif->dealloc_prod -
>> vif->dealloc_cons will be 256, which would be bad. But the while loop
>> should exit here, as we shouldn't have any more pending slots. And if we
>> dealloc and create free pending slots in dealloc_action, dealloc_cons
>> will also advance.
> OK, so this is limited by the size of the pending array, makes sense,
> assuming that array is itself correctly guarded...
Well, that pending ring works the same as before, the only difference
that now the slots are released from dealloc thread as well, not just
from from NAPI instance. That's why we need response_lock. I'll make a
comment on that.
>>>>>> + }
>>>>>> +
>>>>>> + } while (dp != vif->dealloc_prod);
>>>>>> +
>>>>>> + vif->dealloc_cons = dc;
>>>>> No barrier here?
>>>> dealloc_cons only used in the dealloc_thread. dealloc_prod is used by
>>>> the callback and the thread as well, that's why we need mb() in
>>>> previous. Btw. this function comes from classic's net_tx_action_dealloc
>>> Is this code close enough to that code architecturally that you can
>>> infer correctness due to that though?
>> Nope, I've just mentioned it because knowing that old code can help to
>> understand this new, as their logic is very similar some places, like here.
>>
>>> So long as you have considered the barrier semantics in the context of
>>> the current code and you think it is correct to not have one here then
>>> I'm ok. But if you have just assumed it is OK because some older code
>>> didn't have it then I'll have to ask you to consider it again...
>> Nope, as I mentioned above, dealloc_cons only accessed in that funcion,
>> from the same thread. Dealloc_prod is written in the callback and read
>> out here, that's why we need the barrier there.
> OK.
>
> Although this may no longer be true if you added some BUG_ONs as
> discussed above?
Yep, that BUG_ON might see a smaller value of dealloc_cons, but that
should be OK. We will release those slots after grant unmapping, they
shouldn't be filled up again until then.
>
>>>>>> + netdev_err(vif->dev,
>>>>>> + " host_addr: %llx handle: %x status: %d\n",
>>>>>> + gop[i].host_addr,
>>>>>> + gop[i].handle,
>>>>>> + gop[i].status);
>>>>>> + }
>>>>>> + BUG();
>>>>>> + }
>>>>>> + }
>>>>>> +
>>>>>> + for (i = 0; i < gop - vif->tx_unmap_ops; ++i)
>>>>>> + xenvif_idx_release(vif, pending_idx_release[i],
>>>>>> + XEN_NETIF_RSP_OKAY);
>>>>>> +}
>>>>>> +
>>>>>> +
>>>>>> /* Called after netfront has transmitted */
>>>>>> int xenvif_tx_action(struct xenvif *vif, int budget)
>>>>>> {
>>>>>> @@ -1678,6 +1793,25 @@ static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx,
>>>>>> vif->mmap_pages[pending_idx] = NULL;
>>>>>> }
>>>>>>
>>>>>> +void xenvif_idx_unmap(struct xenvif *vif, u16 pending_idx)
>>>>> This is a single shot version of the batched xenvif_tx_dealloc_action
>>>>> version? Why not just enqueue the idx to be unmapped later?
>>>> This is called only from the NAPI instance. Using the dealloc ring
>>>> require synchronization with the callback which can increase lock
>>>> contention. On the other hand, if the guest sends small packets
>>>> (<PAGE_SIZE), the TLB flushing can cause performance penalty.
>>> Right. When/How often is this called from the NAPI instance?
>> When grant mapping error detected in xenvif_tx_check_gop, and if a
>> packet smaller than PKT_PROT_LEN is sent. The latter would be removed if
>> we will grant copy such packets entirely.
>>
>>> Is the locking contention from this case so severe that it out weighs
>>> the benefits of batching the unmaps? That would surprise me. After all
>>> the locking contention is there for the zerocopy_callback case too
>>>
>>>> The above
>>>> mentioned upcoming patch which gntcopy the header can prevent that
>>> So this is only called when doing the pull-up to the linear area?
>> Yes, as mentioned above.
> I'm not sure why you don't just enqueue the dealloc with the other
> normal ones though.
Well, I started off from this approach, as it maintains similarity with
the grant copy ways of doing this. Historically we release the slots in
xenvif_tx_check_gop straight away if there is a mapping error in any of
them. I don't know if the guest expects that slots for the same packet
comes back at the same time. Then I just reused the same function for
<PKT_PROT_LEN packets instead of writing an another one. That will go
away soon anyway.
Zoli
^ permalink raw reply
* Re: linux 3.13: problems with isatap tunnel device and UFO
From: Cong Wang @ 2014-02-21 0:43 UTC (permalink / raw)
To: Wolfgang Walter, Linux Kernel Network Developers, Cong Wang,
Eric Dumazet
In-Reply-To: <20140220024418.GG1179@order.stressinduktion.org>
[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]
On Wed, Feb 19, 2014 at 6:44 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Mon, Feb 17, 2014 at 05:09:16PM +0100, Hannes Frederic Sowa wrote:
>> [+Cc Cong Wang]
>>
>> Hi Cong!
>>
>> In commit d949d826c09fb ("ipv6: Add generic UDP Tunnel segmentation") you
>> patched ip6_offload.c:
>>
>> @@ -126,7 +128,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
>> ipv6h = ipv6_hdr(skb);
>> ipv6h->payload_len = htons(skb->len - skb->mac_len -
>> sizeof(*ipv6h));
>> - if (proto == IPPROTO_UDP) {
>> + if (!tunnel && proto == IPPROTO_UDP) {
>> unfrag_ip6hlen = ip6_find_1stfragopt(skb, &prevhdr);
>> fptr = (struct frag_hdr *)(skb_network_header(skb) +
>> unfrag_ip6hlen);
>>
>>
>> I wonder about the !tunnel exception. This now seems to be a problem in sit
>> ufo output path, where we don't update fragmentation offsets any more thus
>> generating invalid frames.
>>
>> I am not too firm with segmentation in case of tunnels but don't we need to
>> always update the fragmentation offset no matter what, if upper gso callback
>> produced more segments?
>
> Not perfect nor clean (well, I don't know).
>
> The idea is to have the segmentation at the first guessed tunnel
> header cut. I don't know how to deal with stacked tunnels yet, I guess
> we need to have a bit more state in the skb. Just to maybe keep the discussion
> going...
Does the following patch help?
[-- Attachment #2: tmp.diff --]
[-- Type: text/plain, Size: 1484 bytes --]
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 1e8683b..516b889 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -89,7 +89,7 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
unsigned int unfrag_ip6hlen;
u8 *prevhdr;
int offset = 0;
- bool tunnel;
+ bool udpfrag, encap;
int nhoff;
if (unlikely(skb_shinfo(skb)->gso_type &
@@ -110,8 +110,8 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
if (unlikely(!pskb_may_pull(skb, sizeof(*ipv6h))))
goto out;
- tunnel = SKB_GSO_CB(skb)->encap_level > 0;
- if (tunnel)
+ encap = SKB_GSO_CB(skb)->encap_level > 0;
+ if (encap)
features = skb->dev->hw_enc_features & netif_skb_features(skb);
SKB_GSO_CB(skb)->encap_level += sizeof(*ipv6h);
@@ -130,16 +130,17 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
if (IS_ERR(segs))
goto out;
+ udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP;
for (skb = segs; skb; skb = skb->next) {
ipv6h = (struct ipv6hdr *)(skb_mac_header(skb) + nhoff);
ipv6h->payload_len = htons(skb->len - nhoff - sizeof(*ipv6h));
- if (tunnel) {
+ if (encap) {
skb_reset_inner_headers(skb);
skb->encapsulation = 1;
}
skb->network_header = (u8 *)ipv6h - skb->head;
- if (!tunnel && proto == IPPROTO_UDP) {
+ if (udpfrag) {
unfrag_ip6hlen = ip6_find_1stfragopt(skb, &prevhdr);
fptr = (struct frag_hdr *)((u8 *)ipv6h + unfrag_ip6hlen);
fptr->frag_off = htons(offset);
^ permalink raw reply related
* Re: [PATCH v5] can: add Renesas R-Car CAN driver
From: Sergei Shtylyov @ 2014-02-20 23:48 UTC (permalink / raw)
To: Marc Kleine-Budde, netdev, wg, linux-can; +Cc: linux-sh, vksavl
In-Reply-To: <52FCB6C5.6020001@pengutronix.de>
Hello.
On 02/13/2014 03:12 PM, Marc Kleine-Budde wrote:
>>>> Add support for the CAN controller found in Renesas R-Car SoCs.
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>> ---
>>>> The patch is against the 'linux-can-next.git' repo.
>> [...]
>>>> Index: linux-can-next/drivers/net/can/rcar_can.c
>>>> ===================================================================
>>>> --- /dev/null
>>>> +++ linux-can-next/drivers/net/can/rcar_can.c
>>>> @@ -0,0 +1,857 @@
>> [...]
>>>> +/* Mailbox registers structure */
>>>> +struct rcar_can_mbox_regs {
>>>> + u32 id; /* IDE and RTR bits, SID and EID */
>>>> + u8 stub; /* Not used */
>>>> + u8 dlc; /* Data Length Code - bits [0..3] */
>>>> + u8 data[8]; /* Data Bytes */
>>>> + u8 tsh; /* Time Stamp Higher Byte */
>>>> + u8 tsl; /* Time Stamp Lower Byte */
>>>> +} __packed;
>>> If you have contact to the hardware designer please blame him for
>> Unfortunately, we don't.
>>> placing the data register unaligned into the register space. :)
>> It's not even the only one or worst example of questionable register
>> design in this module IMO.
Moreover, there are certainly strange issues with the host bus.
>> [...]
>>>> +static void rcar_can_tx_done(struct net_device *ndev)
>>>> +{
>>>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>>>> + struct net_device_stats *stats = &ndev->stats;
>>>> + int i;
>>>> +
>>>> + spin_lock(&priv->skb_lock);
>>>> + for (i = 0; i < priv->frames_queued; i++)
>>>> + can_get_echo_skb(ndev, i);
>>>> + stats->tx_bytes += priv->bytes_queued;
>>>> + stats->tx_packets += priv->frames_queued;
>>>> + priv->bytes_queued = 0;
>>>> + priv->frames_queued = 0;
>>>> + spin_unlock(&priv->skb_lock);
>>> This looks broken. What happens if you send 2 CAN frames in a row, the
>>> first one is send, a TX complete interrupt is issued and you handle it
>>> here? You assume, that all CAN frames have been sent.
>> TX interrupt will be issued only when TX FIFO gets empty (all 2 frames
>> have been transmitted in this case). Please see the comment to the
>> RCAR_CAN_MIER1_TXFIT bit.
> Does the hardware have a TX complete interrupt?
Yes, there's a mode where TX interrupt signals send completion. I rewrote
the driver to make use of this mode now.
> If you only have TX FIFO
> empty, you have to limit the FIFO depth to 1.
Not quite clear why...
[...]
>>>> +static void rcar_can_set_bittiming(struct net_device *dev)
>>>> +{
>>>> + struct rcar_can_priv *priv = netdev_priv(dev);
>>>> + struct can_bittiming *bt = &priv->can.bittiming;
>>>> + u32 bcr;
>>>> + u8 clkr;
>>>> +
>>>> + /* Don't overwrite CLKR with 32-bit BCR access */
>>>> + /* CLKR has 8-bit access */
>>> Can you explain the register layout here? Why do you access BCR with 32
>>> bits when the register is defined as 3x8 bit? Can't you make it a
>>> standard 32 bit register?
>> 1. According to documentation BCR is the 24-bit register.
>> Actually we can consider some 32-bit register that combines BCR and
>> CLKR but according to documentation there are two separate registers.
>> 2. BCR has 8- ,16-, and 32-bit access (according to documentation).
>> 3. This is the algorithm that the documentation suggests.
>> 4. We had a driver version with byte access but 32-bit access seems
>> shorter.
> Please use a normal read-modify-write 32 bit access.
IMO, reading 32-bits is futile, as we're going to completely overwrite
those 24 bits that constitute BCR. So I kept the 8-bit CLKR read but removed
the CLKR write in the end. I've also added a comment clarifying why CLKR is
positioned in the LSBs of 32-bit word (while it's address would assume MSBs).
The host bus is big-endian but byte-swaps at least 16- and 32-bit accesses, so
that read[wl]()/write[wl]() work. 8-bit accesses are not byte swapped, despite
what the figure in the manual shows.
> Marc
WBR, Sergei
^ permalink raw reply
* Re: pull request: wireless-next 2014-02-20
From: Larry Finger @ 2014-02-20 23:22 UTC (permalink / raw)
To: David Miller, linville; +Cc: linux-wireless, netdev
In-Reply-To: <20140220.172922.864207706999214682.davem@davemloft.net>
On 02/20/2014 04:29 PM, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Thu, 20 Feb 2014 15:30:05 -0500
>
>> Please pull this batch of wireless updates intended for the 3.15
>> stream!
>>
>> For the mac80211 bits, Johannes says:
>>
>> "We have some cleanups and minor fixes as well as userspace API
>> improvements from a lot of people, extended VHT support for radiotap
>> from Emmanuel, CSA improvements from Andrei, Luca and Michal. I've also
>> included my work on hwsim to make dynamic registration of radios
>> possible."
>>
>> Along with that, we get the usual round of updates to ath9k,
>> brcmfmac, mwifiex, wcn36xx, and the ti drivers -- nothing particularly
>> noteworthy, mostly just random updates and refactoring.
>>
>> Also included is a pull of the wireless tree, intended to resolve
>> some potential merge issues.
>>
>> Please let me know if there are problems!
>
> Pulled, but please address this:
>
> drivers/staging/rtl8821ae/rtl8821ae/trx.c: In function ‘rtl8821ae_rx_query_desc’:
> drivers/staging/rtl8821ae/rtl8821ae/trx.c:619:3: warning: passing argument 1 of ‘ieee80211_is_robust_mgmt_frame’ from incompatible pointer type [enabled by default]
>
> I was going to do the easy transformation to the "_" prefixed variant
> but noticed that this code doesn't validate the skb length, which is
> precisely the reason why this routine now takes an skb.
David,
That staging driver is expected to be deleted in a commit to be submitted in
about one week. The new one will be in the regular wireless tree. The staging
version was submitted so that there would be a driver in 3.14.
I was surprised to see this patch in John's list. It should have gone through
GregKH. In fact, has has been suppressing all cleanups because the better one
will be available soon.
I suggest that you drop this one now. I will, however, check the new source to
make sure that the skb length is checked.
Thanks,
Larry
^ permalink raw reply
* Re: [net-next 1/3] net: bcmgenet: drop checks on priv->phydev
From: Sergei Shtylyov @ 2014-02-20 23:54 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: davem
In-Reply-To: <1392929631-7685-2-git-send-email-f.fainelli@gmail.com>
Hello.
On 02/20/2014 11:53 PM, Florian Fainelli wrote:
> 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 where smatch would complain that a pointer is not always
> checked correctly.
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index 0ebc297..8af5f07 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
[...]
> @@ -1811,8 +1810,7 @@ static void bcmgenet_irq_task(struct work_struct *work)
> /* Link UP/DOWN event */
> if ((priv->hw_params->flags & GENET_HAS_MDIO_INTR) &&
> (priv->irq0_stat & (UMAC_IRQ_LINK_UP|UMAC_IRQ_LINK_DOWN))) {
> - if (priv->phydev)
> - phy_mac_interrupt(priv->phydev,
> + phy_mac_interrupt(priv->phydev,
> (priv->irq0_stat & UMAC_IRQ_LINK_UP));
Should probably realign this line (although it wasn't correctly aligned
before). Also () are not needed around &.
WBR, Sergei
^ 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