> give it away on this specific instance. I'm not sure if you should
> attribute to hidden agendas what you can explain by "doing the right
> thing" (granted, very few companies do this which may make it suspect,
> but still..).
Pekka,
I'm not assuming hidden agendas here; I simply don
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Fri, 26 Oct 2007 18:04:22 -0600
> So if this is really something we want to stop doing we should
> be able to take a few extra moments remove the code from the
> two problem drivers, and remove the exports.
I've killed the references in dlm and rr
From: "Nelson, Shannon" <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 08:38:55 -0700
> There is no creation of a pinned_list yet in this path, so I don't think
> this would do us much good.
The pinned list is created in the generic net/ipv4/tcp.c code, not in
the address family specific code.
So yo
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 18:12:26 +0400
> There are places that check for CONFIG_IP_MULTIPLE_TABLES
> twice in the same file, but the internals of these #ifdefs
> can be merged.
>
> As a side effect - remove one ifdef from inside a function.
>
> Signed-off
On Tue, 6 Nov 2007, David Miller wrote:
From: David Stevens <[EMAIL PROTECTED]>
Date: Tue, 6 Nov 2007 22:07:44 -0800
I guess license is no longer required for implementers of ISATAP.
Is it right, Fred?
https://datatracker.ietf.org/ipr/550/
Does this also allow license-free redistribution?
I
From: David Stevens <[EMAIL PROTECTED]>
Date: Tue, 6 Nov 2007 22:07:44 -0800
> > I guess license is no longer required for implementers of ISATAP.
> > Is it right, Fred?
> >
> > https://datatracker.ietf.org/ipr/550/
>
> Does this also allow license-free redistribution?
>
> I'm certainly no lawy
> I guess license is no longer required for implementers of ISATAP.
> Is it right, Fred?
>
> https://datatracker.ietf.org/ipr/550/
Does this also allow license-free redistribution?
I'm certainly no lawyer, but I don't see the point of
having a patent that doesn't restrict *something*. :-)
In article <[EMAIL PROTECTED]> (at Tue, 06 Nov 2007 21:37:50 -0800 (PST)),
David Miller <[EMAIL PROTECTED]> says:
> From: David Stevens <[EMAIL PROTECTED]>
> Date: Tue, 6 Nov 2007 21:26:15 -0800
>
> > Last I heard, there are Intellectual Property claims with ISATAP,
> > which is why the RFC is n
From: David Stevens <[EMAIL PROTECTED]>
Date: Tue, 6 Nov 2007 21:26:15 -0800
> Last I heard, there are Intellectual Property claims with ISATAP,
> which is why the RFC is not standards track and which makes it
> effectively a proprietary protocol.
>
> Unless that's been resolved, I think the clai
Last I heard, there are Intellectual Property claims with ISATAP,
which is why the RFC is not standards track and which makes it
effectively a proprietary protocol.
Unless that's been resolved, I think the claim by the IP owner is
that it can't be distributed without a license from them. So, maybe
From: "Templin, Fred L" <[EMAIL PROTECTED]>
Date: Tue, 6 Nov 2007 17:15:54 -0800
> Please advise as to next steps.
Your email client has mangles the patches, adding line breaks. This
makes the patches not apply at all.
Please correct this and resubmit, thank you.
-
To unsubscribe from this list
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Wed, 7 Nov 2007 15:04:48 +1100
> OK, about the help text. IMHO noone should be using "virtual
> ethernet" unqualified, since there are multiple things that now refers to.
>
> Here's a respin with just the help text changes:
Fair enough, applied.
-
T
Don't use the "replace source address with local MAC address" bits, since
it causes problems on some variations of the hardware due to an erratum.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasemi_mac.c
=
Make sure we don't feed packets with bad CRC up the network stack,
and discount the packet length as reported from the MAC for the CRC
field.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasemi_mac.c
==
Hi Jeff,
Two bugfixes for pasemi_mac for 2.6.24:
[PATCH 1/2] pasemi_mac: Don't set replace-source-address descriptor bits
[PATCH 2/2] pasemi_mac: Fix CRC checks
Thanks,
-Olof
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More
On Wednesday 07 November 2007 14:19:06 David Miller wrote:
> If anything, the veth naming makes more sense than the IBM device
> cases.
>
> And that's why I decreed that last time this came up that the naming
> for veth was just fine.
OK, about the help text. IMHO noone should be using "virtual
e
From: Rusty Russell <[EMAIL PROTECTED]>
Date: Wed, 7 Nov 2007 14:09:00 +1100
> There are already iSeries and pSeries virtual ethernet drivers called
> veth; calling a local tunnel device "veth" is confusing.
>
> I didn't rename the module nor the header, to avoid breaking
> documentation and user
From: Randy Dunlap <[EMAIL PROTECTED]>
Date: Tue, 6 Nov 2007 19:06:29 -0800
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Just move the function so that is it known before it is used.
>
> net/core/net_namespace.c: In function 'copy_net_ns':
> net/core/net_namespace.c:97: error: implicit declarati
Fix the printk() without KERN_* constant in net/ipv4.
Signed-off-by: Wang Chen <[EMAIL PROTECTED]>
---
af_inet.c |4 ++--
devinet.c |2 +-
fib_hash.c|2 +-
fib_semantics.c |2
There are already iSeries and pSeries virtual ethernet drivers called
veth; calling a local tunnel device "veth" is confusing.
I didn't rename the module nor the header, to avoid breaking
documentation and userspace programs respectively. But I'd really
like to. It'd also be nice to mention "con
Dave,
Here are a few for when you decide to open net-2.6.25... :-)
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem
---
The following changes since commit 2655e2cee2d77459fcb7e10228259e4ee0328
From: Randy Dunlap <[EMAIL PROTECTED]>
Just move the function so that is it known before it is used.
net/core/net_namespace.c: In function 'copy_net_ns':
net/core/net_namespace.c:97: error: implicit declaration of function 'net_free'
net/core/net_namespace.c: At top level:
net/core/net_namespace.
From: Fred L. Templin <[EMAIL PROTECTED]>
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".
The following diffs are spec
From: Fred L. Templin <[EMAIL PROTECTED]>
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".
The following diffs are spec
From: Fred L. Templin <[EMAIL PROTECTED]>
The following diffs are specific to the Linux 2.6.23
kernel distribution and implement RFC4214 (Intra-Site
Automatic Tunnel Addressing Protocol - ISATAP). The
affected modules are:
linux2.6.23/include/linux/if.h
linux2.6.23/include/net/addrconf.h
li
From: Fred L. Templin <[EMAIL PROTECTED]>
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".
The following diffs are spec
From: Fred L. Templin <[EMAIL PROTECTED]>
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".
The following diffs are spec
From: Fred L. Templin <[EMAIL PROTECTED]>
This is experimental support for the Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
the SIT module, and is configured using the unmodified
"ip" utility with device names beginning with: "isatap".
The following diffs are spec
On Wed, Nov 07, 2007 at 07:51:57AM +1100, James Morris wrote:
>
> -- Forwarded message --
> Date: Tue, 06 Nov 2007 14:53:30 +0100
> From: Vicenç <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Possible BUG on net/ipv4/ipcomp.c, line 358
>
> Hi James,
>
> I think there is a
Dave,
Here are some fixes for 2.6.24...
The iwlwifi patch is needed because the iwlwifi drivers routinely end-up
associated with the "simple" rate control algorithm, yet those drivers
really only work with their own custom algorithms. The other rate
control patches are there to satisfy dependenc
Krzysztof Halasa wrote:
Patrick McHardy <[EMAIL PROTECTED]> writes:
I think there is one more case that matters, which is briding
from a device with VLAN stripping for a VLAN not configured
locally. The tag will be stripped and will be lost for forwarded
packets.
I think we should drop such p
Chuck Ebbert wrote:
On 11/05/2007 07:12 PM, Patrick McHardy wrote:
Chuck Ebbert wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=333481#c3
This is netfilter kernel problem. There is a usage count for the
conntrack_ipv4
module from the nf_nat module, which is not reported by lsmod.
This i
On Wed, 7 Nov 2007 00:19:08 +0100
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> :
> [...]
> > Really, vendor_id is 1 ?
>
> Yes, the bug seems to be commonly set in hardware.
>
> > How about a comment about which board this is.
>
> B3w4r3 0f Th3 3v1l Fatal1ty
Stephen Hemminger <[EMAIL PROTECTED]> :
[...]
> Really, vendor_id is 1 ?
Yes, the bug seems to be commonly set in hardware.
> How about a comment about which board this is.
B3w4r3 0f Th3 3v1l Fatal1ty M0b0 ?
Imho 'git log/blame' will provide enough information for this hack.
--
Ueimor
-
To un
Jay Vosburgh wrote:
Rick Jones <[EMAIL PROTECTED]> wrote:
So, where do you and I stand wrt the proposed changes to bonding.txt? Are
we at an impass?
Nope, I'm doing a doc update next to incorporate several things,
the reordering stuff included (which I plan to change to describe the
Rick Jones <[EMAIL PROTECTED]> wrote:
>So, where do you and I stand wrt the proposed changes to bonding.txt? Are
>we at an impass?
Nope, I'm doing a doc update next to incorporate several things,
the reordering stuff included (which I plan to change to describe the
levels of badness, as
On Tue, 6 Nov 2007 23:23:54 +0100
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Ciaran McCreesh <[EMAIL PROTECTED]>
> Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
> Cc: Edward Hsu <[EMAIL PROTECTED]>
> ---
> drivers/net/r8169.c |2 ++
> 1 files changed, 2 insertions(+), 0
The socket option for packet sockets to return the original ifindex instead
of the bonded ifindex will not match multicast traffic. Since this socket
option is the most useful for layer 2 traffic and multicast traffic, make
the option multicast-aware.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL
Signed-off-by: Ciaran McCreesh <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Edward Hsu <[EMAIL PROTECTED]>
---
drivers/net/r8169.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b94fa7e..702334
The 8168c and the 8100e choke on it. I have not seen an indication
nor received a report that the TBI is being actively used on the
remaining 8168b and 8110. Let's disable it for now until someone
complains.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
Cc: Matthias Winkler <[EMAIL PROTECTED]
Please pull from branch 'upstream-jeff' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git
upstream-jeff
to get the changes below.
Distance from 'master' (f2511f13daaf00fdd206bee7b108f75923a613c6)
-
Jay -
So, where do you and I stand wrt the proposed changes to bonding.txt? Are we at
an impass?
sincerely,
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-in
Two small fixes to bonding for the mainline.
1: Mishandling of RTNL due to what looks like a merge error.
2: Turn off the new validate_addr check when devices are set
up. For backwards compatibility, the bonding master must be able to be
set up with a MAC address of all
The standard validate_addr handler refuses to accept the all zeroes address
as valid. However, it's common historical practice for the bonding
master to be configured up prior to having any slaves, at which time the
master will have a MAC address of all zeroes.
Resolved by setting the dev->valida
Looks like I incorrectly merged one of the rtnl lock changes,
so that one function, bonding_show_active_slave, held rtnl but didn't
release it, and another, bonding_store_active_slave, never held rtnl but
did release it.
Fixed so the first function doesn't mess with rtnl, and the
s
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
Past performance is no guarantee of current correctness :) And over an
Ethernet, there will be a very different set of both timings and TCP
segment sizes compared to loopback.
My guess is that you will find setting the lo m
[linux-raid was also emailed this same information]
I was testing some network throughput today and ran into this.
I should note that I've this motherboard has 2x MCP55 Ethernet and one
of them works fine and the other one gives lots and lots of frame
errors under load.
The following is only an h
[linux-raid was also emailed this same information]
I was testing some network throughput today and ran into this.
I should note that I've this motherboard has 2x MCP55 Ethernet and one
of them works fine and the other one gives lots and lots of frame
errors under load.
The following is only an h
Radu Rendec wrote, On 11/06/2007 06:00 PM:
> On Tue, 2007-11-06 at 09:43 -0500, jamal wrote:
>> On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
>>
>>> Yes, it saves one htonl() on the slow path!
>> Would it feel better to say grew down exponentially from version 1 to
>> 3? ;->
Sure, bu
Ben Greear <[EMAIL PROTECTED]> writes:
> Bridging eth0 to eth1 should not pay attention to VLAN tags
> at all (if the pkt comes in on VLAN 7, it should go out on VLAN 7),
> in my opinion. If the NIC is stripping the VLAN header, then this
> cannot work unless something re-builds the VLAN header.
Jeff,
Here are a few fixes for 2.6.24. The iwlwifi "is_power_of_2" patch is
a little questionable as a fix. But it does bring the buildtime check
in iwl_tx_queue_init in-line with the runtime check in iwl_queue_init,
and it is 2x a one-liner -- so I think it is worthwhile.
Thanks,
John
---
I
Netpoll will only work on port 0 because of the restrictive
relationship between NAPI and netpoll.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-11-06 09:09:18.0 -0800
+++ b/drivers/net/sky2.c2007-11-06 11:42:48.0 -0800
@@ -3995,
On 11/05/2007 07:12 PM, Patrick McHardy wrote:
> Chuck Ebbert wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=333481#c3
>>
>> This is netfilter kernel problem. There is a usage count for the
>> conntrack_ipv4
>> module from the nf_nat module, which is not reported by lsmod.
>>
>
> This is
Krzysztof Halasa wrote:
Patrick McHardy <[EMAIL PROTECTED]> writes:
I think there is one more case that matters, which is briding
from a device with VLAN stripping for a VLAN not configured
locally. The tag will be stripped and will be lost for forwarded
packets.
I think we should drop such p
On Tue, Nov 06, 2007 at 09:51:57AM +0100, Sergej Stepanov wrote:
> The patch updates the booting-without-of.txt-file.
> There is a description for the case
> if mdio data and clock pins are on different processor ports.
> It is a extending for e-mail "[PATCH v3] using mii-bitbang on different
> pr
Ramkrishna Vepa writes:
> Dave,
>
> If you can remove the patch for the s2io driver, we can submit a patch
> that can dynamically program Xframe to strip or not strip the vlan tag
> based on whether the vlan group is not NULL or NULL respectively. For
> this, we have to modify the initialization a
Dave,
If you can remove the patch for the s2io driver, we can submit a patch
that can dynamically program Xframe to strip or not strip the vlan tag
based on whether the vlan group is not NULL or NULL respectively. For
this, we have to modify the initialization as well as the vlan
registration.
Wi
Patrick McHardy <[EMAIL PROTECTED]> writes:
> I think there is one more case that matters, which is briding
> from a device with VLAN stripping for a VLAN not configured
> locally. The tag will be stripped and will be lost for forwarded
> packets.
I think we should drop such packets on RX. Anyway
Sreenivasa Honnur wrote:
- Fixed memory leak by freeing MSI-X local entry memories when vector allocation
fails in s2io_add_isr.
- Added two utility functions remove_msix_isr and remove_inta_isr to eliminate
code duplication.
- Implemented following review comments from Jeff
- Removed red
John W. Linville wrote:
Jeff,
Here is a slew of patches targeted for 2.6.25. There are a bunch
of rt2x00, iwl3945, iwl4965, b43, and b43legacy patches, as well as
a few others. I'm sorry I didn't spread this out better -- I got a
bit behind... :-(
Thanks,
John
---
Individual patches are av
applied 1-7
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
eric miao wrote:
From 9363662844b6373ddf4265e7007eb29ff963a377 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Tue, 30 Oct 2007 09:48:41 +0800
Subject: [PATCH] add support for smc91x ethernet interface on zylonite
This patch adds LAN91C111 ethernet interface support for zylon
Pavel Emelyanov wrote:
> Roel Kluin wrote:
>> Pavel Emelyanov wrote:
>>> Roel Kluin wrote:
Pavel Emelyanov wrote:
> Roel Kluin wrote:
>> Roel Kluin wrote:
>>> I got this bug recently, I am not sure whether this is related to any
>>> previously
>>> reported ones. It was a
The struct proto has the per-cpu "inuse" counter, which is handled
with a special care. All the handling code hides under the ifdef
CONFIG_SMP and it introduces some code duplication and makes it
look worse than it could.
Clean this.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff
David Acker wrote:
> On the systems that have cache incoherent DMA, including ARM, there is a
> race condition between software allocating a new receive buffer and hardware
> writing into a buffer. The two race on touching the last Receive Frame
> Descriptor (RFD). It has its el-bit set and its n
On Tue, 2007-11-06 at 09:43 -0500, jamal wrote:
> On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
>
> > Yes, it saves one htonl() on the slow path!
>
> Would it feel better to say grew down exponentially from version 1 to
> 3? ;->
Not only it saves one htonl(), but also keeps the code
Roel Kluin wrote:
> Pavel Emelyanov wrote:
>> Roel Kluin wrote:
>>> Pavel Emelyanov wrote:
Roel Kluin wrote:
> Roel Kluin wrote:
>> I got this bug recently, I am not sure whether this is related to any
>> previously
>> reported ones. It was a recently pulled git kernel. Also
Pavel Emelyanov wrote:
> Roel Kluin wrote:
>> Pavel Emelyanov wrote:
>>> Roel Kluin wrote:
Roel Kluin wrote:
> I got this bug recently, I am not sure whether this is related to any
> previously
> reported ones. It was a recently pulled git kernel. Also I have been
> hacking
On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
> Yes, it saves one htonl() on the slow path!
Would it feel better to say grew down exponentially from version 1 to
3? ;->
> > Please give yourself a little pat on the back for me.
>
> Wait a minute! Don't forget to take a picture or som
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
i'm just going to assume that loop is rounding up to the next power
of two, right?
diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c
index db6a97d..07eae16 100644
--- a/drivers/net/pcmcia/pcnet_cs.c
+++ b/driver
On Tue, Nov 06, 2007 at 08:34:31AM -0500, jamal wrote:
> On Tue, 2007-06-11 at 10:09 +0200, Radu Rendec wrote:
>
> > Yup, you're right. Bitwise anding is the same regardless of the byte
> > ordering of the operands. As long as you don't have one operand in host
> > order and the other in net order
On Tue, 2007-06-11 at 10:09 +0200, Radu Rendec wrote:
> Yup, you're right. Bitwise anding is the same regardless of the byte
> ordering of the operands. As long as you don't have one operand in host
> order and the other in net order, it's ok.
Ok
> However, Jarek's computations with his mask and
On Tue, Nov 06, 2007 at 03:23:50PM +0300, Alexey Dobriyan wrote:
> proc_net_create() stands on the way of shrinking the number of
> interfaces one can use for /proc files, namely, it uses ->get_info
> hook which will be converted, deprecated and deleted on its own
> schedule.
It's just a trivial h
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Tue, 6 Nov 2007 15:23:50 +0300
> proc_net_create() stands on the way of shrinking the number of
> interfaces one can use for /proc files, namely, it uses ->get_info
> hook which will be converted, deprecated and deleted on its own
> schedule.
>
> Si
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Tue, 6 Nov 2007 15:21:50 +0300
> This removes last proc_net_create() user. Kudos to Benjamin Thery and
> Stephen Hemminger for comments on previous version.
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this
proc_net_create() stands on the way of shrinking the number of
interfaces one can use for /proc files, namely, it uses ->get_info
hook which will be converted, deprecated and deleted on its own
schedule.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
Documentation/feature-removal-schedul
This removes last proc_net_create() user. Kudos to Benjamin Thery and
Stephen Hemminger for comments on previous version.
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
net/ipv6/route.c | 91 +--
1 file changed, 29 insertions(+), 62 d
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 6 Nov 2007 13:48:55 +0300
> Tested, works, fixed.
>
> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
Applied, thanks a lot Evgeniy!
I'll queue this up for -stable too.
-
To unsubscribe from this list: send the line "unsubscribe netdev"
"Matthew Faulkner" <[EMAIL PROTECTED]> writes:
> I'm probably being stupid and very confused here. Appologies if it is
> a stupid question.
>
> For a particular test I assign a client to core 1 and a server to core
> 0. My first assumption was all the sending side kernel TCP/IP
> processing will b
On Mon, Nov 05, 2007 at 11:08:00PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Tue, Oct 30, 2007 at 01:33:41AM -0700, David Miller ([EMAIL PROTECTED])
> wrote:
> > > The panic is in __teql_resolve (which has been inlined into
> > > teql_master_xmit) in
> > > net/sched/sch_teql.c at t
Both lookup the nf_sockopt_ops object to call the get/set callbacks
from, but they perform it in a completely similar way.
Introduce the helper for finding the ops.
Ported at the top of today's net-2.6 tree to resolve conflict
with the patch from Alexey Dobriyan.
Signed-off-by: Pavel Emelyanov <
On Tue, 2007-11-06 at 01:02 +0100, Jarek Poplawski wrote:
> > I meant that it didnt seem necessary to me you have to do the conversion
> > back and forth of the hmask as you do in the u32_change(). The basis of
> > the patch i posted - which is based on yours - is to remove that change.
> > If that
The patch updates the booting-without-of.txt-file.
There is a description for the case
if mdio data and clock pins are on different processor ports.
It is a extending for e-mail "[PATCH v3] using mii-bitbang on different
processor ports".
Signed-off-by: Sergej Stepanov <[EMAIL PROTECTED]>
--
dif
Roel Kluin wrote:
> Pavel Emelyanov wrote:
>> Roel Kluin wrote:
>>> Roel Kluin wrote:
I got this bug recently, I am not sure whether this is related to any
previously
reported ones. It was a recently pulled git kernel. Also I have been
hacking my
kernel a bit lately, but
Same thing happens with Ethernet slave - Intel 82546GB Gigabit Ethernet
Controller (rev 03)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
85 matches
Mail list logo
