* Re: [PATCH 0/5] sky2: version 1.2
From: Bertrand Jacquin @ 2006-04-29 18:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: jgarzik, netdev
In-Reply-To: <20060425175849.372221000@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 476 bytes --]
Le Tue, 25 Apr 2006 10:58:49 -0700, Stephen Hemminger <shemminger@osdl.org> m'a avoué:
> Update to sky2 driver. Mostly fixes to try and handle users
> stuck with edge-triggered interrupts. Also, some minor cleanups.
>
> Patches apply onto 1.1 version in 2.6.17-rc2
Hi,
I've just testing patches and I get still the same bug.
--
/* Beber : beber (AT) gna (DOT) org
* http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
* Guybrush @ Melee */
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00 drivers: rt61pci
From: Francois Romieu @ 2006-04-29 16:10 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: netdev, rt2x00-devel
In-Reply-To: <200604291735.12720.IvDoorn@gmail.com>
Ivo van Doorn <ivdoorn@gmail.com> :
[...]
> Not sure about that either. I usually choose the type of the counter
> depending on the max size of that counter.
It is not arch-neutral. powerpc favors unsigned int over int but I am
too lazy to check if the size matters.
[...]
> Perhaps, but I prefer the usage of the name "counter".
> I am not sure if there is a coding style about this? If so I could
> rename "counter" to "i".
Chapter 4 of Documentation/CodingStyle goes in this direction.
The document is not meant to be a taken too literally though.
The repetitive use of 'counter' + foo[counter].blah tends to be a
bit bloaty.
[...]
> I'll create a bugreport in the rt2x00 project bugzilla
> with some of the coding style change requests.
I will not complain if you open a bugreport to provide a git repo
as well.
/me hides...
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00 drivers: rt61pci
From: Ivo van Doorn @ 2006-04-29 15:35 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, rt2x00-devel
In-Reply-To: <20060429145850.GA2456@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]
On Saturday 29 April 2006 16:58, Francois Romieu wrote:
> Ivo van Doorn <ivdoorn@gmail.com> :
> > From: Ivo van Doorn <IvDoorn@gmail.com>
> >
> > This adds the rt61pci driver to the tree
> >
> > Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
> >
> > Available on server:
> > http://mendiosus.nl/rt2x00/rt61pci.diff
>
> It is nice that you are doing this work but I still don't feel
> the same while reading your patches or tg3.c/sky2.c (for instance).
>
> +static inline void
> +rt2x00_register_read(
>
> grep accepts regular expression and ctags works quite well.
> Why do you cut an expression which would fit on a 80 columns line ?
Part of the coding style I use. Bad habit, I know.
I'll change them.
> [...]
> + u32 reg;
> + u8 counter;
>
> It's (mostly) fine with me if you want to align the declaration
> but why do you use more than the minimum amount of required tab ?
> Elsewhere the variable is completely shifted right: beyond a point,
> it does not make the code more readable.
Unless I am mistaken, 2 tabs are used at a max.
Perhaps in some cases it is more, because the variable beneath
is a long structure name. I'll go over them again, and check where
they could be minimized.
> Not sure if 'unsigned int' would be welcome instead of 'u8' for
> counter.
Not sure about that either. I usually choose the type of the counter
depending on the max size of that counter.
> [...]
> + for (counter = 0; counter < REGISTER_BUSY_COUNT; counter++) {
> + rt2x00_register_read(rt2x00pci, PHY_CSR3, ®);
>
> "i" is more idiomatic C-kernel than "counter".
Perhaps, but I prefer the usage of the name "counter".
I am not sure if there is a coding style about this? If so I could rename "counter" to "i".
> [...]
> + if (rt2x00_rf(&rt2x00pci->chip, RF5225)
> + || rt2x00_rf(&rt2x00pci->chip, RF2527))
>
> If you put the || at the end of the previous line, you can indent
> the second line with four withspaces, thus aligning the content.
I'll create a bugreport in the rt2x00 project bugzilla
with some of the coding style change requests.
It could take a while before a patch will be ready since I put higher
priority to get the drivers working correctly. ;)
> [...]
> +static void
> +rt61pci_init_firmware_cont(const struct firmware *fw, void *context)
> [...]
> + for (counter = 0; counter < 100; counter++) {
> + rt2x00_register_read(rt2x00pci, MCU_CNTL_CSR, ®);
> + if (rt2x00_get_field32(reg, MCU_CNTL_CSR_READY))
> + break;
> + msleep(1);
> + }
> +
> + if (counter == 1000) {
> ^ -> typo
Good call. Thanks. :)
> [...]
> static int
> +rt61pci_init_firmware(struct rt2x00_pci *rt2x00pci)
> +{
> + /*
> + * Read correct firmware from harddisk.
> + */
> + if (rt2x00_rt(&rt2x00pci->chip, RT2561))
> + return request_firmware_nowait(THIS_MODULE, 1,
> + "rt2561.bin", &rt2x00pci->pci_dev->dev, rt2x00pci,
> + rt61pci_init_firmware_cont);
> + else if (rt2x00_rt(&rt2x00pci->chip, RT2561s))
> + return request_firmware_nowait(THIS_MODULE, 1,
> + "rt2561s.bin", &rt2x00pci->pci_dev->dev, rt2x00pci,
> + rt61pci_init_firmware_cont);
> + else if (rt2x00_rt(&rt2x00pci->chip, RT2661))
> + return request_firmware_nowait(THIS_MODULE, 1,
> + "rt2661.bin", &rt2x00pci->pci_dev->dev, rt2x00pci,
> + rt61pci_init_firmware_cont);
>
> struct {
> char *name;
> unsigned int chip;
> } firmware[] = {
> { "rt2561.bin", RT2561 },
> { "rt2561s.bin", RT2561s },
> { "rt2561.bin", RT2661 }
> };
> int rc = -EINVAL;
> unsigned int i;
>
> for (i = 0; i < ARRAY_SIZE(firmware); i++) {
> if (!rt2x00_rt(&rt2x00pci->chip, firmware[i].chip))
> continue;
> rc = request_firmware_nowait(THIS_MODULE, 1,
> firmware[i].name, &rt2x00pci->pci_dev->dev,
> rt2x00pci, rt61pci_init_firmware_cont);
> break;
> }
> return rc;
Sounds good to me.
I'll make this fix part of next patch series.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] rt2x00 drivers: rt61pci
From: Francois Romieu @ 2006-04-29 14:58 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: netdev, rt2x00-devel
In-Reply-To: <200604291147.26887.IvDoorn@gmail.com>
Ivo van Doorn <ivdoorn@gmail.com> :
> From: Ivo van Doorn <IvDoorn@gmail.com>
>
> This adds the rt61pci driver to the tree
>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
>
> Available on server:
> http://mendiosus.nl/rt2x00/rt61pci.diff
It is nice that you are doing this work but I still don't feel
the same while reading your patches or tg3.c/sky2.c (for instance).
+static inline void
+rt2x00_register_read(
grep accepts regular expression and ctags works quite well.
Why do you cut an expression which would fit on a 80 columns line ?
[...]
+ u32 reg;
+ u8 counter;
It's (mostly) fine with me if you want to align the declaration
but why do you use more than the minimum amount of required tab ?
Elsewhere the variable is completely shifted right: beyond a point,
it does not make the code more readable.
Not sure if 'unsigned int' would be welcome instead of 'u8' for
counter.
[...]
+ for (counter = 0; counter < REGISTER_BUSY_COUNT; counter++) {
+ rt2x00_register_read(rt2x00pci, PHY_CSR3, ®);
"i" is more idiomatic C-kernel than "counter".
[...]
+ if (rt2x00_rf(&rt2x00pci->chip, RF5225)
+ || rt2x00_rf(&rt2x00pci->chip, RF2527))
If you put the || at the end of the previous line, you can indent
the second line with four withspaces, thus aligning the content.
[...]
+static void
+rt61pci_init_firmware_cont(const struct firmware *fw, void *context)
[...]
+ for (counter = 0; counter < 100; counter++) {
+ rt2x00_register_read(rt2x00pci, MCU_CNTL_CSR, ®);
+ if (rt2x00_get_field32(reg, MCU_CNTL_CSR_READY))
+ break;
+ msleep(1);
+ }
+
+ if (counter == 1000) {
^ -> typo
[...]
static int
+rt61pci_init_firmware(struct rt2x00_pci *rt2x00pci)
+{
+ /*
+ * Read correct firmware from harddisk.
+ */
+ if (rt2x00_rt(&rt2x00pci->chip, RT2561))
+ return request_firmware_nowait(THIS_MODULE, 1,
+ "rt2561.bin", &rt2x00pci->pci_dev->dev, rt2x00pci,
+ rt61pci_init_firmware_cont);
+ else if (rt2x00_rt(&rt2x00pci->chip, RT2561s))
+ return request_firmware_nowait(THIS_MODULE, 1,
+ "rt2561s.bin", &rt2x00pci->pci_dev->dev, rt2x00pci,
+ rt61pci_init_firmware_cont);
+ else if (rt2x00_rt(&rt2x00pci->chip, RT2661))
+ return request_firmware_nowait(THIS_MODULE, 1,
+ "rt2661.bin", &rt2x00pci->pci_dev->dev, rt2x00pci,
+ rt61pci_init_firmware_cont);
struct {
char *name;
unsigned int chip;
} firmware[] = {
{ "rt2561.bin", RT2561 },
{ "rt2561s.bin", RT2561s },
{ "rt2561.bin", RT2661 }
};
int rc = -EINVAL;
unsigned int i;
for (i = 0; i < ARRAY_SIZE(firmware); i++) {
if (!rt2x00_rt(&rt2x00pci->chip, firmware[i].chip))
continue;
rc = request_firmware_nowait(THIS_MODULE, 1,
firmware[i].name, &rt2x00pci->pci_dev->dev,
rt2x00pci, rt61pci_init_firmware_cont);
break;
}
return rc;
--
Ueimor
^ permalink raw reply
* Your urgent response is required.
From: Steven Alamieyeseigha @ 2006-04-29 14:37 UTC (permalink / raw)
To: okir
Dear friend,
I can understand how surprise this letter will mean to you, but would advice that you consider it as
a request from a family in dare need of assistance. My name is Steven D. Alamieyeseigha, son of the
embattled Governor of Bayelsa state-Nigeria, my dad was arrested on the 16 September 2005 in United
Kingdom with allegations of money laundering.
I got your contact information from your country's trade journal during my search for a reliable and
God-fearing person that can assist my family. I quite believe on my own that you can be of great
help in this regard even if I am not acquainted to you before. I am contacting you to solicite for
your assistance in helping my family to receive the sum of $11 million US Dollars for safe keeping,
we are also willing to invest this money in your country, since the United Kingdom and Nigeria
Governments are still investigating my father's case.
You can find more details about my dad's arrest through this website:
http://news.bbc.co.uk/2/hi/africa/4253362.stm
Please! Send your reply to my private email address which is: mr_stevenalamieyeseigha01@yahoo.it
for security reasons.
I am looking forward to hearing from you soon.
Best regards,
Steven .D Alamieyeseigha.
--
Deze mail is verzonden via web.nl
http://mail.web.nl
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-29 13:54 UTC (permalink / raw)
To: David S. Miller; +Cc: shemminger, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428.150056.18940876.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]
On Fri, Apr 28, 2006 at 03:00:56PM -0700, David S. Miller (davem@davemloft.net) wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Fri, 28 Apr 2006 23:59:30 +0400
>
> > kevent can be used as poll without any changes to the socket code.
> > There are two types of network related kevents - socket events
> > (recv/send/accept) and network aio, which can be turned completely off
> > in config.
> > There are following events which are supported by kevent:
> > o usual poll/select notifications
> > o inode notifications (create/remove)
> > o timer notifications
> > o socket notifications (send/recv/accept)
> > o network aio system
> > o fs aio (project closed, aio_sendfile() is being developed instead)
> >
> > Any of the above can be turned off by config option.
>
> Feel free to post the current version of your kevent patch
> here so we can discuss something concrete.
>
> Maybe you have even some toy example user applications that
> use kevent that people can look at too? That might help
> in understanding how it's supposed to be used.
There are several at project's homepage [1] and in archive [2]:
evserver_epoll.c - epoll-based web server (pure epoll)
evserver_kevent.c - kevent-based web server (socket notifications)
evserver_poll.c - web server which uses kevent-based poll (poll/select
notifications)
evtest.c - can wait for any type of events. It was used to test
timer notifications.
naio_recv.c/naio_send.c - network AIO sending and receiving benchmarks
(sync/async)
aio_sendfile.c - aio sendfile benchmark (sendfile/aio_sendfile). Kernel
implementation is not 100% ready, pages are only asynchronously propagated
into VFS cache, but are not sent yet.
There are also links to benchmark results, comparison with FreeBSD kqueue, some
conclusions on kevent homepage [1].
Network AIO [3] homepage also contains additional NAIO benchmarks with
some graphs.
1. kevent project home page.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent
2. kevent archive
http://tservice.net.ru/~s0mbre/archive/kevent/
3. Network AIO
http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
Current development kevent patchset (against 2.6.15-rc7, but could be
applied against later trees too) attached gzipped, sory if you get this
twice.
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
--
Evgeniy Polyakov
[-- Attachment #2: kevent_full.diff.gz --]
[-- Type: application/x-gunzip, Size: 23625 bytes --]
^ permalink raw reply
* [TCP]: Fix sock_orphan dead lock
From: Herbert Xu @ 2006-04-29 13:13 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David S. Miller, Arjan van de Ven, netdev
In-Reply-To: <20060429111507.GA3077@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]
On Sat, Apr 29, 2006 at 09:15:07PM +1000, herbert wrote:
>
> Unfortunately this is only true for TCP. All of the connectionless
> protocols use the callback lock without the socket lock so it does
> still serve a purpose.
>
> I'd be happy to see your patch included.
I've just changed my mind :) Instead of disabling BH on the read_lock
callers, we can instead move sock_orphan outside bh_lock_sock.
[TCP]: Fix sock_orphan dead lock
Calling sock_orphan inside bh_lock_sock in tcp_close can lead to dead
locks. For example, the inet_diag code holds sk_callback_lock without
disabling BH. If an inbound packet arrives during that admittedly tiny
window, it will cause a dead lock on bh_lock_sock. Another possible
path would be through sock_wfree if the network device driver frees the
tx skb in process context with BH enabled.
We can fix this by moving sock_orphan out of bh_lock_sock.
The tricky bit is to work out when we need to destroy the socket
ourselves and when it has already been destroyed by someone else.
By moving sock_orphan before the release_sock we can solve this
problem. This is because as long as we own the socket lock its
state cannot change.
So we simply record the socket state before the release_sock
and then check the state again after we regain the socket lock.
If the socket state has transitioned to TCP_CLOSE in the time being,
we know that the socket has been destroyed. Otherwise the socket is
still ours to keep.
Note that I've also moved the increment on the orphan count forward.
This may look like a problem as we're increasing it even if the socket
is just about to be destroyed where it'll be decreased again. However,
this simply enlarges a window that already exists. This also changes
the orphan count test by one.
Considering what the orphan count is meant to do this is no big deal.
This problem was discoverd by Ingo Molnar using his lock validator.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[-- Attachment #2: tcp-sock-orphan.patch --]
[-- Type: text/plain, Size: 1337 bytes --]
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 87f68e7..e2b7b80 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1468,6 +1468,7 @@
{
struct sk_buff *skb;
int data_was_unread = 0;
+ int state;
lock_sock(sk);
sk->sk_shutdown = SHUTDOWN_MASK;
@@ -1544,6 +1545,11 @@
sk_stream_wait_close(sk, timeout);
adjudge_to_death:
+ state = sk->sk_state;
+ sock_hold(sk);
+ sock_orphan(sk);
+ atomic_inc(sk->sk_prot->orphan_count);
+
/* It is the last release_sock in its life. It will remove backlog. */
release_sock(sk);
@@ -1555,8 +1561,9 @@
bh_lock_sock(sk);
BUG_TRAP(!sock_owned_by_user(sk));
- sock_hold(sk);
- sock_orphan(sk);
+ /* Have we already been destroyed by a softirq or backlog? */
+ if (state != TCP_CLOSE && sk->sk_state == TCP_CLOSE)
+ goto out;
/* This is a (useful) BSD violating of the RFC. There is a
* problem with TCP as specified in that the other end could
@@ -1584,7 +1591,6 @@
if (tmo > TCP_TIMEWAIT_LEN) {
inet_csk_reset_keepalive_timer(sk, tcp_fin_time(sk));
} else {
- atomic_inc(sk->sk_prot->orphan_count);
tcp_time_wait(sk, TCP_FIN_WAIT2, tmo);
goto out;
}
@@ -1603,7 +1609,6 @@
NET_INC_STATS_BH(LINUX_MIB_TCPABORTONMEMORY);
}
}
- atomic_inc(sk->sk_prot->orphan_count);
if (sk->sk_state == TCP_CLOSE)
inet_csk_destroy_sock(sk);
^ permalink raw reply related
* Re: IP1000 gigabit nic driver
From: David Vrabel @ 2006-04-29 12:58 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Gómez, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <1146306567.1642.3.camel@localhost>
Pekka Enberg wrote:
>
> I ended up doing most of them myself [1]. Sorry :-) Are the datasheets
> public by the way?
http://www.icplus.com.tw/Data/Datasheet/IP1000A-DS-R08-07052005.pdf
> 1. http://www.cs.helsinki.fi/u/penberg/linux/ip1000-driver.patch
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: David Gómez @ 2006-04-29 12:21 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Vrabel, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <1146306567.1642.3.camel@localhost>
Hi Pekka,
On Apr 29 at 01:29:26, Pekka Enberg wrote:
> I ended up doing most of them myself [1]. Sorry :-) Are the datasheets
> public by the way?
I already had it modified, just needed to create the patch... Anyway,
have you submitted it to netdev?
About the datasheets, i don't think so. The icplus web page seems broken
except for the driver section. But maybe if asked they'll made public
the datasheets.
cheers,
--
David Gómez Jabber ID: davidge@jabber.org
^ permalink raw reply
* wireless-dev: warnings while removing bcm43xx-d80211
From: Johannes Berg @ 2006-04-29 11:00 UTC (permalink / raw)
To: netdev; +Cc: Broadcom Linux
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
This didn't look too good to me, maybe someone can investigate?
[24070.841580] Badness in remove_proc_entry at fs/proc/generic.c:732
[24070.841593] Call Trace:
[24070.841598] [E9A87C30] [C00081E8] show_stack+0x50/0x190 (unreliable)
[24070.841618] [E9A87C60] [C000E4EC] program_check_exception+0x454/0x5d0
[24070.841632] [E9A87CC0] [C000FA00] ret_from_except_full+0x0/0x4c
[24070.841643] --- Exception: 700 at remove_proc_entry+0x14c/0x1d0
[24070.841661] LR = remove_proc_entry+0x58/0x1d0
[24070.841667] [E9A87DC0] [F20BE214] ieee80211_proc_deinit_interface+0x38/0xe4 [80211]
[24070.841729] [E9A87DD0] [F20B17E0] ieee80211_unregister_hw+0xf4/0x1ac [80211]
[24070.841749] [E9A87DF0] [F24C2644] bcm43xx_remove_one+0x44/0xc0 [bcm43xx_d80211]
[24070.841789] [E9A87E10] [C0151670] pci_device_remove+0x38/0x60
[24070.841806] [E9A87E20] [C019F098] __device_release_driver+0x74/0xac
[24070.841822] [E9A87E40] [C019F5DC] driver_detach+0x110/0x140
[24070.841833] [E9A87E60] [C019E8C8] bus_remove_driver+0x8c/0xc8
[24070.841844] [E9A87E80] [C019F990] driver_unregister+0x18/0x34
[24070.841855] [E9A87EA0] [C0151524] pci_unregister_driver+0x20/0x8c
[24070.841866] [E9A87EC0] [F24D9954] bcm43xx_exit+0x18/0x376c [bcm43xx_d80211]
[24070.841886] [E9A87ED0] [C0047D30] sys_delete_module+0x19c/0x20c
[24070.841899] [E9A87F40] [C000F3A4] ret_from_syscall+0x0/0x38
[24070.841909] --- Exception: c01 at 0xff6e708
[24070.841918] LR = 0x1000103c
[24084.097041] Badness in remove_proc_entry at fs/proc/generic.c:732
[24084.097056] Call Trace:
[24084.097061] [E9BDBD20] [C00081E8] show_stack+0x50/0x190 (unreliable)
[24084.097081] [E9BDBD50] [C000E4EC] program_check_exception+0x454/0x5d0
[24084.097095] [E9BDBDB0] [C000FA00] ret_from_except_full+0x0/0x4c
[24084.097106] --- Exception: 700 at remove_proc_entry+0x14c/0x1d0
[24084.097124] LR = remove_proc_entry+0x58/0x1d0
[24084.097130] [E9BDBEB0] [F20BE37C] ieee80211_proc_deinit+0x38/0x48 [80211]
[24084.097174] [E9BDBEC0] [F20C7560] ieee80211_exit+0x14/0x3aec [80211]
[24084.097192] [E9BDBED0] [C0047D30] sys_delete_module+0x19c/0x20c
[24084.097206] [E9BDBF40] [C000F3A4] ret_from_syscall+0x0/0x38
[24084.097215] --- Exception: c01 at 0xff6e708
[24084.097224] LR = 0x1000103c
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Arjan van de Ven @ 2006-04-29 10:35 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Gómez, David Vrabel, Francois Romieu, Linux-kernel,
netdev
In-Reply-To: <1146306567.1642.3.camel@localhost>
On Sat, 2006-04-29 at 13:29 +0300, Pekka Enberg wrote:
> On Fri, 28 Apr 2006, David Gómezz wrote:
> > > Ok, i could take care of that, and it's a good way of getting my hands
> > > dirty with kernel programming ;). David, if it's ok to you i'll do the
> > > cleanup thing.
>
> On Fri, 2006-04-28 at 14:59 +0300, Pekka J Enberg wrote:
> > Here are some suggestions for coding style cleanups:
>
> [snip]
>
> I ended up doing most of them myself [1]. Sorry :-) Are the datasheets
> public by the way?
you want to nuke the ioctl btw and just use ethtool ioctl instead
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Pekka Enberg @ 2006-04-29 10:29 UTC (permalink / raw)
To: David Gómez; +Cc: David Vrabel, Francois Romieu, Linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.58.0604281458110.19801@sbz-30.cs.Helsinki.FI>
On Fri, 28 Apr 2006, David Gómezz wrote:
> > Ok, i could take care of that, and it's a good way of getting my hands
> > dirty with kernel programming ;). David, if it's ok to you i'll do the
> > cleanup thing.
On Fri, 2006-04-28 at 14:59 +0300, Pekka J Enberg wrote:
> Here are some suggestions for coding style cleanups:
[snip]
I ended up doing most of them myself [1]. Sorry :-) Are the datasheets
public by the way?
Pekka
1. http://www.cs.helsinki.fi/u/penberg/linux/ip1000-driver.patch
^ permalink raw reply
* [PATCH 2/3] rt2x00 drivers: rt61pci
From: Ivo van Doorn @ 2006-04-29 9:47 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
This adds the rt61pci driver to the tree
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Available on server:
http://mendiosus.nl/rt2x00/rt61pci.diff
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 3/3] rt2x00 drivers: rt73usb
From: Ivo van Doorn @ 2006-04-29 9:47 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
This adds the rt73usb driver to the tree
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Available on server:
http://mendiosus.nl/rt2x00/rt73usb.diff
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/3] rt2x00 drivers: Makefile & CRC
From: Ivo van Doorn @ 2006-04-29 9:47 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 7109 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
Change Makefile and KConfig file to add the rt61pci and rt73usb
drivers to the list.
The firmware needs to be validated by CRC, for this a crc header
has been added to the tree as well.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/Kconfig wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/Kconfig
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/Kconfig 2006-04-27 00:52:56.000000000 +0200
+++ wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/Kconfig 2006-04-29 11:42:17.000000000 +0200
@@ -5,7 +5,7 @@ config RT2X00
This will enable the experimental support for the Ralink drivers,
developed in the rt2x00 project <http://rt2x00.serialmonkey.com>.
- These drivers will make use of the DeviceScape ieee80211 stack.
+ These drivers will make use of the Devicescape ieee80211 stack.
config RT2400PCI
tristate "Ralink rt2400 pci/pcmcia support"
@@ -53,6 +53,29 @@ config RT2500PCI_DEBUG
---help---
Enable debugging output.
+config RT61PCI
+ tristate "Ralink rt61 pci/pcmcia support"
+ depends on RT2X00 && FW_LOADER && PCI
+ ---help---
+ This is an experimental driver for the Ralink rt61 wireless chip.
+
+ When compiled as a module, this driver will be called "rt61pci.ko".
+
+config RT2500PCI_BUTTON
+ bool "Ralink rt61 hardware button support"
+ depends on RT61PCI && X86
+ ---help---
+ In some notebooks the rt61 chipset is integrated in the machine,
+ with this option enabled the device will periodically poll the
+ the status of this button and will send and ACPI event when
+ the button has been pressed.
+
+config RT61PCI_DEBUG
+ bool "Ralink rt61 debug output"
+ depends on RT61PCI
+ ---help---
+ Enable debugging output.
+
config RT2500USB
tristate "Ralink rt2500 usb support"
depends on RT2X00 && USB
@@ -66,3 +89,17 @@ config RT2500USB_DEBUG
depends on RT2500USB
---help---
Enable debugging output.
+
+config RT73USB
+ tristate "Ralink rt73 usb support"
+ depends on RT2X00 && FW_LOADER && USB
+ ---help---
+ This is an experimental driver for the Ralink rt73 wireless chip.
+
+ When compiled as a module, this driver will be called "rt73usb.ko".
+
+config RT73USB_DEBUG
+ bool "Ralink rt73 debug output"
+ depends on RT73USB
+ ---help---
+ Enable debugging output.
\ No newline at end of file
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/Makefile wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/Makefile
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/Makefile 2006-04-27 00:52:56.000000000 +0200
+++ wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/Makefile 2006-04-29 11:41:21.000000000 +0200
@@ -1,3 +1,5 @@
obj-$(CONFIG_RT2400PCI) += rt2400pci.o
obj-$(CONFIG_RT2500PCI) += rt2500pci.o
-obj-$(CONFIG_RT2500USB) += rt2500usb.o
+obj-$(CONFIG_RT61PCI) += rt61pci.o
+obj-$(CONFIG_RT2500USB) += rt2500usb.o
+obj-$(CONFIG_RT73USB) += rt73usb.o
\ No newline at end of file
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00crc.h wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/rt2x00crc.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2x00crc.h 1970-01-01 01:00:00.000000000 +0100
+++ wireless-dev-rt2x00-drivers/drivers/net/wireless/d80211/rt2x00/rt2x00crc.h 2006-04-29 11:41:21.000000000 +0200
@@ -0,0 +1,82 @@
+/*
+ Copyright (C) 2004 - 2006 rt2x00 SourceForge Project
+ <http://rt2x00.serialmonkey.com>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Module: rt2x00
+ Abstract: rt2x00 CRC implementation for firmware validation.
+ Supported chipsets: rt2561, rt2561s, rt2661 & rt2573
+ */
+
+#ifndef RT2X00CRC_H
+#define RT2X00CRC_H
+
+static const u16 rt2x00crc_table[256] = {
+ 0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7,
+ 0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef,
+ 0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6,
+ 0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de,
+ 0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485,
+ 0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d,
+ 0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4,
+ 0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc,
+ 0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823,
+ 0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b,
+ 0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12,
+ 0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a,
+ 0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41,
+ 0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49,
+ 0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70,
+ 0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78,
+ 0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f,
+ 0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067,
+ 0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e,
+ 0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256,
+ 0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d,
+ 0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
+ 0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c,
+ 0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634,
+ 0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab,
+ 0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3,
+ 0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a,
+ 0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1, 0x1ad0, 0x2ab3, 0x3a92,
+ 0xfd2e, 0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8, 0x8dc9,
+ 0x7c26, 0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83, 0x1ce0, 0x0cc1,
+ 0xef1f, 0xff3e, 0xcf5d, 0xdf7c, 0xaf9b, 0xbfba, 0x8fd9, 0x9ff8,
+ 0x6e17, 0x7e36, 0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0x0ed1, 0x1ef0
+};
+
+static inline u16
+rt2x00crc_byte(u16 crc, const u8 data)
+{
+ return (crc << 8) ^ rt2x00crc_table[((crc >> 8) ^ data) & 0xff];
+}
+
+/*
+ * Compute the rt2x00 CRC for the data buffer
+ */
+static inline u16
+rt2x00crc(u16 crc, const u8 *buffer, size_t len)
+{
+ while (len--)
+ crc = rt2x00crc_byte(crc, *buffer++);
+ return crc;
+}
+
+#endif /* RT2X00CRC_H */
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 0/3] rt2x00 drivers
From: Ivo van Doorn @ 2006-04-29 9:47 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 266 bytes --]
Hi,
These patches are for the wireless-dev tree
and will add the rt61pci and rt73usb drivers
into the tree.
I have split them up into patches:
[PATCH 1/3] rt2x00 drivers: Makefile & CRC
[PATCH 2/3] rt2x00 drivers: rt61pci
[PATCH 3/3] rt2x00 drivers: rt73usb
IvD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH RESEND] rt2x00: Compile fix and kernel version cleanup
From: Ivo van Doorn @ 2006-04-29 9:36 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
In-Reply-To: <200604291126.56978.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5791 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
During CVS merge I noticed several compilation errors have sneaked
into the git version of rt2x00.
- PRIO_ENTRIES define has been removed, TX_ENTRIES should be used
- poll_delay module argument is of the type short
- Remove LINUX_VERSION_CODE checks.
- Fix missing byteordering type
- Fix typo in usb_device
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-29 11:30:00.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-29 11:31:06.000000000 +0200
@@ -1239,7 +1239,7 @@ rt2400pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_PRIO], rt2400pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_BEACON], rt2400pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -2729,14 +2729,11 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2400PCI_DEBUG */
#ifdef CONFIG_RT2400PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, "Delay between WiFi button pollings (in 100ms).");
#endif /* CONFIG_RT2400PCI_BUTTON */
static struct pci_driver rt2400pci_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14)
- .owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2400pci_device_table,
.probe = rt2400pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-29 11:30:00.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-29 11:31:00.000000000 +0200
@@ -1328,7 +1328,7 @@ rt2500pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_PRIO], rt2500pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_BEACON], rt2500pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -3032,14 +3032,11 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2500PCI_DEBUG */
#ifdef CONFIG_RT2500PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, "Delay between WiFi button pollings (in 100ms).");
#endif /* CONFIG_RT2500PCI_BUTTON */
static struct pci_driver rt2500pci_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14)
- .owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2500pci_device_table,
.probe = rt2500pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-29 11:29:58.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-29 11:30:39.000000000 +0200
@@ -1005,7 +1005,7 @@ struct txd{
__le32 word1;
#define TXD_W1_BUFFER_ADDRESS FIELD32(0xffffffff)
- u32 word2;
+ __le32 word2;
#define TXD_W2_IV_OFFSET FIELD32(0x0000003f)
#define TXD_W2_AIFS FIELD32(0x000000c0)
#define TXD_W2_CWMIN FIELD32(0x00000f00)
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-29 11:30:00.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-29 11:30:54.000000000 +0200
@@ -1362,7 +1362,7 @@ rt2500usb_tx(struct net_device *net_dev,
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb *rt2x00usb = ieee80211_dev_hw_data(net_dev);
- struct usb_devive *usb_dev =
+ struct usb_device *usb_dev =
interface_to_usbdev(rt2x00usb->usb_intf);
struct data_ring *ring;
struct data_entry *entry;
@@ -1844,7 +1844,7 @@ rt2500usb_beacon_update(struct net_devic
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb *rt2x00usb = ieee80211_dev_hw_data(net_dev);
- struct usb_devive *usb_dev =
+ struct usb_device *usb_dev =
interface_to_usbdev(rt2x00usb->usb_intf);
struct data_entry *entry;
@@ -2074,7 +2074,7 @@ rt2500usb_init_hw_channels(struct rt2x00
channels[counter].val = vals[counter];
}
- /*
+ /*
* Set TX power, each EEPROM TXpower entry
* contains the TXpower value for 2 channels.
*/
@@ -2628,9 +2628,6 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2500USB_DEBUG */
static struct usb_driver rt2500usb_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 15)
- .owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 15) */
.name = DRV_NAME,
.id_table = rt2500usb_device_table,
.probe = rt2500usb_probe,
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] rt2x00: Compile fix and kernel version cleanup
From: Ivo van Doorn @ 2006-04-29 9:26 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
In-Reply-To: <200604282052.44767.IvDoorn@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Friday 28 April 2006 20:52, Ivo van Doorn wrote:
> From: Ivo van Doorn <IvDoorn@gmail.com>
>
> During CVS merge I noticed several compilation errors have sneaked
> into the git version of rt2x00.
> - PRIO_ENTRIES define has been removed, TX_ENTRIES should be used
> - poll_delay module argument is of the type short
> - Remove LINUX_VERSION_CODE checks.
> - Fix missing byteordering type
> - Fix typo in usb_device
>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Please drop this patch, I'll resend a correct verion in a few minutes.
The LINUX_VERSION_CODE checks removal was obviously wrong.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-29 6:46 UTC (permalink / raw)
To: rusty; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <1146270160.8029.78.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Sat, 29 Apr 2006 10:22:40 +1000
> You're thinking the card would place the packet in the mmap'ed buffer,
> but the protocol handling would still be done (on that user-accessible
> buffer) in kernelspace?
Exactly.
> I hadn't considered that. Are the userspace-kernel interactions here
> are a lesser problem than telling userspace "you want direct access to
> the packets? Great, *you* handle the whole thing".
I've very much weary of putting a second TCP stack in userspace
for the same reasons most folks are weary of TOE.
And frankly we should only go towards that kind of duplication if it
shows a real performance gain.
Nevertheless I do highly encourage folks to experiment with that
as much as possible, I could be dead wrong on my hunch that it
won't help enough to justify allowing it.
^ permalink raw reply
* Re: E1000 stopped transmitting in rc3.
From: Jim McCullough @ 2006-04-29 6:46 UTC (permalink / raw)
To: Auke Kok; +Cc: David S. Miller, davej, netdev
In-Reply-To: <39fa70c7844cbb7240b98446e0940de7@localhost>
>From what I have seen currently, the issue is resolved. Based on a
test across multiple systems on x86-64, i386, and ia64 builds.
On 4/28/06, Auke Kok <sofar@foo-projects.org> wrote:
>
>
> On Fri, 28 Apr 2006 00:14:40 -0700 (PDT), "David S. Miller" <davem@davemloft.net> wrote:
> > From: Auke Kok <sofar@foo-projects.org>
> > Date: Thu, 27 Apr 2006 18:54:28 -0700
> >
> >> Dave Jones wrote:
> >> > With 2.6.17-rc3, my E1000 won't get a dhcp lease.
> >> > Looking at tcpdump and ifconfig output, it's easy to see why.
> >> > It's recieving packets, but the packets transmitted field
> >> > of ifconfig never increases.
> >> >
> >> > The last version I have built that worked ok was 2.6.17rc2-git3
> >>
> >> *puzzled*
> >>
> >> the only patch between 2.6.17rc2 and 2.6.17rc3 contains an rx-path
> > patch, but
> >> nothing that affects tx. All the other patches sent earlier are queued
> > for
> >> 2.6.18 so they don't apply.
> >
> > If the rx path is corrupting the packets or providing bad
> > checksums, there will be nothing to transmit back.
> >
> > So RX changes could explain the behavior.
>
> Jim sent me a private message that his colleagues messed up the build, and that it is working correctly now, right Jim?
>
> Cheers,
>
> Auke
>
>
>
--
Jim McCullough
^ permalink raw reply
* RE: [PATCH] PCI Error Recovery: e1000 network device driver
From: Zhang, Yanmin @ 2006-04-29 3:26 UTC (permalink / raw)
To: Linas Vepstas, Greg KH
Cc: Jeff Garzik, Ronciak, John, Brandeburg, Jesse, Kirsher, Jeffrey T,
linux-kernel, netdev, linux-pci, linuxppc-dev, Linux NICS
>>-----Original Message-----
>>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Linas Vepstas
>>Sent: 2006年3月25日 11:22
>>To: Greg KH
>>Cc: Jeff Garzik; Ronciak, John; Brandeburg, Jesse; Kirsher, Jeffrey T; linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
>>linux-pci@atrey.karlin.mff.cuni.cz; linuxppc-dev@ozlabs.org; Linux NICS
>>Subject: Re: [PATCH] PCI Error Recovery: e1000 network device driver
>>
>>On Fri, Mar 24, 2006 at 06:22:06PM -0800, Greg KH wrote:
>>> ... a bit
>>> different from the traditional kernel coding style.
>>
>>Sorry, this is due to inattention on my part; I get cross-eyed
>>after staring at the same code for too long. The patch below should
>>fix things.
>>
>>--linas
>>
>>
>>[PATCH] PCI Error Recovery: e1000 network device driver
>>
>>Various PCI bus errors can be signaled by newer PCI controllers. This
>>patch adds the PCI error recovery callbacks to the intel gigabit
>>ethernet e1000 device driver. The patch has been tested, and appears
>>to work well.
>>
>>Signed-off-by: Linas Vepstas <linas@linas.org>
>>Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>>
>>----
>>
>> drivers/net/e1000/e1000_main.c | 114 ++++++++++++++++++++++++++++++++++++++++-
>> 1 files changed, 113 insertions(+), 1 deletion(-)
>>
>>Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
>>===================================================================
>>--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-23 15:48:01.000000000 -0600
>>+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c 2006-03-24 15:14:40.431371705 -0600
>>@@ -226,6 +226,16 @@ static int e1000_resume(struct pci_dev *
>>+/**
>>+ * e1000_io_error_detected - called when PCI error is detected
>>+ * @pdev: Pointer to PCI device
>>+ * @state: The current pci conneection state
>>+ *
>>+ * This function is called after a PCI bus error affecting
>>+ * this device has been detected.
>>+ */
>>+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
>>+{
>>+ struct net_device *netdev = pci_get_drvdata(pdev);
>>+ struct e1000_adapter *adapter = netdev->priv;
>>+
>>+ netif_device_detach(netdev);
>>+
>>+ if (netif_running(netdev))
>>+ e1000_down(adapter);
[YM] e1000_down will do device IO. So it's not appropriate to do so here.
>>+
>>+ /* Request a slot slot reset. */
>>+ return PCI_ERS_RESULT_NEED_RESET;
>>+}
>>+
>>+/**
>>+ * e1000_io_slot_reset - called after the pci bus has been reset.
>>+ * @pdev: Pointer to PCI device
>>+ *
>>+ * Restart the card from scratch, as if from a cold-boot. Implementation
>>+ * resembles the first-half of the e1000_resume routine.
>>+ */
>>+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev)
>>+{
>>+ struct net_device *netdev = pci_get_drvdata(pdev);
>>+ struct e1000_adapter *adapter = netdev->priv;
>>+
>>+ if (pci_enable_device(pdev)) {
>>+ printk(KERN_ERR "e1000: Cannot re-enable PCI device after reset.\n");
>>+ return PCI_ERS_RESULT_DISCONNECT;
>>+ }
>>+ pci_set_master(pdev);
>>+
>>+ pci_enable_wake(pdev, 3, 0);
>>+ pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
[YM] Suggest using PCI_D3hot and PCI_D3cold instead of hard-coded numbers.
^ permalink raw reply
* Re: [PATCH] PCI Error Recovery: e100 network device driver
From: Zhang, Yanmin @ 2006-04-29 2:48 UTC (permalink / raw)
To: Linas Vepstas
Cc: Jeff Garzik, netdev, linux-pci, LKML, linuxppc-dev, john.ronciak,
jesse.brandeburg, jeffrey.t.kirsher
In-Reply-To: <20060406222359.GA30037@austin.ibm.com>
On Fri, 2006-04-07 at 06:24, Linas Vepstas wrote:
> Please apply and forward upstream.
>
> --linas
>
> [PATCH] PCI Error Recovery: e100 network device driver
>
> Various PCI bus errors can be signaled by newer PCI controllers. This
> patch adds the PCI error recovery callbacks to the intel ethernet e100
> device driver. The patch has been tested, and appears to work well.
>
> Signed-off-by: Linas Vepstas <linas@linas.org>
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
I am enabling PCI-Express AER (Advanced Error Reporting) in kernel and
glad to see many drivers to support pci error handling.
>
> ----
>
> drivers/net/e100.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 65 insertions(+)
>
> Index: linux-2.6.17-rc1/drivers/net/e100.c
> ===================================================================
> --- linux-2.6.17-rc1.orig/drivers/net/e100.c 2006-04-05 09:56:06.000000000 -0500
> +++ linux-2.6.17-rc1/drivers/net/e100.c 2006-04-06 15:17:29.000000000 -0500
> @@ -2781,6 +2781,70 @@ static void e100_shutdown(struct pci_dev
> }
>
>
> +/* ------------------ PCI Error Recovery infrastructure -------------- */
> +/** e100_io_error_detected() is called when PCI error is detected */
> +static pci_ers_result_t e100_io_error_detected(struct pci_dev *pdev, pci_channel_state_t state)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> +
> + /* Same as calling e100_down(netdev_priv(netdev)), but generic */
> + netdev->stop(netdev);
e100 stop method e100_close calls e100_down which would do IO. Does it
violate the rule defined in Documentation/pci-error-recovery.txt that
error_detected shouldn't do any IO?
Suggest to create a new function, such like e100_close_noreset.
> +
> + /* Detach; put netif into state similar to hotplug unplug */
> + netif_poll_enable(netdev);
> + netif_device_detach(netdev);
> +
> + /* Request a slot reset. */
> + return PCI_ERS_RESULT_NEED_RESET;
> +}
> +
> +/** e100_io_slot_reset is called after the pci bus has been reset.
> + * Restart the card from scratch. */
> +static pci_ers_result_t e100_io_slot_reset(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + if(pci_enable_device(pdev)) {
> + printk(KERN_ERR "e100: Cannot re-enable PCI device after reset.\n");
> + return PCI_ERS_RESULT_DISCONNECT;
> + }
> + pci_set_master(pdev);
> +
> + /* Only one device per card can do a reset */
> + if (0 != PCI_FUNC (pdev->devfn))
> + return PCI_ERS_RESULT_RECOVERED;
> + e100_hw_reset(nic);
> + e100_phy_init(nic);
Should pci_set_master be called after e100_hw_reset like in function
e100_probe?
> +
> + return PCI_ERS_RESULT_RECOVERED;
> +}
> +
> +/** e100_io_resume is called when the error recovery driver
> + * tells us that its OK to resume normal operation.
> + */
> +static void e100_io_resume(struct pci_dev *pdev)
> +{
> + struct net_device *netdev = pci_get_drvdata(pdev);
> + struct nic *nic = netdev_priv(netdev);
> +
> + /* ack any pending wake events, disable PME */
> + pci_enable_wake(pdev, 0, 0);
> +
> + netif_device_attach(netdev);
> + if(netif_running(netdev)) {
> + e100_open (netdev);
> + mod_timer(&nic->watchdog, jiffies);
e100_open calls e100_up which already sets watchdog timer. Why to set
it again?
> + }
> +}
> +
^ permalink raw reply
* [PATCH 6/6] tg3: Update version and reldate
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Update version to 3.57.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0779544..beeb612 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,8 +69,8 @@
#define DRV_MODULE_NAME "tg3"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "3.56"
-#define DRV_MODULE_RELDATE "Apr 1, 2006"
+#define DRV_MODULE_VERSION "3.57"
+#define DRV_MODULE_RELDATE "Apr 28, 2006"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
^ permalink raw reply related
* [PATCH 5/6] tg3: Fix bug in nvram write
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Fix bug in nvram write function. If the starting nvram address offset
happens to be the last dword of the page, the NVRAM_CMD_LAST bit will
not get set in the existing code. This patch fixes the bug by changing
the "else if" to "if" so that the last dword condition always gets
checked.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 97e27d8..0779544 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9404,7 +9404,7 @@ static int tg3_nvram_write_block_buffere
if ((page_off == 0) || (i == 0))
nvram_cmd |= NVRAM_CMD_FIRST;
- else if (page_off == (tp->nvram_pagesize - 4))
+ if (page_off == (tp->nvram_pagesize - 4))
nvram_cmd |= NVRAM_CMD_LAST;
if (i == (len - 4))
^ permalink raw reply related
* [PATCH 4/6] tg3: Add reset_phy parameter to chip reset functions
From: Michael Chan @ 2006-04-28 23:36 UTC (permalink / raw)
To: davem; +Cc: netdev
Add a reset_phy parameter to tg3_reset_hw() and tg3_init_hw(). With
the full chip reset during MAC address change, the automatic PHY reset
during chip reset will cause a link down and bonding will not work
properly as a result. With this reset_phy parameter, we can do a chip
reset without link down when changing MAC address or MTU.
Signed-off-by: Gary Zambrano <zambrano@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0ccfb63..97e27d8 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3544,7 +3544,7 @@ static irqreturn_t tg3_test_isr(int irq,
return IRQ_RETVAL(0);
}
-static int tg3_init_hw(struct tg3 *);
+static int tg3_init_hw(struct tg3 *, int);
static int tg3_halt(struct tg3 *, int, int);
#ifdef CONFIG_NET_POLL_CONTROLLER
@@ -3580,7 +3580,7 @@ static void tg3_reset_task(void *_data)
tp->tg3_flags2 &= ~TG3_FLG2_RESTART_TIMER;
tg3_halt(tp, RESET_KIND_SHUTDOWN, 0);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
@@ -4055,7 +4055,7 @@ static int tg3_change_mtu(struct net_dev
tg3_set_mtu(dev, tp, new_mtu);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 0);
tg3_netif_start(tp);
@@ -5740,7 +5740,7 @@ static int tg3_set_mac_addr(struct net_d
tg3_full_lock(tp, 1);
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 0);
tg3_netif_start(tp);
tg3_full_unlock(tp);
@@ -5798,7 +5798,7 @@ static void __tg3_set_coalesce(struct tg
}
/* tp->lock is held. */
-static int tg3_reset_hw(struct tg3 *tp)
+static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
{
u32 val, rdmac_mode;
int i, err, limit;
@@ -5813,7 +5813,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tg3_abort_hw(tp, 1);
}
- if (tp->tg3_flags2 & TG3_FLG2_MII_SERDES)
+ if ((tp->tg3_flags2 & TG3_FLG2_MII_SERDES) && reset_phy)
tg3_phy_reset(tp);
err = tg3_chip_reset(tp);
@@ -6354,7 +6354,7 @@ static int tg3_reset_hw(struct tg3 *tp)
tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl);
}
- err = tg3_setup_phy(tp, 1);
+ err = tg3_setup_phy(tp, reset_phy);
if (err)
return err;
@@ -6427,7 +6427,7 @@ static int tg3_reset_hw(struct tg3 *tp)
/* Called at device open time to get the chip ready for
* packet processing. Invoked with tp->lock held.
*/
-static int tg3_init_hw(struct tg3 *tp)
+static int tg3_init_hw(struct tg3 *tp, int reset_phy)
{
int err;
@@ -6440,7 +6440,7 @@ static int tg3_init_hw(struct tg3 *tp)
tw32(TG3PCI_MEM_WIN_BASE_ADDR, 0);
- err = tg3_reset_hw(tp);
+ err = tg3_reset_hw(tp, reset_phy);
out:
return err;
@@ -6710,7 +6710,7 @@ static int tg3_test_msi(struct tg3 *tp)
tg3_full_lock(tp, 1);
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- err = tg3_init_hw(tp);
+ err = tg3_init_hw(tp, 1);
tg3_full_unlock(tp);
@@ -6775,7 +6775,7 @@ static int tg3_open(struct net_device *d
tg3_full_lock(tp, 0);
- err = tg3_init_hw(tp);
+ err = tg3_init_hw(tp, 1);
if (err) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
tg3_free_rings(tp);
@@ -7866,7 +7866,7 @@ static int tg3_set_ringparam(struct net_
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -7911,7 +7911,7 @@ static int tg3_set_pauseparam(struct net
if (netif_running(dev)) {
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -8549,7 +8549,7 @@ static int tg3_test_loopback(struct tg3
if (!netif_running(tp->dev))
return TG3_LOOPBACK_FAILED;
- tg3_reset_hw(tp);
+ tg3_reset_hw(tp, 1);
if (tg3_run_loopback(tp, TG3_MAC_LOOPBACK))
err |= TG3_MAC_LOOPBACK_FAILED;
@@ -8623,7 +8623,7 @@ static void tg3_self_test(struct net_dev
tg3_halt(tp, RESET_KIND_SHUTDOWN, 1);
if (netif_running(dev)) {
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tg3_netif_start(tp);
}
@@ -11599,7 +11599,7 @@ static int tg3_suspend(struct pci_dev *p
tg3_full_lock(tp, 0);
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tp->timer.expires = jiffies + tp->timer_offset;
add_timer(&tp->timer);
@@ -11633,7 +11633,7 @@ static int tg3_resume(struct pci_dev *pd
tg3_full_lock(tp, 0);
tp->tg3_flags |= TG3_FLAG_INIT_COMPLETE;
- tg3_init_hw(tp);
+ tg3_init_hw(tp, 1);
tp->timer.expires = jiffies + tp->timer_offset;
add_timer(&tp->timer);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox