* Re: Broadcom 43xx first results
From: Jeff Garzik @ 2005-12-06 19:05 UTC (permalink / raw)
To: Harald Welte
Cc: Dave Jones, Jiri Benc, Joseph Jezak, mbuesch, linux-kernel,
bcm43xx-dev, NetDev
In-Reply-To: <20051206151046.GF4038@rama.exocore.com>
Harald Welte wrote:
> I also think that there is a lack of knowledge on the architecture of
> 802.11 low-level protocols and drivers among many people (including
> myself) in the network community. Only this way I can explain why there
> are always people who claim that the kernel already has a 802.11
> 'stack'.
This last sentence, regardless of the source, is simply playing with words.
We have 802.11 common code in the kernel, that several drivers are
using. Future drivers should modify that common code to suit their
needs, rather than dropping it and starting from scratch.
Jeff
^ permalink raw reply
* ¢»µ¿ÀÏÁ÷Àå3°³¿ùÀÌ»ó±Ù¹«ÇÑÁ÷ÀåÀÎ,°ø¹«¿ø¿ù0.5%±Ý¸®
From: °ñ ¿¬È« @ 2005-12-06 17:03 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: multipart/alternative, Size: 1087 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Ben Greear @ 2005-12-06 16:43 UTC (permalink / raw)
To: Pavel Machek
Cc: Jiri Benc, Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel,
NetDev
In-Reply-To: <20051206150909.GB1999@elf.ucw.cz>
Pavel Machek wrote:
> Hi!
>
>
>>>That's because you still don't get how we do development. The last thing
>>>we want is full-scale rewrites. Submit patches to fix things based on
>>>whatever you want but do it incremental.
>>
>>We have got almost finished and working stack. Everything we need to do
>>is:
>>1. identify issues;
>>2. fix the issues; some of them will need broader discussion;
>>3. split it into several (potentially a lot of) reviewable patches;
>>4. clean up the drivers.
>>
>>I'm in phase 2 now (no interesting results yet). I don't think it is
>
>
> No, it does not work like that. You don't get nice, reviewable,
> mergeable patches by developing code independently for 3 years or so
> then attempting merge.
>
> If devicescape code is better than mainline, merge it _now_. If it is
> not, drop it and start from mainline code.
Merge now even if it breaks the current tree? I for one would certainly
rather he finish his work on it and get it more polished. Reviewing and
testing something that actually works would be a lot more fun...
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Harald Welte @ 2005-12-06 15:10 UTC (permalink / raw)
To: Dave Jones, Jeff Garzik, Jiri Benc, Joseph Jezak, mbuesch,
linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <20051205195329.GB19964@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
On Mon, Dec 05, 2005 at 02:53:29PM -0500, Dave Jones wrote:
> > ieee80211 is used by Intel. Some bits used by HostAP, which also
> > duplicates a lot of ieee80211 code. And bcm43xx. And another couple
> > drivers found in -mm or out-of-tree.
>
> Orinoco also uses it now no ?
Dave, the Orinoco is a wireless card that has a hardware MAC, plust
firmware.
I do agree with Jiri that there basically is no support for softmac
devices in the ieee80211 code.
I'm also in favor of merging the devicescape code, but I don't see it
happening without somebody taking care to provide all the required
levels of interfaces (I see at least three levels of API's that a wireless
driver would need, depending on how much stuff is done in
hardware/firmware and how much in software.
I also think that there is a lack of knowledge on the architecture of
802.11 low-level protocols and drivers among many people (including
myself) in the network community. Only this way I can explain why there
are always people who claim that the kernel already has a 802.11
'stack'.
--
- Harald Welte <laforge@gnumonks.org> http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Pavel Machek @ 2005-12-06 15:09 UTC (permalink / raw)
To: Jiri Benc; +Cc: Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel, NetDev
In-Reply-To: <20051205211107.61941ab9@griffin.suse.cz>
Hi!
> > That's because you still don't get how we do development. The last thing
> > we want is full-scale rewrites. Submit patches to fix things based on
> > whatever you want but do it incremental.
>
> We have got almost finished and working stack. Everything we need to do
> is:
> 1. identify issues;
> 2. fix the issues; some of them will need broader discussion;
> 3. split it into several (potentially a lot of) reviewable patches;
> 4. clean up the drivers.
>
> I'm in phase 2 now (no interesting results yet). I don't think it is
No, it does not work like that. You don't get nice, reviewable,
mergeable patches by developing code independently for 3 years or so
then attempting merge.
If devicescape code is better than mainline, merge it _now_. If it is
not, drop it and start from mainline code.
> And if you are familiar with the current in-kernel 802.11 code (and if
> you know at least two different drivers), you will probably agree that
> many things have to be changed in the current code even if we decided to
> build on the top of it, so the result will finally differ a lot and will
> be almost incompatible with the current code.
That's okay; as long as incremental way exist, first version not being
compatible with last version is not a problem.
Pavel
--
Thanks, Sharp!
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Pavel Machek @ 2005-12-06 15:04 UTC (permalink / raw)
To: Jiri Benc
Cc: Christoph Hellwig, Joseph Jezak, mbuesch, linux-kernel,
bcm43xx-dev, NetDev
In-Reply-To: <20051205203121.48241a08@griffin.suse.cz>
Hi!
> > Please stop beeing a freaking jackass. There are various projects using
> > the current code. It's not perfect but people are working on it.
>
> Yes, and everyone implements his own softmac (this is the third one I
> know about). I tried to put all of these efforts together (google
> through the netdev archives) and wrote many patches.
Well, unfortunately people seem to disagree about "what the right
softmac is". And James's code is in kernel, thats _huge_ advantage.
> > And please stop your stupid devicespace advertisements. If you think the
> > code is so useful why don't you send patches to integrate it with the
> > currently existing wireless code (after cleaning up the horrible mess
> > it is currently)?
>
> This is what I'm doing last two months. But it's not so easy to clean it
> up and it seems that nobody else is interested. But it has all of the
> features you need (except active scanning) - this is the reason I
> stopped to work on improving current in-kernel 802.11 code and focused
> on Devicescape's code. It is several years beyond the state that current
> code is at now. And it is not an advertisement, it is a fact.
Another fact is that it is not in kernel, and by the time you get it
cleaned up, in-kernel code will probably get advanced enough that your
code will not be merged.
If devicescape is really so much better, submit it _now_. It may be
slightly buggy, but so is probably current code.
--
Thanks, Sharp!
^ permalink raw reply
* Registration_Confirmation
From: postman @ 2005-12-06 14:17 UTC (permalink / raw)
To: emailserv
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Account and Password Information are attached!
***** Go to: http://www.gaertner.de
***** Email: postman@gaertner.de
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* CONGRATULATIONS WINNING NOTIFICATION
From: international lottery @ 2005-12-06 12:15 UTC (permalink / raw)
To: internationallottery104
>From Australia/Euro-Afro-American-junostake Lottery
Headquarters: 1a, Bexon Court Carlton
Nottingham shire NG4 1SQ Melbourne Australia.
Customer Service: 580 NCA 85914
Ref: EAASL/941OYI/04
Batch: 12/25/DC34
Dear Sir/Madam,
CONGRATULATIONS! LOTTERY WINNING NOTIFICATION
We happily announce to you the draw of the Australia/Euro-Afro American
Sweepstake Lottery International programs held on the 11th April 2005
in Melbourne Australia.
.
Your e-mail address attached to ticket number: B956475604545 188 with!
Serial number 97560 drew the winning: 01/10/11/18/19/46, which
subsequently
won you the lottery in the 2nd category.
You have therefore been approved to claim a total sum of
US$1,120,000.00
(One Million, One Hundred and Twenty Thousand United States Dollars) in
cash
credited to file KPC/9080118308/02.This is from a total cash prize of
US $2,440,000,00 dollars, shared
amongst the first One Hundred (100) lucky winners in this category
world-wide.
Please note that your lucky winning numbers falls within our Afro
booklet representative office in Southern Africa as indicated in your play
coupon.
In view of this, your US$1,120,000.00 (One Million, One Hundred and
Twenty
Thousand United States Dollars)
would be released to you by FNB Bank South Africa.
Our corresponded office/agent in Southern Africa will immediately
commence
the process to facilitate the release of your funds as soon as you
contact
them. All participants were selected randomly from World Wide Web site
through computer draws system and extracted from over 15,000,00
companies.
This promotion takes place annually. For security reasons, you are
advised to keep your winning information confidential till your claims is
processed and your money remitted to you in whatever manner
you deem fit to claim your prize.
This is part of our precautionary measure to avoid double claiming and
unwarranted abuse of this program by some unscrupulous elements.
“PLEASE BE
WARNED”. To file for your claim, please contact our corresponding
office/agent in South Africa immediately you read this message for
quick and urgent release of your fund.
contact information’s are as follow:
Contact Person. Mr Gerald Smith
EMAIL: geraldsmith_za@yahoo.com or gerald_smith01@yahoo.com
TELEPHONE LINE: + 27-73-860-7422
FAX LINE:+27-11-507-5338
Please be informed that all winning must be claimed on or before 30
days
upon the receipt, to avoid unnecessary delays and complications. Please
quote your reference/batch numbers in any correspondences with our
designated office/agents or us.
Congratulations once more from all members and staffs of this program
that
have successfully won this competition and thank you for being part of
our
promotional lottery program.
NOTE: Please, as soon as you are in contact with our Office/agent,
kindly
keep us informed and your fund must be released under our instruction.
We
are sorry for the late information.
Sincerely Yours,
Mr. Swarth A.Swarth
National Lottery
Australia zonal Secretary General.
Mrs. Teresa Allan.
National Lottery
Australia Zonal Co-coordinator.
>From Australia/Euro-Afro-American-junostake Lottery
Headquarters: 1a, Bexon Court Carlton
Nottingham shire NG4 1SQ Melbourne Australia.
Customer Service: 580 NCA 85914
Ref: EAASL/941OYI/04
Batch: 12/25/DC34
Dear Sir/Madam,
CONGRATULATIONS! LOTTERY WINNING NOTIFICATION
We happily announce to you the draw of the Australia/Euro-Afro American
Sweepstake Lottery International programs held on the 11th April 2005
in Melbourne Australia.
.
Your e-mail address attached to ticket number: B956475604545 188 with!
Serial number 97560 drew the winning: 01/10/11/18/19/46, which
subsequently
won you the lottery in the 2nd category.
You have therefore been approved to claim a total sum of
US$1,120,000.00
(One Million, One Hundred and Twenty Thousand United States Dollars) in
cash
credited to file KPC/9080118308/02.This is from a total cash prize of
US $2,440,000,00 dollars, shared
amongst the first One Hundred (100) lucky winners in this category
world-wide.
Please note that your lucky winning numbers falls within our Afro
booklet representative office in Southern Africa as indicated in your play
coupon.
In view of this, your US$1,120,000.00 (One Million, One Hundred and
Twenty
Thousand United States Dollars)
would be released to you by FNB Bank South Africa.
Our corresponded office/agent in Southern Africa will immediately
commence
the process to facilitate the release of your funds as soon as you
contact
them. All participants were selected randomly from World Wide Web site
through computer draws system and extracted from over 15,000,00
companies.
This promotion takes place annually. For security reasons, you are
advised to keep your winning information confidential till your claims is
processed and your money remitted to you in whatever manner
you deem fit to claim your prize.
This is part of our precautionary measure to avoid double claiming and
unwarranted abuse of this program by some unscrupulous elements.
“PLEASE BE
WARNED”. To file for your claim, please contact our corresponding
office/agent in South Africa immediately you read this message for
quick and urgent release of your fund.
contact information’s are as follow:
Contact Person. Mr Gerald Kabani
EMAIL: geraldsmith_za@yahoo.com or gerald_smith01@yahoo.com
TELEPHONE LINE: + 27-73-860-7422
FAX LINE:+27-11-507-5338
Please be informed that all winning must be claimed on or before 30
days
upon the receipt, to avoid unnecessary delays and complications. Please
quote your reference/batch numbers in any correspondences with our
designated office/agents or us.
Congratulations once more from all members and staffs of this program
that
have successfully won this competition and thank you for being part of
our
promotional lottery program.
NOTE: Please, as soon as you are in contact with our Office/agent,
kindly
keep us informed and your fund must be released under our instruction.
We
are sorry for the late information.
Sincerely Yours,
Mr. Swarth A.Swarth
National Lottery
Australia zonal Secretary General.
Mrs. Teresa Allan.
National Lottery
Australia Zonal Co-coordinator.
^ permalink raw reply
* Re: Broadcom 43xx first results
From: Luc Saillard @ 2005-12-06 10:23 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Jiri Benc, Michael Buesch, linux-kernel, bcm43xx-dev, NetDev
In-Reply-To: <D76B7270-C6A7-4068-9FDD-4C8B9F491F62@mac.com>
On Tue, Dec 06, 2005 at 04:26:50AM -0500, Kyle Moffett wrote:
> 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.
>
I do not want to enter in this flamewar, but the current driver i'm working
on (marvell libertas chipset) need management frames in software. But to
reduce cost, i think that lower chipset try to put the most in the host and
not in the chipset. Marvell build the chipset around a ARM cpu so i think one
day i can do it in hardware but for now i need to choose a ieee802.11 stack.
I've began to used the in kernel solution with my own functions to
send and received this frame. But i hope we will find a technical solution
that please everyone. I'll try to see if the softmac layer written for
broadcom driver can be used for my project.
Luc
^ permalink raw reply
* Re: [PATCH 12/14] spidernet: check if firmware was loaded correctly
From: Arnd Bergmann @ 2005-12-06 10:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, netdev, Jens.Osterkamp
In-Reply-To: <17300.57951.373636.507621@cargo.ozlabs.ibm.com>
On Dinsdag 06 Dezember 2005 01:59, Paul Mackerras wrote:
> 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.
Ok.
Jens, is it ok for you if you send the network driver stuff to
jgarzik@pobox.com, Cc: netdev@vger.kernel.org yourself in the future?
Arnd <><
^ 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
* 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: [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: [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
* 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
* [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
* [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 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 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
* 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
* 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] 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: [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: [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: 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
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