* Re: [PATCH 41/44] net/ipv6/mcast.c: Remove unnecessary semicolons
From: David Miller @ 2010-11-15 19:07 UTC (permalink / raw)
To: joe; +Cc: trivial, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev,
linux-kernel
In-Reply-To: <1f3e1f7e454f3c62b66fc5f3e1e1ed90d62b7fb0.1289789605.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 14 Nov 2010 19:05:00 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 38/44] include/linux/if_macvlan.h: Remove unnecessary semicolons
From: David Miller @ 2010-11-15 19:07 UTC (permalink / raw)
To: joe; +Cc: trivial, kaber, netdev, linux-kernel
In-Reply-To: <186ca914f887b2354ea3178696edc81cacbb28c6.1289789605.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 14 Nov 2010 19:04:57 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 15/44] drivers/net/vxge: Remove unnecessary semicolons
From: David Miller @ 2010-11-15 19:07 UTC (permalink / raw)
To: joe
Cc: trivial, ramkrishna.vepa, sivakumar.subramani, sreenivasa.honnur,
jon.mason, netdev, linux-kernel
In-Reply-To: <e86e79a18106cc38715136bfb2e880b38f5ac764.1289789604.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 14 Nov 2010 19:04:34 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Not applicable to net-next-2.6
^ permalink raw reply
* Re: [BUG]: skge not working (as module) in 2.6.37-rc1
From: Maciej Rutecki @ 2010-11-15 19:07 UTC (permalink / raw)
To: Marin Mitov
Cc: Stephen Hemminger, Stephen Hemminger, netdev, linux-kernel,
David S. Miller
In-Reply-To: <201011150555.59407.mitov@issp.bas.bg>
On poniedziałek, 15 listopada 2010 o 04:55:58 Marin Mitov wrote:
> On Sunday, November 14, 2010 09:45:14 pm Maciej Rutecki wrote:
> > On niedziela, 7 listopada 2010 o 22:45:52 Marin Mitov wrote:
> > > Hi Stephen,
> > >
> > > skge as in 2.6.36 (and before) is working.
> >
> > > As in 2.6.37-rc1 it is not:
> > I created a Bugzilla entry at
> > https://bugzilla.kernel.org/show_bug.cgi?id=22892
> > for your bug report, please add your address to the CC list in there,
> > thanks!
>
> Hi Maciej,
>
> It is already corrected, as in 2.6.37-rc1-git11.
>
> Thanks.
>
> Marin Mitov
Thanks for the update.
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* Re: [PATCH 18/44] drivers/net/cnic.c: Remove unnecessary semicolons
From: David Miller @ 2010-11-15 19:08 UTC (permalink / raw)
To: joe; +Cc: trivial, netdev, linux-kernel
In-Reply-To: <950331e47b16c2ad28d73502f30f5a0f017b5493.1289789604.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 14 Nov 2010 19:04:37 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 07/44] drivers/isdn: Remove unnecessary semicolons
From: David Miller @ 2010-11-15 19:08 UTC (permalink / raw)
To: joe; +Cc: trivial, isdn, netdev, linux-kernel
In-Reply-To: <c7a38f65340aafb208d50fc3a781602c07aebb0c.1289789604.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 14 Nov 2010 19:04:26 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 14/44] drivers/net/ixgbe: Remove unnecessary semicolons
From: David Miller @ 2010-11-15 19:08 UTC (permalink / raw)
To: joe
Cc: trivial, e1000-devel, bruce.w.allan, jesse.brandeburg,
linux-kernel, gregory.v.rose, john.ronciak, jeffrey.t.kirsher,
netdev
In-Reply-To: <7d2c334daa75c5221946a17d45c9de1901cf06e7.1289789604.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 14 Nov 2010 19:04:33 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 13/44] drivers/net/e1000e: Remove unnecessary semicolons
From: David Miller @ 2010-11-15 19:08 UTC (permalink / raw)
To: joe
Cc: trivial, e1000-devel, bruce.w.allan, jesse.brandeburg,
linux-kernel, gregory.v.rose, john.ronciak, jeffrey.t.kirsher,
netdev
In-Reply-To: <e5cf92d50de7924930d660a5865c3d60d9cd9dc5.1289789604.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 14 Nov 2010 19:04:32 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 12/44] drivers/net/bnx2x: Remove unnecessary semicolons
From: David Miller @ 2010-11-15 19:08 UTC (permalink / raw)
To: joe; +Cc: trivial, eilong, netdev, linux-kernel
In-Reply-To: <2bfaf1f1fe5d503a8a386a433b5187997819d771.1289789604.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 14 Nov 2010 19:04:31 -0800
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: network device reference leak with net-next
From: Stephen Hemminger @ 2010-11-15 19:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1289847840.2607.120.camel@edumazet-laptop>
On Mon, 15 Nov 2010 20:04:00 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 15 novembre 2010 à 10:56 -0800, Stephen Hemminger a écrit :
> > This is a new regression (doesn't exist with 2.6.36)
> >
> > If I shutdown KVM instance with Virt manager, the virtual
> > interfaces in the bridge aren't getting cleaned up because
> > of leftover reference count.
> >
> >
> > [ 9781.050474] unregister_netdevice: waiting for vnet1 to become free. Usage count = 1
> > [ 9785.143400] virbr4: port 3(vnet6) entering forwarding state
> > [ 9785.177194] virbr4: port 3(vnet6) entering disabled state
> > [ 9785.201129] device vnet6 left promiscuous mode
> > [ 9785.201135] virbr4: port 3(vnet6) entering disabled state
> > [ 9791.286950] unregister_netdevice: waiting for vnet1 to become free. Usage count = 1
> > [ 9795.461526] unregister_netdevice: waiting for vnet6 to become free. Usage count = 1
> > [ 9801.523398] unregister_netdevice: waiting for vnet1 to become free. Usage count = 1
> > --
>
> Is the refcount stay forever to 1, or eventually reaches 0 ?
>
>
>
Stays 1 for as long as I waited about 10 minutes
--
^ permalink raw reply
* Re: [PATCH 0/5] bridge RCU patches (rev2)
From: David Miller @ 2010-11-15 19:13 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20101115163809.215552143@vyatta.com>
All applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] hso: Fix unused variable warning
From: David Miller @ 2010-11-15 19:13 UTC (permalink / raw)
To: alan; +Cc: netdev
In-Reply-To: <20101115173038.6846.72062.stgit@localhost.localdomain>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Mon, 15 Nov 2010 17:30:42 +0000
> From: Alan Cox <alan@linux.intel.com>
>
> Fallout from the TIOCGICOUNT work
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] enic: Fix build warnings
From: David Miller @ 2010-11-15 19:13 UTC (permalink / raw)
To: vkolluri; +Cc: netdev, roprabhu, dwang2
In-Reply-To: <20101115180955.5779.32244.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Mon, 15 Nov 2010 10:09:55 -0800
> From: Vasanthy Kolluri <vkolluri@cisco.com>
>
> Fix data type of argument passed to pci_alloc_consistent and pci_free_consistent routines.
>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
Applied, thank you.
^ permalink raw reply
* Re: ethtool maintenance
From: Jeff Garzik @ 2010-11-15 19:16 UTC (permalink / raw)
To: Ben Hutchings; +Cc: NetDev, David Miller
In-Reply-To: <1289832387.2586.10.camel@bwh-desktop>
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
On 11/15/2010 09:46 AM, Ben Hutchings wrote:
> On Sat, 2010-11-13 at 14:30 +0000, Ben Hutchings wrote:
>> On Sat, 2010-11-13 at 03:45 -0500, Jeff Garzik wrote:
>>> So, a recent emergency surgery has really set me back, work-wise.
>>> ethtool [the userspace utility] 2.6.36 is still not out, and personally
>>> it remains a third or fourth priority.
>>>
>>> While it's likely that I could get back to ethtool's patch queue next
>>> week, it continues to be low man on the totem pole. Seems only fair to
>>> see if anyone else is interested in maintaining it.
>>>
>>> I emailed Ben Hutchings privately about this, but haven't heard back, so
>>> I thought I'd go ahead and email the list.
>>>
>>> Anyone interested?
>>
>> I am interested, but will need to clear it with my boss before making
>> such a commitment.
>
> OK, this is fine. Are there any patches waiting other than mine and
> these?
>
> http://patchwork.ozlabs.org/patch/67662/
> http://patchwork.ozlabs.org/patch/68237/
> http://patchwork.ozlabs.org/patch/69155/
>
> I'll need to sort out my kernel.org account before I can publish a git
> tree.
I've attached an mbox.
In the short term, there is no need to wait, I can simply publish 'git
pull' requests from you, and push a release out to SF.
I would recommend moving the tarball release area away from SF in the
long term; SF is really going downhill.
Jeff
[-- Attachment #2: mbox.bz2 --]
[-- Type: application/x-bzip, Size: 23028 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] net: rtnetlink.h -- only include linux/netdevice.h when used by the kernel
From: David Miller @ 2010-11-15 19:30 UTC (permalink / raw)
To: apw; +Cc: eric.dumazet, netdev, linux-kernel, tim.gardner
In-Reply-To: <1289836919-19153-2-git-send-email-apw@canonical.com>
From: Andy Whitcroft <apw@canonical.com>
Date: Mon, 15 Nov 2010 16:01:59 +0000
> The commit below added a new helper dev_ingress_queue to cleanly obtain the
> ingress queue pointer. This necessitated including 'linux/netdevice.h':
...
> However this include triggers issues for applications in userspace
> which use the rtnetlink interfaces. Commonly this requires they include
> 'net/if.h' and 'linux/rtnetlink.h' leading to a compiler error as below:
>
> In file included from /usr/include/linux/netdevice.h:28:0,
> from /usr/include/linux/rtnetlink.h:9,
> from t.c:2:
> /usr/include/linux/if.h:135:8: error: redefinition of ‘struct ifmap’
> /usr/include/net/if.h:112:8: note: originally defined here
> /usr/include/linux/if.h:169:8: error: redefinition of ‘struct ifreq’
> /usr/include/net/if.h:127:8: note: originally defined here
> /usr/include/linux/if.h:218:8: error: redefinition of ‘struct ifconf’
> /usr/include/net/if.h:177:8: note: originally defined here
>
> The new helper is only defined for the kernel and protected by __KERNEL__
> therefore we can simply pull the include down into the same protected
> section.
>
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Applied, thanks Andy.
^ permalink raw reply
* Re: [PATCH 1/1] UDEV - Add 'udevlom' command line param to start_udev
From: Rick Jones @ 2010-11-15 19:32 UTC (permalink / raw)
To: Ben Hutchings
Cc: Matt Domsch, Greg KH, K, Narendra, linux-hotplug@vger.kernel.org,
netdev@vger.kernel.org, Hargrave, Jordan, Rose, Charles
In-Reply-To: <1289841399.2586.18.camel@bwh-desktop>
>>I'm getting a lot of pushback from Dell customers on our
>>linux-poweredge mailing list (thread starts [1]) that the choice of
>>name "lomX" is poor, due to HP's extensive use of LOM meaning Lights
>>Out Management, rather than my intended meaning of "LAN on
>>Motherboard". Gotta hate TLA collisions.
I think Sun (sorry, Oracle) push LOM for Lights-Out Management quite a lot -
calling their service processor an iLOM IIRC.
>>So, I'm open to new ideas for naming these. At LPC, Ted noted that
>>2- and 3-letter names are expected. "nic[1234]" or "en[1234]" ?
>
> [...]
>
> I would suggest avoiding "nic" since some people use "NIC" to mean
> specifically an add-in card rather than LOM. In addition there is some
> ambiguity with multi-port cards/controllers of whether NIC means a
> controller or a port.
>
> Other options for the prefix:
> - "lan". Maybe too generic.
yes and no - that is the prefix for "ethernet" network interface names in HP-UX,
going back decades. so, there is precedent for that, and given the way HP-UX
device name persistence works, 99 times out of ten, the "built-in" or "core" LAN
interfaces ended-up being enumerated starting from zero - lan0, lan1, etc.
(There are exceptions relating to certain modles of systems and a full
re-install of the OS with add-on cards present but that is a story for another
thread).
> - "mbe" = MotherBoard Ethernet. Looks a bit like "GbE" as some OEMs put
> on the port labels.
Collides with Multi-Bit Error.
> - "eom" = Ethernet On Motherboard
Collides with End of Message.
If there is indeed *no* way to get then named eth[1-N], and "lan" doesn't
resonate well-enough, then my contribution to the bikeshed would be "cor" simply
because I don't know the TLA with which that collides :)
Are folks sufficently confident that using anything other than "eth" won't cause
some unpleasant "our app always ass-u-me-d interfaces started with 'eth'"
situations?
rick jones
^ permalink raw reply
* the future of ethtool
From: Jeff Garzik @ 2010-11-15 19:41 UTC (permalink / raw)
To: Ben Hutchings; +Cc: NetDev, David Miller
Thanks for accepting ethtool maintainership.
There are two key unresolved issues with ethtool that are worth noting
to the next maintainer. Both of these come from years of user and
customer complaints.
1) ethtool command line interface.
For 1,001 minor reasons of user taste and expectation, people tend to
complain about the command line interface. Due to script usage it is
set in stone, and has been since before my tenure. But users
continually request something more flexible, often, in particular,
wanting to set multiple settings in one execution, or wanting to apply
the same setting to multiple interface in one execution.
Obviously one can script this, but, it is probably the #1 user request.
My thought was to create "nictool", a new tool with more flexible
command line interface, using the same old ethtool ioctls currently in
use today. ('nictool' also solves a minor naming complaint from
wireless and other people, who use ethtool on non-ethernet network
interfaces)
2) multiple settings and the ethtool kernel interface
Another common complaint is related to multiple settings, and associated
hardware NIC resets.
Many ethtool driver implementations look like this:
ethtool_op_do_something()
stop RX/TX
apply settings
perform full NIC reset, consuming much time
start RX/TX
The problem arises when the user wishes to change multiple hardware
attributes at the same time. A user wishing to change 4 attributes
could wind up with 4 ethtool(1) invocations, with 4 accompanying
hardware NIC resets. Time consuming, inefficient, and unnecessary.
Obviously the world has not ended without these changes, but these items
do cause continued complaints from users, and we're here to be
responsive to users presumably ;-)
Jeff
^ permalink raw reply
* Re: [RFC PATCH] network: return errors if we know tcp_connect failed
From: Alexey Kuznetsov @ 2010-11-15 20:00 UTC (permalink / raw)
To: Eric Paris
Cc: Patrick McHardy, Hua Zhong, netdev, linux-kernel, davem, pekkas,
jmorris, yoshfuji
In-Reply-To: <1289836066.14282.7.camel@localhost.localdomain>
Hello!
On Mon, Nov 15, 2010 at 10:47:46AM -0500, Eric Paris wrote:
> Well I'm (I guess?) surprised that the --reject-with icmp doesn't do
> anything with a local outgoing connection
Yeah. This was "an obvious surpise": for local socket the first icmp error always
arrives on locked socket and gets dropped. I even forgot about this (tcp-reset
still works ok due to backlog) This makes the idea to respect error more attractive.
Alexey
^ permalink raw reply
* [PATCH 00/11] Remove unnecessary casts of pci_get_drvdata
From: Joe Perches @ 2010-11-15 20:13 UTC (permalink / raw)
To: Jiri Kosina
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw
Joe Perches (11):
drivers/i2c/busses/i2c-nforce2.c: Remove unnecessary casts of pci_get_drvdata
drivers/ide/pmac.c: Remove unnecessary casts of pci_get_drvdata
drivers/media/dvb/ngene/ngene-core.c: Remove unnecessary casts of pci_get_drvdata
drivers/misc/ibmasm/module.c: Remove unnecessary casts of pci_get_drvdata
drivers/net/irda: Remove unnecessary casts of pci_get_drvdata
drivers/net/s2io.c: Remove unnecessary casts of pci_get_drvdata
drivers/net/vxge/vxge-main.c: Remove unnecessary casts of pci_get_drvdata
drivers/scsi/be2iscsi/be_main.c: Remove unnecessary casts of pci_get_drvdata
drivers/staging: Remove unnecessary casts of pci_get_drvdata
drivers/usb/host/uhci-hcd.c: Remove unnecessary casts of pci_get_drvdata
sound/pci/asihpi/hpioctl.c: Remove unnecessary casts of pci_get_drvdata
drivers/i2c/busses/i2c-nforce2.c | 2 +-
drivers/ide/pmac.c | 4 ++--
drivers/media/dvb/ngene/ngene-core.c | 2 +-
drivers/misc/ibmasm/module.c | 2 +-
drivers/net/irda/donauboe.c | 6 +++---
drivers/net/irda/vlsi_ir.c | 2 +-
drivers/net/s2io.c | 3 +--
drivers/net/vxge/vxge-main.c | 28 ++++++++++++----------------
drivers/scsi/be2iscsi/be_main.c | 2 +-
drivers/staging/crystalhd/crystalhd_lnx.c | 6 +++---
drivers/staging/et131x/et131x_initpci.c | 2 +-
drivers/staging/wlags49_h2/wl_pci.c | 2 +-
drivers/usb/host/uhci-hcd.c | 2 +-
sound/pci/asihpi/hpioctl.c | 2 +-
14 files changed, 30 insertions(+), 35 deletions(-)
--
1.7.3.1.g432b3.dirty
^ permalink raw reply
* [PATCH 05/11] drivers/net/irda: Remove unnecessary casts of pci_get_drvdata
From: Joe Perches @ 2010-11-15 20:13 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Samuel Ortiz, netdev, linux-kernel
In-Reply-To: <cover.1289851770.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/irda/donauboe.c | 6 +++---
drivers/net/irda/vlsi_ir.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/irda/donauboe.c b/drivers/net/irda/donauboe.c
index b626ccc..bee5ccc 100644
--- a/drivers/net/irda/donauboe.c
+++ b/drivers/net/irda/donauboe.c
@@ -1488,7 +1488,7 @@ static void
toshoboe_close (struct pci_dev *pci_dev)
{
int i;
- struct toshoboe_cb *self = (struct toshoboe_cb*)pci_get_drvdata(pci_dev);
+ struct toshoboe_cb *self = pci_get_drvdata(pci_dev);
IRDA_DEBUG (4, "%s()\n", __func__);
@@ -1698,7 +1698,7 @@ freeself:
static int
toshoboe_gotosleep (struct pci_dev *pci_dev, pm_message_t crap)
{
- struct toshoboe_cb *self = (struct toshoboe_cb*)pci_get_drvdata(pci_dev);
+ struct toshoboe_cb *self = pci_get_drvdata(pci_dev);
unsigned long flags;
int i = 10;
@@ -1727,7 +1727,7 @@ toshoboe_gotosleep (struct pci_dev *pci_dev, pm_message_t crap)
static int
toshoboe_wakeup (struct pci_dev *pci_dev)
{
- struct toshoboe_cb *self = (struct toshoboe_cb*)pci_get_drvdata(pci_dev);
+ struct toshoboe_cb *self = pci_get_drvdata(pci_dev);
unsigned long flags;
IRDA_DEBUG (4, "%s()\n", __func__);
diff --git a/drivers/net/irda/vlsi_ir.c b/drivers/net/irda/vlsi_ir.c
index c3d0738..62f2d12 100644
--- a/drivers/net/irda/vlsi_ir.c
+++ b/drivers/net/irda/vlsi_ir.c
@@ -542,7 +542,7 @@ static int vlsi_process_rx(struct vlsi_ring *r, struct ring_descr *rd)
int crclen, len = 0;
struct sk_buff *skb;
int ret = 0;
- struct net_device *ndev = (struct net_device *)pci_get_drvdata(r->pdev);
+ struct net_device *ndev = pci_get_drvdata(r->pdev);
vlsi_irda_dev_t *idev = netdev_priv(ndev);
pci_dma_sync_single_for_cpu(r->pdev, rd_get_addr(rd), r->len, r->dir);
--
1.7.3.1.g432b3.dirty
^ permalink raw reply related
* [PATCH 06/11] drivers/net/s2io.c: Remove unnecessary casts of pci_get_drvdata
From: Joe Perches @ 2010-11-15 20:13 UTC (permalink / raw)
To: Jiri Kosina
Cc: Ramkrishna Vepa, Sivakumar Subramani, Sreenivasa Honnur,
Jon Mason, netdev, linux-kernel
In-Reply-To: <cover.1289851770.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/s2io.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index ecc25aa..0f4219c 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -8321,8 +8321,7 @@ mem_alloc_failed:
static void __devexit s2io_rem_nic(struct pci_dev *pdev)
{
- struct net_device *dev =
- (struct net_device *)pci_get_drvdata(pdev);
+ struct net_device *dev = pci_get_drvdata(pdev);
struct s2io_nic *sp;
if (dev == NULL) {
--
1.7.3.1.g432b3.dirty
^ permalink raw reply related
* [PATCH 07/11] drivers/net/vxge/vxge-main.c: Remove unnecessary casts of pci_get_drvdata
From: Joe Perches @ 2010-11-15 20:13 UTC (permalink / raw)
To: Jiri Kosina
Cc: Ramkrishna Vepa, Sivakumar Subramani, Sreenivasa Honnur,
Jon Mason, netdev, linux-kernel
In-Reply-To: <cover.1289851770.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/vxge/vxge-main.c | 28 ++++++++++++----------------
1 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/net/vxge/vxge-main.c b/drivers/net/vxge/vxge-main.c
index 3f2d6ed..22c7d79 100644
--- a/drivers/net/vxge/vxge-main.c
+++ b/drivers/net/vxge/vxge-main.c
@@ -688,7 +688,7 @@ static int vxge_learn_mac(struct vxgedev *vdev, u8 *mac_header)
struct vxge_vpath *vpath = NULL;
struct __vxge_hw_device *hldev;
- hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
+ hldev = pci_get_drvdata(vdev->pdev);
mac_address = (u8 *)&mac_addr;
memcpy(mac_address, mac_header, ETH_ALEN);
@@ -1313,7 +1313,7 @@ static void vxge_vpath_intr_disable(struct vxgedev *vdev, int vp_id)
struct __vxge_hw_device *hldev;
int msix_id;
- hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
+ hldev = pci_get_drvdata(vdev->pdev);
vxge_hw_vpath_wait_receive_idle(hldev, vpath->device_id);
@@ -1632,8 +1632,7 @@ static int vxge_poll_inta(struct napi_struct *napi, int budget)
int budget_org = budget;
struct vxge_ring *ring;
- struct __vxge_hw_device *hldev = (struct __vxge_hw_device *)
- pci_get_drvdata(vdev->pdev);
+ struct __vxge_hw_device *hldev = pci_get_drvdata(vdev->pdev);
for (i = 0; i < vdev->no_of_vpath; i++) {
ring = &vdev->vpaths[i].ring;
@@ -1673,7 +1672,7 @@ static void vxge_netpoll(struct net_device *dev)
struct vxgedev *vdev;
vdev = (struct vxgedev *)netdev_priv(dev);
- hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
+ hldev = pci_get_drvdata(vdev->pdev);
vxge_debug_entryexit(VXGE_TRACE, "%s:%d", __func__, __LINE__);
@@ -2107,7 +2106,7 @@ static irqreturn_t vxge_isr_napi(int irq, void *dev_id)
vxge_debug_intr(VXGE_TRACE, "%s:%d", __func__, __LINE__);
dev = vdev->ndev;
- hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
+ hldev = pci_get_drvdata(vdev->pdev);
if (pci_channel_offline(vdev->pdev))
return IRQ_NONE;
@@ -2342,7 +2341,7 @@ static void vxge_rem_msix_isr(struct vxgedev *vdev)
static void vxge_rem_isr(struct vxgedev *vdev)
{
struct __vxge_hw_device *hldev;
- hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
+ hldev = pci_get_drvdata(vdev->pdev);
#ifdef CONFIG_PCI_MSI
if (vdev->config.intr_type == MSI_X) {
@@ -2583,7 +2582,7 @@ vxge_open(struct net_device *dev)
"%s: %s:%d", dev->name, __func__, __LINE__);
vdev = (struct vxgedev *)netdev_priv(dev);
- hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
+ hldev = pci_get_drvdata(vdev->pdev);
function_mode = vdev->config.device_hw_info.function_mode;
/* make sure you have link off by default every time Nic is
@@ -2811,7 +2810,7 @@ static int do_vxge_close(struct net_device *dev, int do_io)
dev->name, __func__, __LINE__);
vdev = (struct vxgedev *)netdev_priv(dev);
- hldev = (struct __vxge_hw_device *)pci_get_drvdata(vdev->pdev);
+ hldev = pci_get_drvdata(vdev->pdev);
if (unlikely(!is_vxge_card_up(vdev)))
return 0;
@@ -3985,8 +3984,7 @@ static int vxge_pm_resume(struct pci_dev *pdev)
static pci_ers_result_t vxge_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
{
- struct __vxge_hw_device *hldev =
- (struct __vxge_hw_device *)pci_get_drvdata(pdev);
+ struct __vxge_hw_device *hldev = pci_get_drvdata(pdev);
struct net_device *netdev = hldev->ndev;
netif_device_detach(netdev);
@@ -4015,8 +4013,7 @@ static pci_ers_result_t vxge_io_error_detected(struct pci_dev *pdev,
*/
static pci_ers_result_t vxge_io_slot_reset(struct pci_dev *pdev)
{
- struct __vxge_hw_device *hldev =
- (struct __vxge_hw_device *)pci_get_drvdata(pdev);
+ struct __vxge_hw_device *hldev = pci_get_drvdata(pdev);
struct net_device *netdev = hldev->ndev;
struct vxgedev *vdev = netdev_priv(netdev);
@@ -4041,8 +4038,7 @@ static pci_ers_result_t vxge_io_slot_reset(struct pci_dev *pdev)
*/
static void vxge_io_resume(struct pci_dev *pdev)
{
- struct __vxge_hw_device *hldev =
- (struct __vxge_hw_device *)pci_get_drvdata(pdev);
+ struct __vxge_hw_device *hldev = pci_get_drvdata(pdev);
struct net_device *netdev = hldev->ndev;
if (netif_running(netdev)) {
@@ -4689,7 +4685,7 @@ static void __devexit vxge_remove(struct pci_dev *pdev)
struct net_device *dev;
int i = 0;
- hldev = (struct __vxge_hw_device *)pci_get_drvdata(pdev);
+ hldev = pci_get_drvdata(pdev);
if (hldev == NULL)
return;
--
1.7.3.1.g432b3.dirty
^ permalink raw reply related
* Re: the future of ethtool
From: Ben Hutchings @ 2010-11-15 20:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: NetDev, David Miller
In-Reply-To: <4CE18CEA.5080502@garzik.org>
On Mon, 2010-11-15 at 14:41 -0500, Jeff Garzik wrote:
> Thanks for accepting ethtool maintainership.
>
> There are two key unresolved issues with ethtool that are worth noting
> to the next maintainer. Both of these come from years of user and
> customer complaints.
>
> 1) ethtool command line interface.
>
> For 1,001 minor reasons of user taste and expectation, people tend to
> complain about the command line interface. Due to script usage it is
> set in stone, and has been since before my tenure. But users
> continually request something more flexible, often, in particular,
> wanting to set multiple settings in one execution, or wanting to apply
> the same setting to multiple interface in one execution.
>
> Obviously one can script this, but, it is probably the #1 user request.
Thinking further along those lines, it would be useful to have ethtool
API bindings for Perl/Python/whatever, though those belong outside of
the current ethtool package. I tried doing that for use in my own
scripts and it looks reasonably practical, though I'm not volunteering
to maintain such bindings.
> My thought was to create "nictool", a new tool with more flexible
> command line interface, using the same old ethtool ioctls currently in
> use today. ('nictool' also solves a minor naming complaint from
> wireless and other people, who use ethtool on non-ethernet network
> interfaces)
I agree, some of the ethtool operations are very Ethernet-specific but
enough of them are applicable to other media that this makes sense.
I've recently been looking at FreeBSD where the sort of configuration we
do through ethtool is invoked through ifconfig, but then ifconfig is
effectively deprecated on Linux...
> 2) multiple settings and the ethtool kernel interface
>
> Another common complaint is related to multiple settings, and associated
> hardware NIC resets.
>
> Many ethtool driver implementations look like this:
>
> ethtool_op_do_something()
> stop RX/TX
> apply settings
> perform full NIC reset, consuming much time
> start RX/TX
>
> The problem arises when the user wishes to change multiple hardware
> attributes at the same time. A user wishing to change 4 attributes
> could wind up with 4 ethtool(1) invocations, with 4 accompanying
> hardware NIC resets. Time consuming, inefficient, and unnecessary.
Right. In fact the begin() and complete() operations look like they
were meant to support this sort of optimisation. Is that the case?
Ben.
> Obviously the world has not ended without these changes, but these items
> do cause continued complaints from users, and we're here to be
> responsive to users presumably ;-)
--
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: the future of ethtool
From: Stephen Hemminger @ 2010-11-15 20:44 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Jeff Garzik, NetDev, David Miller
In-Reply-To: <1289852326.2586.32.camel@bwh-desktop>
On Mon, 15 Nov 2010 20:18:46 +0000
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Mon, 2010-11-15 at 14:41 -0500, Jeff Garzik wrote:
> > Thanks for accepting ethtool maintainership.
> >
> > There are two key unresolved issues with ethtool that are worth noting
> > to the next maintainer. Both of these come from years of user and
> > customer complaints.
> >
> > 1) ethtool command line interface.
> >
> > For 1,001 minor reasons of user taste and expectation, people tend to
> > complain about the command line interface. Due to script usage it is
> > set in stone, and has been since before my tenure. But users
> > continually request something more flexible, often, in particular,
> > wanting to set multiple settings in one execution, or wanting to apply
> > the same setting to multiple interface in one execution.
> >
> > Obviously one can script this, but, it is probably the #1 user request.
>
> Thinking further along those lines, it would be useful to have ethtool
> API bindings for Perl/Python/whatever, though those belong outside of
> the current ethtool package. I tried doing that for use in my own
> scripts and it looks reasonably practical, though I'm not volunteering
> to maintain such bindings.
>
> > My thought was to create "nictool", a new tool with more flexible
> > command line interface, using the same old ethtool ioctls currently in
> > use today. ('nictool' also solves a minor naming complaint from
> > wireless and other people, who use ethtool on non-ethernet network
> > interfaces)
>
> I agree, some of the ethtool operations are very Ethernet-specific but
> enough of them are applicable to other media that this makes sense.
>
> I've recently been looking at FreeBSD where the sort of configuration we
> do through ethtool is invoked through ifconfig, but then ifconfig is
> effectively deprecated on Linux...
>
> > 2) multiple settings and the ethtool kernel interface
> >
> > Another common complaint is related to multiple settings, and associated
> > hardware NIC resets.
> >
> > Many ethtool driver implementations look like this:
> >
> > ethtool_op_do_something()
> > stop RX/TX
> > apply settings
> > perform full NIC reset, consuming much time
> > start RX/TX
> >
> > The problem arises when the user wishes to change multiple hardware
> > attributes at the same time. A user wishing to change 4 attributes
> > could wind up with 4 ethtool(1) invocations, with 4 accompanying
> > hardware NIC resets. Time consuming, inefficient, and unnecessary.
>
> Right. In fact the begin() and complete() operations look like they
> were meant to support this sort of optimisation. Is that the case?
>
> Ben.
>
> > Obviously the world has not ended without these changes, but these items
> > do cause continued complaints from users, and we're here to be
> > responsive to users presumably ;-)
>
>
My views are simple:
Ethtool needs to be an extension of existing netlink API for interfaces.
- handles multiple values per transaction
- extensible
Someone has to write good libraries to access netlink from Perl/Python/C++.
The best so far is libmnl.
--
^ permalink raw reply
* [PATCH] gianfar: fix signedness issue
From: Nicolas Kaiser @ 2010-11-15 20:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, kernel-janitors, linux-kernel
irq_of_parse_and_map() has an unsigned return type.
Testing for a negative error value doesn't work here.
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
---
I see that in numerous places the return value is tested
for NO_IRQ. I hope it's the right thing to do here as well?
drivers/net/gianfar.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 49e4ce1..d1bec62 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -577,11 +577,10 @@ static int gfar_parse_group(struct device_node *np,
irq_of_parse_and_map(np, 1);
priv->gfargrp[priv->num_grps].interruptError =
irq_of_parse_and_map(np,2);
- if (priv->gfargrp[priv->num_grps].interruptTransmit < 0 ||
- priv->gfargrp[priv->num_grps].interruptReceive < 0 ||
- priv->gfargrp[priv->num_grps].interruptError < 0) {
+ if (priv->gfargrp[priv->num_grps].interruptTransmit == NO_IRQ ||
+ priv->gfargrp[priv->num_grps].interruptReceive == NO_IRQ ||
+ priv->gfargrp[priv->num_grps].interruptError == NO_IRQ)
return -EINVAL;
- }
}
priv->gfargrp[priv->num_grps].grp_id = priv->num_grps;
--
1.7.2.2
^ permalink raw reply related
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