Re: [PATCH] drivers/net: spidernet driver on Celleb
I got a note from Jens earlier today that mentioned some changes he has made to the PHY code. He plans to get those in soon, so this might be solved already. Jim Lewis On Wed, 2006-12-13 at 14:54 +1100, Benjamin Herrenschmidt wrote: > On Tue, 2006-12-12 at 19:14 -0600, Linas Vepstas wrote: > > On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote: > > > > > > Following are the changes. > > > -This patch enables auto-negotiation. > > > -Loading firmware is done when spidernet_open() is called. > > > -And this patch adds other several small changes for Celleb. > > > -This patch is not tested on CellBlade. > > > > I just tested this, and it does not work. Jim Lewis is gone > > until the new year. However, as he was leaving, he grumbled something > > about how autonegotiation simply won't work on the spider. > > (I didn't think to ask about the details). Perhaps he'll > > look at his email soon? > > Duh ? Autoneg is completely local to the PHY. It will not work on the > Cell blade because it's using a fiber link though, thus we probably need > to disable this code when running on a fiber link. > > > I've been trying to figure out how to modify the patch to make it > > work anyway, but so far, no success. > > > > Basically, in genmii_poll_link(), > > status = phy_read(phy, MII_BMSR); > > status & BMSR_LSTATUS will always be zero. > > > > So I tried ignoring this value, and calling setup_forced() > > However, this still doesn't get the thing working. > > I am somewhat at a loss to see why right now, since > > I don't see what may be causing this. > > I can have a look, most of the code was borrowed from sungem and I wrote > the MII code for it :-) > > Ben. > - 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
Re: examples of setting ip address/netmask/etc.. on a device
Kumar Gala <[EMAIL PROTECTED]> wrote:
> I was wondering if there were any examples of net devices that expect
> to be told the ip information for their connection (things doing
> forms of offload). If so can someone point me at a driver that does
> this.
Try drivers/s390/net/qeth_main.c. Of course, it's best to avoid this
if at all possible.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
Re: [patch sungem] improved locking
On Tue, 2006-12-12 at 20:03 -0800, David Miller wrote: > From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Date: Wed, 13 Dec 2006 14:12:13 +1100 > > > David, could that be the pause stuff not working properly ? > > It could be, but if the tg3 says flow control is up in the kernel logs > things ought to be OK. tg3 says tg3: eth0: Link is up at 1000 Mbps, full duplex. tg3: eth0: Flow control is on for TX and on for RX. but sungem says eth0: Link is up at 1000 Mbps, full-duplex. eth0: Pause is disabled Hrm... I suppose I need to dig more. No time to do that today though. Ben. - 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
Re: [patch sungem] improved locking
Been hitting a raw throughput in both directions plus a few other things on a dual G5 and the driver didn't crash :-) I'm seeing a problem though but I'm not sure it's related to your patch, I'll have to test without it. Basically, if I use a slightly modified versio of tridge's socklib (raw xput test, basically, a tcp connection with one side pushing as fast as it can a known pattern and the other one just receiving and verifying the data integrity), it works fine when running only one side (either rx or tx, doesn't matter). But if I start it both ways (that is both a receiver and a sender on the GMAC box) and the other end is a tg3 (quad g5), then I'm getting a lot of eth0: RX MAC fifo overflow smac[02045822 but there are other numbers here every now and then] errors on the sungem side. David, could that be the pause stuff not working properly ? The link is gigabit and the tg3 side doesn't complain about anything. Ben. - 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
Re: [patch sungem] improved locking
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Wed, 13 Dec 2006 14:12:13 +1100 > David, could that be the pause stuff not working properly ? It could be, but if the tg3 says flow control is up in the kernel logs things ought to be OK. - 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
Re: [PATCH] drivers/net: spidernet driver on Celleb
On Tue, 2006-12-12 at 19:14 -0600, Linas Vepstas wrote: > On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote: > > > > Following are the changes. > > -This patch enables auto-negotiation. > > -Loading firmware is done when spidernet_open() is called. > > -And this patch adds other several small changes for Celleb. > > -This patch is not tested on CellBlade. > > I just tested this, and it does not work. Jim Lewis is gone > until the new year. However, as he was leaving, he grumbled something > about how autonegotiation simply won't work on the spider. > (I didn't think to ask about the details). Perhaps he'll > look at his email soon? Duh ? Autoneg is completely local to the PHY. It will not work on the Cell blade because it's using a fiber link though, thus we probably need to disable this code when running on a fiber link. > I've been trying to figure out how to modify the patch to make it > work anyway, but so far, no success. > > Basically, in genmii_poll_link(), > status = phy_read(phy, MII_BMSR); > status & BMSR_LSTATUS will always be zero. > > So I tried ignoring this value, and calling setup_forced() > However, this still doesn't get the thing working. > I am somewhat at a loss to see why right now, since > I don't see what may be causing this. I can have a look, most of the code was borrowed from sungem and I wrote the MII code for it :-) Ben. - 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
Re: [patch sungem] improved locking
On Wed, 2006-12-13 at 14:12 +1100, Benjamin Herrenschmidt wrote: > Been hitting a raw throughput in both directions plus a few other things > on a dual G5 and the driver didn't crash :-) > > I'm seeing a problem though but I'm not sure it's related to your patch, > I'll have to test without it. > > Basically, if I use a slightly modified versio of tridge's socklib (raw > xput test, basically, a tcp connection with one side pushing as fast as > it can a known pattern and the other one just receiving and verifying > the data integrity), it works fine when running only one side (either rx > or tx, doesn't matter). > > But if I start it both ways (that is both a receiver and a sender on the > GMAC box) and the other end is a tg3 (quad g5), then I'm getting a lot > of eth0: RX MAC fifo overflow smac[02045822 but there are other numbers > here every now and then] errors on the sungem side. > > David, could that be the pause stuff not working properly ? > > The link is gigabit and the tg3 side doesn't complain about anything. I've verified that the problem isn't related to Eric's patch and is there without it... I suppose I just never noticed it before :-) So far, the patch looks solid. I'll let it run overnight and will holler if things went wrong tomorrow. Cheers, Ben. - 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
Re: d80211-drivers pull request (week-48)
On Tuesday 12 December 2006 18:39, Ulrich Kunitz wrote: > Just two observations: > > 1) The retry-failed-interrupt message contains the destination >MAC address of the transmitted message. Hm, that might be useful to check in master or adhoc mode to make sure the tx queue isn't messed up. > 2) We could get easily two acks for the same transmission. How would this occur? > 3) We could get ACKs or retry-failed-interrupts for packets, for >which no status has been requested by the upper layers. > We report status for every frame which will get an ACK, which is every unicast frame. Coincidentally, d80211 uses the same logic to determine when it wants the status to be reported (IIRC). > I suggest that the skbs as buffer for the URB transmissions. Yes, copying the entire frame to another buffer isn't very performance friendly. This was one of the things that bothered me when I ported zd1211rw. > We could add a timeout value to each > packet to make sure, that we don't ACK or NAK packets, which have > been overdue. Some sort of watchdog to kick things when things stall could be useful, though I'm not sure how to go about it. -Michael Wu pgpHi8ZnfpgQg.pgp Description: PGP signature
Re: [Bugme-new] [Bug 7665] New: getsockopt(IPV6_*CAST_HOPS) returns -1
From: Brian Haley <[EMAIL PROTECTED]> Date: Tue, 12 Dec 2006 16:16:27 -0500 > The following patch seems to work for me, but this code has behaved this > way for a while, so don't know if it will break any existing apps. > > Signed-off-by: Brian Haley <[EMAIL PROTECTED]> I like this patch so I have applied it, thanks Brian. I'll push it to -stable too. I wonder, since the most accurate return value is tied to the route, what is expected of this getsockopt() before a socket's identity (and therefore route) is known? I suppose returning the default value, which Brian's patch does, is a reasonable best-effort. - 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
Re: kernel panic with the newly merged md5 signature support
From: "Leigh Brown" <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 23:03:34 - (GMT)
> Well, the inline functions seem okay in that regard, but I'll bow to
> your superior judgement.
I think we're still not onto the right fix.
I took a look, and the issue seems to simply be that the
__tcp_put_md5sig_pool() is not doing the reference count
thing that __tcp_get_md5sig_pool() does (via tcp_md5sig_users).
The direct call to __tcp_free_md5sig_pool() seems to be
what causes this problem, we should be invoking
tcp_free_md5sig_pool() instead.
Can you give this patch a try? Thanks.
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 090c690..4c57019 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2364,8 +2364,9 @@ struct tcp_md5sig_pool *__tcp_get_md5sig
EXPORT_SYMBOL(__tcp_get_md5sig_pool);
-void __tcp_put_md5sig_pool(void) {
- __tcp_free_md5sig_pool(tcp_md5sig_pool);
+void __tcp_put_md5sig_pool(void)
+{
+ tcp_free_md5sig_pool(tcp_md5sig_pool);
}
EXPORT_SYMBOL(__tcp_put_md5sig_pool);
-
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
Re: [2.6 patch] drivers/net/loopback.c: convert to module_init()
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Tue, 12 Dec 2006 17:24:35 +0100 > This patch converts drivers/net/loopback.c to using module_init(). > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> I'm not %100 sure of this one, let's look at the comment you are deleting: > -/* > - * The loopback device is global so it can be directly referenced > - * by the network code. Also, it must be first on device list. > - */ > -extern int loopback_init(void); > - in particular notice the part that says "it must be first on the device list". I'm not sure whether that is important any longer. It probably isn't, but we should verify it before applying such a patch. Since module_init() effectively == device_initcall() for statically built objects, which loopback always is, the Makefile ordering does not seem to indicate to me that there is anything guarenteeing this "first on the list" invariant. At least not via object file ordering. So this gives some support to the idea that loopback_dev's position on the device list no longer matters. - 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
Re: [PATCH] drivers/net: spidernet driver on Celleb
On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote: > > Following are the changes. > -This patch enables auto-negotiation. > -Loading firmware is done when spidernet_open() is called. > -And this patch adds other several small changes for Celleb. > -This patch is not tested on CellBlade. I just tested this, and it does not work. Jim Lewis is gone until the new year. However, as he was leaving, he grumbled something about how autonegotiation simply won't work on the spider. (I didn't think to ask about the details). Perhaps he'll look at his email soon? I've been trying to figure out how to modify the patch to make it work anyway, but so far, no success. Basically, in genmii_poll_link(), status = phy_read(phy, MII_BMSR); status & BMSR_LSTATUS will always be zero. So I tried ignoring this value, and calling setup_forced() However, this still doesn't get the thing working. I am somewhat at a loss to see why right now, since I don't see what may be causing this. --linas - 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
Re: d80211-drivers pull request (week-48)
On 06-12-11 21:20 Michael Wu wrote: > On Monday 11 December 2006 20:07, Daniel Drake wrote: > > Michael Wu wrote: > > > zd1211rw-d80211: Use ieee80211_tx_status > > > > I've thought some more about this and I'm not so sure that this is the > > right approach. > > > > Can't devicescape be taught that the ZD1211 handles retries in hardware > > and the stack doesn't need to worry about it? > > > All 802.11 devices have to be able to handle retries in hardware to do random > backoff properly. Still, the stack wants to know what happened. > > > I think I remember reading that devicescape uses failed transmission > > rate in the rate adjustment calculations. Even without this racy ack > > system we can still achieve that - the device tells us every time it > > retries a transmit, and then it sends a special interrupt at the end > > saying that all retries failed. > > > Yes, but it also uses successful transmissions in rate adjustment. > > I don't think this race is such a big deal. It will only happen when someone > is really trying to mess with the link, and would cause the rate control to > jump to the highest speed. However, if someone is really trying to mess with > the link this way, the stability of the link is in trouble anyways. Wait for > stations to send frames, and send an ack for every unicast frame - everyone > will get confused. To actually mess with this code, the attacker would have > to transmit acks nearly continuously as it can't tell exactly when is a good > time to screw things up, and the driver recovers as soon as the queue is > emptied. Someone transmitting all the time is a problem for all wireless > cards. :) Just two observations: 1) The retry-failed-interrupt message contains the destination MAC address of the transmitted message. 2) We could get easily two acks for the same transmission. 3) We could get ACKs or retry-failed-interrupts for packets, for which no status has been requested by the upper layers. I suggest that the skbs as buffer for the URB transmissions. Check ACK/NAK for all packets, but still prepare the status only for packets, which requested it. We could add a timeout value to each packet to make sure, that we don't ACK or NAK packets, which have been overdue. -- Uli Kunitz - 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
Re: [PATCH] zd1211rw-d80211: Use LED class
On Tuesday 12 December 2006 17:38, Ulrich Kunitz wrote: > Micheal, how resetting an LED every second is overkill is beyond > me. I mean it is overkill in that is more than needed. > On a USB 2.0 port the available bandwidth is much higher than > on the air. Notify also that the LED is flip-flopped on tx packets > (which might include ACKs), so you simply don't know, when it > becomes dark. Ah, but if we transmit an ACK, we know because we receive a unicast frame. And then we can rearm the TX LED reset timer. Any other cases? > If nothing is transmitted the LED stays on, but if > something is transmitted you might have to guess. That's the > reason why I added the reset code. BTW the driver makes the LED > blinks in a certain sequence (1s on, 2s off) while scanning. It is > quite useful for debugging. You cannot do that without workqueues. > I don't think being able to flash pretty patterns while scanning is very convincing reason to keep this. ;) > > The upper layer does not know about the LEDs of individual devices. It > > merely provides a number of LED triggers which device drivers can choose > > to listen to - which sounds like what you're suggesting. > > No, this is not true. The upper layer has to support a Link-LED > trigger. I believe that event triggers are a generic concept and > should not be LED-specific. These triggers should inform about > LINK status changes and the driver has to know, whether it has a > LINK LED to switch or a LCD to display some information. There > might be also other uses than for switching LEDs. > Yes, userspace can do that by listening for the SIOCGIWAP wireless event. LED triggers allow this to be done easily by default with no userspace intervention. A link LED trigger would be added in addition to the usual wireless event. > > Switching to using LED class makes the housekeeping & workqueue code not > > do anything useful, so I removed it. I am not against the housekeeping & > > workqueue code - but right now this is dead code that will unnecessarily > > cause zd1211rw-d80211 not to compile when wireless-dev gets the workqueue > > api changes. (of course, d80211 doesn't compile either with the workqueue > > changes, but I'm working out a patch for that..) > > No, it is not dead code as I explained. Your patch is removing > functionality and if I undestand right, might work in the future. > But it is not tested and doesn't care for the activity > flip-flopping. > It has been tested to the point where I can manually control the state of the LED from userspace via sysfs. I had to switch to using LED_OFF (or rather, LED_DISABLED now) since the blinking behavior of LED_SCANNING made turning off the LED not guaranteed. Turning off the link LED thus forces the activity light off also, but that minor and can be easily fixed. The activity flip flopping can be fixed as I mentioned further above, and I do intend to make this all work (eg. link LED trigger) as I need p54 to support blinking its LEDs. Do you really mind breaking the LED blinking for now? How many users are going to be affected while things are being sorted out? If you really think the idea of LED classes and LED triggers is that incredibly bad, I will drop this patch and just fix the workqueues. However, as far as I can tell, it helps move policy out of the kernel while allowing the most common use case to continue to work without userspace intervention. -Michael Wu pgpMnRIEcF0wq.pgp Description: PGP signature
Re: kernel panic with the newly merged md5 signature support
On Tue, December 12, 2006 10:25 pm, David Miller said:
> From: "Leigh Brown" <[EMAIL PROTECTED]>
> Date: Tue, 12 Dec 2006 22:22:13 - (GMT)
>
>> I'm not sure what the correct way forward is. Could these functions
>> not be just:
>>
>> struct tcp_md5sig_pool *__tcp_get_md5sig_pool(int cpu)
>> {
>> struct tcp_md5sig_pool **p = tcp_md5_sig_pool;
>> BUG_ON(!p);
>> return *per_cpu_ptr(p, cpu);
>> }
>>
>> void __tcp_put_md5sig_pool(void) {
>> /* nuffin */
>> }
>>
>> In other words, can we assume that the pool is allocated when we call
>> tcp_get_md5sig_pool?
>
> I think the issue is that we need to get a balanced get_cpu()/put_cpu()
> in there somehow.
Well, the inline functions seem okay in that regard, but I'll bow to
your superior judgement.
static inline
struct tcp_md5sig_pool *tcp_get_md5sig_pool(void)
{
int cpu = get_cpu();
struct tcp_md5sig_pool *ret = __tcp_get_md5sig_pool(cpu);
if (!ret)
put_cpu();
return ret;
}
static inline void tcp_put_md5sig_pool(void)
{
__tcp_put_md5sig_pool();
put_cpu();
}
-
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
Re: [PATCH] zd1211rw-d80211: Use LED class
On 06-12-11 20:32 Michael Wu wrote: > On Monday 11 December 2006 17:55, Ulrich Kunitz wrote: > > I cannot accknowledge this patch. Michael, the LED does not only > > show the link status, but also indicate that packets are sent, > > which is done by the firmware. However the LED flags have to be > > reset every second, because if an odd number of packets have been > > transmitted, the LED stays dark. > The d80211 TX trigger has the same behavior. It's probably worse on single > LED > devices since it may look like nothing is on. Even then, I think having it > reset every second is overkill. Having an "TX LED" watchdog run when we > haven't TXed anything for the last second or sounds better to me. This would > force the LEDs to a reasonable state when we know nothing has been TXed > recently. This could be for STA mode only.. I dunno if the LED blinks when > sending hardware generated/filled beacons. Micheal, how resetting an LED every second is overkill is beyond me. On a USB 2.0 port the available bandwidth is much higher than on the air. Notify also that the LED is flip-flopped on tx packets (which might include ACKs), so you simply don't know, when it becomes dark. If nothing is transmitted the LED stays on, but if something is transmitted you might have to guess. That's the reason why I added the reset code. BTW the driver makes the LED blinks in a certain sequence (1s on, 2s off) while scanning. It is quite useful for debugging. You cannot do that without workqueues. > The upper layer does not know about the LEDs of individual devices. It merely > provides a number of LED triggers which device drivers can choose to listen > to - which sounds like what you're suggesting. No, this is not true. The upper layer has to support a Link-LED trigger. I believe that event triggers are a generic concept and should not be LED-specific. These triggers should inform about LINK status changes and the driver has to know, whether it has a LINK LED to switch or a LCD to display some information. There might be also other uses than for switching LEDs. > Switching to using LED class makes the housekeeping & workqueue code not do > anything useful, so I removed it. I am not against the housekeeping & > workqueue code - but right now this is dead code that will unnecessarily > cause zd1211rw-d80211 not to compile when wireless-dev gets the workqueue api > changes. (of course, d80211 doesn't compile either with the workqueue > changes, but I'm working out a patch for that..) No, it is not dead code as I explained. Your patch is removing functionality and if I undestand right, might work in the future. But it is not tested and doesn't care for the activity flip-flopping. Regards, Uli -- Uli Kunitz - 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
Re: Fw: [Bugme-new] [Bug 7665] New: getsockopt(IPV6_*CAST_HOPS) returns -1
Le mardi 12 décembre 2006 22:16, vous avez écrit : > > I don't reckon -1 could be the hop limit value. > > -1 means un-initialized. Sure, -1 means "kernel default" for setsockopt(), but it is not specified for getsockopt(). > The following patch seems to work for me, but this code has behaved > this way for a while, so don't know if it will break any existing > apps. Google Codesearch for "getsockopt IPV6_MULTICAST_HOPS" yields a bunch of apps that seem to assume a valid hop limit is returned, none of which detects -1. I believe applying your patch would fix much more apps than it is going to break. Hopefully those not handling -1 will somehow cast it to 255 if it is ever re-used, but I can also imagine some broken SDP-or-similar with "/-1" or "/4294967295" as a hop limit. Thanks, -- Rémi Denis-Courmont - 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
Re: kernel panic with the newly merged md5 signature support
From: "Leigh Brown" <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 22:22:13 - (GMT)
> I'm not sure what the correct way forward is. Could these functions
> not be just:
>
> struct tcp_md5sig_pool *__tcp_get_md5sig_pool(int cpu)
> {
> struct tcp_md5sig_pool **p = tcp_md5_sig_pool;
> BUG_ON(!p);
> return *per_cpu_ptr(p, cpu);
> }
>
> void __tcp_put_md5sig_pool(void) {
> /* nuffin */
> }
>
> In other words, can we assume that the pool is allocated when we call
> tcp_get_md5sig_pool?
I think the issue is that we need to get a balanced get_cpu()/put_cpu()
in there somehow.
I'll take a look at this later today, thanks for pointing it out.
-
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
Re: kernel panic with the newly merged md5 signature support
On Mon, December 11, 2006 9:38 pm, I said:
> I decided to try out the md5 signature support, with a view to eventually
> fixing up Quagga to make use of it. As the API has changed quite a bit,
> I modified a simple echo client/server as a simple test. I compiled
> up 2.6.19-git17 and ran it under debian etch.
>
> Unfortunately, both the client and server machines panic (actually I'm
> using qemu to make things easy for myself). Although my test programs
> might be buggy, I don't believe they should cause a panic.
>
> Has anyone got this stuff working yet?
This seems bogus to me :-
struct tcp_md5sig_pool *__tcp_get_md5sig_pool(int cpu)
{
struct tcp_md5sig_pool **p;
spin_lock(&tcp_md5sig_pool_lock);
p = tcp_md5sig_pool;
if (p)
tcp_md5sig_users++;
spin_unlock(&tcp_md5sig_pool_lock);
return (p ? *per_cpu_ptr(p, cpu) : NULL);
}
void __tcp_put_md5sig_pool(void) {
__tcp_free_md5sig_pool(tcp_md5sig_pool);
}
Certainly commenting out the body of __tcp_put_md5sig_pool gets things
working.
I'm not sure what the correct way forward is. Could these functions
not be just:
struct tcp_md5sig_pool *__tcp_get_md5sig_pool(int cpu)
{
struct tcp_md5sig_pool **p = tcp_md5_sig_pool;
BUG_ON(!p);
return *per_cpu_ptr(p, cpu);
}
void __tcp_put_md5sig_pool(void) {
/* nuffin */
}
In other words, can we assume that the pool is allocated when we call
tcp_get_md5sig_pool?
Thanks,
Leigh.
-
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
Re: examples of setting ip address/netmask/etc.. on a device
> I was wondering if there were any examples of net devices that expect > to be told the ip information for their connection (things doing > forms of offload). If so can someone point me at a driver that does > this. I don't know much about the HW details but drivers/infiniband/hw/amso1100 does something like that. drivers/infiniband is somewhat misnamed these days but amso1100 is a driver for RDMA over ethernet hardware. - 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
Re: Fw: [Bugme-new] [Bug 7665] New: getsockopt(IPV6_*CAST_HOPS) returns -1
Where fd is a socket (datagram or raw) with IPv6 protocol family,
getsockopt(fd, IPPROTO_IPV6, IPV6_UNICAST_HOPS, ...) succeeds, but
the returned hop limit is -1. connect()'ing the socket first does
not solve the problem.
An IPv6 socket's hoplimit value is not set at creation time, instead,
the hoplimit in an outgoing packet is set dynamically at transmit
time to one of the following (in this order):
1. Hoplimit route metric (if set)
2. Outgoing interface value (/proc/sys/net/ipv6/conf/ethX/hop_limit)
3. Global IPv6 value (/proc/sys/net/ipv6/conf/all/hop_limit)
A setsockopt() value *will* override this.
Relevant standard (RFC 3493) notes:
The IPV6_UNICAST_HOPS option may be used with getsockopt() to
determine the hop limit value that the system will use for subsequent
unicast packets sent via that socket.
I don't reckon -1 could be the hop limit value.
-1 means un-initialized.
IMHO, the value from
case 1 (if socket is connected to some destination), otherwise case 2
(if bound to a scope interface) or ultimately the default hop limit
ought to be returned instead, as it will be most often correct, while
the current behavior is always wrong, unless setsockopt() has been used
first. I don't if some people may think doing a route lookup in
getsockopt might be overly expensive, but at least the two other cases
should be ok, particularly the last one.
The following patch seems to work for me, but this code has behaved this
way for a while, so don't know if it will break any existing apps.
-Brian
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 1eafcfc..352690e 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -978,12 +978,27 @@ static int do_ipv6_getsockopt(struct soc
break;
case IPV6_UNICAST_HOPS:
- val = np->hop_limit;
- break;
-
case IPV6_MULTICAST_HOPS:
- val = np->mcast_hops;
+ {
+ struct dst_entry *dst;
+
+ if (optname == IPV6_UNICAST_HOPS)
+ val = np->hop_limit;
+ else
+ val = np->mcast_hops;
+
+ dst = sk_dst_get(sk);
+ if (dst) {
+ if (val < 0)
+val = dst_metric(dst, RTAX_HOPLIMIT);
+ if (val < 0)
+val = ipv6_get_hoplimit(dst->dev);
+ dst_release(dst);
+ }
+ if (val < 0)
+ val = ipv6_devconf.hop_limit;
break;
+ }
case IPV6_MULTICAST_LOOP:
val = np->mc_loop;
examples of setting ip address/netmask/etc.. on a device
I was wondering if there were any examples of net devices that expect to be told the ip information for their connection (things doing forms of offload). If so can someone point me at a driver that does this. - kumar - 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
wake on LAN with sky2
Hi folks, I just tried the sk98lin driver version 8.41.2.3 and was happy that it seems to support wake on LAN with the Marvell 88E8053 PCIe chip. However, after resume from suspend to RAM, the machine hangs. As it doesn't hang with sky2, it looks like this particular driver breaks suspend to RAM. ($%&?#!!!) A quick look into sk98lin_suspend() shows that there is not much stuff in there. Am I right that I just have to port that stuff to sky2? The affected file skge.c is licenced under the GPL v2 or later. Regards, Tino - 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
[PATCH 2.6.19.1] prism54: add ethtool -i interface
Add support for "ethtool -i" to prism54 driver.
ethtool -i queries the specified device for
associated driver information.
This helps tools like Fedora's system-config-network to
provide GUI management of network devices.
I learned how to write this patch by reading the ipw2100
driver code.
Signed-off-by: Kai Engert <[EMAIL PROTECTED]>
--- linux-2.6.19.1/drivers/net/wireless/prism54/islpci_dev.h.preke
2006-12-11 20:32:53.0 +0100
+++ linux-2.6.19.1/drivers/net/wireless/prism54/islpci_dev.h2006-12-12
20:33:09.0 +0100
@@ -212,4 +212,8 @@
int islpci_free_memory(islpci_private *);
struct net_device *islpci_setup(struct pci_dev *);
+
+#define DRV_NAME "prism54"
+#define DRV_VERSION"1.2"
+
#endif /* _ISLPCI_DEV_H */
--- linux-2.6.19.1/drivers/net/wireless/prism54/islpci_dev.c.preke
2006-12-11 20:32:53.0 +0100
+++ linux-2.6.19.1/drivers/net/wireless/prism54/islpci_dev.c2006-12-12
20:33:09.0 +0100
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -788,6 +789,17 @@
}
#endif
+static void islpci_ethtool_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *info)
+{
+ strcpy(info->driver, DRV_NAME);
+ strcpy(info->version, DRV_VERSION);
+}
+
+static struct ethtool_ops islpci_ethtool_ops = {
+ .get_drvinfo = islpci_ethtool_get_drvinfo,
+};
+
struct net_device *
islpci_setup(struct pci_dev *pdev)
{
@@ -814,6 +826,7 @@
ndev->do_ioctl = &prism54_ioctl;
ndev->wireless_handlers =
(struct iw_handler_def *) &prism54_handler_def;
+ ndev->ethtool_ops = &islpci_ethtool_ops;
ndev->hard_start_xmit = &islpci_eth_transmit;
/* ndev->set_multicast_list = &islpci_set_multicast_list; */
--- linux-2.6.19.1/drivers/net/wireless/prism54/islpci_hotplug.c.preke
2006-12-11 20:32:53.0 +0100
+++ linux-2.6.19.1/drivers/net/wireless/prism54/islpci_hotplug.c
2006-12-12 20:33:09.0 +0100
@@ -29,9 +29,6 @@
#include "islpci_mgt.h" /* for pc_debug */
#include "isl_oid.h"
-#define DRV_NAME "prism54"
-#define DRV_VERSION"1.2"
-
MODULE_AUTHOR("[Intersil] R.Bastings and W.Termorshuizen, The prism54.org Development Team
<[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("The Prism54 802.11 Wireless LAN adapter");
MODULE_LICENSE("GPL");
-
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
Re: ieee80211 sleeping in invalid context
Ray Lee wrote: Michael Buesch wrote: Congratulations to your decision ;) Sometimes making decisions via Brownian motion has its advantages. Which kernel are you using? Hmm, I'm using the mercurial repository, let me see if I can translate that to a git head... Looks like git tree c2bb88baa52429b6b76e3ba4272cb2b29713c5a8 . (Which is from less than 24 hours ago.) There is some locking breakage in latest kernels with softmac. I attached the fixes for the known bugs. Okay, I'll apply to my local copy, rebuild, and try again. I'll let you know what happens. Please note that the 3rd hunk of the second patch that Michael sent is already in Linus's 2.6.19-gitXX tree. You may get that part rejected by patch. Larry - 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
Re: [PATCH 2.6.19] e100: replace kmalloc with kcalloc
Yan Burman wrote:
Replace kmalloc+memset with kcalloc
ACK, fine with me.
Signed-off-by: Yan Burman <[EMAIL PROTECTED]>
diff -rubp linux-2.6.19-rc5_orig/drivers/net/e100.c
linux-2.6.19-rc5_kzalloc/drivers/net/e100.c
--- linux-2.6.19-rc5_orig/drivers/net/e100.c2006-11-09 12:16:21.0
+0200
+++ linux-2.6.19-rc5_kzalloc/drivers/net/e100.c 2006-11-11 22:44:04.0
+0200
@@ -1930,9 +1930,8 @@ static int e100_rx_alloc_list(struct nic
nic->rx_to_use = nic->rx_to_clean = NULL;
nic->ru_running = RU_UNINITIALIZED;
- if(!(nic->rxs = kmalloc(sizeof(struct rx) * count, GFP_ATOMIC)))
+ if(!(nic->rxs = kcalloc(count, sizeof(struct rx), GFP_ATOMIC)))
return -ENOMEM;
- memset(nic->rxs, 0, sizeof(struct rx) * count);
for(rx = nic->rxs, i = 0; i < count; rx++, i++) {
rx->next = (i + 1 < count) ? rx + 1 : nic->rxs;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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
[PATCH 3/3] d80211: fix workqueue breakage
d80211: fix workqueue breakage
This patch updates d80211 to use the new workqueue API.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c |7 ---
net/d80211/ieee80211_i.h |8 +---
net/d80211/ieee80211_iface.c |2 +-
net/d80211/ieee80211_sta.c | 26 ++
net/d80211/sta_info.c|7 ---
5 files changed, 28 insertions(+), 22 deletions(-)
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 6e10db5..76ee491 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -2092,13 +2092,13 @@ void ieee80211_if_shutdown(struct net_de
case IEEE80211_IF_TYPE_IBSS:
sdata->u.sta.state = IEEE80211_DISABLED;
cancel_delayed_work(&sdata->u.sta.work);
- if (local->scan_work.data == sdata->dev) {
+ if (local->scan_dev == sdata->dev) {
local->sta_scanning = 0;
cancel_delayed_work(&local->scan_work);
flush_scheduled_work();
/* see comment in ieee80211_unregister_hw to
* understand why this works */
- local->scan_work.data = NULL;
+ local->scan_dev = NULL;
} else
flush_scheduled_work();
break;
@@ -4486,6 +4486,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(
INIT_LIST_HEAD(&local->sub_if_list);
spin_lock_init(&local->generic_lock);
+ INIT_DELAYED_WORK(&local->scan_work, ieee80211_sta_scan_work);
init_timer(&local->stat_timer);
local->stat_timer.function = ieee80211_stat_refresh;
local->stat_timer.data = (unsigned long) local;
@@ -4686,7 +4687,7 @@ void ieee80211_unregister_hw(struct ieee
if (local->stat_time)
del_timer_sync(&local->stat_timer);
- if (local->scan_work.data) {
+ if (local->scan_dev) {
local->sta_scanning = 0;
cancel_delayed_work(&local->scan_work);
flush_scheduled_work();
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..b7b4b35 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -240,7 +240,7 @@ struct ieee80211_if_sta {
IEEE80211_ASSOCIATE, IEEE80211_ASSOCIATED,
IEEE80211_IBSS_SEARCH, IEEE80211_IBSS_JOINED
} state;
- struct work_struct work;
+ struct delayed_work work;
u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
u8 ssid[IEEE80211_MAX_SSID_LEN];
size_t ssid_len;
@@ -429,7 +429,8 @@ struct ieee80211_local {
int scan_channel_idx;
enum { SCAN_SET_CHANNEL, SCAN_SEND_PROBE } scan_state;
unsigned long last_scan_completed;
- struct work_struct scan_work;
+ struct delayed_work scan_work;
+ struct net_device *scan_dev;
int scan_oper_channel;
int scan_oper_channel_val;
int scan_oper_power_level;
@@ -638,7 +639,8 @@ int ieee80211_set_compression(struct iee
struct net_device *dev, struct sta_info *sta);
int ieee80211_init_client(struct net_device *dev);
/* ieee80211_sta.c */
-void ieee80211_sta_work(void *ptr);
+void ieee80211_sta_work(struct work_struct *work);
+void ieee80211_sta_scan_work(struct work_struct *work);
void ieee80211_sta_rx_mgmt(struct net_device *dev, struct sk_buff *skb,
struct ieee80211_rx_status *rx_status);
int ieee80211_sta_set_ssid(struct net_device *dev, char *ssid, size_t len);
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index 3e9d531..288dce5 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -185,7 +185,7 @@ void ieee80211_if_set_type(struct net_de
struct ieee80211_if_sta *ifsta;
ifsta = &sdata->u.sta;
- INIT_WORK(&ifsta->work, ieee80211_sta_work, dev);
+ INIT_DELAYED_WORK(&ifsta->work, ieee80211_sta_work);
ifsta->capab = WLAN_CAPABILITY_ESS;
ifsta->auth_algs = IEEE80211_AUTH_ALG_OPEN |
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 04bd5cd..35eb5a2 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -1837,10 +1837,11 @@ static void ieee80211_sta_merge_ibss(str
}
-void ieee80211_sta_work(void *ptr)
+void ieee80211_sta_work(struct work_struct *work)
{
- struct net_device *dev = ptr;
- struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_sub_if_data *sdata =
+ container_of(work, struct ieee80211_sub_if_data,
u.sta.work.work);
+ struct net_device *dev = sdata->dev;
struct ieee80211_if_sta *ifsta;
if (!netif_running(dev))
@@ -2407,7 +2408,7 @@ static int ieee80211_active_scan(struct
void ieee80211_scan_completed(struct ieee80211_hw *hw)
{
struct ieee80
[PATCH 0/3] Fix breakage in d80211
Hi, I've made some patches to make d80211 compile with recent changes in Linus' tree. They've only been compile tested since I haven't bothered to fix merge conflicts (or rather, haven't figured out how to) and make everything compile, but I don't see much of a reason why it shouldn't work. Hope you find this useful. -Michael Wu pgptTNY09pbnm.pgp Description: PGP signature
[PATCH 1/3] d80211: fix wep.c breakage
d80211: fix wep.c breakage This patch fixes wep.c, which was broken by Al Viro's severing skbuff.h -> mm.h patch. Signed-off-by: Michael Wu <[EMAIL PROTECTED]> --- net/d80211/wep.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/d80211/wep.c b/net/d80211/wep.c index dee8eae..6a96ade 100644 --- a/net/d80211/wep.c +++ b/net/d80211/wep.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include pgpwt3FSYiljx.pgp Description: PGP signature
[PATCH 2/3] d80211: fix wme.c breakage
d80211: fix wme.c breakage
This fixes wme.c, which was broken by a recent qdisc api change.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
---
net/d80211/wme.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/d80211/wme.c b/net/d80211/wme.c
index b9505dc..bffdce9 100644
--- a/net/d80211/wme.c
+++ b/net/d80211/wme.c
@@ -432,7 +432,8 @@ static int wme_qdiscop_init(struct Qdisc
/* create child queues */
for (i = 0; i < queues; i++) {
skb_queue_head_init(&q->requeued[i]);
- q->queues[i] = qdisc_create_dflt(qd->dev, &CHILD_QDISC_OPS);
+ q->queues[i] = qdisc_create_dflt(qd->dev, &CHILD_QDISC_OPS,
+qd->handle);
if (q->queues[i] == 0) {
q->queues[i] = &noop_qdisc;
printk(KERN_ERR "%s child qdisc %i creation failed",
dev->name, i);
@@ -658,7 +659,7 @@ void ieee80211_install_qdisc(struct net_
{
struct Qdisc *qdisc;
- qdisc = qdisc_create_dflt(dev, &wme_qdisc_ops);
+ qdisc = qdisc_create_dflt(dev, &wme_qdisc_ops, TC_H_ROOT);
if (!qdisc) {
printk(KERN_ERR "%s: qdisc installation failed\n", dev->name);
return;
pgppL7NfGAwkQ.pgp
Description: PGP signature
Re: ieee80211 sleeping in invalid context
Michael Buesch wrote: > Congratulations to your decision ;) Sometimes making decisions via Brownian motion has its advantages. > Which kernel are you using? Hmm, I'm using the mercurial repository, let me see if I can translate that to a git head... Looks like git tree c2bb88baa52429b6b76e3ba4272cb2b29713c5a8 . (Which is from less than 24 hours ago.) > There is some locking breakage in latest kernels with softmac. > I attached the fixes for the known bugs. Okay, I'll apply to my local copy, rebuild, and try again. I'll let you know what happens. Ray - 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
[2.6 patch] bonding.h: "extern inline" -> "static inline"
"extern inline" generates a warning with -Wmissing-prototypes and I'm
currently working on getting the kernel cleaned up for adding this to
the CFLAGS since it will help us to avoid a nasty class of runtime
errors.
If there are places that really need a forced inline, __always_inline
would be the correct solution.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/bonding/bonding.h |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.19-mm1/drivers/net/bonding/bonding.h.old 2006-12-12
15:57:43.0 +0100
+++ linux-2.6.19-mm1/drivers/net/bonding/bonding.h 2006-12-12
15:58:17.0 +0100
@@ -237,12 +237,13 @@
#define BOND_ARP_VALIDATE_ALL (BOND_ARP_VALIDATE_ACTIVE | \
BOND_ARP_VALIDATE_BACKUP)
-extern inline int slave_do_arp_validate(struct bonding *bond, struct slave
*slave)
+static inline int slave_do_arp_validate(struct bonding *bond,
+ struct slave *slave)
{
return bond->params.arp_validate & (1 << slave->state);
}
-extern inline u32 slave_last_rx(struct bonding *bond, struct slave *slave)
+static inline u32 slave_last_rx(struct bonding *bond, struct slave *slave)
{
if (slave_do_arp_validate(bond, slave))
return slave->last_arp_rx;
-
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
[2.6 patch] net/wanrouter/wanmain.c: cleanups
This patch contains the following cleanups:
- make the following needlessly global functions static:
- lock_adapter_irq()
- unlock_adapter_irq()
- #if 0 the following unused global functions:
- wanrouter_encapsulate()
- wanrouter_type_trans()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 30 Jun 2006
- 5 Apr 2006
include/linux/wanrouter.h |8
net/wanrouter/wanmain.c | 17 -
2 files changed, 8 insertions(+), 17 deletions(-)
--- linux-2.6.17-rc1-mm1-full/include/linux/wanrouter.h.old 2006-04-05
17:03:07.0 +0200
+++ linux-2.6.17-rc1-mm1-full/include/linux/wanrouter.h 2006-04-05
17:15:20.0 +0200
@@ -516,9 +516,6 @@
/* Public functions available for device drivers */
extern int register_wan_device(struct wan_device *wandev);
extern int unregister_wan_device(char *name);
-__be16 wanrouter_type_trans(struct sk_buff *skb, struct net_device *dev);
-int wanrouter_encapsulate(struct sk_buff *skb, struct net_device *dev,
- unsigned short type);
/* Proc interface functions. These must not be called by the drivers! */
extern int wanrouter_proc_init(void);
@@ -527,11 +524,6 @@
extern int wanrouter_proc_delete(struct wan_device *wandev);
extern int wanrouter_ioctl( struct inode *inode, struct file *file, unsigned
int cmd, unsigned long arg);
-extern void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-extern void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-
-
-
/* Public Data */
/* list of registered devices */
extern struct wan_device *wanrouter_router_devlist;
--- linux-2.6.17-rc1-mm1-full/net/wanrouter/wanmain.c.old 2006-04-05
17:03:39.0 +0200
+++ linux-2.6.17-rc1-mm1-full/net/wanrouter/wanmain.c 2006-04-05
17:18:32.0 +0200
@@ -144,8 +144,8 @@
static struct wan_device *wanrouter_find_device(char *name);
static int wanrouter_delete_interface(struct wan_device *wandev, char *name);
-void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
+static void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
+static void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
@@ -162,8 +162,8 @@
* Organize Unique Identifiers for encapsulation/decapsulation
*/
-static unsigned char wanrouter_oui_ether[] = { 0x00, 0x00, 0x00 };
#if 0
+static unsigned char wanrouter_oui_ether[] = { 0x00, 0x00, 0x00 };
static unsigned char wanrouter_oui_802_2[] = { 0x00, 0x80, 0xC2 };
#endif
@@ -304,6 +304,8 @@
return 0;
}
+#if 0
+
/*
* Encapsulate packet.
*
@@ -399,6 +401,7 @@
return ethertype;
}
+#endif /* 0 */
/*
* WAN device IOCTL.
@@ -860,23 +863,19 @@
return 0;
}
-void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
+static void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
{
spin_lock_irqsave(lock, *smp_flags);
}
-void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
+static void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
{
spin_unlock_irqrestore(lock, *smp_flags);
}
EXPORT_SYMBOL(register_wan_device);
EXPORT_SYMBOL(unregister_wan_device);
-EXPORT_SYMBOL(wanrouter_encapsulate);
-EXPORT_SYMBOL(wanrouter_type_trans);
-EXPORT_SYMBOL(lock_adapter_irq);
-EXPORT_SYMBOL(unlock_adapter_irq);
MODULE_LICENSE("GPL");
-
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
[2.6 patch] drivers/net/loopback.c: convert to module_init()
This patch converts drivers/net/loopback.c to using module_init().
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/Space.c| 11 ---
drivers/net/loopback.c |4 +++-
2 files changed, 3 insertions(+), 12 deletions(-)
--- linux-2.6.19-mm1/drivers/net/loopback.c.old 2006-12-12 15:59:02.0
+0100
+++ linux-2.6.19-mm1/drivers/net/loopback.c 2006-12-12 16:02:11.0
+0100
@@ -229,9 +229,11 @@
};
/* Setup and register the loopback device. */
-int __init loopback_init(void)
+static int __init loopback_init(void)
{
return register_netdev(&loopback_dev);
};
+module_init(loopback_init);
+
EXPORT_SYMBOL(loopback_dev);
--- linux-2.6.19-mm1/drivers/net/Space.c.old2006-12-12 15:59:11.0
+0100
+++ linux-2.6.19-mm1/drivers/net/Space.c2006-12-12 16:01:35.0
+0100
@@ -345,22 +345,11 @@
#endif
-/*
- * The loopback device is global so it can be directly referenced
- * by the network code. Also, it must be first on device list.
- */
-extern int loopback_init(void);
-
/* Statically configured drivers -- order matters here. */
static int __init net_olddevs_init(void)
{
int num;
- if (loopback_init()) {
- printk(KERN_ERR "Network loopback device setup failed\n");
- }
-
-
#ifdef CONFIG_SBNI
for (num = 0; num < 8; ++num)
sbni_probe(num);
-
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
[2.6 patch] remove the broken SKMC driver
The SKMC driver has:
- already been marked as BROKEN in 2.6.0 three years ago and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still
present in the older kernel releases.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 25 Nov 2006
- 20 Nov 2006
drivers/net/Kconfig | 15
drivers/net/Makefile |1
drivers/net/Space.c |4
drivers/net/sk_mca.c | 1216 ---
drivers/net/sk_mca.h | 170 --
5 files changed, 1406 deletions(-)
--- linux-2.6.19-rc5-mm2/drivers/net/Kconfig.old2006-11-17
19:19:48.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/net/Kconfig2006-11-17 19:20:18.0
+0100
@@ -1144,21 +1115,6 @@
. The module
will be called seeq8005.
-config SKMC
- tristate "SKnet MCA support"
- depends on NET_ETHERNET && MCA && BROKEN
- ---help---
- These are Micro Channel Ethernet adapters. You need to say Y to "MCA
- support" in order to use this driver. Supported cards are the SKnet
- Junior MC2 and the SKnet MC2(+). The driver automatically
- distinguishes between the two cards. Note that using multiple boards
- of different type hasn't been tested with this driver. Say Y if you
- have one of these Ethernet adapters.
-
- To compile this driver as a module, choose M here and read
- . The module
- will be called sk_mca.
-
config NE2_MCA
tristate "NE/2 (ne2000 MCA version) support"
depends on NET_ETHERNET && MCA_LEGACY
--- linux-2.6.19-rc5-mm2/drivers/net/Makefile.old 2006-11-17
19:20:47.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/net/Makefile 2006-11-17 19:24:57.0
+0100
@@ -137,7 +137,6 @@
obj-$(CONFIG_EL1) += 3c501.o
obj-$(CONFIG_EL16) += 3c507.o
obj-$(CONFIG_ELMC) += 3c523.o
-obj-$(CONFIG_SKMC) += sk_mca.o
obj-$(CONFIG_IBMLANA) += ibmlana.o
obj-$(CONFIG_ELMC_II) += 3c527.o
obj-$(CONFIG_EL3) += 3c509.o
--- linux-2.6.19-rc5-mm2/drivers/net/Space.c.old2006-11-17
19:21:00.0 +0100
+++ linux-2.6.19-rc5-mm2/drivers/net/Space.c2006-11-17 19:25:06.0
+0100
@@ -59,7 +59,6 @@
extern struct net_device *arlan_probe(int unit);
extern struct net_device *el16_probe(int unit);
extern struct net_device *elmc_probe(int unit);
-extern struct net_device *skmca_probe(int unit);
extern struct net_device *elplus_probe(int unit);
extern struct net_device *ac3200_probe(int unit);
extern struct net_device *es_probe(int unit);
@@ -153,9 +149,6 @@
#ifdef CONFIG_ELMC_II /* 3c527 */
{mc32_probe, 0},
#endif
-#ifdef CONFIG_SKMC /* SKnet Microchannel */
-{skmca_probe, 0},
-#endif
{NULL, 0},
};
--- linux-2.6.19-rc5-mm2/drivers/net/sk_mca.h 2006-11-14 18:33:16.0
+0100
+++ /dev/null 2006-09-19 00:45:31.0 +0200
@@ -1,170 +0,0 @@
-#ifndef _SK_MCA_INCLUDE_
-#define _SK_MCA_INCLUDE_
-
-#ifdef _SK_MCA_DRIVER_
-
-/* Adapter ID's */
-#define SKNET_MCA_ID 0x6afd
-#define SKNET_JUNIOR_MCA_ID 0x6be9
-
-/* media enumeration - defined in a way that it fits onto the MC2+'s
- POS registers... */
-
-typedef enum { Media_10Base2, Media_10BaseT,
- Media_10Base5, Media_Unknown, Media_Count
-} skmca_medium;
-
-/* private structure */
-typedef struct {
- unsigned int slot; /* MCA-Slot-# */
- void __iomem *base;
- void __iomem *macbase; /* base address of MAC address PROM */
- void __iomem *ioregaddr;/* address of I/O-register (Lo) */
- void __iomem *ctrladdr; /* address of control/stat register */
- void __iomem *cmdaddr; /* address of I/O-command register */
- int nextrx; /* index of next RX descriptor to
- be read */
- int nexttxput; /* index of next free TX descriptor */
- int nexttxdone; /* index of next TX descriptor to
- be finished */
- int txbusy; /* # of busy TX descriptors */
- struct net_device_stats stat; /* packet statistics*/
- int realirq;/* memorizes actual IRQ, even when
- currently not allocated */
- skmca_medium medium;/* physical cannector */
- spinlock_t lock;
-} skmca_priv;
-
-/* card registers: control/status register bits */
-
-#define CTRL_ADR_DATA 0 /* Bit 0 = 0 ->access data register */
-#define CTRL_ADR_RAP 1 /* Bit 0 = 1 ->access RAP register */
-#define CTRL_RW_WRITE 0 /* Bit 1 = 0 ->write register*/
-#define CTRL_RW_READ 2 /* Bit 1 = 1 ->read register */
-#define CTRL_RESET_ON 0 /
Re: [patch] remove NETIF_F_TSO ifdefery
Jeff Garzik write: > Seems sane, though bnx2 and tg3 might want trivial modifications. I > dunno if DaveM and mchan want to keep BCM_TSO and TG3_SUPPORT_TSO > defines (you kept them, I prefer to kill them). > I agree with Jeff. Those can be killed. - 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
Re: [take26-resend1 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: On Mon, Dec 11, 2006 at 10:16:30AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote: Comments: * [oh, everybody will hate me for saying this, but...] to me, "kevent" implies an internal kernel subsystem. I would rather call it "uevent" or anything else lacking a 'k' prefix. It is kernel subsystem indeed, which exports some of its part to userspace. I previously thought that prefix 'k' can only be confused with KDE. It is a true statement to say "without the kevent subsystem, userspace lacks uevent handling". And let's be honest, the main consumers of this will be userspace apps, and a few in-kernel users pretending to be userspace apps (kernel threads). Jeff - 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
Re: [patch] remove NETIF_F_TSO ifdefery
Arjan van de Ven wrote: Hi, this patch removes the NETIF_F_TSO #ifdef-ery in drivers/net; this was for old-old-2.4 compat (even current 2.4 has NETIF_F_TSO) but it's time to get rid of it by now. Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> Seems sane, though bnx2 and tg3 might want trivial modifications. I dunno if DaveM and mchan want to keep BCM_TSO and TG3_SUPPORT_TSO defines (you kept them, I prefer to kill them). Jeff - 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
[patch] remove NETIF_F_TSO ifdefery
Hi,
this patch removes the NETIF_F_TSO #ifdef-ery in drivers/net; this was
for old-old-2.4 compat (even current 2.4 has NETIF_F_TSO)
but it's time to get rid of it by now.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/net/bnx2.c
===
--- linux-2.6.orig/drivers/net/bnx2.c
+++ linux-2.6/drivers/net/bnx2.c
@@ -39,12 +39,10 @@
#include
#define BCM_VLAN 1
#endif
-#ifdef NETIF_F_TSO
#include
#include
#include
#define BCM_TSO 1
-#endif
#include
#include
#include
@@ -1715,7 +1713,7 @@ bnx2_tx_int(struct bnx2 *bp)
tx_buf = &bp->tx_buf_ring[sw_ring_cons];
skb = tx_buf->skb;
-#ifdef BCM_TSO
+
/* partial BD completions possible with TSO packets */
if (skb_is_gso(skb)) {
u16 last_idx, last_ring_idx;
@@ -1731,7 +1729,7 @@ bnx2_tx_int(struct bnx2 *bp)
break;
}
}
-#endif
+
pci_unmap_single(bp->pdev, pci_unmap_addr(tx_buf, mapping),
skb_headlen(skb), PCI_DMA_TODEVICE);
@@ -4503,7 +4501,6 @@ bnx2_start_xmit(struct sk_buff *skb, str
vlan_tag_flags |=
(TX_BD_FLAGS_VLAN_TAG | (vlan_tx_tag_get(skb) << 16));
}
-#ifdef BCM_TSO
if ((mss = skb_shinfo(skb)->gso_size) &&
(skb->len > (bp->dev->mtu + ETH_HLEN))) {
u32 tcp_opt_len, ip_tcp_len;
@@ -4536,7 +4533,6 @@ bnx2_start_xmit(struct sk_buff *skb, str
}
}
else
-#endif
{
mss = 0;
}
@@ -5533,10 +5529,8 @@ static const struct ethtool_ops bnx2_eth
.set_tx_csum= ethtool_op_set_tx_csum,
.get_sg = ethtool_op_get_sg,
.set_sg = ethtool_op_set_sg,
-#ifdef BCM_TSO
.get_tso= ethtool_op_get_tso,
.set_tso= bnx2_set_tso,
-#endif
.self_test_count= bnx2_self_test_count,
.self_test = bnx2_self_test,
.get_strings= bnx2_get_strings,
@@ -6050,9 +6044,7 @@ bnx2_init_one(struct pci_dev *pdev, cons
#ifdef BCM_VLAN
dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
#endif
-#ifdef BCM_TSO
dev->features |= NETIF_F_TSO | NETIF_F_TSO_ECN;
-#endif
netif_carrier_off(bp->dev);
Index: linux-2.6/drivers/net/e1000/e1000.h
===
--- linux-2.6.orig/drivers/net/e1000/e1000.h
+++ linux-2.6/drivers/net/e1000/e1000.h
@@ -59,17 +59,13 @@
#include
#include
#include
-#ifdef NETIF_F_TSO6
#include
-#endif
#include
#include
#include
#include
#include
-#ifdef NETIF_F_TSO
#include
-#endif
#include
#include
#include
@@ -348,9 +344,7 @@ struct e1000_adapter {
boolean_t have_msi;
#endif
/* to not mess up cache alignment, always add to the bottom */
-#ifdef NETIF_F_TSO
boolean_t tso_force;
-#endif
boolean_t smart_power_down; /* phy smart power down */
boolean_t quad_port_a;
unsigned long flags;
Index: linux-2.6/drivers/net/e1000/e1000_ethtool.c
===
--- linux-2.6.orig/drivers/net/e1000/e1000_ethtool.c
+++ linux-2.6/drivers/net/e1000/e1000_ethtool.c
@@ -335,7 +335,6 @@ e1000_set_tx_csum(struct net_device *net
return 0;
}
-#ifdef NETIF_F_TSO
static int
e1000_set_tso(struct net_device *netdev, uint32_t data)
{
@@ -349,18 +348,15 @@ e1000_set_tso(struct net_device *netdev,
else
netdev->features &= ~NETIF_F_TSO;
-#ifdef NETIF_F_TSO6
if (data)
netdev->features |= NETIF_F_TSO6;
else
netdev->features &= ~NETIF_F_TSO6;
-#endif
DPRINTK(PROBE, INFO, "TSO is %s\n", data ? "Enabled" : "Disabled");
adapter->tso_force = TRUE;
return 0;
}
-#endif /* NETIF_F_TSO */
static uint32_t
e1000_get_msglevel(struct net_device *netdev)
@@ -1968,10 +1964,8 @@ static const struct ethtool_ops e1000_et
.set_tx_csum= e1000_set_tx_csum,
.get_sg = ethtool_op_get_sg,
.set_sg = ethtool_op_set_sg,
-#ifdef NETIF_F_TSO
.get_tso= ethtool_op_get_tso,
.set_tso= e1000_set_tso,
-#endif
.self_test_count= e1000_diag_test_count,
.self_test = e1000_diag_test,
.get_strings= e1000_get_strings,
Index: linux-2.6/drivers/net/e1000/e1000_main.c
===
--- linux-2.6.orig/drivers/net/e1000/e1000_main.c
+++ linux-2.6/drivers/net/e1000/e1000_main.c
@@ -852,16 +852,12 @@ e1000_probe(struct pci_dev *pdev,
netdev->features &= ~NETIF_F_HW_VLAN_FILTER;
Re: [PATCH] drivers/net: spidernet driver on Celleb
On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote:
>
> Following are the changes.
> -This patch enables auto-negotiation.
> -Loading firmware is done when spidernet_open() is called.
> -And this patch adds other several small changes for Celleb.
This should be split into three separate patches, sent as a patch
series.
> -/* outside loopback mode: ETOMOD signal dont matter, not connected */
> -#define SPIDER_NET_OPMODE_VALUE 0x0063
> +/* ETOMOD signal is brought to PHY reset. bit2 must be 1 in Celleb */
> +#define SPIDER_NET_OPMODE_VALUE 0x0067
Is it okay to simple change this value for the ibm blades?
> +static int is1000 = 1;
This should be in struct spider_net_card instead of a global flag.
> case SPIDER_NET_GTMFLLINT:
> - if (netif_msg_intr(card) && net_ratelimit())
> - pr_err("Spider TX RAM full\n");
> + /* if (netif_msg_intr(card) && net_ratelimit())
> + pr_err("Spider TX RAM full\n"); */
Either this should be kept or removed entirely. In the latter case you
need a good description why it's removed in the patch header.
> +
> + spider_net_write_reg(card, SPIDER_NET_GMACOPEMD,
> + spider_net_read_reg(card, SPIDER_NET_GMACOPEMD) |
> 0x4);
Please make sure this doesn't overflow the 80 characters per line limit.
> +static int spider_net_init_firmware(struct spider_net_card *);
Random forward declarations in the middle of the file aren't very nice.
If you really need them put them at the beggining of the file, but it would
be even better if you moved spider_net_init_firmware further up in the
file so we wouldn't need the forward-declaration at all.
> + if (card->phy.def->phy_id)
> + mod_timer(&card->aneg_timer, jiffies + SPIDER_NET_ANEG_TIMER);
> + else
> + pr_err("No phy is available\n");
What is this idiom about? Is not having a phy a fatal error in which case
we should abort here, or is it tolerable in which case pr_err is too much.
> +static void spider_net_init_card(struct spider_net_card *);
Same comment above forward declarations as above.
-
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
Re: [NETLINK]: Schedule removal of old macros exported to userspace
On Sat, 2006-12-09 at 15:58 +0100, Stefan Rompf wrote: > But when even glibc needs internal compat headers to compile with the second > kernel version that provides userspace headers, what is the long-term - even > mid-term - perspective of make headers_install then? Bear in mind that with the first cut of the headers_install I was trying to keep it entirely uncontentious and stick to _mechanism_, not policy. The _first_ set of exported headers still aren't ideal, and we're still cleaning up some parts of them (like properly getting rid of the _syscallX() macros, etc.). We've only just started to be sensible about what we export to userspace -- it's not entirely set in stone at this point, -- dwmw2 - 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
Re: d80211-drivers pull request (week-48)
On Tuesday 12 December 2006 02:07, Daniel Drake wrote: > Michael Wu wrote: > > zd1211rw-d80211: Use ieee80211_tx_status > > I've thought some more about this and I'm not so sure that this is the > right approach. > > Can't devicescape be taught that the ZD1211 handles retries in hardware > and the stack doesn't need to worry about it? > > What does devicescape do in response to not getting an ack? It does ratecontrol based on that. Basically: No ACK == failed packet. If too many failures, lower the rate. -- Greetings Michael. - 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
Re: ieee80211 sleeping in invalid context
On Tuesday 12 December 2006 05:06, Ray Lee wrote:
> Hey all, more data on my bcm43xx problem report from a few weeks back.
>
> By random chance I acquired a brain, and decided to rebuild my latest kernel
Congratulations to your decision ;)
> Dec 11 19:34:47 phoenix kernel: [ 57.044691] WARNING at kernel/mutex.c:132
> __mutex_lock_common()
> Dec 11 19:34:47 phoenix kernel: [ 57.044694]
I'm not sure what's happening here. Either one of the following
assertions is failing:
038 #define spin_lock_mutex(lock, flags)\
039 do {\
040 struct mutex *l = container_of(lock, struct mutex,
wait_lock); \
041 \
042 DEBUG_LOCKS_WARN_ON(in_interrupt());\
043 local_irq_save(flags); \
044 __raw_spin_lock(&(lock)->raw_lock); \
045 DEBUG_LOCKS_WARN_ON(l->magic != l); \
046 } while (0)
Which kernel are you using?
There is some locking breakage in latest kernels with softmac.
I attached the fixes for the known bugs.
From: Michael Buesch <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Sun, 10 Dec 2006 18:39:28 +0100
Message-Id: <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>, Johannes Berg <[EMAIL PROTECTED]>, "John
W. Linville" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: ieee80211softmac: Fix mutex_lock at exit of ieee80211_softmac_get_genie
From: Ulrich Kunitz <[EMAIL PROTECTED]>
ieee80211softmac_wx_get_genie locks the associnfo mutex at
function exit. This patch fixes it. The patch is against Linus'
tree (commit af1713e0).
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/ieee80211/softmac/ieee80211softmac_wx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.19.1.orig/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ linux-2.6.19.1/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -463,7 +463,7 @@ ieee80211softmac_wx_get_genie(struct net
err = -E2BIG;
}
spin_unlock_irqrestore(&mac->lock, flags);
- mutex_lock(&mac->associnfo.mutex);
+ mutex_unlock(&mac->associnfo.mutex);
return err;
}
From: Ulrich Kunitz <[EMAIL PROTECTED]>
The signature of work functions changed recently from a context
pointer to the work structure pointer. This caused a problem in
the ieee80211softmac code, because the ieee80211softmac_assox_work
function has been called directly with a parameter explicitly
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
call of the schedule_work function. Softmac works again and this
fixes the problem I mentioned earlier in the zd1211rw rx tasklet
patch. The patch is against Linus' tree (commit af1713e0).
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch should be pushed upstream to 2.6.20. At the moment, the work
struct changes have not yet propagated to wireless-2.6. When they do,
it will be needed there as well.
Larry
net/ieee80211/softmac/ieee80211softmac_assoc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type,
void *context)
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(&mac->associnfo.work.work);
}
static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struc
switch (event_type) {
case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(&mac->associnfo.work.work);
break;
case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
@@ -438,7 +438,7 @@ ieee80211softmac_try_reassoc(struct ieee
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.associating = 1;
- schedule_work(&mac->associnfo.work);
+ schedule_delayed_work(&mac->associnfo.work, 0);
spin_unlock_irqrestore(&mac->lock, flags);
}
--
Greetings Michael.
-
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
Re: Fw: [Bugme-new] [Bug 7665] New: getsockopt(IPV6_*CAST_HOPS) returns -1
Hello, Le lundi 11 décembre 2006 22:55, Brian Haley a écrit : > Andrew Morton wrote: > > Where fd is a socket (datagram or raw) with IPv6 protocol family, > > getsockopt(fd, IPPROTO_IPV6, IPV6_UNICAST_HOPS, ...) succeeds, but > > the returned hop limit is -1. connect()'ing the socket first does > > not solve the problem. > > An IPv6 socket's hoplimit value is not set at creation time, instead, > the hoplimit in an outgoing packet is set dynamically at transmit > time to one of the following (in this order): > > 1. Hoplimit route metric (if set) > 2. Outgoing interface value (/proc/sys/net/ipv6/conf/ethX/hop_limit) > 3. Global IPv6 value (/proc/sys/net/ipv6/conf/all/hop_limit) > > A setsockopt() value *will* override this. Relevant standard (RFC 3493) notes: The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine the hop limit value that the system will use for subsequent unicast packets sent via that socket. I don't reckon -1 could be the hop limit value. IMHO, the value from case 1 (if socket is connected to some destination), otherwise case 2 (if bound to a scope interface) or ultimately the default hop limit ought to be returned instead, as it will be most often correct, while the current behavior is always wrong, unless setsockopt() has been used first. I don't if some people may think doing a route lookup in getsockopt might be overly expensive, but at least the two other cases should be ok, particularly the last one. -- Rémi Denis-Courmont - 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
