David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Zach Brown <[EMAIL PROTECTED]>
> Date: Fri, 07 Apr 2006 16:59:01 -0700
>
>> b) Just calculate the hashes under the lock, we're already doing lots of
>> work there anyway.
>
> I think this is the best way to go. Then we don't need to think
> abou
Johannes Berg <[EMAIL PROTECTED]> wrote:
>
> @@ -239,6 +259,7 @@ void ieee80211softmac_scan_finished(stru
>if (net)
>sm->set_channel(sm->dev, net->channel);
>}
> + netif_start_queue(sm->ieee->dev);
Please use netif_wake_queue as otherwise packe
jamal <[EMAIL PROTECTED]> wrote:
>
> I think that the broadcast ARP is still valid for any address configured
> as a link local addresses to be done in the kernel - for those reasons
> described in the RFC (which i didnt find very convincing, but other
> people felt strongly about and not having th
On Fri, 2006-07-04 at 18:11 -0700, David S. Miller wrote:
>
> There is actually a desire to move this stuff out of the kernel, especially
> now that we have klibc and the like which is a more appropriate place for
> things like dhcp, rarp, and bootp.
>
Makes a lot of sense.
> So what it comes
Sorry - i promised not to respond on this thread; but since i responded
to Dave, its only fair i respond to you as well.
On Fri, 2006-07-04 at 22:45 +0200, Freek Dijkstra wrote:
> jamal wrote:
>
> > I am assuming you have some form of configuration, no? You should only
> > configure an IP addres
From: jamal <[EMAIL PROTECTED]>
Date: Fri, 07 Apr 2006 21:07:13 -0400
> On Fri, 2006-07-04 at 14:26 -0700, David S. Miller wrote:
>
> > If an RFC specifically describes the behavior of a specific range of
> > IP addresses, we should follow that by default.
> >
>
> The control/ownership of these
On Fri, 2006-07-04 at 14:26 -0700, David S. Miller wrote:
> If an RFC specifically describes the behavior of a specific range of
> IP addresses, we should follow that by default.
>
The control/ownership of these IP addresses happens in user space;
they are the ones which decide what address to u
> I think this is the best way to go. Then we don't need to think
> about it, and frankly I think the "recheck hash rnd after getting
> lock" idea would turn out to be more expensive :)
OK :). I'll throw that together..
- z
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
Quoting Francois Romieu <[EMAIL PROTECTED]>:
> > > Is there a reason why dev->mem_{start/end} should not be removed ?
> >
> > Is there a reason why it should? Is it going to be obsolete?
>
> It is slowly obsoleting for a few years (don't laugh...). It is preferred
> to store the relevant address in
From: Zach Brown <[EMAIL PROTECTED]>
Date: Fri, 07 Apr 2006 16:59:01 -0700
> b) Just calculate the hashes under the lock, we're already doing lots of
> work there anyway.
I think this is the best way to go. Then we don't need to think
about it, and frankly I think the "recheck hash rnd after get
On Fri, Apr 07, 2006 at 06:11:34PM -0500, Linas Vepstas wrote:
> --- linux-2.6.17-rc1.orig/drivers/net/e100.c
> +++ linux-2.6.17-rc1/drivers/net/e100.c
> + * @state: The current pci conneection state
connection
> +static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev,
> pci_channe
On Thu, 6 Apr 2006 22:37:08 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 23, 2006 at 01:06:02PM +1100, Peter Chubb wrote:
> >
> > I see lots of
> > kernel unaligned access to 0xa001009dbb6f, ip=0xa00100811591
> > kernel unaligned access to 0xa001009dbb6b, ip=0xa0
I noticed that ip_find() calculates the hash bucket for the incoming
fragment using ipfrag_hash_rnd outside the ipfrag_lock. So it can race
with ipfrag_secret_rebuild() and end up putting a frag in the previous
bucket instead of the new bucket that ipfrag_secret_rebuild() has put
the previous frag
Catherine Zhang <[EMAIL PROTECTED]> wrote:
>
> Enclosed please find the updated AF_UNIX patch.
>
> ...
>
> --- linux-2.6.17-rc1/include/asm-alpha/socket.h~lsm-secpeer-unix
> 2006-04-03 18:19:47.0 -0400
> +++ linux-2.6.17-rc1-cxzhang/include/asm-alpha/socket.h 2006-04-03
> 18:20
Pavel Roskin <[EMAIL PROTECTED]> :
> On Fri, 2006-04-07 at 23:36 +0200, Francois Romieu wrote:
>
> > > @@ -208,8 +205,8 @@ static int orinoco_pci_init_one(struct p
> > > priv = netdev_priv(dev);
> > > card = priv->card;
> > > card->pci_ioaddr = pci_ioaddr;
> > > - dev->mem_start = pci_iorang
Hi, James, Stephen, Dave and Chris,
Enclosed please find the updated AF_UNIX patch. It addressed three major
issues in the previous patch.
1. No directly calling of the SELINUX function security_sid_to_context().
The fix is to export this and other similar functions through
wrapper functio
On Thu, Apr 06, 2006 at 03:46:43PM -0700, Greg KH wrote:
> On Thu, Apr 06, 2006 at 05:24:00PM -0500, Linas Vepstas wrote:
> > + if(pci_enable_device(pdev)) {
>
> Add a space after "if" and before "(" please.
I guess I'm immune to learning from experience. :-/
Here's a new improved patch.
--li
Pavel Roskin <[EMAIL PROTECTED]> :
> On Fri, 2006-04-07 at 23:24 +0200, Francois Romieu wrote:
> > Pavel Roskin <[EMAIL PROTECTED]> :
> > [...]
> > > diff --git a/drivers/net/wireless/orinoco_pci.c
> > > b/drivers/net/wireless/orinoco_pci.c
> > > index 5362c21..e57e92b 100644
> > > --- a/drivers/n
On Sat, 2006-04-08 at 00:10 +0200, Francois Romieu wrote:
> > + spin_lock_irqsave(&priv->lock, flags);
>
> Interruptions are enabled. No need to save/restore.
Agreed. I have found a few other places where it's also true. I'll fix
it. Actually, I'm going to change the locking to accommodate s
On Fri, 2006-04-07 at 23:36 +0200, Francois Romieu wrote:
> > @@ -208,8 +205,8 @@ static int orinoco_pci_init_one(struct p
> > priv = netdev_priv(dev);
> > card = priv->card;
> > card->pci_ioaddr = pci_ioaddr;
> > - dev->mem_start = pci_iorange;
> > - dev->mem_end = pci_iorange + p
Pavel Roskin <[EMAIL PROTECTED]> :
> index 000..b05a9a5
> --- /dev/null
> +++ b/drivers/net/wireless/orinoco_pci.h
[...]
> +static int orinoco_pci_resume(struct pci_dev *pdev)
> +{
> + struct net_device *dev = pci_get_drvdata(pdev);
> + struct orinoco_private *priv = netdev_priv(dev);
>
Hello!
On Fri, 2006-04-07 at 23:24 +0200, Francois Romieu wrote:
> Pavel Roskin <[EMAIL PROTECTED]> :
> [...]
> > diff --git a/drivers/net/wireless/orinoco_pci.c
> > b/drivers/net/wireless/orinoco_pci.c
> > index 5362c21..e57e92b 100644
> > --- a/drivers/net/wireless/orinoco_pci.c
> > +++ b/drive
From: Brian Haley <[EMAIL PROTECTED]>
Date: Fri, 07 Apr 2006 15:37:51 -0400
> Can't build latest 2.6 kernel with CONFIG_NETFILTER=y/m on IA64, there's
> a missing #include in net/ipv6/netfilter.c
>
> net/ipv6/netfilter.c: In function `nf_ip6_checksum':
> net/ipv6/netfilter.c:92: warning: implici
Seems we forgot to stop the queue while scanning. Better do that so we
don't transmit packets all the time during background scanning.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
--- a/net/ieee80211/softmac/ieee80211softmac_scan.c
+++ b/net/ieee80211/softmac/ieee80211softmac_scan.c
@@ -47,6
Pavel Roskin <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/net/wireless/orinoco_pci.c
> b/drivers/net/wireless/orinoco_pci.c
> index e57e92b..75df90f 100644
> --- a/drivers/net/wireless/orinoco_pci.c
> +++ b/drivers/net/wireless/orinoco_pci.c
> @@ -170,9 +170,7 @@ static int orinoco_pci_init_
From: Freek Dijkstra <[EMAIL PROTECTED]>
Date: Fri, 07 Apr 2006 22:45:46 +0200
> Jamal also wrote:
> > Should we hard-code checks for RFC 1918 IPV4 addresses in the kernel?
> > After all, they are well defined by the IETF. The answer is no.
>
> You make a valid argument here: that hard-coding IP
Pavel Roskin <[EMAIL PROTECTED]> :
[...]
> diff --git a/drivers/net/wireless/orinoco_pci.c
> b/drivers/net/wireless/orinoco_pci.c
> index 5362c21..e57e92b 100644
> --- a/drivers/net/wireless/orinoco_pci.c
> +++ b/drivers/net/wireless/orinoco_pci.c
> @@ -304,7 +304,9 @@ static int orinoco_pci_suspe
Begin forwarded message:
Date: Fri, 7 Apr 2006 06:12:07 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6349] New: iptables DNAT returns unknown error
4294967295
http://bugzilla.kernel.org/show_bug.cgi?id=6349
Summary: iptables DNAT returns unknown er
David S. Miller wrote:
From: David Acker <[EMAIL PROTECTED]>
Date: Fri, 07 Apr 2006 14:12:05 -0400
This is a second attempt at a patch for include/linux/if_vlan.h .
Its purpose is to allow a user space program to use the vlan_ethhdr
structure when directly handling 802.1Q packets. This can be
On Fri, 2006-07-04 at 13:31 -0700, David Daney wrote:
> jamal wrote:
> >
> > RFC 3927 defines what addresses are legit link local scope. The kernel
> > says what to do with addresses that are link local scopes. It knows this
> > if you tell it is a link local address.
> >
>
> The point that I
jamal wrote:
> I am assuming you have some form of configuration, no? You should only
> configure an IP address to be link local if you really mean it to be
> so.
Typically, there is no user-configuration.
The 169.254.0.0./16 and FE80::0/8 IP ranges are used for so-called zero
configuration net
David Daney wrote:
Following your logic through, It seems that you are advocating
broadcasting *all* ARP packets on *all* link local addresses. That
would mean that on a 192.168.* switched Ethernet network with DHCP
that twice as many ARP packets would be broadcast.
192.168.* addresses are
jamal wrote:
On Fri, 2006-07-04 at 11:31 -0700, David Daney wrote:
jamal wrote:
It exists. Just use it. For testing just use the ip utility.
But why does it exist? There must be one or more reasons that it exists.
There is only one reason it exists: to define an IP address as being
l
From: David Acker <[EMAIL PROTECTED]>
Date: Fri, 07 Apr 2006 14:12:05 -0400
> This is a second attempt at a patch for include/linux/if_vlan.h .
> Its purpose is to allow a user space program to use the vlan_ethhdr
> structure when directly handling 802.1Q packets. This can be done
> by using a ra
On Fri, 2006-07-04 at 11:31 -0700, David Daney wrote:
> jamal wrote:
> > It exists. Just use it. For testing just use the ip utility.
>
> But why does it exist? There must be one or more reasons that it exists.
>
There is only one reason it exists: to define an IP address as being
link local.
From: Heiko Carstens <[EMAIL PROTECTED]>
Date: Fri, 7 Apr 2006 10:15:33 +0200
> From: Heiko Carstens <[EMAIL PROTECTED]>
>
> The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK
> detects that this lock is not initialized as it is supposed to be.
>
> Signed-off-by: Heiko Carst
Can't build latest 2.6 kernel with CONFIG_NETFILTER=y/m on IA64, there's
a missing #include in net/ipv6/netfilter.c
net/ipv6/netfilter.c: In function `nf_ip6_checksum':
net/ipv6/netfilter.c:92: warning: implicit declaration of function
`csum_ipv6_magic'
LD net/ipv6/ipv6.o
LD net/
jamal wrote:
broadcasting requirement would result in generation of unnecessary
network traffic in configurations that are probably the majority of
Linux deployments.
If you choose to configure something to be link local, then you should
live with the consequences.
169.254.0.0/16 is by
From Dave Acker <[EMAIL PROTECTED]>
The purpose is to allow a user space program to use the vlan_ethhdr
structure when directly handling 802.1Q packets. This can be done
by using a raw socket like:
int s = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
This socket should see VLAN packets from th
Hi,
Johannes Berg wrote:
> Below patch was developed after discussion with Daniel Drake who
> mentioned to me that wireless tools expect an EAGAIN return from getscan
> so that they can wait for the scan to finish before printing out the
> results.
And why do you implement it across two files?
I
This is a second attempt at a patch for include/linux/if_vlan.h .
Its purpose is to allow a user space program to use the vlan_ethhdr
structure when directly handling 802.1Q packets. This can be done
by using a raw socket like:
int s = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
This socket sh
BTW, what is the point of CCing lkml? This is a networking issue. People
interested in networking discussions join netdev. I have taken it,
please keep it that way.
On Fri, 2006-07-04 at 09:18 -0700, David Daney wrote:
> jamal wrote:
> > On Thu, 2006-06-04 at 09:17 -0700, David Daney wrote:
> >
On Fri, 2006-07-04 at 18:01 +0200, Freek Dijkstra wrote:
> jamal wrote:
> > Excellent point! It was bothering me as well but i couldnt express my
> > view eloquently as you did.
>
> Explicitly defining scope may indeed be a better approach at first
> sight, but there are a few very practical reas
jamal wrote:
On Thu, 2006-06-04 at 09:17 -0700, David Daney wrote:
Janos Farkas wrote:
Sorry for chiming in this late in the discussion, but... Shouldn't it
be more correct to not depend on the ip address of the used network,
but to use the "scope" parameter of the given address?
Exce
jamal wrote:
>>> Sorry for chiming in this late in the discussion, but... Shouldn't it
>>> be more correct to not depend on the ip address of the used network,
>>> but to use the "scope" parameter of the given address?
>
> Excellent point! It was bothering me as well but i couldnt express my
> v
On Fri, 2006-07-04 at 08:06 -0600, Mark Butler wrote:
> In IPv4, how is this information supposed to be communicated? The
> possibilities I can see are:
>
> 1. Assuming link local based on SO_BINDTODEVICE.
> 2. Adding a new field to sockaddr_in in a backward compatible manner
> 3. Defining a new
On Fri, 7 Apr 2006 10:15:33 +0200
Heiko Carstens <[EMAIL PROTECTED]> wrote:
> From: Heiko Carstens <[EMAIL PROTECTED]>
>
> The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK
> detects that this lock is not initialized as it is supposed to be.
>
> Signed-off-by: Heiko Carsten
On Sat, 2006-08-04 at 00:14 +1000, Herbert Xu wrote:
> This looks good except that I think the flag beats jiffies since the
> latter can wrap around. Of course on any sane setup the SA should've
> expired by then but it pays to be safe.
>
Ok, Lets hear Krisztian's view for a tie breaker. Whiche
Mark Butler wrote:
jamal wrote:
On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the
jamal wrote:
On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in
Hi Jamal:
On Fri, Apr 07, 2006 at 09:15:41AM -0400, jamal wrote:
>
> Ok, I built on Herbert's suggestion and tried to be a little
> clever/accurate. Instead of a flag i introduce a variable that stores
> the jiffy point when the timer is killed. If we fall anywhere to the
> right or at exact poin
On Fri, 2006-07-04 at 17:20 +1000, Anand Kumria wrote:
> On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
>
> > From: David Daney
> >
> > Greetings,
> >
> > When an internet host joins a network where there is no DHCP server,
> > it may auto-allocate an IP address by the method described i
On Thu, 2006-06-04 at 09:17 -0700, David Daney wrote:
> Janos Farkas wrote:
> > Sorry for chiming in this late in the discussion, but... Shouldn't it
> > be more correct to not depend on the ip address of the used network,
> > but to use the "scope" parameter of the given address?
> >
>
Excell
On Thu, 2006-06-04 at 22:13 +0200, KOVACS Krisztian wrote:
> Hi,
>
> On Thursday 06 April 2006 17:18, jamal wrote:
> > On Fri, 2006-07-04 at 00:30 +1000, Herbert Xu wrote:
> > > If so I see what you mean but I think a better solution is to just
> > > set a flag when the XFRM_REPLAY_TIMEOUT fires
On Thu, 2006-06-04 at 18:29 +0200, Patrick McHardy wrote:
[..]
> There are basically two possibilities how to implement this. The less
> intrusive, but IMO more hackish one is to just handle this inside the
> qdiscs that require this operation by not requeueing the packet to
> the qdisc, but keepi
> "Michael" == Michael Buesch <[EMAIL PROTECTED]> writes:
Michael> If you use pci_iomap, you will have to use its counterpart,
Michael> pci_iounmap, too.
Indeed... Here is the latest patch.
M.
This patch (against 2.6.17-rc1) converts the cassini driver to the
pci_iomap API, so archi
From: Heiko Carstens <[EMAIL PROTECTED]>
The qeth driver makes use of the arp_tbl rw lock. CONFIG_DEBUG_SPINLOCK
detects that this lock is not initialized as it is supposed to be.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
net/ipv4/arp.c |1 +
1 file changed, 1 insertion(+)
diff
From: Jiri Benc <[EMAIL PROTECTED]>
After several days of operation of Netgear MA311 card, the card becomes
to seek improperly and needs reset. This patch tries to reset the card
when this situation occurs.
Mar 9 06:45:16 berkeley kernel: wlan0: Error -5 writing packet to BAP
Mar 9 06:45:16 ber
From: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/spectrum_cs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/spectrum_cs.c
b/drivers/net/wireless/spectrum_cs.c
index 58c153a..14f4da
From: Pavel Roskin <[EMAIL PROTECTED]>
When processing Tx exception, only read data until addr1. Rename
hermes_tx_descriptor_802_11 to hermes_txexc_data since it's only used to
Tx exceptions. Reuse existing hermes_tx_descriptor structure. Remove
fields after addr1 - they are not read from the c
From: Pavel Roskin <[EMAIL PROTECTED]>
Use skb_pull() to strip the addresses from the original packet. Don't
strip protocol bytes.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco.c | 44 ++--
drivers/net/wireless/orinoco.h
From: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/orinoco.h b/drivers/net/wireless/orinoco.h
index ca01e45..16db3e1 100644
--- a/
From: Pavel Roskin <[EMAIL PROTECTED]>
The result of orinoco_xmit() can be OK, dropped packet and busy
transmitter. Rename labels accordingly. Increment stats->tx_errors in
one place. Increment stats->tx_dropped - nobody is doing it for us.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
From: Pavel Roskin <[EMAIL PROTECTED]>
Copy PCI suspend/resume functions from orinoco_pci.c.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco_nortel.c | 87 +++--
drivers/net/wireless/orinoco_plx.c| 79 +
From: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco_pci.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/orinoco_pci.c
b/drivers/net/wireless/orinoco_pci.c
index 5362c21
From: Pavel Roskin <[EMAIL PROTECTED]>
The new function can write an odd number of bytes, thus making padding
unnecessary.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/hermes.c | 17 -
drivers/net/wireless/hermes.h |7 +--
drivers/
From: Pavel Roskin <[EMAIL PROTECTED]>
hermes_bap_pwrite() supports odd-sized packets now. There is no
minimal packet size for 802.11. Also, hermes_bap_pwrite() supports
odd-sized packets now. This removes all reasons to pad the Tx data.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
d
From: Pavel Roskin <[EMAIL PROTECTED]>
Make all Orinoco PCI drivers (orinoco_pci, orinoco_plx, orinoco_tmd and
orinoco_nortel) as similar as possible. Use the best implementation of
error handling, the best error messages, the best comments.
Put common code to orinoco_pci.h. For now, it's suspe
From: Pavel Roskin <[EMAIL PROTECTED]>
This is needed to identify the card before possible allocation problems,
so that the user at least can report the firmware version that fails.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco.c | 28 ++-
From: Pavel Roskin <[EMAIL PROTECTED]>
Don't ever return -errno from orinoco_xmit() - the network layer doesn't
expect it.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drive
From: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco_nortel.c |7 +--
drivers/net/wireless/orinoco_pci.c| 69 +
drivers/net/wireless/orinoco_plx.c| 42 +++-
drivers/
From: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco_pci.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/orinoco_pci.c
b/drivers/net/wireless/orinoco_pci.c
index e57e
From: Pavel Roskin <[EMAIL PROTECTED]>
The PCMCIA drivers would never be loaded if the CIS were wrong.
No other PCMCIA drivers validate CIS.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco_cs.c |3 ---
drivers/net/wireless/spectrum_cs.c |3 ---
2 files
From: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco.c | 83
drivers/net/wireless/orinoco.h |3 -
2 files changed, 0 insertions(+), 86 deletions(-)
diff --git a/drivers/net/wireless
From: Pavel Roskin <[EMAIL PROTECTED]>
Symbol firmware F3.91-71 has an additional word in the commsquality RID.
Extend the receiving buffer by one word to accomodate it.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco.c |2 +-
1 files changed, 1 insertions(+
From: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/hermes.c | 19 ---
drivers/net/wireless/hermes.h | 34 --
2 files changed, 0 insertions(+), 53 deletions(-)
diff --git a/drivers/ne
From: Pavel Roskin <[EMAIL PROTECTED]>
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/orinoco_cs.c |6 --
drivers/net/wireless/spectrum_cs.c |6 --
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/orinoco_cs.c
b/driv
From: Pavel Roskin <[EMAIL PROTECTED]>
Sparse is much better at finding endianess issues than such visual cues.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
---
drivers/net/wireless/spectrum_cs.c | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --
Hello!
I'm about to submit series of 21 patches for Orinoco drivers. Those
patches have been in Orinoco CVS for months, and there have been no bug
reports. I believe it's about time that I submit the patches to the
kernel.
I know, I've missed the boat for 2.6.17 (sorry for that, I was really
ov
On Fri, 31 Mar 2006 15:26:00 -0800, David Daney wrote:
> From: David Daney
>
> Greetings,
>
> When an internet host joins a network where there is no DHCP server,
> it may auto-allocate an IP address by the method described in RFC
> 3927. There are several user space daemons available that impl
80 matches
Mail list logo
