* Re: [RFC] ip / ifconfig redesign
From: Marc Singer @ 2005-12-05 20:56 UTC (permalink / raw)
To: Jeroen Massar; +Cc: Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <43947FEB.7020504@unfix.org>
On Mon, Dec 05, 2005 at 06:59:07PM +0100, Jeroen Massar wrote:
> Marc Singer wrote:
> > On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote:
> >> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote:
> <SNIP>
> >> The association between IP addresses and links is already a bit murky.
> >> Reference the arp_announce sysctl for what I mean. I recall Dave M.
> >> emphasizing on at least one occassion that IP addresses belong to
> >> the _box_, not to the link.
> >
> > Precisely the case. It should be the case that a box response to an
> > arp on *any* interface for *any* IP address known to the box.
>
> Thus you have the following nice setup:
>
> 10.100.10.0/24 = 10Gbit streaming network
> 10.100.20.0/24 = 10mbit admin network
>
> 10.100.10.1 on eth0
> 10.100.20.1 on eth2
>
> Then some idiot misconfigures his client box, putting 10.100.10.42/24 on
> the NIC that is supposed to be in the admin network only.
> Suddenly your 10mbit link is full because the arp's get answered on this
> link.
Huh? The arp requests don't establish routing and they aren't a
significant source of traffic. Besides, all I suggested is that if a
machine receives an arp request on eth2 for an address it has on
10.100.10/24, it should answer with it's MAC address on eth2.
My readings of the RFC do not address this issue directly. My
understand of this behaviour is from a discussion with someone
regarding iptables.
Moreover, if you allow users to willy-nilly connect to your networks,
you've got a completely different kind of problem on your hands.
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Marc Singer @ 2005-12-05 21:03 UTC (permalink / raw)
To: Ben Greear; +Cc: Al Boldi, netdev, linux-net
In-Reply-To: <43948049.3040508@candelatech.com>
On Mon, Dec 05, 2005 at 10:00:41AM -0800, Ben Greear wrote:
> >Precisely the case. It should be the case that a box response to an
> >arp on *any* interface for *any* IP address known to the box.
>
> I certainly don't mind if this is a configurable, or even default
> behaviour, but we also need the ability to only respond to particular
> arps on particular interfaces, based on the IP addresses assigned
> to those interfaces.
Why? The routing determines connectivity, not ARP. AFAIK, ARP
requests are not made on interfaces that lack that the network being
queried.
If I put a host with an address on network 12 onto an ethernet segment
for network 10 and then ARP for addresses on network 10, I ought to be
able to send packets to those hosts (baring a firewal). However, I
won't be able to get anything back because those hosts don't know how
to send to network 12. Misconfiguration? Yes. Non-compliant? No.
> I am able to get this particular arp binding working today, so I'm
> not suggesting changes, just mentioning that there are other
> configurations than what you mention that are useful to people.
Anyway, I haven't seen a good reason to change the current behavior.
While the above described functionality is missing, no one has made a
case to support it.
^ permalink raw reply
* Re: [2.6 patch] move some code to net/ipx/af_ipx.c
From: Adrian Bunk @ 2005-12-05 21:35 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Matt Mackall, acme, Andrew Morton, linux-kernel, netdev
In-Reply-To: <39e6f6c70511181224r20801b61j87c856c703ab2b4d@mail.gmail.com>
On Fri, Nov 18, 2005 at 06:24:10PM -0200, Arnaldo Carvalho de Melo wrote:
> On 11/18/05, Adrian Bunk <bunk@stusta.de> wrote:
> > On Mon, Nov 14, 2005 at 02:57:07AM +0100, Adrian Bunk wrote:
> > > On Fri, Nov 11, 2005 at 02:35:51AM -0600, Matt Mackall wrote:
> > > > trivial: drop unused 802.3 code if we compile without IPX
> > > >
> > > > (originally from http://wohnheim.fh-wedel.de/~joern/software/kernel/je/25/)
>
> Thanks Adrian, from a quick glance looks OK, I'll review it later
> today to see if everything is fine wrt appletalk, tr, etc.
Any result from your review?
> - Arnaldo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John Heffner @ 2005-12-05 22:19 UTC (permalink / raw)
To: Jeroen Massar; +Cc: Marc Singer, Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <43947FEB.7020504@unfix.org>
Jeroen Massar wrote:
> I wonder how many RFC's it violates. An interface must only answer ARP's
> on the interface that it is configured on, not anything else.
Not true. See RFC 1122, section 3.3.4. The standard leaves this
decision up to the implementation, for good reason.
From 1122 (note the use of MAY, not MUST or SHOULD):
"
There are two key requirement issues related to multihoming:
(A) A host MAY silently discard an incoming datagram whose
destination address does not correspond to the physical
interface through which it is received.
(B) A host MAY restrict itself to sending (non-source-
routed) IP datagrams only through the physical
interface that corresponds to the IP source address of
the datagrams.
"
This topic has been discussed many times on a variety of mailing lists.
I think the best way to do this is to make the behavior configurable,
which Linux currently does.
-John
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Rick Jones @ 2005-12-05 22:28 UTC (permalink / raw)
To: John Heffner
Cc: Jeroen Massar, Marc Singer, Ben Greear, Al Boldi, netdev,
linux-net
In-Reply-To: <4394BCD5.1060505@psc.edu>
John Heffner wrote:
> Jeroen Massar wrote:
>
>> I wonder how many RFC's it violates. An interface must only answer ARP's
>> on the interface that it is configured on, not anything else.
>
>
> Not true. See RFC 1122, section 3.3.4. The standard leaves this
> decision up to the implementation, for good reason.
>
> From 1122 (note the use of MAY, not MUST or SHOULD):
> "
> There are two key requirement issues related to multihoming:
>
> (A) A host MAY silently discard an incoming datagram whose
> destination address does not correspond to the physical
> interface through which it is received.
>
> (B) A host MAY restrict itself to sending (non-source-
> routed) IP datagrams only through the physical
> interface that corresponds to the IP source address of
> the datagrams.
> "
That's the discussion related to things like the "Strong ES" (end system) model
right? As such, isn't that discussing what _IP_ may do rather than what ARP may
do? 1122 doesn't say much about the interfaces/MAC's that should be part of a
given ARP reply. ARP seems to be RFC 826 and probably others, and the algorithm
described in 826 doesn't seem to be specific on the topic of interfaces - at
least not to my really brief read.
rick jones
^ permalink raw reply
* ¢³øL¦
From: mahomaho094dsh @ 2005-12-05 22:29 UTC (permalink / raw)
To: netdev
j4mC34LcgrWCxIFCgXmDWoOMg3WJ74FGkeOVXCCL4I/pkF6LfIF6gsaQXIK1gtyCt4FCDQqC
sYLMg1SDQ4NngsmPb46RgrWCxIKigumCzILFk8GVyoLJi5aJwoLwkriCq4FBleWPV4K1gtyC
t4FCDQqKhJDYgsGCvYzwjduC8IuBgt+C6ZROjvsxNTAwlpyIyI/jgsyPl5CrgsaCzIt0g1SD
fIGbg2eM8I3bgvCCtYLEgt2C3IK5gvGCqYFIDQqBnZP8ie+L4IFFie+U75OZgreC14LEj5eQ
q5WJklOBQZJqkKuCzYLcgsGCvYKtl7+L4IKqinyCqYLogtyCuYLxgUINCoGdjI4xgWAyifEo
j5eQq4LJguaC6YFBlpSCzZhigrWNh4KigsUpDQqBnYqEkNiCwYK9itaMV4FBjIuNpZFPkvGB
QYNyg1eDbINYg3CBW4Nng2mBW4FBj5eQq4LMltqTSYLgl2yBWILFgrcNCmh0dHA6Ly93d3cu
NTUxNWQuY29tL35mYzUwMTIvDQqXVJWfgsiPl5Crie+I9YLNk/yJ74vggUWJ75TvgvCVpYLB
gsSTb5hegrWCxIKigtyCt4FCDQqX4oLigqmCtYFBg1SDToOJgsyPl5Crgs2I6pBsguCCooLc
grmC8YLMgsWCsojAkFOCrYK+grOCooFCDQoNCi0tDQqUepBNjtKBRoz8iOSQXpS/DQoxMDIt
MDA3NQ0Kk4yLnpNzkOeR45Nji+aOT5TUkqw2lNSSbg0KlHqQTYuRlNuCzJX7gs2CsYK/gueC
yYKymEGXjYm6grOCooFCDQptYWhvbWFobzA5NGRzaEB5YWhvby5jb20NCg==
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John Heffner @ 2005-12-05 22:30 UTC (permalink / raw)
To: Rick Jones
Cc: Jeroen Massar, Marc Singer, Ben Greear, Al Boldi, netdev,
linux-net
In-Reply-To: <4394BF11.2070205@hp.com>
Rick Jones wrote:
> That's the discussion related to things like the "Strong ES" (end
> system) model right? As such, isn't that discussing what _IP_ may do
> rather than what ARP may do? 1122 doesn't say much about the
> interfaces/MAC's that should be part of a given ARP reply. ARP seems to
> be RFC 826 and probably others, and the algorithm described in 826
> doesn't seem to be specific on the topic of interfaces - at least not to
> my really brief read.
>
> rick jones
Yes, but if an interface will accept packets for a certain IP address,
and will send packets with that IP address, is there any reason it can't
ARP for that address?
-John
^ permalink raw reply
* Registration Confirmation
From: office @ 2005-12-05 22:37 UTC (permalink / raw)
To: ralf
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
Account and Password Information are attached!
***** Go to: http://www.intraware.de
***** Email: postman@intraware.de
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Rick Jones @ 2005-12-05 22:43 UTC (permalink / raw)
To: John Heffner
Cc: Jeroen Massar, Marc Singer, Ben Greear, Al Boldi, netdev,
linux-net
In-Reply-To: <4394BF9E.90303@psc.edu>
John Heffner wrote:
> Rick Jones wrote:
>
>> That's the discussion related to things like the "Strong ES" (end
>> system) model right? As such, isn't that discussing what _IP_ may do
>> rather than what ARP may do? 1122 doesn't say much about the
>> interfaces/MAC's that should be part of a given ARP reply. ARP seems
>> to be RFC 826 and probably others, and the algorithm described in 826
>> doesn't seem to be specific on the topic of interfaces - at least not
>> to my really brief read.
>>
>> rick jones
>
>
> Yes, but if an interface will accept packets for a certain IP address,
> and will send packets with that IP address, is there any reason it can't
> ARP for that address?
If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP,
accepting IPs is IP. The maze of twisty passages may be similar, but they are
distinct.
Is a MAC address a property of the host, or of the interface connected to the host?
rick jones
is on netdev, so no need for direct reply to my address...
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Jeroen Massar @ 2005-12-05 22:48 UTC (permalink / raw)
To: John Heffner; +Cc: Marc Singer, Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <4394BCD5.1060505@psc.edu>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
John Heffner wrote:
> Jeroen Massar wrote:
>> I wonder how many RFC's it violates. An interface must only answer ARP's
>> on the interface that it is configured on, not anything else.
>
> Not true. See RFC 1122, section 3.3.4. The standard leaves this
> decision up to the implementation, for good reason.
RFC1122 is a document about multicast. ARP is broadcast see the very old
RFC826/STD0037. Multicast didn't even work on much of the hardware from
the times that that document was written.
Probably the best text about this subject can be found in RFC1027:
8<-----------
2.4 Sanity checks
Care must be taken by the network and gateway administrators to keep
the network masks the same on all the subnet gateway machines. The
most common error is to set the network mask on a host without a
subnet implementation to include the subnet number. This causes the
host to fail to attempt to send packets to hosts not on its local
subnet. Adjusting its routing tables will not help, since it will
not know how to route to subnets.
If the IP networks of the source and target hosts of an ARP request
are different, an ARP subnet gateway implementation should not
reply. This is to prevent the ARP subnet gateway from being used to
reach foreign IP networks and thus possibly bypass security checks
provided by IP gateways.
-------------->8
Which is almost the same as what I noted. Note that the document is
about Proxy ARP, when a host is responding ARP queries for an IP on a
different link, this is exactly what it is doing: proxy arp.
> This topic has been discussed many times on a variety of mailing lists.
> I think the best way to do this is to make the behavior configurable,
> which Linux currently does.
As long as the default is off I am fine with it, people turning it on
themselves break their own network :)
Greets,
Jeroen
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John Heffner @ 2005-12-05 22:56 UTC (permalink / raw)
To: Jeroen Massar; +Cc: Marc Singer, Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <4394C3D4.9050909@unfix.org>
Jeroen Massar wrote:
> John Heffner wrote:
>
>>Jeroen Massar wrote:
>>
>>>I wonder how many RFC's it violates. An interface must only answer ARP's
>>>on the interface that it is configured on, not anything else.
>>
>>Not true. See RFC 1122, section 3.3.4. The standard leaves this
>>decision up to the implementation, for good reason.
>
>
> RFC1122 is a document about multicast. ARP is broadcast see the very old
> RFC826/STD0037. Multicast didn't even work on much of the hardware from
> the times that that document was written.
??? RFC 1122 is the Hosts Requirements RFC. It applies to any host
implementing IP. Maybe you're thinking of 1112?
-John
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: John Heffner @ 2005-12-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: Jeroen Massar, Marc Singer, Ben Greear, Al Boldi, linux-net
In-Reply-To: <4394C2A9.6000606@hp.com>
Rick Jones wrote:
> John Heffner wrote:
>> Yes, but if an interface will accept packets for a certain IP address,
>> and will send packets with that IP address, is there any reason it
>> can't ARP for that address?
>
>
> If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP,
> accepting IPs is IP. The maze of twisty passages may be similar, but
> they are distinct.
I actually think it would be out of scope for an ARP RFC to specify this
(and none I'm aware of do). It really is an IP layer decision. That
is, the decision naturally extends beyond the scope of ARP, applying
also to layer 2 devices which don't even do ARP.
> Is a MAC address a property of the host, or of the interface connected
> to the host?
Depends on whether you run your interfaces in promiscuous mode, and send
frames with different MAC addresses from one interface. ;-)
-John
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Jeroen Massar @ 2005-12-05 23:10 UTC (permalink / raw)
To: John Heffner; +Cc: Marc Singer, Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <4394C5B6.8020301@psc.edu>
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]
John Heffner wrote:
> Jeroen Massar wrote:
>> John Heffner wrote:
>>
>>> Jeroen Massar wrote:
>>>
>>>> I wonder how many RFC's it violates. An interface must only answer
>>>> ARP's
>>>> on the interface that it is configured on, not anything else.
>>>
>>> Not true. See RFC 1122, section 3.3.4. The standard leaves this
>>> decision up to the implementation, for good reason.
>>
>>
>> RFC1122 is a document about multicast. ARP is broadcast see the very old
>> RFC826/STD0037. Multicast didn't even work on much of the hardware from
>> the times that that document was written.
>
> ??? RFC 1122 is the Hosts Requirements RFC. It applies to any host
> implementing IP. Maybe you're thinking of 1112?
Oops, mixed up a number. 1122 refers to 826, with 1027 extending it
partially for situations where one is multihomed.
Section 3.3.4 of 1122 is about IP and not about ARP, which is, just like
IP directly on top of Ethernet.
Greets,
Jeroen
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 238 bytes --]
^ permalink raw reply
* Re: [PATCH] natsemi: NAPI support
From: Mark Brown @ 2005-12-05 23:23 UTC (permalink / raw)
To: Francois Romieu
Cc: Jeff Garzik, Tim Hockin, Harald Welte, netdev, linux-kernel
In-Reply-To: <20051204231209.GA28949@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
On Mon, Dec 05, 2005 at 12:12:09AM +0100, Francois Romieu wrote:
> -> netif_poll_disable() may sleep while a spinlock is held.
So it can, thanks.
> Btw, the poll/close routines seem racy with each other.
I had been under the impression that the stack was supposed to make sure
that no poll() is running before the driver close() gets called? I
could well be missing something there, though. Indeed, now that I think
about it the calls netif_poll_disable() in suspend() ought to mean that
we don't need to look at hands_off inside poll().
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: [PATCH] natsemi: NAPI support
From: Francois Romieu @ 2005-12-06 0:19 UTC (permalink / raw)
To: broonie; +Cc: Jeff Garzik, Tim Hockin, Harald Welte, netdev, linux-kernel
In-Reply-To: <20051205232301.GA4551@sirena.org.uk>
Mark Brown <broonie@sirena.org.uk> :
[...]
> I had been under the impression that the stack was supposed to make sure
> that no poll() is running before the driver close() gets called ?
Not exactly. dev_close() waits a bit but it can not be sure that the
device driver will not schedule ->poll() from its irq handler later.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 12/14] spidernet: check if firmware was loaded correctly
From: Paul Mackerras @ 2005-12-06 0:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc64-dev, netdev, Arnd Bergmann, Jens.Osterkamp
In-Reply-To: <20051206040645.193163000@localhost>
Arnd Bergmann writes:
> Uploading the device firmware may fail if wrong input data
> was provided by the user. This checks for the condition.
>
> From: Jens.Osterkamp@de.ibm.com
> Cc: netdev@vger.kernel.org
This one should be sent to Jeff Garzik, along with patches 11, 13 and
14.
Paul.
^ permalink raw reply
* [PATCH 11/14] spidernet: fix Kconfig after BPA->CELL rename
From: Arnd Bergmann @ 2005-12-06 3:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc64-dev, netdev, Arnd Bergmann, Jens.Osterkamp
In-Reply-To: <20051206035220.097737000@localhost>
[-- Attachment #1: spidernet-with-pci-and-cell.diff --]
[-- Type: text/plain, Size: 710 bytes --]
We changed the name of the Kconfig symbols along with
the move to arch/powerpc. This one hunk got lost during
the conversion.
From: Jens.Osterkamp@de.ibm.com
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
Index: linux-2.6.15-rc1/drivers/net/Kconfig
===================================================================
--- linux-2.6.15-rc1.orig/drivers/net/Kconfig
+++ linux-2.6.15-rc1/drivers/net/Kconfig
@@ -2120,7 +2120,7 @@ config BNX2
config SPIDER_NET
tristate "Spider Gigabit Ethernet driver"
- depends on PCI && PPC_BPA
+ depends on PCI && PPC_CELL
help
This driver supports the Gigabit Ethernet chips present on the
Cell Processor-Based Blades from IBM.
--
^ permalink raw reply
* [PATCH 12/14] spidernet: check if firmware was loaded correctly
From: Arnd Bergmann @ 2005-12-06 3:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc64-dev, netdev, Arnd Bergmann, Jens.Osterkamp
In-Reply-To: <20051206035220.097737000@localhost>
[-- Attachment #1: spidernet-programcheck.diff --]
[-- Type: text/plain, Size: 1798 bytes --]
Uploading the device firmware may fail if wrong input data
was provided by the user. This checks for the condition.
From: Jens.Osterkamp@de.ibm.com
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
Index: linux-2.6.15-rc/drivers/net/spider_net.c
===================================================================
--- linux-2.6.15-rc.orig/drivers/net/spider_net.c
+++ linux-2.6.15-rc/drivers/net/spider_net.c
@@ -1836,7 +1836,7 @@ spider_net_setup_phy(struct spider_net_c
* spider_net_download_firmware loads the firmware opened by
* spider_net_init_firmware into the adapter.
*/
-static void
+static int
spider_net_download_firmware(struct spider_net_card *card,
const struct firmware *firmware)
{
@@ -1857,8 +1857,13 @@ spider_net_download_firmware(struct spid
}
}
+ if (spider_net_read_reg(card, SPIDER_NET_GSINIT))
+ return -EIO;
+
spider_net_write_reg(card, SPIDER_NET_GSINIT,
SPIDER_NET_RUN_SEQ_VALUE);
+
+ return 0;
}
/**
@@ -1909,9 +1914,8 @@ spider_net_init_firmware(struct spider_n
goto out;
}
- spider_net_download_firmware(card, firmware);
-
- err = 0;
+ if (!spider_net_download_firmware(card, firmware))
+ err = 0;
out:
release_firmware(firmware);
Index: linux-2.6.15-rc/drivers/net/spider_net.h
===================================================================
--- linux-2.6.15-rc.orig/drivers/net/spider_net.h
+++ linux-2.6.15-rc/drivers/net/spider_net.h
@@ -155,7 +155,7 @@ extern char spider_net_driver_name[];
/* set this first, then the FRAMENUM_VALUE */
#define SPIDER_NET_GFXFRAMES_VALUE 0x00000000
-#define SPIDER_NET_STOP_SEQ_VALUE 0x00000000
+#define SPIDER_NET_STOP_SEQ_VALUE 0x007e0000
#define SPIDER_NET_RUN_SEQ_VALUE 0x0000007e
#define SPIDER_NET_PHY_CTRL_VALUE 0x00040040
--
^ permalink raw reply
* [PATCH 13/14] spidernet: read firmware from the OF device tree
From: Arnd Bergmann @ 2005-12-06 3:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc64-dev, netdev, Arnd Bergmann, Jens.Osterkamp
In-Reply-To: <20051206035220.097737000@localhost>
[-- Attachment #1: spidernet-fw-from-dt-2.diff --]
[-- Type: text/plain, Size: 1584 bytes --]
request_firmware() is sometimes problematic, especially
in initramfs, reading the firmware from Open Firmware
is much preferrable.
We still try to get the firmware from the file system
first, in order to support old SLOF releases and to allow
updates of the spidernet firmware without reflashing
the system.
From: Jens.Osterkamp@de.ibm.com
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
Index: linux-2.6.15-rc/drivers/net/spider_net.c
===================================================================
--- linux-2.6.15-rc.orig/drivers/net/spider_net.c
+++ linux-2.6.15-rc/drivers/net/spider_net.c
@@ -1895,16 +1895,27 @@ spider_net_download_firmware(struct spid
static int
spider_net_init_firmware(struct spider_net_card *card)
{
- const struct firmware *firmware;
+ struct firmware *firmware;
+ struct device_node *dn;
+ u8 *fw_prop;
int err = -EIO;
- if (request_firmware(&firmware,
+ if (request_firmware((const struct firmware **)&firmware,
SPIDER_NET_FIRMWARE_NAME, &card->pdev->dev) < 0) {
if (netif_msg_probe(card))
pr_err("Couldn't read in sequencer data file %s.\n",
SPIDER_NET_FIRMWARE_NAME);
- firmware = NULL;
- goto out;
+
+ dn = pci_device_to_OF_node(card->pdev);
+ if (!dn)
+ goto out;
+
+ fw_prop = (u8 *)get_property(dn, "firmware", NULL);
+ if (!fw_prop)
+ goto out;
+
+ memcpy(firmware->data, fw_prop, 6 * SPIDER_NET_FIRMWARE_LEN * sizeof(u32));
+ firmware->size = 6 * SPIDER_NET_FIRMWARE_LEN * sizeof(u32);
}
if (firmware->size != 6 * SPIDER_NET_FIRMWARE_LEN * sizeof(u32)) {
--
^ permalink raw reply
* [PATCH 14/14] spidernet: fix HW structures for 64 bit dma_addr_t
From: Arnd Bergmann @ 2005-12-06 3:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc64-dev, netdev, Arnd Bergmann, Jens.Osterkamp
In-Reply-To: <20051206035220.097737000@localhost>
[-- Attachment #1: spidernet-dma_addr_t-fix-2.diff --]
[-- Type: text/plain, Size: 2460 bytes --]
The driver incorrectly used dma_addr_t to describe
HW structures and consequently broke when that type
was changed in 2.6.15-rc.
This changed spidernet to use u32 for 32 bit HW defined
structure elements.
From: Jens.Osterkamp@de.ibm.com
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <arndb@de.ibm.com>
Index: linux-2.6.15-rc/drivers/net/spider_net.h
===================================================================
--- linux-2.6.15-rc.orig/drivers/net/spider_net.h
+++ linux-2.6.15-rc/drivers/net/spider_net.h
@@ -373,9 +373,9 @@ enum spider_net_descr_status {
struct spider_net_descr {
/* as defined by the hardware */
- dma_addr_t buf_addr;
+ u32 buf_addr;
u32 buf_size;
- dma_addr_t next_descr_addr;
+ u32 next_descr_addr;
u32 dmac_cmd_status;
u32 result_size;
u32 valid_size; /* all zeroes for tx */
Index: linux-2.6.15-rc/drivers/net/spider_net.c
===================================================================
--- linux-2.6.15-rc.orig/drivers/net/spider_net.c
+++ linux-2.6.15-rc/drivers/net/spider_net.c
@@ -480,6 +480,7 @@ static int
spider_net_prepare_rx_descr(struct spider_net_card *card,
struct spider_net_descr *descr)
{
+ dma_addr_t buf;
int error = 0;
int offset;
int bufsize;
@@ -510,10 +511,11 @@ spider_net_prepare_rx_descr(struct spide
if (offset)
skb_reserve(descr->skb, SPIDER_NET_RXBUF_ALIGN - offset);
/* io-mmu-map the skb */
- descr->buf_addr = pci_map_single(card->pdev, descr->skb->data,
+ buf = pci_map_single(card->pdev, descr->skb->data,
SPIDER_NET_MAX_MTU,
PCI_DMA_BIDIRECTIONAL);
- if (descr->buf_addr == DMA_ERROR_CODE) {
+ descr->buf_addr = buf;
+ if (buf == DMA_ERROR_CODE) {
dev_kfree_skb_any(descr->skb);
if (netif_msg_rx_err(card))
pr_err("Could not iommu-map rx buffer\n");
@@ -914,15 +916,16 @@ spider_net_prepare_tx_descr(struct spide
struct spider_net_descr *descr,
struct sk_buff *skb)
{
- descr->buf_addr = pci_map_single(card->pdev, skb->data,
- skb->len, PCI_DMA_BIDIRECTIONAL);
- if (descr->buf_addr == DMA_ERROR_CODE) {
+ dma_addr_t buf = pci_map_single(card->pdev, skb->data,
+ skb->len, PCI_DMA_BIDIRECTIONAL);
+ if (buf == DMA_ERROR_CODE) {
if (netif_msg_tx_err(card))
pr_err("could not iommu-map packet (%p, %i). "
"Dropping packet\n", skb->data, skb->len);
return -ENOMEM;
}
+ descr->buf_addr = buf;
descr->buf_size = skb->len;
descr->skb = skb;
descr->data_status = 0;
--
^ permalink raw reply
* Registration Confirmation
From: info @ 2005-12-06 4:01 UTC (permalink / raw)
To: mailserver
[-- Attachment #1: Type: text/plain, Size: 109 bytes --]
Protected message is attached!
***** Go to: http://www.cconcepts.co.uk
***** Email: postman@cconcepts.co.uk
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Marc Singer @ 2005-12-06 5:13 UTC (permalink / raw)
To: John Heffner; +Cc: netdev, Jeroen Massar, Ben Greear, Al Boldi, linux-net
In-Reply-To: <4394C726.80902@psc.edu>
On Mon, Dec 05, 2005 at 06:03:02PM -0500, John Heffner wrote:
> Rick Jones wrote:
> >John Heffner wrote:
> >>Yes, but if an interface will accept packets for a certain IP address,
> >>and will send packets with that IP address, is there any reason it
> >>can't ARP for that address?
> >
> >
> >If ARP RFC's say it shouldn't :) (I don't know that it does) ARP is ARP,
> >accepting IPs is IP. The maze of twisty passages may be similar, but
> >they are distinct.
>
> I actually think it would be out of scope for an ARP RFC to specify this
> (and none I'm aware of do). It really is an IP layer decision. That
> is, the decision naturally extends beyond the scope of ARP, applying
> also to layer 2 devices which don't even do ARP.
Indeed. We've been talking about ARP responses, not queries.
> >Is a MAC address a property of the host, or of the interface connected
> >to the host?
>
> Depends on whether you run your interfaces in promiscuous mode, and send
> frames with different MAC addresses from one interface. ;-)
MAC addresses are owned by the link. It is not meaningful for eth1 to
transmit the MAC for eth0. Consider that both interfaces could be on
the same link.
Yes, we can do all manner of gymnastics, but this is something that
IEEE standardizes.
^ permalink raw reply
* Re: [RFC] ip / ifconfig redesign
From: Marc Singer @ 2005-12-06 5:18 UTC (permalink / raw)
To: Jeroen Massar; +Cc: John Heffner, Ben Greear, Al Boldi, netdev, linux-net
In-Reply-To: <4394C3D4.9050909@unfix.org>
On Mon, Dec 05, 2005 at 11:48:52PM +0100, Jeroen Massar wrote:
> John Heffner wrote:
> > Jeroen Massar wrote:
> >> I wonder how many RFC's it violates. An interface must only answer ARP's
> >> on the interface that it is configured on, not anything else.
> >
> > Not true. See RFC 1122, section 3.3.4. The standard leaves this
> > decision up to the implementation, for good reason.
>
> RFC1122 is a document about multicast. ARP is broadcast see the very old
> RFC826/STD0037. Multicast didn't even work on much of the hardware from
> the times that that document was written.
>
> Probably the best text about this subject can be found in RFC1027:
> 8<-----------
> 2.4 Sanity checks
>
> Care must be taken by the network and gateway administrators to keep
> the network masks the same on all the subnet gateway machines. The
> most common error is to set the network mask on a host without a
> subnet implementation to include the subnet number. This causes the
> host to fail to attempt to send packets to hosts not on its local
> subnet. Adjusting its routing tables will not help, since it will
> not know how to route to subnets.
>
> If the IP networks of the source and target hosts of an ARP request
> are different, an ARP subnet gateway implementation should not
> reply. This is to prevent the ARP subnet gateway from being used to
> reach foreign IP networks and thus possibly bypass security checks
> provided by IP gateways.
> -------------->8
>
> Which is almost the same as what I noted. Note that the document is
> about Proxy ARP, when a host is responding ARP queries for an IP on a
> different link, this is exactly what it is doing: proxy arp.
Interesting, but I don't think it applies. We're talking about
reaching the node, not about using the node as a transparent gateway.
Note the part about "an ARP subnet gateway implementation" that need
to be careful.
>
> > This topic has been discussed many times on a variety of mailing lists.
> > I think the best way to do this is to make the behavior configurable,
> > which Linux currently does.
>
> As long as the default is off I am fine with it, people turning it on
> themselves break their own network :)
Indeed. Safety (sanity) first.
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Michael Renzmann @ 2005-12-06 7:17 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Jiri Benc, mbuesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <43948B13.2090509@pobox.com>
Hi.
On Mon, 2005-12-05 at 13:46 -0500, Jeff Garzik wrote:
> > Although I'm a bit biased towards MadWifi, I'd second your suggestion to
> > make use of the Devicescape code. The benefit of having a fully-blown
> > 802.11 stack in the kernel that drivers can make use of has been
> > discussed before, so I won't go into that yet again.
> Use the stack that's already in the kernel.
Sorry, that was my bad. I thought that the Devicescape code found its
way to the kernel (didn't follow the discussion some months ago too
closely). Although I think there probably are better alternatives to the
802.11 stack that is in the kernel right now, having a central 802.11
stack at all is a great improvement that should be used where possible.
> Encouraging otherwise hinders continued wireless progress under Linux.
That depends. If the encouraging is about an alternative, more complete
and superior 802.11 stack for Linux which could be integrated with less
effort than extending the existing code, that should be worth to talk
about.
Please note that I'm not refering here to any of the related suggestions
which have been made during the past months - it's a general statement.
Bye, Mike
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Kyle Moffett @ 2005-12-06 9:26 UTC (permalink / raw)
To: Jiri Benc; +Cc: Michael Buesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205214256.492421ad@griffin.suse.cz>
On Dec 05, 2005, at 15:42, Jiri Benc wrote:
> On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote:
>> This is __not__ "yet another stack". It is an _extension_. It is
>> all about management frames, which the in-kernel code does not
>> manage.
>
> But this code should be part of the stack, as nearly every driver
> needs it.
WRONG. More than half the currently Linux-compatible wireless cards
handle the wireless management packets in hardware, such that they're
little more complicated than a basic ethernet device with a channel,
an ESSID, and a list of MACs/APs.
> Management handling should be really managed by the kernel.
Yes, but it might not need to be in the base stack if it's largely
functionally independent.
> The hard part is that every driver will need a slightly different
> amount of this support depending on the amount of features that are
> provided by firmware.
s/firmware/hardware/g. This is _exactly_ why an external module
makes a lot of sense.
>> We tried the code from the RTL driver, but it is total crap. We
>> dropped it again. We thought about using yet another out of kernel
>> ieee80211 stack, but we began to write an extension to the in-
>> kernel code. If that was right or wrong, well, that's the question.
>>
>> If you _really_ think we should have used $EXTERNAL_STACK, go and
>> patch the driver to work with it.
>
> No. I just think we (everybody) should concentrate at one
> particular stack, finish it and merge it. And I'm convinced Jouni's
> stack is currently the best solution available - far far from
> perfect, with many issues, but still the best - and it will finally
> save as much time.
What you miss is that the kernel does _not_ go with the "rewrite it
and replace it" methodology. See Luben Toikov in the SAS flamewar
for another example. If a better stack exists, provide a nice clean
set of totally functional changes that convert the current one into
that one. In the process, we even get to keep the nice parts of the
current one that aren't in his (whatever they may be), and we always
have a working wireless stack. With the rewrite/replace solution,
you end up broken or unstable half the time.
Cheers,
Kyle Moffett
--
Simple things should be simple and complex things should be possible
-- Alan Kay
^ 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