* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-02 17:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091102100702.GA16963-X9Un+BFzKDI@public.gmane.org>
On Mon, Nov 02, 2009 at 11:07:02AM +0100, Ingo Molnar wrote:
>
> * Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> > On Mon, 2009-11-02 at 10:10 +0100, Ingo Molnar wrote:
> >
> > > So i have read the thread you and Bartlomiej referenced:
> > >
> > > http://lkml.org/lkml/2009/10/17/81
> > >
> > > ... and my understanding of that discussion is very different from
> > > yours. Here is my annotated history of the beginnings of that
> > > discussion:
> >
> > [snip]
> >
> > You shouldn't ignore all previous interaction between Bart and us --
> > which wasn't pretty: http://thread.gmane.org/gmane.linux.kernel/901892
>
> I have seen that exchange too - here's the lkml.org link for those who
> like the lkml.org format:
>
> http://lkml.org/lkml/2009/10/13/186
>
> And i can see no supporting fact here either, for the (very serious)
> accusation launched by John Linville, that Bartlomiej is 'petty,
> whining, indignant'. In my reading he is the opposite of that, even in
> this second thread you point out.
Again, you seem to be very generous to Bartlomiej and very critical of
the rest of us in your readings.
> So, no matter how much you disagree about the code and its direction,
> please either back up your assertion with specific links to a pattern of
> misbehavior or apologize for the ad-hominen attacks against Bartlomiej.
His behavior is evident in the threads you cited. How you do not
see that is a mystery.
> > Of course we were biased when he came around with that petty code
> > duplication argument, since it seemed to support only his agenda of
> > working only with the staging drivers.
>
> Why do you think that disagreeing in the past gives you the right to get
> into ad-hominens? You should concentrate on the code and on the
> technical side, not on the person making the argument.
>
> Also, why do you characterise a code duplication argument as 'petty'?
Did you actually look at the thread? Or did you simply here "code
duplication" and run with it?
> Bloat and unnecessary technical forking is the #1 enemy of Linux.
> Integrating code and infrastructure is the #1 strength of Linux.
>
> Upstream subsystems/drivers running away with their private
> implementations has its clear costs:
...which has nothing to do with the case at hand. Please do not
perpetuate this myth. If anything, your argument applies far more
to the drivers in staging that Bartlomiej has focused his attention
upon until recently.
<snip>
> [ I dont know why drivers/staging/ is even an argument here - he argued
> about the technical qualities of a new upstream driver, not about a
> staging driver. Upstream drivers are to be held to higher standards,
> _especially_ now that we can isolate not-clean-enough-yet drivers into
> drivers/staging/, without hurting users. ]
If you had been keeping-up, you would realize that Bartlomiej is upset
about our criticisms of the Ralink drivers in staging. That would seem
to be the reason he has made himself such an irritant in linux-wireless
over the past few weeks.
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Connection tracking and vlan
From: Eric W. Biederman @ 2009-11-02 17:02 UTC (permalink / raw)
To: Patrick McHardy
Cc: Eric Dumazet, Adayadil Thomas, Ben Greear, Herbert Xu,
Linux Netdev List, Netfilter Development Mailinglist
In-Reply-To: <4AEF0D69.7070205@trash.net>
Patrick McHardy <kaber@trash.net> writes:
> Eric Dumazet wrote:
>> Patrick McHardy a écrit :
>>> But it would be preferrable if we could do this using network
>>> namespaces somehow.
>>
>> eg eth0.100 and eth0.101 on namespace 1, eth0.200 and eth0.201 on namespace 2 ?
>>
>> Can we do that with current kernel ? (different vlans on an unique physical device)
>
> By default the underlying device needs to exist in the same namespace
> in which the VLAN device is created. I believe it should be possible
> to move the VLAN device to a different namespace after creating it,
> but I'm not sure about that.
There should be no problem moving the vlan device after it is created.
Eric
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: Eric Dumazet @ 2009-11-02 17:04 UTC (permalink / raw)
To: William Allen Simpson; +Cc: Linux Kernel Network Developers, Ilpo Järvinen
In-Reply-To: <4AEF0603.7060502@gmail.com>
William Allen Simpson a écrit :
> It will be, when we have running code, as I'm loath to publish until I'm
> certain it *can* be implemented.
This is why RFC is better before coding. To avoid wasting time on experiments
that have a fatal flaw. Once included in an official kernel, we wont be able
to change some parameters very easily (think about 253 constant you use)
Or do you think only *you* can understand what's going on, and we should
just trust you ?
>
> I've something like 40 RFCs published over the years.
I believe I know who you are, Mr William Allen Simpson, you dont need to
repeat how much work you did in the past. This is a bit annoying.
Some patches need 6-12 months of polishing before inclusion, there is nothing
wrong about it. It only depends on your cooperation and patience.
And yes, even if a patch comes from Linus Torvald himself, I can talk if
it does not please me.
SYNFLOOD problem is more than 13 years old, I am quite surprised its becoming
so urgent we should accept your patches "as is".
May I suggest to switch to normal mode, ie you prepare a next round of
patches, you submit them, we review them, [repeat 0-N time(s)], we Ack them ?
^ permalink raw reply
* Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie
From: William Allen Simpson @ 2009-11-02 17:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Developers, Linux Kernel Network Developers
In-Reply-To: <4AEEDBBC.40800@gmail.com>
Eric Dumazet wrote:
> Large part of network code is run by softirq handler, and a softirq handler
> is not preemptable with another softirq (including itself).
>
Thank you. That's helpful to know, as some existing locks have a "bh".
I've never figured out the ip_local_deliver_finish() context.
Knowing that there can only be one instance of the tcp stack running at
any one time, and the cpu never changes even after being interrupted, will
make it much easier to code.
>> Perhaps a function header comment that mentions it?
>
> So we are going to add a header to thousand of functions repeating this prereq ?
>
That's my usual practice. (Dozens would be more accurate in this case.)
I've always found it helpful for those coming after me, and sure would have
found it helpful now myself.... Repetitious, but well worth it.
Especially at tcp_v4_rcv(), as that's called through a vector named
"handler", which was particularly hard to track down.
It has an innocuous header "From tcp_input.c", that doesn't seem to have
anything to do with current reality.... (It's really called from
ip_input.c via af_inet.c).
>> All I know is (from testing) that the tcp_minisockets.c caller is sometimes
>> called in a fashion that requires atomic allocation, and other times
>> does not!
>
> Maybe callers have different contexts (running from softirq handler or
> from process context). Atomic ops are expensive and we try to avoid them
> if/when possible.
>
>> See my "Subject: query: tcpdump versus atomic?" thread from Oct 14th.
>
> You probably add a bug in your kernel, leaving a function with unpaired lock/unlock
> of notallow_something/allow_something
>
(No, I've not yet added locks; obviously, I'm still asking about them.)
Unlikely, as it was easy to reproduce by changing one line, without *any* of
my code present. Usually works, but doesn't work with tcpdump running on
the interface:
struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb)
{
- struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC);
+ struct sock *newsk = inet_csk_clone(sk, req, GFP_KERNEL);
if (newsk != NULL) {
[ 2.876485] eth0: RealTek RTL8139 at 0x2000, 00:40:2b:6b:61:36, IRQ 17
[ 2.876490] eth0: Identified 8139 chip type 'RTL-8101'
[ 88.997594] device eth0 entered promiscuous mode
[ 114.827403] BUG: scheduling while atomic: swapper/0/0x10000100
[ 114.827462] Modules linked in: lp snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd ppdev iTCO_wdt iTCO_vendor_support psmouse soundcore parport_pc intel_agp parport agpgart pcspkr serio_raw shpchp snd_page_alloc 8139too aic7xxx 8139cp
scsi_transport_spi mii floppy
[ 114.827493]
[ 114.827497] Pid: 0, comm: swapper Not tainted (2.6.32-rc3 #4) Imperial
[ 114.827501] EIP: 0060:[<c0123295>] EFLAGS: 00000246 CPU: 0
[ 114.827512] EIP is at native_safe_halt+0x5/0x10
[ 114.827515] EAX: c0740000 EBX: 00000000 ECX: ffff4b6e EDX: 00000000
[ 114.827519] ESI: c07992c0 EDI: c0743000 EBP: c0741fa0 ESP: c0741fa0
[ 114.827522] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 114.827525] CR0: 8005003b CR2: 09278fc4 CR3: 04b56000 CR4: 00000690
[ 114.827529] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 114.827532] DR6: ffff0ff0 DR7: 00000400
[ 114.827535] Call Trace:
[ 114.827546] [<c01098b5>] default_idle+0x65/0x90
[ 114.827550] [<c0102062>] cpu_idle+0x52/0x90
[ 114.827558] [<c056cc23>] rest_init+0x53/0x60
[ 114.827565] [<c079c93d>] start_kernel+0x328/0x390
[ 114.827569] [<c079c3ce>] ? unknown_bootoption+0x0/0x1f6
[ 114.827574] [<c079c07e>] i386_start_kernel+0x7e/0xa8
[ 136.570632] device eth0 left promiscuous mode
> There are books about linux internals that you could read if you want some extra
> documentation. Dont ask me details, I never read them :)
>
Sorry, I've only read much of the Documentation directory (some parts
repeatedly), and Googled for more specific information. Pretty sparse!
Thank you again for your patient explanation.
^ permalink raw reply
* [PATCHv2] tun: export underlying socket
From: Michael S. Tsirkin @ 2009-11-02 17:20 UTC (permalink / raw)
To: David Miller, Eric Dumazet; +Cc: Paul Moore, netdev, herbert
In-Reply-To: <20090910125929.GA32593@redhat.com>
Tun device looks similar to a packet socket
in that both pass complete frames from/to userspace.
This patch fills in enough fields in the socket underlying tun driver
to support sendmsg/recvmsg operations, and message flags
MSG_TRUNC and MSG_DONTWAIT, and exports access to this socket
to modules. Regular read/write behaviour is unchanged.
This way, code using raw sockets to inject packets
into a physical device, can support injecting
packets into host network stack almost without modification.
First user of this interface will be vhost virtualization
accelerator.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Changes from v1:
addressed comments from review
This patch is on top of net-next master.
vhost which is the first user of this interface is intended to be merged
through Rusty's virtio tree, so I think it's easiest to merge this patch
trough that tree, as well, as part of the vhost patchset.
Makes sense? Please comment.
Usage example in vhost is here:
http://git.kernel.org/?p=linux/kernel/git/mst/vhost.git;a=commitdiff;h=030c5e25539e8fb14ca9130621710b7a006f3c1c
An alternative approach would be to make sendmsg work on tun fd from
userspace as well as from kernel: a uniform way to work with a network
device and the host stack might be useful there, as well. Kernel users
could then do sockfd_lookup to get the socket. I decided against it for
now as it requires more code and touches net core.
Please comment.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 4fdfa2a..18f8876 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -144,6 +144,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
err = 0;
tfile->tun = tun;
tun->tfile = tfile;
+ tun->socket.file = file;
dev_hold(tun->dev);
sock_hold(tun->socket.sk);
atomic_inc(&tfile->count);
@@ -158,6 +159,7 @@ static void __tun_detach(struct tun_struct *tun)
/* Detach from net device */
netif_tx_lock_bh(tun->dev);
tun->tfile = NULL;
+ tun->socket.file = NULL;
netif_tx_unlock_bh(tun->dev);
/* Drop read queue */
@@ -387,7 +389,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
/* Notify and wake up reader process */
if (tun->flags & TUN_FASYNC)
kill_fasync(&tun->fasync, SIGIO, POLL_IN);
- wake_up_interruptible(&tun->socket.wait);
+ wake_up_interruptible_poll(&tun->socket.wait, POLLIN |
+ POLLRDNORM | POLLRDBAND);
return NETDEV_TX_OK;
drop:
@@ -743,7 +746,7 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
len = min_t(int, skb->len, len);
skb_copy_datagram_const_iovec(skb, 0, iv, total, len);
- total += len;
+ total += skb->len;
tun->dev->stats.tx_packets++;
tun->dev->stats.tx_bytes += len;
@@ -751,34 +754,23 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
return total;
}
-static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
- unsigned long count, loff_t pos)
+static ssize_t tun_do_read(struct tun_struct *tun,
+ struct kiocb *iocb, const struct iovec *iv,
+ ssize_t len, int noblock)
{
- struct file *file = iocb->ki_filp;
- struct tun_file *tfile = file->private_data;
- struct tun_struct *tun = __tun_get(tfile);
DECLARE_WAITQUEUE(wait, current);
struct sk_buff *skb;
- ssize_t len, ret = 0;
-
- if (!tun)
- return -EBADFD;
+ ssize_t ret = 0;
DBG(KERN_INFO "%s: tun_chr_read\n", tun->dev->name);
- len = iov_length(iv, count);
- if (len < 0) {
- ret = -EINVAL;
- goto out;
- }
-
add_wait_queue(&tun->socket.wait, &wait);
while (len) {
current->state = TASK_INTERRUPTIBLE;
/* Read frames from the queue */
if (!(skb=skb_dequeue(&tun->socket.sk->sk_receive_queue))) {
- if (file->f_flags & O_NONBLOCK) {
+ if (noblock) {
ret = -EAGAIN;
break;
}
@@ -805,6 +797,27 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
current->state = TASK_RUNNING;
remove_wait_queue(&tun->socket.wait, &wait);
+ return ret;
+}
+
+static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
+ unsigned long count, loff_t pos)
+{
+ struct file *file = iocb->ki_filp;
+ struct tun_file *tfile = file->private_data;
+ struct tun_struct *tun = __tun_get(tfile);
+ ssize_t len, ret;
+
+ if (!tun)
+ return -EBADFD;
+ len = iov_length(iv, count);
+ if (len < 0) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = tun_do_read(tun, iocb, iv, len, file->f_flags & O_NONBLOCK);
+ ret = min_t(ssize_t, ret, len);
out:
tun_put(tun);
return ret;
@@ -847,7 +860,8 @@ static void tun_sock_write_space(struct sock *sk)
return;
if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
- wake_up_interruptible_sync(sk->sk_sleep);
+ wake_up_interruptible_sync_poll(sk->sk_sleep, POLLOUT |
+ POLLWRNORM | POLLWRBAND);
tun = container_of(sk, struct tun_sock, sk)->tun;
kill_fasync(&tun->fasync, SIGIO, POLL_OUT);
@@ -858,6 +872,37 @@ static void tun_sock_destruct(struct sock *sk)
free_netdev(container_of(sk, struct tun_sock, sk)->tun->dev);
}
+static int tun_sendmsg(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *m, size_t total_len)
+{
+ struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+ return tun_get_user(tun, m->msg_iov, total_len,
+ m->msg_flags & MSG_DONTWAIT);
+}
+
+static int tun_recvmsg(struct kiocb *iocb, struct socket *sock,
+ struct msghdr *m, size_t total_len,
+ int flags)
+{
+ struct tun_struct *tun = container_of(sock, struct tun_struct, socket);
+ int ret;
+ if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
+ return -EINVAL;
+ ret = tun_do_read(tun, iocb, m->msg_iov, total_len,
+ flags & MSG_DONTWAIT);
+ if (ret > total_len) {
+ m->msg_flags |= MSG_TRUNC;
+ ret = flags & MSG_TRUNC ? ret : total_len;
+ }
+ return ret;
+}
+
+/* Ops structure to mimic raw sockets with tun */
+static const struct proto_ops tun_socket_ops = {
+ .sendmsg = tun_sendmsg,
+ .recvmsg = tun_recvmsg,
+};
+
static struct proto tun_proto = {
.name = "tun",
.owner = THIS_MODULE,
@@ -986,6 +1031,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
goto err_free_dev;
init_waitqueue_head(&tun->socket.wait);
+ tun->socket.ops = &tun_socket_ops;
sock_init_data(&tun->socket, sk);
sk->sk_write_space = tun_sock_write_space;
sk->sk_sndbuf = INT_MAX;
@@ -1489,6 +1535,23 @@ static void tun_cleanup(void)
rtnl_link_unregister(&tun_link_ops);
}
+/* Get an underlying socket object from tun file. Returns error unless file is
+ * attached to a device. The returned object works like a packet socket, it
+ * can be used for sock_sendmsg/sock_recvmsg. The caller is responsible for
+ * holding a reference to the file for as long as the socket is in use. */
+struct socket *tun_get_socket(struct file *file)
+{
+ struct tun_struct *tun;
+ if (file->f_op != &tun_fops)
+ return ERR_PTR(-EINVAL);
+ tun = tun_get(file);
+ if (!tun)
+ return ERR_PTR(-EBADFD);
+ tun_put(tun);
+ return &tun->socket;
+}
+EXPORT_SYMBOL_GPL(tun_get_socket);
+
module_init(tun_init);
module_exit(tun_cleanup);
MODULE_DESCRIPTION(DRV_DESCRIPTION);
diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index 3f5fd52..404abe0 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -86,4 +86,18 @@ struct tun_filter {
__u8 addr[0][ETH_ALEN];
};
+#ifdef __KERNEL__
+#if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
+struct socket *tun_get_socket(struct file *);
+#else
+#include <linux/err.h>
+#include <linux/errno.h>
+struct file;
+struct socket;
+static inline struct socket *tun_get_socket(struct file *f)
+{
+ return ERR_PTR(-EINVAL);
+}
+#endif /* CONFIG_TUN */
+#endif /* __KERNEL__ */
#endif /* __IF_TUN_H */
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2009-10-28
From: Luis Correia @ 2009-11-02 17:32 UTC (permalink / raw)
To: John W. Linville
Cc: Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20091102170114.GE14046@tuxdriver.com>
[huge snip]
This is going to be my last reply to this thread (even if I get to be insulted).
I'm not a coder, I'm a tester and administrator for the rt2x00 project.
I'm not happy about the current state of the rt2x00 in-kernel drivers.
I tend to agree that more could be done.
Even though I'm not a coder, I could be hipotetically responsable for
the current situation. It is my job function to motivate people to
work on the rt2x00 in-kernel drivers, but apparently I've failed here.
It's not an atitude problem, as some have suggested, it's just life.
About Bartlomiej, there is only one more thing that I'll say:
I've searched on my GMail archives and the only patch Bart has
provided so far for the rt2x00 project is this:
[PATCH] MAINTAINERS: rt2x00 list is moderated
Which, while technically correct, adds nothing to the project.
So, I will personally continue to ignore Bart's comments, regards and
rants, until he provides patches for rt2x00 that actually make the
driver better.
Luis Correia
rt2x00 project admin,
(but not writing this email as an official project statement)
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Randy Dunlap @ 2009-11-02 17:36 UTC (permalink / raw)
To: Luis Correia
Cc: John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <efe7343f0911020932l21a570c8u9478568329d38e2c@mail.gmail.com>
Luis Correia wrote:
> [huge snip]
>
> This is going to be my last reply to this thread (even if I get to be insulted).
>
> I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> I'm not happy about the current state of the rt2x00 in-kernel drivers.
> I tend to agree that more could be done.
>
> Even though I'm not a coder, I could be hipotetically responsable for
> the current situation. It is my job function to motivate people to
> work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> It's not an atitude problem, as some have suggested, it's just life.
>
> About Bartlomiej, there is only one more thing that I'll say:
>
> I've searched on my GMail archives and the only patch Bart has
> provided so far for the rt2x00 project is this:
>
> [PATCH] MAINTAINERS: rt2x00 list is moderated
>
> Which, while technically correct, adds nothing to the project.
whatever. That patch still needs to be applied.
> So, I will personally continue to ignore Bart's comments, regards and
> rants, until he provides patches for rt2x00 that actually make the
> driver better.
>
> Luis Correia
> rt2x00 project admin,
> (but not writing this email as an official project statement)
--
~Randy
^ permalink raw reply
* Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie
From: Eric Dumazet @ 2009-11-02 17:42 UTC (permalink / raw)
To: William Allen Simpson
Cc: Linux Kernel Developers, Linux Kernel Network Developers
In-Reply-To: <4AEF1534.4090506@gmail.com>
William Allen Simpson a écrit :
> Eric Dumazet wrote:
>> Large part of network code is run by softirq handler, and a softirq
>> handler
>> is not preemptable with another softirq (including itself).
>>
> Thank you. That's helpful to know, as some existing locks have a "bh".
> I've never figured out the ip_local_deliver_finish() context.
>
> Knowing that there can only be one instance of the tcp stack running at
> any one time, and the cpu never changes even after being interrupted, will
> make it much easier to code.
Correction :
There is one instance of sofirq handler running per cpu.
So TCP (or UDP) stack can run simultaneously on several (and eventually all online) cpus.
This is why we still need some locks in various places.
>>
> (No, I've not yet added locks; obviously, I'm still asking about them.)
>
> Unlikely, as it was easy to reproduce by changing one line, without
> *any* of
> my code present. Usually works, but doesn't work with tcpdump running on
> the interface:
Yes, tcpdump has the nasty habit to consume a lot of ram, queuing a copy of
all network traffic on an af_packet socket. (or using a mmap buffer, it depends
on libpcap version you use)
>
> struct sock *tcp_create_openreq_child(struct sock *sk, struct
> request_sock *req, struct sk_buff *skb)
> {
> - struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC);
> + struct sock *newsk = inet_csk_clone(sk, req, GFP_KERNEL);
Here you want a GFP_KERNEL allocation, that is allowed to sleep if there is not
enough available memory. (It's allowed to sleep to let some processes to free
bit of ram, eventually)
But as the caller of tcp_create_openreq_child() runs from {soft}irq context,
its not allowed to sleep at all, even 10 usecs.
Therefore, linux kernel kindly warns you that's its illegal and deadlockable.
Dont change GFP_ATOMIC here, its really there for a valid reason.
And be prepared to get a NULL result from allocation.
If your machine has problems when running tcpdump, maybe it lacks some ram, maybe you could
tune tcpdump socket to not exhaust all LOWMEM.
I see your kernel is 32bits, so you have only 860 MB of kernel memory, called LOWMEM.
I believe last kernels might have some problems in OOM situations...
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-02 17:50 UTC (permalink / raw)
To: Joe Perches; +Cc: Eric Dumazet, Linux Kernel Network Developers
In-Reply-To: <1257181219.28925.13.camel@Joe-Laptop.home>
Joe Perches wrote:
> Linus wrote a long time back (5+ years):
>
> The reason for "if (x == 8)" comes from the way we're taught to think.
> Arguing against that _fact_ is just totally non-productive, and you have
> to _force_ yourself to write it the other way around.
>
Interesting. I've not been able to Google this quote.
I actually think as I write it, finding the other ragged and hard to
visually review. But apparently it's an issue for ESL or something,
taught to think in another way.
Therefore, I'll re-code as Linus has prescribed. Sadly, I'm having
very bad luck verifying coding examples by checking against the
installed base, as I found thousands of lines following more usual
secure coding practices....
Thank you.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 2/3] TCPCT part 1b: sysctl_tcp_cookie_size, socket option TCP_COOKIE_TRANSACTIONS, functions
From: William Allen Simpson @ 2009-11-02 17:54 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20091102.025150.73299764.davem@davemloft.net>
David Miller wrote:
> Yes, it is a problem.
>
> You can allocate the bit when you add the feature.
>
Sadly, I've been having very bad luck in my choice of code base, and
reviewing other similar code -- it seemed the common practice was to
specify the interface completely (even those bits not yet used).
I'll remove that line in the next pass.
^ permalink raw reply
* Re: [PATCH] cnic: ensure ulp_type is not negative
From: Michael Chan @ 2009-11-02 17:56 UTC (permalink / raw)
To: Roel Kluin; +Cc: netdev@vger.kernel.org, Andrew Morton, LKML, davem
In-Reply-To: <4AEF0E98.5050304@gmail.com>
On Mon, 2009-11-02 at 08:53 -0800, Roel Kluin wrote:
> `ulp_type' is signed, make sure it is not negative
> when we read the array element.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Looks good to me. Thanks.
Acked-by: Michael Chan <mchan@broadcom.com>
> ---
> drivers/net/cnic.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
> index 3bf1b04..f384b0a 100644
> --- a/drivers/net/cnic.c
> +++ b/drivers/net/cnic.c
> @@ -347,7 +347,7 @@ int cnic_register_driver(int ulp_type, struct cnic_ulp_ops *ulp_ops)
> {
> struct cnic_dev *dev;
>
> - if (ulp_type >= MAX_CNIC_ULP_TYPE) {
> + if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
> printk(KERN_ERR PFX "cnic_register_driver: Bad type %d\n",
> ulp_type);
> return -EINVAL;
> @@ -393,7 +393,7 @@ int cnic_unregister_driver(int ulp_type)
> struct cnic_ulp_ops *ulp_ops;
> int i = 0;
>
> - if (ulp_type >= MAX_CNIC_ULP_TYPE) {
> + if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
> printk(KERN_ERR PFX "cnic_unregister_driver: Bad type %d\n",
> ulp_type);
> return -EINVAL;
> @@ -449,7 +449,7 @@ static int cnic_register_device(struct cnic_dev *dev, int ulp_type,
> struct cnic_local *cp = dev->cnic_priv;
> struct cnic_ulp_ops *ulp_ops;
>
> - if (ulp_type >= MAX_CNIC_ULP_TYPE) {
> + if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
> printk(KERN_ERR PFX "cnic_register_device: Bad type %d\n",
> ulp_type);
> return -EINVAL;
> @@ -490,7 +490,7 @@ static int cnic_unregister_device(struct cnic_dev *dev, int ulp_type)
> struct cnic_local *cp = dev->cnic_priv;
> int i = 0;
>
> - if (ulp_type >= MAX_CNIC_ULP_TYPE) {
> + if (ulp_type < 0 || ulp_type >= MAX_CNIC_ULP_TYPE) {
> printk(KERN_ERR PFX "cnic_unregister_device: Bad type %d\n",
> ulp_type);
> return -EINVAL;
>
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-02 18:10 UTC (permalink / raw)
To: Linux Kernel Network Developers
Cc: Ilpo Järvinen, Eric Dumazet, Joe Perches
In-Reply-To: <4AE6E7C0.2050408@gmail.com>
Another style question:
+struct tcp_extend_values {
+ u8 cookie_bakery[TCP_COOKIE_MAX];
+ u8 cookie_plus;
+ u8 cookie_in_always:1,
+ cookie_out_never:1;
+};
+
+static inline struct tcp_extend_values *tcp_xv(const struct request_values *rvp)
+{
+ return (struct tcp_extend_values *)rvp;
+}
Some examples have "struct request_values" as the first element, others
don't. I started with it, and then removed it (as essentially nil).
Is there a preference?
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: Joe Perches @ 2009-11-02 18:16 UTC (permalink / raw)
To: William Allen Simpson
Cc: Linux Kernel Network Developers, Ilpo Järvinen, Eric Dumazet
In-Reply-To: <4AEF207C.9030002@gmail.com>
On Mon, 2009-11-02 at 13:10 -0500, William Allen Simpson wrote:
> Another style question:
>
> +struct tcp_extend_values {
> + u8 cookie_bakery[TCP_COOKIE_MAX];
> + u8 cookie_plus;
> + u8 cookie_in_always:1,
> + cookie_out_never:1;
> +};
> +
> +static inline struct tcp_extend_values *tcp_xv(const struct request_values *rvp)
> +{
> + return (struct tcp_extend_values *)rvp;
> +}
>
> Some examples have "struct request_values" as the first element, others
> don't. I started with it, and then removed it (as essentially nil).
>
> Is there a preference?
I don't know, but I do have a bias against casting
const to non-const.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] Multicast packet reassembly can fail
From: Steve Chen @ 2009-11-02 18:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: rick.jones2, mhuth, David Stevens, Eric Dumazet, netdev
In-Reply-To: <20091029180450.GA31044@gondor.apana.org.au>
On Thu, 2009-10-29 at 14:04 -0400, Herbert Xu wrote:
> Steve Chen <schen@mvista.com> wrote:
> >
> > of the interface that the application is expecting the packet. It
> > appears to bind on interface based on that casual observation. I'll
> > have to study the code in detail to be able to say for sure.
>
> Well if it does bind to the interface then that explains the
> failure. And the fix is "if it hurts, don't do it" :)
>
> Cheers,
The packet drop was tracked to rp_filter. All packets received as
expected after disabling rp_filter. Thank you all for the inputs.
Regards,
Steve
^ permalink raw reply
* Re: RFC: netdev: allow ethtool physical id to drop rtnl_lock
From: Ben Hutchings @ 2009-11-02 18:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, mchan, netdev
In-Reply-To: <20091102085121.7416fa8f@nehalam>
On Mon, 2009-11-02 at 08:51 -0800, Stephen Hemminger wrote:
[...]
> For compatibility, I was thinking of adding a new ethtool hook that
> moves the blinking loop into ethtool.
>
> static int ethtool_phys_blink(struct net_device *dev, u32 secs)
> {
> while (secs > 0) {
> dev->ethtool_ps->phys_led(dev, ETH_LED_ON);
> ...
> dev->ethtool_ps->phys_led(dev, ETH_LED_OFF);
> }
> dev->ethtool_ops->phys_led(dev, ETH_LED_NORMAL);
> }
[...]
We could even force this on unconverted drivers, but using a longer
loop period to allow for slow blinking:
static int ethtool_phys_id_loop(struct net_device *dev, u32 secs)
{
u32 timeout;
int rc;
for (;;) {
timeout = min_t(u32, secs, 5);
secs -= timeout;
rc = dev->ethtool_ops->phys_id(dev, timeout);
if (rc || secs == 0)
return rc;
...
}
}
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-02 18:29 UTC (permalink / raw)
To: Randy Dunlap
Cc: Luis Correia, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4AEF1894.2010809-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
On Mon, Nov 02, 2009 at 09:36:20AM -0800, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> >
> > This is going to be my last reply to this thread (even if I get to be insulted).
> >
> > I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> > I'm not happy about the current state of the rt2x00 in-kernel drivers.
> > I tend to agree that more could be done.
> >
> > Even though I'm not a coder, I could be hipotetically responsable for
> > the current situation. It is my job function to motivate people to
> > work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> > It's not an atitude problem, as some have suggested, it's just life.
> >
> > About Bartlomiej, there is only one more thing that I'll say:
> >
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
>
> whatever. That patch still needs to be applied.
And, in fact, it has been...already in linux-2.6:
commit b5654f5e7fc414a6e69b3647db2b043257c9e62e
Author: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon Oct 26 16:49:50 2009 -0700
MAINTAINERS: rt2x00 list is moderated
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Hth...
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Ivo van Doorn @ 2009-11-02 18:43 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4AEF1894.2010809-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
Well and then another rt2x00 developer discovered this nice little
fight about rt2x00 on the mailinglists...
First for the record, because at the start people where talking about the
maintainership of rt2x00, one thing needs to be straight:
As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
drivers/net/wireless/rt2x00 folder.
At this time I am hold the position within the rt2x00 team which is making the
decisions about the rt2x00 code and design.
I am also the one that is (N)Acks the patches from others when they are send
to the rt2x00-users or linux-wireless mailinglist.
As for my behavior in discussions:
I am doing my best to listen to all complains regarding the rt2x00 code and design and
improve it if the complainer has a valid point. However, obviously I can disagree with
the complainer and in that case I will explain to that person _why_ I disagree. It is up
to the complainer to convince me that he is right, agree with my response, or whine.
Now as for more specific responses:
On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> rt2800 drivers have their maintainers and I would like to know what they
> are doing besides complaining about users and staging tree..
Working for Avanade, Zarafa and as freelancer for Linux Magazine.
But I guess you mean rt2x00 specific work?
Well that list consists of:
- Listening to people complain
- Responding to those people, because otherwise they complain that they are being ignored.
- Following bug reports, and request testing or additional information if required
- Bugfixing
- Reviewing patches from contributors
- Applying patches from contributors
- Discussing improvements over patches from contributors
Well nothing of this list should be new to you, but apparently you needed some confirmation.
On Thursday 29 October 2009, Johannes Berg wrote:
> On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
>
> > In case you're concerned, I actually agree with John and others
> > on this issue, and disagree with your position.
>
> In this particular case, I think it makes more sense to duplicate the
> code _especially_ because it's not working yet. That frees people
> hacking on it of having to worry about breaking other devices.
Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
in the previous discussion.
On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..
Your code review comments were commented upon with my reasons
why this code duplication exists. I even admitted that when the time is
ready I will remove the code duplication.
On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
The review concerns regarding the duplicate code would only reduce the
amount of code. It would not magically fix bugs (at least the chance of that
would be quite small).
So far rt2800usb performs better then rt2800pci, and the difference gets
only bigger when I use the exact same register initialization from rt2800usb
in rt2800pci.
But Bartjmoiej knows that the register initialization can be exactly the same,
from his experience with the staging drivers.
So far hasn't been interested in sharing the knowledge in what must be
changed in rt2800pci/usb to make them both work with the same register
initialization.
On Monday 02 November 2009, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
>
> whatever. That patch still needs to be applied.
And I haven't seen anybody stating the opposite...
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] r8169: partial support and phy init for the 8168d
From: Ben Hutchings @ 2009-11-02 19:06 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev, edward_hsu
In-Reply-To: <20091101.224645.262714217.davem@davemloft.net>
On Sun, Nov 01, 2009 at 10:46:45PM -0800, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Sun, 01 Nov 2009 16:24:43 +0000
>
> > I believe this is patching machine code in the PHY. And we do not have
> > source for that code, so it cannot possibly be distributed under GPL.
>
> You don't know if it's machine code or some data values that
> are used to control the PHY's execution.
No, I don't know that this is machine code. But you are setting up
a false opposition: 'data values that are used to control the PHY's
execution' certainly include the machine code that it executes.
> In fact I would really be surprised if they had some cpu interpeting
> code in the 8168d PHY.
Your knowledge of PHYs may be outdated. 1000BASE-T has to be done
with a mixture of analog and digital signal processing, since analog
alone would be too power-hungry. While autonegotiation and power
management could be hardwired it's less risky to put in a micro-
controller and finalise the firmware after the silicon... or even
after release, as seems to have happened here.
> You did do some research about that before making such accusations
> right? :-)
I began with 'I believe'. It's not an accusation.
Ben.
--
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.
^ permalink raw reply
* Re: [PATCH net-next-2.6] Driver for the Microchip MCP251x SPI CAN controllers
From: Wolfgang Grandegger @ 2009-11-02 19:28 UTC (permalink / raw)
To: christian pellegrin
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cabda6420911020706r340ef073qea40527f09551a8a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
christian pellegrin wrote:
> On Sun, Nov 1, 2009 at 10:31 AM, Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org> wrote:
>> Hi Christian,
>>
>
> Hi,
>
>> there are a few. In general, please check the usage of {} for if
>
> sorry for missing this: I read your link below: I missed that rule on
> first reading! And I tend to trust checkpatch.pl too much ;-)
>
>> statements and check if "if (ret)" should be used instead of "if (ret <
>> 0)" if 0 means success and !0 failure. I don't have a MCP251x hardware
>
> ok, I misunderstood this to. Now I think it's ok.
>
> I'm replying to this thread with v2 patch. I'm rebasing the
> differences against SVN trunk too, but I'm waiting to send them until
> this patch is accepted in net-next-2.6 since their are only of
> cosmetic nature.
That's fine. of course.
[snip]
>>> +#include <linux/can/core.h>
>> I don't think you need "can/core.h"?
>>
>
> I tried without but there are some dependencies in "can/dev.h" to some
> netdev stuff that are broken if I omit it.
Hm, sounds like a bug. I will check a.s.a.p.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] can: Driver for the Microchip MCP251x SPI CAN controllers
From: Wolfgang Grandegger @ 2009-11-02 19:49 UTC (permalink / raw)
To: Christian Pellegrin
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1257175840-28528-1-git-send-email-chripell-VaTbYqLCNhc@public.gmane.org>
I assume this is v2 of the patch.
Christian Pellegrin wrote:
> Signed-off-by: Christian Pellegrin <chripell-VaTbYqLCNhc@public.gmane.org>
> ---
> drivers/net/can/Kconfig | 6 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/mcp251x.c | 1164 ++++++++++++++++++++++++++++++++++
> include/linux/can/platform/mcp251x.h | 36 +
> 4 files changed, 1207 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/can/mcp251x.c
> create mode 100644 include/linux/can/platform/mcp251x.h
>
[snip]
> diff --git a/drivers/net/can/mcp251x.c b/drivers/net/can/mcp251x.c
> new file mode 100644
> index 0000000..9471bb7
> --- /dev/null
> +++ b/drivers/net/can/mcp251x.c
[snip]
> +static void mcp251x_hw_tx(struct spi_device *spi, struct can_frame *frame,
> + int tx_buf_idx)
> +{
> + u32 sid, eid, exide, rtr;
> + u8 buf[SPI_TRANSFER_BUF_LEN];
> +
> + exide = (frame->can_id & CAN_EFF_FLAG) ? 1 : 0; /* Extended ID Enable */
> + if (exide)
> + sid = (frame->can_id & CAN_EFF_MASK) >> 18;
> + else
> + sid = frame->can_id & CAN_SFF_MASK; /* Standard ID */
> + eid = frame->can_id & CAN_EFF_MASK; /* Extended ID */
> + rtr = (frame->can_id & CAN_RTR_FLAG) ? 1 : 0; /* Remote transmission */
> +
> + buf[TXBCTRL_OFF] = INSTRUCTION_LOAD_TXB(tx_buf_idx);
> + buf[TXBSIDH_OFF] = sid >> SIDH_SHIFT;
> + buf[TXBSIDL_OFF] = ((sid & SIDL_SID_MASK) << SIDL_SID_SHIFT) |
> + (exide << SIDL_EXIDE_SHIFT) |
> + ((eid >> SIDL_EID_SHIFT) & SIDL_EID_MASK);
> + buf[TXBEID8_OFF] = GET_BYTE(eid, 1);
> + buf[TXBEID0_OFF] = GET_BYTE(eid, 0);
> + buf[TXBDLC_OFF] = (rtr << DLC_RTR_SHIFT) | frame->can_dlc;
Two spaces before "=".
> + memcpy(buf + TXBDAT_OFF, frame->data, frame->can_dlc);
> + mcp251x_hw_tx_frame(spi, buf, frame->can_dlc, tx_buf_idx);
> + mcp251x_write_reg(spi, TXBCTRL(tx_buf_idx), TXBCTRL_TXREQ);
> +}
> +
[snip]
> +static int mcp251x_open(struct net_device *net)
> +{
> + struct mcp251x_priv *priv = netdev_priv(net);
> + struct spi_device *spi = priv->spi;
> + struct mcp251x_platform_data *pdata = spi->dev.platform_data;
> + int ret;
> +
> + if (pdata->transceiver_enable)
> + pdata->transceiver_enable(1);
> +
> + priv->force_quit = 0;
> + priv->tx_skb = NULL;
> + priv->tx_len = 0;
> +
> + ret = request_irq(spi->irq, mcp251x_can_isr,
> + IRQF_TRIGGER_FALLING, DEVICE_NAME, net);
> + if (ret) {
> + dev_err(&spi->dev, "failed to acquire irq %d\n", spi->irq);
> + return ret;
> + }
Here the transceiver should be switched off!?
> + mcp251x_hw_wakeup(spi);
> + mcp251x_hw_reset(spi);
> + ret = mcp251x_setup(net, priv, spi);
> + if (ret) {
> + free_irq(spi->irq, net);
> + if (pdata->transceiver_enable)
> + pdata->transceiver_enable(0);
> + return ret;
> + }
> + mcp251x_set_normal_mode(spi);
> + netif_wake_queue(net);
> +
> + return 0;
> +}
> +
[snip]
> +static void mcp251x_irq_work_handler(struct work_struct *ws)
> +{
> + struct mcp251x_priv *priv = container_of(ws, struct mcp251x_priv,
> + irq_work);
> + struct spi_device *spi = priv->spi;
> + struct net_device *net = priv->net;
> + u8 txbnctrl;
> + u8 intf;
> + enum can_state new_state;
> +
> + if (priv->after_suspend) {
> + mdelay(10);
> + mcp251x_hw_reset(spi);
> + mcp251x_setup(net, priv, spi);
> + if (priv->after_suspend & AFTER_SUSPEND_RESTART) {
> + mcp251x_set_normal_mode(spi);
> + } else if (priv->after_suspend & AFTER_SUSPEND_UP) {
> + netif_device_attach(net);
> + /* Clean since we lost tx buffer */
> + if (priv->tx_skb || priv->tx_len) {
> + mcp251x_clean(net);
> + netif_wake_queue(net);
> + }
> + mcp251x_set_normal_mode(spi);
> + } else {
> + mcp251x_hw_sleep(spi);
> + }
> + priv->after_suspend = 0;
> + }
> +
> + if (priv->can.restart_ms == 0 && priv->can.state == CAN_STATE_BUS_OFF) {
> + while (!priv->force_quit && !freezing(current) &&
> + (intf = mcp251x_read_reg(spi, CANINTF)))
> + mcp251x_write_bits(spi, CANINTF, intf, 0x00);
Assigning variables within if or while expressions is not allowed. I
wonder why checkpatch did not spot it.
> + return;
> + }
> +
> + while (!priv->force_quit && !freezing(current)) {
> + u8 eflag = mcp251x_read_reg(spi, EFLG);
> + int can_id = 0, data1 = 0;
> +
> + mcp251x_write_reg(spi, EFLG, 0x00);
> +
> + if (priv->restart_tx) {
> + priv->restart_tx = 0;
> + mcp251x_write_reg(spi, TXBCTRL(0), 0);
> + if (priv->tx_skb || priv->tx_len)
> + mcp251x_clean(net);
> + netif_wake_queue(net);
> + can_id |= CAN_ERR_RESTARTED;
> + }
> +
> + if (priv->wake) {
> + /* Wait whilst the device wakes up */
> + mdelay(10);
> + priv->wake = 0;
> + }
> +
> + intf = mcp251x_read_reg(spi, CANINTF);
> + mcp251x_write_bits(spi, CANINTF, intf, 0x00);
> +
> + /* Update can state */
> + if (eflag & EFLG_TXBO) {
> + new_state = CAN_STATE_BUS_OFF;
> + can_id |= CAN_ERR_BUSOFF;
> + } else if (eflag & EFLG_TXEP) {
> + new_state = CAN_STATE_ERROR_PASSIVE;
> + can_id |= CAN_ERR_CRTL;
> + data1 |= CAN_ERR_CRTL_TX_PASSIVE;
> + } else if (eflag & EFLG_RXEP) {
> + new_state = CAN_STATE_ERROR_PASSIVE;
> + can_id |= CAN_ERR_CRTL;
> + data1 |= CAN_ERR_CRTL_RX_PASSIVE;
> + } else if (eflag & EFLG_TXWAR) {
> + new_state = CAN_STATE_ERROR_WARNING;
> + can_id |= CAN_ERR_CRTL;
> + data1 |= CAN_ERR_CRTL_TX_WARNING;
> + } else if (eflag & EFLG_RXWAR) {
> + new_state = CAN_STATE_ERROR_WARNING;
> + can_id |= CAN_ERR_CRTL;
> + data1 |= CAN_ERR_CRTL_RX_WARNING;
> + } else {
> + new_state = CAN_STATE_ERROR_ACTIVE;
> + }
> +
> + /* Update can state statistics */
> + switch (priv->can.state) {
> + case CAN_STATE_ERROR_ACTIVE:
> + if (new_state >= CAN_STATE_ERROR_WARNING &&
> + new_state <= CAN_STATE_BUS_OFF)
> + priv->can.can_stats.error_warning++;
> + case CAN_STATE_ERROR_WARNING: /* fallthrough */
> + if (new_state >= CAN_STATE_ERROR_PASSIVE &&
> + new_state <= CAN_STATE_BUS_OFF)
> + priv->can.can_stats.error_passive++;
> + break;
> + default:
> + break;
> + }
> + priv->can.state = new_state;
> +
> + if ((intf & CANINTF_ERRIF) || (can_id & CAN_ERR_RESTARTED)) {
> + struct sk_buff *skb;
> + struct can_frame *frame;
> +
> + /* Create error frame */
> + skb = alloc_can_err_skb(net, &frame);
> + if (skb) {
> + /* Set error frame flags based on bus state */
> + frame->can_id = can_id;
> + frame->data[1] = data1;
> +
> + /* Update net stats for overflows */
> + if (eflag & (EFLG_RX0OVR | EFLG_RX1OVR)) {
> + if (eflag & EFLG_RX0OVR)
> + net->stats.rx_over_errors++;
> + if (eflag & EFLG_RX1OVR)
> + net->stats.rx_over_errors++;
> + frame->can_id |= CAN_ERR_CRTL;
> + frame->data[1] |=
> + CAN_ERR_CRTL_RX_OVERFLOW;
> + }
> +
> + netif_rx(skb);
> + } else {
> + dev_info(&spi->dev,
> + "cannot allocate error skb\n");
> + }
> + }
> +
> + if (priv->can.state == CAN_STATE_BUS_OFF) {
> + if (priv->can.restart_ms == 0) {
> + can_bus_off(net);
> + mcp251x_hw_sleep(spi);
> + return;
> + }
> + }
> +
> + if (intf == 0)
> + break;
> +
> + if (intf & CANINTF_WAKIF)
> + complete(&priv->awake);
> +
> + if (intf & CANINTF_MERRF) {
> + /* If there are pending Tx buffers, restart queue */
> + txbnctrl = mcp251x_read_reg(spi, TXBCTRL(0));
> + if (!(txbnctrl & TXBCTRL_TXREQ)) {
> + if (priv->tx_skb || priv->tx_len)
> + mcp251x_clean(net);
> + netif_wake_queue(net);
> + }
> + }
> +
> + if (intf & (CANINTF_TX2IF | CANINTF_TX1IF | CANINTF_TX0IF)) {
> + net->stats.tx_packets++;
> + net->stats.tx_bytes += priv->tx_len - 1;
> + if (priv->tx_len) {
> + can_get_echo_skb(net, 0);
> + priv->tx_len = 0;
> + }
> + netif_wake_queue(net);
> + }
> +
> + if (intf & CANINTF_RX0IF)
> + mcp251x_hw_rx(spi, 0);
> +
> + if (intf & CANINTF_RX1IF)
> + mcp251x_hw_rx(spi, 1);
> + }
> +}
> +
> +static const struct net_device_ops mcp251x_netdev_ops = {
> + .ndo_open = mcp251x_open,
> + .ndo_stop = mcp251x_stop,
> + .ndo_start_xmit = mcp251x_hard_start_xmit,
> +};
> +
> +static int __devinit mcp251x_can_probe(struct spi_device *spi)
> +{
> + struct net_device *net;
> + struct mcp251x_priv *priv;
> + struct mcp251x_platform_data *pdata = spi->dev.platform_data;
> + int ret = -ENODEV;
> +
> + if (!pdata)
> + /* Platform data is required for osc freq */
> + goto error_out;
> +
> + /* Allocate can/net device */
> + net = alloc_candev(sizeof(struct mcp251x_priv), TX_ECHO_SKB_MAX);
> + if (!net) {
> + ret = -ENOMEM;
> + goto error_alloc;
> + }
> +
> + net->netdev_ops = &mcp251x_netdev_ops;
> + net->flags |= IFF_ECHO;
Remove spaces, please.
> + priv = netdev_priv(net);
> + priv->can.bittiming_const = &mcp251x_bittiming_const;
> + priv->can.do_set_mode = mcp251x_do_set_mode;
> + priv->can.clock.freq = pdata->oscillator_frequency / 2;
> + priv->can.do_set_bittiming = mcp251x_do_set_bittiming;
> + priv->net = net;
> + dev_set_drvdata(&spi->dev, priv);
> +
> + priv->spi = spi;
> + mutex_init(&priv->spi_lock);
> +
> + /* If requested, allocate DMA buffers */
> + if (mcp251x_enable_dma) {
> + spi->dev.coherent_dma_mask = ~0;
> +
> + /*
> + * Minimum coherent DMA allocation is PAGE_SIZE, so allocate
> + * that much and share it between Tx and Rx DMA buffers.
> + */
> + priv->spi_tx_buf = dma_alloc_coherent(&spi->dev,
> + PAGE_SIZE,
> + &priv->spi_tx_dma,
> + GFP_DMA);
> +
> + if (priv->spi_tx_buf) {
> + priv->spi_rx_buf = (u8 *)(priv->spi_tx_buf +
> + (PAGE_SIZE / 2));
> + priv->spi_rx_dma = (dma_addr_t)(priv->spi_tx_dma +
> + (PAGE_SIZE / 2));
> + } else {
> + /* Fall back to non-DMA */
> + mcp251x_enable_dma = 0;
> + }
> + }
> +
> + /* Allocate non-DMA buffers */
> + if (!mcp251x_enable_dma) {
> + priv->spi_tx_buf = kmalloc(SPI_TRANSFER_BUF_LEN, GFP_KERNEL);
> + if (!priv->spi_tx_buf) {
> + ret = -ENOMEM;
> + goto error_tx_buf;
> + }
> + priv->spi_rx_buf = kmalloc(SPI_TRANSFER_BUF_LEN, GFP_KERNEL);
> + if (!priv->spi_tx_buf) {
> + ret = -ENOMEM;
> + goto error_rx_buf;
> + }
> + }
> +
> + if (pdata->power_enable)
> + pdata->power_enable(1);
> +
> + /* Call out to platform specific setup */
> + if (pdata->board_specific_setup)
> + pdata->board_specific_setup(spi);
> +
> + SET_NETDEV_DEV(net, &spi->dev);
> +
> + priv->wq = create_freezeable_workqueue("mcp251x_wq");
> +
> + INIT_WORK(&priv->tx_work, mcp251x_tx_work_handler);
> + INIT_WORK(&priv->irq_work, mcp251x_irq_work_handler);
> +
> + init_completion(&priv->awake);
> +
> + /* Configure the SPI bus */
> + spi->mode = SPI_MODE_0;
> + spi->bits_per_word = 8;
> + spi_setup(spi);
> +
> + if (!mcp251x_hw_probe(spi)) {
> + dev_info(&spi->dev, "Probe failed\n");
> + goto error_probe;
> + }
> + mcp251x_hw_sleep(spi);
> +
> + if (pdata->transceiver_enable)
> + pdata->transceiver_enable(0);
> +
> + ret = register_candev(net);
> + if (ret >= 0) {
if (!ret) ?
> + dev_info(&spi->dev, "probed\n");
> + return ret;
> + }
Shouldn't the power be switched off?
> +error_probe:
> + if (!mcp251x_enable_dma)
> + kfree(priv->spi_rx_buf);
> +error_rx_buf:
> + if (!mcp251x_enable_dma)
> + kfree(priv->spi_tx_buf);
> +error_tx_buf:
> + free_candev(net);
> + if (mcp251x_enable_dma)
> + dma_free_coherent(&spi->dev, PAGE_SIZE,
> + priv->spi_tx_buf, priv->spi_tx_dma);
> +error_alloc:
> + dev_err(&spi->dev, "probe failed\n");
> +error_out:
> + return ret;
> +}
> +
[snip]
We are close...
Wolfgang.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-02 20:15 UTC (permalink / raw)
To: Joe Perches
Cc: Linux Kernel Network Developers, Ilpo Järvinen, Eric Dumazet
In-Reply-To: <1257185798.28925.33.camel@Joe-Laptop.home>
Joe Perches wrote:
> On Mon, 2009-11-02 at 13:10 -0500, William Allen Simpson wrote:
>> +static inline struct tcp_extend_values *tcp_xv(const struct request_values *rvp)
>> +{
>> + return (struct tcp_extend_values *)rvp;
>> +}
>>...
> I don't know, but I do have a bias against casting
> const to non-const.
>
Oh dear. That's how everything in both include/linux/tcp.h and
include/net/tcp.h is done.... As I said, we've had really bad luck
using examples from the existing code base.
If somebody else submitted a patch to change all the rest, I'd be
content to follow along.
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Mel Gorman @ 2009-11-02 20:30 UTC (permalink / raw)
To: Karol Lewandowski
Cc: Frans Pop, Jiri Kosina, Sven Geggus, Tobias Oetiker,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
In-Reply-To: <20091030142350.GA9343-nLtalAL5mPp2RxbNQum0x1nzlInOXLuq@public.gmane.org>
On Fri, Oct 30, 2009 at 03:23:50PM +0100, Karol Lewandowski wrote:
> On Wed, Oct 28, 2009 at 11:59:26AM +0000, Mel Gorman wrote:
> > On Wed, Oct 28, 2009 at 12:42:08PM +0100, Karol Lewandowski wrote:
> > > On Sat, Oct 24, 2009 at 02:46:56PM +0100, Mel LKML wrote:
> > > I've tested patches 1+2+3+4 in my normal usage scenario (do some work,
> > > suspend, do work, suspend, ...) and it failed today after 4 days (== 4
> > > suspend-resume cycles).
> > >
> > > I'll test 1-5 now.
>
> 2.6.32-rc5 with patches 1-5 fails too.
>
>
> > Also, what was the behaviour of the e100 driver when suspending before
> > this commit?
> >
> > 6905b1f1a03a48dcf115a2927f7b87dba8d5e566: Net / e100: Fix suspend of devices that cannot be power managed
>
> This was discussed before with e100 maintainers and Rafael. Reverting
> this patch didn't change anything.
>
Does applying the following on top make any difference?
==== CUT HERE ====
PM: Shrink memory before suspend
This is a partial revert of c6f37f12197ac3bd2e5a35f2f0e195ae63d437de. It
is an outside possibility for fixing the e100 bug where an order-5
allocation is failing during resume. The commit notes that the shrinking
of memory should be unnecessary but maybe it is in error.
Signed-off-by: Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 6f10dfc..4f6ae64 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -23,6 +23,9 @@ const char *const pm_states[PM_SUSPEND_MAX] = {
[PM_SUSPEND_MEM] = "mem",
};
+/* This is just an arbitrary number */
+#define FREE_PAGE_NUMBER (100)
+
static struct platform_suspend_ops *suspend_ops;
/**
@@ -78,6 +81,7 @@ static int suspend_test(int level)
static int suspend_prepare(void)
{
int error;
+ unsigned int free_pages;
if (!suspend_ops || !suspend_ops->enter)
return -EPERM;
@@ -92,10 +96,24 @@ static int suspend_prepare(void)
if (error)
goto Finish;
- error = suspend_freeze_processes();
+ if (suspend_freeze_processes()) {
+ error = -EAGAIN;
+ goto Thaw;
+ }
+
+ free_pages = global_page_state(NR_FREE_PAGES);
+ if (free_pages < FREE_PAGE_NUMBER) {
+ pr_debug("PM: free some memory\n");
+ shrink_all_memory(FREE_PAGE_NUMBER - free_pages);
+ if (nr_free_pages() < FREE_PAGE_NUMBER) {
+ error = -ENOMEM;
+ printk(KERN_ERR "PM: No enough memory\n");
+ }
+ }
if (!error)
return 0;
+ Thaw:
suspend_thaw_processes();
usermodehelper_enable();
Finish:
^ permalink raw reply related
* Re: [net-next-2.6 PATCH v4 3/3] TCPCT part 1c: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-02 20:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers, Ilpo Järvinen
In-Reply-To: <4AEF1106.40403@gmail.com>
Eric Dumazet wrote:
> William Allen Simpson a écrit :
>
>> It will be, when we have running code, as I'm loath to publish until I'm
>> certain it *can* be implemented.
>
> This is why RFC is better before coding. To avoid wasting time on experiments
> that have a fatal flaw. Once included in an official kernel, we wont be able
> to change some parameters very easily (think about 253 constant you use)
>
We are talking at cross purposes. IEEE had/has a tendency to publish
without running code. CTIA/TIA/EIA has interim standards without running
code, and had/has rules against even speaking about implementations. Only
IETF expected/expects running code. An RFC is rarely issued before coding.
http://www.iana.org/assignments/tcp-parameters/
253 N RFC3692-style Experiment 1 (*) [RFC4727]
When my code is done, I'll post the completed draft and ask IANA for a
non-experimental number. That's the usual process. My code shouldn't go
into an official release until we know that number.
PS. Rumor has it that Cisco shipped a release with 254 in it. Let's not
do that here.
PPS. Adam used 255, not a correct official experimental number.
^ permalink raw reply
* Re: wanPMC-CxT1E1
From: Bob Beers @ 2009-11-02 20:41 UTC (permalink / raw)
To: netdev; +Cc: Greg KH, Krzysztof Halasa
In-Reply-To: <m3d4454phz.fsf@intrepid.localdomain>
On Thu, Oct 29, 2009 at 8:52 PM, Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Bob Beers <bob.beers@gmail.com> writes:
>
>> ok, so where do I start, I have a system ready to start
>> git cloning, and creating patches. I googled for a while
>> but didn't find a nice recipe for participating in the -staging
>> process.
>
> I gave it a try. At least compiles with few warnings. Not sure about the
> WORK_INIT() change.
>
> Created drivers/net/wan/cxt1e1, moved all relevant SBE's .c and .h
> there, added a simple Makefile/Kconfig. Quick and dirty. There is a
> _lot_ of work to be done before it meets the usual kernel standards.
>
> It's not in staging/ so the paths need to be corrected but I can't work
> further on it at this time. Hand-edited but I tried to be careful.
>
<snip Krzysztof's diff file>
Ok, I took a shot at it too, It compiles for me and generates the
cxt1e1.ko file.
I have made a git clone of kernel, added the directory cxt1e1 under staging,
added a Kconfig, Makefile, and all the *.[ch] from the tarball's driver/ and
include/ directories, called git add on cxt1e1 directory and the files
mentioned above. In the cxt1e1 directory I modified the *.[ch] files as I saw
fit, and using many hints from Krzysztof
(I'm also not sure about the changes to INIT_WORK).
I modified Makefile in staging/ and ran 'git -a commit'.
Here is top part of output from 'git log --stat':
commit d54e08030785153c8c0f4eb4f1cf320d60fff286
Author: Bob Beers <bob.beers@gmail.com>
Date: Mon Nov 2 15:06:19 2009 -0500
Add CXT1E1 [1,2,4] channel wan card driver.
drivers/net/wan/Makefile | 1 +
drivers/staging/Kconfig | 2 +
drivers/staging/Makefile | 1 +
drivers/staging/cxt1e1/Kconfig | 22 +
drivers/staging/cxt1e1/Makefile | 20 +
drivers/staging/cxt1e1/comet.c | 566 +++++++
drivers/staging/cxt1e1/comet.h | 366 +++++
drivers/staging/cxt1e1/comet_tables.c | 561 +++++++
drivers/staging/cxt1e1/comet_tables.h | 85 +
drivers/staging/cxt1e1/functions.c | 366 +++++
drivers/staging/cxt1e1/hwprobe.c | 400 +++++
drivers/staging/cxt1e1/libsbew.h | 581 +++++++
drivers/staging/cxt1e1/linux.c | 1354 ++++++++++++++++
drivers/staging/cxt1e1/musycc.c | 2180 ++++++++++++++++++++++++++
drivers/staging/cxt1e1/musycc.h | 460 ++++++
drivers/staging/cxt1e1/ossiRelease.c | 39 +
drivers/staging/cxt1e1/pmc93x6_eeprom.c | 559 +++++++
drivers/staging/cxt1e1/pmc93x6_eeprom.h | 60 +
drivers/staging/cxt1e1/pmcc4.h | 155 ++
drivers/staging/cxt1e1/pmcc4_cpld.h | 124 ++
drivers/staging/cxt1e1/pmcc4_defs.h | 82 +
drivers/staging/cxt1e1/pmcc4_drv.c | 1855 ++++++++++++++++++++++
drivers/staging/cxt1e1/pmcc4_ioctls.h | 81 +
drivers/staging/cxt1e1/pmcc4_private.h | 295 ++++
drivers/staging/cxt1e1/pmcc4_sysdep.h | 62 +
drivers/staging/cxt1e1/sbe_bid.h | 61 +
drivers/staging/cxt1e1/sbe_promformat.h | 157 ++
drivers/staging/cxt1e1/sbecom_inline_linux.h | 310 ++++
drivers/staging/cxt1e1/sbecrc.c | 137 ++
drivers/staging/cxt1e1/sbeid.c | 217 +++
drivers/staging/cxt1e1/sbeproc.c | 358 +++++
drivers/staging/cxt1e1/sbeproc.h | 52 +
drivers/staging/cxt1e1/sbew_ioc.h | 136 ++
33 files changed, 11705 insertions(+), 0 deletions(-)
How do I generate the patch file?
thanks,
--
-Bob Beers
^ permalink raw reply
* [PATCH] trivial: remove duplicated MIN macro from tehuti.
From: Thiago Farina @ 2009-11-02 20:45 UTC (permalink / raw)
To: trivial
Cc: baum, andy, davem, shemminger, apkm, ben, yanghy, netdev,
linux-kernel, Thiago Farina
Since the kernel api already has the macro "min",
just use it instead of declaring another one.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
drivers/net/tehuti.c | 4 ++--
drivers/net/tehuti.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tehuti.c b/drivers/net/tehuti.c
index ec9dfb2..8d116a9 100644
--- a/drivers/net/tehuti.c
+++ b/drivers/net/tehuti.c
@@ -1878,7 +1878,7 @@ static void bdx_tx_push_desc_safe(struct bdx_priv *priv, void *data, int size)
udelay(50); /* give hw a chance to clean fifo */
continue;
}
- avail = MIN(avail, size);
+ avail = min(avail, size);
DBG("about to push %d bytes starting %p size %d\n", avail,
data, size);
bdx_tx_push_desc(priv, data, avail);
@@ -1889,7 +1889,7 @@ static void bdx_tx_push_desc_safe(struct bdx_priv *priv, void *data, int size)
}
static const struct net_device_ops bdx_netdev_ops = {
- .ndo_open = bdx_open,
+ .ndo_open = bdx_open,
.ndo_stop = bdx_close,
.ndo_start_xmit = bdx_tx_transmit,
.ndo_validate_addr = eth_validate_addr,
diff --git a/drivers/net/tehuti.h b/drivers/net/tehuti.h
index 4fc875e..1241419 100644
--- a/drivers/net/tehuti.h
+++ b/drivers/net/tehuti.h
@@ -76,8 +76,6 @@
#define FIFO_SIZE 4096
#define FIFO_EXTRA_SPACE 1024
-#define MIN(x, y) ((x) < (y) ? (x) : (y))
-
#if BITS_PER_LONG == 64
# define H32_64(x) (u32) ((u64)(x) >> 32)
# define L32_64(x) (u32) ((u64)(x) & 0xffffffff)
--
1.6.5.1.61.ge79999
^ 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