* Re: [PATCH 2.6.32-rc6] drivers/net: ks8851_mll ethernet network driver
From: David Miller @ 2009-11-19 21:19 UTC (permalink / raw)
To: David.Choi; +Cc: netdev, linux-kernel, shemminger, greg
In-Reply-To: <20091119.122734.89781869.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 19 Nov 2009 12:27:34 -0800 (PST)
> From: "Choi, David" <David.Choi@Micrel.Com>
> Date: Tue, 17 Nov 2009 15:02:36 -0800
>
>> This patch is for ks8851 16bit MLL Ethernet network device driver in order to fix bugs and to enhance functions.
> ...
>> Signed-off-by: David J. Choi <david.choi@micrel.com>
>
> Applied.
Sorry I had to revert this, it adds new warnings to the
build.
You can't cast pointers to 'int' in order to print them,
that emits a warning on 64-bit systems because you're
truncating the top bits.
There is really no point in printing __iomem pointers,
those are very architecture specific. So is the IRQ
number.
I would just remove this part of your patch entirely
(don't forget to update the commit message to match).
Please fix this up and resubmit, thank you.
^ permalink raw reply
* Re: [PATCH net-next] drivers/isdn/gigaset: tasklet_init - Remove unnecessary leading & from second arg
From: David Miller @ 2009-11-19 20:29 UTC (permalink / raw)
To: joe; +Cc: netdev, hjlipp, tilman, isdn, gigaset307x-common
In-Reply-To: <1258660553.3863.18.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Thu, 19 Nov 2009 11:55:53 -0800
> Changed function pointer use from non-majority address-of style
> to majority short form without & via:
>
> grep -rPl "\btasklet_init\s*\([^,\)]+,\s*\&" drivers/isdn | while read file ; do \
> perl -i -e 'local $/; while (<>) { s@(\btasklet_init\s*\([^,\)]+,\s*)\&@\1@g ; print ; }' $file ;\
> done
>
> Compile tested allyesconfig x86
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH] drivers/net: tasklet_init - Remove unnecessary leading & from second arg
From: David Miller @ 2009-11-19 20:29 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1258659010.3863.11.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Thu, 19 Nov 2009 11:30:10 -0800
> Changed function pointer use from non-majority address-of style
> to majority short form without & via: (was: 8 with &, 36 without)
>
> grep -rPl "\btasklet_init\s*\([^,\)]+,\s*\&" drivers/net | while read file ; do \
> perl -i -e 'local $/; while (<>) { s@(\btasklet_init\s*\([^,\)]+,\s*)\&@\1@g ; print ; }' $file ;\
> done
>
> Compile tested allyesconfig x86
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: netfilter 01/02: xt_osf: fix xt_osf_remove_callback() return value
From: David Miller @ 2009-11-19 20:28 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel
In-Reply-To: <20091119145903.18633.79066.sendpatchset@x2.localnet>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 19 Nov 2009 15:59:03 +0100 (MET)
> commit 1c622ae67bfc729891f5cd80795b15b87e6ac471
> Author: Roel Kluin <roel.kluin@gmail.com>
> Date: Fri Nov 13 09:31:35 2009 +0100
>
> netfilter: xt_osf: fix xt_osf_remove_callback() return value
>
> Return a negative error value.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied.
^ permalink raw reply
* Re: netfilter 02/02: nf_log: fix sleeping function called from invalid context in seq_show()
From: David Miller @ 2009-11-19 20:28 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel
In-Reply-To: <20091119145904.18633.11963.sendpatchset@x2.localnet>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 19 Nov 2009 15:59:05 +0100 (MET)
> commit 7378396cd172cc058fa62220c6486419046c4e0c
> Author: Wu Fengguang <fengguang.wu@intel.com>
> Date: Fri Nov 13 09:34:44 2009 +0100
>
> netfilter: nf_log: fix sleeping function called from invalid context in seq_show()
...
> Reported-by: "Yin, Kangkai" <kangkai.yin@intel.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
Applied.
^ permalink raw reply
* Re: [PATCH] ieee802154: dont leak skbs in ieee802154_fake_xmit()
From: David Miller @ 2009-11-19 20:27 UTC (permalink / raw)
To: dbaryshkov; +Cc: eric.dumazet, netdev
In-Reply-To: <bc64b4640911190757w7eea481sd346085e3ceb1276@mail.gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Thu, 19 Nov 2009 18:57:48 +0300
> On Thu, Nov 19, 2009 at 2:28 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> ieee802154_fake_xmit() should free skbs since it returns NETDEV_TX_OK
>
> Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>
> David, please apply.
Applied.
^ permalink raw reply
* Re: [PATCH] veth: Fix veth_get_stats()
From: David Miller @ 2009-11-19 20:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4B042A53.9010301@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Nov 2009 18:09:39 +0100
> veth_get_stats() can be called in parallel on several cpus.
>
> It's better to not reset dev->stats as it could give wrong result on
> one cpu. Use temporary variables, then store the final results.
>
> Also, we should loop on every possible cpus, not only online cpus,
> or cpu hotplug can suddenly give wrong veth stats.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2.6.32-rc6] drivers/net: ks8851_mll ethernet network driver
From: David Miller @ 2009-11-19 20:27 UTC (permalink / raw)
To: David.Choi; +Cc: netdev, linux-kernel, shemminger, greg
In-Reply-To: <C43529A246480145B0A6D0234BDB0F0D021299@MELANITE.micrel.com>
From: "Choi, David" <David.Choi@Micrel.Com>
Date: Tue, 17 Nov 2009 15:02:36 -0800
> This patch is for ks8851 16bit MLL Ethernet network device driver in order to fix bugs and to enhance functions.
...
> Signed-off-by: David J. Choi <david.choi@micrel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net:Patch to flash redboot section while firmware update.
From: David Miller @ 2009-11-19 20:23 UTC (permalink / raw)
To: sarveshwarb; +Cc: netdev
In-Reply-To: <20091119084829.GA19247@serverengines.com>
From: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Date: Thu, 19 Nov 2009 14:18:43 +0530
> 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>
What is this redboot section all about?
^ permalink raw reply
* Re: [PATCH 1/3] hso: memory leak in hso_serial_common_free()
From: David Miller @ 2009-11-19 20:20 UTC (permalink / raw)
To: mschiller; +Cc: netdev, linux-kernel
In-Reply-To: <1C487791B6A047B7A26F2B3C54BE0A70@mschille2>
From: "Martin Schiller" <mschiller@tdt.de>
Date: Thu, 19 Nov 2009 09:43:57 +0100
> 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>
All three of your patches have been severely corrupted by
your email client. Sequences of one or more tab characters
have been converted in a single space, etc.
> 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);
> }
>
This makes your changes unusable.
You've already gone through two iterations trying to submit
these bug fixes. Please take some time out to verify that
your outging patches in emails can be received accurately
and applied by the receiver (send the patch to yourself
and try to apply it, for example).
Thanks.
^ permalink raw reply
* stmmac patches...
From: David Miller @ 2009-11-19 20:18 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
Please do not intermix coding style changes with bug
fixes.
In your second patch you change the indentation of
the arguments to ->init_rx_desc() in stmmac_suspend()
Not only is this inappropriate in a bug fix patch, it
is actually making the indentation incorrect. The
arguments should line up to the column after the
function argument set openning '(' on the previous
line.
Please fix this up and resubmit both of your patches.
Thank you.
^ permalink raw reply
* Re: [Bug #14252] WARNING: at include/linux/skbuff.h:1382 w/ e1000
From: David Miller @ 2009-11-19 20:07 UTC (permalink / raw)
To: rjw-KKrjLPT3xs0
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
skraw-DcQCyzbjH0jQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <OWmO9uyC1hM.A.w9C.NodALB@chimera>
From: "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>
Date: Tue, 17 Nov 2009 00:01:18 +0100 (CET)
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.30 and 2.6.31.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.30 and 2.6.31. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14252
> Subject : WARNING: at include/linux/skbuff.h:1382 w/ e1000
> Submitter : Stephan von Krawczynski <skraw-DcQCyzbjH0jQT0dZR+AlfA@public.gmane.org>
> Date : 2009-09-20 11:26 (58 days old)
> References : http://marc.info/?l=linux-kernel&m=125344599006033&w=4
Please CC: netdev when reporting networking problems, thank you.
Intel folks can you please take a look at this? Thanks.
^ permalink raw reply
* [PATCH net-next] drivers/isdn/gigaset: tasklet_init - Remove unnecessary leading & from second arg
From: Joe Perches @ 2009-11-19 19:55 UTC (permalink / raw)
To: David Miller
Cc: netdev, Hansjoerg Lipp, Tilman Schmidt, Karsten Keil,
gigaset307x-common
Changed function pointer use from non-majority address-of style
to majority short form without & via:
grep -rPl "\btasklet_init\s*\([^,\)]+,\s*\&" drivers/isdn | while read file ; do \
perl -i -e 'local $/; while (<>) { s@(\btasklet_init\s*\([^,\)]+,\s*)\&@\1@g ; print ; }' $file ;\
done
Compile tested allyesconfig x86
Signed-off-by: Joe Perches <joe@perches.com>
drivers/isdn/gigaset/bas-gigaset.c | 4 ++--
drivers/isdn/gigaset/common.c | 2 +-
drivers/isdn/gigaset/interface.c | 2 +-
drivers/isdn/gigaset/ser-gigaset.c | 2 +-
drivers/isdn/gigaset/usb-gigaset.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/isdn/gigaset/bas-gigaset.c b/drivers/isdn/gigaset/bas-gigaset.c
index 9fd19db..95ebc51 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -2117,7 +2117,7 @@ static int gigaset_initbcshw(struct bc_state *bcs)
return 0;
}
tasklet_init(&ubc->sent_tasklet,
- &write_iso_tasklet, (unsigned long) bcs);
+ write_iso_tasklet, (unsigned long) bcs);
spin_lock_init(&ubc->isoinlock);
for (i = 0; i < BAS_INURBS; ++i)
@@ -2138,7 +2138,7 @@ static int gigaset_initbcshw(struct bc_state *bcs)
ubc->shared0s = 0;
ubc->stolen0s = 0;
tasklet_init(&ubc->rcvd_tasklet,
- &read_iso_tasklet, (unsigned long) bcs);
+ read_iso_tasklet, (unsigned long) bcs);
return 1;
}
diff --git a/drivers/isdn/gigaset/common.c b/drivers/isdn/gigaset/common.c
index c438cfc..82ed1cd 100644
--- a/drivers/isdn/gigaset/common.c
+++ b/drivers/isdn/gigaset/common.c
@@ -727,7 +727,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
cs->ev_tail = 0;
cs->ev_head = 0;
- tasklet_init(&cs->event_tasklet, &gigaset_handle_event,
+ tasklet_init(&cs->event_tasklet, gigaset_handle_event,
(unsigned long) cs);
cs->commands_pending = 0;
cs->cur_at_seq = 0;
diff --git a/drivers/isdn/gigaset/interface.c b/drivers/isdn/gigaset/interface.c
index 577809c..d2260b0 100644
--- a/drivers/isdn/gigaset/interface.c
+++ b/drivers/isdn/gigaset/interface.c
@@ -584,7 +584,7 @@ void gigaset_if_init(struct cardstate *cs)
if (!drv->have_tty)
return;
- tasklet_init(&cs->if_wake_tasklet, &if_wake, (unsigned long) cs);
+ tasklet_init(&cs->if_wake_tasklet, if_wake, (unsigned long) cs);
mutex_lock(&cs->mutex);
cs->tty_dev = tty_register_device(drv->tty, cs->minor_index, NULL);
diff --git a/drivers/isdn/gigaset/ser-gigaset.c b/drivers/isdn/gigaset/ser-gigaset.c
index ac3409e..168d585 100644
--- a/drivers/isdn/gigaset/ser-gigaset.c
+++ b/drivers/isdn/gigaset/ser-gigaset.c
@@ -434,7 +434,7 @@ static int gigaset_initcshw(struct cardstate *cs)
dev_set_drvdata(&cs->hw.ser->dev.dev, cs);
tasklet_init(&cs->write_tasklet,
- &gigaset_modem_fill, (unsigned long) cs);
+ gigaset_modem_fill, (unsigned long) cs);
return 1;
}
diff --git a/drivers/isdn/gigaset/usb-gigaset.c b/drivers/isdn/gigaset/usb-gigaset.c
index f56b2a8..3ab1dae 100644
--- a/drivers/isdn/gigaset/usb-gigaset.c
+++ b/drivers/isdn/gigaset/usb-gigaset.c
@@ -614,7 +614,7 @@ static int gigaset_initcshw(struct cardstate *cs)
ucs->bulk_out_urb = NULL;
ucs->read_urb = NULL;
tasklet_init(&cs->write_tasklet,
- &gigaset_modem_fill, (unsigned long) cs);
+ gigaset_modem_fill, (unsigned long) cs);
return 1;
}
^ permalink raw reply related
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-19 19:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1258657155.2837.10.camel@achroite.uk.solarflarecom.com>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Thursday, November 19, 2009 10:59 AM
>> Please explain specifically what you perceive to be the difference
>between:
>>
>> $ ip link set eth1 queue 1 mac <blah>
>> $ ip link set eth1 queue 1 vlan <foo>
>>
>> and
>>
>> $ ip link set eth1 queue 1 mac <blah> vlan <foo>
>>
>> The two filter types are, in my mind, completely orthogonal. You can
>> have one, or the other, or both, or neither. What do we gain by
>> glomming both options on one command line? And is this worth the
>> tradeoff of more complex code?
>
>I think you need to state clearly what semantics you are now proposing
>before I can make any judgement on them.
>
OK, now I'm really confused, Ben. It seems that we are both asking each other the same question.
What I'm proposing is really the same as we have now for single-queue devices:
- A MAC filter is enabled by default. If you want to change the MAC address, you use a tool (ip or ifconfig) to change it.
- A VLAN filter is not enabled by default. If you want to filter on VLANs, then you load the 8021q module, and enable a filter.
The MAC filter is configured completely separately from the VLAN filter. Either one can be changed without affecting the other one and, in fact, you use two different tools to do these operations.
For SR-IOV VF devices, my proposed changes implement exactly the same thing. You use one command to change the MAC address. You use another command to change the VLAN filter. Changing one does not affect the other.
In this case, we use the same tool for both operations, but they're still separate operations.
-Mitch
N.B.
The major difference in VLAN filtering is that this implementation allows the VF to participate in only one VLAN, and the filter is applied independently of the VF driver. So you can put a specific VM on a VLAN without its knowledge. If you want the VM to have more intelligent VLAN filtering, you don't use this filter, and you load 8021q in the VM and set your filters there.
^ permalink raw reply
* [PATCH] drivers/net: tasklet_init - Remove unnecessary leading & from second arg
From: Joe Perches @ 2009-11-19 19:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Changed function pointer use from non-majority address-of style
to majority short form without & via: (was: 8 with &, 36 without)
grep -rPl "\btasklet_init\s*\([^,\)]+,\s*\&" drivers/net | while read file ; do \
perl -i -e 'local $/; while (<>) { s@(\btasklet_init\s*\([^,\)]+,\s*)\&@\1@g ; print ; }' $file ;\
done
Compile tested allyesconfig x86
Signed-off-by: Joe Perches <joe@perches.com>
drivers/net/cnic.c | 4 ++--
drivers/net/jme.c | 10 +++++-----
drivers/net/skge.c | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index e503384..ee7eb9e 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -3387,7 +3387,7 @@ static int cnic_init_bnx2_irq(struct cnic_dev *dev)
cp->bnx2_status_blk = cp->status_blk;
cp->last_status_idx = cp->bnx2_status_blk->status_idx;
- tasklet_init(&cp->cnic_irq_task, &cnic_service_bnx2_msix,
+ tasklet_init(&cp->cnic_irq_task, cnic_service_bnx2_msix,
(unsigned long) dev);
err = request_irq(ethdev->irq_arr[0].vector, cnic_irq, 0,
"cnic", dev);
@@ -3787,7 +3787,7 @@ static int cnic_init_bnx2x_irq(struct cnic_dev *dev)
struct cnic_eth_dev *ethdev = cp->ethdev;
int err = 0;
- tasklet_init(&cp->cnic_irq_task, &cnic_service_bnx2x_bh,
+ tasklet_init(&cp->cnic_irq_task, cnic_service_bnx2x_bh,
(unsigned long) dev);
if (ethdev->drv_state & CNIC_DRV_STATE_USING_MSIX) {
err = request_irq(ethdev->irq_arr[0].vector, cnic_irq, 0,
diff --git a/drivers/net/jme.c b/drivers/net/jme.c
index 1d2a325..6c1b92f 100644
--- a/drivers/net/jme.c
+++ b/drivers/net/jme.c
@@ -2764,19 +2764,19 @@ jme_init_one(struct pci_dev *pdev,
atomic_set(&jme->rx_empty, 1);
tasklet_init(&jme->pcc_task,
- &jme_pcc_tasklet,
+ jme_pcc_tasklet,
(unsigned long) jme);
tasklet_init(&jme->linkch_task,
- &jme_link_change_tasklet,
+ jme_link_change_tasklet,
(unsigned long) jme);
tasklet_init(&jme->txclean_task,
- &jme_tx_clean_tasklet,
+ jme_tx_clean_tasklet,
(unsigned long) jme);
tasklet_init(&jme->rxclean_task,
- &jme_rx_clean_tasklet,
+ jme_rx_clean_tasklet,
(unsigned long) jme);
tasklet_init(&jme->rxempty_task,
- &jme_rx_empty_tasklet,
+ jme_rx_empty_tasklet,
(unsigned long) jme);
tasklet_disable_nosync(&jme->linkch_task);
tasklet_disable_nosync(&jme->txclean_task);
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index ba5eb14..34b4e7d 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -3947,7 +3947,7 @@ static int __devinit skge_probe(struct pci_dev *pdev,
hw->pdev = pdev;
spin_lock_init(&hw->hw_lock);
spin_lock_init(&hw->phy_lock);
- tasklet_init(&hw->phy_task, &skge_extirq, (unsigned long) hw);
+ tasklet_init(&hw->phy_task, skge_extirq, (unsigned long) hw);
hw->regs = ioremap_nocache(pci_resource_start(pdev, 0), 0x4000);
if (!hw->regs) {
^ permalink raw reply related
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-19 19:12 UTC (permalink / raw)
To: Patrick McHardy
Cc: Ben Hutchings, Kirsher, Jeffrey T, davem@davemloft.net,
shemminger@vyatta.com, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <4B059563.3010702@trash.net>
>From: Patrick McHardy [mailto:kaber@trash.net]
>Sent: Thursday, November 19, 2009 10:59 AM
[snip]
>
>One argument would be that "ip link show" should probably display
>all filters, so they all need to be included in the dump message.
>
>And this is exactly the same message type used for configuring
>links and the API is supposed to be symetric, meaning you can
>send a dump message with NLM_F_REQUEST to the kernel again and
>it (re-)creates the same object.
Yeah, we've indentified that as a need - that's one reason we sent this out as an RFC. I'll implement the "show" semantics before we repost.
-Mitch
^ permalink raw reply
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Ben Hutchings @ 2009-11-19 18:59 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FA6A1FF82@rrsmsx501.amr.corp.intel.com>
On Thu, 2009-11-19 at 11:43 -0700, Williams, Mitch A wrote:
[...]
> OK, point taken. Specific hardware features/limitations shouldn't affect kernel policy.
>
> However, I'm still back to code complexity, and general usage models.
>
> Please explain specifically what you perceive to be the difference between:
>
> $ ip link set eth1 queue 1 mac <blah>
> $ ip link set eth1 queue 1 vlan <foo>
>
> and
>
> $ ip link set eth1 queue 1 mac <blah> vlan <foo>
>
> The two filter types are, in my mind, completely orthogonal. You can
> have one, or the other, or both, or neither. What do we gain by
> glomming both options on one command line? And is this worth the
> tradeoff of more complex code?
I think you need to state clearly what semantics you are now proposing
before I can make any judgement on them.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Patrick McHardy @ 2009-11-19 18:58 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Ben Hutchings, Kirsher, Jeffrey T, davem@davemloft.net,
shemminger@vyatta.com, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FA6A1FF82@rrsmsx501.amr.corp.intel.com>
Williams, Mitch A wrote:
> However, I'm still back to code complexity, and general usage models.
>
> Please explain specifically what you perceive to be the difference between:
>
> $ ip link set eth1 queue 1 mac <blah>
> $ ip link set eth1 queue 1 vlan <foo>
>
> and
>
> $ ip link set eth1 queue 1 mac <blah> vlan <foo>
>
> The two filter types are, in my mind, completely orthogonal. You can have one, or the other, or both, or neither. What do we gain by glomming both options on one command line? And is this worth the tradeoff of more complex code?
One argument would be that "ip link show" should probably display
all filters, so they all need to be included in the dump message.
And this is exactly the same message type used for configuring
links and the API is supposed to be symetric, meaning you can
send a dump message with NLM_F_REQUEST to the kernel again and
it (re-)creates the same object.
^ permalink raw reply
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-19 18:43 UTC (permalink / raw)
To: Ben Hutchings
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1258642493.2837.8.camel@achroite.uk.solarflarecom.com>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Thursday, November 19, 2009 6:55 AM
>[...]
>> In the case of SR-IOV on our hardware, these filters are perfect - no
>> hash tables are required. (We do use hash tables when we have a bunch
>> of multicast addresses, but that's not what this is about.)
>>
>> MAC filters deny packets by default, so you won't get anything without
>> a valid MAC filter on the queue.
>>
>> A queue with no VLAN filters will receive packets from all VLANs,
>> albeit with the tags passed up intact. So in that sense, the VLAN
>> filters are default-allow.
>>
>> However, once you enable any VLAN filter, the hardware starts
>> stripping tags and begins to deny packets by default.
>>
>> Based on these semantics, the filtering operation that I've described
>> above makes perfect sense.
>[...]
>
>But they are not the semantics we would want in supposedly generic
>netdev operations.
>
OK, point taken. Specific hardware features/limitations shouldn't affect kernel policy.
However, I'm still back to code complexity, and general usage models.
Please explain specifically what you perceive to be the difference between:
$ ip link set eth1 queue 1 mac <blah>
$ ip link set eth1 queue 1 vlan <foo>
and
$ ip link set eth1 queue 1 mac <blah> vlan <foo>
The two filter types are, in my mind, completely orthogonal. You can have one, or the other, or both, or neither. What do we gain by glomming both options on one command line? And is this worth the tradeoff of more complex code?
-Mitch
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Jens Rosenboom @ 2009-11-19 18:36 UTC (permalink / raw)
To: Dhananjay Phadke; +Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha
In-Reply-To: <7608421F3572AB4292BB2532AE89D5658B0B95BD5C@AVEXMB1.qlogic.org>
On Thu, Nov 19, 2009 at 10:07:21AM -0800, Dhananjay Phadke wrote:
> > My netxen 10G card stops working somewhere between 2.6.30 and 2.6.31-rc1.
> > With the
> > newer kernel I can see packets been received on the switch it is
> > connected to, but
> > the kernel doesn't report any sent packets in the interface counters and
> > nothing
> > is being received either.
> >
> > I've tried to bisect this, but only seems the end up with kernels that do
> > not boot
> > at all because some SCSI stuff goes bad.
>
> Any particular reason for using -rc1 kernel and not 2.6.31 stable kernel?
Sorry, I forgot to mention that all later kernels that I tested
including 2.6.31 and the current net-2.6 also fail, so the badness
comes in somewhere in between 2.6.30 and 2.6.31-rc1.
I also noticed that the newer kernel allocate four interrupts for the
card instead of only one, but none of them seem to get triggered, the
/proc/interrupts counters all stay at zero.
^ permalink raw reply
* RE: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Dhananjay Phadke @ 2009-11-19 18:07 UTC (permalink / raw)
To: Jens Rosenboom, netdev@vger.kernel.org; +Cc: Amit Salecha
In-Reply-To: <20091119163908.GJ14661@jayr.de>
> My netxen 10G card stops working somewhere between 2.6.30 and 2.6.31-rc1.
> With the
> newer kernel I can see packets been received on the switch it is
> connected to, but
> the kernel doesn't report any sent packets in the interface counters and
> nothing
> is being received either.
>
> I've tried to bisect this, but only seems the end up with kernels that do
> not boot
> at all because some SCSI stuff goes bad.
Any particular reason for using -rc1 kernel and not 2.6.31 stable kernel?
-Dhananjay
^ permalink raw reply
* [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Jens Rosenboom @ 2009-11-19 16:39 UTC (permalink / raw)
To: netdev; +Cc: Dhananjay Phadke
My netxen 10G card stops working somewhere between 2.6.30 and 2.6.31-rc1. With the
newer kernel I can see packets been received on the switch it is connected to, but
the kernel doesn't report any sent packets in the interface counters and nothing
is being received either.
I've tried to bisect this, but only seems the end up with kernels that do not boot
at all because some SCSI stuff goes bad.
Any hints how to address this further? Please keep me on CC:.
Yours,
Jens
^ permalink raw reply
* Re: tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-19 16:08 UTC (permalink / raw)
To: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
In-Reply-To: <4B056158.5060104@embedded-sol.com>
Hi,
The problem goes away if I remove the call to
tg3_set_power_state(tp, PCI_D3hot);
from tg3_close().
Some relevant stuff from dmesg:
pci 0002:05:00.0: PME# supported from D3hot D3cold
pci 0002:05:00.0: PME# disabled
tg3.c:v3.102 (September 1, 2009)
tg3 0002:05:00.0: enabling device (0000 -> 0002)
tg3 0002:05:00.0: PME# disabled
tg3 mdio bus: probed
eth2: Tigon3 [partno(BCM57760) rev 57780001] (PCI Express) MAC address
00:10:18:00:00:00
eth2: attached PHY driver [Broadcom BCM57780] (mii_bus:phy_addr=500:01)
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
eth2: dma_rwctrl[76180000] dma_mask[64-bit]
Is my problem related to hardware or it's a tg3 driver bug ?
Thanks a lot.
Felix.
Felix Radensky wrote:
> Hi,
>
> I have a problem with tg3 driver on a custom MPC8536 based board
> running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
> linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
>
> The problem I'm seeing is that the downing and interface leads to
> permanent link loss, even after interface is upped again. E.g, to
> reproduce the problem it is sufficient to run:
>
> modprobe tg3
> ifconfig eth2 up
> ifconfig eth2 down
> ifconfig eth2 up
>
> After ifdown PHY LEDs also go down and do not come back
> after ifup. Ethtool reports that no link is detected. After reloading
> the driver the link comes back.
>
> Am I the only one seeing this problem ?
> Any help on fixing this is appreciated.
>
> Thanks a lot.
>
> Felix.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] ieee802154: dont leak skbs in ieee802154_fake_xmit()
From: Dmitry Eremin-Solenikov @ 2009-11-19 15:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4B052BCA.4020901@gmail.com>
On Thu, Nov 19, 2009 at 2:28 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> ieee802154_fake_xmit() should free skbs since it returns NETDEV_TX_OK
Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
David, please apply.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: Oops in Unix sockets code
From: Sebastian Ott @ 2009-11-19 15:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Christian Borntraeger, Blaschka, netdev, linux-s390
In-Reply-To: <4B05542D.7060401@gmail.com>
On Thu, 19 Nov 2009, Eric Dumazet wrote:
...
> 2.6.31 has a known bug
>
> 2.6.31.4 should correct it
>
> commit 657453424a3c382035983f9a47306fafea730f6d
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu Sep 24 10:49:24 2009 +0000
indeed, problem didn't show up with d99927f applied. thanks for
pointing that out.
sebastian
^ 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