* Re: fanotify as syscalls
From: Andreas Gruenbacher @ 2009-09-22 21:38 UTC (permalink / raw)
To: Eric Paris
Cc: Jamie Lokier, Linus Torvalds, Evgeniy Polyakov, David Miller,
linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <1253653576.2747.27.camel@dhcp231-106.rdu.redhat.com>
On Tuesday, 22 September 2009 23:06:16 Eric Paris wrote:
> this is true, if there is only one namespace subtree notification works
> the same as global notification.
>
> [...]
>
> I don't see how subtree notification can possibly solve the global
> notification problem.
I'm thinking of is something like this: A listener registers interest in "/",
recursively. The kernel sets a FSNOTIFY_WATCH_RECURSIVE flag on "/" and each
mount point below. Afterwards when something is mounted anywhere, same
namespace or not, the kernel sets the new mount's FSNOTIFY_WATCH_RECURSIVE
flag if the parent mount has this flag set.
(Of course we need per fsnotify_group flags and not global ones, but this
doesn't change the principle.)
Andreas
^ permalink raw reply
* Re: [patch 1/6] isdn: hisax, fix lock imbalance
From: David Miller @ 2009-09-22 21:34 UTC (permalink / raw)
To: akpm; +Cc: isdn, netdev, jirislaby, Karsten-Keil
In-Reply-To: <200909181953.n8IJr1Wl026154@imap1.linux-foundation.org>
I'm hoping Karsten will pick these up.
But I'm not optimistic as I've been waiting weeks for some
other ISDN fixes to get looked at :-/
^ permalink raw reply
* Re: tun: Return -EINVAL if neither IFF_TUN nor IFF_TAP is set.
From: David Miller @ 2009-09-22 21:26 UTC (permalink / raw)
To: paul.moore; +Cc: slash, netdev, linux-kernel
In-Reply-To: <200909180754.05817.paul.moore@hp.com>
From: Paul Moore <paul.moore@hp.com>
Date: Fri, 18 Sep 2009 07:54:05 -0400
> On Thursday 17 September 2009 03:36:13 am Kusanagi Kouichi wrote:
>> After commit 2b980dbd77d229eb60588802162c9659726b11f4
>> ("lsm: Add hooks to the TUN driver") tun_set_iff doesn't
>> return -EINVAL though neither IFF_TUN nor IFF_TAP is set.
>>
>> Signed-off-by: Kusanagi Kouichi <slash@ma.neweb.ne.jp>
>
> Sorry about that, my mistake, thanks for finding and fixing this.
>
> Reviewed-by: Paul Moore <paul.moore@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH] 8139cp: fix duplicate loglevel in module load message
From: David Miller @ 2009-09-22 21:25 UTC (permalink / raw)
To: alan-jenkins; +Cc: netdev, linux-kernel, a.beregalov
In-Reply-To: <4AB8D9B3.4010805@tuffmail.co.uk>
From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date: Tue, 22 Sep 2009 15:05:39 +0100
> This was introduced by b93d58 "8139*: convert printk() to pr_<foo>()":
>
> [ 2256252443 ] <6>8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
>
> The "version" string is printed using pr_info(), so it doesn't need to
> include a loglevel.
>
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> CC: Alexander Beregalov <a.beregalov@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: dereference of he_dev->rbps_virt in he_init_group()
From: David Miller @ 2009-09-22 21:25 UTC (permalink / raw)
To: roel.kluin; +Cc: joe, chas, linux-atm-general, netdev, akpm
In-Reply-To: <4AB66240.6060703@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Sun, 20 Sep 2009 19:11:28 +0200
> he_dev->rbps_virt or he_dev->rbpl_virt allocation may fail, s
> them. Make sure that he_init_group() cleans up after errors.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ax25: Fix SIOCAX25GETINFO ioctl
From: David Miller @ 2009-09-22 21:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: jr+netfilter-devel, netdev
In-Reply-To: <4AB65937.8010508@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 20 Sep 2009 18:32:55 +0200
> [PATCH] ax25: Fix SIOCAX25GETINFO ioctl
>
> rcv_q & snd_q initializations were reversed in commit
> 31e6d363abcd0d05766c82f1a9c905a4c974a199
> (net: correct off-by-one write allocations reports)
>
> Signed-off-by: Jan Rafaj <jr+netfilter-devel@cedric.unob.cz>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied and I'll make sure to check if it needs -stable
treatment too.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] pktgen: check for link down
From: David Miller @ 2009-09-22 21:24 UTC (permalink / raw)
To: shemminger; +Cc: robert, jdb, netdev
In-Reply-To: <20090921225543.44d2d5c4@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 21 Sep 2009 22:55:43 -0700
> You can hold off on these two patches, I have better version
> which fixes some other issues. But testing time is limited this week.
Ok
^ permalink raw reply
* Re: [Patch net-next]atl1c:remove compiling warning
From: David Miller @ 2009-09-22 21:21 UTC (permalink / raw)
To: jie.yang; +Cc: akpm, jirislaby, jcliburn, netdev, linux-kernel
In-Reply-To: <12535093181069-git-send-email-jie.yang@atheros.com>
From: <jie.yang@atheros.com>
Date: Mon, 21 Sep 2009 13:01:58 +0800
> Set wol_ctrl_data to value 0, to remove compiling warning.
>
> Signed-off-by: Jie Yang <jie.yang@atheros.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: Set SKY2_HW_RAM_BUFFER in sky2_init
From: David Miller @ 2009-09-22 21:21 UTC (permalink / raw)
To: mikem; +Cc: shemminger, netdev
In-Reply-To: <4AB788F4.90503@ring3k.org>
From: Mike McCormack <mikem@ring3k.org>
Date: Mon, 21 Sep 2009 23:08:52 +0900
> The SKY2_HW_RAM_BUFFER bit in hw->flags was checked in sky2_mac_init(),
> before being set later in sky2_up().
>
> Setting SKY2_HW_RAM_BUFFER in sky2_init() where other hw->flags are set
> should avoid this problem recurring.
>
> Signed-off-by: Mike McCormack <mikem@ring3k.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 2/5] drivers/net: remove duplicate structure field initialization
From: David Miller @ 2009-09-22 21:21 UTC (permalink / raw)
To: julia; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0909192148180.27171@ask.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Sat, 19 Sep 2009 21:48:41 +0200 (CEST)
> From: Julia Lawall <julia@diku.dk>
>
> The definitions of vnet_ops and ehea_netdev_ops have initializations of a
> local function and eth_change_mtu for their respective ndo_change_mtu
> fields. This change uses only the local function.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH] smsc95xx: add additional USB product IDs
From: David Miller @ 2009-09-22 21:20 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev, ian.saturley, vlad.lyalikov
In-Reply-To: <1253632382-18458-1-git-send-email-steve.glendinning@smsc.com>
From: Steve Glendinning <steve.glendinning@smsc.com>
Date: Tue, 22 Sep 2009 16:13:02 +0100
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Applied.
^ permalink raw reply
* Re: [PATCH] smsc95xx: fix transmission where ZLP is expected
From: David Miller @ 2009-09-22 21:19 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev, ian.saturley, vlad.lyalikov
In-Reply-To: <1253628027-2704-1-git-send-email-steve.glendinning@smsc.com>
From: Steve Glendinning <steve.glendinning@smsc.com>
Date: Tue, 22 Sep 2009 15:00:27 +0100
> Usbnet framework assumes USB hardware doesn't handle zero length
> packets, but SMSC LAN95xx requires these to be sent for correct
> operation.
>
> This patch fixes an easily reproducible tx lockup when sending a frame
> that results in exactly 512 bytes in a USB transmission (e.g. a UDP
> frame with 458 data bytes, due to IP headers and our USB headers). It
> adds an extra flag to usbnet for the hardware driver to indicate that
> it can handle and requires the zero length packets.
>
> This patch should not affect other usbnet users, please also consider
> for -stable.
>
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] lib/vsprintf.c: Avoid possible unaligned accesses in %pI6c
From: David Miller @ 2009-09-22 21:17 UTC (permalink / raw)
To: joe; +Cc: netdev, me
In-Reply-To: <1253315046.2543.475.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Fri, 18 Sep 2009 16:04:06 -0700
> Jens Rosenboom noticed that a possibly unaligned const char*
> is cast to a const struct in6_addr *.
>
> Avoid this at the cost of a struct in6_addr copy on the stack.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
From: David Miller @ 2009-09-22 21:17 UTC (permalink / raw)
To: John.Linn; +Cc: grant.likely, netdev, linuxppc-dev, jwboyer, sadanan, monstr
In-Reply-To: <20090922165612.584554A8052@mail195-sin.bigfish.com>
From: John Linn <John.Linn@xilinx.com>
Date: Tue, 22 Sep 2009 10:56:27 -0600
> Thanks Grant, I wondered about that myself.
I've applied this patch, thanks.
^ permalink raw reply
* Re: [RFC][PATCH] pcmcia: pcnet_cs.c removing useless condition
From: David Miller @ 2009-09-22 21:17 UTC (permalink / raw)
To: jaswinder; +Cc: jeff, netdev, linux-pcmcia, linux
In-Reply-To: <1252782529.3687.26.camel@ht.satnam>
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
Date: Sun, 13 Sep 2009 00:38:49 +0530
> [This is untested]
>
> 'if (i < NR_INFO)' will only true if we breaks from 'for (i = 0; i < NR_INFO; i++)'
> So removing useless 'if (i < NR_INFO)'
>
> This also fixed following compilation warning :
>
> CC [M] drivers/net/pcmcia/pcnet_cs.o
> drivers/net/pcmcia/pcnet_cs.c: In function ‘get_hwinfo’:
> drivers/net/pcmcia/pcnet_cs.c:321: warning: ‘base’ may be used uninitialized in this function
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Looks good to me, applied.
^ permalink raw reply
* Re: [PATCH 2/2] netxen: fix firmware init after resume
From: David Miller @ 2009-09-22 21:14 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1253510439-28464-2-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 20 Sep 2009 22:20:39 -0700
> After successful firmware init, return instead of
> falling to error path (leading to detach) after
> resuming to D0 state. This was broken in recent
> firmware reset rehaul.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] netxen: fix minor tx timeout bug
From: David Miller @ 2009-09-22 21:14 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1253510439-28464-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 20 Sep 2009 22:20:38 -0700
> Fix minor bug in netdev tx timeout handling which could
> always lead to firmware reset instead of pci function reset.
>
> netxen_nic_reset_context() requires __NX_RESETTING bit
> cleared.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ permalink raw reply
* Re: fanotify as syscalls
From: Eric Paris @ 2009-09-22 21:06 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: Jamie Lokier, Linus Torvalds, Evgeniy Polyakov, David Miller,
linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <200909212204.51077.agruen@suse.de>
On Mon, 2009-09-21 at 22:04 +0200, Andreas Gruenbacher wrote:
> On Saturday, 19 September 2009 5:04:31 Eric Paris wrote:
> > Let me start by saying I am agreeing I should pursue subtree
> > notification. It's what I think everyone really wants. It's a great
> > idea, and I think you might have a simple way to get close. Clearly
> > these are avenues I'm willing and hoping to pursue. Also I say it
> > again, I believe the interface as proposed (except maybe some of my
> > exclusion stuff) is flexible enough to implement any of these ideas.
> > Does anyone disagree?
>
> It does seem flexible enough. However, the current interface assumes "global"
> listeners (the mask argument of fanotify_init):
>
> int fanotify_init(int flags, int f_flags, __u64 mask,
> unsigned int priority);
>
> Once subtree support is added, this parameter becomes obsolete. That's pretty
> broken for a syscall yet to be introduced.
Absolutely not obsolete. Subtree notification cannot do fscking all
notification.
> > BUT to solve one of the main problems fanotify is intending to solve it
> > needs a way to be the 'fscking all notifier.' It needs to be the whole
> > damn system.
>
> Think of a system after boot, with a single global namespace. Whatever you
> access by filename is reachable from the namespace root. At this point,
> nothing more global exists. A listener can watch the mount points of
> interest, and everything's fine.
this is true, if there is only one namespace subtree notification works
the same as global notification.
> What's a bit more tricky is to ensure that this listener will continue to
> receive all events from whatever else is mounted anywhere, irrespective of
> namespaces. I think we can get there.
Lets say I want the subtree under / to get every event on the system. A
process comes along and clones the namespace. Then lets say that
process mounts something inside his new namespace. There is absolutely
no path between my / and that new mount. How can subtree checking
possibly find and indicate it wants notification about this mount? I
don't see how subtree checking could do it. There can be completely
disjoint trees with no overlap.
mount -t tmpfs none /to_umount
clone namespace
mount -t tmpfs none /to_umount/private
pivot_root /tmp_umount/private
Something else umounts /to_umount
That process is in an completely detached namespace? right?
Heck, there could be operations on files that aren't in ANY namespace.
a = open(/path/to/dir/);
umount -l /path/to/
openat(a, "filename");
I don't see how subtree notification can possibly solve the global
notification problem.
I've been thinking that checking CAP_SYS_RAWIO as well as CAP_SYS_ADMIN
might be reasonable when trying to use a global listener. If you can
CAP_SYS_RAWIO I sorta feel like you can break out of a namespace anyway,
right?
-Eric
^ permalink raw reply
* Re: [PATCH][RESEND 2] IPv6: 6rd tunnel mode
From: Alexandre Cassen @ 2009-09-22 20:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090922.134543.158902222.davem@davemloft.net>
On Tue, 22 Sep 2009, David Miller wrote:
> From: Alexandre Cassen <acassen@freebox.fr>
> Date: Tue, 22 Sep 2009 10:51:05 +0200
>
>> IPv6 rapid deployment (RFC5569) builds upon mechanisms of 6to4 (RFC3056)
>> to enable a service provider to rapidly deploy IPv6 unicast service
>> to IPv4 sites to which it provides customer premise equipment. Like
>
> I've read your explanation, but it is still presumptious to mention
> an RFC number before it isn't really released yet.
>
> Mention the drafts only, and when it achieves true RFC status
> you can send another patch updating those references in the
> code comments.
ack. will fix this and resend.
^ permalink raw reply
* Re: [PATCH][RESEND 2] IPv6: 6rd tunnel mode
From: David Miller @ 2009-09-22 20:45 UTC (permalink / raw)
To: acassen; +Cc: netdev
In-Reply-To: <20090922085105.GA20906@lnxos.staff.proxad.net>
From: Alexandre Cassen <acassen@freebox.fr>
Date: Tue, 22 Sep 2009 10:51:05 +0200
> IPv6 rapid deployment (RFC5569) builds upon mechanisms of 6to4 (RFC3056)
> to enable a service provider to rapidly deploy IPv6 unicast service
> to IPv4 sites to which it provides customer premise equipment. Like
I've read your explanation, but it is still presumptious to mention
an RFC number before it isn't really released yet.
Mention the drafts only, and when it achieves true RFC status
you can send another patch updating those references in the
code comments.
^ permalink raw reply
* Re: Resend: [PATCH] TCP Early Retransmit: reduce required dupacks for triggering fast retrans
From: David Miller @ 2009-09-22 20:42 UTC (permalink / raw)
To: Christian.Samsel; +Cc: netdev
In-Reply-To: <20090922.134021.82409230.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 22 Sep 2009 13:40:21 -0700 (PDT)
> If you're resending just to get our attention, please don't do that.
>
> It only creates confusion and makes it take longer for your patch to
> get reviewed and applied.
Also I just checked and this patch is severely whitespace damaged
and we wouldn't be able to use it anyways. Your email client
truncated tabs and changed them into spaces, amongst other things.
You will need to fix this up before anyone can take your changes
seriously.
Thanks.
^ permalink raw reply
* Re: Resend: [PATCH] TCP Early Retransmit: reduce required dupacks for triggering fast retrans
From: David Miller @ 2009-09-22 20:40 UTC (permalink / raw)
To: Christian.Samsel; +Cc: netdev
In-Reply-To: <fab65f44d75b.4ab891f2@rwth-aachen.de>
From: Christian Samsel <Christian.Samsel@rwth-aachen.de>
Date: Tue, 22 Sep 2009 08:59:30 +0000 (GMT)
> This patch implements draft-ietf-tcpm-early-rexmt. The early retransmit
> mechanism allows the transport to reduce the number of duplicate
> acknowledgments required to trigger a fast retransmission in case we
> don't expect enough dupacks, (e.g. because there are not enough
> packets inflight and nothing to send). This allows the transport to use
> fast retransmit to recover packet losses that would otherwise require
> a lengthy retransmission timeout.
>
> See: http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01
>
> Signed-off-by: Christian Samsel <christian.samsel@rwth-aachen.de>
What changed from the previous version?
Nothing?
If you're resending just to get our attention, please don't do that.
It only creates confusion and makes it take longer for your patch to
get reviewed and applied.
^ permalink raw reply
* Re: [PATCH 1/2] ipv4: fix do_ip_setsockopt optlen check for IP_MULTICAST_IF
From: David Miller @ 2009-09-22 20:38 UTC (permalink / raw)
To: shanwei
Cc: dfeng, kaber, yoshfuji, jmorris, pekkas, kuznet, netdev,
linux-kernel
In-Reply-To: <4AB1FE2A.1060906@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Thu, 17 Sep 2009 17:15:22 +0800
> Xiaotian Feng wrote, at 09/17/2009 01:19 PM:
>> Due to man page of setsockopt, if optlen is not valid, kernel should return
>> -EINVAL. But a simple testcase as following, errno is 0, which means setsockopt
>> is successful.
>>
>> addr.s_addr = inet_addr("192.1.2.3");
>> setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, 1);
>> printf("errno is %d\n", errno);
>>
>> This patch fixes the optlen check part, with the patch, we got errno EINVAL.
>>
>
> I also think it's a bug, the freebsd also does the optlen check.
> But the style should be coincident with other option: firstly check the
> availability of optlen, then copy option value from user and deal with it.
>
> How about this one:
This definitely is better and cleaner, but please don't post such
things without proper signoffs and commit messages because now
I have to ask you to do that instead of me just applying your
patch :-/
^ permalink raw reply
* Re: [RFC] Virtual Machine Device Queues(VMDq) support on KVM
From: Arnd Bergmann @ 2009-09-22 18:34 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Michael S. Tsirkin, Chris Wright, Rusty Russell, virtualization,
Xin, Xiaohui, kvm@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, hpa@zytor.com,
mingo@elte.hu, akpm@linux-foundation.org
In-Reply-To: <20090922092957.17e68cbc@s6510>
On Tuesday 22 September 2009, Stephen Hemminger wrote:
> > My idea for that was to open multiple file descriptors to the same
> > macvtap device and let the kernel figure out the right thing to
> > do with that. You can do the same with raw packed sockets in case
> > of vhost_net, but I wouldn't want to add more complexity to the
> > tun/tap driver for this.
> >
> Or get tap out of the way entirely. The packets should not have
> to go out to user space at all (see veth)
How does veth relate to that, do you mean vhost_net? With vhost_net,
you could still open multiple sockets, only the access is in the kernel.
Obviously, once it all is in the kernel, that could be done under the
covers, but I think it would be cleaner to treat vhost_net purely as
a way to bypass the syscalls for user space, with as little as possible
visible impact otherwise.
Arnd <><
^ permalink raw reply
* RE: [PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
From: John Linn @ 2009-09-22 16:56 UTC (permalink / raw)
To: Grant Likely; +Cc: Michal Simek, linuxppc-dev, netdev, Sadanand Mutyala, davem
In-Reply-To: <fa686aa40909220953g708445d9s9c25bd839cc2dd2e@mail.gmail.com>
Thanks Grant, I wondered about that myself.
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely
> Sent: Tuesday, September 22, 2009 10:54 AM
> To: John Linn
> Cc: netdev@vger.kernel.org; davem@davemloft.net; linuxppc-dev@ozlabs.org; jwboyer@linux.vnet.ibm.com;
> Sadanand Mutyala; Michal Simek
> Subject: Re: [PATCH] net: xilinx_emaclite: Fix problem with first incoming packet
>
> On Tue, Sep 22, 2009 at 8:24 AM, John Linn <john.linn@xilinx.com> wrote:
> > From: Michal Simek <monstr@monstr.eu>
> >
> > You can't ping the board or connect to it unless you send
> > any packet out from board.
> >
> > Tested-by: John Williams <john.williams@petalogix.com>
> > Signed-off-by: Michal Simek <monstr@monstr.eu>
> > Acked-by: John Linn <john.linn@xilinx.com>
>
> John, Since this patch is being *sent* by you, then you should use a
> "signed-off-by" tag instead because it actually passed through your
> hands.
>
> Oh, and:
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> > ---
> > drivers/net/xilinx_emaclite.c | 7 ++-----
> > 1 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
> > index dc22782..83a044d 100644
> > --- a/drivers/net/xilinx_emaclite.c
> > +++ b/drivers/net/xilinx_emaclite.c
> > @@ -134,18 +134,15 @@ static void xemaclite_enable_interrupts(struct net_local *drvdata)
> > }
> >
> > /* Enable the Rx interrupts for the first buffer */
> > - reg_data = in_be32(drvdata->base_addr + XEL_RSR_OFFSET);
> > out_be32(drvdata->base_addr + XEL_RSR_OFFSET,
> > - reg_data | XEL_RSR_RECV_IE_MASK);
> > + XEL_RSR_RECV_IE_MASK);
> >
> > /* Enable the Rx interrupts for the second Buffer if
> > * configured in HW */
> > if (drvdata->rx_ping_pong != 0) {
> > - reg_data = in_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
> > - XEL_RSR_OFFSET);
> > out_be32(drvdata->base_addr + XEL_BUFFER_OFFSET +
> > XEL_RSR_OFFSET,
> > - reg_data | XEL_RSR_RECV_IE_MASK);
> > + XEL_RSR_RECV_IE_MASK);
> > }
> >
> > /* Enable the Global Interrupt Enable */
> > --
> > 1.6.2.1
> >
> >
> >
> > This email and any attachments are intended for the sole use of the named recipient(s) and
> contain(s) confidential information that may be proprietary, privileged or copyrighted under
> applicable law. If you are not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any attachments immediately.
> >
> >
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
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