* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: Hannes Reinecke @ 2009-10-30 7:45 UTC (permalink / raw)
To: Kay Sievers
Cc: Matt Domsch, dann frazier, linux-hotplug, Narendra_K, netdev,
Jordan_Hargrave, Charles_Rose, Ben Hutchings
In-Reply-To: <ac3eb2510910280123g3c0e3d95wb38a239238906027@mail.gmail.com>
Kay Sievers wrote:
> On Tue, Oct 27, 2009 at 21:55, Matt Domsch <Matt_Domsch@dell.com> wrote:
>> On Thu, Oct 22, 2009 at 12:36:20AM -0600, dann frazier wrote:
>>> Here's a proof of concept to further the discussion..
>>>
>>> The default filename uses the format:
>>> /dev/netdev/by-ifindex/$ifindex
>>>
>>> This provides the infrastructure to permit udev rules to create aliases for
>>> network devices using symlinks, for example:
>>>
>>> /dev/netdev/by-name/eth0 -> ../by-ifindex/1
>>> /dev/netdev/by-biosname/LOM0 -> ../by-ifindex/3
>>>
>>> A library (such as the proposed libnetdevname) could use this information
>>> to provide an alias->realname mapping for network utilities.
>> yes, this could work, as IFINDEX is already exported in the uevents,
>> and that's the primary value udev needs to set up the mapping.
>>
>> While I like the little ifindex2name script you've got, I think udev
>> could simply call if_indextoname() to get this, and not call an
>> external program? I suppose it could be a really really simple
>> external program too.
>
> What's the point of all this? Why would udev ever need to find the
> name of a device by the ifindex? The device name is the primary value
> for the kernel events udev acts on.
>
>> I'd be fine with this approach. It has the advantages of not
>> requiring a kernel change at all, and not creating a whole character
>> device which would be useless. And it doesn't preclude someone in the
>> future from creating a char device for network devices should they so
>> choose.
>>
>> Kay, what say you as udev owner?
>
> That all sounds very much like something which will hit us back some
> day. I'm not sure, if udev should publish such dead text files in
> /dev, it does not seem to fit the usual APIs/assumptions where /sys
> and /dev match, and libudev provides access to both. It all sounds
> more like a database for a possible netdevname library, which does not
> need to be public in /dev, right?
>
And to throw in some bit of useless information;
I've pondered the idea of persistent device names for network interfaces
a while back when designing the original layout of the persistent
device naming scheme.
The one reason I didn't to this was that a network interface is
_not_ a file, but rather an abstract type which is known only internally
in the kernel (ie the one exemption from the 'everything is a file'
UNIX rule).
And as udev is primarily concerned with the _files_, using it for
network interfaces would be a workaround at best.
When I were to design this, I would be implementing network interface
_aliases_, so that a network interface could be accessed either by
name or by alias. This mechanism can then be managed by udev, much
like we (ie SUSE) is using it nowadays to assign the network interface
numbers.
But the mechanism for the aliases has to live in the same instance which
also handles the network interface nowadays, ie the net subsystem of
the kernel. Implementing this in udev is _not_ the way to go.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v3 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-30 7:22 UTC (permalink / raw)
To: netdev; +Cc: Fleming Andy-AFLEMING, David Miller
In-Reply-To: <20091029.212142.189578068.davem@davemloft.net>
>Did you try the bundle I posted yesterday which failed? This
>one is identical, you didn't change anything.
>
>This is getting rediculious.
>
>Try again, and when you do take the patches from patchwork at:
>
> http://patchwork.ozlabs.org/project/netdev/list/
>
>and you try to apply them to net-next-2.6 using git (_not_
>'patch', 'patch' is way too lenient about fuzz and line
>offsets) so that you can see what's happening.
>
>I'm completely ignoring your patch postings until you sort this out.
1. The patch failure is due to the absence of following commit in
net-next-2.6 tree.
commit e72701acbe0b35e52d3f04d442837c06b4e64f1c
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed Oct 14 14:54:52 2009 -0700
net: Fix OF platform drivers coldplug/hotplug when compiled
as modules
Some OF platform drivers are missing module device tables,
so they won't
load automatically on boot. This patch fixes the issue by
adding proper
MODULE_DEVICE_TABLE() macros to the drivers.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2. The git clone DOES NOT show the changes affected by the above patch
3. If we take a log of the affected file(fsl_pq_mdio.c), then it DOES
show the commit/changes
(Gitweb:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=histo
ry;f=drivers/net/fsl_pq_mdio.c;h=6ac4648669728421b934d32646ffbb626128387
6;hb=HEAD)
4. If we take the log of the tree, the same commit is NOT visible.
(Gitweb:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=log)
5. If we take a Snapshot of the tree, the changes to the file are
present. (in the tarball)
To sum up, the Clone and Tree log DOES NOT show the changes.
The Snapshot and file log DOES show it.
We have tried it on multiple machine/tree clones here.
Is there some problem with the Git tree itself?
>
>You cannot have line offsets or fuzz when you send patches
>that are to be applied by GIT, and that is the problem with patch #4:
>
>davem@sunset:~/src/GIT/net-next-2.6$ patch -p1 <diff patching
>file drivers/net/fsl_pq_mdio.c Hunk #6 succeeded at 436 with fuzz 1.
>patching file drivers/net/fsl_pq_mdio.h
>
>GIT does not allow line fuzz, you must make absolutely
>pristine patches, and therefore if you are testing your
>submission with just 'patch' that absolutely will not work.
No we are using git-am.
We did try this on multiple clones of the net-next-2.6 tree.
>
>Thanks.
>--
>To unsubscribe from this list: send the line "unsubscribe
>netdev" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Thanks
Sandeep
^ permalink raw reply
* [PATCH net-next-2.6] veth: Fix veth_dellink method
From: Eric Dumazet @ 2009-10-30 7:00 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List, Pavel Emelyanov
In commit 23289a37e2b127dfc4de1313fba15bb4c9f0cd5b
(net: add a list_head parameter to dellink() method),
I forgot to actually use this parameter in veth_dellink.
I remember feeling a bit uncomfortable about veth_close(),
because it does :
netif_carrier_off(dev);
netif_carrier_off(priv->peer);
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index ffb502d..9bed694 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -450,8 +450,8 @@ static void veth_dellink(struct net_device *dev, struct list_head *head)
priv = netdev_priv(dev);
peer = priv->peer;
- unregister_netdevice(dev);
- unregister_netdevice(peer);
+ unregister_netdevice_queue(dev, head);
+ unregister_netdevice_queue(peer, head);
}
static const struct nla_policy veth_policy[VETH_INFO_MAX + 1];
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2009-10-28
From: Johannes Berg @ 2009-10-30 7:00 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Pekka Enberg, David Miller, linux-wireless, netdev, linux-kernel,
linville
In-Reply-To: <200910292248.42229.bzolnier@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Thu, 2009-10-29 at 22:48 +0100, Bartlomiej Zolnierkiewicz wrote:
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
So you know how to make the driver better, whine that it doesn't work,
but don't help out either. Hey, good way to collaborate!
> > It should be pretty obvious by now that the best way to improve things
> > is to work with the relevant maintainers, not against them. (Unless
> > you wish your work to be ignored, of course.)
>
> I work with a lot of other maintainers. I would say that providing valuable
> review feedback is also "working with" (at least I would be very happy with
> such feedback in my projects).
Face it though, people have read your feedback, thought about it, and
decided to disagree. You seem to have a childish problem with that,
appealing to higher authority to get your way just makes you look more
childish.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] vlan: Optimize multiple unregistration
From: David Miller @ 2009-10-30 6:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: kaber, netdev
In-Reply-To: <4AEA8813.9090505@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 30 Oct 2009 07:30:43 +0100
> Patrick McHardy a écrit :
>> Eric Dumazet wrote:
>>> Patrick McHardy a écrit :
>>>
>>>> Indeed, but unregister_vlan_dev() destroys the group once the
>>>> count has reached zero, so we must not access it after that.
>>> Well, I hoped call_rcu() callback doesnt fire and kfree(grp) until we exited
>>> from unregister_vlan_dev_alls(), with RTNL locked...
>>
>> The RTNL is a mutex, so it shouldn't prevent call_rcu from firing.
>
> Oops this is totally right of course, so your patch is actually a bug fix :)
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
I've applied Patrick's patch, thanks everyone.
^ permalink raw reply
* Re: [PATCH 0/6] Bonding simplifications and netns support
From: David Miller @ 2009-10-30 6:40 UTC (permalink / raw)
To: dada1; +Cc: ebiederm, netdev, fubar
In-Reply-To: <4AEA89E9.30902@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Fri, 30 Oct 2009 07:38:33 +0100
> I have patches against bond driver for unregister_netdevice_queue() stuff,
> I'll wait for Eric work being committed first.
Ok, thanks for the heads up.
^ permalink raw reply
* Re: [PATCH 0/6] Bonding simplifications and netns support
From: Eric Dumazet @ 2009-10-30 6:38 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, netdev, fubar
In-Reply-To: <20091029.232523.66969302.davem@davemloft.net>
David Miller a écrit :
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Thu, 29 Oct 2009 17:16:54 -0700
>
>> I recently had it pointed out to me that the bonding driver does not
>> work in a network namespace. So I have simplified the bonding driver
>> a bit, added support for ip link add and ip link del, and finally made
>> the bonding driver work in multiple network namespaces.
>>
>> The most note worthy change in the patchset is the addition of support
>> in the networking core for registering a sysfs group for a device.
>>
>> Using this in the bonding driver simplifies the code and removes a
>> userspace race between actions triggered by the netlink event and the
>> bonding sysfs attributes appearing.
>
> I have no objections to these patches, but I'd like the bonding
> folks to have a chance to look at it before I apply to net-next-2.6
>
> One question though, are you sure this clever extra slot scheme
> in patch #1 works for, f.e., a bond of wireless devices? It seems
> like it would work out, but I wanted to ask to make sure you
> considered that case.
>
I have patches against bond driver for unregister_netdevice_queue() stuff,
I'll wait for Eric work being committed first.
Thanks
^ permalink raw reply
* Re: [PATCH 4/6] vlan: Optimize multiple unregistration
From: Eric Dumazet @ 2009-10-30 6:30 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AE9D000.90603@trash.net>
Patrick McHardy a écrit :
> Eric Dumazet wrote:
>> Patrick McHardy a écrit :
>>
>>> Indeed, but unregister_vlan_dev() destroys the group once the
>>> count has reached zero, so we must not access it after that.
>> Well, I hoped call_rcu() callback doesnt fire and kfree(grp) until we exited
>> from unregister_vlan_dev_alls(), with RTNL locked...
>
> The RTNL is a mutex, so it shouldn't prevent call_rcu from firing.
Oops this is totally right of course, so your patch is actually a bug fix :)
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 0/6] Bonding simplifications and netns support
From: David Miller @ 2009-10-30 6:25 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, fubar
In-Reply-To: <m1tyxhwxah.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 29 Oct 2009 17:16:54 -0700
> I recently had it pointed out to me that the bonding driver does not
> work in a network namespace. So I have simplified the bonding driver
> a bit, added support for ip link add and ip link del, and finally made
> the bonding driver work in multiple network namespaces.
>
> The most note worthy change in the patchset is the addition of support
> in the networking core for registering a sysfs group for a device.
>
> Using this in the bonding driver simplifies the code and removes a
> userspace race between actions triggered by the netlink event and the
> bonding sysfs attributes appearing.
I have no objections to these patches, but I'd like the bonding
folks to have a chance to look at it before I apply to net-next-2.6
One question though, are you sure this clever extra slot scheme
in patch #1 works for, f.e., a bond of wireless devices? It seems
like it would work out, but I wanted to ask to make sure you
considered that case.
Thanks.
^ permalink raw reply
* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: Marco d'Itri @ 2009-10-30 6:22 UTC (permalink / raw)
To: dann frazier
Cc: Greg KH, Matt Domsch, Kay Sievers, linux-hotplug, Narendra_K,
netdev, Jordan_Hargrave, Charles_Rose, Ben Hutchings
In-Reply-To: <20091030053824.GA25540@ldl.fc.hp.com>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Oct 30, dann frazier <dannf@hp.com> wrote:
> On Fri, Oct 30, 2009 at 04:30:29AM +0100, Marco d'Itri wrote:
> > On Oct 29, dann frazier <dannf@dannf.org> wrote:
> >
> > > That would make a lot of users much happier (myself included), but it
> > > does restrict us into one view. At different times, admins think of
> > > their NICs by different properties. I may want to do IP assignment by
> > [Citation needed]
> Is "I" not clear, or do you just not believe I admin servers?
I was referring to "At different times, admins think of their NICs by
different properties", which I am not sure is a valid generalization.
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Fix checks on unsigned in w90p910_ether_probe()
From: Wan ZongShun @ 2009-10-30 6:18 UTC (permalink / raw)
To: David Miller, roel.kluin; +Cc: netdev, akpm, linux-arm-kernel
In-Reply-To: <20091029.230624.125832796.davem@davemloft.net>
Dear sirs,
Okay, it is right, thanks all for your help.
I will re-fix it later.
2009/10/30, David Miller <davem@davemloft.net>:
> From: Roel Kluin <roel.kluin@gmail.com>
> Date: Tue, 20 Oct 2009 20:14:36 +0200
>
> > ether->txirq and ->rxirq are unsigned
> >
> > Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>
> platform_get_irq() returns a signed int so the intention
> is more likely that catching negative value returns
> was intended.
>
> Probably the correct fix is to mark txirq and rxirq as
> plain 'int'.
>
--
Wan z.s
^ permalink raw reply
* Re: [PATCH] ax25: unsigned cannot be less than 0 in ax25_ctl_ioctl()
From: David Miller @ 2009-10-30 6:06 UTC (permalink / raw)
To: roel.kluin; +Cc: kevind, wharms, linux-hams, netdev, jreuter, akpm
In-Reply-To: <4AD5EDA6.4040709@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Wed, 14 Oct 2009 17:26:30 +0200
> struct ax25_ctl_struct member `arg' is unsigned and cannot be less
> than 0.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [patch]convert kaweth to use usb_reset_configuration()
From: David Miller @ 2009-10-30 6:07 UTC (permalink / raw)
To: oliver; +Cc: sarah.a.sharp, netdev
In-Reply-To: <200910291607.12382.oliver@neukum.org>
From: Oliver Neukum <oliver@neukum.org>
Date: Thu, 29 Oct 2009 16:07:12 +0100
> For USB 3.0 it is necessary that all drivers use the standard
> API to reset a configuration. This removes a home-grown
> implementation.
>
> Signed-off-by: Oliver Neukum <oliver@neukum.org>
>
> Hi David,
>
> please take this for the next merge window.
Applied to net-next-2.6, thanks Oliver.
^ permalink raw reply
* Re: [PATCH] net: Fix checks on unsigned in w90p910_ether_probe()
From: David Miller @ 2009-10-30 6:06 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm, mcuos.com
In-Reply-To: <4ADDFE0C.3020400@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Tue, 20 Oct 2009 20:14:36 +0200
> ether->txirq and ->rxirq are unsigned
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
platform_get_irq() returns a signed int so the intention
is more likely that catching negative value returns
was intended.
Probably the correct fix is to mark txirq and rxirq as
plain 'int'.
^ permalink raw reply
* Re: [PATCH against V2]NET/KS8695: add support NAPI for Rx
From: David Miller @ 2009-10-30 6:00 UTC (permalink / raw)
To: figo1802; +Cc: dsilvers, netdev, ben
In-Reply-To: <1256825088.2148.77.camel@myhost>
From: "Figo.zhang" <figo1802@gmail.com>
Date: Thu, 29 Oct 2009 22:04:48 +0800
>
> Add support NAPI Rx API for KS8695NET driver.
You're not adding NAPI support in this patch.
Instead, you're fixing up the implementation based upon feedback
you've received on this list.
Please correct your commit message and subject line and resubmit.
Thank you.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pekka Enberg @ 2009-10-30 5:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <200910292248.42229.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Bart,
On Thu, Oct 29, 2009 at 11:48 PM, Bartlomiej Zolnierkiewicz
<bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
I don't think your technical arguments are pointless either. However,
asking Dave to revert something over John and then arguing about it is
pointless and will likely just piss people off and make them ignore
you.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames
From: David Miller @ 2009-10-30 5:55 UTC (permalink / raw)
To: ray; +Cc: romieu, netdev
In-Reply-To: <4AE60C15.3040206@apollo.lv>
From: Raimonds Cicans <ray@apollo.lv>
Date: Mon, 26 Oct 2009 22:52:37 +0200
> r8169 card drop incoming VLAN tagged MTU byte large jumbo frames
>
> It looks to compare current and maximal packet sizes hardware use
> '<' operator, not '<='.
>
> Bug introduced by patch:
> r8169: fix crash when large packets are received
>
> Signed-off-by: Raimonds Cicans <ray@apollo.lv>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] ibmtr: possible Read buffer overflow?
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm
In-Reply-To: <4AC7C19F.2080800@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Sat, 03 Oct 2009 23:26:55 +0200
> Prevent read outside array bounds.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Is this maybe required?
I can't see anything that protects against this, so yes it
seems to be required.
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] e1000e: rework disable K1 at 1000Mbps for 82577/82578
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20091029234604.5413.1698.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 29 Oct 2009 16:46:05 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> This patch reworks a previous workaround (commit 7d3cabbcc) for an issue
> in hardware where noise on the interconnect between the MAC and PHY could
> be generated by a lower power mode (K1) at 1000Mbps resulting in bad
> packets. Disable K1 while at 1000 Mbps but keep it enabled for 10/100Mbps
> and when the cable is disconnected. The original version of this
> workaround was found to be incomplete.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] e1000e: config PHY via software after resets
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20091029234545.5413.9667.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 29 Oct 2009 16:45:45 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> On PCH-based (82577/82578) and some ICH8-based parts (82566) there is an
> issue with the hardware automatically configuring the PHY with contents
> from the EEPROM after the PHY is reset, so do the configuration by the
> driver instead. This was already similarly done for some 82566 parts in
> e1000_phy_hw_reset_ich8lan() but needs to be done after other resets,
> so move the PHY configuration code to its own function and call after
> all PHY resets.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] e100: e100_phy_init() isolates selected PHY, causes 10 second boot delay
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bernhard.kaindl, bruce.w.allan
In-Reply-To: <20091029234228.5100.17917.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 29 Oct 2009 16:42:41 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> A change in how PHYs are electrically isolated caused all PHYs to be
> isolated followed by reverting that isolation for the selected PHY.
> Unfortunately, isolating the selected PHY for even a short period of
> time can result in DHCP negotiation taking more than 10 seconds on certain
> embedded configurations delaying boot time as reported by Bernhard Kaindl.
> This patch reverts the change to how PHYs are isolated yet still works
> around the issue for 82552 needing the selected PHY's BMCR register to
> be written after the unused PHYs are isolated. This code is moved below
> the setting of nic->phy ID in order to do the 82552-specific workaround.
>
> Cc: Bernhard Kaindl <bernhard.kaindl@gmx.net>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix kmemcheck annotations
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE97220.3000004@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Oct 2009 11:44:48 +0100
> David Miller a écrit :
>>
>> We may be trading size for performance here, I wonder if
>> it's wise to move queue_mapping like that and what
>> locality change we get as a result.
>
> I agree, but could not convince me it makes a difference.
Ok, I'll apply your patch as-is to net-2.6, thanks!
^ permalink raw reply
* Re: [PATCH 0/6] sky2: driver update
From: David Miller @ 2009-10-30 5:53 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20091029163704.793246334@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 29 Oct 2009 09:37:04 -0700
> This patch set adds support for Yukon Optima (88E8059) based
> on the vendor driver. Hopefully, it can go in 2.6.32.
Sorry, this is too much too late. You don't even have the hardware
to test the changes you are making to the driver which makes this
even more questionable for net-2.6
I'll toss this into net-next-2.6 and let's let it cook there for
a while at least.
If you want to pick out a small bug fix or two from this series
for net-2.6, please feel free to resubmit them specifically for
net-2.6 inclusion.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: Fix RPF to work with policy routing
From: David Miller @ 2009-10-30 5:51 UTC (permalink / raw)
To: hadi; +Cc: netdev, atis, eric.dumazet, zenczykowski
In-Reply-To: <1255867954.4815.25.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Sun, 18 Oct 2009 08:12:33 -0400
> commit f7c6fd2465d8e6f4f89c5d1262da10b4a6d499d0
> Author: Jamal Hadi Salim <hadi@cyberus.ca>
> Date: Sun Oct 18 08:04:51 2009 -0400
>
> [PATCH] net: Fix RPF to work with policy routing
> Policy routing is not looked up by mark on reverse path filtering.
> This fixes it.
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card
From: David Miller @ 2009-10-30 5:51 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20091018103920.ca9217ee.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 18 Oct 2009 10:39:20 +0900
>
> pcnet_cs,serial_cs:
>
> add cis of PreMax ethernet pcmcia card,
> and some Sierra Wireless serial card(AC555, AC7xx, AC8xx).
>
> use PROD_ID for AC7xx, because MANF_ID of AC7xx and AC8xx are the same.
>
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied to net-2.6, thanks.
^ 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