* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Ben Hutchings @ 2013-11-05 23:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alistair Popple, netdev, linuxppc-dev, David S. Miller
In-Reply-To: <1383681240.4776.97.camel@pasglop>
On Wed, 2013-11-06 at 06:54 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-11-05 at 18:16 +0000, Ben Hutchings wrote:
> > On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
> > [...]
> > > --- a/drivers/net/ethernet/ibm/emac/Kconfig
> > > +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> > > @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> > > bool
> > > default n
> > >
> > > +config IBM_EMAC_RGMII_WOL
> > > + bool
> > > + default n
> > > +
> > [...]
> >
> > So no-one can even build-test this at present!
>
> Patch 7/7 adds the select to the platform, isn't that sufficient ?
I suppose so, but I don't think that went to netdev.
> It's an SoC bit so there's little point making it generally
> selectable by the user.
I think a better way to do this is:
config IBM_EMAC_RGMII_WOL
bool "IBM EMAC RGMII wake-on-LAN support"
depends on MY_WONDERFUL_NEW_SOC || COMPILE_TEST
default y if MY_WONDERFUL_NEW_SOC
Then anyone making an API change that affects this driver can check that
it still complies.
Ben.
> Alistair: The commit name should be different, it's not a PHY you are
> adding, it's a PHY interface (the PHY itself is off chip).
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Jason Cooper @ 2013-11-05 23:00 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <87sivacxcf.fsf@natisbad.org>
On Tue, Nov 05, 2013 at 11:12:00PM +0100, Arnaud Ebalard wrote:
> Hi Jason,
>
> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
>
> > Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
> > present' made the call to phy_scan optional, if the DT has a link to
> > the phy node.
> >
> > However phy_scan has the side effect of calling phy_addr_set, which
> > writes the phy MDIO address to the ethernet controller. If phy_addr_set
> > is not called, and the bootloader has not set the correct address then
> > the driver will fail to function.
>
> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
> (Armada 370 based) which I had put on a todo list and temporarily
readynas duo v2?
thx,
Jason.
> workarounded by including a 'ping whatever' call in my u-boot env in
> order to force it to do the init. Without it, I was unable to properly
> use the interface. With your fix, after multiple reboots to test it,
> everything works as expected. So, FWIW:
>
> Tested-by: Arnaud Ebalard <arno@natisbad.org>
>
> Cheers,
>
> a+
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Sebastian Hesselbarth @ 2013-11-05 22:17 UTC (permalink / raw)
To: Arnaud Ebalard, Jason Gunthorpe
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel, linux-arm-kernel,
Benjamin Herrenschmidt, linuxppc-dev, David Miller,
Lennert Buytenhek
In-Reply-To: <87sivacxcf.fsf@natisbad.org>
On 11/05/2013 11:12 PM, Arnaud Ebalard wrote:
> Hi Jason,
>
> Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
>
>> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
>> present' made the call to phy_scan optional, if the DT has a link to
>> the phy node.
>>
>> However phy_scan has the side effect of calling phy_addr_set, which
>> writes the phy MDIO address to the ethernet controller. If phy_addr_set
>> is not called, and the bootloader has not set the correct address then
>> the driver will fail to function.
>
> Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
> (Armada 370 based) which I had put on a todo list and temporarily
Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta,
are you sure it is (was) related to Jason's fix?
Sebastian
> workarounded by including a 'ping whatever' call in my u-boot env in
> order to force it to do the init. Without it, I was unable to properly
> use the interface. With your fix, after multiple reboots to test it,
> everything works as expected. So, FWIW:
>
> Tested-by: Arnaud Ebalard <arno@natisbad.org>
^ permalink raw reply
* [PATCH net-next trivial] udp: Remove unnecessary semicolon from do{}while (0) macro
From: Joe Perches @ 2013-11-05 22:13 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, LKML
Just an unnecessary semicolon that should be removed...
Whitespace neatening of macro too.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/net/udp.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/net/udp.h b/include/net/udp.h
index fe4ba9f..a24f0f3 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -230,13 +230,13 @@ struct sock *__udp6_lib_lookup(struct net *net,
} while(0)
#if IS_ENABLED(CONFIG_IPV6)
-#define UDPX_INC_STATS_BH(sk, field) \
- do { \
- if ((sk)->sk_family == AF_INET) \
- UDP_INC_STATS_BH(sock_net(sk), field, 0); \
- else \
- UDP6_INC_STATS_BH(sock_net(sk), field, 0); \
- } while (0);
+#define UDPX_INC_STATS_BH(sk, field) \
+do { \
+ if ((sk)->sk_family == AF_INET) \
+ UDP_INC_STATS_BH(sock_net(sk), field, 0); \
+ else \
+ UDP6_INC_STATS_BH(sock_net(sk), field, 0); \
+} while (0)
#else
#define UDPX_INC_STATS_BH(sk, field) UDP_INC_STATS_BH(sock_net(sk), field, 0)
#endif
^ permalink raw reply related
* Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
From: Arnaud Ebalard @ 2013-11-05 22:12 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel,
Lennert Buytenhek, Benjamin Herrenschmidt, linuxppc-dev,
David Miller, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <1383611239-14556-1-git-send-email-jgunthorpe@obsidianresearch.com>
Hi Jason,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> writes:
> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
> present' made the call to phy_scan optional, if the DT has a link to
> the phy node.
>
> However phy_scan has the side effect of calling phy_addr_set, which
> writes the phy MDIO address to the ethernet controller. If phy_addr_set
> is not called, and the bootloader has not set the correct address then
> the driver will fail to function.
Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102
(Armada 370 based) which I had put on a todo list and temporarily
workarounded by including a 'ping whatever' call in my u-boot env in
order to force it to do the init. Without it, I was unable to properly
use the interface. With your fix, after multiple reboots to test it,
everything works as expected. So, FWIW:
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Cheers,
a+
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Patrick McHardy @ 2013-11-05 22:02 UTC (permalink / raw)
To: Jiri Pirko
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105205520.GD2438@minipsycho.orion>
On Tue, Nov 05, 2013 at 09:55:20PM +0100, Jiri Pirko wrote:
> Tue, Nov 05, 2013 at 07:16:33PM CET, kaber@trash.net wrote:
>
> >> I'm a bit lost. What "nfct_frag" are you reffering to here?
> >
> >I meant nfct_reasm of course.
>
> The patch is not moving this to struct sk_buff. It is already there.
Right again, sorry, I was replying to Florian's mail without the
quoted patch, so I seem to have mixed up things in between :)
> >> >So if someone wants to change this, simply *only* pass the reassembled
> >> >packet through the netfilter hooks and drop the fragments, as in IPv4.
> >>
> >> This is unfortunatelly not possible because in forwarding use case, the
> >> fragments have to be send out as they come in.
> >
> >No, the IPv6 NAT patches fixed that, we still do proper refragmentation
> >and we still respect the original fragment sizes, thus are not responsible
> >for potentially exceeding the PMTU on the following path.
>
> Ok. So the plan is to remove net/ipv6/netfilter/nf_conntrack_reasm.c
> code entirely and use net/ipv6/reassembly.c code directly from
> nf_defrag_ipv6. This would result in very similar code currently ipv4
> has.
If its possible to use net/ipv6/reassembly.c directly, even better,
so far I was thinking of just getting rid of the fragment replay,
but you're most likely right that this is the proper way to do it.
^ permalink raw reply
* Re: [PATCH v2] can: add Renesas R-Car CAN driver
From: Sergei Shtylyov @ 2013-11-05 22:59 UTC (permalink / raw)
To: Wolfgang Grandegger, netdev, mkl, linux-can; +Cc: linux-sh, vksavl
In-Reply-To: <5276A63E.3070505@grandegger.com>
Hello.
On 11/03/2013 10:38 PM, Wolfgang Grandegger wrote:
>>>> Add support for the CAN controller found in Renesas R-Car SoCs.
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> [...]
>>>> Index: linux-can-next/drivers/net/can/rcar_can.c
>>>> ===================================================================
>>>> --- /dev/null
>>>> +++ linux-can-next/drivers/net/can/rcar_can.c
>>>> @@ -0,0 +1,920 @@
>> [...]
>>>> + rcar_can_writeb(priv, RCAR_CAN_ECSR, (u8)~ECSR_ADEF);
>>> Please avoid casts here and below.
>> These casts help avoid compiler warnings.
> Well instead of using casts the declaration of ECSR_ADEF and otheres
> should be fixed. I think the problem is that BIT is declared as shown below:
> #define BIT(nr) (1UL << (nr))
> Using BIT seems not appropriate here.
Well, I thought it was designed to replace explicit (1 << (nr)) #define's.
Hopefully those are good for you then...
> Wolfgang,
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] ipv6: drop the judgement in rt6_alloc_cow()
From: Hannes Frederic Sowa @ 2013-11-05 21:23 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <5278837D.7030207@cn.fujitsu.com>
On Tue, Nov 05, 2013 at 01:34:53PM +0800, Duan Jiong wrote:
>
> Now rt6_alloc_cow() is only called by ip6_pol_route() when
> rt->rt6i_flags doesn't contain both RTF_NONEXTHOP and RTF_GATEWAY,
> and rt->rt6i_flags hasn't been changed in ip6_rt_copy().
> So there is no neccessary to judge whether rt->rt6i_flags contains
> RTF_GATEWAY or not.
This is ok.
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
Hannes
^ permalink raw reply
* [PATCH 1/3] rtlwifi: rtl8192se: Fix incorrect signal strength for unassociated AP
From: Larry Finger @ 2013-11-05 21:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Stable
In-Reply-To: <1383686130-5113-1-git-send-email-Larry.Finger@lwfinger.net>
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=63881.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Matthieu Baerts <matttbe@gmail.com>
Cc: Stable <stable@vger.kernel.org> [3.0 +]
---
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
index 222d2e7..27efbcd 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
@@ -329,7 +329,7 @@ bool rtl92se_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
}
/*rx_status->qual = stats->signal; */
- rx_status->signal = stats->rssi + 10;
+ rx_status->signal = stats->recvsignalpower + 10;
return true;
}
--
1.8.4
^ permalink raw reply related
* [PATCH 0/3] Fix incorrect returned signal strengths
From: Larry Finger @ 2013-11-05 21:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev
In rtl8192se, rtl8192cu, and rtl8192du, the routines that process the
received frames get the signal strength from the RSSI value. Unfortunately,
that value is non-zero only if the interface is associated with the AP. As
a result, scans return incorrect values for the strength, which causes
unwanted attempts to roam.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Larry Finger (3):
rtlwifi: rtl8192se: Fix incorrect signal strength for unassociated AP
rtlwifi: rtl8192cu: Fix incorrect signal strength for unassociated AP
rtlwifi: rtl8192de: Fix incorrect signal strength for unassociated AP
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192de/trx.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192se/trx.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--
1.8.4
^ permalink raw reply
* [PATCH 3/3] rtlwifi: rtl8192de: Fix incorrect signal strength for unassociated AP
From: Larry Finger @ 2013-11-05 21:15 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA, Stable
In-Reply-To: <1383686130-5113-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> [3.1+]
---
drivers/net/wireless/rtlwifi/rtl8192de/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/trx.c b/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
index 945ddec..0eb0f4a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/trx.c
@@ -525,7 +525,7 @@ bool rtl92de_rx_query_desc(struct ieee80211_hw *hw, struct rtl_stats *stats,
p_drvinfo);
}
/*rx_status->qual = stats->signal; */
- rx_status->signal = stats->rssi + 10;
+ rx_status->signal = stats->recvsignalpower + 10;
return true;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] rtlwifi: rtl8192cu: Fix incorrect signal strength for unassociated AP
From: Larry Finger @ 2013-11-05 21:15 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Larry Finger,
netdev-u79uwXL29TY76Z2rM5mHXA, Stable
In-Reply-To: <1383686130-5113-1-git-send-email-Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
The routine that processes received frames was returning the RSSI value for the
signal strength; however, that value is available only for associated APs. As
a result, the strength was the absurd value of 10 dBm. As a result, scans
return incorrect values for the strength, which causes unwanted attempts to roam.
Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: Stable <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> [2.6.39+]
---
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
index 25e50ff..b0c346a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
@@ -349,7 +349,7 @@ bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
p_drvinfo);
}
/*rx_status->qual = stats->signal; */
- rx_status->signal = stats->rssi + 10;
+ rx_status->signal = stats->recvsignalpower + 10;
return true;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-11-05 21:11 UTC (permalink / raw)
To: David Laight
Cc: nicolas.dichtel, David Miller, jiri, vyasevich, netdev, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73E2@saturn3.aculab.com>
On Tue, Nov 05, 2013 at 05:12:46PM -0000, David Laight wrote:
> > From: Nicolas Dichtel [mailto:nicolas.dichtel@6wind.com]
> ...
> > If I remember well, another problem is to be able to send these packets with
> > 0.0.0.0 when another IP address is available on the system:
> >
> > RFC2131
> > 4.1 Constructing and sending DHCP messages
> > ...
> > DHCP messages broadcast by a client prior to that client obtaining
> > its IP address must have the source address field in the IP header
> > set to 0.
> >
> > We made a patch (never proposed upstream) to add a socket option to keep
> > this 0.0.0.0 address.
> > If people are interested, I can try to port it on net-next.
>
> Really, what dhcp does before the interface has an address doesn't
> really matter - using bpf isn't a problem.
>
> What it needs to do is switch to using a normal socket for the renewals.
>
> Maybe I'll try asking Roy about it on the NetBSD lists.
I would do the full switch to UDP sockets. It is much easier to accomplish
in the isc-dhcp codebase. It is e.g. already implemented and used e.g. by
Solaris. I would just have to wire up Nicolas INADDR_ANY source patch.
By the way:
Although dhclient uses an AF_PACKET socket, it never does request
additional multicast addresses or promisc mode. So the only overhead is
that we have to run the socket filter on each incoming packet.
Greetings,
Hannes
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Hannes Frederic Sowa @ 2013-11-05 20:57 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: David Laight, David Miller, jiri, vyasevich, netdev, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <52792499.3030201@6wind.com>
On Tue, Nov 05, 2013 at 06:02:17PM +0100, Nicolas Dichtel wrote:
> Le 29/10/2013 13:40, Hannes Frederic Sowa a écrit :
> >On Tue, Oct 29, 2013 at 09:37:06AM -0000, David Laight wrote:
> >>>Note that you don't even need to put the DHCP protocol core into the
> >>>kernel to fix the promiscuous problem. You just have to use the
> >>>current kernel interfaces correctly.
> >>>
> >>>It used to be the case a very long time ago that you couldn't even
> >>>receive broadcast UDP datagrams on a socket until an address was
> >>>configured on it.
> >>>
> >>>So everyone turns on promiscuous mode and uses RAW sockets or
> >>>AF_PACKET.
> >>>
> >>>Stupid? yes.
> >>
> >>Not only that, but the dhcp client could use a normal UDP socket
> >>to keep the lease renewed - I suspect it has only ever needed
> >>to use the BPF interface (I didn't think it set promiscuous)
> >>when acquiring the initial lease.
> >
> >Yes, this is a very unfortunate situation. From my experience it is not
> >that
> >easy to get a patch merged into isc-dhcp.
> >
> >It seems not that invasive to switch from af_packet to an udp socket with
> >SO_BROADCAST set.
> If I remember well, another problem is to be able to send these packets with
> 0.0.0.0 when another IP address is available on the system:
>
> RFC2131
> 4.1 Constructing and sending DHCP messages
> ...
> DHCP messages broadcast by a client prior to that client obtaining
> its IP address must have the source address field in the IP header
> set to 0.
>
> We made a patch (never proposed upstream) to add a socket option to keep
> this 0.0.0.0 address.
> If people are interested, I can try to port it on net-next.
Yes, this indeed is a problem for a socket only dhcp client. I would make the
appropriate changes to isc-dhcp if you submit such a patch.
Thanks,
Hannes
^ permalink raw reply
* Re: [patch v2] mlx5_core: delete some dead code
From: David Miller @ 2013-11-05 20:51 UTC (permalink / raw)
To: dan.carpenter; +Cc: eli, netdev, linux-rdma, kernel-janitors
In-Reply-To: <20131104222056.GA4248@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 5 Nov 2013 01:20:56 +0300
> The printk() looks like it is left over debug code. I have removed it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: Remove the printk instead of moving it infront of the return.
This doesn't apply to the current tree, I suspect some recent changes made
this fix no longer applicable. Please take a look.
Thanks!
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Jiri Pirko @ 2013-11-05 20:55 UTC (permalink / raw)
To: Patrick McHardy
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105181633.GA7435@macbook.localnet>
Tue, Nov 05, 2013 at 07:16:33PM CET, kaber@trash.net wrote:
>On Tue, Nov 05, 2013 at 04:01:15PM +0100, Jiri Pirko wrote:
>> Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
>> >On Tue, Nov 05, 2013 at 02:32:05PM +0100, Florian Westphal wrote:
>> >> Jiri Pirko <jiri@resnulli.us> wrote:
>> >> > This patch fixes for example following situation:
>> >> > On HOSTA do:
>> >> > ip6tables -I INPUT -p icmpv6 -j DROP
>> >> > ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> >>
>> >> untested:
>> >>
>> >> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> >> -A INPUT -p icmpv6 -m conntrack --ctstatus CONFIRMED -j ACCEPT
>> >> -A INPUT -p icmpv6 -j DROP
>> >>
>> >> > and on HOSTB you do:
>> >> > ping6 HOSTA -s2000 (MTU is 1500)
>> >> >
>> >> > Incoming echo requests will be filtered out on HOSTA. This issue does
>> >> > not occur with smaller packets than MTU (where fragmentation does not happen).
>> >>
>> >> Patrick, any reason not to kill the special-casing (ct has assigned helper or
>> >> unconfirmed conntrack) in __ipv6_conntrack_in() ?
>> >>
>> >> This should make ipv6 frag behaviour consistent; right now its rather
>> >> confusing from ruleset point of view, especially the first packet
>> >> of a connection is always seen as reassembled.
>> >>
>> >> So with Jiris rules
>> >>
>> >> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> >> -A INPUT -p icmpv6 -j DROP
>> >>
>> >> ping6 -s $bignum works for the first packet but not for subsequent ones
>> >> which is quite irritating.
>> >
>> >Well, the reason was to avoid unnecessary work doing refragmentation
>> >unless really required. I know its rather complicated, but IPv6 has
>> >always required treating fragments manually or using conntrack state.
>> >
>> >I'm not objecting to changing this, but the patches as they are are
>> >not the way to go. First, moving nfct_frag to struct sk_buff seems
>>
>> I'm a bit lost. What "nfct_frag" are you reffering to here?
>
>I meant nfct_reasm of course.
The patch is not moving this to struct sk_buff. It is already there.
>
>> >like a real waste of space for this quite rare case. Also, we can't
>> >just use the reassembled packet in ip6tables, when modifying it we
>> >will still output the unchanged fragments. An last of all, we'll be
>> >executing the rules on the reassembled packet multiple times, one
>> >for each fragment.
>>
>> Reassembled skb would be only used for matching where no changes takes
>> place.
>
>That still doesn't work, our matches are not purely passive.
>
>> End even though, the matching is now done for each fragment skb anyway. The
>> change is only to do it on different skb. I see no erformance or any
>> other problem in that.
>
>Accounting, quota, statistic, limit, ... come to mind. Basically any
>match that keeps state.
Ok. Makes sense.
>
>> >So if someone wants to change this, simply *only* pass the reassembled
>> >packet through the netfilter hooks and drop the fragments, as in IPv4.
>>
>> This is unfortunatelly not possible because in forwarding use case, the
>> fragments have to be send out as they come in.
>
>No, the IPv6 NAT patches fixed that, we still do proper refragmentation
>and we still respect the original fragment sizes, thus are not responsible
>for potentially exceeding the PMTU on the following path.
Ok. So the plan is to remove net/ipv6/netfilter/nf_conntrack_reasm.c
code entirely and use net/ipv6/reassembly.c code directly from
nf_defrag_ipv6. This would result in very similar code currently ipv4
has.
^ permalink raw reply
* Re: [PATCH v2 2/2] ixgbe: enable l2 forwarding acceleration for macvlans
From: Neil Horman @ 2013-11-05 20:52 UTC (permalink / raw)
To: John Fastabend; +Cc: alexander.h.duyck, netdev, andy, davem, jeffrey.t.kirsher
In-Reply-To: <5279566E.6030807@intel.com>
On Tue, Nov 05, 2013 at 12:34:54PM -0800, John Fastabend wrote:
> On 11/5/2013 6:26 AM, Neil Horman wrote:
> >On Mon, Nov 04, 2013 at 11:01:55AM -0800, John Fastabend wrote:
> >>Now that l2 acceleration ops are in place from the prior patch,
> >>enable ixgbe to take advantage of these operations. Allow it to
> >>allocate queues for a macvlan so that when we transmit a frame,
> >>we can do the switching in hardware inside the ixgbe card, rather
> >>than in software.
> >>
> >>For now this patch limits the hardware to 8 offloaded macvlan ports.
> >>A follow on patch will remove this limitation but to simplify
> >>review/validation of the new macvlan offload ops we leave it at 8
> >>for now.
> >>
> >>Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> >>CC: Andy Gospodarek <andy@greyhouse.net>
> >>CC: "David S. Miller" <davem@davemloft.net>
> >
> >A few Nits, since you're going to send a V3 anyway. Comments inline.
> >
> >>---
>
>
> [...]
>
> >Nit: You're using macvlan here, and vsi above. Might be nice to give everything
> >a consistent suffix/prefix for clarity. Perhaps dfwd since thats what the new
> >ndo_ops uses?
> >
>
> using dfwd now.
>
> >><snip>
> >
> >> static inline bool ixgbe_is_sfp(struct ixgbe_hw *hw)
> >>@@ -4317,6 +4521,8 @@ static void ixgbe_setup_gpie(struct ixgbe_adapter *adapter)
> >> static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
> >> {
> >> struct ixgbe_hw *hw = &adapter->hw;
> >>+ struct net_device *upper;
> >>+ struct list_head *iter;
> >> int err;
> >> u32 ctrl_ext;
> >>
> >>@@ -4360,6 +4566,16 @@ static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
> >> /* enable transmits */
> >> netif_tx_start_all_queues(adapter->netdev);
> >>
> >>+ /* enable any upper devices */
> >>+ netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
> >>+ if (netif_is_macvlan(upper)) {
> >>+ struct macvlan_dev *vlan = netdev_priv(upper);
> >>+
> >>+ if (vlan->fwd_priv)
> >>+ netif_tx_start_all_queues(upper);
> >>+ }
> >>+ }
> >>+
> >I don't think it matters much, but do we want to start the upper devs queues
> >here unilaterally? Nominally a network interface starts its queues on dev_open.
> >Would it be better to only start those devices if (vlan->fwd_priv &&
> >(upper->flags & IFF_UP)? We would then have to listen for NETDEV_UP events as
> >well to handle accelerated macvlans comming up after ixgbe does, which is more
> >work, but I wanted to mention this in case theres some disadvantage to starting
> >the queue early.
> >
>
> vlan->fwd_priv is set in macvlan_open() and cleared in macvlan_close()
> and serialized with the rtnl lock. So I think anytime you get here and
> have vlan->fwd_priv non-null its the same as IFF_UP being set.
>
> The only call sites I see changing the IFF_UP flag are dev_open() and
> dev_close() and derivatives. Each calls ndo_open and ndo_close. So
> assuming I didn't miss some call sites the above seems correct.
>
> >
> >Other than that I think it looks good though. Nice work!
> >
>
> Great thanks for looking it over. I should have v3 out here shortly
> doing a couple more tests for feature interop.
>
Copy that, I'll sign off on that version
Neil
> >Regards
> >Neil
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
^ permalink raw reply
* [PATCH] wcn36xx: Fix logging macro with unnecessary semicolon
From: Joe Perches @ 2013-11-05 20:40 UTC (permalink / raw)
To: Eugene Krasnikov
Cc: John W. Linville, wcn36xx-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The wcn36xx_err macro should not end in a semicolon as
there are 2 consecutive semicolons in the preprocessed
output.
Remove it.
Neaten the logging macros to use a more common style.
Convert to use pr_debug to enable dynamic debug.
Signed-off-by: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 58b6383..d157bb7 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -53,22 +53,20 @@ enum wcn36xx_debug_mask {
WCN36XX_DBG_ANY = 0xffffffff,
};
-#define wcn36xx_err(fmt, arg...) \
- printk(KERN_ERR pr_fmt("ERROR " fmt), ##arg);
-
-#define wcn36xx_warn(fmt, arg...) \
- printk(KERN_WARNING pr_fmt("WARNING " fmt), ##arg)
-
-#define wcn36xx_info(fmt, arg...) \
- printk(KERN_INFO pr_fmt(fmt), ##arg)
-
-#define wcn36xx_dbg(mask, fmt, arg...) do { \
- if (wcn36xx_dbg_mask & mask) \
- printk(KERN_DEBUG pr_fmt(fmt), ##arg); \
+#define wcn36xx_err(fmt, ...) \
+ pr_err("ERROR " fmt, ##__VA_ARGS__)
+#define wcn36xx_warn(fmt, ...) \
+ pr_warn("WARNING " fmt, ##__VA_ARGS__)
+#define wcn36xx_info(fmt, ...) \
+ pr_info(fmt, ##__VA_ARGS__)
+#define wcn36xx_dbg(mask, fmt, ...) \
+do { \
+ if (wcn36xx_dbg_mask & mask) \
+ pr_debug(fmt, ##__VA_ARGS__); \
} while (0)
^ permalink raw reply related
* Re: [PATCH v2 2/2] ixgbe: enable l2 forwarding acceleration for macvlans
From: John Fastabend @ 2013-11-05 20:34 UTC (permalink / raw)
To: Neil Horman; +Cc: alexander.h.duyck, netdev, andy, davem, jeffrey.t.kirsher
In-Reply-To: <20131105142631.GB14954@hmsreliant.think-freely.org>
On 11/5/2013 6:26 AM, Neil Horman wrote:
> On Mon, Nov 04, 2013 at 11:01:55AM -0800, John Fastabend wrote:
>> Now that l2 acceleration ops are in place from the prior patch,
>> enable ixgbe to take advantage of these operations. Allow it to
>> allocate queues for a macvlan so that when we transmit a frame,
>> we can do the switching in hardware inside the ixgbe card, rather
>> than in software.
>>
>> For now this patch limits the hardware to 8 offloaded macvlan ports.
>> A follow on patch will remove this limitation but to simplify
>> review/validation of the new macvlan offload ops we leave it at 8
>> for now.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> CC: Andy Gospodarek <andy@greyhouse.net>
>> CC: "David S. Miller" <davem@davemloft.net>
>
> A few Nits, since you're going to send a V3 anyway. Comments inline.
>
>> ---
[...]
> Nit: You're using macvlan here, and vsi above. Might be nice to give everything
> a consistent suffix/prefix for clarity. Perhaps dfwd since thats what the new
> ndo_ops uses?
>
using dfwd now.
>> <snip>
>
>> static inline bool ixgbe_is_sfp(struct ixgbe_hw *hw)
>> @@ -4317,6 +4521,8 @@ static void ixgbe_setup_gpie(struct ixgbe_adapter *adapter)
>> static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
>> {
>> struct ixgbe_hw *hw = &adapter->hw;
>> + struct net_device *upper;
>> + struct list_head *iter;
>> int err;
>> u32 ctrl_ext;
>>
>> @@ -4360,6 +4566,16 @@ static void ixgbe_up_complete(struct ixgbe_adapter *adapter)
>> /* enable transmits */
>> netif_tx_start_all_queues(adapter->netdev);
>>
>> + /* enable any upper devices */
>> + netdev_for_each_all_upper_dev_rcu(adapter->netdev, upper, iter) {
>> + if (netif_is_macvlan(upper)) {
>> + struct macvlan_dev *vlan = netdev_priv(upper);
>> +
>> + if (vlan->fwd_priv)
>> + netif_tx_start_all_queues(upper);
>> + }
>> + }
>> +
> I don't think it matters much, but do we want to start the upper devs queues
> here unilaterally? Nominally a network interface starts its queues on dev_open.
> Would it be better to only start those devices if (vlan->fwd_priv &&
> (upper->flags & IFF_UP)? We would then have to listen for NETDEV_UP events as
> well to handle accelerated macvlans comming up after ixgbe does, which is more
> work, but I wanted to mention this in case theres some disadvantage to starting
> the queue early.
>
vlan->fwd_priv is set in macvlan_open() and cleared in macvlan_close()
and serialized with the rtnl lock. So I think anytime you get here and
have vlan->fwd_priv non-null its the same as IFF_UP being set.
The only call sites I see changing the IFF_UP flag are dev_open() and
dev_close() and derivatives. Each calls ndo_open and ndo_close. So
assuming I didn't miss some call sites the above seems correct.
>
> Other than that I think it looks good though. Nice work!
>
Great thanks for looking it over. I should have v3 out here shortly
doing a couple more tests for feature interop.
> Regards
> Neil
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver
From: David Miller @ 2013-11-05 20:22 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, mrkiko.rs, oliver
In-Reply-To: <1383555049-24834-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Mon, 4 Nov 2013 09:50:46 +0100
> Enrico has been kind enough to let me repost his driver with the changes
> requested by Oliver Neukum during the last review of this series.
>
> The changes I have made from Enricos original v5 series to this version
> are:
>
> v6:
> - fix to avoid corrupting drvstate->pmcount
> - fix error return value from huawei_cdc_ncm_suspend()
> - drop redundant testing for subdriver->suspend during resume
> - broke a few lines to keep within the 80 columns recommendation
> - rebased on top of current net-next
>
> Enrico's orginal introduction to the v5 series follows below. It explains
> the background much better than I can.
Looks good, series applied, thanks!
^ permalink raw reply
* Re: [PATCH] sh_eth: call phy_scan_fixups() after PHY reset
From: Sergei Shtylyov @ 2013-11-05 20:18 UTC (permalink / raw)
To: David Miller
Cc: nobuhiro.iwamatsu.yj, netdev, linux-sh, laurent.pinchart+renesas
In-Reply-To: <5271712A.6020105@cogentembedded.com>
Hello.
On 10/30/2013 11:50 PM, Sergei Shtylyov wrote:
>>>> Sometimes the PHY reset that sh_eth_phy_start() does effects the PHY
>>>> registers
>>>> registers values of which are vital for the correct functioning of the
>>>> driver.
>>>> Unfortunately, the existing PHY platform fixup mechanism doesn't help
>>>> here as
>>>> it only hooks PHY resets done by ioctl() calls. Calling phy_scan_fixups()
>>>> from
>>>> the driver helps here. With a proper platform fixup, this fixes NFS
>>>> timeouts on
>>>> the SH-Mobile Lager board.
> Timeouts happen because of the sideband ETH_LINK signal connected to PHY's
> LED0 pin -- it bounces on/off after each packet in the default LED mode and
> that seems to hinder packet sending and/or reception...
>> "And sets the PHY LED pins to the desired mode", I should have added.
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>> The PHY layer is designed to naturally already take care of this kind of
>>> thing. I think that part of the problem is that you're fighting the
>>> natural control flow the PHY layer provides.
>>> When the phy_connect() is performed, what we end up doing is calling
>>> phy_attach_direct() which invokes the ->probe() method of the driver
>>> and then afterwards we do phy_init_hw() which takes care of doing
>>> the fixup calls.
>> Yes, I have studied the code paths beforehand.
>>> So if you really need to do a BMCR reset then run the fixups I'd like
>>> you to look into making that happen within the provided control
>>> flow rather than with an exceptional explicit call to run the fixups.
>> That could change the behavior of many Ethernet drivers in sometimes
>> unpredictable ways I think (due to extended registers the PHYs sometimes have,
>> like in this case) if you meant including the PHY reset into phylib control
>> flows. Anyway, that would have required more complex patches only good for
>> merging at the merge window time while I aimed at a quick fix for a problem at
>> hand (which is NFS timeout/slowdown and LED mode mismatch to what was designed
>> for the board).
>> Some other drivers also do reset the PHYs but usually that's accompanied
>> by a loop polling for reset completion, so a naive code like that one on the
>> phylib's ioctl() path couldn't have helped if I wanted to hook reset writes in
>> the same fashion in phy_write(). In my case reset seems just quick enough for
>> the extended PHY register reads/writes to work correctly without polling the
>> reset bit first...
>> That's why I took an easy way and used already exported phy_scan_fixups()
>> to undo what the PHY reset did to some of the PHY's registers. The question is
>> why it was exported in the first place? It doesn't seem to be used by anything
>> but phylib internally...
> Well, how about I create phy_reset() function (that will care about BMCR
> polling and calling PHY driver/fixups) that those drivers that currently do
> reset their PHYs can call (instead of open coding BMCR reset)? That way it
> seems to be less invasive than embedding PHY reset into phylib's control flow...
>>> I'm willing to be convinced that this is a better or necessary approach
>>> but you'll need to explain it to me.
David, will you ever reply to this mail?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] sh_eth: call phy_scan_fixups() after PHY reset
From: David Miller @ 2013-11-05 20:01 UTC (permalink / raw)
To: sergei.shtylyov
Cc: nobuhiro.iwamatsu.yj, netdev, linux-sh, laurent.pinchart+renesas
In-Reply-To: <52795282.20708@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 05 Nov 2013 23:18:10 +0300
> David, will you ever reply to this mail?
I really haven't had the time with my backlog, and it's been so long ago
that I've forgotten all of the context.
Sorry, someone will have to start the conversation up anew.
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Benjamin Herrenschmidt @ 2013-11-05 19:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Alistair Popple, netdev, linuxppc-dev, David S. Miller
In-Reply-To: <1383675404.2868.8.camel@bwh-desktop.uk.level5networks.com>
On Tue, 2013-11-05 at 18:16 +0000, Ben Hutchings wrote:
> On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
> [...]
> > --- a/drivers/net/ethernet/ibm/emac/Kconfig
> > +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> > @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> > bool
> > default n
> >
> > +config IBM_EMAC_RGMII_WOL
> > + bool
> > + default n
> > +
> [...]
>
> So no-one can even build-test this at present!
Patch 7/7 adds the select to the platform, isn't that sufficient ?
It's an SoC bit so there's little point making it generally
selectable by the user.
Alistair: The commit name should be different, it's not a PHY you are
adding, it's a PHY interface (the PHY itself is off chip).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: remove old conditions on flow label sharing
From: David Miller @ 2013-11-05 19:41 UTC (permalink / raw)
To: florent.fourcot; +Cc: netdev
In-Reply-To: <1383400507-12604-1-git-send-email-florent.fourcot@enst-bretagne.fr>
From: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Date: Sat, 2 Nov 2013 14:55:07 +0100
> The code of flow label in Linux Kernel follows
> the rules of RFC 1809 (an informational one) for
> conditions on flow label sharing. There rules are
> not in the last proposed standard for flow label
> (RFC 6437), or in the previous one (RFC 3697).
>
> Since this code does not follow any current or
> old standard, we can remove it.
>
> With this removal, the ipv6_opt_cmp function is
> now a dead code and it can be removed too.
>
> Changelog to v1:
> * add justification for the change
> * remove the condition on IPv6 options
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Applied, but I had to also remove ipv6_hdr_cmp() as that became unused
as well.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Florian Fainelli @ 2013-11-05 18:47 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383629471-16979-3-git-send-email-alistair@popple.id.au>
[snip]
> +/* RGMII bridge supports only GMII/TBI and RGMII/RTBI PHYs */
> +static inline int rgmii_valid_mode(int phy_mode)
> +{
> + return phy_mode == PHY_MODE_GMII ||
> + phy_mode == PHY_MODE_MII ||
> + phy_mode == PHY_MODE_RGMII ||
> + phy_mode == PHY_MODE_TBI ||
> + phy_mode == PHY_MODE_RTBI;
> +}
> +
> +static inline const char *rgmii_mode_name(int mode)
> +{
> + switch (mode) {
> + case PHY_MODE_RGMII:
> + return "RGMII";
> + case PHY_MODE_TBI:
> + return "TBI";
> + case PHY_MODE_GMII:
> + return "GMII";
> + case PHY_MODE_MII:
> + return "MII";
> + case PHY_MODE_RTBI:
> + return "RTBI";
> + default:
> + BUG();
> + }
Any reasons why you are duplicating what is available in
drivers/of/of_net.c ::of_get_phy_mode()?
--
Florian
^ 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