* Re: [patch] usbnet: add timestamping support
From: David Miller @ 2011-09-29 18:55 UTC (permalink / raw)
To: michael; +Cc: netdev, oneukum
In-Reply-To: <1317305186-32700-1-git-send-email-michael@riesch.at>
From: Michael Riesch <michael@riesch.at>
Date: Thu, 29 Sep 2011 16:06:26 +0200
> In order to make USB-to-Ethernet-adapters (depending on usbnet) support
> timestamping, the "skb_defer_rx_timestamp" and "skb_tx_timestamp" function
> calls are added.
>
> Signed-off-by: Michael Riesch <michael@riesch.at>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] net/fec: add poll controller function for fec nic
From: David Miller @ 2011-09-29 18:54 UTC (permalink / raw)
To: jgq516; +Cc: netdev, linux-kernel
In-Reply-To: <1317298557-2878-2-git-send-email-jgq516@gmail.com>
From: jgq516@gmail.com
Date: Thu, 29 Sep 2011 20:15:57 +0800
> From: Xiao Jiang <jgq516@gmail.com>
>
> Add poll controller function for fec nic.
>
> Signed-off-by: Xiao Jiang <jgq516@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/2] net/fec: replace hardcoded irq num with macro
From: David Miller @ 2011-09-29 18:54 UTC (permalink / raw)
To: jgq516; +Cc: netdev, linux-kernel
In-Reply-To: <1317298557-2878-1-git-send-email-jgq516@gmail.com>
From: jgq516@gmail.com
Date: Thu, 29 Sep 2011 20:15:56 +0800
> From: Xiao Jiang <jgq516@gmail.com>
>
> Don't use hardcoded irq num and replace it with
> FEC_IRQ_NUM macro.
>
> Signed-off-by: Xiao Jiang <jgq516@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Venkat Venkatsubra @ 2011-09-29 18:51 UTC (permalink / raw)
To: jonathan; +Cc: netdev, davem
In the rds_iw_mr_pool struct the free_pinned field keeps track of
memory pinned by free MRs. While this field is incremented properly
upon allocation, it is never decremented upon unmapping. This would
cause the rds_rdma module to crash the kernel upon unloading, by
triggering the BUG_ON in the rds_iw_destroy_mr_pool function.
This change keeps track of the MRs that become unpinned, so that
free_pinned can be decremented appropriately.
Signed-off-by: Jonathan Lallinger <jonathan@ogc.us>
Signed-off-by: Steve Wise <swise@ogc.us>
---
Signed-off-by: Venkat Venkatsubra <venkat.x.venkatsubra@oracle.com>
Venkat
^ permalink raw reply
* [PATCH] RDSRDMA: Fix cleanup of rds_iw_mr_pool
From: Jonathan Lallinger @ 2011-09-29 17:58 UTC (permalink / raw)
To: davem, venkat.x.venkatsubra; +Cc: netdev
In the rds_iw_mr_pool struct the free_pinned field keeps track of
memory pinned by free MRs. While this field is incremented properly
upon allocation, it is never decremented upon unmapping. This would
cause the rds_rdma module to crash the kernel upon unloading, by
triggering the BUG_ON in the rds_iw_destroy_mr_pool function.
This change keeps track of the MRs that become unpinned, so that
free_pinned can be decremented appropriately.
Signed-off-by: Jonathan Lallinger <jonathan@ogc.us>
Signed-off-by: Steve Wise <swise@ogc.us>
---
net/rds/iw_rdma.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/net/rds/iw_rdma.c b/net/rds/iw_rdma.c
index 7c1c873..81d3167 100644
--- a/net/rds/iw_rdma.c
+++ b/net/rds/iw_rdma.c
@@ -84,7 +84,8 @@ static int rds_iw_map_fastreg(struct rds_iw_mr_pool *pool,
static void rds_iw_free_fastreg(struct rds_iw_mr_pool *pool, struct rds_iw_mr *ibmr);
static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
struct list_head *unmap_list,
- struct list_head *kill_list);
+ struct list_head *kill_list,
+ int *unpinned);
static void rds_iw_destroy_fastreg(struct rds_iw_mr_pool *pool, struct rds_iw_mr *ibmr);
static int rds_iw_get_device(struct rds_sock *rs, struct rds_iw_device **rds_iwdev, struct rdma_cm_id **cm_id)
@@ -499,7 +500,7 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
LIST_HEAD(unmap_list);
LIST_HEAD(kill_list);
unsigned long flags;
- unsigned int nfreed = 0, ncleaned = 0, free_goal;
+ unsigned int nfreed = 0, ncleaned = 0, unpinned = 0, free_goal;
int ret = 0;
rds_iw_stats_inc(s_iw_rdma_mr_pool_flush);
@@ -524,7 +525,8 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
* will be destroyed by the unmap function.
*/
if (!list_empty(&unmap_list)) {
- ncleaned = rds_iw_unmap_fastreg_list(pool, &unmap_list, &kill_list);
+ ncleaned = rds_iw_unmap_fastreg_list(pool, &unmap_list,
+ &kill_list, &unpinned);
/* If we've been asked to destroy all MRs, move those
* that were simply cleaned to the kill list */
if (free_all)
@@ -548,6 +550,7 @@ static int rds_iw_flush_mr_pool(struct rds_iw_mr_pool *pool, int free_all)
spin_unlock_irqrestore(&pool->list_lock, flags);
}
+ atomic_sub(unpinned, &pool->free_pinned);
atomic_sub(ncleaned, &pool->dirty_count);
atomic_sub(nfreed, &pool->item_count);
@@ -828,7 +831,8 @@ static void rds_iw_free_fastreg(struct rds_iw_mr_pool *pool,
static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
struct list_head *unmap_list,
- struct list_head *kill_list)
+ struct list_head *kill_list,
+ int *unpinned)
{
struct rds_iw_mapping *mapping, *next;
unsigned int ncleaned = 0;
@@ -855,6 +859,7 @@ static unsigned int rds_iw_unmap_fastreg_list(struct rds_iw_mr_pool *pool,
spin_lock_irqsave(&pool->list_lock, flags);
list_for_each_entry_safe(mapping, next, unmap_list, m_list) {
+ *unpinned += mapping->m_sg.len;
list_move(&mapping->m_list, &laundered);
ncleaned++;
}
^ permalink raw reply related
* Re: [net-next 1/9] igb: Update RXDCTL/TXDCTL configurations
From: Arnaud Lacombe @ 2011-09-29 17:41 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Alexander Duyck, netdev, gospo
In-Reply-To: <1316502690-25488-2-git-send-email-jeffrey.t.kirsher@intel.com>
Hi,
On Tue, Sep 20, 2011 at 3:11 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change cleans up the RXDCTL and TXDCTL configurations and optimizes RX
> performance by allowing back write-backs on all hardware other than 82576.
>
Where does this limitation comes from ? The "Intel 82576EB GbE
Controller - Programming Interface" from May 2011 advertises that both
the RXDCTL and TXDCTL register have a 5bit wide WTHRESH field.
Thanks,
- Arnaud
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb.h | 5 +++--
> drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++++--------------
> 2 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
> index 265e151..577fd3e 100644
> --- a/drivers/net/ethernet/intel/igb/igb.h
> +++ b/drivers/net/ethernet/intel/igb/igb.h
> @@ -100,11 +100,12 @@ struct vf_data_storage {
> */
> #define IGB_RX_PTHRESH 8
> #define IGB_RX_HTHRESH 8
> -#define IGB_RX_WTHRESH 1
> #define IGB_TX_PTHRESH 8
> #define IGB_TX_HTHRESH 1
> +#define IGB_RX_WTHRESH ((hw->mac.type == e1000_82576 && \
> + adapter->msix_entries) ? 1 : 4)
> #define IGB_TX_WTHRESH ((hw->mac.type == e1000_82576 && \
> - adapter->msix_entries) ? 1 : 16)
> + adapter->msix_entries) ? 1 : 16)
>
> /* this is the size past which hardware will drop packets when setting LPE=0 */
> #define MAXIMUM_ETHERNET_VLAN_SIZE 1522
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> index 3cb1bc9..aa78c10 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -2666,14 +2666,12 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
> struct igb_ring *ring)
> {
> struct e1000_hw *hw = &adapter->hw;
> - u32 txdctl;
> + u32 txdctl = 0;
> u64 tdba = ring->dma;
> int reg_idx = ring->reg_idx;
>
> /* disable the queue */
> - txdctl = rd32(E1000_TXDCTL(reg_idx));
> - wr32(E1000_TXDCTL(reg_idx),
> - txdctl & ~E1000_TXDCTL_QUEUE_ENABLE);
> + wr32(E1000_TXDCTL(reg_idx), 0);
> wrfl();
> mdelay(10);
>
> @@ -2685,7 +2683,7 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
>
> ring->head = hw->hw_addr + E1000_TDH(reg_idx);
> ring->tail = hw->hw_addr + E1000_TDT(reg_idx);
> - writel(0, ring->head);
> + wr32(E1000_TDH(reg_idx), 0);
> writel(0, ring->tail);
>
> txdctl |= IGB_TX_PTHRESH;
> @@ -3028,12 +3026,10 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> struct e1000_hw *hw = &adapter->hw;
> u64 rdba = ring->dma;
> int reg_idx = ring->reg_idx;
> - u32 srrctl, rxdctl;
> + u32 srrctl = 0, rxdctl = 0;
>
> /* disable the queue */
> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
> - wr32(E1000_RXDCTL(reg_idx),
> - rxdctl & ~E1000_RXDCTL_QUEUE_ENABLE);
> + wr32(E1000_RXDCTL(reg_idx), 0);
>
> /* Set DMA base address registers */
> wr32(E1000_RDBAL(reg_idx),
> @@ -3045,7 +3041,7 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> /* initialize head and tail */
> ring->head = hw->hw_addr + E1000_RDH(reg_idx);
> ring->tail = hw->hw_addr + E1000_RDT(reg_idx);
> - writel(0, ring->head);
> + wr32(E1000_RDH(reg_idx), 0);
> writel(0, ring->tail);
>
> /* set descriptor configuration */
> @@ -3076,13 +3072,12 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
> /* set filtering for VMDQ pools */
> igb_set_vmolr(adapter, reg_idx & 0x7, true);
>
> - /* enable receive descriptor fetching */
> - rxdctl = rd32(E1000_RXDCTL(reg_idx));
> - rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
> - rxdctl &= 0xFFF00000;
> rxdctl |= IGB_RX_PTHRESH;
> rxdctl |= IGB_RX_HTHRESH << 8;
> rxdctl |= IGB_RX_WTHRESH << 16;
> +
> + /* enable receive descriptor fetching */
> + rxdctl |= E1000_RXDCTL_QUEUE_ENABLE;
> wr32(E1000_RXDCTL(reg_idx), rxdctl);
> }
>
> --
> 1.7.6.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Catalin Marinas @ 2011-09-29 14:18 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Huajun Li, linux-mm@kvack.org, netdev, linux-kernel,
Tejun Heo
In-Reply-To: <alpine.DEB.2.00.1109290907450.9382@router.home>
On Thu, Sep 29, 2011 at 03:08:47PM +0100, Christoph Lameter wrote:
> On Wed, 28 Sep 2011, Catalin Marinas wrote:
>
> > I tried this but it's tricky. The problem is that the percpu pointer
> > returned by alloc_percpu() does not directly point to the per-cpu chunks
> > and kmemleak would report most percpu allocations as leaks. So far the
> > workaround is to simply mark the alloc_percpu() objects as never leaking
> > and at least we avoid false positives in other areas. See the patch
> > below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
> > as there are many alloc_percpu() calls before kmemleak is fully
> > initialised):
>
> Seems that kernel.org is out and so tejon wont be seeing these.
That's ok, I don't aim this at the upcoming merging window. I don't have
an alternative email address for him.
--
Catalin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Question about memory leak detector giving false positive report for net/core/flow.c
From: Christoph Lameter @ 2011-09-29 14:08 UTC (permalink / raw)
To: Catalin Marinas
Cc: Eric Dumazet, Huajun Li, linux-mm@kvack.org, netdev, linux-kernel,
Tejun Heo
In-Reply-To: <20110928172342.GH23559@e102109-lin.cambridge.arm.com>
On Wed, 28 Sep 2011, Catalin Marinas wrote:
> I tried this but it's tricky. The problem is that the percpu pointer
> returned by alloc_percpu() does not directly point to the per-cpu chunks
> and kmemleak would report most percpu allocations as leaks. So far the
> workaround is to simply mark the alloc_percpu() objects as never leaking
> and at least we avoid false positives in other areas. See the patch
> below (note that you have to increase the CONFIG_KMEMLEAK_EARLY_LOG_SIZE
> as there are many alloc_percpu() calls before kmemleak is fully
> initialised):
Seems that kernel.org is out and so tejon wont be seeing these.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] usbnet: add timestamping support
From: Michael Riesch @ 2011-09-29 14:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, oneukum
In-Reply-To: <20110928.032057.938343201578831873.davem@davemloft.net>
On Wed, 2011-09-28 at 03:20 -0400, David Miller wrote:
> Patch is severly corrupted by your email client.
>
> Correct this (see Documentation/email-clients.txt), send a test patch
> to yourself, and only resubmit this change when you can successfully
> apply a patch you send to youself.
Sorry about that. I switched to git-send-email and tested it. I hope it
works now.
Regards, Michael
^ permalink raw reply
* [patch] usbnet: add timestamping support
From: Michael Riesch @ 2011-09-29 14:06 UTC (permalink / raw)
To: netdev; +Cc: oneukum, davem, Michael Riesch
In order to make USB-to-Ethernet-adapters (depending on usbnet) support
timestamping, the "skb_defer_rx_timestamp" and "skb_tx_timestamp" function
calls are added.
Signed-off-by: Michael Riesch <michael@riesch.at>
---
drivers/net/usb/usbnet.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 2ab9b98..b57b57b 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -239,6 +239,10 @@ void usbnet_skb_return (struct usbnet *dev, struct sk_buff *skb)
netif_dbg(dev, rx_status, dev->net, "< rx, len %zu, type 0x%x\n",
skb->len + sizeof (struct ethhdr), skb->protocol);
memset (skb->cb, 0, sizeof (struct skb_data));
+
+ if (skb_defer_rx_timestamp(skb))
+ return;
+
status = netif_rx (skb);
if (status != NET_RX_SUCCESS)
netif_dbg(dev, rx_err, dev->net,
@@ -1071,6 +1075,8 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
unsigned long flags;
int retval;
+ skb_tx_timestamp(skb);
+
// some devices want funky USB-level framing, for
// win32 driver (usually) and/or hardware quirks
if (info->tx_fixup) {
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] net/flow: remove sleeping and deferral mechanism from flow_cache_flush
From: Benjamin Poirier @ 2011-09-29 13:24 UTC (permalink / raw)
To: Madalin Bucur; +Cc: eric.dumazet, netdev, davem, timo.teras
In-Reply-To: <1317056956-23644-1-git-send-email-madalin.bucur@freescale.com>
On 11-09-26 20:09, Madalin Bucur wrote:
> flow_cache_flush must not sleep as it can be called in atomic context;
> removed the schedule_work as the deferred processing lead to the flow
> cache gc never being actually run under heavy network load
>
> Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
> ---
> net/core/flow.c | 21 +++++++++------------
> 1 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/net/core/flow.c b/net/core/flow.c
> index 555a456..0950f97 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -14,7 +14,6 @@
> #include <linux/init.h>
> #include <linux/slab.h>
> #include <linux/smp.h>
> -#include <linux/completion.h>
> #include <linux/percpu.h>
> #include <linux/bitops.h>
> #include <linux/notifier.h>
> @@ -49,7 +48,6 @@ struct flow_cache_percpu {
> struct flow_flush_info {
> struct flow_cache *cache;
> atomic_t cpuleft;
> - struct completion completion;
> };
>
> struct flow_cache {
> @@ -100,7 +98,7 @@ static void flow_entry_kill(struct flow_cache_entry *fle)
> kmem_cache_free(flow_cachep, fle);
> }
>
> -static void flow_cache_gc_task(struct work_struct *work)
> +static void flow_cache_gc_task(void)
> {
> struct list_head gc_list;
> struct flow_cache_entry *fce, *n;
> @@ -113,7 +111,6 @@ static void flow_cache_gc_task(struct work_struct *work)
> list_for_each_entry_safe(fce, n, &gc_list, u.gc_list)
> flow_entry_kill(fce);
> }
> -static DECLARE_WORK(flow_cache_gc_work, flow_cache_gc_task);
>
> static void flow_cache_queue_garbage(struct flow_cache_percpu *fcp,
> int deleted, struct list_head *gc_list)
> @@ -123,7 +120,7 @@ static void flow_cache_queue_garbage(struct flow_cache_percpu *fcp,
> spin_lock_bh(&flow_cache_gc_lock);
> list_splice_tail(gc_list, &flow_cache_gc_list);
> spin_unlock_bh(&flow_cache_gc_lock);
> - schedule_work(&flow_cache_gc_work);
> + flow_cache_gc_task();
> }
> }
>
> @@ -320,8 +317,7 @@ static void flow_cache_flush_tasklet(unsigned long data)
>
> flow_cache_queue_garbage(fcp, deleted, &gc_list);
>
> - if (atomic_dec_and_test(&info->cpuleft))
> - complete(&info->completion);
> + atomic_dec(&info->cpuleft);
> }
>
> static void flow_cache_flush_per_cpu(void *data)
> @@ -339,22 +335,23 @@ static void flow_cache_flush_per_cpu(void *data)
> void flow_cache_flush(void)
> {
> struct flow_flush_info info;
> - static DEFINE_MUTEX(flow_flush_sem);
> + static DEFINE_SPINLOCK(flow_flush_lock);
>
> /* Don't want cpus going down or up during this. */
> get_online_cpus();
> - mutex_lock(&flow_flush_sem);
> + spin_lock_bh(&flow_flush_lock);
> info.cache = &flow_cache_global;
> atomic_set(&info.cpuleft, num_online_cpus());
> - init_completion(&info.completion);
>
> local_bh_disable();
local_bh_disable may as well be removed with the change to
spin_lock_bh() just above.
Also, I fail to see why bh_disable is needed for
flow_cache_flush_tasklet(). If you don't mind enlightening me, it'll be
appreciated.
Thanks,
-Ben
> smp_call_function(flow_cache_flush_per_cpu, &info, 0);
> flow_cache_flush_tasklet((unsigned long)&info);
> local_bh_enable();
>
> - wait_for_completion(&info.completion);
> - mutex_unlock(&flow_flush_sem);
> + while (atomic_read(&info.cpuleft) != 0)
> + cpu_relax();
> +
> + spin_unlock_bh(&flow_flush_lock);
> put_online_cpus();
> }
>
> --
> 1.7.0.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Network problem with bridge and virtualbox
From: William Thompson @ 2011-09-29 12:49 UTC (permalink / raw)
To: netdev
Please keep me in the CC as I am not subscribed.
I'm using a 64-bit kernel 3.0.0 and virtualbox 4.1.2.
My problem is that I cannot ping the host from a virtual machine.
My bridge is configured as follows:
# brctl addbr br0
# brctl setfd br0 0
# brctl stp br0 off
# ifconfig br0 10.2.3.1 netmask 255.255.255.0
In the virtual machine, it is set to use br0 as it's interface (bridge mode)
and it's IP is 10.2.3.10.
The host gets packets from the vm, but the vm does not receive packets back.
I have this same setup working on a 32-bit kernel 2.6.38.6 on another
machine with virtualbox 4.0.4.
I had a thought that the bridge on the host wasn't responding due to having
no ports configured so I added one of my spare ethernet cards to it as
follows:
# brctl addif br0 eth1
# ifconfig eth1 up
The card was plugged into a switch. After doing this, the vm still could not
talk to the host. I added a physical machine to the switch that eth1 was
connected to and configured it to 10.2.3.2. I was able to ping 10.2.3.2 but
not 10.2.3.1
^ permalink raw reply
* [PATCH v2 2/2] net/fec: add poll controller function for fec nic
From: jgq516 @ 2011-09-29 12:15 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, jgq516
In-Reply-To: <1317298557-2878-1-git-send-email-jgq516@gmail.com>
From: Xiao Jiang <jgq516@gmail.com>
Add poll controller function for fec nic.
Signed-off-by: Xiao Jiang <jgq516@gmail.com>
---
drivers/net/ethernet/freescale/fec.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 1794ea4..1124ce0 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -242,6 +242,7 @@ struct fec_enet_private {
int link;
int full_duplex;
struct completion mdio_done;
+ int irq[FEC_IRQ_NUM];
};
/* FEC MII MMFR bits definition */
@@ -1363,6 +1364,29 @@ fec_set_mac_address(struct net_device *ndev, void *p)
return 0;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * fec_poll_controller: FEC Poll controller function
+ * @dev: The FEC network adapter
+ *
+ * Polled functionality used by netconsole and others in non interrupt mode
+ *
+ */
+void fec_poll_controller(struct net_device *dev)
+{
+ int i;
+ struct fec_enet_private *fep = netdev_priv(dev);
+
+ for (i = 0; i < FEC_IRQ_NUM; i++) {
+ if (fep->irq[i] > 0) {
+ disable_irq(fep->irq[i]);
+ fec_enet_interrupt(fep->irq[i], dev);
+ enable_irq(fep->irq[i]);
+ }
+ }
+}
+#endif
+
static const struct net_device_ops fec_netdev_ops = {
.ndo_open = fec_enet_open,
.ndo_stop = fec_enet_close,
@@ -1373,6 +1397,9 @@ static const struct net_device_ops fec_netdev_ops = {
.ndo_tx_timeout = fec_timeout,
.ndo_set_mac_address = fec_set_mac_address,
.ndo_do_ioctl = fec_enet_ioctl,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = fec_poll_controller,
+#endif
};
/*
--
1.7.6.1
^ permalink raw reply related
* [PATCH v2 1/2] net/fec: replace hardcoded irq num with macro
From: jgq516 @ 2011-09-29 12:15 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, jgq516
From: Xiao Jiang <jgq516@gmail.com>
Don't use hardcoded irq num and replace it with
FEC_IRQ_NUM macro.
Signed-off-by: Xiao Jiang <jgq516@gmail.com>
---
The two patches are based on git://github.com/davem330/net-next.git
pls correct me if I still used wrong tree.
Thanks,
Xiao Jiang
drivers/net/ethernet/freescale/fec.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index cce78ce..1794ea4 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -177,6 +177,8 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
#define PKT_MINBUF_SIZE 64
#define PKT_MAXBLR_SIZE 1520
+/* This device has up to three irqs on some platforms */
+#define FEC_IRQ_NUM 3
/*
* The 5270/5271/5280/5282/532x RX control register also contains maximum frame
@@ -1540,8 +1542,7 @@ fec_probe(struct platform_device *pdev)
fec_reset_phy(pdev);
- /* This device has up to three irqs on some platforms */
- for (i = 0; i < 3; i++) {
+ for (i = 0; i < FEC_IRQ_NUM; i++) {
irq = platform_get_irq(pdev, i);
if (i && irq < 0)
break;
@@ -1586,7 +1587,7 @@ failed_init:
clk_disable(fep->clk);
clk_put(fep->clk);
failed_clk:
- for (i = 0; i < 3; i++) {
+ for (i = 0; i < FEC_IRQ_NUM; i++) {
irq = platform_get_irq(pdev, i);
if (irq > 0)
free_irq(irq, ndev);
--
1.7.6.1
^ permalink raw reply related
* Re: Antwort: Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Wolfgang Grandegger @ 2011-09-29 11:54 UTC (permalink / raw)
To: Thomas Wiedemann
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Oliver Hartkopp
In-Reply-To: <OF72B7C0BE.EE4FAB88-ONC125791A.004029CC-C125791A.004097EF-Npw8gZsewqCELgA04lAiVw@public.gmane.org>
Hi Thomas,
On 09/29/2011 01:46 PM, Thomas Wiedemann wrote:
> Hi Wolfgang,
> i just replaced peak_pci.c.
> The net-next-2.6 branch? Is that the one in the latest linux kernels? I'll
> try to find some time to test a new kernel.
Temporarily (kernel.org is still down) you can get the "net-next-2.6" as
shown below:
$ git clone git://github.com/davem330/net-next.git
The tree is maintained by David Miller and will show up mainline with
the next kernel release.
Thanks,
Wolfgang.
^ permalink raw reply
* Antwort: Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Thomas Wiedemann @ 2011-09-29 11:46 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Oliver Hartkopp
In-Reply-To: <4E844AFB.3020201-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hi Wolfgang,
i just replaced peak_pci.c.
The net-next-2.6 branch? Is that the one in the latest linux kernels? I'll
try to find some time to test a new kernel.
Thomas
Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org> schrieb am 29.09.2011 12:39:55:
> Hi Thomas,
>
> On 09/29/2011 11:21 AM, Thomas Wiedemann wrote:
> > I got access to another system with a 4 channel card and tested your
patch
> > (v1) within the Berlios socket-can SVN tree: it worked :)
>
> Hm, did the patch apply to the SVN tree? Any chance to test with David
> Miller's net-next-2.6 tree. Anyway, I'm quite sure now that the patch
> works fine on 4-channel cards as well.
>
> Thanks for your effort.
>
> Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Wolfgang Grandegger @ 2011-09-29 10:39 UTC (permalink / raw)
To: Thomas Wiedemann
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Oliver Hartkopp
In-Reply-To: <OFA1D2B7AC.618D2DB3-ONC125791A.0032F517-C125791A.00335871-Npw8gZsewqCELgA04lAiVw@public.gmane.org>
Hi Thomas,
On 09/29/2011 11:21 AM, Thomas Wiedemann wrote:
> I got access to another system with a 4 channel card and tested your patch
> (v1) within the Berlios socket-can SVN tree: it worked :)
Hm, did the patch apply to the SVN tree? Any chance to test with David
Miller's net-next-2.6 tree. Anyway, I'm quite sure now that the patch
works fine on 4-channel cards as well.
Thanks for your effort.
Wolfgang.
^ permalink raw reply
* COCA COLA AWARD!!
From: Diana Yicel Jimenez Agudelo @ 2011-09-29 10:02 UTC (permalink / raw)
Your Email-ID Has won Ј1,000,000.00 GBP from the Coca Cola Anniversary Award for claims send your details to email cocadpt2011@live.co.uk
^ permalink raw reply
* Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Thomas Wiedemann @ 2011-09-29 9:21 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: linux, Netdev, Oliver Hartkopp, SocketCAN Core Mailing List
In-Reply-To: <4E6F0891.8030600@grandegger.com>
I got access to another system with a 4 channel card and tested your patch
(v1) within the Berlios socket-can SVN tree: it worked :)
Thanks!
Thomas
Wolfgang Grandegger <wg@grandegger.com> schrieb am 13.09.2011 09:38:57:
> Hi Oliver,
>
> On 09/12/2011 05:49 PM, Oliver Hartkopp wrote:
> > On 09/09/11 17:20, Wolfgang Grandegger wrote:
> >
> >
> >>
> >>> I'll also test your driver on Monday.
> >>
> >> Thanks,
> >
> >
> > Hi Wolfgang,
> >
> > even if i only had my hardware-patched PEAK PCI ExpressCard hardware
here
> > (which is to be removed in the supported PCI device list due to the
missing
> > I2C initialization), i successfully tested your driver.
> >
> > Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> Thanks, I have just sent v2.
>
> > So let's wait for some feedback from Thomas, when he's back to the
office ;-)
>
> Yep, some testing on a 4 channel card would be nice.
>
> Wolfgang.
>
^ permalink raw reply
* Re: about bmac/mace/macmace/mac89x0/cs89x0: Move the Macintosh (Apple) drivers
From: Jeff Kirsher @ 2011-09-29 9:12 UTC (permalink / raw)
To: Sascha Hauer
Cc: Paul Mackerras, Russell Nelson, netdev, davem, Jaccon Bastiaansen
In-Reply-To: <20110928070439.GV31404@pengutronix.de>
On Wed, Sep 28, 2011 at 00:04, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi,
>
>> commit 8fb6b0908176704a3ea22005e8a9fa3ebf35b5be
>> Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Mon May 16 01:39:01 2011 -0700
>>
>> bmac/mace/macmace/mac89x0/cs89x0: Move the Macintosh (Apple) drivers
>>
>> Move the Apple drivers into driver/net/ethernet/apple/ and make the
>> necessary Kconfig and Makefile changes.
>
> This commit moves drivers/net/cs89x0.[ch] to drivers/net/ethernet/apple/.
>
> This is wrong. The cs89x0 driver is a general ISA driver and is also
> used on some embedded boards. This patch should only move drivers/net/mac89x0.c
> which basically is a driver for the same device but used on Macintosh.
>
> I think it should go to drivers/net/ethernet/cirrus instead.
>
> Sascha
>
Thanks Sasha, I am looking into the past emails on this to see if
there was a suggested reason that in be where it is at. I do agree
with you that it looks like it should be in
/drivers/net/ethernet/cirrus/, before making a patch to move it, I
want to double check all the previous emails I received to ensure that
there was a logic reason for placing it where it is.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Rongqing Li @ 2011-09-29 9:10 UTC (permalink / raw)
To: Yan, Zheng ; +Cc: netdev
In-Reply-To: <CAAM7YAmwXyORpFWhthX4iSEkBp7OANnZ8tHruEyN62Z3mnOdLw@mail.gmail.com>
On 09/29/2011 04:52 PM, Yan, Zheng wrote:
> On Thu, Sep 29, 2011 at 4:25 PM, Rongqing Li<rongqing.li@windriver.com> wrote:
>> On 09/29/2011 04:16 PM, Yan, Zheng wrote:
>>>
>>> I think the rcu_read_lock protects in6_dev->nd_parms.
>>>
>> It can not protect in6_dev->nd_parms.
>>
>> rcu_read_lock protects the data which is accessed by rcu_XXX,
>>
>
> I'm confused, why does neigh_parms_release() use call_rcu() to release nd_parms.
>
Same as idev, there is a reference on struct neigh_parms
which protects them
-Roy
^ permalink raw reply
* Re: [RFC] IPVS: secure_tcp does provide alternate state timeouts
From: Simon Horman @ 2011-09-29 9:01 UTC (permalink / raw)
To: Julian Anastasov; +Cc: lvs-devel, netdev, netfilter-devel
In-Reply-To: <alpine.LFD.2.00.1109291119420.1696@ja.ssi.bg>
On Thu, Sep 29, 2011 at 11:47:10AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 29 Sep 2011, Simon Horman wrote:
>
> > * Also reword the test to make it read more easily (to me)
> >
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > ---
> >
> > Julian, I don't see that IPVS currently implements alternate
> > timeouts for secure_tcp. Am I missing something?
>
> Yes, only states are changed. What is missing is a
> libipvs support to modify per-protocol timeouts because they
> are not exported to /proc anymore. As the states have name,
> may be we can implement timeout to be set as follows:
>
> ipvsadm --set-state-timeout -p TCP SYN 10
>
> Using 2 timeout tables just for secure_tcp is
> complicated and with the above control it is not needed.
Yes, I agree there is room for improvement.
I guess the best way forward is to use netlink
to allow per-state per-protocol timeout adjustment.
In the mean time, I'll queue this patch up as I think
its good that the documentation reflects the implementation.
>
> > ---
> > Documentation/networking/ipvs-sysctl.txt | 10 ++++------
> > 1 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
> > index 1dcdd49..13610e3 100644
> > --- a/Documentation/networking/ipvs-sysctl.txt
> > +++ b/Documentation/networking/ipvs-sysctl.txt
> > @@ -140,13 +140,11 @@ nat_icmp_send - BOOLEAN
> > secure_tcp - INTEGER
> > 0 - disabled (default)
> >
> > - The secure_tcp defense is to use a more complicated state
> > - transition table and some possible short timeouts of each
> > - state. In the VS/NAT, it delays the entering the ESTABLISHED
> > - until the real server starts to send data and ACK packet
> > - (after 3-way handshake).
> > + The secure_tcp defense is to use a more complicated TCP state
> > + transition table. For VS/NAT, it also delays entering the
> > + TCP ESTABLISHED state until the three way handshake is completed.
> >
> > - The value definition is the same as that of drop_entry or
> > + The value definition is the same as that of drop_entry and
> > drop_packet.
> >
> > sync_threshold - INTEGER
> > --
> > 1.7.5.4
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Yan, Zheng @ 2011-09-29 8:52 UTC (permalink / raw)
To: Rongqing Li; +Cc: netdev
In-Reply-To: <4E842B93.3010203@windriver.com>
On Thu, Sep 29, 2011 at 4:25 PM, Rongqing Li <rongqing.li@windriver.com> wrote:
> On 09/29/2011 04:16 PM, Yan, Zheng wrote:
>>
>> I think the rcu_read_lock protects in6_dev->nd_parms.
>>
> It can not protect in6_dev->nd_parms.
>
> rcu_read_lock protects the data which is accessed by rcu_XXX,
>
I'm confused, why does neigh_parms_release() use call_rcu() to release nd_parms.
^ permalink raw reply
* Re: [PATCH] Ipv6: Delete rcu_read_lock
From: Rongqing Li @ 2011-09-29 8:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1317285859.2855.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 09/29/2011 04:44 PM, Eric Dumazet wrote:
> A good changelog and patch title are required.
>
> Something like :
>
> [PATCH net-next] ipv6: remove a rcu_read_lock in ndisc_constructor
>
> in6_dev_get(dev) takes a reference on struct inet6_dev, we dont need rcu
> locking in ndisc_constructor()
>
>
Thank you, I will resend it.
-Roy
^ permalink raw reply
* Re: [RFC] IPVS: secure_tcp does provide alternate state timeouts
From: Julian Anastasov @ 2011-09-29 8:47 UTC (permalink / raw)
To: Simon Horman; +Cc: lvs-devel, netdev, netfilter-devel
In-Reply-To: <1317281111-23985-1-git-send-email-horms@verge.net.au>
Hello,
On Thu, 29 Sep 2011, Simon Horman wrote:
> * Also reword the test to make it read more easily (to me)
>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> Julian, I don't see that IPVS currently implements alternate
> timeouts for secure_tcp. Am I missing something?
Yes, only states are changed. What is missing is a
libipvs support to modify per-protocol timeouts because they
are not exported to /proc anymore. As the states have name,
may be we can implement timeout to be set as follows:
ipvsadm --set-state-timeout -p TCP SYN 10
Using 2 timeout tables just for secure_tcp is
complicated and with the above control it is not needed.
> ---
> Documentation/networking/ipvs-sysctl.txt | 10 ++++------
> 1 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
> index 1dcdd49..13610e3 100644
> --- a/Documentation/networking/ipvs-sysctl.txt
> +++ b/Documentation/networking/ipvs-sysctl.txt
> @@ -140,13 +140,11 @@ nat_icmp_send - BOOLEAN
> secure_tcp - INTEGER
> 0 - disabled (default)
>
> - The secure_tcp defense is to use a more complicated state
> - transition table and some possible short timeouts of each
> - state. In the VS/NAT, it delays the entering the ESTABLISHED
> - until the real server starts to send data and ACK packet
> - (after 3-way handshake).
> + The secure_tcp defense is to use a more complicated TCP state
> + transition table. For VS/NAT, it also delays entering the
> + TCP ESTABLISHED state until the three way handshake is completed.
>
> - The value definition is the same as that of drop_entry or
> + The value definition is the same as that of drop_entry and
> drop_packet.
>
> sync_threshold - INTEGER
> --
> 1.7.5.4
Regards
--
Julian Anastasov <ja@ssi.bg>
^ 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