* [PATCH 06/11] vxge: add receive hardware timestamping
From: Jon Mason @ 2010-10-29 2:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
In-Reply-To: <1288318786-12319-1-git-send-email-jon.mason@exar.com>
Add support for enable/disabling hardware timestamping on receive
packets via ioctl call. When enabled, the hardware timestamp replaces
the FCS in the payload.
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/vxge/vxge-main.c | 133 ++++++++++++++++++++++++++++++++++++++++--
drivers/net/vxge/vxge-main.h | 8 ++-
2 files changed, 132 insertions(+), 9 deletions(-)
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index 52a48e7..a365784 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -51,6 +51,7 @@
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
#include <linux/firmware.h>
+#include <linux/net_tstamp.h>
#include "vxge-main.h"
#include "vxge-reg.h"
@@ -360,7 +361,7 @@ vxge_rx_1b_compl(struct __vxge_hw_ring *ringh, void *dtr,
u8 t_code, void *userdata)
{
struct vxge_ring *ring = (struct vxge_ring *)userdata;
- struct net_device *dev = ring->ndev;
+ struct net_device *dev = ring->ndev;
unsigned int dma_sizes;
void *first_dtr = NULL;
int dtr_cnt = 0;
@@ -504,6 +505,16 @@ vxge_rx_1b_compl(struct __vxge_hw_ring *ringh, void *dtr,
else
skb_checksum_none_assert(skb);
+
+ if (ring->rx_hwts) {
+ struct skb_shared_hwtstamps *skb_hwts;
+ u32 ns = *(u32 *)(skb->head + pkt_length);
+
+ skb_hwts = skb_hwtstamps(skb);
+ skb_hwts->hwtstamp = ns_to_ktime(ns);
+ skb_hwts->syststamp.tv64 = 0;
+ }
+
/* rth_hash_type and rth_it_hit are non-zero regardless of
* whether rss is enabled. Only the rth_value is zero/non-zero
* if rss is disabled/enabled, so key off of that.
@@ -2026,6 +2037,7 @@ int vxge_open_vpaths(struct vxgedev *vdev)
vdev->config.fifo_indicate_max_pkts;
vpath->ring.rx_vector_no = 0;
vpath->ring.rx_csum = vdev->rx_csum;
+ vpath->ring.rx_hwts = vdev->rx_hwts;
vpath->is_open = 1;
vdev->vp_handles[i] = vpath->handle;
vpath->ring.gro_enable = vdev->config.gro_enable;
@@ -2960,6 +2972,101 @@ vxge_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *net_stats)
return net_stats;
}
+static enum vxge_hw_status vxge_timestamp_config(struct vxgedev *vdev,
+ int enable)
+{
+ enum vxge_hw_status status;
+ u64 val64;
+
+ /* Timestamp is passed to the driver via the FCS, therefore we
+ * must disable the FCS stripping by the adapter. Since this is
+ * required for the driver to load (due to a hardware bug),
+ * there is no need to do anything special here.
+ */
+ if (enable)
+ val64 = VXGE_HW_XMAC_TIMESTAMP_EN |
+ VXGE_HW_XMAC_TIMESTAMP_USE_LINK_ID(0) |
+ VXGE_HW_XMAC_TIMESTAMP_INTERVAL(0);
+ else
+ val64 = 0;
+
+ status = vxge_hw_mgmt_reg_write(vdev->devh,
+ vxge_hw_mgmt_reg_type_mrpcim,
+ 0,
+ offsetof(struct vxge_hw_mrpcim_reg,
+ xmac_timestamp),
+ val64);
+ vxge_hw_device_flush_io(vdev->devh);
+ return status;
+}
+
+static int vxge_hwtstamp_ioctl(struct vxgedev *vdev, void __user *data)
+{
+ struct hwtstamp_config config;
+ enum vxge_hw_status status;
+ int i;
+
+ if (copy_from_user(&config, data, sizeof(config)))
+ return -EFAULT;
+
+ /* reserved for future extensions */
+ if (config.flags)
+ return -EINVAL;
+
+ /* Transmit HW Timestamp not supported */
+ switch (config.tx_type) {
+ case HWTSTAMP_TX_OFF:
+ break;
+ case HWTSTAMP_TX_ON:
+ default:
+ return -ERANGE;
+ }
+
+ switch (config.rx_filter) {
+ case HWTSTAMP_FILTER_NONE:
+ status = vxge_timestamp_config(vdev, 0);
+ if (status != VXGE_HW_OK)
+ return -EFAULT;
+
+ vdev->rx_hwts = 0;
+ config.rx_filter = HWTSTAMP_FILTER_NONE;
+ break;
+
+ case HWTSTAMP_FILTER_ALL:
+ case HWTSTAMP_FILTER_SOME:
+ case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
+ case HWTSTAMP_FILTER_PTP_V2_EVENT:
+ case HWTSTAMP_FILTER_PTP_V2_SYNC:
+ case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ status = vxge_timestamp_config(vdev, 1);
+ if (status != VXGE_HW_OK)
+ return -EFAULT;
+
+ vdev->rx_hwts = 1;
+ config.rx_filter = HWTSTAMP_FILTER_ALL;
+ break;
+
+ default:
+ return -ERANGE;
+ }
+
+ for (i = 0; i < vdev->no_of_vpath; i++)
+ vdev->vpaths[i].ring.rx_hwts = vdev->rx_hwts;
+
+ if (copy_to_user(data, &config, sizeof(config)))
+ return -EFAULT;
+
+ return 0;
+}
+
/**
* vxge_ioctl
* @dev: Device pointer.
@@ -2972,7 +3079,20 @@ vxge_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *net_stats)
*/
static int vxge_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
- return -EOPNOTSUPP;
+ struct vxgedev *vdev = netdev_priv(dev);
+ int ret;
+
+ switch (cmd) {
+ case SIOCSHWTSTAMP:
+ ret = vxge_hwtstamp_ioctl(vdev, rq->ifr_data);
+ if (ret)
+ return ret;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
}
/**
@@ -3169,6 +3289,7 @@ int __devinit vxge_device_register(struct __vxge_hw_device *hldev,
vdev->pdev = hldev->pdev;
memcpy(&vdev->config, config, sizeof(struct vxge_config));
vdev->rx_csum = 1; /* Enable Rx CSUM by default. */
+ vdev->rx_hwts = 0;
SET_NETDEV_DEV(ndev, &vdev->pdev->dev);
@@ -4303,10 +4424,10 @@ vxge_probe(struct pci_dev *pdev, const struct pci_device_id *pre)
}
/* if FCS stripping is not disabled in MAC fail driver load */
- if (vxge_hw_vpath_strip_fcs_check(hldev, vpath_mask) != VXGE_HW_OK) {
- vxge_debug_init(VXGE_ERR,
- "%s: FCS stripping is not disabled in MAC"
- " failing driver load", VXGE_DRIVER_NAME);
+ status = vxge_hw_vpath_strip_fcs_check(hldev, vpath_mask);
+ if (status != VXGE_HW_OK) {
+ vxge_debug_init(VXGE_ERR, "%s: FCS stripping is enabled in MAC"
+ " failing driver load", VXGE_DRIVER_NAME);
ret = -EINVAL;
goto _exit4;
}
diff --git a/drivers/net/vxge/vxge-main.h b/drivers/net/vxge/vxge-main.h
index 1e47319..947893e 100644
--- a/drivers/net/vxge/vxge-main.h
+++ b/drivers/net/vxge/vxge-main.h
@@ -248,8 +248,9 @@ struct vxge_ring {
*/
int driver_id;
- /* copy of the flag indicating whether rx_csum is to be used */
- u32 rx_csum;
+ /* copy of the flag indicating whether rx_csum is to be used */
+ u32 rx_csum:1,
+ rx_hwts:1;
int pkts_processed;
int budget;
@@ -327,7 +328,8 @@ struct vxgedev {
u16 all_multi_flg;
/* A flag indicating whether rx_csum is to be used or not. */
- u32 rx_csum;
+ u32 rx_csum:1,
+ rx_hwts:1;
struct vxge_msix_entry *vxge_entries;
struct msix_entry *entries;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 07/11] vxge: Handle errors in vxge_hw_vpath_fw_api
From: Jon Mason @ 2010-10-29 2:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
In-Reply-To: <1288318786-12319-1-git-send-email-jon.mason@exar.com>
Propagate the return code of the call to vxge_hw_vpath_fw_api and
__vxge_hw_vpath_pci_func_mode_get. This enables the proper handling of
error conditions when querying the function mode of the device during
probe.
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/vxge/vxge-config.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/vxge/vxge-config.c b/drivers/net/vxge/vxge-config.c
index 4a166a3..e18b2f9 100644
--- a/drivers/net/vxge/vxge-config.c
+++ b/drivers/net/vxge/vxge-config.c
@@ -958,8 +958,9 @@ __vxge_hw_vpath_card_info_get(struct __vxge_hw_virtualpath *vpath,
* __vxge_hw_vpath_pci_func_mode_get - Get the pci mode
* Returns pci function mode
*/
-static u64
-__vxge_hw_vpath_pci_func_mode_get(struct __vxge_hw_virtualpath *vpath)
+static enum vxge_hw_status
+__vxge_hw_vpath_pci_func_mode_get(struct __vxge_hw_virtualpath *vpath,
+ struct vxge_hw_device_hw_info *hw_info)
{
u64 data0, data1 = 0, steer_ctrl = 0;
enum vxge_hw_status status;
@@ -970,8 +971,11 @@ __vxge_hw_vpath_pci_func_mode_get(struct __vxge_hw_virtualpath *vpath)
VXGE_HW_RTS_ACCESS_STEER_CTRL_ACTION_READ_MEMO_ENTRY,
VXGE_HW_RTS_ACCESS_STEER_CTRL_DATA_STRUCT_SEL_FW_MEMO,
0, &data0, &data1, &steer_ctrl);
+ if (status != VXGE_HW_OK)
+ return status;
- return data0;
+ hw_info->function_mode = data0;
+ return status;
}
/*
@@ -1086,8 +1090,9 @@ vxge_hw_device_hw_info_get(void __iomem *bar0,
(bar0 + val64);
vpath.vp_open = 0;
- hw_info->function_mode =
- __vxge_hw_vpath_pci_func_mode_get(&vpath);
+ status = __vxge_hw_vpath_pci_func_mode_get(&vpath, hw_info);
+ if (status != VXGE_HW_OK)
+ goto exit;
status = __vxge_hw_vpath_fw_ver_get(&vpath, hw_info);
if (status != VXGE_HW_OK)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 08/11] vxge: Titan1A detection
From: Jon Mason @ 2010-10-29 2:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
In-Reply-To: <1288318786-12319-1-git-send-email-jon.mason@exar.com>
Detect if the adapter is Titan or Titan1A, and tune the driver for this
hardware. Also, remove unnecessary function __vxge_hw_device_id_get.
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/vxge/vxge-config.c | 37 ++++++--------------------
drivers/net/vxge/vxge-config.h | 9 ------
drivers/net/vxge/vxge-main.c | 53 ++++++++++++++++++++++++++++++++------
drivers/net/vxge/vxge-main.h | 55 +++++++++++++++++++++++++++-------------
4 files changed, 90 insertions(+), 64 deletions(-)
diff --git a/drivers/net/vxge/vxge-config.c b/drivers/net/vxge/vxge-config.c
index e18b2f9..d61d7f4 100644
--- a/drivers/net/vxge/vxge-config.c
+++ b/drivers/net/vxge/vxge-config.c
@@ -657,26 +657,6 @@ exit:
}
/*
- * __vxge_hw_device_id_get
- * This routine returns sets the device id and revision numbers into the device
- * structure
- */
-void __vxge_hw_device_id_get(struct __vxge_hw_device *hldev)
-{
- u64 val64;
-
- val64 = readq(&hldev->common_reg->titan_asic_id);
- hldev->device_id =
- (u16)VXGE_HW_TITAN_ASIC_ID_GET_INITIAL_DEVICE_ID(val64);
-
- hldev->major_revision =
- (u8)VXGE_HW_TITAN_ASIC_ID_GET_INITIAL_MAJOR_REVISION(val64);
-
- hldev->minor_revision =
- (u8)VXGE_HW_TITAN_ASIC_ID_GET_INITIAL_MINOR_REVISION(val64);
-}
-
-/*
* __vxge_hw_device_access_rights_get: Get Access Rights of the driver
* This routine returns the Access Rights of the driver
*/
@@ -1178,7 +1158,6 @@ vxge_hw_device_initialize(
vfree(hldev);
goto exit;
}
- __vxge_hw_device_id_get(hldev);
__vxge_hw_device_host_info_get(hldev);
@@ -4329,16 +4308,18 @@ vpath_open_exit1:
void
vxge_hw_vpath_rx_doorbell_init(struct __vxge_hw_vpath_handle *vp)
{
- struct __vxge_hw_virtualpath *vpath = NULL;
+ struct __vxge_hw_virtualpath *vpath = vp->vpath;
+ struct __vxge_hw_ring *ring = vpath->ringh;
+ struct vxgedev *vdev = netdev_priv(vpath->hldev->ndev);
u64 new_count, val64, val164;
- struct __vxge_hw_ring *ring;
- vpath = vp->vpath;
- ring = vpath->ringh;
+ if (vdev->titan1) {
+ new_count = readq(&vpath->vp_reg->rxdmem_size);
+ new_count &= 0x1fff;
+ } else
+ new_count = ring->config->ring_blocks * VXGE_HW_BLOCK_SIZE / 8;
- new_count = readq(&vpath->vp_reg->rxdmem_size);
- new_count &= 0x1fff;
- val164 = (VXGE_HW_RXDMEM_SIZE_PRC_RXDMEM_SIZE(new_count));
+ val164 = VXGE_HW_RXDMEM_SIZE_PRC_RXDMEM_SIZE(new_count);
writeq(VXGE_HW_PRC_RXD_DOORBELL_NEW_QW_CNT(val164),
&vpath->vp_reg->prc_rxd_doorbell);
diff --git a/drivers/net/vxge/vxge-config.h b/drivers/net/vxge/vxge-config.h
index 3859d59..252969c 100644
--- a/drivers/net/vxge/vxge-config.h
+++ b/drivers/net/vxge/vxge-config.h
@@ -713,9 +713,6 @@ struct __vxge_hw_vpath_handle{
/**
* struct __vxge_hw_device - Hal device object
* @magic: Magic Number
- * @device_id: PCI Device Id of the adapter
- * @major_revision: PCI Device major revision
- * @minor_revision: PCI Device minor revision
* @bar0: BAR0 virtual address.
* @pdev: Physical device handle
* @config: Confguration passed by the LL driver at initialization
@@ -727,9 +724,6 @@ struct __vxge_hw_device {
u32 magic;
#define VXGE_HW_DEVICE_MAGIC 0x12345678
#define VXGE_HW_DEVICE_DEAD 0xDEADDEAD
- u16 device_id;
- u8 major_revision;
- u8 minor_revision;
void __iomem *bar0;
struct pci_dev *pdev;
struct net_device *ndev;
@@ -2212,9 +2206,6 @@ __vxge_hw_device_toc_get(void __iomem *bar0);
enum vxge_hw_status
__vxge_hw_device_reg_addr_get(struct __vxge_hw_device *hldev);
-void
-__vxge_hw_device_id_get(struct __vxge_hw_device *hldev);
-
enum vxge_hw_status
vxge_hw_device_flick_link_led(struct __vxge_hw_device *devh, u64 on_off);
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index a365784..c014b26 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -2001,8 +2001,23 @@ int vxge_open_vpaths(struct vxgedev *vdev)
for (i = 0; i < vdev->no_of_vpath; i++) {
vpath = &vdev->vpaths[i];
-
vxge_assert(vpath->is_configured);
+
+ if (!vdev->titan1) {
+ struct vxge_hw_vp_config *vcfg;
+ vcfg = &vdev->devh->config.vp_config[vpath->device_id];
+
+ vcfg->rti.urange_a = RTI_T1A_RX_URANGE_A;
+ vcfg->rti.urange_b = RTI_T1A_RX_URANGE_B;
+ vcfg->rti.urange_c = RTI_T1A_RX_URANGE_C;
+ vcfg->tti.uec_a = TTI_T1A_TX_UFC_A;
+ vcfg->tti.uec_b = TTI_T1A_TX_UFC_B;
+ vcfg->tti.uec_c = TTI_T1A_TX_UFC_C(vdev->mtu);
+ vcfg->tti.uec_d = TTI_T1A_TX_UFC_D(vdev->mtu);
+ vcfg->tti.ltimer_val = VXGE_T1A_TTI_LTIMER_VAL;
+ vcfg->tti.rtimer_val = VXGE_T1A_TTI_RTIMER_VAL;
+ }
+
attr.vp_id = vpath->device_id;
attr.fifo_attr.callback = vxge_xmit_compl;
attr.fifo_attr.txdl_term = vxge_tx_term;
@@ -2699,9 +2714,10 @@ vxge_open(struct net_device *dev)
vxge_os_timer(vdev->vp_reset_timer,
vxge_poll_vp_reset, vdev, (HZ/2));
- if (vdev->vp_lockup_timer.function == NULL)
- vxge_os_timer(vdev->vp_lockup_timer,
- vxge_poll_vp_lockup, vdev, (HZ/2));
+ /* There is no need to check for RxD leak and RxD lookup on Titan1A */
+ if (vdev->titan1 && vdev->vp_lockup_timer.function == NULL)
+ vxge_os_timer(vdev->vp_lockup_timer, vxge_poll_vp_lockup, vdev,
+ HZ / 2);
set_bit(__VXGE_STATE_CARD_UP, &vdev->state);
@@ -2833,7 +2849,9 @@ int do_vxge_close(struct net_device *dev, int do_io)
smp_wmb();
}
- del_timer_sync(&vdev->vp_lockup_timer);
+
+ if (vdev->titan1)
+ del_timer_sync(&vdev->vp_lockup_timer);
del_timer_sync(&vdev->vp_reset_timer);
@@ -3251,10 +3269,23 @@ static const struct net_device_ops vxge_netdev_ops = {
#endif
};
-int __devinit vxge_device_register(struct __vxge_hw_device *hldev,
- struct vxge_config *config,
- int high_dma, int no_of_vpath,
- struct vxgedev **vdev_out)
+static int __devinit vxge_device_revision(struct vxgedev *vdev)
+{
+ int ret;
+ u8 revision;
+
+ ret = pci_read_config_byte(vdev->pdev, PCI_REVISION_ID, &revision);
+ if (ret)
+ return -EIO;
+
+ vdev->titan1 = (revision == VXGE_HW_TITAN1_PCI_REVISION);
+ return 0;
+}
+
+static int __devinit vxge_device_register(struct __vxge_hw_device *hldev,
+ struct vxge_config *config,
+ int high_dma, int no_of_vpath,
+ struct vxgedev **vdev_out)
{
struct net_device *ndev;
enum vxge_hw_status status = VXGE_HW_OK;
@@ -3291,6 +3322,10 @@ int __devinit vxge_device_register(struct __vxge_hw_device *hldev,
vdev->rx_csum = 1; /* Enable Rx CSUM by default. */
vdev->rx_hwts = 0;
+ ret = vxge_device_revision(vdev);
+ if (ret < 0)
+ goto _out1;
+
SET_NETDEV_DEV(ndev, &vdev->pdev->dev);
ndev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX |
diff --git a/drivers/net/vxge/vxge-main.h b/drivers/net/vxge/vxge-main.h
index 947893e..151f54b 100644
--- a/drivers/net/vxge/vxge-main.h
+++ b/drivers/net/vxge/vxge-main.h
@@ -29,6 +29,9 @@
#define PCI_DEVICE_ID_TITAN_WIN 0x5733
#define PCI_DEVICE_ID_TITAN_UNI 0x5833
+#define VXGE_HW_TITAN1_PCI_REVISION 1
+#define VXGE_HW_TITAN1A_PCI_REVISION 2
+
#define VXGE_USE_DEFAULT 0xffffffff
#define VXGE_HW_VPATH_MSIX_ACTIVE 4
#define VXGE_ALARM_MSIX_ID 2
@@ -53,11 +56,13 @@
#define VXGE_TTI_BTIMER_VAL 250000
-#define VXGE_TTI_LTIMER_VAL 1000
-#define VXGE_TTI_RTIMER_VAL 0
-#define VXGE_RTI_BTIMER_VAL 250
-#define VXGE_RTI_LTIMER_VAL 100
-#define VXGE_RTI_RTIMER_VAL 0
+#define VXGE_TTI_LTIMER_VAL 1000
+#define VXGE_T1A_TTI_LTIMER_VAL 80
+#define VXGE_TTI_RTIMER_VAL 0
+#define VXGE_T1A_TTI_RTIMER_VAL 400
+#define VXGE_RTI_BTIMER_VAL 250
+#define VXGE_RTI_LTIMER_VAL 100
+#define VXGE_RTI_RTIMER_VAL 0
#define VXGE_FIFO_INDICATE_MAX_PKTS VXGE_DEF_FIFO_LENGTH
#define VXGE_ISR_POLLING_CNT 8
#define VXGE_MAX_CONFIG_DEV 0xFF
@@ -76,14 +81,32 @@
#define TTI_TX_UFC_B 40
#define TTI_TX_UFC_C 60
#define TTI_TX_UFC_D 100
+#define TTI_T1A_TX_UFC_A 30
+#define TTI_T1A_TX_UFC_B 80
+/* Slope - (max_mtu - min_mtu)/(max_mtu_ufc - min_mtu_ufc) */
+/* Slope - 93 */
+/* 60 - 9k Mtu, 140 - 1.5k mtu */
+#define TTI_T1A_TX_UFC_C(mtu) (60 + ((VXGE_HW_MAX_MTU - mtu) / 93))
+
+/* Slope - 37 */
+/* 100 - 9k Mtu, 300 - 1.5k mtu */
+#define TTI_T1A_TX_UFC_D(mtu) (100 + ((VXGE_HW_MAX_MTU - mtu) / 37))
+
+
+#define RTI_RX_URANGE_A 5
+#define RTI_RX_URANGE_B 15
+#define RTI_RX_URANGE_C 40
+#define RTI_T1A_RX_URANGE_A 1
+#define RTI_T1A_RX_URANGE_B 20
+#define RTI_T1A_RX_URANGE_C 50
+#define RTI_RX_UFC_A 1
+#define RTI_RX_UFC_B 5
+#define RTI_RX_UFC_C 10
+#define RTI_RX_UFC_D 15
+#define RTI_T1A_RX_UFC_B 20
+#define RTI_T1A_RX_UFC_C 50
+#define RTI_T1A_RX_UFC_D 60
-#define RTI_RX_URANGE_A 5
-#define RTI_RX_URANGE_B 15
-#define RTI_RX_URANGE_C 40
-#define RTI_RX_UFC_A 1
-#define RTI_RX_UFC_B 5
-#define RTI_RX_UFC_C 10
-#define RTI_RX_UFC_D 15
/* Milli secs timer period */
#define VXGE_TIMER_DELAY 10000
@@ -329,7 +352,8 @@ struct vxgedev {
/* A flag indicating whether rx_csum is to be used or not. */
u32 rx_csum:1,
- rx_hwts:1;
+ rx_hwts:1,
+ titan1:1;
struct vxge_msix_entry *vxge_entries;
struct msix_entry *entries;
@@ -396,11 +420,6 @@ struct vxge_tx_priv {
mod_timer(&timer, (jiffies + exp)); \
} while (0);
-int __devinit vxge_device_register(struct __vxge_hw_device *devh,
- struct vxge_config *config,
- int high_dma, int no_of_vpath,
- struct vxgedev **vdev);
-
void vxge_device_unregister(struct __vxge_hw_device *devh);
void vxge_vpath_intr_enable(struct vxgedev *vdev, int vp_id);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 09/11] vxge: correct multi-function detection
From: Jon Mason @ 2010-10-29 2:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
In-Reply-To: <1288318786-12319-1-git-send-email-jon.mason@exar.com>
The values used to determined if the adapter is running in single or
multi-function mode were previously modified to the values necessary
when making the VXGE_HW_FW_API_GET_FUNC_MODE firmware call. However,
the firmware call was not modified. This had the driver printing out on
probe that the adapter was in multi-function mode when in single
function mode and vice versa.
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/vxge/vxge-config.c | 6 +++---
drivers/net/vxge/vxge-reg.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxge/vxge-config.c b/drivers/net/vxge/vxge-config.c
index d61d7f4..312c4c1 100644
--- a/drivers/net/vxge/vxge-config.c
+++ b/drivers/net/vxge/vxge-config.c
@@ -945,16 +945,16 @@ __vxge_hw_vpath_pci_func_mode_get(struct __vxge_hw_virtualpath *vpath,
u64 data0, data1 = 0, steer_ctrl = 0;
enum vxge_hw_status status;
- data0 = VXGE_HW_RTS_ACCESS_STEER_DATA0_MEMO_ITEM_PCI_MODE;
+ data0 = 0;
status = vxge_hw_vpath_fw_api(vpath,
- VXGE_HW_RTS_ACCESS_STEER_CTRL_ACTION_READ_MEMO_ENTRY,
+ VXGE_HW_FW_API_GET_FUNC_MODE,
VXGE_HW_RTS_ACCESS_STEER_CTRL_DATA_STRUCT_SEL_FW_MEMO,
0, &data0, &data1, &steer_ctrl);
if (status != VXGE_HW_OK)
return status;
- hw_info->function_mode = data0;
+ hw_info->function_mode = VXGE_HW_GET_FUNC_MODE_VAL(data0);
return status;
}
diff --git a/drivers/net/vxge/vxge-reg.h b/drivers/net/vxge/vxge-reg.h
index f9ac574..278daae 100644
--- a/drivers/net/vxge/vxge-reg.h
+++ b/drivers/net/vxge/vxge-reg.h
@@ -62,6 +62,9 @@
#define VXGE_HW_GET_EPROM_IMAGE_REV(val) vxge_bVALn(val, 48, 16)
#define VXGE_HW_RTS_ACCESS_STEER_ROM_IMAGE_INDEX(val) vxge_vBIT(val, 16, 8)
+#define VXGE_HW_FW_API_GET_FUNC_MODE 29
+#define VXGE_HW_GET_FUNC_MODE_VAL(val) (val & 0xFF)
+
#define VXGE_HW_BYTES_PER_U64 8
#define VXGE_HW_FW_UPGRADE_MEMO 13
#define VXGE_HW_FW_UPGRADE_ACTION 16
--
1.7.0.4
^ permalink raw reply related
* [PATCH 10/11] vxge: update Kconfig
From: Jon Mason @ 2010-10-29 2:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
In-Reply-To: <1288318786-12319-1-git-send-email-jon.mason@exar.com>
Update Kconfig to reflect Exar's purchase of Neterion (formerly S2IO).
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/Kconfig | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 77c1fab..123a11e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2750,29 +2750,38 @@ config IXGB
will be called ixgb.
config S2IO
- tristate "S2IO 10Gbe XFrame NIC"
+ tristate "Exar Xframe 10Gb Ethernet Adapter"
depends on PCI
---help---
- This driver supports the 10Gbe XFrame NIC of S2IO.
+ This driver supports Exar Corp's Xframe Series 10Gb Ethernet Adapters.
+
More specific information on configuring the driver is in
<file:Documentation/networking/s2io.txt>.
+ To compile this driver as a module, choose M here. The module
+ will be called s2io.
+
config VXGE
- tristate "Neterion X3100 Series 10GbE PCIe Server Adapter"
+ tristate "Exar X3100 Series 10GbE PCIe Server Adapter"
depends on PCI && INET
---help---
- This driver supports Neterion Inc's X3100 Series 10 GbE PCIe
+ This driver supports Exar Corp's X3100 Series 10 GbE PCIe
I/O Virtualized Server Adapter.
+
More specific information on configuring the driver is in
<file:Documentation/networking/vxge.txt>.
+ To compile this driver as a module, choose M here. The module
+ will be called vxge.
+
config VXGE_DEBUG_TRACE_ALL
bool "Enabling All Debug trace statments in driver"
default n
depends on VXGE
---help---
Say Y here if you want to enabling all the debug trace statements in
- driver. By default only few debug trace statements are enabled.
+ the vxge driver. By default only few debug trace statements are
+ enabled.
config MYRI10GE
tristate "Myricom Myri-10G Ethernet support"
--
1.7.0.4
^ permalink raw reply related
* [PATCH 11/11] vxge: update driver version
From: Jon Mason @ 2010-10-29 2:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sivakumar Subramani, Sreenivasa Honnur, Ram Vepa
In-Reply-To: <1288318786-12319-1-git-send-email-jon.mason@exar.com>
Update vxge driver version
Signed-off-by: Jon Mason <jon.mason@exar.com>
Signed-off-by: Ram Vepa <ram.vepa@exar.com>
---
drivers/net/vxge/vxge-version.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxge/vxge-version.h b/drivers/net/vxge/vxge-version.h
index b4eced1..c6948bb 100644
--- a/drivers/net/vxge/vxge-version.h
+++ b/drivers/net/vxge/vxge-version.h
@@ -16,8 +16,8 @@
#define VXGE_VERSION_MAJOR "2"
#define VXGE_VERSION_MINOR "0"
-#define VXGE_VERSION_FIX "9"
-#define VXGE_VERSION_BUILD "20840"
+#define VXGE_VERSION_FIX "10"
+#define VXGE_VERSION_BUILD "21754"
#define VXGE_VERSION_FOR "k"
#define VXGE_FW_VER(maj, min, bld) (((maj) << 16) + ((min) << 8) + (bld))
--
1.7.0.4
^ permalink raw reply related
* [PATCH] drivers/net/igb: remove unused variable in igb_xmit_frame_ring_adv.
From: Tao Ma @ 2010-10-29 2:55 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, Tao Ma, Jiri Kosina
drivers/net/igb/igb_main.c: In function ‘igb_xmit_frame_ring_adv’:
drivers/net/igb/igb_main.c:4110: warning: unused variable ‘adapter’
Cc: Jiri Kosina <trivial@kernel.org>
Signed-off-by: Tao Ma <tao.ma@oracle.com>
---
drivers/net/igb/igb_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 14db09e..892d196 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -4107,7 +4107,6 @@ static inline int igb_maybe_stop_tx(struct igb_ring *tx_ring, int size)
netdev_tx_t igb_xmit_frame_ring_adv(struct sk_buff *skb,
struct igb_ring *tx_ring)
{
- struct igb_adapter *adapter = netdev_priv(tx_ring->netdev);
int tso = 0, count;
u32 tx_flags = 0;
u16 first;
--
1.7.1.GIT
^ permalink raw reply related
* Re: [PATCH] drivers/net/igb: remove unused variable in igb_xmit_frame_ring_adv.
From: David Miller @ 2010-10-29 3:12 UTC (permalink / raw)
To: tao.ma; +Cc: linux-kernel, netdev, trivial
In-Reply-To: <1288320949-5136-1-git-send-email-tao.ma@oracle.com>
Fixed already in the net-2.6 GIT tree.
^ permalink raw reply
* [PATCH] ixgbe: refactor ixgbe_alloc_queues()
From: Eric Dumazet @ 2010-10-29 3:45 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Tantilov, Emil S, David Miller, Waskiewicz Jr, Peter P,
Brattain, Ross B, netdev
In-Reply-To: <1288268493.27890.5.camel@jtkirshe-MOBL1>
Note : compiled only patch, not tested.
Thanks !
[PATCH] ixgbe: refactor ixgbe_alloc_queues()
I noticed ring variable was initialized before allocations, and that
memory node management was a bit ugly. We also leak memory in case of
ring allocations error.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/ixgbe/ixgbe_main.c | 69 ++++++++++++-------------------
1 file changed, 28 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 2bd3eb4..e89da9a 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -4470,65 +4470,52 @@ static void ixgbe_cache_ring_register(struct ixgbe_adapter *adapter)
**/
static int ixgbe_alloc_queues(struct ixgbe_adapter *adapter)
{
- int i;
- int orig_node = adapter->node;
+ int rx = 0, tx = 0, nid = adapter->node;
- for (i = 0; i < adapter->num_tx_queues; i++) {
- struct ixgbe_ring *ring = adapter->tx_ring[i];
- if (orig_node == -1) {
- int cur_node = next_online_node(adapter->node);
- if (cur_node == MAX_NUMNODES)
- cur_node = first_online_node;
- adapter->node = cur_node;
- }
- ring = kzalloc_node(sizeof(struct ixgbe_ring), GFP_KERNEL,
- adapter->node);
+ if (nid < 0 || !node_online(nid))
+ nid = first_online_node;
+
+ for (; tx < adapter->num_tx_queues; tx++) {
+ struct ixgbe_ring *ring;
+
+ ring = kzalloc_node(sizeof(*ring), GFP_KERNEL, nid);
if (!ring)
- ring = kzalloc(sizeof(struct ixgbe_ring), GFP_KERNEL);
+ ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (!ring)
- goto err_tx_ring_allocation;
+ goto err_allocation;
ring->count = adapter->tx_ring_count;
- ring->queue_index = i;
- ring->numa_node = adapter->node;
+ ring->queue_index = tx;
+ ring->numa_node = nid;
- adapter->tx_ring[i] = ring;
+ adapter->tx_ring[tx] = ring;
}
- /* Restore the adapter's original node */
- adapter->node = orig_node;
+ for (; rx < adapter->num_rx_queues; rx++) {
+ struct ixgbe_ring *ring;
- for (i = 0; i < adapter->num_rx_queues; i++) {
- struct ixgbe_ring *ring = adapter->rx_ring[i];
- if (orig_node == -1) {
- int cur_node = next_online_node(adapter->node);
- if (cur_node == MAX_NUMNODES)
- cur_node = first_online_node;
- adapter->node = cur_node;
- }
- ring = kzalloc_node(sizeof(struct ixgbe_ring), GFP_KERNEL,
- adapter->node);
+ ring = kzalloc_node(sizeof(*ring), GFP_KERNEL, nid);
if (!ring)
- ring = kzalloc(sizeof(struct ixgbe_ring), GFP_KERNEL);
+ ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (!ring)
- goto err_rx_ring_allocation;
+ goto err_allocation;
ring->count = adapter->rx_ring_count;
- ring->queue_index = i;
- ring->numa_node = adapter->node;
+ ring->queue_index = rx;
+ ring->numa_node = nid;
- adapter->rx_ring[i] = ring;
+ adapter->rx_ring[rx] = ring;
}
- /* Restore the adapter's original node */
- adapter->node = orig_node;
-
ixgbe_cache_ring_register(adapter);
return 0;
-err_rx_ring_allocation:
- for (i = 0; i < adapter->num_tx_queues; i++)
- kfree(adapter->tx_ring[i]);
-err_tx_ring_allocation:
+err_allocation:
+ while (tx)
+ kfree(adapter->tx_ring[--tx]);
+
+ while (rx)
+ kfree(adapter->tx_ring[--rx]);
+
return -ENOMEM;
}
^ permalink raw reply related
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Maciej W. Rozycki @ 2010-10-29 4:21 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: davem, netdev
In-Reply-To: <1288315159-1350-6-git-send-email-paul.gortmaker@windriver.com>
On Thu, 28 Oct 2010, Paul Gortmaker wrote:
> DEC as a name brand has been gone for over 10 years, and these
> drivers represent technology from the 1990's like the venerable
> ISA bus. Hence relocate them to the legacy dir.
NAK for the TURBOchannel bits (defxx.[ch] and declance.c) unless you give
a plausible justification. You won't get these drivers offered unless you
have the bus in your system anyway, and if you do than you don't want to
have them hidden somewhere in the corner. If you see anything wrong with
these drivers, then please do let me know.
Also defxx.c is PCI too (apart from being EISA and TC).
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> drivers/net/Kconfig | 63 -----------------------------------
> drivers/net/Makefile | 4 --
> drivers/net/legacy/Kconfig | 63 +++++++++++++++++++++++++++++++++++
> drivers/net/legacy/Makefile | 5 +++
> drivers/net/{ => legacy}/declance.c | 0
> drivers/net/{ => legacy}/defxx.c | 0
> drivers/net/{ => legacy}/defxx.h | 0
> drivers/net/{ => legacy}/depca.c | 0
> drivers/net/{ => legacy}/depca.h | 0
> drivers/net/{ => legacy}/ewrk3.c | 0
> drivers/net/{ => legacy}/ewrk3.h | 0
Maciej
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: David Miller @ 2010-10-29 4:29 UTC (permalink / raw)
To: macro; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290516110.25426@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 29 Oct 2010 05:21:35 +0100 (BST)
> On Thu, 28 Oct 2010, Paul Gortmaker wrote:
>
>> DEC as a name brand has been gone for over 10 years, and these
>> drivers represent technology from the 1990's like the venerable
>> ISA bus. Hence relocate them to the legacy dir.
>
> NAK for the TURBOchannel bits (defxx.[ch] and declance.c) unless you give
> a plausible justification. You won't get these drivers offered unless you
> have the bus in your system anyway, and if you do than you don't want to
> have them hidden somewhere in the corner. If you see anything wrong with
> these drivers, then please do let me know.
>
> Also defxx.c is PCI too (apart from being EISA and TC).
PCI things can be legacy too.
This is not about a specific bus technology, it's simply for
"really old stuff" so we can declutter the top-level of drivers/net
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Maciej W. Rozycki @ 2010-10-29 4:54 UTC (permalink / raw)
To: David Miller; +Cc: paul.gortmaker, netdev
In-Reply-To: <20101028.212939.189691515.davem@davemloft.net>
On Thu, 28 Oct 2010, David Miller wrote:
> > NAK for the TURBOchannel bits (defxx.[ch] and declance.c) unless you give
> > a plausible justification. You won't get these drivers offered unless you
> > have the bus in your system anyway, and if you do than you don't want to
> > have them hidden somewhere in the corner. If you see anything wrong with
> > these drivers, then please do let me know.
> >
> > Also defxx.c is PCI too (apart from being EISA and TC).
>
> PCI things can be legacy too.
>
> This is not about a specific bus technology, it's simply for
> "really old stuff" so we can declutter the top-level of drivers/net
Hmm, what's the difference between placing these drivers here or there
and what's so particular about them that they cause clutter? I mean a
mere high number of items does not cause a mess by itself -- the lack of
order might.
Also -- if this change goes ahead -- when I add new TURBOchannel drivers,
should they go straight to legacy/? It sounds odd to me to have a thing
obsolete straight from the beginning.
Maciej
^ permalink raw reply
* [PATCH] ks8851: suspend resume support
From: Arce, Abraham @ 2010-10-29 4:57 UTC (permalink / raw)
To: netdev@vger.kernel.org
Add suspend/resume support using default open/stop interface methods
to do hardware dependant operations.
On suspend, same low power state (soft power mode) will be kept, the
following blocks will be disabled:
- Internal PLL Clock
- Tx/Rx PHY
- MAC
- SPI Interface
Signed-off-by: Abraham Arce <x0066660@ti.com>
---
drivers/net/ks8851.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index 8a178bc..9d40e33 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -1570,6 +1570,37 @@ static int ks8851_read_selftest(struct ks8851_net *ks)
/* driver bus management functions */
+#ifdef CONFIG_PM
+static int ks8851_suspend(struct spi_device *spi, pm_message_t state)
+{
+ struct ks8851_net *ks = dev_get_drvdata(&spi->dev);
+ struct net_device *dev = ks->netdev;
+
+ if (netif_running(dev)) {
+ netif_device_detach(dev);
+ ks8851_net_stop(dev);
+ }
+
+ return 0;
+}
+
+static int ks8851_resume(struct spi_device *spi)
+{
+ struct ks8851_net *ks = dev_get_drvdata(&spi->dev);
+ struct net_device *dev = ks->netdev;
+
+ if (netif_running(dev)) {
+ ks8851_net_open(dev);
+ netif_device_attach(dev);
+ }
+
+ return 0;
+}
+#else
+#define ks8851_suspend NULL
+#define ks8851_resume NULL
+#endif
+
static int __devinit ks8851_probe(struct spi_device *spi)
{
struct net_device *ndev;
@@ -1710,6 +1741,8 @@ static struct spi_driver ks8851_driver = {
},
.probe = ks8851_probe,
.remove = __devexit_p(ks8851_remove),
+ .suspend = ks8851_suspend,
+ .resume = ks8851_resume,
};
static int __init ks8851_init(void)
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Maciej W. Rozycki @ 2010-10-29 5:46 UTC (permalink / raw)
To: David Miller; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290545270.25426@eddie.linux-mips.org>
On Fri, 29 Oct 2010, Maciej W. Rozycki wrote:
> > This is not about a specific bus technology, it's simply for
> > "really old stuff" so we can declutter the top-level of drivers/net
>
> Hmm, what's the difference between placing these drivers here or there
> and what's so particular about them that they cause clutter? I mean a
> mere high number of items does not cause a mess by itself -- the lack of
> order might.
I have given myself some food for thought and have come up with the
following proposal: how about simply classifying drivers according to the
physical layer they support or if multiple are, such as with the Ethernet
that is backwards compatible, the newest variation they do?
This would be no different to what we do wrt network protocols under
net/, so drivers would go to ethernet/, fasteth/, gbeth/, 10gbeth/, fddi/,
tokenring/, atm/, appletalk/, etc. (names up to debate if need be) as
applicable. This would scale well, avoid the need for arbitrary decisions
(is this piece legacy yet or not?) and automatically classify drivers as
more or less obsolescent too, as obviously none of the stuff under
ethernet/, fddi/ or tokenring/ can be reasonably recent unlike 10gbeth/.
Software stuff such as SLIP or PPP could go either into separate
subdirectories or grouped together under software/; I gather we have a few
such pieces only.
What do you think?
Maciej
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: David Miller @ 2010-10-29 5:47 UTC (permalink / raw)
To: macro; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290545270.25426@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 29 Oct 2010 05:54:56 +0100 (BST)
> Hmm, what's the difference between placing these drivers here or there
> and what's so particular about them that they cause clutter? I mean a
> mere high number of items does not cause a mess by itself -- the lack of
> order might.
>
> Also -- if this change goes ahead -- when I add new TURBOchannel drivers,
> should they go straight to legacy/? It sounds odd to me to have a thing
> obsolete straight from the beginning.
This patch series started with a "0/15" introduction posting which
explains the intention and reasoning.
It might be easier for you to read it instead of asking me to repeat
it's contents :-)
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Maciej W. Rozycki @ 2010-10-29 5:50 UTC (permalink / raw)
To: David Miller; +Cc: paul.gortmaker, netdev
In-Reply-To: <20101028.224703.112589527.davem@davemloft.net>
On Thu, 28 Oct 2010, David Miller wrote:
> This patch series started with a "0/15" introduction posting which
> explains the intention and reasoning.
Well, I didn't reach it (ENOBREAKFAST that has been fixed since ;) ), but
I sort of guessed it anyway and didn't like the arbitrary nature of
assigning drivers to legacy/.
> It might be easier for you to read it instead of asking me to repeat
> it's contents :-)
See my proposal that crossed with your e-mail. I think it fits the
purpose very well. :)
Maciej
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: David Miller @ 2010-10-29 5:53 UTC (permalink / raw)
To: macro; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290629450.25426@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 29 Oct 2010 06:46:13 +0100 (BST)
> This would be no different to what we do wrt network protocols under
> net/, so drivers would go to ethernet/, fasteth/, gbeth/, 10gbeth/, fddi/,
> tokenring/, atm/, appletalk/, etc. (names up to debate if need be) as
> applicable. This would scale well, avoid the need for arbitrary decisions
> (is this piece legacy yet or not?) and automatically classify drivers as
> more or less obsolescent too, as obviously none of the stuff under
> ethernet/, fddi/ or tokenring/ can be reasonably recent unlike 10gbeth/.
Why are you so hung up about something being called legacy?
I would be proud to be labelled "legacy", as that means I've served a
purpose for a long time and some folks even want or need me to stick
around for a bit longer.
Legacy hardware is just old and the drivers for them are in a purely
"sustaining" state, that is all.
And using link layer technology to classify is really stupid since
many devices match multiple of the categories you've suggested.
I think the existing proposal is just fine.
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: David Miller @ 2010-10-29 5:53 UTC (permalink / raw)
To: macro; +Cc: paul.gortmaker, netdev
In-Reply-To: <alpine.LFD.2.00.1010290647270.25426@eddie.linux-mips.org>
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Fri, 29 Oct 2010 06:50:17 +0100 (BST)
> On Thu, 28 Oct 2010, David Miller wrote:
>
>> It might be easier for you to read it instead of asking me to repeat
>> it's contents :-)
>
> See my proposal that crossed with your e-mail. I think it fits the
> purpose very well. :)
No, it's foolish, see my reply.
^ permalink raw reply
* Re: [PATCH iproute2] Support 'mode' parameter when creating macvtap device
From: Arnd Bergmann @ 2010-10-29 6:27 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Stephen Hemminger, Patrick McHardy, Michael S. Tsirkin, netdev,
kvm@vger.kernel.org l
In-Reply-To: <1288307440.30131.81.camel@sridhar.beaverton.ibm.com>
On Friday 29 October 2010, Sridhar Samudrala wrote:
> Add support for 'mode' parameter when creating a macvtap device.
> This allows a macvtap device to be created in bridge, private or
> the default vepa modes.
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Maciej W. Rozycki @ 2010-10-29 6:37 UTC (permalink / raw)
To: David Miller; +Cc: paul.gortmaker, netdev
In-Reply-To: <20101028.225356.39188490.davem@davemloft.net>
On Thu, 28 Oct 2010, David Miller wrote:
> > See my proposal that crossed with your e-mail. I think it fits the
> > purpose very well. :)
>
> No, it's foolish, see my reply.
Well, you are the maintainer, so it's your call. I disagree and I have
given what I believe is a reasonable justification, but that's about as
much as I can do -- I can't force it onto you. As I say my concern is
about the arbitrary assignment and not things being called "legacy" or
"best-ever", "pre-y2k", or whatever. And splitting a bunch of pieces of
software that are loosely related to one another into two bunches isn't
going to reduce clutter, but to spread it instead -- now you'll have
clutter in two places rather than just one, so I think the change is just
missing the point. Again, as the maintainer it's your right to disagree.
Thank you for the time you've taken to consider my comments nonetheless.
Maciej
^ permalink raw reply
* Re: [PATCH] net: Limit socket I/O iovec total length to INT_MAX.
From: Linus Torvalds @ 2010-10-29 6:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, drosenberg, jon.maloy, allan.stephens
In-Reply-To: <20101028.112231.232747062.davem@davemloft.net>
Oh, btw, noticed another small detail..
I don't know if this matters, but the regular read/write routines
don't actually use INT_MAX as the limit, but instead a "maximally
page-aligned value that fits in an int":
#define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK)
because the code does _not_ want to turn a nice set of huge
page-aligned big writes into a write of an odd number (2GB-1).
This may not make much of a difference to networking - you guys are
already used to working with odd sizes like 1500 bytes of data payload
per packet etc. Most regular filesystems are much more sensitive to
things like block (and particularly page-cache sized) boundaries
because of the vagaries of disk and cache granularities. But MAX_INT
is a _really_ odd size, and things like csum_and_copy still tends to
want to get things at least word-aligned, no? And if nothing else, the
memory copies tend to be better with cacheline boundaries.
It would be sad if a 4GB aligned write turns into
- one 2GB-1 aligned write
- one pessimally unaligned 2G-1 write where every read from user
space is unaligned
- finally a single 2-byte write.
I suspect it would be better off using the same kind of (MAX_INT &
PAGE_CACHE_MASK) logic - that 4GB write would still get split into
three partial writes (and _lots_ of packets ;), but at least they'd
all be word-aligned.
Does it matter? I dunno. Once you do 2GB+ writes, these kinds of small
details may be totally hidden in all the noise.
Linus
On Thu, Oct 28, 2010 at 11:22 AM, David Miller <davem@davemloft.net> wrote:
>
> This helps protect us from overflow issues down in the
> individual protocol sendmsg/recvmsg handlers. Once
> we hit INT_MAX we truncate out the rest of the iovec
> by setting the iov_len members to zero.
>
> This works because:
>
> 1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
> writes are allowed and the application will just continue
> with another write to send the rest of the data.
>
> 2) For datagram oriented sockets, where there must be a
> one-to-one correspondance between write() calls and
> packets on the wire, INT_MAX is going to be far larger
> than the packet size limit the protocol is going to
> check for and signal with -EMSGSIZE.
>
> Based upon a patch by Linus Torvalds.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>
> Ok, this is the patch I am testing right now. It ought to
> plug the TIPC holes wrt. handling iovecs given by the
> user.
>
> I'll look at the recently discovered RDS crap next :-/
>
> include/linux/socket.h | 2 +-
> net/compat.c | 12 +++++++-----
> net/core/iovec.c | 19 +++++++++----------
> 3 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 5146b50..86b652f 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -322,7 +322,7 @@ extern int csum_partial_copy_fromiovecend(unsigned char *kdata,
> int offset,
> unsigned int len, __wsum *csump);
>
> -extern long verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode);
> +extern int verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode);
> extern int memcpy_toiovec(struct iovec *v, unsigned char *kdata, int len);
> extern int memcpy_toiovecend(const struct iovec *v, unsigned char *kdata,
> int offset, int len);
> diff --git a/net/compat.c b/net/compat.c
> index 63d260e..71bfd8e 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -34,17 +34,19 @@ static inline int iov_from_user_compat_to_kern(struct iovec *kiov,
> struct compat_iovec __user *uiov32,
> int niov)
> {
> - int tot_len = 0;
> + size_t tot_len = 0;
>
> while (niov > 0) {
> compat_uptr_t buf;
> compat_size_t len;
>
> if (get_user(len, &uiov32->iov_len) ||
> - get_user(buf, &uiov32->iov_base)) {
> - tot_len = -EFAULT;
> - break;
> - }
> + get_user(buf, &uiov32->iov_base))
> + return -EFAULT;
> +
> + if (len > INT_MAX - tot_len)
> + len = INT_MAX - tot_len;
> +
> tot_len += len;
> kiov->iov_base = compat_ptr(buf);
> kiov->iov_len = (__kernel_size_t) len;
> diff --git a/net/core/iovec.c b/net/core/iovec.c
> index 72aceb1..e7f5b29 100644
> --- a/net/core/iovec.c
> +++ b/net/core/iovec.c
> @@ -35,10 +35,10 @@
> * in any case.
> */
>
> -long verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode)
> +int verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address, int mode)
> {
> int size, ct;
> - long err;
> + size_t err;
>
> if (m->msg_namelen) {
> if (mode == VERIFY_READ) {
> @@ -62,14 +62,13 @@ long verify_iovec(struct msghdr *m, struct iovec *iov, struct sockaddr *address,
> err = 0;
>
> for (ct = 0; ct < m->msg_iovlen; ct++) {
> - err += iov[ct].iov_len;
> - /*
> - * Goal is not to verify user data, but to prevent returning
> - * negative value, which is interpreted as errno.
> - * Overflow is still possible, but it is harmless.
> - */
> - if (err < 0)
> - return -EMSGSIZE;
> + size_t len = iov[ct].iov_len;
> +
> + if (len > INT_MAX - err) {
> + len = INT_MAX - err;
> + iov[ct].iov_len = len;
> + }
> + err += len;
> }
>
> return err;
> --
> 1.7.3.2
>
>
^ permalink raw reply
* RE: [PATCH] cxgb4vf: fix crash due to manipulating queues before registration
From: Dimitrios Michailidis @ 2010-10-29 7:36 UTC (permalink / raw)
To: David Miller, Casey Leedom; +Cc: netdev
In-Reply-To: <20101028.132122.245402585.davem@davemloft.net>
> > Before commit "net: allocate tx queues in register_netdevice"
> > netif_tx_stop_all_queues and related functions could be used between
> > device allocation and registration but now only after registration.
> > cxgb4 has such a call before registration and crashes now. Move it
> > after register_netdev.
> >
> > Signed-off-by: Casey Leedom <leedom@chelsio.com>
>
> Why are you manipulating the queue at all here?
>
> The queue state is "don't care" at this point in time,
> and has no meaning until ->open() is invoked.
The reason for the call at its initial pre register_netdev location was
an attempt to make the queues have the same state at the time of each
open. Without it at the first open __QUEUE_STATE_XOFF is not set due to
0-initialization but at subsequent opens it is set because close stops
the queues. I agree however that this disparity is not functionally
significant. Further, I believe moving the call after register_netdev
is buggy as open can be called after registration and it can clash with
the queue stopping. It seems then that these netif_tx_stop_all_queues
calls have to go now.
^ permalink raw reply
* RE: About the Davicom PHY in drivers/net/phy in Linux kernel
From: macpaul @ 2010-10-29 7:46 UTC (permalink / raw)
To: joseph_chang, netdev; +Cc: afleming, jeff, f.rodo
Hi Joseph,
I just followed up your suggestion in previous mail, let me quote them here:
# quote
The recommend is changed to be as below:
err = phy_write(phydev, MII_BMCR, BMCR_RESET);
//err = phy_write(phydev, MII_BMCR, BMCR_ISOLATE);
err = phy_write(phydev, MII_DM9161_SCR, MII_DM9161_SCR_INIT);
err = phy_write(phydev, MII_DM9161_10BTCSR, MII_DM9161_10BTCSR_INIT);
// err = phy_write(phydev, MII_NWAYTEST, 0x10);
err = phy_write(phydev, MII_BMCR, BMCR_ANENABLE | BMCR_ANRESTART);
*Note: Added a PHY reset command.
# end quote
>
> * == > Would you tell us your:
> CPU = ?
SoC: Faraday A320 (arm920t) / Andes AG101 (NDS32)
> Linux Kernel version= ?
Linux: 2.6.32
> I will like to download the same source code from LXR.
> And can check more detail for you.
I've believed that you have download the source already. :-)
^ permalink raw reply
* Re: [PATCH] ixgbe: refactor ixgbe_alloc_queues()
From: Jeff Kirsher @ 2010-10-29 7:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tantilov, Emil S, David Miller, Waskiewicz Jr, Peter P,
Brattain, Ross B, netdev
In-Reply-To: <1288323933.2711.43.camel@edumazet-laptop>
On Thu, Oct 28, 2010 at 20:45, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Note : compiled only patch, not tested.
>
> Thanks !
>
> [PATCH] ixgbe: refactor ixgbe_alloc_queues()
>
> I noticed ring variable was initialized before allocations, and that
> memory node management was a bit ugly. We also leak memory in case of
> ring allocations error.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> drivers/net/ixgbe/ixgbe_main.c | 69 ++++++++++++-------------------
> 1 file changed, 28 insertions(+), 41 deletions(-)
>
Thanks Eric. I will add this to my queue of patches.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Michael S. Tsirkin @ 2010-10-29 8:03 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288294355.11251.20.camel@localhost.localdomain>
On Thu, Oct 28, 2010 at 12:32:35PM -0700, Shirley Ma wrote:
> On Thu, 2010-10-28 at 07:20 +0200, Michael S. Tsirkin wrote:
> > My concern is this can delay signalling for unlimited time.
> > Could you pls test this with guests that do not have
> > 2b5bbe3b8bee8b38bdc27dd9c0270829b6eb7eeb
> > b0c39dbdc204006ef3558a66716ff09797619778
> > that is 2.6.31 and older?
>
> The patch only induces delay signaling unlimited time when there is no
> TX packet to transmit. I thought TX signaling only noticing guest to
> release the used buffers, anything else beside this?
Right, that's it I think. For newer kernels we orphan the skb
on xmit so we don't care that much about completing them.
This does rely on an undocumented assumption about guest
behaviour though.
> I tested rhel5u5 guest (2.6.18 kernel), it works fine. I checked the two
> commits log, I don't think this patch could cause any issue w/o these
> two patches.
>
> Also I found a big TX regression for old guest and new guest. For old
> guest, I am able to get almost 11Gb/s for 2K message size, but for the
> new guest kernel, I can only get 3.5 Gb/s with the patch and same host.
> I will dig it why.
>
> thanks
> Shirley
^ 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