* Re: [PATCH v2 1/7] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-09-18 20:40 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <20110918203931.GA28611@shutemov.name>
On 09/18/2011 05:39 PM, Kirill A. Shutemov wrote:
> On Sun, Sep 18, 2011 at 04:11:21PM -0300, Glauber Costa wrote:
>> On 09/18/2011 04:05 PM, Kirill A. Shutemov wrote:
>>> On Sun, Sep 18, 2011 at 12:39:12AM -0300, Glauber Costa wrote:
>>>>> Always zero in root cgroup?
>>>>
>>>> Yes, if we're not accounting, it should be zero. WARN_ON, maybe?
>>>
>>> -ENOSYS?
>>>
>> I'd personally prefer WARN_ON. It is good symmetry from userspace PoV to
>> always be able to get a value out of it. Also, it something goes wrong
>> and it is not zero for some reason, this will help us find it.
>
> What's the point to get non-relevant value?
> What about -ENOSYS + WARN_ON?
>
Well,
what about not even registering kernel memory files for !root cgroup?
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 1/7] Basic kernel memory functionality for the Memory Controller
From: Kirill A. Shutemov @ 2011-09-18 20:39 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <4E764259.5070209@parallels.com>
On Sun, Sep 18, 2011 at 04:11:21PM -0300, Glauber Costa wrote:
> On 09/18/2011 04:05 PM, Kirill A. Shutemov wrote:
> > On Sun, Sep 18, 2011 at 12:39:12AM -0300, Glauber Costa wrote:
> >>> Always zero in root cgroup?
> >>
> >> Yes, if we're not accounting, it should be zero. WARN_ON, maybe?
> >
> > -ENOSYS?
> >
> I'd personally prefer WARN_ON. It is good symmetry from userspace PoV to
> always be able to get a value out of it. Also, it something goes wrong
> and it is not zero for some reason, this will help us find it.
What's the point to get non-relevant value?
What about -ENOSYS + WARN_ON?
--
Kirill A. Shutemov
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [BUG?] tcp: potential bug in tcp_is_sackblock_valid()
From: Eric Dumazet @ 2011-09-18 20:39 UTC (permalink / raw)
To: Dave Taht
Cc: Ilpo Järvinen, Yan, Zheng, Herbert Xu,
netdev@vger.kernel.org, davem@davemloft.net, sfr@canb.auug.org.au
In-Reply-To: <CAA93jw7L9KyXVevZ8dqE+ExLYP9=CLMmj1gPD88ihBuC6ZovOQ@mail.gmail.com>
Le samedi 17 septembre 2011 à 11:30 -0700, Dave Taht a écrit :
>
> As cerowrt is one of the few projects enabling sack/dsack/ecn by
> default, it would be good to know either
>
dsack is enabled by default on linux, not only cerowt project.
> A) how to test to see if this problem is really a problem
> B) should we apply the obvious fix
Isnt Cerowrt a router, most of frames are forwarded anyway ?
This bug is relevant to linux hosts, receiving Duplicate Sacks (RFC
2883).
^ permalink raw reply
* Re: [GIT] Networking
From: Eric Dumazet @ 2011-09-18 20:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Markus Trippelsdorf, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <CA+55aFwmwYXzC_4q+XuEAx3ta6U-jf=NvMcAc-J+4DBxLm8Efg@mail.gmail.com>
Le dimanche 18 septembre 2011 à 12:55 -0700, Linus Torvalds a écrit :
> On Sun, Sep 18, 2011 at 12:48 PM, Markus Trippelsdorf
> <markus@trippelsdorf.de> wrote:
> >
> > The following works for me:
>
> No it doesn't. It may *compile* for you, but it doesn't work for you.
> It avoids all the other stuff that tcp_syn_flood_action() also does
> (notably the printout).
>
> The real fix looks to be either:
>
> - make an empty (inline/macro) cookie_v4_init_sequence() for the
> non-syncookie config case
>
Yes, this one seems the less ugly.
Frankly, we should remove CONFIG_SYN_COOKIE option...
Sorry for the mess, dont blame David on this, since netdev guys
probably always use CONFIG_SYN_COOKIE.
Thanks
[PATCH] tcp: fix build error if !CONFIG_SYN_COOKIE
commit 946cedccbd7387 (tcp: Change possible SYN flooding messages)
added a build error if CONFIG_SYN_COOKIE=n
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/tcp.h | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index e9b48b0..f860d64 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -431,17 +431,34 @@ extern int tcp_disconnect(struct sock *sk, int flags);
extern __u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS];
extern struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb,
struct ip_options *opt);
+#ifdef CONFIG_SYN_COOKIE
extern __u32 cookie_v4_init_sequence(struct sock *sk, struct sk_buff *skb,
__u16 *mss);
+#else
+static inline __u32 cookie_v4_init_sequence(struct sock *sk,
+ struct sk_buff *skb,
+ __u16 *mss)
+{
+ return 0;
+}
+#endif
extern __u32 cookie_init_timestamp(struct request_sock *req);
extern bool cookie_check_timestamp(struct tcp_options_received *opt, bool *);
/* From net/ipv6/syncookies.c */
extern struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb);
+#ifdef CONFIG_SYN_COOKIE
extern __u32 cookie_v6_init_sequence(struct sock *sk, struct sk_buff *skb,
__u16 *mss);
-
+#else
+static inline __u32 cookie_v6_init_sequence(struct sock *sk,
+ struct sk_buff *skb,
+ __u16 *mss)
+{
+ return 0;
+}
+#endif
/* tcp_output.c */
extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss,
^ permalink raw reply related
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-09-18 19:55 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Eric Dumazet, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <20110918194818.GB1641@x4.trippels.de>
On Sun, Sep 18, 2011 at 12:48 PM, Markus Trippelsdorf
<markus@trippelsdorf.de> wrote:
>
> The following works for me:
No it doesn't. It may *compile* for you, but it doesn't work for you.
It avoids all the other stuff that tcp_syn_flood_action() also does
(notably the printout).
The real fix looks to be either:
- make an empty (inline/macro) cookie_v4_init_sequence() for the
non-syncookie config case
OR
- change tcp_syn_flood_action() to have an inline wrapper that always
returns 0 for the non-syncookie config case so that the compiler can
see statically that when syncookies are disabled, it will always
return zero.
Or something like that.
Tssk. David, linux-next may not be fully operational, but by -rc6 you
shouldn't have sent me stuff like this that was even *remotely*
complex anyway.
Stop it.
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: Eric Dumazet @ 2011-09-18 19:50 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Linus Torvalds, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <20110918194818.GB1641@x4.trippels.de>
Le dimanche 18 septembre 2011 à 21:48 +0200, Markus Trippelsdorf a
écrit :
> On 2011.09.18 at 21:46 +0200, Eric Dumazet wrote:
> > Le dimanche 18 septembre 2011 à 21:23 +0200, Markus Trippelsdorf a
> > écrit :
> > > On 2011.09.18 at 11:06 -0700, Linus Torvalds wrote:
> > > > 2011/9/17 David Miller <davem@davemloft.net>:
> > > > >
> > > > > dpward (2):
> > > > > net: Make flow cache namespace-aware
> > > > > net: Handle different key sizes between address families in flow cache
> > > > >
> > > > > nhorman (1):
> > > > > net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
> > > > >
> > > > > rajan.aggarwal85@gmail.com (1):
> > > > > net/can/af_can.c: Change del_timer to del_timer_sync
> > > >
> > > > Guys, if somebody has such a broken email setup that they don't even
> > > > show their own name, don't take patches from them.
> > > >
> > > > If you cannot even set up email sanely, there is zero reason to
> > > > believe that the patch should be good. And if the patch is trivial and
> > > > you want to take it despite the source of the patch being crap, please
> > > > spend the five seconds to fix it up.
> > > >
> > > > Proper names are part of the commit message. Don't make it look like
> > > > crap. I get ugly flashbacks to SVN or CVS when I see stuff like this.
> > > > Don't do it.
> > >
> > > Plus commit 946cedccbd73874 breaks the build:
> > >
> > > LD init/built-in.o
> > > LD .tmp_vmlinux1
> > > net/built-in.o:sysctl_net.c:function tcp_v4_conn_request: error: undefined reference to 'cookie_v4_init_sequence'
> > > make: *** [.tmp_vmlinux1] Error 1
> > >
> > > commit 946cedccbd7387488d2cee5da92cdfeb28d2e670
> > > Author: Eric Dumazet <eric.dumazet@gmail.com>
> > > Date: Tue Aug 30 03:21:44 2011 +0000
> > >
> > > tcp: Change possible SYN flooding messages
> > >
> > > "Possible SYN flooding on port xxxx " messages can fill logs on servers.
> > >
> > > Change logic to log the message only once per listener, and add two new
> > > SNMP counters to track :
> > >
> > > TCPReqQFullDoCookies : number of times a SYNCOOKIE was replied to client
> > >
> > > TCPReqQFullDrop : number of times a SYN request was dropped because
> > > syncookies were not enabled.
> > >
> > > Based on a prior patch from Tom Herbert, and suggestions from David.
> > >
> > >
> >
> > Oh well, trying to remove those ugly #ifdef was not so easy.
> > I'll cook a patch, thanks for the report
>
> The following works for me:
>
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index c34f015..ef9dd55 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1264,7 +1264,9 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
> * evidently real one.
> */
> if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
> +#ifdef CONFIG_SYN_COOKIES
> want_cookie = tcp_syn_flood_action(sk, skb, "TCP");
> +#endif
> if (!want_cookie)
> goto drop;
> }
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index 3c9fa61..7ffc3b1 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -1174,7 +1174,9 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
> goto drop;
>
> if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
> +#ifdef CONFIG_SYN_COOKIES
> want_cookie = tcp_syn_flood_action(sk, skb, "TCPv6");
> +#endif
> if (!want_cookie)
> goto drop;
> }
>
Dont do that, we _really_ want to call tcp_syn_flood_action()
^ permalink raw reply
* Re: [GIT] Networking
From: Markus Trippelsdorf @ 2011-09-18 19:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linus Torvalds, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <1316375164.31335.18.camel@edumazet-laptop>
On 2011.09.18 at 21:46 +0200, Eric Dumazet wrote:
> Le dimanche 18 septembre 2011 à 21:23 +0200, Markus Trippelsdorf a
> écrit :
> > On 2011.09.18 at 11:06 -0700, Linus Torvalds wrote:
> > > 2011/9/17 David Miller <davem@davemloft.net>:
> > > >
> > > > dpward (2):
> > > > net: Make flow cache namespace-aware
> > > > net: Handle different key sizes between address families in flow cache
> > > >
> > > > nhorman (1):
> > > > net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
> > > >
> > > > rajan.aggarwal85@gmail.com (1):
> > > > net/can/af_can.c: Change del_timer to del_timer_sync
> > >
> > > Guys, if somebody has such a broken email setup that they don't even
> > > show their own name, don't take patches from them.
> > >
> > > If you cannot even set up email sanely, there is zero reason to
> > > believe that the patch should be good. And if the patch is trivial and
> > > you want to take it despite the source of the patch being crap, please
> > > spend the five seconds to fix it up.
> > >
> > > Proper names are part of the commit message. Don't make it look like
> > > crap. I get ugly flashbacks to SVN or CVS when I see stuff like this.
> > > Don't do it.
> >
> > Plus commit 946cedccbd73874 breaks the build:
> >
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > net/built-in.o:sysctl_net.c:function tcp_v4_conn_request: error: undefined reference to 'cookie_v4_init_sequence'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > commit 946cedccbd7387488d2cee5da92cdfeb28d2e670
> > Author: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Tue Aug 30 03:21:44 2011 +0000
> >
> > tcp: Change possible SYN flooding messages
> >
> > "Possible SYN flooding on port xxxx " messages can fill logs on servers.
> >
> > Change logic to log the message only once per listener, and add two new
> > SNMP counters to track :
> >
> > TCPReqQFullDoCookies : number of times a SYNCOOKIE was replied to client
> >
> > TCPReqQFullDrop : number of times a SYN request was dropped because
> > syncookies were not enabled.
> >
> > Based on a prior patch from Tom Herbert, and suggestions from David.
> >
> >
>
> Oh well, trying to remove those ugly #ifdef was not so easy.
> I'll cook a patch, thanks for the report
The following works for me:
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index c34f015..ef9dd55 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1264,7 +1264,9 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
* evidently real one.
*/
if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
+#ifdef CONFIG_SYN_COOKIES
want_cookie = tcp_syn_flood_action(sk, skb, "TCP");
+#endif
if (!want_cookie)
goto drop;
}
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 3c9fa61..7ffc3b1 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1174,7 +1174,9 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
goto drop;
if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
+#ifdef CONFIG_SYN_COOKIES
want_cookie = tcp_syn_flood_action(sk, skb, "TCPv6");
+#endif
if (!want_cookie)
goto drop;
}
--
Markus
^ permalink raw reply related
* Re: [GIT] Networking
From: Eric Dumazet @ 2011-09-18 19:46 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Linus Torvalds, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <20110918192333.GA1641@x4.trippels.de>
Le dimanche 18 septembre 2011 à 21:23 +0200, Markus Trippelsdorf a
écrit :
> On 2011.09.18 at 11:06 -0700, Linus Torvalds wrote:
> > 2011/9/17 David Miller <davem@davemloft.net>:
> > >
> > > dpward (2):
> > > net: Make flow cache namespace-aware
> > > net: Handle different key sizes between address families in flow cache
> > >
> > > nhorman (1):
> > > net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
> > >
> > > rajan.aggarwal85@gmail.com (1):
> > > net/can/af_can.c: Change del_timer to del_timer_sync
> >
> > Guys, if somebody has such a broken email setup that they don't even
> > show their own name, don't take patches from them.
> >
> > If you cannot even set up email sanely, there is zero reason to
> > believe that the patch should be good. And if the patch is trivial and
> > you want to take it despite the source of the patch being crap, please
> > spend the five seconds to fix it up.
> >
> > Proper names are part of the commit message. Don't make it look like
> > crap. I get ugly flashbacks to SVN or CVS when I see stuff like this.
> > Don't do it.
>
> Plus commit 946cedccbd73874 breaks the build:
>
> LD init/built-in.o
> LD .tmp_vmlinux1
> net/built-in.o:sysctl_net.c:function tcp_v4_conn_request: error: undefined reference to 'cookie_v4_init_sequence'
> make: *** [.tmp_vmlinux1] Error 1
>
> commit 946cedccbd7387488d2cee5da92cdfeb28d2e670
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue Aug 30 03:21:44 2011 +0000
>
> tcp: Change possible SYN flooding messages
>
> "Possible SYN flooding on port xxxx " messages can fill logs on servers.
>
> Change logic to log the message only once per listener, and add two new
> SNMP counters to track :
>
> TCPReqQFullDoCookies : number of times a SYNCOOKIE was replied to client
>
> TCPReqQFullDrop : number of times a SYN request was dropped because
> syncookies were not enabled.
>
> Based on a prior patch from Tom Herbert, and suggestions from David.
>
>
Oh well, trying to remove those ugly #ifdef was not so easy.
I'll cook a patch, thanks for the report
^ permalink raw reply
* Re: [PATCH v2 4/7] per-cgroup tcp buffers control
From: Glauber Costa @ 2011-09-18 19:42 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Cyrill Gorcunov, linux-kernel, paul, lizf, kamezawa.hiroyu,
ebiederm, davem, gthelen, netdev, linux-mm
In-Reply-To: <20110918185806.GA28057@shutemov.name>
On 09/18/2011 03:58 PM, Kirill A. Shutemov wrote:
> On Sat, Sep 17, 2011 at 10:33:58PM +0400, Cyrill Gorcunov wrote:
>> On Sat, Sep 17, 2011 at 09:11:32PM +0300, Kirill A. Shutemov wrote:
>>> On Wed, Sep 14, 2011 at 10:46:12PM -0300, Glauber Costa wrote:
>>>> +int tcp_init_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
>>>> + struct cgroup_subsys *ss)
>>>> +{
>>>> + prot->enter_memory_pressure = tcp_enter_memory_pressure;
>>>> + prot->memory_allocated = memory_allocated_tcp;
>>>> + prot->prot_mem = tcp_sysctl_mem;
>>>> + prot->sockets_allocated = sockets_allocated_tcp;
>>>> + prot->memory_pressure = memory_pressure_tcp;
>>>
>>> No fancy formatting, please.
>>>
>>
>> What's wrong with having fancy formatting? It's indeed easier to read
>> when members are assigned this way. It's always up to maintainer to
>> choose what he prefers, but I see nothing wrong in such style (if only it
>> doesn't break the style of the whole file).
>
> You have to remove this indenting if you'll reorganize code (e.g. move
> part under if(...)).
> IMO, it reduces code maintainability.
>
As I said, I don't care, so I'll change. But I have to say I disagree
with your statement.
It is a pack of assignments, so if you reorganize this code, two things
can happen:
1) It is not moved to a new ident level -> It keeps being a pack of
assignments, and you don't really need to change it.
2) It is moved to a new ident level -> You have to touch it anyway...
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [BUG?] tcp: potential bug in tcp_is_sackblock_valid()
From: Eric Dumazet @ 2011-09-18 19:35 UTC (permalink / raw)
To: Yan, Zheng
Cc: netdev@vger.kernel.org, davem@davemloft.net, herbert,
sfr@canb.auug.org.au
In-Reply-To: <4E696FD0.7060702@intel.com>
Le vendredi 09 septembre 2011 à 09:45 +0800, Yan, Zheng a écrit :
> Hi all,
>
> I found a check in tcp_is_sackblock_valid() is suspicious. It against
> its comment and RFC. I think the correct check should be:
>
> ---
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 385c470..a5d01b1 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -1124,7 +1124,7 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack,
> return 0;
>
> /* ...Then it's D-SACK, and must reside below snd_una completely */
> - if (!after(end_seq, tp->snd_una))
> + if (after(end_seq, tp->snd_una))
> return 0;
>
> if (!before(start_seq, tp->undo_marker))
> ---
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
This bug was introduced in 2.6.24 by commit 5b3c9882
^ permalink raw reply
* Re: [GIT] Networking
From: Markus Trippelsdorf @ 2011-09-18 19:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel, eric.dumazet
In-Reply-To: <CA+55aFxc1tMCXKBV33PVD5BybTLBpfJAEcObvoQwbwqbKOsp7g@mail.gmail.com>
On 2011.09.18 at 11:06 -0700, Linus Torvalds wrote:
> 2011/9/17 David Miller <davem@davemloft.net>:
> >
> > dpward (2):
> > net: Make flow cache namespace-aware
> > net: Handle different key sizes between address families in flow cache
> >
> > nhorman (1):
> > net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
> >
> > rajan.aggarwal85@gmail.com (1):
> > net/can/af_can.c: Change del_timer to del_timer_sync
>
> Guys, if somebody has such a broken email setup that they don't even
> show their own name, don't take patches from them.
>
> If you cannot even set up email sanely, there is zero reason to
> believe that the patch should be good. And if the patch is trivial and
> you want to take it despite the source of the patch being crap, please
> spend the five seconds to fix it up.
>
> Proper names are part of the commit message. Don't make it look like
> crap. I get ugly flashbacks to SVN or CVS when I see stuff like this.
> Don't do it.
Plus commit 946cedccbd73874 breaks the build:
LD init/built-in.o
LD .tmp_vmlinux1
net/built-in.o:sysctl_net.c:function tcp_v4_conn_request: error: undefined reference to 'cookie_v4_init_sequence'
make: *** [.tmp_vmlinux1] Error 1
commit 946cedccbd7387488d2cee5da92cdfeb28d2e670
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue Aug 30 03:21:44 2011 +0000
tcp: Change possible SYN flooding messages
"Possible SYN flooding on port xxxx " messages can fill logs on servers.
Change logic to log the message only once per listener, and add two new
SNMP counters to track :
TCPReqQFullDoCookies : number of times a SYNCOOKIE was replied to client
TCPReqQFullDrop : number of times a SYN request was dropped because
syncookies were not enabled.
Based on a prior patch from Tom Herbert, and suggestions from David.
--
Markus
^ permalink raw reply
* Re: [PATCH v2 1/7] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-09-18 19:11 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <20110918190509.GC28057@shutemov.name>
On 09/18/2011 04:05 PM, Kirill A. Shutemov wrote:
> On Sun, Sep 18, 2011 at 12:39:12AM -0300, Glauber Costa wrote:
>>> No kernel memory accounting for root cgroup, right?
>> Not sure. Maybe kernel memory accounting is useful even for root cgroup.
>> Same as normal memory accounting... what we want to avoid is kernel
>> memory limits. OTOH, if we are not limiting it anyway, accounting it is
>> just useless overhead... Even the statistics can then be gathered
>> through all
>> the proc files that show slab usage, I guess?
>
> It's better to leave root cgroup without accounting. At least for now.
> We can add it later if needed.
Fair.
>>>
>>>> @@ -3979,6 +3999,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
>>>> else
>>>> val = res_counter_read_u64(&mem->memsw, name);
>>>> break;
>>>> + case _KMEM:
>>>> + val = res_counter_read_u64(&mem->kmem, name);
>>>> + break;
>>>> +
>>>
>>> Always zero in root cgroup?
>>
>> Yes, if we're not accounting, it should be zero. WARN_ON, maybe?
>
> -ENOSYS?
>
I'd personally prefer WARN_ON. It is good symmetry from userspace PoV to
always be able to get a value out of it. Also, it something goes wrong
and it is not zero for some reason, this will help us find it.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 1/7] Basic kernel memory functionality for the Memory Controller
From: Kirill A. Shutemov @ 2011-09-18 19:05 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <4E7567E0.9010401@parallels.com>
On Sun, Sep 18, 2011 at 12:39:12AM -0300, Glauber Costa wrote:
> > No kernel memory accounting for root cgroup, right?
> Not sure. Maybe kernel memory accounting is useful even for root cgroup.
> Same as normal memory accounting... what we want to avoid is kernel
> memory limits. OTOH, if we are not limiting it anyway, accounting it is
> just useless overhead... Even the statistics can then be gathered
> through all
> the proc files that show slab usage, I guess?
It's better to leave root cgroup without accounting. At least for now.
We can add it later if needed.
> >
> >> @@ -3979,6 +3999,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
> >> else
> >> val = res_counter_read_u64(&mem->memsw, name);
> >> break;
> >> + case _KMEM:
> >> + val = res_counter_read_u64(&mem->kmem, name);
> >> + break;
> >> +
> >
> > Always zero in root cgroup?
>
> Yes, if we're not accounting, it should be zero. WARN_ON, maybe?
-ENOSYS?
--
Kirill A. Shutemov
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 2/7] socket: initial cgroup code.
From: Kirill A. Shutemov @ 2011-09-18 18:58 UTC (permalink / raw)
To: Glauber Costa
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm
In-Reply-To: <4E75664B.9070605@parallels.com>
On Sun, Sep 18, 2011 at 12:32:27AM -0300, Glauber Costa wrote:
> On 09/17/2011 02:52 PM, Kirill A. Shutemov wrote:
> > Do we really need to have these functions in the header?
> >
> No, I can move it to memcontrol.c
>
Yes, please.
--
Kirill A. Shutemov
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2 4/7] per-cgroup tcp buffers control
From: Kirill A. Shutemov @ 2011-09-18 18:58 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Glauber Costa, linux-kernel, paul, lizf, kamezawa.hiroyu,
ebiederm, davem, gthelen, netdev, linux-mm
In-Reply-To: <20110917183358.GB2783@moon>
On Sat, Sep 17, 2011 at 10:33:58PM +0400, Cyrill Gorcunov wrote:
> On Sat, Sep 17, 2011 at 09:11:32PM +0300, Kirill A. Shutemov wrote:
> > On Wed, Sep 14, 2011 at 10:46:12PM -0300, Glauber Costa wrote:
> > > +int tcp_init_cgroup_fill(struct proto *prot, struct cgroup *cgrp,
> > > + struct cgroup_subsys *ss)
> > > +{
> > > + prot->enter_memory_pressure = tcp_enter_memory_pressure;
> > > + prot->memory_allocated = memory_allocated_tcp;
> > > + prot->prot_mem = tcp_sysctl_mem;
> > > + prot->sockets_allocated = sockets_allocated_tcp;
> > > + prot->memory_pressure = memory_pressure_tcp;
> >
> > No fancy formatting, please.
> >
>
> What's wrong with having fancy formatting? It's indeed easier to read
> when members are assigned this way. It's always up to maintainer to
> choose what he prefers, but I see nothing wrong in such style (if only it
> doesn't break the style of the whole file).
You have to remove this indenting if you'll reorganize code (e.g. move
part under if(...)).
IMO, it reduces code maintainability.
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH ] dynamic_debug: call __netdev_printk only for CONFIG_NET
From: Randy Dunlap @ 2011-09-18 18:42 UTC (permalink / raw)
To: Greg KH
Cc: Jason Baron, Arnd Bergmann, gregkh, joe, jim.cromie, bvanassche,
linux-kernel, davem, aloisio.almeida, netdev
In-Reply-To: <20110918182714.GA32615@kroah.com>
On 09/18/2011 11:27 AM, Greg KH wrote:
> On Sun, Sep 18, 2011 at 10:21:14AM -0700, Randy Dunlap wrote:
>> On 09/18/2011 01:27 AM, Greg KH wrote:
>>> On Thu, Sep 01, 2011 at 11:18:18AM -0400, Jason Baron wrote:
>>>> On Thu, Sep 01, 2011 at 04:57:02PM +0200, Arnd Bergmann wrote:
>>>>> __netdev_printk is only defined when CONFIG_NET is set. Since we only need
>>>>> __dynamic_netdev_dbg for network drivers, we can make it conditional on the
>>>>> same Kconfig symbol.
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> Yes, I've posted a fix for this:
>>>>
>>>> https://lkml.org/lkml/2011/8/30/297
>>>>
>>>> Hopefully, it will be pulled in soon.
>>>
>>> As that thread again spun off into confusion, can you please resend the
>>> end result?
>>
>> That spinning confusion had nothing to do with the posted & correct patch
>> which could have been applied several weeks ago.
>>
>> I'm curious: Do you delete most of your email on a routine basis?
>
> No, only after going through pending patches do I purge them. And when
> a series of patches generates a thread like this one, where people are
> arguing over the way the macros are named, and no one seems to agree, I
> will take it as the fact that this series was contentious and needs to
> be resent after taking into consideration the original complaints.
Sheesh. The naming of the macros has nothing to do with this build fix.
> For me to keep all email threads, based on the amount of email I get[1],
> would be ludicrous.
>
> greg k-h
>
> [1]: http://www.kroah.com/log/linux/get_lots_of_email.html
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH ] dynamic_debug: call __netdev_printk only for CONFIG_NET
From: Greg KH @ 2011-09-18 18:27 UTC (permalink / raw)
To: Randy Dunlap
Cc: Jason Baron, Arnd Bergmann, gregkh, joe, jim.cromie, bvanassche,
linux-kernel, davem, aloisio.almeida, netdev
In-Reply-To: <4E76288A.4020801@xenotime.net>
On Sun, Sep 18, 2011 at 10:21:14AM -0700, Randy Dunlap wrote:
> On 09/18/2011 01:27 AM, Greg KH wrote:
> > On Thu, Sep 01, 2011 at 11:18:18AM -0400, Jason Baron wrote:
> >> On Thu, Sep 01, 2011 at 04:57:02PM +0200, Arnd Bergmann wrote:
> >>> __netdev_printk is only defined when CONFIG_NET is set. Since we only need
> >>> __dynamic_netdev_dbg for network drivers, we can make it conditional on the
> >>> same Kconfig symbol.
> >>>
> >>
> >> Hi,
> >>
> >> Yes, I've posted a fix for this:
> >>
> >> https://lkml.org/lkml/2011/8/30/297
> >>
> >> Hopefully, it will be pulled in soon.
> >
> > As that thread again spun off into confusion, can you please resend the
> > end result?
>
> That spinning confusion had nothing to do with the posted & correct patch
> which could have been applied several weeks ago.
>
> I'm curious: Do you delete most of your email on a routine basis?
No, only after going through pending patches do I purge them. And when
a series of patches generates a thread like this one, where people are
arguing over the way the macros are named, and no one seems to agree, I
will take it as the fact that this series was contentious and needs to
be resent after taking into consideration the original complaints.
For me to keep all email threads, based on the amount of email I get[1],
would be ludicrous.
greg k-h
[1]: http://www.kroah.com/log/linux/get_lots_of_email.html
^ permalink raw reply
* Re: [PATCH 4/4] net/fec: add imx6q enet support
From: Francois Romieu @ 2011-09-18 18:09 UTC (permalink / raw)
To: Shawn Guo; +Cc: netdev, David S. Miller, linux-arm-kernel, patches
In-Reply-To: <1316346852-17090-5-git-send-email-shawn.guo@linaro.org>
Shawn Guo <shawn.guo@linaro.org> :
[...]
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 04206e4..849cb0b 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -442,18 +453,23 @@ fec_restart(struct net_device *ndev, int duplex)
> /* Enable flow control and length check */
> rcntl |= 0x40000000 | 0x00000020;
>
> - /* MII or RMII */
> + /* RGMII, RMII or MII */
> + if (fep->phy_interface == PHY_INTERFACE_MODE_RGMII)
> + rcntl |= (1 << 6);
> if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
^^^^ missing "else"
[...]
> + /* 1G, 100M or 10M */
> + if (fep->phy_dev) {
> + if (fep->phy_dev->speed == SPEED_1000)
> + ecntl |= (1 << 8);
> + else if (fep->phy_dev->speed == SPEED_100)
> + rcntl &= ~(1 << 9);
> + else
> + rcntl |= (1 << 9);
> + }
[...]
> + if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
> + /* enable ENET endian swap */
> + ecntl |= (1 << 8);
I do not understand why the endian swap bit of ecntl needs to be
set the same in these two different paths, especially as the latter
handles the old faulty imx28 and the former the newly fixed imx6q.
Typo ?
--
Ueimor
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-09-18 18:06 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20110918.022125.1554085675403900813.davem@davemloft.net>
2011/9/17 David Miller <davem@davemloft.net>:
>
> dpward (2):
> net: Make flow cache namespace-aware
> net: Handle different key sizes between address families in flow cache
>
> nhorman (1):
> net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
>
> rajan.aggarwal85@gmail.com (1):
> net/can/af_can.c: Change del_timer to del_timer_sync
Guys, if somebody has such a broken email setup that they don't even
show their own name, don't take patches from them.
If you cannot even set up email sanely, there is zero reason to
believe that the patch should be good. And if the patch is trivial and
you want to take it despite the source of the patch being crap, please
spend the five seconds to fix it up.
Proper names are part of the commit message. Don't make it look like
crap. I get ugly flashbacks to SVN or CVS when I see stuff like this.
Don't do it.
Linus
^ permalink raw reply
* Re: [PATCH ] dynamic_debug: call __netdev_printk only for CONFIG_NET
From: Randy Dunlap @ 2011-09-18 17:21 UTC (permalink / raw)
To: Greg KH
Cc: Jason Baron, Arnd Bergmann, gregkh, joe, jim.cromie, bvanassche,
linux-kernel, davem, aloisio.almeida, netdev
In-Reply-To: <20110918082736.GB19444@kroah.com>
On 09/18/2011 01:27 AM, Greg KH wrote:
> On Thu, Sep 01, 2011 at 11:18:18AM -0400, Jason Baron wrote:
>> On Thu, Sep 01, 2011 at 04:57:02PM +0200, Arnd Bergmann wrote:
>>> __netdev_printk is only defined when CONFIG_NET is set. Since we only need
>>> __dynamic_netdev_dbg for network drivers, we can make it conditional on the
>>> same Kconfig symbol.
>>>
>>
>> Hi,
>>
>> Yes, I've posted a fix for this:
>>
>> https://lkml.org/lkml/2011/8/30/297
>>
>> Hopefully, it will be pulled in soon.
>
> As that thread again spun off into confusion, can you please resend the
> end result?
That spinning confusion had nothing to do with the posted & correct patch
which could have been applied several weeks ago.
I'm curious: Do you delete most of your email on a routine basis?
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Follow-up to routing IPv6 source address selection bug in kernel
From: Xavier Roche @ 2011-09-18 14:11 UTC (permalink / raw)
To: netdev
[ Moved from linux-kernel where it did not belong ]
Hi folks,
I reported a year ago a bug regarding source address selection in the
kernel for Ipv6, but it seem to be still there. If anyone has any
insightful advice on possible workarounds, or (better) possible fixes,
it would be great.
Basically, the "src" attribute of "ip -6 route add" is ignored, and
default source address selection is selected by the kernel.
This is probably related to the way the kernel handles RFC 3484 source
address selection [ The RFC states that [RFC 3484] "If the eight [source
address selection] rules fail to choose a single address, some
unspecified tie-breaker should be used". The unspecified tie-breaker
would then be the src routing information, or any additional netfilter
setting. ]
Selecting the source address according to outgoing parameters
(destination network, destination protocol, for example, but it could be
running uid/gid with advanced netfilter rules) is kind of handy when you
want to have dedicated addresses for, say, outgoing SMTP, outgoing HTTP,
outgoing SSH and so on..
This is especially true with IPv6: the default allocated size is at
least 16 billions billions IP addresses. Being able to use more than one
address per server is then kind of handy.
Binding to a special IP address for outgoing connections is difficult in
most cases, because the application would have to do the logic the
kernel is computing normally (destination on local network ? or on the
same interface ..) and would prevent proper use when multiple
interfaces/networks are in use.
The simplest way to achieve that would be to build a dedicated route for
a specific netblock, for example (this would not solve the
"per-destination-protocol" case, but this is a beginning). As I said
before, it unfortunately does not work.
Note that:
- Marking packets and using policy-based routing is not possible either
(as I understood, the source address has already been computed at this
point and the packet is built, so this is too late)
- Source NATing is also impossible (not implemented on IPv6)
- The /etc/gai.conf tuning file is no help for this purpose either.
I understand this is not a major kernel issue, but this is a really
annoying limitation when you have an almost infinite address space unused :)
[ Note: see also "src attribute ignored for IPv6 (preferred source
address selection)" in linux-netdev mailing-list one year ago. ]
^ permalink raw reply
* Re: [PATCH 1/2] iwlegacy: change IWL_WARN to IWL_DEBUG_HT in iwl4965_tx_agg_start
From: Greg Dietsche @ 2011-09-18 14:41 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20110908161129.GC2195@redhat.com>
On Thu, 8 Sep 2011 18:11:30 +0200, Stanislaw Gruszka wrote:
<snip>
> The second patch is ok. I'm not sure about first one, but we can get
> rid of "ctx = il_rxon_ctx_from_vif(vif)" at all, because we have
> only one context. Removing il_rxon_context structure from
> iwlegacy driver is my long term plan, you can look at that
> if you wish.
Sounds good. I'll let you know if I start to remove the il_rxon_context
structure. It looks right now like I might not have much free time in
the near future.
Greg
^ permalink raw reply
* (unknown)
From: Mrs. Tessy Brown @ 2011-09-18 13:54 UTC (permalink / raw)
Win $500,000 in Coca Cola Company @West Africa end of year
promo.To qualify, Email the correct answer to the question given below
to Mr. Frank Morris via(frankmorris10@ymail.com)
Question: Who won the 2010 FIFA World Cup in South Africa?
(A)England (B)Spain (C)Germany (D)Brazil.
^ permalink raw reply
* [PATCH 4/4] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-18 11:54 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316346852-17090-1-git-send-email-shawn.guo@linaro.org>
The imx6q enet is a derivative of imx28 enet controller. It fixed
the frame endian issue found on imx28, and added 1 Gbps support.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/Kconfig | 3 +-
drivers/net/fec.c | 59 +++++++++++++++++++++++++++++++++++++++++---------
2 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 8d0314d..fb38962 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1937,8 +1937,7 @@ config DECLANCE
config FEC
bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on M523x || M527x || M5272 || M528x || M520x || M532x || \
- IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC
- default IMX_HAVE_PLATFORM_FEC || MXS_HAVE_PLATFORM_FEC if ARM
+ ARCH_MXC || ARCH_MXS
select PHYLIB
help
Say Y here if you want to use the built-in 10/100 Fast ethernet
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 04206e4..849cb0b 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -18,7 +18,7 @@
* Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
* Copyright (c) 2004-2006 Macq Electronique SA.
*
- * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc.
*/
#include <linux/module.h>
@@ -72,6 +72,10 @@
#define FEC_QUIRK_SWAP_FRAME (1 << 1)
/* Controller uses gasket */
#define FEC_QUIRK_USE_GASKET (1 << 2)
+/* Controller has GBIT support */
+#define FEC_QUIRK_HAS_GBIT (1 << 3)
+/* Controller's phy_speed bit field need to minus one */
+#define FEC_QUIRK_PHY_SPEED_MINUS_ONE (1 << 4)
static struct platform_device_id fec_devtype[] = {
{
@@ -88,6 +92,10 @@ static struct platform_device_id fec_devtype[] = {
.name = "imx28-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME,
}, {
+ .name = "imx6q-fec",
+ .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT |
+ FEC_QUIRK_PHY_SPEED_MINUS_ONE,
+ }, {
/* sentinel */
}
};
@@ -97,12 +105,14 @@ enum imx_fec_type {
IMX25_FEC = 1, /* runs on i.mx25/50/53 */
IMX27_FEC, /* runs on i.mx27/35/51 */
IMX28_FEC,
+ IMX6Q_FEC,
};
static const struct of_device_id fec_dt_ids[] = {
{ .compatible = "fsl,imx25-fec", .data = &fec_devtype[IMX25_FEC], },
{ .compatible = "fsl,imx27-fec", .data = &fec_devtype[IMX27_FEC], },
{ .compatible = "fsl,imx28-fec", .data = &fec_devtype[IMX28_FEC], },
+ { .compatible = "fsl,imx6q-fec", .data = &fec_devtype[IMX6Q_FEC], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, fec_dt_ids);
@@ -373,6 +383,7 @@ fec_restart(struct net_device *ndev, int duplex)
int i;
u32 temp_mac[2];
u32 rcntl = OPT_FRAME_SIZE | 0x04;
+ u32 ecntl = 0x2; /* ETHEREN */
/* Whack a reset. We should wait for this. */
writel(1, fep->hwp + FEC_ECNTRL);
@@ -442,18 +453,23 @@ fec_restart(struct net_device *ndev, int duplex)
/* Enable flow control and length check */
rcntl |= 0x40000000 | 0x00000020;
- /* MII or RMII */
+ /* RGMII, RMII or MII */
+ if (fep->phy_interface == PHY_INTERFACE_MODE_RGMII)
+ rcntl |= (1 << 6);
if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
rcntl |= (1 << 8);
else
rcntl &= ~(1 << 8);
- /* 10M or 100M */
- if (fep->phy_dev && fep->phy_dev->speed == SPEED_100)
- rcntl &= ~(1 << 9);
- else
- rcntl |= (1 << 9);
-
+ /* 1G, 100M or 10M */
+ if (fep->phy_dev) {
+ if (fep->phy_dev->speed == SPEED_1000)
+ ecntl |= (1 << 8);
+ else if (fep->phy_dev->speed == SPEED_100)
+ rcntl &= ~(1 << 9);
+ else
+ rcntl |= (1 << 9);
+ }
} else {
#ifdef FEC_MIIGSK_ENR
if (id_entry->driver_data & FEC_QUIRK_USE_GASKET) {
@@ -478,8 +494,15 @@ fec_restart(struct net_device *ndev, int duplex)
}
writel(rcntl, fep->hwp + FEC_R_CNTRL);
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
+ /* enable ENET endian swap */
+ ecntl |= (1 << 8);
+ /* enable ENET store and forward mode */
+ writel(1 << 8, fep->hwp + FEC_X_WMRK);
+ }
+
/* And last, enable the transmit and receive processing */
- writel(2, fep->hwp + FEC_ECNTRL);
+ writel(ecntl, fep->hwp + FEC_ECNTRL);
writel(0, fep->hwp + FEC_R_DES_ACTIVE);
/* Enable interrupts we wish to service */
@@ -490,6 +513,8 @@ static void
fec_stop(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
/* We cannot expect a graceful transmit stop without link !!! */
if (fep->link) {
@@ -504,6 +529,10 @@ fec_stop(struct net_device *ndev)
udelay(10);
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+
+ /* We have to keep ENET enabled to have MII interrupt stay working */
+ if (id_entry->driver_data & FEC_QUIRK_ENET_MAC)
+ writel(2, fep->hwp + FEC_ECNTRL);
}
@@ -918,6 +947,8 @@ static int fec_enet_mdio_reset(struct mii_bus *bus)
static int fec_enet_mii_probe(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(fep->pdev);
struct phy_device *phy_dev = NULL;
char mdio_bus_id[MII_BUS_ID_SIZE];
char phy_name[MII_BUS_ID_SIZE + 3];
@@ -949,14 +980,18 @@ static int fec_enet_mii_probe(struct net_device *ndev)
snprintf(phy_name, MII_BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id, phy_id);
phy_dev = phy_connect(ndev, phy_name, &fec_enet_adjust_link, 0,
- PHY_INTERFACE_MODE_MII);
+ fep->phy_interface);
if (IS_ERR(phy_dev)) {
printk(KERN_ERR "%s: could not attach to PHY\n", ndev->name);
return PTR_ERR(phy_dev);
}
/* mask with MAC supported features */
- phy_dev->supported &= PHY_BASIC_FEATURES;
+ if (id_entry->driver_data & FEC_QUIRK_HAS_GBIT)
+ phy_dev->supported &= PHY_GBIT_FEATURES;
+ else
+ phy_dev->supported &= PHY_BASIC_FEATURES;
+
phy_dev->advertising = phy_dev->supported;
fep->phy_dev = phy_dev;
@@ -1008,6 +1043,8 @@ static int fec_enet_mii_init(struct platform_device *pdev)
* Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
*/
fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
+ if (id_entry->driver_data & FEC_QUIRK_PHY_SPEED_MINUS_ONE)
+ fep->phy_speed--;
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
fep->mii_bus = mdiobus_alloc();
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Shawn Guo @ 2011-09-18 11:54 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, linux-arm-kernel, patches, Shawn Guo
In-Reply-To: <1316346852-17090-1-git-send-email-shawn.guo@linaro.org>
With the unnecessary 1 bit left-shift on fep->phy_speed during the
calculation, the phy_speed always runs at the half frequency of the
optimal one 2.5 MHz.
The patch removes that 1 bit left-shift to get the optimal phy_speed.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
drivers/net/fec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 5ef0e34..04206e4 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
/*
* Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
*/
- fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000) << 1;
+ fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
fep->mii_bus = mdiobus_alloc();
--
1.7.4.1
^ 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