From: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 20:35:40 +0900
> I fixed. As mentioned in another mail, I mixed up the changes
> in my previous patch. This adds "IPv6 over IPv4 IPsec tunnel".
> The fix of extra tab is included in another mail.
>
> Signed-off-by: Miika Komu <[EMA
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 06 Dec 2006 23:37:49 -0800 (PST)
> From: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
> Date: Wed, 6 Dec 2006 20:35:37 +0900
>
> > BTW, I have a question about descrementing the reference count of
> > rt->peer. The reference cound in normal "dst" struct
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 06 Dec 2006 23:37:49 -0800 (PST)
> From: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
> Date: Wed, 6 Dec 2006 20:35:37 +0900
>
> > Sorry, I mixed up changes in the patches. I described that [4/7] will add
> > "IPv6 over IPv4 IPsec tunnel". However I send
From: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 20:35:37 +0900
> Sorry, I mixed up changes in the patches. I described that [4/7] will add
> "IPv6 over IPv4 IPsec tunnel". However I send a patch for "IPv4 over IPv6"
> as a reply because it includes the discussing item.
> So this
From: "Amit S. Kale" <[EMAIL PROTECTED]>
Date: Thu, 7 Dec 2006 11:55:22 +0530
> We can let a driver handle dma mapping errors using these->
>
> 1.Reduce the size of a receive ring. This will free some possibly remapped
> memory, reducing pressure on iommu. We also need to printk a message so tha
It worries me when a patch series gets resent a few hours later.
Did anything change?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[TG3]: Identify Serdes devices more clearly.
Change the message to more clearly identify Serdes devices.
Update version to 3.70.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 61e9533..a71707e 100644
--- a/drivers/net/tg3.c
+++ b/drivers
[TG3]: Use netif_msg_*.
Use netif_msg_* to turn on or off some messages.
Based on Stephen Hemminger's initial patch.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 5dfeb64..99fb4e4 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@
[TG3]: Use msleep.
Change some udelay() in some eeprom functions to msleep(). Eeprom
related functions are always called from sleepable context.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 99fb4e4..61e9533 100644
--- a/drivers/net/tg3
[TG3]: Allow partial speed advertisement.
Honor the advertisement bitmask from ethtool. We used to always
advertise the full capability when autoneg was set to on.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 6a2f019..5dfeb64 100644
--
[TG3]: Fix Phy loopback.
Phy loopback on most 10/100 devices need to be run in 1Gbps mode in
GMII mode.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index c20bb99..819758e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8781,17 +87
[TG3]: Add TG3_FLG2_IS_NIC flag.
Add Tg3_FLG2_IS_NIC flag to unambiguously determine whether the
device is NIC or onboard. Previously, the EEPROM_WRITE_PROT flag was
overloaded to also mean onboard. With the separation, we can
support some devices that are onboard but do not use eeprom write
pro
[TG3]: Add 5787F device ID.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 819758e..bfa7e3e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -192,6 +192,7 @@ static struct pci_device_id tg3_pci_tbl[
{PCI_DEVICE(PCI_VENDOR_
On Thursday 07 December 2006 12:16, Stephen Hemminger wrote:
> Amit S. Kale wrote:
> > We can let a driver handle dma mapping errors using these->
> >
> > 1.Reduce the size of a receive ring. This will free some possibly
> > remapped memory, reducing pressure on iommu. We also need to printk a
> >
Amit S. Kale wrote:
We can let a driver handle dma mapping errors using these->
1.Reduce the size of a receive ring. This will free some possibly remapped
memory, reducing pressure on iommu. We also need to printk a message so that
a user knows the reason why receive ring was shrunk. Growing i
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>On 12/4/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
[...]
>> Appended is my working development patch for rearranging a bunch
>> of stuff in bonding. This is a work in progress, and is not likely to
>> be very stable. This largely reimplements
We can let a driver handle dma mapping errors using these->
1.Reduce the size of a receive ring. This will free some possibly remapped
memory, reducing pressure on iommu. We also need to printk a message so that
a user knows the reason why receive ring was shrunk. Growing it when iommu
pressure
On Thursday 07 December 2006 01:03, Muli Ben-Yehuda wrote:
> On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote:
> > I think it is really only an issue for drivers that turn on HIGH_DMA
> > and have limited mask values. The majority of drivers either only
> > handle 32 bit (!HIGH_DMA
> What Eugene does currently, which seems to me like it's actually the
> only proper solution, is to create a separate net_device structure for
> the DMA engine and thus have a single NAPI poll & weighting for all the
> EMACs sharing a given MAL (MAL is the name of that DMA engine). This
> means t
Hi Dave !
I'd like your advice on something we need to deal with in the EMAC
ethernet driver (an IBM part). The driver is maintainedby Eugene (CC'd),
I'm mostly adding support for some new hardware at this point, which
involves making it SMP safe among other things ;-)
So the problem this driver
From: Randy Dunlap <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 17:08:18 -0800
> On Wed, 06 Dec 2006 16:57:17 -0800 (PST) David Miller wrote:
>
> > How about we protect these function externs with CONFIG_PROC_FS ifdefs
> > instead?
>
> Sure.
>
> ---
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fi
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Thu, 7 Dec 2006 02:51:17 +0200
> We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in.
>
> Patch from Jeet Chaudhuri <[EMAIL PROTECTED]>
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
Also applied.
Are you sending this patch to -stable? Ple
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Thu, 7 Dec 2006 02:50:53 +0200
> pxaficp_ir.c was not converted to the device model framework.
>
> Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 06 Dec 2006 18:18:52 -0800
> While tossing a TCP|UDP|SCTP|etc packet could be plusungood, especially
> if the IOMMU fills frequently (for some suitable definiton of
> frequently), is it really worth the effort to save say an ACK?
ACKs are less imp
David Miller wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 16:58:35 -0800
The more robust way would be to stop the queue (like flow control)
and return busy. You would need a timer though to handle the case
where some disk i/o stole all the mappings and then network
On 12/4/06, Jay Vosburgh <[EMAIL PROTECTED]> wrote:
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
[...]
>> Let me see if I can dust off the extensive patch that does
>> change the locking model; I'll see if I can bring it up to the current
>> git and post it.
>>
>
>It would seem ideal if we
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 16:58:35 -0800
> The more robust way would be to stop the queue (like flow control)
> and return busy. You would need a timer though to handle the case
> where some disk i/o stole all the mappings and then network device flow
> bloc
On Wed, 06 Dec 2006 16:57:17 -0800 (PST) David Miller wrote:
> How about we protect these function externs with CONFIG_PROC_FS ifdefs
> instead?
Sure.
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix compile warning when CONFIG_PROC_FS=n:
include/net/irda/irlan_filter.h:31: warning: 'struct seq_
On Wed, 06 Dec 2006 16:54:18 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 6 Dec 2006 10:16:44 -0800
>
> > I think it is really only an issue for drivers that turn on HIGH_DMA
> > and have limited mask values. The majority of driver
From: Randy Dunlap <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 11:44:07 -0800
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix compile warning when CONFIG_PROC_FS=n:
>
> include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared
> inside parameter list
> include/net/irda/irlan_filter
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 20:32:40 +0100 (MET)
> Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf:
>
> > I do not agree with the change to include if_addr.h in rtnetlink.h.
> > The point is to move bits apart and have multiple small pieces
> > of header fil
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 10:16:44 -0800
> I think it is really only an issue for drivers that turn on HIGH_DMA
> and have limited mask values. The majority of drivers either only handle
> 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the detail
Hi Dave,
pxaficp_ir.c was not converted to the device model framework.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
drivers/net/irda/pxaficp_ir.c | 26
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in.
Patch from Jeet Chaudhuri <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
net/irda/irttp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/irda/irttp.c b/net/irda/irttp.c
index 252f
We should be checking the type member, not the raw pointer.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless-dev/net/
Without this change d80211 relies on userspace to let it know when it can
configure default wep keys. It is always safe to set default_wep_only if there
is a single station interface. This allows for hardware accelleration for
the case of a single station interface.
Signed-off-by: David Kimdon <
dev->name and ndev->name are both IFNAMSIZ in length, the ".%d" is
not guarenteed to fit in ndev->name.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_iface.c
===
--- wireless-dev.orig/net/d8
sdata->keys[] has NUM_DEFAULT_KEYS elements, don't access past that.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_ioctl.c
+++ wireless
If a hardware key has not been configured then there is no point
to calling DISABLE_KEY.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211_ioctl.c
===
--- wireless-dev.orig/net/d80211/ieee80211_
From: Ralf Baechle <[EMAIL PROTECTED]>
Date: Wed, 6 Dec 2006 21:49:46 +
> I believe all the below memory barriers only matter on SMP so therefore
> the smp_* variant of the barrier should be used.
>
> I'm wondering if the barrier in net/ipv4/inet_timewait_sock.c should be
> dropped entirely.
In these three cases the pointer returned by IEEE80211_DEV_TO_SUB_IF()
is never used.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/net/d80211/ieee80211.c
===
--- wireless-dev.orig/net/d80211/ieee80211.c
+++ wir
Remove incorrect prohibition of hardware crypto support. This was
originally present to prevent hardware crypto when more than one
station interface was created for a single hardware device, the code
in question is no longer correct and should be removed.
Signed-off-by: David Kimdon <[EMAIL PROTE
Michael Buesch wrote:
On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote:
On 06-12-06 21:52 Michael Buesch wrote:
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
On 06-12-06 18:52 Michael Buesch wrote:
All data in mac->associnfo is protected by mac->associnfo->mutex
and _not
Make the hardware perceive the RX descriptor ring as a
null-terminated linked list, instead of a circular ring.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 10 --
1 file c
Add some debugging and error printing.
The show_rx_chain() prints out the status of the rx chain,
which shows that the status of the descriptors gets
messed up after the second & subsequent RX ramfulls.
Print out contents of bad packets if error occurs.
Signed-off-by: Linas Vepstas <[EMAIL PROT
Delete possible source of chain corruption; the hardware
already knows the location of the tail, and writing it
again is likely to mess it up.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_ne
Re-enable irq's after emptying the RX ring; these had
been previously turned off on reception of the rxram_full
interrupt. More punctuation cleanup.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spid
Add memory barrier to make sure that the rest of the
RX descriptor state is flushed to memory before we tell
the hardware that its ready to go.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_
Tell the hardware the location of the rx ring tail.
More punctuation cleanup.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 15 ---
1 file changed, 8 insertions(+), 7 del
Remove unused variable; this makes code easier to read.
Tweak commentary.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-
The invocation of the rx ring refill routine is haphazard;
centralize and make its usage consistent.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 11 ---
1 file changed, 4 i
Two distinct if() statements have the ame body. Merge the clauses.
Also clean up punctuation, capitalization, etc.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 28 --
Simplify the somewhat convoluted use of return codes
in the rx buffre handling.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 31 ---
1 file changed, 12 i
Another skb leak in an error branch. Fix this by adding
call to dev_kfree_skb_irq() after moving to a more
appropriate spot.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 23
One of the unlikely error branches has an skb memory leak.
Fix this by handling the error conditions consistently.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c | 18 +-
Refactor how spider_net_refill_rx_chain() is called.
No functional change; this just simplifies the code
by moving the subroutine call to a more appropriate spot.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
d
The RX packet handling can be called from several
places, yet does not protect the rx ring structure.
This patch places the ring buffer pointers under a lock.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Cc: James K Lewis <[EMAIL PROTECTED]>
Cc: Arnd Bergmann <[EMAIL PROTECTED]>
driver
This patch adds net_ratelimit to many of the printks
in order to limit extraneous warning messages
This patch supercedes all previous ratelimit patches.
This has been tested, please apply.
From: James K Lewis <[EMAIL PROTECTED]>
Signed-off-by: James K Lewis <[EMAIL PROTECTED]>
Signed-off-by: Li
The current driver code performs 512 DMA mappings of a bunch of
32-byte structures. This is silly, as they are all in contiguous
memory. Ths patch changes the code to DMA map the entie area
with just one call.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Acked-by: Joel Schopp <[EMAIL PROTEC
On Wed, 06 Dec 2006 12:44:26 -0500
jamal <[EMAIL PROTECTED]> wrote:
>
> a small one.
> I have a few more but just run out of cycles for now;
> if you dont mind holding before releasing for a short while so i can
> get them out I will appreciate it.
>
> cheers,
> jamal
>
applied all 4 thanks
Hi Randy,
Thanks for the patch. Looks fine to me.
On Wed, Dec 06, 2006 at 11:44:07AM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix compile warning when CONFIG_PROC_FS=n:
>
> include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared
> inside parameter
On Wednesday 06 December 2006 22:51, Ulrich Kunitz wrote:
> On 06-12-06 21:52 Michael Buesch wrote:
>
> > On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
> > > On 06-12-06 18:52 Michael Buesch wrote:
> > >
> > > > All data in mac->associnfo is protected by mac->associnfo->mutex
> > > >
Andrew,
Please apply and forward upstream. This series of 16 small patches
consist of mostly of various cleanups, a few fixes, and a clarification
of the flow of the RX side of the spidernet ethernet driver. The
first patch, though, is a resubmit of an old patch.
--linas
-
To unsubscribe fro
On 12/6/06, Jiri Benc <[EMAIL PROTECTED]> wrote:
On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote:
> On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > Ok, so input device opening should not block the rfkill signal and the
rfkill handler
> > should still go through with its work un
On Wed, 6 Dec 2006 15:18:12 -0500, Dmitry Torokhov wrote:
> On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > Ok, so input device opening should not block the rfkill signal and the
> > rfkill handler
> > should still go through with its work unless a different config option
> > indicates t
On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > 2 - Hardware key that does not control the hardware radio and does not
report anything to userspace
>
> Kind of uninteresting button ;)
And this is the button that rfkill was originally designed for.
Laptops with integrated WiFi cards f
On 06-12-06 21:52 Michael Buesch wrote:
> On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
> > On 06-12-06 18:52 Michael Buesch wrote:
> >
> > > All data in mac->associnfo is protected by mac->associnfo->mutex
> > > and _not_ mac->lock.
> >
> > Are you sure?
>
> Yes I am.
>
> > One ca
I believe all the below memory barriers only matter on SMP so therefore
the smp_* variant of the barrier should be used.
I'm wondering if the barrier in net/ipv4/inet_timewait_sock.c should be
dropped entirely. schedule_work's implementation currently implies a
memory barrier and I think sane sem
Hi,
> > > That is my point. Given the fact that there are keys that are not
> > > directly connected with the radio switch userspace will have to handle
> > > them (wait for events then turn off radios somehow). You are
> > > advocating that userspace should also implement 2nd method for buttons
>
* Al Viro <[EMAIL PROTECTED]> 2006-12-06 20:34
> On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:
> > * Al Viro <[EMAIL PROTECTED]> 2006-12-06 17:13
> > > On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
> > >
> > > > At the time they were added they were meant to be expor
On Wednesday 06 December 2006 21:17, Ulrich Kunitz wrote:
> On 06-12-06 18:52 Michael Buesch wrote:
>
> > All data in mac->associnfo is protected by mac->associnfo->mutex
> > and _not_ mac->lock.
>
> Are you sure?
Yes I am.
> One can find for instance the following function in
> ieee80211softm
On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:
> * Al Viro <[EMAIL PROTECTED]> 2006-12-06 17:13
> > On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
> >
> > > At the time they were added they were meant to be exported but netlink
> > > has evolved and we now have a type
On 06-12-06 18:52 Michael Buesch wrote:
> All data in mac->associnfo is protected by mac->associnfo->mutex
> and _not_ mac->lock.
Are you sure? One can find for instance the following function in
ieee80211softmac_assoc.c:
void
ieee80211softmac_disassoc(struct ieee80211softmac_device *mac)
{
* Stefan Rompf <[EMAIL PROTECTED]> 2006-12-06 20:32
> According to a user's report, your change also broke compilation of my
> dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to
> make one source code build on 2.6.19 and older headers? I hope you don't want
> me to check
On 12/6/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote:
> On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > > I am still not sure that tight coupling of input device with rfkill
> > > structure is such a good idea. Quite often the bu
* Al Viro <[EMAIL PROTECTED]> 2006-12-06 17:13
> On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
>
> > At the time they were added they were meant to be exported but netlink
> > has evolved and we now have a type safe API.
>
> Where? AFAICS, netlink might be considered type-safe on
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix compile warning when CONFIG_PROC_FS=n:
include/net/irda/irlan_filter.h:31: warning: 'struct seq_file' declared inside
parameter list
include/net/irda/irlan_filter.h:31: warning: its scope is only this definition
or declaration, which is probably not wh
On Wednesday 06 December 2006 15:37, Dmitry Torokhov wrote:
> On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > > I am still not sure that tight coupling of input device with rfkill
> > > structure is such a good idea. Quite often the button is separated
> > > from the device itself and radi
Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf:
> I do not agree with the change to include if_addr.h in rtnetlink.h.
> The point is to move bits apart and have multiple small pieces
> of header files defining a specific rtnetlink family which are a
> lot easier to maintain for both kernel
On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote:
> I think it is really only an issue for drivers that turn on HIGH_DMA
> and have limited mask values. The majority of drivers either only
> handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know
> the details of how we
On Tue, 5 Dec 2006 09:00:45 +0200
Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 04, 2006 at 10:39:49AM -0800, Stephen Hemminger wrote:
>
> > I notice that no current network driver handles dma mapping errors.
> > Might that be part of the problem. On i386, this never happens, and
> >
On Wed, Dec 06, 2006 at 02:54:16PM +0300, Kirill Korotaev wrote:
> >>>If there is a better and less intrusive while still being obvious
> >>>method I am all for it. I do not like the OpenVZ thing of doing the
> >>>lookup once and then stashing the value in current and the special
> >>>casing the e
Hi, guys.
I've got a problem. I can see all the incoming packets on an ethernet
interface, but no outgoing packets, although they are sent to the
network, and successfully recieved by the other side. The platform is
ixp420, with severely nodifyed ethernet driver, the kernel is
2.6.16.20. May I a
On Wednesday 06 December 2006 15:45, Larry Finger wrote:
> From: Ulrich Kunitz <[EMAIL PROTECTED]>
>
> A deauthentication from the AP doesn't start a reassociation by
> SoftMAC. To fix this mac->associnfo.associating must be set and the
> ieee80211softmac_assoc_work function must be scheduled.
>
a small one.
I have a few more but just run out of cycles for now;
if you dont mind holding before releasing for a short while so i can
get them out I will appreciate it.
cheers,
jamal
[DOC]: clarify "ok" and "pass"
A small fixup to elucidate the mysteries of accepting ..
---
commit d3f9d336f
Ok, heres hopefully the last one in this series for generic netlink ..
cheers,
jamal
[GENL]: Add controller support for new features exposed
Update the controller to spit out the new features being exposed
from the kernel
Signed-off-by: J Hadi Salim <[EMAIL PROTECTED]>
---
commit 241e28d5d5d3
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 06 Dec 2006 12:02:23 -0500
> fixes something i broke in previous patch. Against net-2.6.20.
> BTW, is it just me having problems syncing net-2.6.20?
You should be using the net-2.6.git tree now, I blow away the
net-2.6.X.git tree when 2.6.X integration s
On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
> At the time they were added they were meant to be exported but netlink
> has evolved and we now have a type safe API.
Where? AFAICS, netlink might be considered type-safe only within an
address family...
-
To unsubscribe from this l
A small typo fixup
BTW, how do you like the subject to look like?
cheers,
jamal
[GENL] Multicast computation off by one
When using the first 32 groups, the multicast group to bit mapping
was off by one.
Signed-off-by: Jamal Hadi Salim
---
commit b883bf2396abc0434b3a63d228593cec80808dbb
tree dba
Stepehen,
Didnt hear back from you, please apply this one; needed for the next
patches.
cheers,
jamal
[GENL] Update generic netlink header
The header file needs to be uptodate with recent changes to allow
for forward compatibility
Signed-off-by: J Hadi Salim <[EMAIL PROTECTED]>
---
commit 515
Jarek Poplawski wrote:
> On 04-12-2006 16:34, Patrick McHardy wrote:
>
>>Thomas, Jamal, do you have an idea what this "old method" stuff
>>is used for? It seems it is only used during the below mentioned
>>race.
>
>
> Sorry for eavesdropping, but have a look at htb_classify
> starting comment. I
fixes something i broke in previous patch. Against net-2.6.20.
BTW, is it just me having problems syncing net-2.6.20?
cheers,
jamal
[GENETLINK] fix misplaced command flags
The command flags for dump and do were swapped..
Signed-off-by: Jamal Hadi Salim<[EMAIL PROTECTED]>
---
commit 03b09fc1e8f
On Wed, 6 Dec 2006 21:40:34 +0530
"Amit S. Kale" <[EMAIL PROTECTED]> wrote:
> Hi Stephen,
>
> This patch looks good.
>
> ioctls: NetXen chip is far more generic and will eventually show a
> significant
> amount of functionality in different products. We need ioctl analysis for
> user level t
All,
Attached is a patch to fix arp_reply when you have multiple possible
routers doing ARP requests to you. Currently arp_reply always replies to the
MAC address that it was given when it starts. However, if you have multiple
routers that can ARP request you, you might respond to the wro
Hi Stephen,
This patch looks good.
ioctls: NetXen chip is far more generic and will eventually show a significant
amount of functionality in different products. We need ioctl analysis for
user level tools that can tell states of registers etc. Removing ioctls all
together will make any analys
On 12/6/06, Dan Williams <[EMAIL PROTECTED]> wrote:
On Wed, 2006-12-06 at 09:37 -0500, Dmitry Torokhov wrote:
>
> Fans of the 3rd method, speak up ;)
I think I brought up the 3rd method initially in this thread. I'm not
necessarily advocating it, but I wanted to be sure people realized that
thi
On Wed, 2006-12-06 at 09:37 -0500, Dmitry Torokhov wrote:
> On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> > > I am still not sure that tight coupling of input device with rfkill
> > > structure is such a good idea. Quite often the button is separated
> > > from the device itself and radio
On 12/4/06, Ivo van Doorn <[EMAIL PROTECTED]> wrote:
> I am still not sure that tight coupling of input device with rfkill
> structure is such a good idea. Quite often the button is separated
> from the device itself and radio control is done via BIOS SMM (see
> wistron driver) or there is no spe
From: Ulrich Kunitz <[EMAIL PROTECTED]>
A deauthentication from the AP doesn't start a reassociation by
SoftMAC. To fix this mac->associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled.
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Lar
* Jakub Jelinek <[EMAIL PROTECTED]> 2006-12-06 15:18
> There are the kernel's own headers and kernel ABI headers for userland use.
> Until recently the latter has been maintained by various distributions
> and manually occassionally updated to sync a little bit with kernel ABI
> additions (new sysc
1 - 100 of 116 matches
Mail list logo
