* Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
From: Ming Lei @ 2012-10-31 3:05 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, linux-kernel, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
In-Reply-To: <CACVXFVMRJPfPSC_4ZamqfYUSYNsMEVYXMFmcs26T=4MdB_Kntw@mail.gmail.com>
On Wed, Oct 31, 2012 at 10:08 AM, Ming Lei <ming.lei@canonical.com> wrote:
>> I am afraid it is, because a disk may just have been probed as the deviceis being reset.
>
> Yes, it is probable, and sounds like similar with 'root_wait' problem, see
> prepare_namespace(): init/do_mounts.c, so looks no good solution
> for the problem, and maybe we have to set the flag always before resetting
> usb device.
The below idea may help the problem which 'memalloc_noio' flag isn't set during
usb_reset_device().
- for usb mass storage device, call pm_runtime_set_memalloc_noio(true)
inside usb_stor_probe2() and uas_probe(), and call
pm_runtime_set_memalloc_noio(false) inside uas_disconnect()
and usb_stor_disconnect().
- for usb network device, register_netdev() is always called inside usb
interface's probe(), looks no such problem.
Thanks,
--
Ming Lei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-10-31 2:48 UTC (permalink / raw)
To: Al Viro
Cc: Steven Rostedt, Sasha Levin, Tejun Heo, akpm, linux-kernel,
linux-mm, paul.gortmaker, davem, mingo, ebiederm, aarcange,
ericvh, netdev, josh, eric.dumazet, mathieu.desnoyers, axboe, agk,
dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust, bfields,
fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet,
linux-nfs, dev, rds-devel, lw
In-Reply-To: <20121031022418.GE2616@ZenIV.linux.org.uk>
On Tue, Oct 30, 2012 at 7:24 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> BTW, how serious have you been back at KS when you were talking about
> pull requests killing a thousand of lines of code being acceptable
> at any point in the cycle?
Well... I'm absolutely a lot more open to pull requests that kill code
than not, but I have to admit to being a bit more worried about stuff
like your execve/fork patches that touch very low-level code.
So I think I'll punt that for 3.8 anyway.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next 3/8] bridge: implement BPDU blocking
From: Cong Wang @ 2012-10-31 2:38 UTC (permalink / raw)
To: netdev
In-Reply-To: <20121030005835.462418417@vyatta.com>
On Tue, 30 Oct 2012 at 00:57 GMT, Stephen Hemminger <shemminger@vyatta.com> wrote:
> --- a/net/bridge/br_stp_bpdu.c 2012-10-29 17:07:08.005982838 -0700
> +++ b/net/bridge/br_stp_bpdu.c 2012-10-29 17:31:14.327457434 -0700
> @@ -170,6 +170,13 @@ void br_stp_rcv(const struct stp_proto *
> if (!ether_addr_equal(dest, br->group_addr))
> goto out;
>
> + if (p->flags & BR_BPDU_GUARD) {
> + br_notice(br, "BPDU received on blocked port %u(%s)\n",
> + (unsigned int) p->port_no, p->dev->name);
net_ratelimit() ?
^ permalink raw reply
* [PATCH] veth: allow changing the mac address while interface is up
From: Hannes Frederic Sowa @ 2012-10-31 2:22 UTC (permalink / raw)
To: netdev
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
drivers/net/veth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 5852361..9f87718 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -264,6 +264,7 @@ static void veth_setup(struct net_device *dev)
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+ dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
dev->netdev_ops = &veth_netdev_ops;
dev->ethtool_ops = &veth_ethtool_ops;
^ permalink raw reply related
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Al Viro @ 2012-10-31 2:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, Sasha Levin, Tejun Heo, akpm, linux-kernel,
linux-mm, paul.gortmaker, davem, mingo, ebiederm, aarcange,
ericvh, netdev, josh, eric.dumazet, mathieu.desnoyers, axboe, agk,
dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust, bfields,
fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet,
linux-nfs, dev, rds-devel, lw
In-Reply-To: <CA+55aFzFMrOUwdHHJ5-YUtEzTHGvdRosQc+K+trjub0K-w-D3A@mail.gmail.com>
On Tue, Oct 30, 2012 at 06:25:46PM -0700, Linus Torvalds wrote:
> But whatever. This series has gotten way too much bike-shedding
> anyway. I think it should just be applied, since it does remove lines
> of code overall. I'd even possibly apply it to mainline, but it seems
> to be against linux-next.
BTW, how serious have you been back at KS when you were talking about
pull requests killing a thousand of lines of code being acceptable
at any point in the cycle? Because right now I'm sitting on a pile that
removes 2-3 times as much (~-2KLoC for stuff that got considerable
testing for most of the architectures, -3KLoC if I include fork/clone/vfork
unification series) and seeing how maintainers of a bunch of embedded
architectures seem to be MIA... The idea of saying "screw them" and sending
a pull request becomes more and more tempting every day ;-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-10-31 2:23 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, Steven Rostedt,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <CA+1xoqd8vAn+N1JuhpXRjSr74OPtnnw_1UBhf8=c4WDC3jOirw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Oct 30, 2012 at 6:36 PM, Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> I can either rebase that on top of mainline, or we can ask maintainers
> to take it to their own trees if you take only 01/16 into mainline.
> What would you prefer?
I don't really care deeply. The only reason to merge it now would be
to avoid any pain with it during the next merge window. Just taking
01/16 might be the sanest way to do that, then the rest can trickle in
independently at their own leisure.
Linus
^ permalink raw reply
* Re: [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
From: Ming Lei @ 2012-10-31 2:08 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, linux-kernel, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
In-Reply-To: <2504263.kbM6W9JoH9@linux-lqwf.site>
On Wed, Oct 31, 2012 at 12:30 AM, Oliver Neukum <oneukum@suse.de> wrote:
>> If the USB mass-storage device is being reseted, the flag should be set
>> already generally. If the flag is still unset, that means the disk/network
>> device isn't added into system(or removed just now), so memory allocation
>> with block I/O should be allowed during the reset. Looks it isn't one problem,
>> isn't it?
>
> I am afraid it is, because a disk may just have been probed as the deviceis being reset.
Yes, it is probable, and sounds like similar with 'root_wait' problem, see
prepare_namespace(): init/do_mounts.c, so looks no good solution
for the problem, and maybe we have to set the flag always before resetting
usb device.
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Steven Rostedt @ 2012-10-31 1:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sasha Levin, Tejun Heo, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, mingo-X9Un+BFzKDI,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, aarcange-H+wXaHxf7aLQT0dZR+AlfA,
ericvh-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
josh-iaAMLnmF4UmaiuxdJuQwMA, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <CA+55aFzFMrOUwdHHJ5-YUtEzTHGvdRosQc+K+trjub0K-w-D3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2012-10-30 at 18:25 -0700, Linus Torvalds wrote:
> On Tue, Oct 30, 2012 at 6:16 PM, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
> >
> > ({ \
> > sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
> > })
> >
> > Is the better way to go. We are C programmers, we like to see the ?: on
> > a single line if possible. The way you have it, looks like three
> > statements run consecutively.
>
> If we're C programmers, why use the non-standard statement-expression
> at all? And split it onto three lines when it's just a single one?
I like the blue color over the pink. Anyway, I was just expressing an
opinion and really didn't care if it was changed or not.
>
> But whatever. This series has gotten way too much bike-shedding
> anyway. I think it should just be applied, since it does remove lines
> of code overall. I'd even possibly apply it to mainline, but it seems
> to be against linux-next.
I would think this change is a bit too big for an -rc4 release, but
you're the boss. I've already given my ack for my code that this set
touches. Let it go to Stephen's repo then.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v8 01/16] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-10-31 1:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, Tejun Heo, akpm, linux-kernel, linux-mm,
paul.gortmaker, davem, mingo, ebiederm, aarcange, ericvh, netdev,
josh, eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel,
neilb, ccaulfie, teigland, Trond.Myklebust, bfields, fweisbec,
jesse, venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs,
dev, rds-devel, lw
In-Reply-To: <CA+55aFzFMrOUwdHHJ5-YUtEzTHGvdRosQc+K+trjub0K-w-D3A@mail.gmail.com>
Hi Linus,
> But whatever. This series has gotten way too much bike-shedding
> anyway. I think it should just be applied, since it does remove lines
> of code overall. I'd even possibly apply it to mainline, but it seems
> to be against linux-next.
Yup, I switched to using -next because I've been running my
trinity/KVM tools tests with it.
I can either rebase that on top of mainline, or we can ask maintainers
to take it to their own trees if you take only 01/16 into mainline.
What would you prefer?
Thanks,
Sasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-10-31 1:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: Sasha Levin, Tejun Heo, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, mingo-X9Un+BFzKDI,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, aarcange-H+wXaHxf7aLQT0dZR+AlfA,
ericvh-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
josh-iaAMLnmF4UmaiuxdJuQwMA, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <1351646186.4004.41.camel-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
On Tue, Oct 30, 2012 at 6:16 PM, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
>
> ({ \
> sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
> })
>
> Is the better way to go. We are C programmers, we like to see the ?: on
> a single line if possible. The way you have it, looks like three
> statements run consecutively.
If we're C programmers, why use the non-standard statement-expression
at all? And split it onto three lines when it's just a single one?
But whatever. This series has gotten way too much bike-shedding
anyway. I think it should just be applied, since it does remove lines
of code overall. I'd even possibly apply it to mainline, but it seems
to be against linux-next.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v8 01/16] hashtable: introduce a small and naive hashtable
From: Steven Rostedt @ 2012-10-31 1:16 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <CA+1xoqeCKS2E4TWCUCELjDqV2pWS4v6EyV6K-=w-GRi_K6quiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2012-10-30 at 20:33 -0400, Sasha Levin wrote:
> On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > Hello,
> >
> > Just some nitpicks.
> >
> > On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
> >> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
> >> +#define hash_min(val, bits) \
> >> +({ \
> >> + sizeof(val) <= 4 ? \
> >> + hash_32(val, bits) : \
> >> + hash_long(val, bits); \
> >> +})
> >
> > Doesn't the above fit in 80 column. Why is it broken into multiple
> > lines? Also, you probably want () around at least @val. In general,
> > it's a good idea to add () around any macro argument to avoid nasty
> > surprises.
>
> It was broken to multiple lines because it looks nicer that way (IMO).
>
> If we wrap it with () it's going to go over 80, so it's going to stay
> broken down either way :)
({ \
sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
})
Is the better way to go. We are C programmers, we like to see the ?: on
a single line if possible. The way you have it, looks like three
statements run consecutively.
-- Steve
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-10-31 1:15 UTC (permalink / raw)
To: Jim Rees
Cc: Tejun Heo, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <20121031005128.GA30251-63aXycvo3TyHXe+LvDLADg@public.gmane.org>
On Tue, Oct 30, 2012 at 8:51 PM, Jim Rees <rees-63aXycvo3TyHXe+LvDLADg@public.gmane.org> wrote:
> Sasha Levin wrote:
>
> On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > Hello,
> >
> > Just some nitpicks.
> >
> > On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
> >> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
> >> +#define hash_min(val, bits) \
> >> +({ \
> >> + sizeof(val) <= 4 ? \
> >> + hash_32(val, bits) : \
> >> + hash_long(val, bits); \
> >> +})
> >
> > Doesn't the above fit in 80 column. Why is it broken into multiple
> > lines? Also, you probably want () around at least @val. In general,
> > it's a good idea to add () around any macro argument to avoid nasty
> > surprises.
>
> It was broken to multiple lines because it looks nicer that way (IMO).
>
> If we wrap it with () it's going to go over 80, so it's going to stay
> broken down either way :)
>
> I would prefer the body be all on one line too. But shouldn't this be a
> static inline function?
We want sizeof(val), which wouldn't work in a static inline. We can
either wrap a static inline __hash_min() with a macro and pass that
size to it, but that's quite an overkill here, or we can add a size
parameter to hash_min(), but it would look awkward considering how
hash_32()/hash_64()/hash_long() look like.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v8 01/16] hashtable: introduce a small and naive hashtable
From: Jim Rees @ 2012-10-31 0:51 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, rostedt-nx8X9YLhiw1AfugRpC6u6w,
lw-BthXqXjhjHXQFUHtdCDX3A,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <CA+1xoqeCKS2E4TWCUCELjDqV2pWS4v6EyV6K-=w-GRi_K6quiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Sasha Levin wrote:
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello,
>
> Just some nitpicks.
>
> On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
>> +#define hash_min(val, bits) \
>> +({ \
>> + sizeof(val) <= 4 ? \
>> + hash_32(val, bits) : \
>> + hash_long(val, bits); \
>> +})
>
> Doesn't the above fit in 80 column. Why is it broken into multiple
> lines? Also, you probably want () around at least @val. In general,
> it's a good idea to add () around any macro argument to avoid nasty
> surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
I would prefer the body be all on one line too. But shouldn't this be a
static inline function?
^ permalink raw reply
* Re: [PATCH 1/1] net: fix compile warning in af_unix.c
From: jing wang @ 2012-10-31 0:46 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David S. Miller, Eric Dumazet, Al Viro, Pavel Emelyanov, netdev
In-Reply-To: <20121030070040.5bdf0f0a@nehalam.linuxnetplumber.net>
于 2012年10月30日 22:00, Stephen Hemminger 写道:
> On Tue, 30 Oct 2012 15:16:36 +0800
> Jing Wang <windsdaemon@gmail.com> wrote:
>
>> This patch fix some compile warning as follows:
>> net/unix/af_unix.c: In function 'unix_bind':
>> net/unix/af_unix.c:895: warning: 'path.dentry' may be used uninitialized in this function
>> net/unix/af_unix.c:895: warning: 'path.mnt' may be used uninitialized in this function
>>
>> Signed-off-by: Jing Wang <windsdaemon@gmail.com>
>> ---
>> net/unix/af_unix.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 5b5c876..9f710ac 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -895,6 +895,8 @@ static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
>> struct path path;
>> umode_t mode = S_IFSOCK |
>> (SOCK_INODE(sock)->i_mode & ~current_umask());
>> + path.mnt = NULL;
>> + path.dentry = NULL;
>> err = unix_mknod(sun_path, mode, &path);
>> if (err) {
>> if (err == -EEXIST)
> I appreciate the effort to silence warnings. But this warning is a false
> positive that only occurs on some versions of Gcc. With gcc 4.7 the
> warning does not occur.
>
> The general consensus has been NOT to do initializations or other changes
> if the problem is due to Gcc bug.
>
Thanks for you review, you're right, the version of my gcc is 4.4.6 !
^ permalink raw reply
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-10-31 0:33 UTC (permalink / raw)
To: Tejun Heo
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, neilb,
ccaulfie, teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <20121030214257.GB2681@htj.dyndns.org>
On Tue, Oct 30, 2012 at 5:42 PM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> Just some nitpicks.
>
> On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
>> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
>> +#define hash_min(val, bits) \
>> +({ \
>> + sizeof(val) <= 4 ? \
>> + hash_32(val, bits) : \
>> + hash_long(val, bits); \
>> +})
>
> Doesn't the above fit in 80 column. Why is it broken into multiple
> lines? Also, you probably want () around at least @val. In general,
> it's a good idea to add () around any macro argument to avoid nasty
> surprises.
It was broken to multiple lines because it looks nicer that way (IMO).
If we wrap it with () it's going to go over 80, so it's going to stay
broken down either way :)
Thanks,
Sasha
> Looks good to me otherwise.
>
> Reviewed-by: Tejun Heo <tj@kernel.org>
>
> Thanks.
>
> --
> tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next v4 0/7] Multiqueue support in tuntap
From: Stephen Hemminger @ 2012-10-30 23:52 UTC (permalink / raw)
To: Jason Wang
Cc: davem, netdev, linux-kernel, mst, maxk, haixiao, ernesto.martin,
krkumar2, edumazet
In-Reply-To: <1351488964-11109-1-git-send-email-jasowang@redhat.com>
I am testing BQL for tuntap.
It wouldn't be hard to do BQL in the multi-queue version.
^ permalink raw reply
* Payment Sent!!
From: Western Union Transfer @ 2012-10-30 22:05 UTC (permalink / raw)
To: netdev
We write to inform you that we have transferred $400,000 dollars. deposited for transfer to you by one MR Bernard Harry from BLACKBERRY MOBILE COMPANY for transfer as a winning prize from the promotion lottery held by the communication company to encourage usage and appreciate already users of their product.
The money is available for pick up by receiver(you) to be cashed on daily installment of $10,000 for 40days. We tried calling to give you the information over the phone but we could not reach you so we decided to email you the information to pick up the first $10,000 already transferred to you. for you to be able to pick the first payment,
You will have to pay $250 to get it re-activated in your name for you to start picking up your money because we de-activate the transaction for security reason, by making the status to display pick up.
Use this link to track the below information
https://wumt.westernunion.com/asp/orderStatus.asp?country=global
Sender's Fist name: Ronald
Sender's Last Name: Mundy
MTCN: 6605740058
Question: Who Is Great
Answer: God
Amount: $10,000.00USD
Thanks
Best Regards
Mr.Mcferrin Phoenix .
+60169162934
western union Office,
MALAYSIA OFFICE.
Western Union® Money Transfer
^ permalink raw reply
* [PATCH net] tcp: Fix double sizeof in new tcp_metrics code
From: Julian Anastasov @ 2012-10-30 22:03 UTC (permalink / raw)
To: netdev
Fix double sizeof when parsing IPv6 address from
user space because it breaks get/del by specific IPv6 address.
Problem noticed by David Binderman:
https://bugzilla.kernel.org/show_bug.cgi?id=49171
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/tcp_metrics.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 4c752a6..53bc584 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -864,7 +864,7 @@ static int parse_nl_addr(struct genl_info *info, struct inetpeer_addr *addr,
}
a = info->attrs[TCP_METRICS_ATTR_ADDR_IPV6];
if (a) {
- if (nla_len(a) != sizeof(sizeof(struct in6_addr)))
+ if (nla_len(a) != sizeof(struct in6_addr))
return -EINVAL;
addr->family = AF_INET6;
memcpy(addr->addr.a6, nla_data(a), sizeof(addr->addr.a6));
--
1.7.3.4
^ permalink raw reply related
* [PATCH] ethtool: Support et131x registers in -d
From: Mark Einon @ 2012-10-30 21:57 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, Mark Einon
The et131x register set contains useful details of RX/TX queues for
the device. This dumps them with the -d option.
Signed-off-by: Mark Einon <mark.einon@gmail.com>
---
Makefile.am | 2 +-
et131x.c | 120 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ethtool.c | 1 +
internal.h | 3 ++
4 files changed, 125 insertions(+), 1 deletion(-)
create mode 100644 et131x.c
diff --git a/Makefile.am b/Makefile.am
index 1b96b98..e33f71f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,7 +5,7 @@ EXTRA_DIST = LICENSE ethtool.8 ethtool.spec.in aclocal.m4 ChangeLog autogen.sh
sbin_PROGRAMS = ethtool
ethtool_SOURCES = ethtool.c ethtool-copy.h internal.h net_tstamp-copy.h \
- amd8111e.c de2104x.c e100.c e1000.c igb.c \
+ amd8111e.c de2104x.c e100.c e1000.c et131x.c igb.c \
fec_8xx.c ibm_emac.c ixgb.c ixgbe.c natsemi.c \
pcnet32.c realtek.c tg3.c marvell.c vioc.c \
smsc911x.c at76c50x-usb.c sfc.c stmmac.c \
diff --git a/et131x.c b/et131x.c
new file mode 100644
index 0000000..46aaa71
--- /dev/null
+++ b/et131x.c
@@ -0,0 +1,120 @@
+#include <stdio.h>
+#include <string.h>
+#include "internal.h"
+
+int et131x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
+{
+ u32 *reg = (u32 *)regs->data;
+
+ fprintf(stdout, "PHY Registers\n");
+ fprintf(stdout, "0x0, Basic Control Reg = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1, Basic Status Reg = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x2, PHY identifier 1 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x3, PHY identifier 2 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x4, Auto Neg Advertisement = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x5, Auto Neg L Partner Ability = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x6, Auto Neg Expansion = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x7, Reserved = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x8, Reserved = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x9, 1000T Control = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xA, 1000T Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xB, Reserved = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xC, Reserved = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xD, MMD Access Control = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xE, MMD access Data = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xF, Extended Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x10, Phy Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x11, Phy Data = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x12, MPhy Control = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x13, Phy Loopback Control1 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x14, Phy Loopback Control2 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x15, Register Management = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x16, Phy Config = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x17, Phy Phy Control = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x18, Phy Interrupt Mask = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x19, Phy Interrupt Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1A, Phy Phy Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1B, Phy LED1 = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1C, Phy LED2 = 0x%04X\n", *reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "JAGCore Global Registers\n");
+ fprintf(stdout, "0x0, TXQ Start Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1, TXQ End Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x2, RXQ Start Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x3, RXQ End Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x4, Power Management Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x5, Interrupt Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x6, Interrupt Mask = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x7, Int Alias Clear Mask = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x8, Int Status Alias = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x9, Software Reset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xA, SLV Timer = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xB, MSI Config = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xC, Loopback = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xD, Watchdog Timer = 0x%04X\n", *reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "TXDMA Registers\n");
+ fprintf(stdout, "0x0, Control Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1, Packet Ring Base Addr (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x2, Packet Ring Base Addr (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x3, Packet Ring Num Descrs = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x4, TX Queue Write Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x5, TX Queue Write Address Ext = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x6, TX Queue Read Address = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x7, Status Writeback Addr (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x8, Status Writeback Addr (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x9, Service Request = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xA, Service Complete = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xB, Cache Read Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xC, Cache Write Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xD, TXDMA Error = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xE, Descriptor Abort Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xF, Payload Abort Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x10, Writeback Abort Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x11, Descriptor Timeout Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x12, Payload Timeout Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x13, Writeback Timeout Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x14, Descriptor Error Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x15, Payload Error Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x16, Writeback Error Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x17, Dropped TLP Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x18, New service Complete = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1A, Ethernet Packet Count = 0x%04X\n", *reg++);
+ fprintf(stdout, "\n");
+
+ fprintf(stdout, "RXDMA Registers\n");
+ fprintf(stdout, "0x0, Control Status = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1, Writeback Addr (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x2, Writeback Addr (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x3, Num Packets Done = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x4, Max Packet Time = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x5, RX Queue Read Addr = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x6, RX Queue Read Address Ext = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x7, RX Queue Write Addr = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x8, Packet Ring Base Addr (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x9, Packet Ring Base Addr (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xA, Packet Ring Num Descrs = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xE, Packet Ring Avail Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0xF, Packet Ring Full Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x10, Packet Ring Access Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x11, Packet Ring Min Descrip = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x12, FBR0 Address (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x13, FBR0 Address (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x14, FBR0 Num Descriptors = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x15, FBR0 Available Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x16, FBR0 Full Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x17, FBR0 Read Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x18, FBR0 Minimum Descriptors = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x19, FBR1 Address (Lo) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1A, FBR1 Address (Hi) = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1B, FBR1 Num Descriptors = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1C, FBR1 Available Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1D, FBR1 Full Offset = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1E, FBR1 Read Index = 0x%04X\n", *reg++);
+ fprintf(stdout, "0x1F, FBR1 Minimum Descriptors = 0x%04X\n", *reg++);
+ fprintf(stdout, "\n");
+ return 0;
+}
+
diff --git a/ethtool.c b/ethtool.c
index f3649e2..7c1bd22 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -888,6 +888,7 @@ static const struct {
{ "sfc", sfc_dump_regs },
{ "st_mac100", st_mac100_dump_regs },
{ "st_gmac", st_gmac_dump_regs },
+ { "et131x", et131x_dump_regs },
};
void dump_hex(FILE *file, const u8 *data, int len, int offset)
diff --git a/internal.h b/internal.h
index deb7868..4f96fd5 100644
--- a/internal.h
+++ b/internal.h
@@ -238,6 +238,9 @@ int st_mac100_dump_regs(struct ethtool_drvinfo *info,
struct ethtool_regs *regs);
int st_gmac_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+/* Et131x ethernet controller */
+int et131x_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs);
+
/* Rx flow classification */
int rxclass_parse_ruleopts(struct cmd_context *ctx,
struct ethtool_rx_flow_spec *fsp);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-10-30 21:42 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, mathieu.desnoyers, axboe, agk, dm-devel, neilb,
ccaulfie, teigland, Trond.Myklebust, bfields, fweisbec, jesse,
venkat.x.venkatsubra, ejt, snitzer, edumazet, linux-nfs, dev,
rds-devel, lw
In-Reply-To: <1351622772-16400-1-git-send-email-levinsasha928@gmail.com>
Hello,
Just some nitpicks.
On Tue, Oct 30, 2012 at 02:45:57PM -0400, Sasha Levin wrote:
> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
> +#define hash_min(val, bits) \
> +({ \
> + sizeof(val) <= 4 ? \
> + hash_32(val, bits) : \
> + hash_long(val, bits); \
> +})
Doesn't the above fit in 80 column. Why is it broken into multiple
lines? Also, you probably want () around at least @val. In general,
it's a good idea to add () around any macro argument to avoid nasty
surprises.
Looks good to me otherwise.
Reviewed-by: Tejun Heo <tj@kernel.org>
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Peter Korsgaard @ 2012-10-30 21:35 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: netdev, paul, linux-arm-kernel, linux-omap, Mugunthan V N,
Richard Cochran, Benoit Cousson
In-Reply-To: <1351498881-32482-6-git-send-email-hvaibhav@ti.com>
>>>>> "Vaibhav" == Vaibhav Hiremath <hvaibhav@ti.com> writes:
Vaibhav> From: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> Add CPSW and MDIO related device tree data for AM33XX.
Vaibhav> Also enable them into board/evm dts files by providing
Vaibhav> respective phy-id.
Vaibhav> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Vaibhav> Cc: Richard Cochran <richardcochran@gmail.com>
Vaibhav> Cc: Benoit Cousson <b-cousson@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 3/4] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
From: Peter Korsgaard @ 2012-10-30 21:35 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: netdev, paul, linux-arm-kernel, linux-omap, Mugunthan V N,
Richard Cochran
In-Reply-To: <1351498881-32482-5-git-send-email-hvaibhav@ti.com>
>>>>> "Vaibhav" == Vaibhav Hiremath <hvaibhav@ti.com> writes:
Vaibhav> From: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> This patch adds hwmod entry for davinci MDIO module,
Vaibhav> creating parent<->child relationship between CPSW and MDIO module.
Vaibhav> This Parent-child relation is required in order to use common resources
Vaibhav> like, clock, but still maintaining the logical separation between them.
Vaibhav> CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
Vaibhav> cpsw, etc... These sub-modules are also used in some of Davinci
Vaibhav> family of devices, so separate and independent platform devices &
Vaibhav> drivers for CPSW and MDIO is implemented.
Vaibhav> In case of AM33XX, the resources are shared and common register
Vaibhav> bit-field is provided to control module/clock enable/disable,
Vaibhav> makes it difficult to handle common resources from both drivers.
Vaibhav> So the solution is, create parent<->child relationship between
Vaibhav> CPGMAC & MDIO modules.
Vaibhav> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Vaibhav> Cc: Richard Cochran <richardcochran@gmail.com>
Vaibhav> Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 2/4] net: cpsw: Add parent<->child relation support between cpsw and mdio
From: Peter Korsgaard @ 2012-10-30 21:34 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: netdev, paul, linux-arm-kernel, linux-omap, Mugunthan V N,
Richard Cochran
In-Reply-To: <1351498881-32482-4-git-send-email-hvaibhav@ti.com>
>>>>> "Vaibhav" == Vaibhav Hiremath <hvaibhav@ti.com> writes:
Vaibhav> CPGMAC SubSystem consist of various sub-modules, like, mdio,
Vaibhav> cpdma, cpsw, etc... These sub-modules are also used in some of
Vaibhav> Davinci family of devices. Now based on requirement, use-case
Vaibhav> and available technology nodes the integration of these
Vaibhav> sub-modules varies across devices.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/4] net: davinci_mdio: Fix typo mistake in calling runtime-pm api
From: Peter Korsgaard @ 2012-10-30 21:33 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: netdev, paul, linux-arm-kernel, linux-omap, Mugunthan V N,
Richard Cochran
In-Reply-To: <1351498881-32482-3-git-send-email-hvaibhav@ti.com>
>>>>> "Vaibhav" == Vaibhav Hiremath <hvaibhav@ti.com> writes:
Vaibhav> By mistake (most likely a copy-paste), instead of pm_runtime_get_sync()
Vaibhav> api, driver is calling pm_runtime_put_sync() api in resume callback
Vaibhav> function. The bug was introduced by commit id (ae2c07aaf74:
Vaibhav> davinci_mdio: runtime PM support).
Vaibhav> Now, the reason why it didn't impact functionality is, the patch has
Vaibhav> been tested on AM335x-EVM and BeagleBone platform while submitting;
Vaibhav> and in case of AM335x the MDIO driver doesn't control the module
Vaibhav> enable/disable part, which is handled by CPSW driver.
Vaibhav> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Vaibhav> Cc: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> Cc: Richard Cochran <richardcochran@gmail.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* ping -f is broken in iputils 20121011
From: Mohammad Alsaleh @ 2012-10-30 20:52 UTC (permalink / raw)
To: netdev
As explained in this bug report(1). ping -f seems to be broken in
iputils 20121011.
(1) https://bugs.archlinux.org/task/32306
^ 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