* [net-next 1/1] iwmc3200top: revamp fw name handling
From: Tomas Winkler @ 2009-11-18 23:55 UTC (permalink / raw)
To: davem, netdev, linux-mmc
Cc: yi.zhu, inaky.perez-gonzalez, guy.cohen, ron.rindjunsky,
Tomas Winkler
1. define macro for handling firmware api version
2. add MODULE_FIRMWARE
3. cleanup iwmct_fw_load style
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
drivers/misc/iwmc3200top/fw-download.c | 24 ++++++++++--------------
drivers/misc/iwmc3200top/iwmc3200top.h | 3 +++
drivers/misc/iwmc3200top/main.c | 1 +
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/misc/iwmc3200top/fw-download.c b/drivers/misc/iwmc3200top/fw-download.c
index 33cb693..50d431e 100644
--- a/drivers/misc/iwmc3200top/fw-download.c
+++ b/drivers/misc/iwmc3200top/fw-download.c
@@ -291,35 +291,31 @@ static int iwmct_kick_fw(struct iwmct_priv *priv, bool jump)
int iwmct_fw_load(struct iwmct_priv *priv)
{
- const struct firmware *raw = NULL;
- __le32 addr;
- size_t len;
+ const u8 *fw_name = FW_NAME(FW_API_VER);
+ const struct firmware *raw;
const u8 *pdata;
- const u8 *name = "iwmc3200top.1.fw";
- int ret = 0;
+ size_t len;
+ __le32 addr;
+ int ret;
/* clear parser struct */
memset(&priv->parser, 0, sizeof(struct iwmct_parser));
- if (!name) {
- ret = -EINVAL;
- goto exit;
- }
/* get the firmware */
- ret = request_firmware(&raw, name, &priv->func->dev);
+ ret = request_firmware(&raw, fw_name, &priv->func->dev);
if (ret < 0) {
LOG_ERROR(priv, FW_DOWNLOAD, "%s request_firmware failed %d\n",
- name, ret);
+ fw_name, ret);
goto exit;
}
if (raw->size < sizeof(struct iwmct_fw_sec_hdr)) {
LOG_ERROR(priv, FW_DOWNLOAD, "%s smaller then (%zd) (%zd)\n",
- name, sizeof(struct iwmct_fw_sec_hdr), raw->size);
+ fw_name, sizeof(struct iwmct_fw_sec_hdr), raw->size);
goto exit;
}
- LOG_INFO(priv, FW_DOWNLOAD, "Read firmware '%s'\n", name);
+ LOG_INFO(priv, FW_DOWNLOAD, "Read firmware '%s'\n", fw_name);
ret = iwmct_fw_parser_init(priv, raw->data, raw->size, priv->trans_len);
if (ret < 0) {
@@ -339,7 +335,7 @@ int iwmct_fw_load(struct iwmct_priv *priv)
while (iwmct_parse_next_section(priv, &pdata, &len, &addr)) {
if (iwmct_download_section(priv, pdata, len, addr)) {
LOG_ERROR(priv, FW_DOWNLOAD,
- "%s download section failed\n", name);
+ "%s download section failed\n", fw_name);
ret = -EIO;
goto exit;
}
diff --git a/drivers/misc/iwmc3200top/iwmc3200top.h b/drivers/misc/iwmc3200top/iwmc3200top.h
index f572fcf..43bd510 100644
--- a/drivers/misc/iwmc3200top/iwmc3200top.h
+++ b/drivers/misc/iwmc3200top/iwmc3200top.h
@@ -30,6 +30,9 @@
#include <linux/workqueue.h>
#define DRV_NAME "iwmc3200top"
+#define FW_API_VER 1
+#define _FW_NAME(api) DRV_NAME "." #api ".fw"
+#define FW_NAME(api) _FW_NAME(api)
#define IWMC_SDIO_BLK_SIZE 256
#define IWMC_DEFAULT_TR_BLK 64
diff --git a/drivers/misc/iwmc3200top/main.c b/drivers/misc/iwmc3200top/main.c
index 02b3dad..fafcaa4 100644
--- a/drivers/misc/iwmc3200top/main.c
+++ b/drivers/misc/iwmc3200top/main.c
@@ -47,6 +47,7 @@ MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
MODULE_VERSION(DRIVER_VERSION);
MODULE_LICENSE("GPL");
MODULE_AUTHOR(DRIVER_COPYRIGHT);
+MODULE_FIRMWARE(FW_NAME(FW_API_VER));
/*
* This workers main task is to wait for OP_OPR_ALIVE
--
1.6.0.6
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: Eric W. Biederman @ 2009-11-18 23:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Eric Dumazet, linux-kernel, netdev, David Miller,
Stephen Hemminger, Herbert Xu, Patrick McHardy, Patrick Mullaney,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <200911182332.56309.arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> On Wednesday 18 November 2009 14:37:50 Eric W. Biederman wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>> > On Wednesday 18 November 2009, Eric Dumazet wrote:
>> >>
>> >> Why do you drop dst here ?
>> >>
>> >> It seems strange, since this driver specifically masks out IFF_XMIT_DST_RELEASE
>> >> in its macvlan_setup() :
>> >>
>> >> dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
>
> It seems that we should never drop dst then. We either forward the frame to
> netif_rx or to dev_queue_xmit, and from how I read it now, we want to keep
> the dst in both cases.
When we loop back on our selves we certainly need to have dst clear because
we don't know how to cache routes through multiple network namespaces. It
might be handy if we had those but that is a problem for another day.
>> Please copy and ideally share code with the veth driver for recycling a skb.
>> There are bunch of little things you have to do to get it right. As I recally
>> I was missing a few details in my original patch.
>
> Are you thinking of something like the patch below? I haven't had the chance
> to test this, but one thing it does is to handle the internal forwarding
> differently from the receive path.
Yes. That is a bit more sharing than I had anticipated, but it looks like
it works.
Eric
^ permalink raw reply
* [PATCH net-next-2.6] netsched: Allow var_sk_bound_if meta to work on all namespaces
From: Eric Dumazet @ 2009-11-18 23:58 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
This fix can probably wait 2.6.33, or should use another patch
if needed in 2.6.32 (no get_dev_by_index_rcu() before 2.6.33)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/sched/em_meta.c b/net/sched/em_meta.c
index 8e8d836..24dce8b 100644
--- a/net/sched/em_meta.c
+++ b/net/sched/em_meta.c
@@ -310,7 +310,8 @@ META_COLLECTOR(var_sk_bound_if)
struct net_device *dev;
rcu_read_lock();
- dev = dev_get_by_index_rcu(&init_net, skb->sk->sk_bound_dev_if);
+ dev = dev_get_by_index_rcu(sock_net(skb->sk),
+ skb->sk->sk_bound_dev_if);
*err = var_dev(dev, dst);
rcu_read_unlock();
}
^ permalink raw reply related
* Re: [net-next-2.6 PATCH 2/3] ixgbe: Set MSI-X vectors to NOBALANCING and set affinity
From: Peter P Waskiewicz Jr @ 2009-11-19 1:14 UTC (permalink / raw)
To: David Miller
Cc: bhutchings@solarflare.com, Kirsher, Jeffrey T, gospo@redhat.com,
netdev@vger.kernel.org
In-Reply-To: <20091118.115039.41419484.davem@davemloft.net>
On Wed, 2009-11-18 at 11:50 -0800, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Wed, 18 Nov 2009 19:46:10 +0000
>
> > When forwarding between 2 ports it can be beneficial to match the
> > affinity of each port's TX interrupts with the other port's RX
> > interrupts. Obviously this is not the case when the system is
> > acting as an endpoint, and the situation is presumably more complex
> > when forwarding between >2 ports.
>
> Yes, but tricks like that won't be necessary with changes that Eric
> Dumazet said he'd work on soon, wherein SKB frees always get scheduled
> to occur on the cpu where allocation occured.
>
We actually just submitted a patch that pairs our Rx queue 0 and Tx
queue 0 (up until the number of queues) onto the same MSI-X interrupt.
Arjan had indicated though he'd still like to make irqbalance smart
enough to distinguish Rx and Tx from one another, regardless if the
drivers just move to queue pairs or not. I don't care either way, since
my queues are now paired.
-PJ
^ permalink raw reply
* Re: [GIT]: Networking
From: David Miller @ 2009-11-19 5:23 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <alpine.LFD.2.00.0911181455260.2793@localhost.localdomain>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 18 Nov 2009 14:59:36 -0800 (PST)
> Anyway, I do seem to get a proper subset, _and_ the stuff I don't get seem
> to be old stuff I already got earlier, so I think everything is fine. But
> you should double-check, because my diffstat/shortlog doesn't match yours
> due to you apparently having included data from previous pull requests..
I forgot to update my origin before generating the pull request, sorry
about that.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] ixgbe: Set MSI-X vectors to NOBALANCING and set affinity
From: David Miller @ 2009-11-19 6:28 UTC (permalink / raw)
To: peter.p.waskiewicz.jr; +Cc: bhutchings, jeffrey.t.kirsher, gospo, netdev
In-Reply-To: <1258593299.3103.0.camel@ppwaskie-mobl2>
From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Date: Wed, 18 Nov 2009 17:14:57 -0800
> We actually just submitted a patch that pairs our Rx queue 0 and Tx
> queue 0 (up until the number of queues) onto the same MSI-X
> interrupt. Arjan had indicated though he'd still like to make
> irqbalance smart enough to distinguish Rx and Tx from one another,
> regardless if the drivers just move to queue pairs or not. I don't
> care either way, since my queues are now paired.
Ok.
^ permalink raw reply
* Re: [PATCH net-next-2.6] netsched: Allow var_sk_bound_if meta to work on all namespaces
From: David Miller @ 2009-11-19 6:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4B048A41.7090103@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Nov 2009 00:58:57 +0100
> This fix can probably wait 2.6.33, or should use another patch
> if needed in 2.6.32 (no get_dev_by_index_rcu() before 2.6.33)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
I'll add this to net-next-2.6, thanks Eric.
^ permalink raw reply
* Re: Shared i2c adapter locking
From: David Miller @ 2009-11-19 6:53 UTC (permalink / raw)
To: sfr-3FnU+UHB4dNDw9hX6IcOSA
Cc: khali-PUYAD+kWke1g9hUCZPvPmw, bhutchings-s/n/eUQHGBpZroRs9YW3xA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mika.kuoppala-xNZwKgViW5gAvxtiuMwx3w,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091118075917.9ac0248c.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
From: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
Date: Wed, 18 Nov 2009 07:59:17 +1100
>> If you did and something is still not clear, please let me know. My
>> understanding is that the action token is in David's hands now.
>
> OK, I will await developments :-)
I just took care of all of this.
Thanks.
^ permalink raw reply
* Re: Shared i2c adapter locking
From: Stephen Rothwell @ 2009-11-19 7:05 UTC (permalink / raw)
To: David Miller
Cc: khali, bhutchings, netdev, linux-next, linux-kernel,
mika.kuoppala, linux-i2c
In-Reply-To: <20091118.225332.18917545.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
Hi Dave,
On Wed, 18 Nov 2009 22:53:32 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 18 Nov 2009 07:59:17 +1100
>
> >> If you did and something is still not clear, please let me know. My
> >> understanding is that the action token is in David's hands now.
> >
> > OK, I will await developments :-)
>
> I just took care of all of this.
Excellent, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: request_irq - Remove unnecessary leading & from second arg
From: David Miller @ 2009-11-19 7:29 UTC (permalink / raw)
To: joe; +Cc: netdev, julia, ebiederm
In-Reply-To: <1258587958.24178.222.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Wed, 18 Nov 2009 15:45:57 -0800
> Not as fancy as coccinelle. Checkpatch errors ignored.
> Compile tested allyesconfig x86, not all files compiled.
>
> grep -rPl --include=*.[ch] "\brequest_irq\s*\([^,\)]+,\s*\&" drivers/net | while read file ; do \
> perl -i -e 'local $/; while (<>) { s@(\brequest_irq\s*\([^,\)]+,\s*)\&@\1@g ; print ; }' $file ;\
> done
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next 1/1] iwmc3200top: revamp fw name handling
From: David Miller @ 2009-11-19 7:30 UTC (permalink / raw)
To: tomas.winkler
Cc: netdev, linux-mmc, yi.zhu, inaky.perez-gonzalez, guy.cohen,
ron.rindjunsky
In-Reply-To: <1258588519-7939-1-git-send-email-tomas.winkler@intel.com>
From: Tomas Winkler <tomas.winkler@intel.com>
Date: Thu, 19 Nov 2009 01:55:19 +0200
> 1. define macro for handling firmware api version
> 2. add MODULE_FIRMWARE
> 3. cleanup iwmct_fw_load style
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] X25: Enable setting of cause and diagnostic fields
From: David Miller @ 2009-11-19 7:30 UTC (permalink / raw)
To: andrew.hendry; +Cc: netdev, linux-x25, linux-kernel
In-Reply-To: <d45a3acc0911181524t58a87d07s42930bda765a97d7@mail.gmail.com>
From: andrew hendry <andrew.hendry@gmail.com>
Date: Thu, 19 Nov 2009 10:24:01 +1100
> Adds SIOCX25SCAUSEDIAG, allowing X.25 programs to set the cause and
> diagnostic fields.
> Normally used to indicate status upon closing connections.
>
> Signed-off-by: Andrew Hendry <andrew.hendry@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 1/2] stmmac: fixed a compilation error when use the external timer
From: Giuseppe CAVALLARO @ 2009-11-19 7:42 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/stmmac_timer.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_timer.c b/drivers/net/stmmac/stmmac_timer.c
index b838c65..679f61f 100644
--- a/drivers/net/stmmac/stmmac_timer.c
+++ b/drivers/net/stmmac/stmmac_timer.c
@@ -63,7 +63,7 @@ int stmmac_open_ext_timer(struct net_device *dev, struct stmmac_timer *tm)
stmmac_rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
if (stmmac_rtc == NULL) {
- pr_error("open rtc device failed\n");
+ pr_err("open rtc device failed\n");
return -ENODEV;
}
@@ -71,7 +71,7 @@ int stmmac_open_ext_timer(struct net_device *dev, struct stmmac_timer *tm)
/* Periodic mode is not supported */
if ((rtc_irq_set_freq(stmmac_rtc, &stmmac_task, tm->freq) < 0)) {
- pr_error("set periodic failed\n");
+ pr_err("set periodic failed\n");
rtc_irq_unregister(stmmac_rtc, &stmmac_task);
rtc_class_close(stmmac_rtc);
return -1;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/2] stmmac: do not fail when the timer cannot be used.
From: Giuseppe CAVALLARO @ 2009-11-19 7:42 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
In-Reply-To: <1258616528-739-1-git-send-email-peppe.cavallaro@st.com>
If the external timer cannot be used the driver
will continue to work without mitigation.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/stmmac_main.c | 52 ++++++++++++++++++++----------------
drivers/net/stmmac/stmmac_timer.h | 1 +
2 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index c2f14dc..e63bf93 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -416,13 +416,8 @@ static void init_dma_desc_rings(struct net_device *dev)
unsigned int txsize = priv->dma_tx_size;
unsigned int rxsize = priv->dma_rx_size;
unsigned int bfsize = priv->dma_buf_sz;
- int buff2_needed = 0;
- int dis_ic = 0;
+ int buff2_needed = 0, dis_ic = 0;
-#ifdef CONFIG_STMMAC_TIMER
- /* Using Timers disable interrupts on completion for the reception */
- dis_ic = 1;
-#endif
/* Set the Buffer size according to the MTU;
* indeed, in case of jumbo we need to bump-up the buffer sizes.
*/
@@ -437,6 +432,11 @@ static void init_dma_desc_rings(struct net_device *dev)
else
bfsize = DMA_BUFFER_SIZE;
+#ifdef CONFIG_STMMAC_TIMER
+ /* Disable interrupts on completion for the reception if timer is on */
+ if (likely(priv->tm->enable))
+ dis_ic = 1;
+#endif
/* If the MTU exceeds 8k so use the second buffer in the chain */
if (bfsize >= BUF_SIZE_8KiB)
buff2_needed = 1;
@@ -809,20 +809,22 @@ static void stmmac_tx(struct stmmac_priv *priv)
static inline void stmmac_enable_irq(struct stmmac_priv *priv)
{
-#ifndef CONFIG_STMMAC_TIMER
- writel(DMA_INTR_DEFAULT_MASK, priv->dev->base_addr + DMA_INTR_ENA);
-#else
- priv->tm->timer_start(tmrate);
+#ifdef CONFIG_STMMAC_TIMER
+ if (likely(priv->tm->enable))
+ priv->tm->timer_start(tmrate);
+ else
#endif
+ writel(DMA_INTR_DEFAULT_MASK, priv->dev->base_addr + DMA_INTR_ENA);
}
static inline void stmmac_disable_irq(struct stmmac_priv *priv)
{
-#ifndef CONFIG_STMMAC_TIMER
- writel(0, priv->dev->base_addr + DMA_INTR_ENA);
-#else
- priv->tm->timer_stop();
+#ifdef CONFIG_STMMAC_TIMER
+ if (likely(priv->tm->enable))
+ priv->tm->timer_stop();
+ else
#endif
+ writel(0, priv->dev->base_addr + DMA_INTR_ENA);
}
static int stmmac_has_work(struct stmmac_priv *priv)
@@ -1031,22 +1033,23 @@ static int stmmac_open(struct net_device *dev)
}
#ifdef CONFIG_STMMAC_TIMER
- priv->tm = kmalloc(sizeof(struct stmmac_timer *), GFP_KERNEL);
+ priv->tm = kzalloc(sizeof(struct stmmac_timer *), GFP_KERNEL);
if (unlikely(priv->tm == NULL)) {
pr_err("%s: ERROR: timer memory alloc failed \n", __func__);
return -ENOMEM;
}
priv->tm->freq = tmrate;
- /* Test if the HW timer can be actually used.
- * In case of failure continue with no timer. */
+ /* Test if the external timer can be actually used.
+ * In case of failure continue without timer. */
if (unlikely((stmmac_open_ext_timer(dev, priv->tm)) < 0)) {
- pr_warning("stmmaceth: cannot attach the HW timer\n");
+ pr_warning("stmmaceth: cannot attach the external timer.\n");
tmrate = 0;
priv->tm->freq = 0;
priv->tm->timer_start = stmmac_no_timer_started;
priv->tm->timer_stop = stmmac_no_timer_stopped;
- }
+ } else
+ priv->tm->enable = 1;
#endif
/* Create and initialize the TX/RX descriptors chains. */
@@ -1322,9 +1325,11 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
/* Interrupt on completition only for the latest segment */
priv->mac_type->ops->close_tx_desc(desc);
+
#ifdef CONFIG_STMMAC_TIMER
- /* Clean IC while using timers */
- priv->mac_type->ops->clear_tx_ic(desc);
+ /* Clean IC while using timer */
+ if (likely(priv->tm->enable))
+ priv->mac_type->ops->clear_tx_ic(desc);
#endif
/* To avoid raise condition */
priv->mac_type->ops->set_tx_owner(first);
@@ -2028,7 +2033,8 @@ static int stmmac_suspend(struct platform_device *pdev, pm_message_t state)
#ifdef CONFIG_STMMAC_TIMER
priv->tm->timer_stop();
- dis_ic = 1;
+ if (likely(priv->tm->enable))
+ dis_ic = 1;
#endif
napi_disable(&priv->napi);
@@ -2037,7 +2043,7 @@ static int stmmac_suspend(struct platform_device *pdev, pm_message_t state)
stmmac_dma_stop_rx(dev->base_addr);
/* Clear the Rx/Tx descriptors */
priv->mac_type->ops->init_rx_desc(priv->dma_rx,
- priv->dma_rx_size, dis_ic);
+ priv->dma_rx_size, dis_ic);
priv->mac_type->ops->init_tx_desc(priv->dma_tx,
priv->dma_tx_size);
diff --git a/drivers/net/stmmac/stmmac_timer.h b/drivers/net/stmmac/stmmac_timer.h
index f795cae..6863590 100644
--- a/drivers/net/stmmac/stmmac_timer.h
+++ b/drivers/net/stmmac/stmmac_timer.h
@@ -26,6 +26,7 @@ struct stmmac_timer {
void (*timer_start) (unsigned int new_freq);
void (*timer_stop) (void);
unsigned int freq;
+ unsigned int enable;
};
/* Open the HW timer device and return 0 in case of success */
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] rps: core implementation
From: Jarek Poplawski @ 2009-11-19 8:08 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <65634d660911160843j3df398f2w876044083181cfcd@mail.gmail.com>
On 16-11-2009 17:43, Tom Herbert wrote:
> On Mon, Nov 16, 2009 at 3:19 AM, David Miller <davem@davemloft.net> wrote:
>> From: Tom Herbert <therbert@google.com>
>> Date: Tue, 10 Nov 2009 22:53:17 -0800
>>
>>> + /* Schedule NAPI for backlog device */
>>> + if (napi_schedule_prep(&queue->backlog)) {
>>> + if (cpu != smp_processor_id()) {
>>> + cpu_set(cpu,
>>> + get_cpu_var(rps_remote_softirq_cpus));
>>> + __raise_softirq_irqoff(NET_RPS_SOFTIRQ);
>>> + } else
>>> + __napi_schedule(&queue->backlog);
>>> + }
>>> + goto enqueue;
>> {,__}send_remote_softirq() doesn't work? :-)
>>
> NET_RPS_SOFTIRQ is intended to provide coalescing of IPIs.
It seems calling net_rps_action() at the end of net_rx_action() should
do (mostly) the same, at least for napi drivers. And I'm not sure it's
worth to add a new softirq because of non-napis.
Jarek P.
^ permalink raw reply
* [RFC] gianfar: multi queue stuff not complete
From: Eric Dumazet @ 2009-11-19 8:28 UTC (permalink / raw)
To: David S. Miller, Sandeep Gopalpet; +Cc: Linux Netdev List
I noticed gianfar got multiqueue support recently, but it still
updates dev->stats.{tx_bytes|tx_packets|tx_dropped} without proper locking
(several cpus could update stats at same time while xmitting on different tx queues)
It should use txq->{tx_bytes|tx_packets|tx_dropped} to avoid wrong tx stats
I cooked following preliminar patch but its only for discussion, because I
dont know yet how to transform dev->stats.tx_dropped++; in gfar_error(),
and also because I cannot compile this driver on my dev machine.
(if a driver uses txq->tx... counters, it must not use any dev->stats.{tx_bytes|tx_packets|tx_dropped}
that are overwritten by dev_txq_stats_fold(). Or we could change dev_txq_stats_fold() logic
to get a mask of what fields a drivers updates in txq-> or dev->stats
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 16def13..8fe38aa 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1937,7 +1937,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
/* Update transmit stats */
- dev->stats.tx_bytes += skb->len;
+ txq->tx_bytes += skb->len;
+ txq->tx_packets++;
txbdp = txbdp_start = tx_queue->cur_tx;
@@ -2295,8 +2296,6 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
tx_queue->skb_dirtytx = skb_dirtytx;
tx_queue->dirty_tx = bdp;
- dev->stats.tx_packets += howmany;
-
return howmany;
}
^ permalink raw reply related
* [PATCH 1/3] hso: memory leak in hso_serial_common_free()
From: Martin Schiller @ 2009-11-19 8:43 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch fixes a memory leak in the hso_serial_common_free() function.
The tx_buffer of a serial device was never freed here.
Signed-off-by: Martin Schiller <mschiller@tdt.de>
---
--- linux-2.6.32-rc7-git3/drivers/net/usb/hso.c.orig 2009-11-19 08:54:08.000000000 +0100
+++ linux-2.6.32-rc7-git3/drivers/net/usb/hso.c 2009-11-19 09:04:29.000000000 +0100
@@ -2296,6 +2296,7 @@ static void hso_serial_common_free(struc
/* unlink and free TX URB */
usb_free_urb(serial->tx_urb);
kfree(serial->tx_data);
+ kfree(serial->tx_buffer);
}
static int hso_serial_common_create(struct hso_serial *serial, int num_urbs,
^ permalink raw reply
* [PATCH 2/3] hso: memory leak in hso_free_net_device()
From: Martin Schiller @ 2009-11-19 8:44 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch fixes a memory leak in the hso_free_net_device() function.
The structure hso_net will be freed by free_netdev(). So, the rx/tx urbs
and buffers must be freed before free_netdev() is called.
Signed-off-by: Martin Schiller <mschiller@tdt.de>
---
kmemleak still finds 1 remaining leak, but I can't find it.
Maybe someone else has an idea for this:
unreferenced object 0xce461130 (size 32):
comm "khubd", pid 1105, jiffies 17464
backtrace:
[<c10745b6>] create_object+0xe6/0x210
[<c10747d7>] kmemleak_alloc+0x27/0x60
[<c1071b0d>] kmem_cache_alloc+0xcd/0x120
[<d0ba29a7>] hso_create_net_device+0x207/0x420 [hso]
[<d0ba30c7>] hso_probe+0x417/0x690 [hso]
[<d0998103>] usb_probe_interface+0x83/0x170 [usbcore]
[<c113f9e2>] driver_probe_device+0x62/0x140
[<c113fb81>] __device_attach+0x41/0x50
[<c113f098>] bus_for_each_drv+0x48/0x70
[<c113fc2d>] device_attach+0x6d/0x80
[<c113eeed>] bus_probe_device+0x1d/0x40
[<c113da66>] device_add+0x436/0x4f0
[<d0997654>] usb_set_configuration+0x424/0x5c0 [usbcore]
[<d099e68e>] generic_probe+0x2e/0xa0 [usbcore]
[<d09979cf>] usb_probe_device+0x1f/0x30 [usbcore]
[<c113f9e2>] driver_probe_device+0x62/0x140
--- linux-2.6.32-rc7-git3/drivers/net/usb/hso.c.orig 2009-11-19 09:04:29.000000000 +0100
+++ linux-2.6.32-rc7-git3/drivers/net/usb/hso.c 2009-11-19 09:08:17.000000000 +0100
@@ -2423,7 +2423,6 @@ static void hso_free_net_device(struct h
if (hso_net->net) {
unregister_netdev(hso_net->net);
- free_netdev(hso_net->net);
}
/* start freeing */
@@ -2436,6 +2435,10 @@ static void hso_free_net_device(struct h
kfree(hso_net->mux_bulk_tx_buf);
hso_net->mux_bulk_tx_buf = NULL;
+ if (hso_net->net) {
+ free_netdev(hso_net->net);
+ }
+
kfree(hso_dev);
}
^ permalink raw reply
* [PATCH 3/3] hso: Fix interface order/creation when disabled_net=1
From: Martin Schiller @ 2009-11-19 8:44 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch stops the useless creation of an serial ttyHS<x> for the
Network Port, when disable_net=1 is set. By that, the order of the
ttyHS<x> is always the same, regardless if disable_net is set or not.
Signed-off-by: Martin Schiller <mschiller@tdt.de>
---
--- linux-2.6.32-rc7-git3/drivers/net/usb/hso.c.orig 2009-11-19 09:08:17.000000000 +0100
+++ linux-2.6.32-rc7-git3/drivers/net/usb/hso.c 2009-11-19 09:10:36.000000000 +0100
@@ -2984,9 +2984,10 @@ static int hso_probe(struct usb_interfac
case HSO_INTF_BULK:
/* It's a regular bulk interface */
- if (((port_spec & HSO_PORT_MASK) == HSO_PORT_NETWORK)
- && !disable_net)
+ if ((port_spec & HSO_PORT_MASK) == HSO_PORT_NETWORK) {
+ if (!disable_net)
hso_dev = hso_create_net_device(interface, port_spec);
+ }
else
hso_dev =
hso_create_bulk_serial_device(interface, port_spec);
^ permalink raw reply
* [net-next-2.6 PATCH] be2net:Patch to flash redboot section while firmware update.
From: Sarveshwar Bandi @ 2009-11-19 8:48 UTC (permalink / raw)
To: netdev; +Cc: davem
Please apply patch to update redboot section while firmware update. Code
checks if section needs to be updated before actually doing it.
Signed-off-by: Sarveshwar Bandi <sarveshwarb@serverengines.com>
---
drivers/net/benet/be_cmds.c | 29 +++++++++++++++++++++++++++++
drivers/net/benet/be_cmds.h | 2 ++
drivers/net/benet/be_hw.h | 5 +++++
drivers/net/benet/be_main.c | 31 +++++++++++++++++++++++++++++++
4 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index cc75dd0..808ad0d 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1251,3 +1251,32 @@ int be_cmd_write_flashrom(struct be_adap
spin_unlock_bh(&adapter->mcc_lock);
return status;
}
+
+int be_cmd_get_flash_crc(struct be_adapter *adapter, u8 *flashed_crc)
+{
+ struct be_mcc_wrb *wrb;
+ struct be_cmd_write_flashrom *req;
+ int status;
+
+ spin_lock_bh(&adapter->mcc_lock);
+
+ wrb = wrb_from_mccq(adapter);
+ req = embedded_payload(wrb);
+
+ be_wrb_hdr_prepare(wrb, sizeof(*req)+4, true, 0);
+
+ be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
+ OPCODE_COMMON_READ_FLASHROM, sizeof(*req)+4);
+
+ req->params.op_type = cpu_to_le32(FLASHROM_TYPE_REDBOOT);
+ req->params.op_code = cpu_to_le32(FLASHROM_OPER_REPORT);
+ req->params.offset = 0x3FFFC;
+ req->params.data_buf_size = 0x4;
+
+ status = be_mcc_notify_wait(adapter);
+ if (!status)
+ memcpy(flashed_crc, req->params.data_buf, 4);
+
+ spin_unlock_bh(&adapter->mcc_lock);
+ return status;
+}
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index 69dc017..6a430e4 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -118,6 +118,7 @@ #define OPCODE_COMMON_NTWK_MAC_SET 2
#define OPCODE_COMMON_NTWK_MULTICAST_SET 3
#define OPCODE_COMMON_NTWK_VLAN_CONFIG 4
#define OPCODE_COMMON_NTWK_LINK_STATUS_QUERY 5
+#define OPCODE_COMMON_READ_FLASHROM 6
#define OPCODE_COMMON_WRITE_FLASHROM 7
#define OPCODE_COMMON_CQ_CREATE 12
#define OPCODE_COMMON_EQ_CREATE 13
@@ -846,3 +847,4 @@ extern int be_cmd_read_port_type(struct
extern int be_cmd_write_flashrom(struct be_adapter *adapter,
struct be_dma_mem *cmd, u32 flash_oper,
u32 flash_opcode, u32 buf_size);
+extern int be_cmd_get_flash_crc(struct be_adapter *adapter, u8 *flashed_crc);
diff --git a/drivers/net/benet/be_hw.h b/drivers/net/benet/be_hw.h
index a3394b4..f53d5ca 100644
--- a/drivers/net/benet/be_hw.h
+++ b/drivers/net/benet/be_hw.h
@@ -225,6 +225,7 @@ #define IMAGE_TYPE_OPTIONROM 32
#define NUM_FLASHDIR_ENTRIES 32
#define FLASHROM_TYPE_ISCSI_ACTIVE 0
+#define FLASHROM_TYPE_REDBOOT 1
#define FLASHROM_TYPE_BIOS 2
#define FLASHROM_TYPE_PXE_BIOS 3
#define FLASHROM_TYPE_FCOE_BIOS 8
@@ -234,9 +235,11 @@ #define FLASHROM_TYPE_FCOE_FW_BACKUP 11
#define FLASHROM_OPER_FLASH 1
#define FLASHROM_OPER_SAVE 2
+#define FLASHROM_OPER_REPORT 4
#define FLASH_IMAGE_MAX_SIZE (1310720) /* Max firmware image size */
#define FLASH_BIOS_IMAGE_MAX_SIZE (262144) /* Max OPTION ROM image sz */
+#define FLASH_REDBOOT_IMAGE_MAX_SIZE (262144) /* Max redboot image sz */
/* Offsets for components on Flash. */
#define FLASH_iSCSI_PRIMARY_IMAGE_START (1048576)
@@ -246,6 +249,8 @@ #define FLASH_FCoE_BACKUP_IMAGE_START
#define FLASH_iSCSI_BIOS_START (7340032)
#define FLASH_PXE_BIOS_START (7864320)
#define FLASH_FCoE_BIOS_START (524288)
+#define FLASH_REDBOOT_START (32768)
+#define FLASH_REDBOOT_ISM_START (0)
struct controller_id {
u32 vendor;
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index c0bd203..921103c 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1721,6 +1721,31 @@ static int be_close(struct net_device *n
#define FW_FILE_HDR_SIGN "ServerEngines Corp. "
char flash_cookie[2][16] = {"*** SE FLAS",
"H DIRECTORY *** "};
+
+static bool be_flash_redboot(struct be_adapter *adapter,
+ const u8 *p)
+{
+ u32 crc_offset;
+ u8 flashed_crc[4];
+ int status;
+ crc_offset = FLASH_REDBOOT_START + FLASH_REDBOOT_IMAGE_MAX_SIZE - 4
+ + sizeof(struct flash_file_hdr) - 32*1024;
+ p += crc_offset;
+ status = be_cmd_get_flash_crc(adapter, flashed_crc);
+ if (status) {
+ dev_err(&adapter->pdev->dev,
+ "could not get crc from flash, not flashing redboot\n");
+ return false;
+ }
+
+ /*update redboot only if crc does not match*/
+ if (!memcmp(flashed_crc, p, 4))
+ return false;
+ else
+ return true;
+
+}
+
static int be_flash_image(struct be_adapter *adapter,
const struct firmware *fw,
struct be_dma_mem *flash_cmd, u32 flash_type)
@@ -1760,6 +1785,12 @@ static int be_flash_image(struct be_adap
image_offset = FLASH_PXE_BIOS_START;
image_size = FLASH_BIOS_IMAGE_MAX_SIZE;
break;
+ case FLASHROM_TYPE_REDBOOT:
+ if (!be_flash_redboot(adapter, fw->data))
+ return 0;
+ image_offset = FLASH_REDBOOT_ISM_START;
+ image_size = FLASH_REDBOOT_IMAGE_MAX_SIZE;
+ break;
default:
return 0;
}
--
1.4.0
^ permalink raw reply related
* RE: [RFC] gianfar: multi queue stuff not complete
From: Kumar Gopalpet-B05799 @ 2009-11-19 8:52 UTC (permalink / raw)
To: Eric Dumazet, David S. Miller; +Cc: Linux Netdev List
In-Reply-To: <4B05019F.4090208@gmail.com>
>I noticed gianfar got multiqueue support recently, but it
>still updates dev->stats.{tx_bytes|tx_packets|tx_dropped}
>without proper locking (several cpus could update stats at
>same time while xmitting on different tx queues)
>
>It should use txq->{tx_bytes|tx_packets|tx_dropped} to avoid
>wrong tx stats
>
>
>I cooked following preliminar patch but its only for
>discussion, because I dont know yet how to transform
>dev->stats.tx_dropped++; in gfar_error(), and also because I
>cannot compile this driver on my dev machine.
>
>(if a driver uses txq->tx... counters, it must not use any
>dev->stats.{tx_bytes|tx_packets|tx_dropped}
>that are overwritten by dev_txq_stats_fold(). Or we could
>change dev_txq_stats_fold() logic to get a mask of what fields
>a drivers updates in txq-> or dev->stats
>
>
Eric, Yes I agree that still there are a couple of changes left and I am
working on it.
One of them being the stats. Currently caught up in something else, I
will update them ASAP.
Also, suggest me on what kind of stats do I need to maintain ? Both per
device and per queue
or only per queue would be sufficient ?
--
Thanks
Sandeep
^ permalink raw reply
* Re: [RFC] gianfar: multi queue stuff not complete
From: Eric Dumazet @ 2009-11-19 9:13 UTC (permalink / raw)
To: Kumar Gopalpet-B05799; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950E25@zin33exm22.fsl.freescale.net>
Kumar Gopalpet-B05799 a écrit :
>
> Eric, Yes I agree that still there are a couple of changes left and I am
> working on it.
> One of them being the stats. Currently caught up in something else, I
> will update them ASAP.
>
> Also, suggest me on what kind of stats do I need to maintain ? Both per
> device and per queue
> or only per queue would be sufficient ?
>
Optimum would be per queue only, to avoid locking and let each queue be really independant.
^ permalink raw reply
* RE: [RFC] gianfar: multi queue stuff not complete
From: Kumar Gopalpet-B05799 @ 2009-11-19 9:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4B050C25.5010309@gmail.com>
>> Eric, Yes I agree that still there are a couple of changes
>left and I
>> am working on it.
>> One of them being the stats. Currently caught up in
>something else, I
>> will update them ASAP.
>>
>> Also, suggest me on what kind of stats do I need to maintain ? Both
>> per device and per queue or only per queue would be sufficient ?
>>
>Optimum would be per queue only, to avoid locking and let each
>queue be really independant.
>
Thanks Eric, I will proceed with per queue stats then.
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: Jarek Poplawski @ 2009-11-19 9:57 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <65634d660911102253o2b4f7a19kfed5849e5c88bfe1@mail.gmail.com>
On 11-11-2009 07:53, Tom Herbert wrote:
> Third version of RPS.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
...
> @@ -2266,10 +2401,10 @@ void netif_nit_deliver(struct sk_buff *skb)
> }
>
> /**
> - * netif_receive_skb - process receive buffer from network
> + * __netif_receive_skb - process receive buffer from network
> * @skb: buffer to process
> *
> - * netif_receive_skb() is the main receive data processing function.
> + * __netif__napireceive_skb() is the main receive data processing function.
--------------->^^^^^^^^^^^^ ?
> * It always succeeds. The buffer may be dropped during processing
> * for congestion control or by the protocol layers.
> *
> @@ -2280,7 +2415,8 @@ void netif_nit_deliver(struct sk_buff *skb)
> * NET_RX_SUCCESS: no congestion
> * NET_RX_DROP: packet was dropped
> */
> -int netif_receive_skb(struct sk_buff *skb)
> +
> +int __netif_receive_skb(struct sk_buff *skb)
> {
> struct packet_type *ptype, *pt_prev;
> struct net_device *orig_dev;
> @@ -2378,6 +2514,16 @@ out:
> }
> EXPORT_SYMBOL(netif_receive_skb);
>
> +int netif_receive_skb(struct sk_buff *skb)
> +{
> + int cpu = get_rps_cpu(skb->dev, skb);
> +
> + if (cpu < 0)
The description reads: "This solution queues packets early on in the
receive path on the backlog queues of other CPUs.", so I'm not sure
it's intended. Did you test it like this (and it was visibly worse)?:
if (cpu < 0 || cpu == smp_processor_id())
> + return __netif_receive_skb(skb);
> + else
> + return enqueue_to_backlog(skb, cpu);
> +}
> +
Jarek P.
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: Andi Kleen @ 2009-11-19 10:08 UTC (permalink / raw)
To: Tom Herbert; +Cc: Andi Kleen, David Miller, netdev
In-Reply-To: <65634d660911160902t677a4fb4r71602cb0d10f1cce@mail.gmail.com>
On Mon, Nov 16, 2009 at 09:02:32AM -0800, Tom Herbert wrote:
Sorry for the late answer.
> >> + case __constant_htons(ETH_P_IPV6):
> >> + if (!pskb_may_pull(skb, sizeof(*ip6)))
> >> + return -1;
> >> +
> >> + ip6 = (struct ipv6hdr *) skb->data;
> >> + ip_proto = ip6->nexthdr;
> >> + addr1 = ip6->saddr.s6_addr32[3];
> >> + addr2 = ip6->daddr.s6_addr32[3];
> >
> > Why only [3] ? Is this future proof?
> >
> No. But it's same as inet6_ehashfn :-)
Perhaps it would be good to consolidate all these ipv6 hashes
into one place where they could be at least fixed easily.
>
> >> + for_each_cpu_mask_nr(cpu, __get_cpu_var(rps_remote_softirq_cpus)) {
> >> + struct softnet_data *queue = &per_cpu(softnet_data, cpu);
> >> + __smp_call_function_single(cpu, &queue->csd, 0);
> >
> > How do you get around the standard deadlocks with IPI called from
> > irq disabled section?
> >
>
> What are the standard deadlocks? Looks like __send_remote_softirq
> will call __smp_call_function with irq's disabled...
The traditional deadlock (that was before the queue smp_call_function)
was
A B
grab lock
interrupts off
spin on lock
send IPI
wait for specific CPU
never answers because
interrupts are off
hangs forever
I think with the queued smp_call_function it's better because
the locks are only hold much shorter and that particular scenario
is gone, but I'm not sure the problem has fully gone away.
At least there are still plenty of WARN_ON( ... irqs_disabled()) in
kernel/smp.c
> > It's a standard pet peeve of me, but it's quite unlikely you'll
> > get any useful entropy at this time of kernel startup.
> >
> > Normally it's always the same.
> >
> Would it make sense to just use skb_tx_hashrnd for the receive hash
> key also (renaming it to be more general)?
That has the same problem, although it's at least a bit later,
but I suspect it would be still not very random.
You could just drop it and always use a constant hash rnd?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ 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