Re: [PATCH net-next 0/2] ovs: refresh a flow via netlink
From: Samuel Gauthier Date: Wed, 16 Mar 2016 16:07:50 +0100 > This patchset adds a netlink api to refresh an existing flow in > openvswitch. This is too late for net-next, please resubmit this after the merge window. Thanks.
Re: [PATCH 5/5] net: macb: Fix simple typo.
Le 14/03/2016 21:47, Michal Simek a écrit : > On 13.3.2016 20:10, Moritz Fischer wrote: >> Signed-off-by: Moritz Fischer >> --- >> drivers/net/ethernet/cadence/macb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/ethernet/cadence/macb.c >> b/drivers/net/ethernet/cadence/macb.c >> index a0c01e5..681e5bf 100644 >> --- a/drivers/net/ethernet/cadence/macb.c >> +++ b/drivers/net/ethernet/cadence/macb.c >> @@ -127,7 +127,7 @@ static void hw_writel(struct macb *bp, int offset, u32 >> value) >> } >> >> /* Find the CPU endianness by using the loopback bit of NCR register. When >> the >> - * CPU is in big endian we need to program swaped mode for management >> + * CPU is in big endian we need to program swapped mode for management >> * descriptor access. >> */ >> static bool hw_is_native_io(void __iomem *addr) >> > > Remove dot at the end of subject and feel free to add my: > Acked-by: Michal Simek Yes, same for me, no dot. But anyway, here is my: Acked-by: Nicolas Ferre Thanks Moritz for the patches and Michal for the reviews. Bye, -- Nicolas Ferre
[linux-next:master 8604/12950] net/openvswitch/vport-internal_dev.c:141:6: sparse: symbol 'internal_set_rx_headroom' was not declared. Should it be static?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: 5e3497cca281616e7930b74a0076b7324dcc2057 commit: 3a927bc7cf9d0fbe8f4a8189dd5f8440228f64e7 [8604/12950] ovs: propagate per dp max headroom to all vports reproduce: # apt-get install sparse git checkout 3a927bc7cf9d0fbe8f4a8189dd5f8440228f64e7 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> net/openvswitch/vport-internal_dev.c:141:6: sparse: symbol >> 'internal_set_rx_headroom' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH ethtool 2/3] Add IPv6 support to NFC
On Wed, 2016-03-16 at 14:53 +, Edward Cree wrote:
> On 13/03/16 16:43, Ben Hutchings wrote:
> >
> > On Mon, 2016-02-15 at 14:59 +, Edward Cree wrote:
> > >
> > > Signed-off-by: Edward Cree
> > [...]
> > >
> > > @@ -950,6 +1154,19 @@ static int rxclass_get_mask(char *str, unsigned
> > > char *p,
> > > *(__be32 *)&p[opt->moffset] = ~val;
> > > break;
> > > }
> > > + case OPT_IP6: {
> > > + __be32 val[4];
> > > + int i;
> > > + err = rxclass_get_ipv6(str, val);
> > > + if (err)
> > > + return -1;
> > > + for (i = 0; i < 4; i++) {
> > > + ((__be32 *)&p[opt->offset])[i] = val[i];
> > > + if (opt->moffset >= 0)
> > > + ((__be32 *)&p[opt->moffset])[i] = ~val[i];
> > This pointer arithmetic looks terrible. I think memcpy() would be much
> > clearer here.
> I've changed the version in rxclass_get_val to use memcpy() (and memset() the
> mask). Unfortunately, we can't do that here, because we need to complement
> the mask valueas we go, and afaik there's no library function to copy-and-
> complement a byte array.
Sorry, I missed the inversion. But it would still be cleaner to use a
local variable:
__be32 *field = (__be32 *)&p[opt->offset];
> Glibc does, however, have a function memfrob(), which XORs every byte of an
> arraywiththe constant 42. Useful feature, that.
It is!
#include
int main(void)
{
char answer;
memset(&answer, 0, 1);
memfrob(&answer, 1);
return answer;
}
> On the other hand, the quoted code is still wrong because it's also writing
> throughopt->offset and checking for opt->moffset>= 0, both daft copy-and-
> paste errors onmypart. Will fix in next version.
> >
> > I won't apply patches labelled as "confidential". You need to stop
> > including this nonsense in your public messages (I thought you fixed
> > this once before).
> In theory it's been fixed harder now - please let me know if not.
Looks like you're sending two copies, one with and one without. Which
works for me, though it might annoy some recipients...
Ben.
--
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] mac80211: fix order of flag descriptions
On Fri, 2016-03-18 at 16:35 +, Luis de Bethencourt wrote: > Fix order of mac80211_rx_flags description to match the enum. > > Signed-off-by: Luis de Bethencourt > --- > Hi, > > I want ahead and fixed the order of the descriptions. checkpatch.pl > was giving > a warning to my previous patch and I had a hunch it was because the > wrong order > breaks the parser. Indeed it does and with this patch below > checkpatch.pl does > not complain about this flag descriptions anymore. > Huh. I think we should fix checkpatch.pl instead. While the current order isn't likely really good, I believe kernel-doc will output the documentation in the order it's listed, and that can be useful for the documentation output to group related things, even if their bits may be further apart. johannes
Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB
Hello Sebastian,
On Fri, Mar 18, 2016 at 04:56:21PM +0100, Sebastian Frias wrote:
> On 03/18/2016 01:54 PM, Uwe Kleine-König wrote:
> > From a driver perspecitive, it would be nice if devm_gpiod_get_optional
> > returned NULL iff the respective gpio isn't specified even with
> > GPIOLIB=n, but this isn't sensible either because it would result in
> > quite some gpiolib code to not being conditionally compiled on
> > CONFIG_GPIOLIB any more.
>
> Let's say that was the case, what would the PHY code do?
With reset gpios it might not be that critical, but consider an optional
enable gpio. (Optional in the sense, that some device have it and others
don't, e.g. because the pin is pulled into active level by hardware.)
Now you do:
gpiod = gpiod_get_optional("enable");
and if gpiod now is an error pointer, you must assume that you cannot
operate the device. And even with GPIOLIB=n (and gpiod = ERR_PTR(-ENOSYS))
you cannot ignore the error. For consistency I'd recommend to do the
same for reset even though there is a chance to get a working device.
> What would you think of making at803x_link_change_notify() print a
> message every time it should do a reset but does not has a way to do it?
Then this question is obsolete because the device doesn't probe.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH] net: phy: at803x: Add support to control PHY LEDs
On Thu, Mar 17, 2016 at 02:59:07PM +0100, Vishal Thanki wrote: > The LEDs can be turned on and off by a sysfs interface > now. Write 0 to "led_enable" file to turn off the LEDs > and write 1 to turn on. The support is experimental > and can be enabled by kernel configuration option. > > Signed-off-by: Vishal Thanki > --- > drivers/net/phy/Kconfig | 7 + > drivers/net/phy/at803x.c | 71 > Hi Vishal This solution seems specific to the at803. You should be thinking of a generic solution that all PHYs can use. eg add a new callback function to phy_driver, and put the sysfs handling code in phylib. Andrew
Re: [RFCv2 0/3] mac80211: implement fq codel
On Thu, Mar 17, 2016 at 09:55:03AM +0100, Michal Kazior wrote: > If you consider Wi-Fi is half-duplex and latency in the entire stack > (for processing ICMP and UDP_RR) is greater than 11e contention window > timings you can get your BE flow responses with extra delay (since > other queues might have responses ready quicker). Got it, that makes sense. Thanks for the explanation! -- Bob Copeland %% http://bobcopeland.com/
Re: [PATCH net-next v3] rocker: add debugfs support to dump internal tables
Thu, Mar 17, 2016 at 10:25:19PM IST, and...@lunn.ch wrote: >On Thu, Mar 17, 2016 at 04:10:31PM -0400, Murali Karicheri wrote: >> David, >> >> On 08/18/2015 04:47 PM, David Miller wrote: >> > I see some drivers where the foo_debugfs.c file is larger than the rest >> > of the driver. Once people start using it, it's like crack, and they >> > dump every single debugging widget they found useful at some point into >> > there. >> > >> > This is not what we want. Most things I see in debugfs support was >> > probably useful for debugging one particular bug but then it was never >> > really useful again in the future. Those kinds of things can be done >> > locally in someone's tree. >> > >> > I often see various kinds of "statistics" ending up in these things, >> > or register dumps, both of which are 'ethtool' or similar material. >> Very late to this discussion, but I need to port some of the internal code >> to display the content of a ALE (Address Learning Engine) table maintained >> in hardwareat L2 layer. Currently I have a sysfs implementation that dumps >> information like below. >> >> root@k2e-evm:~# cat /sys/devices/platform/soc/2620110.netcp/ale_table >> index 0, raw: 07fc d000 , type: addr(1), addr: >> ff:ff:ff:ff:ff:ff, mcstate: f(3), port mask: 1ff, no super >> index 1, raw: 1800 28329a1c, type: addr(1), addr: >> 08:00:28:32:9a:1c, uctype: persistent(0), port: 0 >> index 2, raw: 07fc d100 5e01, type: addr(1), addr: >> 01:00:5e:00:00:01, mcstate: f(3), port mask: 1ff, no super >> index 19, raw: 0004 d000d4be d93db6c1, type: addr(1), addr: >> d4:be:d9:3d:b6:c1, uctype: touched(3), port: 1 >> >> What is the available interface in kernel to expose this information >> to user space as debugfs is not suggested based on this thread? > >This looks a lot like what the mv88e6xxx_port_fdb_dump() callback >returns to DSA when SWITCHDEV_OBJ_ID_PORT_FDB is passed to >switchdev_port_obj_dump() in the switchdev ops. +1 Also, Murali, using standard interfaces instead of debugfs will allow you to: 1) Upstream your code 2) Use existing tests for your code. In particular, the following (which is used for mlxsw testing): https://github.com/jpirko/lnst/blob/master/recipes/switchdev/l2-002-bridge_fdb.py There are a bunch of others there which you'll probably find useful. BTW, are you familiar with the following document? https://www.kernel.org/doc/Documentation/networking/switchdev.txt I believe it answers your question. Good luck! > > Andrew
Re: [PATCH] qmi_wwan: Added support for Gemalto's Cinterion PHxx WWAN interface
From: Schemmel Hans-Christoph Date: Thu, 17 Mar 2016 10:07:56 + > Added support for Gemalto's Cinterion PHxx WWAN interfaces > by adding QMI_FIXED_INTF with Cinterion's VID and PID. > > PHxx can have: > 2 RmNet Interfaces (PID 0x0082) or > 1 RmNet + 1 USB Audio interface (PID 0x0083). > > Signed-off-by: Hans-Christoph Schemmel Applied, thanks.
Re: [PATCH v6 net-next 2/2] tcp: Add Redundant Data Bundling (RDB)
On 14/03/16 22:15, Eric Dumazet wrote: > Acked-by: Eric Dumazet > > Note that RDB probably should get some SNMP counters, > so that we get an idea of how many times a loss could be repaired. Good idea. Simply count how many times an RDB packet successfully repaired loss? Note that this can be one or more lost packets. When bundling N packets, the RDB packet can repair up to N losses in the previous N packets that were sent. Which list should this be added to? snmp4_tcp_list? Any other counters that would be useful? Total number of RDB packets transmitted? > Ideally, if the path happens to be lossless, all these pro active > bundles are overhead. Might be useful to make RDB conditional to > tp->total_retrans or something. Yes, that is a good point. We have discussed this (for years really), but have not had the opportunity to investigate it in-depth. Having such a condition hard coded is not ideal, as it very much depends on the use case if bundling from the beginning is desirable. In most cases, this is probably a fair compromise, but preferably we would have some logic/settings to control how the bundling rate can be dynamically adjusted in response to certain events, defined by a set of given metrics. A conservative (default) setting would not do bundling until loss has been registered, and could also check against some smoothed loss indicator such that a certain amount of loss must have occurred within a specific time frame to allow bundling. This could be useful in cases where the network congestion varies greatly depending on such as the time of day/night. In a scenario where minimal application layer latency is very important, but only sporadic (single) packet loss is expected to regularly occur, always bundling one previous packet may be both sufficient and desirable. In the end, the best settings for an application/service depends on the degree to which application layer latency (both minimal and variations) affects the QoE. There are many possibilities to consider in this regard, and I expect we will not have this question fully explored any time soon. Most importantly, we should ensure that such logic can easily be added later on without breaking backwards compatibility. Suggestions and comments on this are very welcome. Bendik
[PATCH net-next 2/6] bridge: simplify the forward_delay_store by calling store_bridge_parm
There are some repetitive codes in forward_delay_store, we can remove
them by calling store_bridge_parm.
Signed-off-by: Xin Long
---
net/bridge/br_sysfs_br.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 095a751..c846bf9 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -160,29 +160,22 @@ static ssize_t group_fwd_mask_show(struct device *d,
return sprintf(buf, "%#x\n", br->group_fwd_mask);
}
-
-static ssize_t group_fwd_mask_store(struct device *d,
- struct device_attribute *attr,
- const char *buf,
- size_t len)
+static int set_group_fwd_mask(struct net_bridge *br, unsigned long val)
{
- struct net_bridge *br = to_bridge(d);
- char *endp;
- unsigned long val;
-
- if (!ns_capable(dev_net(br->dev)->user_ns, CAP_NET_ADMIN))
- return -EPERM;
-
- val = simple_strtoul(buf, &endp, 0);
- if (endp == buf)
- return -EINVAL;
-
if (val & BR_GROUPFWD_RESTRICTED)
return -EINVAL;
br->group_fwd_mask = val;
- return len;
+ return 0;
+}
+
+static ssize_t group_fwd_mask_store(struct device *d,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t len)
+{
+ return store_bridge_parm(d, buf, len, set_group_fwd_mask);
}
static DEVICE_ATTR_RW(group_fwd_mask);
--
2.1.0
Re: pull-request: wireless-drivers-next 2016-03-14
Kalle Valo writes: > David Miller writes: > >> From: Kalle Valo >> Date: Mon, 14 Mar 2016 10:31:48 +0200 >> >>> I know I'm late now that merge window was opened yesterday but here's >>> one more set of patches I would like to get to 4.6 still. There isn't >>> anything controversial so I hope this should be still safe to pull. The >>> patches have been in linux-next since Friday and I haven't seen any >>> reports about issues. But if you think it's too late just let me know >>> and I'll resubmit these for 4.7. >>> >>> The most notable part here of course is rtl8xxxu with over 100 patches. >>> As the driver is new and under heavy development I think they are ok to >>> take still. Otherwise there are mostly fixes with an exception of adding >>> a new debugfs file to wl18xx. >>> >>> Please let me know if you have any problems. >> >> Pulled, thanks. > > Great, thanks a lot. > >> I really like Jes's work and I wish you had integrated it several >> months ago, instead of sloshing him needlessly through a non-stop >> cycle of very nit-picky issues, just FYI. > > I also like his work and I'm sorry for being too nit-picky. I have tried > to be extra careful with the patches I send to you, especially with new > drivers, and I guess I have been too pedantic. I'll try to lower the bar > to a more reasonable level. > > But I actually started to wonder what you actually mean and checked the > dates of initial rtl8xxxu submission from patchwork: > > 2015-08-29 v1 > 2015-08-30 v2 > 2015-10-15 v3 > 2015-10-21 applied 26f1fad29ad9 to w-d-next for v4.4 > > Two months is quite long for a good driver like this but IIRC the > initial commit was pending wireless-drivers directory reorganisation, > and that just took too long on my side. With all the trying to break down the patches and reorganizing them into smaller blocks (disentangling 8723bu and 8192eu) to be submitted independently, I have now ended up with a tree that simply is unmergeable. I have spent about three days trying to roll back merges and pop off my devel changes to allow it to merge, and I give up. As a result I have created a new branch off wireless-drivers-next and cherry picked all my devel patches on top of this. The new branch is rtl8xxxu-devel. The old branch rtl8xxxu-nextgen I am going to let go stale, but I will keep it in place as it contains all the old devel history for the original driver prior to the initial upstream submission of rtl8xxxu. For anyone following rtl8xxxu development and/or submitting patches, please submit against the new branch from now on. Thanks, Jes
Re: linux-next: manual merge of the rdma tree with the net-next tree
Hi Stephen > How about "This is now fixed as far as linux-next is concerned, but any > non trivial conflicts should be mentioned to your upstream maintainer > when your tree is submitted for merging. You may want also want to Only the second want is required. > consider cooperate with the maintainer of the conflicting tree to cooperating Andrew
Re: [PATCH] xfrm: don't segment UFO packets
On Wed, Mar 16, 2016 at 05:00:26PM +0100, Jiri Bohac wrote: > xfrm_output() will segment GSO packets, including UDP (UFO) packets. > this is wrong per RFC4303, section 3.3.4. Fragmentation: > >If necessary, fragmentation is performed after ESP >processing within an IPsec implementation. Thus, >transport mode ESP is applied only to whole IP >datagrams (not to IP fragments). > > Prevent xfrm_output() from segmenting UFO packets so that they will be > fragmented after the xfrm transforms. > > Signed-off-by: Jiri Bohac Fair enough. But I wonder if this is enough. Wouldn't UDP notice that we're doing IPsec and prefragment the packet anyway? So I think this check may also be needed in the UDP output path. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[patch net-next RFC 06/13] mlxsw: reg: Share direction enum between SBPR, SBCM, SBPM
From: Jiri Pirko
Same field, same values, so share the same enum.
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 23 +++---
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 20 +--
2 files changed, 17 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/reg.h
b/drivers/net/ethernet/mellanox/mlxsw/reg.h
index ffe4c03..fa1c7bd 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
@@ -2985,9 +2985,10 @@ static const struct mlxsw_reg_info mlxsw_reg_sbpr = {
.len = MLXSW_REG_SBPR_LEN,
};
-enum mlxsw_reg_sbpr_dir {
- MLXSW_REG_SBPR_DIR_INGRESS,
- MLXSW_REG_SBPR_DIR_EGRESS,
+/* shared direstion enum for SBPR, SBCM, SBPM */
+enum mlxsw_reg_sbxx_dir {
+ MLXSW_REG_SBXX_DIR_INGRESS,
+ MLXSW_REG_SBXX_DIR_EGRESS,
};
/* reg_sbpr_dir
@@ -3020,7 +3021,7 @@ enum mlxsw_reg_sbpr_mode {
MLXSW_ITEM32(reg, sbpr, mode, 0x08, 0, 4);
static inline void mlxsw_reg_sbpr_pack(char *payload, u8 pool,
- enum mlxsw_reg_sbpr_dir dir,
+ enum mlxsw_reg_sbxx_dir dir,
enum mlxsw_reg_sbpr_mode mode, u32 size)
{
MLXSW_REG_ZERO(sbpr, payload);
@@ -3062,11 +3063,6 @@ MLXSW_ITEM32(reg, sbcm, local_port, 0x00, 16, 8);
*/
MLXSW_ITEM32(reg, sbcm, pg_buff, 0x00, 8, 6);
-enum mlxsw_reg_sbcm_dir {
- MLXSW_REG_SBCM_DIR_INGRESS,
- MLXSW_REG_SBCM_DIR_EGRESS,
-};
-
/* reg_sbcm_dir
* Direction.
* Access: Index
@@ -3099,7 +3095,7 @@ MLXSW_ITEM32(reg, sbcm, max_buff, 0x1C, 0, 24);
MLXSW_ITEM32(reg, sbcm, pool, 0x24, 0, 4);
static inline void mlxsw_reg_sbcm_pack(char *payload, u8 local_port, u8
pg_buff,
- enum mlxsw_reg_sbcm_dir dir,
+ enum mlxsw_reg_sbxx_dir dir,
u32 min_buff, u32 max_buff, u8 pool)
{
MLXSW_REG_ZERO(sbcm, payload);
@@ -3139,11 +3135,6 @@ MLXSW_ITEM32(reg, sbpm, local_port, 0x00, 16, 8);
*/
MLXSW_ITEM32(reg, sbpm, pool, 0x00, 8, 4);
-enum mlxsw_reg_sbpm_dir {
- MLXSW_REG_SBPM_DIR_INGRESS,
- MLXSW_REG_SBPM_DIR_EGRESS,
-};
-
/* reg_sbpm_dir
* Direction.
* Access: Index
@@ -3170,7 +3161,7 @@ MLXSW_ITEM32(reg, sbpm, min_buff, 0x18, 0, 24);
MLXSW_ITEM32(reg, sbpm, max_buff, 0x1C, 0, 24);
static inline void mlxsw_reg_sbpm_pack(char *payload, u8 local_port, u8 pool,
- enum mlxsw_reg_sbpm_dir dir,
+ enum mlxsw_reg_sbxx_dir dir,
u32 min_buff, u32 max_buff)
{
MLXSW_REG_ZERO(sbpm, payload);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
index d59195e..fb5f787 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
@@ -86,7 +86,7 @@ static int mlxsw_sp_port_pb_init(struct mlxsw_sp_port
*mlxsw_sp_port)
struct mlxsw_sp_sb_pool {
u8 pool;
- enum mlxsw_reg_sbpr_dir dir;
+ enum mlxsw_reg_sbxx_dir dir;
enum mlxsw_reg_sbpr_mode mode;
u32 size;
};
@@ -107,11 +107,11 @@ struct mlxsw_sp_sb_pool {
}
#define MLXSW_SP_SB_POOL_INGRESS(_pool, _size) \
- MLXSW_SP_SB_POOL(_pool, MLXSW_REG_SBPR_DIR_INGRESS, \
+ MLXSW_SP_SB_POOL(_pool, MLXSW_REG_SBXX_DIR_INGRESS, \
MLXSW_REG_SBPR_MODE_DYNAMIC, _size)
#define MLXSW_SP_SB_POOL_EGRESS(_pool, _size) \
- MLXSW_SP_SB_POOL(_pool, MLXSW_REG_SBPR_DIR_EGRESS, \
+ MLXSW_SP_SB_POOL(_pool, MLXSW_REG_SBXX_DIR_EGRESS, \
MLXSW_REG_SBPR_MODE_DYNAMIC, _size)
static const struct mlxsw_sp_sb_pool mlxsw_sp_sb_pools[] = {
@@ -151,7 +151,7 @@ struct mlxsw_sp_sb_cm {
u8 pg;
u8 tc;
} u;
- enum mlxsw_reg_sbcm_dir dir;
+ enum mlxsw_reg_sbxx_dir dir;
u32 min_buff;
u32 max_buff;
u8 pool;
@@ -167,15 +167,15 @@ struct mlxsw_sp_sb_cm {
}
#define MLXSW_SP_SB_CM_INGRESS(_pg, _min_buff, _max_buff) \
- MLXSW_SP_SB_CM(_pg, MLXSW_REG_SBCM_DIR_INGRESS, \
+ MLXSW_SP_SB_CM(_pg, MLXSW_REG_SBXX_DIR_INGRESS, \
_min_buff, _max_buff, 0)
#define MLXSW_SP_SB_CM_EGRESS(_tc, _min_buff, _max_buff) \
- MLXSW_SP_SB_CM(_tc, MLXSW_REG_SBCM_DIR_EGRESS, \
+ MLXSW_SP_SB_CM(_tc, MLXSW_REG_SBXX_DIR_EGRESS, \
_min_buff, _max_buff, 0)
#define MLXSW_SP_CPU_PORT_SB_CM_EGRESS(_tc)\
- MLXSW_SP_SB_CM(_tc, MLXSW_REG_SBCM_DIR_EGRESS, 104, 2, 3)
+ MLXSW_SP_SB_CM(_tc, ML
[net-next RFC 4/4] bindtosubnet: UPD implementation
Signed-off-by: Gilberto Bertin
---
net/ipv4/udp.c | 36
1 file changed, 36 insertions(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 95d2f19..1ecffa8 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -133,6 +133,23 @@ EXPORT_SYMBOL(udp_memory_allocated);
#define MAX_UDP_PORTS 65536
#define PORTS_PER_CHAIN (MAX_UDP_PORTS / UDP_HTABLE_SIZE_MIN)
+static inline int udp_csk_bind_subnet_conflict(const struct sock *sk,
+ const struct sock *sk2)
+{
+ __be32 mask;
+
+ if (sk->sk_bind_to_subnet && sk2->sk_bind_to_subnet) {
+ mask = inet_make_mask(min(sk->sk_bind_subnet4.plen,
+ sk2->sk_bind_subnet4.plen));
+
+ return (sk->sk_bind_subnet4.net & mask) ==
+ (sk2->sk_bind_subnet4.net & mask);
+ }
+
+ return 0;
+}
+
+
static int udp_lib_lport_inuse(struct net *net, __u16 num,
const struct udp_hslot *hslot,
unsigned long *bitmap,
@@ -153,6 +170,7 @@ static int udp_lib_lport_inuse(struct net *net, __u16 num,
(!sk2->sk_reuse || !sk->sk_reuse) &&
(!sk2->sk_bound_dev_if || !sk->sk_bound_dev_if ||
sk2->sk_bound_dev_if == sk->sk_bound_dev_if) &&
+udp_csk_bind_subnet_conflict(sk, sk2) &&
(!sk2->sk_reuseport || !sk->sk_reuseport ||
rcu_access_pointer(sk->sk_reuseport_cb) ||
!uid_eq(uid, sock_i_uid(sk2))) &&
@@ -189,6 +207,7 @@ static int udp_lib_lport_inuse2(struct net *net, __u16 num,
(!sk2->sk_reuse || !sk->sk_reuse) &&
(!sk2->sk_bound_dev_if || !sk->sk_bound_dev_if ||
sk2->sk_bound_dev_if == sk->sk_bound_dev_if) &&
+udp_csk_bind_subnet_conflict(sk, sk2) &&
(!sk2->sk_reuseport || !sk->sk_reuseport ||
rcu_access_pointer(sk->sk_reuseport_cb) ||
!uid_eq(uid, sock_i_uid(sk2))) &&
@@ -426,6 +445,15 @@ static inline int compute_score(struct sock *sk, struct
net *net,
return -1;
score += 4;
}
+
+ if (sk->sk_bind_to_subnet) {
+ __be32 mask = inet_make_mask(sk->sk_bind_subnet4.plen);
+
+ if ((sk->sk_bind_subnet4.net & mask) != (daddr & mask))
+ return -1;
+ score += 4;
+ }
+
if (sk->sk_incoming_cpu == raw_smp_processor_id())
score++;
return score;
@@ -471,6 +499,14 @@ static inline int compute_score2(struct sock *sk, struct
net *net,
score += 4;
}
+ if (sk->sk_bind_to_subnet) {
+ __be32 mask = inet_make_mask(sk->sk_bind_subnet4.plen);
+
+ if ((sk->sk_bind_subnet4.net & mask) != (daddr & mask))
+ return -1;
+ score += 4;
+ }
+
if (sk->sk_incoming_cpu == raw_smp_processor_id())
score++;
--
2.7.2
Re: [PATCH net-next 4/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_br
On Wed, Mar 16, 2016 at 10:14 PM, Nikolay Aleksandrov wrote: > On 03/16/2016 02:34 PM, Xin Long wrote: >> Now when we change the attributes of bridge or br_port by netlink, >> a relevant netlink notification will be sent, but if we change them >> by ioctl or sysfs, no notification will be sent. >> >> We should ensure that whenever those attributes change internally or from >> sysfs/ioctl, that a netlink notification is sent out to listeners. >> >> Also, NetworkManager will use this in the future to listen for out-of-band >> bridge master attribute updates and incorporate them into the runtime >> configuration. >> >> This patch is used for br_sysfs_br. and we also need to remove some >> rtnl_trylock in old functions so that we can call it in a common one. >> >> Signed-off-by: Xin Long >> --- >> net/bridge/br_sysfs_br.c | 17 - >> net/bridge/br_vlan.c | 30 +- >> 2 files changed, 13 insertions(+), 34 deletions(-) >> > > What about the group_addr option ? Changing it will not generate a > notification. > > group_addr is not a string-to-long convert in sysfs. so it's hard to use store_bridge_parm, that's why I didn't modify it. in group_addr_store(): it also tries to hold rtnl_lock. maybe we can send rtnl msg there. what do you think? when I cooked this patch, I was wondering why br_recalculate_fwd_mask "Must be protected by RTNL."
[PATCH 3/3] tc: q_{codel,fq_codel}: add missing space in help text
Signed-off-by: Luca Lemmo
---
tc/q_codel.c| 2 +-
tc/q_fq_codel.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tc/q_codel.c b/tc/q_codel.c
index c24246c..cff609e 100644
--- a/tc/q_codel.c
+++ b/tc/q_codel.c
@@ -53,7 +53,7 @@
static void explain(void)
{
- fprintf(stderr, "Usage: ... codel [ limit PACKETS ] [ target TIME]\n");
+ fprintf(stderr, "Usage: ... codel [ limit PACKETS ] [ target TIME ]\n");
fprintf(stderr, " [ interval TIME ] [ ecn | noecn ]\n");
fprintf(stderr, " [ ce_threshold TIME ]\n");
}
diff --git a/tc/q_fq_codel.c b/tc/q_fq_codel.c
index 4f747eb..0392c64 100644
--- a/tc/q_fq_codel.c
+++ b/tc/q_fq_codel.c
@@ -51,7 +51,7 @@
static void explain(void)
{
fprintf(stderr, "Usage: ... fq_codel [ limit PACKETS ] [ flows NUMBER
]\n");
- fprintf(stderr, "[ target TIME] [ interval TIME
]\n");
+ fprintf(stderr, "[ target TIME ] [ interval TIME
]\n");
fprintf(stderr, "[ quantum BYTES ] [ [no]ecn ]\n");
fprintf(stderr, "[ ce_threshold TIME ]\n");
}
--
2.7.3
Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
On Thursday 17 March 2016 12:01:01 Rob Herring wrote: > On Mon, Mar 14, 2016 at 05:45:43PM +, Scott Wood wrote: > > >> This makes the driver non-portable. Better identify the specific > > >> workarounds based on the compatible string for this device, or add a > > >> boolean DT property for the quirk. > > >> > > >>Arnd > > > > > > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in > > > v1 before. > > > https://patchwork.kernel.org/patch/6834221/ > > > > > > We don’t have a separate DTS file for each revision of an SOC and if we > > > did, we'd constantly have people using the wrong one. > > > In addition, the device tree is stable ABI and errata are often > > > discovered after device tree are deployed. > > > See the link for details. > > > > > > So we decide to read SVR from the device-config/guts MMIO block other > > > than using DTS. > > > Thanks. > > > > Also note that this driver is already only for fsl-specific hardware, > > and it will still work even if fsl_guts doesn't find anything to bind to > > -- it just wouldn't be able to detect errata based on SVR in that case. > > IIRC, it is the same IP block as i.MX and Arnd's point is this won't > even compile on !PPC. It is things like this that prevent sharing the > driver. I think the first four patches take care of building for ARM, but the problem remains if you want to enable COMPILE_TEST as we need for certain automated checking. > Dealing with Si revs is a common problem. We should have a > common solution. There is soc_device for this purpose. Exactly. The last time this came up, I think we agreed to implement a helper using glob_match() on the soc_device strings. Unfortunately this hasn't happened then, but I'd still prefer that over yet another vendor-specific way of dealing with the generic issue. Arnd
Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)
Am 16.03.2016 um 13:09 schrieb Robin Murphy:
> On 16/03/16 11:39, Marc Zyngier wrote:
>> On 16/03/16 11:19, Bert Lindner wrote:
>>> Hopefully this is the correct place and way to report this.
The main discussion is on netdev list actually, CC'ed.
>>> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
>>> with the eth0 PHY in mainline kernel 4.5.0 that developed since
>>> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
>>>
>>> root@lime2-079f:~# ip a l eth0
>>> 2: eth0: mtu 1500 qdisc noop state DOWN group
>>> default qlen 1000
>>> link/ether 02:c9:05:02:07:9f brd ff:ff:ff:ff:ff:ff
>>>
>>>Difference reported in dmesg:
>>>
>>> 4.5.0-rc7:
>>> [9.379279] NET: Registered protocol family 10
>>> [ 10.217148] RX IPC Checksum Offload disabled
>>> [ 10.217195] No MAC Management Counters available
>>> [ 10.217627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> [ 15.206250] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
>>> 1Gbps/Full - flow control off
>>> [ 15.206360] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>
>>> 4.5.0:
>>> [9.767125] NET: Registered protocol family 10
>>> [ 10.357405] libphy: PHY stmmac-0: not found
>>> [ 10.362382] eth0: Could not attach to PHY
>>> [ 10.366557] stmmac_open: Cannot attach to PHY (error: -19)
>>>
>>> .config is identical for both, also after make oldconfig, apart from
>>> comment with version number. DTB file is also identical between the two
>>> versions.
>>>
>>> Kernels are compiled on the board itself. /proc/version string:
>>> Linux version 4.5.0-rc7 (root@lime2-079f) (gcc version 4.9.1
>>> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Mon Mar 7 11:57:25 UTC 2016
>>> Linux version 4.5.0 (root@lime2-079f) (gcc version 4.9.1 (Ubuntu/Linaro
>>> 4.9.1-16ubuntu6) ) #1 SMP Tue Mar 15 11:39:01 UTC 2016
>>>
>>> Please let me know if more info is needed, if I should post complete
>>> .config, test compile with a particular config or patch, etc. Part of
>>> .config below.
>>
>> Can you please try reverting 88f8b1b ("stmmac: Fix 'eth0: No PHY found'
>> regression") and report whether or not this changes anything? This seems
>> to be the only stmac patch between -rc7 and release...
>
> Sounds like the same thing as the giant ongoing discussion thread here:
>
> http://thread.gmane.org/gmane.linux.drivers.devicetree/159007/focus=402830
v4 fixes for 4.5 are here:
https://patchwork.ozlabs.org/patch/598195/ (revert)
https://patchwork.ozlabs.org/patch/598196/
v2 fixes for linux-next here:
https://patchwork.ozlabs.org/patch/598331/ (revert)
https://patchwork.ozlabs.org/patch/598332/
Please let Peppe know whether they work for you guys.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
Re: [PATCH net-next V1 00/13] Mellanox 100G mlx5 driver receive path optimizations
Sorry, the merge window is open therefore net-next is closed for new submissions.
Re: [PATCH net] vlan: propagate gso_max_segs
From: Eric Dumazet Date: Wed, 16 Mar 2016 21:59:49 -0700 > From: Eric Dumazet > > vlan drivers lack proper propagation of gso_max_segs from > lower device. > > Signed-off-by: Eric Dumazet Applied.
Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU
"Michael S. Tsirkin" writes:
> On Tue, Mar 15, 2016 at 05:04:13PM -0400, Aaron Conole wrote:
>> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it
>> exists, read the advised MTU and use it.
>>
>> No proper error handling is provided for the case where a user changes the
>> negotiated MTU. A future commit will add proper error handling. Instead, a
>> warning is emitted if the guest changes the device MTU after previously
>> being given advice.
>
> I don't see this as an error. Device might at best give a hint,
> user/network admin always knows best.
>
>>
>> Signed-off-by: Aaron Conole
>> ---
>> v2:
>> * Whitespace cleanup in the last hunk
>> * Code style change around the pr_warn
>> * Additional test for mtu change before printing warning
>>
>> drivers/net/virtio_net.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 767ab11..429fe01 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -146,6 +146,7 @@ struct virtnet_info {
>> virtio_net_ctrl_ack ctrl_status;
>> u8 ctrl_promisc;
>> u8 ctrl_allmulti;
>> +bool negotiated_mtu;
>> };
>>
>> struct padded_vnet_hdr {
>> @@ -1390,8 +1391,11 @@ static const struct ethtool_ops virtnet_ethtool_ops =
>> {
>>
>> static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
>> {
>> +struct virtnet_info *vi = netdev_priv(dev);
>> if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
>> return -EINVAL;
>> +if ((vi->negotiated_mtu) && (dev->mtu != new_mtu))
>> +pr_warn("changing mtu while the advised mtu bit exists.");
>
> I don't really see why are we warning here. Just drop this chunk,
> as well as the flag in struct virtnet_info.
Okay. I was warning because the user is changing this after telling to
use something different - but if you don't think it's an error, I will
drop it.
Thanks so much for the review, Michael!
-Aaron
>> dev->mtu = new_mtu;
>> return 0;
>> }
>> @@ -1836,6 +1840,13 @@ static int virtnet_probe(struct virtio_device *vdev)
>> if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
>> vi->has_cvq = true;
>>
>> +if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
>> +vi->negotiated_mtu = true;
>> +dev->mtu = virtio_cread16(vdev,
>> + offsetof(struct virtio_net_config,
>> + mtu));
>> +}
>> +
>> if (vi->any_header_sg)
>> dev->needed_headroom = vi->hdr_len;
>>
>> @@ -2019,6 +2030,7 @@ static unsigned int features[] = {
>> VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
>> VIRTIO_NET_F_CTRL_MAC_ADDR,
>> VIRTIO_F_ANY_LAYOUT,
>> +VIRTIO_NET_F_MTU,
>> };
>>
>> static struct virtio_driver virtio_net_driver = {
>> --
>> 2.5.0
[patch net-next RFC 09/13] mlxsw: spectrum_buffers: Push out shared buffer register writes
From: Jiri Pirko
Pushed them into helper functions.
Signed-off-by: Jiri Pirko
---
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 54 --
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
index fb5f787..cc40f4c 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
@@ -40,6 +40,37 @@
#include "port.h"
#include "reg.h"
+static int mlxsw_sp_sb_pr_write(struct mlxsw_sp *mlxsw_sp, u8 pool,
+ enum mlxsw_reg_sbxx_dir dir,
+ enum mlxsw_reg_sbpr_mode mode, u32 size)
+{
+ char sbpr_pl[MLXSW_REG_SBPR_LEN];
+
+ mlxsw_reg_sbpr_pack(sbpr_pl, pool, dir, mode, size);
+ return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(sbpr), sbpr_pl);
+}
+
+static int mlxsw_sp_sb_cm_write(struct mlxsw_sp *mlxsw_sp, u8 local_port,
+ u8 pg_buff, enum mlxsw_reg_sbxx_dir dir,
+ u32 min_buff, u32 max_buff, u8 pool)
+{
+ char sbcm_pl[MLXSW_REG_SBCM_LEN];
+
+ mlxsw_reg_sbcm_pack(sbcm_pl, local_port, pg_buff, dir,
+ min_buff, max_buff, pool);
+ return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(sbcm), sbcm_pl);
+}
+
+static int mlxsw_sp_sb_pm_write(struct mlxsw_sp *mlxsw_sp, u8 local_port,
+ u8 pool, enum mlxsw_reg_sbxx_dir dir,
+ u32 min_buff, u32 max_buff)
+{
+ char sbpm_pl[MLXSW_REG_SBPM_LEN];
+
+ mlxsw_reg_sbpm_pack(sbpm_pl, local_port, pool, dir, min_buff, max_buff);
+ return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(sbpm), sbpm_pl);
+}
+
struct mlxsw_sp_pb {
u8 index;
u16 size;
@@ -129,7 +160,6 @@ static const struct mlxsw_sp_sb_pool mlxsw_sp_sb_pools[] = {
static int mlxsw_sp_sb_pools_init(struct mlxsw_sp *mlxsw_sp)
{
- char sbpr_pl[MLXSW_REG_SBPR_LEN];
int i;
int err;
@@ -137,9 +167,8 @@ static int mlxsw_sp_sb_pools_init(struct mlxsw_sp *mlxsw_sp)
const struct mlxsw_sp_sb_pool *pool;
pool = &mlxsw_sp_sb_pools[i];
- mlxsw_reg_sbpr_pack(sbpr_pl, pool->pool, pool->dir,
- pool->mode, pool->size);
- err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(sbpr), sbpr_pl);
+ err = mlxsw_sp_sb_pr_write(mlxsw_sp, pool->pool, pool->dir,
+ pool->mode, pool->size);
if (err)
return err;
}
@@ -250,7 +279,6 @@ static int mlxsw_sp_sb_cms_init(struct mlxsw_sp *mlxsw_sp,
u8 local_port,
const struct mlxsw_sp_sb_cm *cms,
size_t cms_len)
{
- char sbcm_pl[MLXSW_REG_SBCM_LEN];
int i;
int err;
@@ -258,9 +286,9 @@ static int mlxsw_sp_sb_cms_init(struct mlxsw_sp *mlxsw_sp,
u8 local_port,
const struct mlxsw_sp_sb_cm *cm;
cm = &cms[i];
- mlxsw_reg_sbcm_pack(sbcm_pl, local_port, cm->u.pg, cm->dir,
- cm->min_buff, cm->max_buff, cm->pool);
- err = mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(sbcm), sbcm_pl);
+ err = mlxsw_sp_sb_cm_write(mlxsw_sp, local_port, cm->u.pg,
+ cm->dir, cm->min_buff,
+ cm->max_buff, cm->pool);
if (err)
return err;
}
@@ -318,7 +346,6 @@ static const struct mlxsw_sp_sb_pm mlxsw_sp_sb_pms[] = {
static int mlxsw_sp_port_sb_pms_init(struct mlxsw_sp_port *mlxsw_sp_port)
{
- char sbpm_pl[MLXSW_REG_SBPM_LEN];
int i;
int err;
@@ -326,11 +353,10 @@ static int mlxsw_sp_port_sb_pms_init(struct mlxsw_sp_port
*mlxsw_sp_port)
const struct mlxsw_sp_sb_pm *pm;
pm = &mlxsw_sp_sb_pms[i];
- mlxsw_reg_sbpm_pack(sbpm_pl, mlxsw_sp_port->local_port,
- pm->pool, pm->dir,
- pm->min_buff, pm->max_buff);
- err = mlxsw_reg_write(mlxsw_sp_port->mlxsw_sp->core,
- MLXSW_REG(sbpm), sbpm_pl);
+ err = mlxsw_sp_sb_pm_write(mlxsw_sp_port->mlxsw_sp,
+ mlxsw_sp_port->local_port,
+ pm->pool, pm->dir,
+ pm->min_buff, pm->max_buff);
if (err)
return err;
}
--
2.5.0
[iproute PATCH 8/8] man: tc-vlan.8: Describe CONTROL option
This should be made generic and part of a common tc-actions man page.
Though leave it here for now to not confuse readers of the example which
uses it.
Signed-off-by: Phil Sutter
---
man/man8/tc-vlan.8 | 56 +-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/man/man8/tc-vlan.8 b/man/man8/tc-vlan.8
index e650b72d3b395..4bfd72b129aaf 100644
--- a/man/man8/tc-vlan.8
+++ b/man/man8/tc-vlan.8
@@ -6,13 +6,17 @@ vlan - vlan manipulation module
.in +8
.ti -8
.BR tc " ... " "action vlan" " { " pop " |"
-.IR PUSH " }"
+.IR PUSH " } [ " CONTROL " ]"
.ti -8
.IR PUSH " := "
.BR push " [ " protocol
.IR VLANPROTO " ]"
.BI id " VLANID"
+
+.ti -8
+.IR CONTROL " := { "
+.BR reclassify " | " pipe " | " drop " | " continue " | " pass " }"
.SH DESCRIPTION
The
.B vlan
@@ -50,5 +54,55 @@ for hexadecimal interpretation, etc.).
.BI protocol " VLANPROTO"
Choose the VLAN protocol to use. At the time of writing, the kernel accepts
only
.BR 802.1Q " or " 802.1ad .
+.TP
+.I CONTROL
+How to continue after executing this action.
+.RS
+.TP
+.B reclassify
+Restarts classification by jumping back to the first filter attached to this
+action's parent.
+.TP
+.B pipe
+Continue with the next action, this is the default.
+.TP
+.B drop
+Packet will be dropped without running further actions.
+.TP
+.B continue
+Continue classification with next filter in line.
+.TP
+.B pass
+Return to calling qdisc for packet processing. This ends the classification
+process.
+.RE
+.SH EXAMPLES
+The following example encapsulates incoming ICMP packets on eth0 from 10.0.0.2
+into VLAN ID 123:
+
+.RS
+.EX
+#tc qdisc add dev eth0 handle : ingress
+#tc filter add dev eth0 parent : pref 11 protocol ip \\
+ u32 match ip protocol 1 0xff flowid 1:1 \\
+ u32 match ip src 10.0.0.2 flowid 1:1 \\
+ action vlan push id 123
+.EE
+.RE
+
+Here is an example of the
+.B pop
+function: Incoming VLAN packets on eth0 are decapsulated and the classification
+process then restarted for the plain packet:
+
+.RS
+.EX
+#tc qdisc add dev eth0 handle : ingress
+#tc filter add dev $ETH parent : pref 1 protocol 802.1Q \\
+ u32 match u32 0 0 flowid 1:1 \\
+ action vlan pop reclassify
+.EE
+.RE
+
.SH SEE ALSO
.BR tc (8)
--
2.7.2
Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
On 03/17/2016 12:06 PM, Arnd Bergmann wrote: > On Thursday 17 March 2016 12:01:01 Rob Herring wrote: >> On Mon, Mar 14, 2016 at 05:45:43PM +, Scott Wood wrote: > > This makes the driver non-portable. Better identify the specific > workarounds based on the compatible string for this device, or add a > boolean DT property for the quirk. > >Arnd [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before. https://patchwork.kernel.org/patch/6834221/ We don’t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one. In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed. See the link for details. So we decide to read SVR from the device-config/guts MMIO block other than using DTS. Thanks. >>> >>> Also note that this driver is already only for fsl-specific hardware, >>> and it will still work even if fsl_guts doesn't find anything to bind to >>> -- it just wouldn't be able to detect errata based on SVR in that case. >> >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't >> even compile on !PPC. It is things like this that prevent sharing the >> driver. The whole point of using the MMIO SVR instead of the PPC SPR is so that it will work on ARM... The guts driver should build on any platform as long as OF is enabled, and if it doesn't find a node to bind to it will return 0 for SVR, and the eSDHC driver will continue (after printing an error that should be removed) without the ability to test for errata based on SVR. > I think the first four patches take care of building for ARM, > but the problem remains if you want to enable COMPILE_TEST as > we need for certain automated checking. What specific problem is there with COMPILE_TEST? >> Dealing with Si revs is a common problem. We should have a >> common solution. There is soc_device for this purpose. > > Exactly. The last time this came up, I think we agreed to implement a > helper using glob_match() on the soc_device strings. Unfortunately > this hasn't happened then, but I'd still prefer that over yet another > vendor-specific way of dealing with the generic issue. soc_device would require encoding the SVR as a string and then decoding the string, which is more complicated and error prone than having platform-specific code test a platform-specific number. And when would it get registered on arm64, which doesn't have platform code? -Scott
Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)
On Thu, 17 Mar 2016 00:56:40 +0100
Bert Lindner wrote:
> On 2016-03-16 18:42, Marc Zyngier wrote:
> > On 16/03/16 15:10, Bert Lindner wrote:
> >> On 2016-03-16 14:10, Andreas Färber wrote:
> >>> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
> On 16/03/16 11:39, Marc Zyngier wrote:
> > On 16/03/16 11:19, Bert Lindner wrote:
> >> Hopefully this is the correct place and way to report this.
> >>>
> >>> The main discussion is on netdev list actually, CC'ed.
> >>>
> >> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
> >> with the eth0 PHY in mainline kernel 4.5.0 that developed since
> >> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
> >>
> >> root@lime2-079f:~# ip a l eth0
> >> 2: eth0: mtu 1500 qdisc noop state DOWN group
> >> default qlen 1000
> >> link/ether 02:c9:05:02:07:9f brd ff:ff:ff:ff:ff:ff
> >>
> >> Difference reported in dmesg:
> >>
> >> 4.5.0-rc7:
> >> [9.379279] NET: Registered protocol family 10
> >> [ 10.217148] RX IPC Checksum Offload disabled
> >> [ 10.217195] No MAC Management Counters available
> >> [ 10.217627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> >> [ 15.206250] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
> >> 1Gbps/Full - flow control off
> >> [ 15.206360] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>
> >> 4.5.0:
> >> [9.767125] NET: Registered protocol family 10
> >> [ 10.357405] libphy: PHY stmmac-0: not found
> >> [ 10.362382] eth0: Could not attach to PHY
> >> [ 10.366557] stmmac_open: Cannot attach to PHY (error: -19)
> >>
> >> .config is identical for both, also after make oldconfig, apart from
> >> comment with version number. DTB file is also identical between the two
> >> versions.
> >>
> >> Kernels are compiled on the board itself. /proc/version string:
> >> Linux version 4.5.0-rc7 (root@lime2-079f) (gcc version 4.9.1
> >> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Mon Mar 7 11:57:25 UTC 2016
> >> Linux version 4.5.0 (root@lime2-079f) (gcc version 4.9.1 (Ubuntu/Linaro
> >> 4.9.1-16ubuntu6) ) #1 SMP Tue Mar 15 11:39:01 UTC 2016
> >>
> >> Please let me know if more info is needed, if I should post complete
> >> .config, test compile with a particular config or patch, etc. Part of
> >> .config below.
> >
> > Can you please try reverting 88f8b1b ("stmmac: Fix 'eth0: No PHY found'
> > regression") and report whether or not this changes anything? This seems
> > to be the only stmac patch between -rc7 and release...
>
> Sounds like the same thing as the giant ongoing discussion thread here:
>
> http://thread.gmane.org/gmane.linux.drivers.devicetree/159007/focus=402830
> >>>
> >>> v4 fixes for 4.5 are here:
> >>>
> >>> https://patchwork.ozlabs.org/patch/598195/ (revert)
> >>> https://patchwork.ozlabs.org/patch/598196/
> >>>
> >>> v2 fixes for linux-next here:
> >>>
> >>> https://patchwork.ozlabs.org/patch/598331/ (revert)
> >>> https://patchwork.ozlabs.org/patch/598332/
> >>>
> >>> Please let Peppe know whether they work for you guys.
> >>
> >> Hi guys - I can confirm 4.5.0 minus 88f8b1b works for me:
> >>
> >> root@lime2-079f:~# cat /proc/version
> >> Linux version 4.5.0-minus-88f8b1b (root@lime2-079f) (gcc version 4.9.1
> >> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #2 SMP Wed Mar 16 12:50:03 UTC 2016
> >>
> >> From dmesg output:
> >> [9.731730] NET: Registered protocol family 10
> >> [ 10.516893] RX IPC Checksum Offload disabled
> >> [ 10.516948] No MAC Management Counters available
> >> [ 10.517374] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> >> [ 15.505548] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
> >> 1Gbps/Full - flow control off
> >> [ 15.505660] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> >>
> >> .. and connected over ethernet.
> >
> > Good to know, thanks. Could you also give the potential fix a go (as
> > mentioned by Andreas)? Just to make sure that whatever gets merged next
> > will actually fix the issue.
>
> Yes sure, it took a while because I had to travel. Confirmed, the
> v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:
>
> root@lime2-079f:~# cat /proc/version
> Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version
> 4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC 2016
>
> dmesg:
> [8.245273] NET: Registered protocol family 10
> [9.297406] RX IPC Checksum Offload disabled
> [9.297460] No MAC Management Counters available
> [9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 16.285658] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
> 1Gbps/Full - flow control rx/tx
> [ 16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> The board is connected to my laptop rather than to a switch, so that
> might be
[net-next:master 386/609] include/net/vxlan.h:302:17: sparse: cast to restricted __be64
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
master
head: 93e68cd6115f67d8363c94dae8206af36f6d3b00
commit: 07dabf20d9867710b90b91108b2adcd448773e25 [386/609] vxlan: tun_id is
64bit, not 32bit
reproduce:
# apt-get install sparse
git checkout 07dabf20d9867710b90b91108b2adcd448773e25
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/net/checksum.h:177:43: sparse: incorrect type in argument 2
(different base types)
include/net/checksum.h:177:43:expected restricted __wsum [usertype]
addend
include/net/checksum.h:177:43:got restricted __sum16 [usertype]
include/net/inet_ecn.h:131:58: sparse: incorrect type in argument 2
(different base types)
include/net/inet_ecn.h:131:58:expected restricted __wsum [usertype]
addend
include/net/inet_ecn.h:131:58:got restricted __be32 [assigned]
[usertype] from
include/net/inet_ecn.h:131:65: sparse: incorrect type in argument 2
(different base types)
include/net/inet_ecn.h:131:65:expected restricted __wsum [usertype]
addend
include/net/inet_ecn.h:131:65:got restricted __be32 [assigned]
[usertype] to
include/net/inet_ecn.h:131:58: sparse: incorrect type in argument 2
(different base types)
include/net/inet_ecn.h:131:58:expected restricted __wsum [usertype]
addend
include/net/inet_ecn.h:131:58:got restricted __be32 [assigned]
[usertype] from
include/net/inet_ecn.h:131:65: sparse: incorrect type in argument 2
(different base types)
include/net/inet_ecn.h:131:65:expected restricted __wsum [usertype]
addend
include/net/inet_ecn.h:131:65:got restricted __be32 [assigned]
[usertype] to
include/net/vxlan.h:275:27: sparse: restricted __be32 degrades to integer
include/net/vxlan.h:275:45: sparse: incorrect type in return expression
(different base types)
include/net/vxlan.h:275:45:expected restricted __be32
include/net/vxlan.h:275:45:got unsigned int
>> include/net/vxlan.h:302:17: sparse: cast to restricted __be64
>> include/net/vxlan.h:302:17: sparse: cast from restricted __be32
include/net/vxlan.h:302:17: sparse: restricted __be64 degrades to integer
>> include/net/vxlan.h:302:28: sparse: incorrect type in return expression
>> (different base types)
include/net/vxlan.h:302:28:expected restricted __be64
include/net/vxlan.h:302:28:got unsigned long long
include/net/vxlan.h:275:27: sparse: restricted __be32 degrades to integer
include/net/vxlan.h:275:45: sparse: incorrect type in return expression
(different base types)
include/net/vxlan.h:275:45:expected restricted __be32
include/net/vxlan.h:275:45:got unsigned int
include/net/vxlan.h:284:16: sparse: restricted __be32 degrades to integer
include/net/vxlan.h:284:20: sparse: incorrect type in return expression
(different base types)
include/net/vxlan.h:284:20:expected restricted __be32
include/net/vxlan.h:284:20:got unsigned int
include/net/vxlan.h:293:16: sparse: restricted __be64 degrades to integer
include/net/vxlan.h:293:23: sparse: incorrect type in return expression
(different base types)
include/net/vxlan.h:293:23:expected restricted __be32
include/net/vxlan.h:293:23:got unsigned long long
vim +302 include/net/vxlan.h
269
270 static inline __be32 vxlan_vni(__be32 vni_field)
271 {
272 #if defined(__BIG_ENDIAN)
273 return vni_field >> 8;
274 #else
> 275 return (vni_field & VXLAN_VNI_MASK) << 8;
276 #endif
277 }
278
279 static inline __be32 vxlan_vni_field(__be32 vni)
280 {
281 #if defined(__BIG_ENDIAN)
282 return vni << 8;
283 #else
284 return vni >> 8;
285 #endif
286 }
287
288 static inline __be32 vxlan_tun_id_to_vni(__be64 tun_id)
289 {
290 #if defined(__BIG_ENDIAN)
291 return tun_id;
292 #else
293 return tun_id >> 32;
294 #endif
295 }
296
297 static inline __be64 vxlan_vni_to_tun_id(__be32 vni)
298 {
299 #if defined(__BIG_ENDIAN)
300 return (__be64)vni;
301 #else
> 302 return (__be64)vni << 32;
303 #endif
304 }
305
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] sctp: consolidate local_bh_disable/enable + spin_lock/unlock to _bh variant
From: Nicholas Mc Guire Date: Sun, 13 Mar 2016 11:48:24 +0100 > local_bh_disable() + spin_lock() is equivalent to spin_lock_bh(), same for > the unlock/enable case, so replace the calls by the appropriate wrappers. > > Signed-off-by: Nicholas Mc Guire Applied.
Re: [PATCH net-next v3 1/2] RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on rds-tcp socket
On 16.03.2016 12:10, Sowmini Varadhan wrote:
On (03/16/16 11:29), Hannes Frederic Sowa wrote:
Normally we kmemdup a table per netns and update its data pointer,
so we can reuse the proc_doint_minmax functions.
I remembered one more thing.. in this particular case, I need to
have my one ->proc_handler, because I need to rds_tcp_sysctl_reset()
existing connections to make them use the new tunable.
My hope was actually that by using the ->data pointer in netns you don't
need to provide the two functions, just simply use something like the
following for both cases.
static int rds_skbuf_handler(...) {
int err;
err = proc_dointvec(...);
if (err)
return err;
if (write)
rds_tcp_sysctl_reset(...);
return err;
}
If you use proc_dointvec_min(max) you can already sanitize the input
values even more.
Do I understand it correctly that all connections of a namespace will be
dropped if you modify those sysctls?
Thanks,
Hannes
Re: Re: [PATCH V7] netfilter: h323: avoid potential attack
Thanks Pablo for reviewing
> From: "Pablo Neira Ayuso"
> Sent Time: Saturday, March 12, 2016
> To: "Zhouyi Zhou"
> On Sun, Feb 21, 2016 at 12:03:59AM +0800, Zhouyi Zhou wrote:
> > I think hackers chould build a malicious h323 packet to overflow
(iph->ihl * 4 + th->doff * 4);
> You cannot trust the information that is available in the header. If
> this is bogus this check will be defeated. That's why we pass this
> protoff parameters to each function.
The length of IP header is checked in the function nf_conntrack_in which calls
get_l4proto hook to detect bogus ip header.
There is no where in the call stack to the function set_addr to check bogus
TCP header, and my code does the job:
+ th = (void *)iph + iph->ihl * 4;
+ datalen = skb->len - (iph->ihl * 4 + th->doff * 4);
+ /* check offset overflow */
+ if (addroff > datalen)
+ return -1;
if th->doff be too big addroff will greater than datalen.
>
> You also refer to get_h225_addr() in your description. That function
> always copies 4 or 16 bytes, so I would appreciate if you can describe
> the possible issue further.
The problem of get_h225_addr lies in bogus taddr->ipAddress.ip, if this value
is too big, it may make the pointer p point to no exist address.
(gdb) list 686
681 struct h323_ct_state *ctstate)
682 {
683 const unsigned char *p;
684 int len;
685
686 switch (taddr->choice) {
687 case eTransportAddress_ipAddress:
688 if (nf_ct_l3num(ct) != AF_INET)
689 return 0;
690 p = data + taddr->ipAddress.ip;
Thanks for your time and effort
Cheers
Zhouyi
[PATCH net-next 6/6] bridge: a netlink notification should be sent when those attributes are changed by ioctl
Now when we change the attributes of bridge or br_port by netlink,
a relevant netlink notification will be sent, but if we change them
by ioctl or sysfs, no notification will be sent.
We should ensure that whenever those attributes change internally or from
sysfs/ioctl, that a netlink notification is sent out to listeners.
Also, NetworkManager will use this in the future to listen for out-of-band
bridge master attribute updates and incorporate them into the runtime
configuration.
This patch is used for ioctl.
Signed-off-by: Xin Long
---
net/bridge/br_ioctl.c | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c
index 263b4de..f8fc624 100644
--- a/net/bridge/br_ioctl.c
+++ b/net/bridge/br_ioctl.c
@@ -112,7 +112,9 @@ static int add_del_if(struct net_bridge *br, int ifindex,
int isadd)
static int old_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct net_bridge *br = netdev_priv(dev);
+ struct net_bridge_port *p = NULL;
unsigned long args[4];
+ int ret = -EOPNOTSUPP;
if (copy_from_user(args, rq->ifr_data, sizeof(args)))
return -EFAULT;
@@ -182,25 +184,29 @@ static int old_dev_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
if (!ns_capable(dev_net(dev)->user_ns, CAP_NET_ADMIN))
return -EPERM;
- return br_set_forward_delay(br, args[1]);
+ ret = br_set_forward_delay(br, args[1]);
+ break;
case BRCTL_SET_BRIDGE_HELLO_TIME:
if (!ns_capable(dev_net(dev)->user_ns, CAP_NET_ADMIN))
return -EPERM;
- return br_set_hello_time(br, args[1]);
+ ret = br_set_hello_time(br, args[1]);
+ break;
case BRCTL_SET_BRIDGE_MAX_AGE:
if (!ns_capable(dev_net(dev)->user_ns, CAP_NET_ADMIN))
return -EPERM;
- return br_set_max_age(br, args[1]);
+ ret = br_set_max_age(br, args[1]);
+ break;
case BRCTL_SET_AGEING_TIME:
if (!ns_capable(dev_net(dev)->user_ns, CAP_NET_ADMIN))
return -EPERM;
- return br_set_ageing_time(br, args[1]);
+ ret = br_set_ageing_time(br, args[1]);
+ break;
case BRCTL_GET_PORT_INFO:
{
@@ -240,20 +246,19 @@ static int old_dev_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
return -EPERM;
br_stp_set_enabled(br, args[1]);
- return 0;
+ ret = 0;
+ break;
case BRCTL_SET_BRIDGE_PRIORITY:
if (!ns_capable(dev_net(dev)->user_ns, CAP_NET_ADMIN))
return -EPERM;
br_stp_set_bridge_priority(br, args[1]);
- return 0;
+ ret = 0;
+ break;
case BRCTL_SET_PORT_PRIORITY:
{
- struct net_bridge_port *p;
- int ret;
-
if (!ns_capable(dev_net(dev)->user_ns, CAP_NET_ADMIN))
return -EPERM;
@@ -263,14 +268,11 @@ static int old_dev_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
else
ret = br_stp_set_port_priority(p, args[2]);
spin_unlock_bh(&br->lock);
- return ret;
+ break;
}
case BRCTL_SET_PATH_COST:
{
- struct net_bridge_port *p;
- int ret;
-
if (!ns_capable(dev_net(dev)->user_ns, CAP_NET_ADMIN))
return -EPERM;
@@ -280,8 +282,7 @@ static int old_dev_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
else
ret = br_stp_set_path_cost(p, args[2]);
spin_unlock_bh(&br->lock);
-
- return ret;
+ break;
}
case BRCTL_GET_FDB_ENTRIES:
@@ -289,7 +290,14 @@ static int old_dev_ioctl(struct net_device *dev, struct
ifreq *rq, int cmd)
args[2], args[3]);
}
- return -EOPNOTSUPP;
+ if (!ret) {
+ if (p)
+ br_ifinfo_notify(RTM_NEWLINK, p);
+ else
+ netdev_state_change(br->dev);
+ }
+
+ return ret;
}
static int old_deviceless(struct net *net, void __user *uarg)
--
2.1.0
Re: Regression: netlink fail (triggered by iw) removes extra wlan (phy) interface
On 25 February 2016 at 14:22, Rafał Miłecki wrote: > After updating kernel in OpenWrt from 4.1.6 to 4.1.10 I noticed that > if "iw" command fails (which happens very rarely) my wlan0-1 interface > disappears. To trigger this problem easily I'm using this trivial > script: > while [ 1 ] > do > iw phy phy0 interface add mon0 type monitor > ifconfig mon0 up > iw dev mon0 del > done > > Whenever it goes wrong I see: > Failed to connect to generic netlink. > kern.info kernel: [ 1933.114338] br-lan: port 3(wlan0-1) entered disabled > state > kern.info kernel: [ 1933.335568] device wlan0-1 left promiscuous mode > kern.info kernel: [ 1933.340385] br-lan: port 3(wlan0-1) entered disabled > state > daemon.notice netifd: Network device 'wlan0-1' link is down > command failed: Too many open files in system (-23) > > This regression is caused by commit: > 4e27762 netlink: Fix autobind race condition that leads to zero port ID > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=4e27762417669cb459971635be550eb7b5598286 > that is a backport of upstream: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1f770c0a09da855a2b51af6d19de97fb955eca85 > > This still happens with kernel 4.4. > > My hardware is Linksys WRT160NL (Atheros AR9130 SoC) and I'm using two > __ap interfaces on phy0 (wlan0 and wlan0-1). > > Could you take a look at this? > Is there some additional info I could provide to help fixing this? Ping? -- Rafał
[iproute PATCH 6/8] man: tc-skbedit.8: Elaborate a bit on TX queues
Signed-off-by: Phil Sutter --- man/man8/tc-skbedit.8 | 14 ++ 1 file changed, 14 insertions(+) diff --git a/man/man8/tc-skbedit.8 b/man/man8/tc-skbedit.8 index b585a4d4253ba..c75d082148ac3 100644 --- a/man/man8/tc-skbedit.8 +++ b/man/man8/tc-skbedit.8 @@ -17,6 +17,18 @@ The action allows to change a packet's associated meta data. It complements the .B pedit action, which in turn allows to change parts of the packet data itself. + +The most unique feature of +.B skbedit +is it's ability to decide over which queue of an interface with multiple +transmit queues the packet is to be sent out. The number of available transmit +queues is reflected by sysfs entries within +.I /sys/class/net//queues +with name +.I tx-N +(where +.I N +is the actual queue number). .SH OPTIONS .TP .BI queue_mapping " QUEUE_MAPPING" @@ -40,6 +52,8 @@ Change the packet's firewall mark value. is an unsigned 32bit value in automatically detected format (i.e., prefix with .RB ' 0x ' for hexadecimal interpretation, etc.). +.SH EXAMPLES +XXX: write me .SH SEE ALSO .BR tc (8), .BR tc-pedit (8) -- 2.7.2
[linux-next:master 4720/12950] net/core/dst_cache.c:31:6: sparse: symbol 'dst_cache_per_cpu_dst_set' was not declared. Should it be static?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: 5e3497cca281616e7930b74a0076b7324dcc2057 commit: 607f725f6f7d5ec3759fbc16224afb60e2152a5b [4720/12950] net: replace dst_cache ip6_tunnel implementation with the generic one reproduce: # apt-get install sparse git checkout 607f725f6f7d5ec3759fbc16224afb60e2152a5b make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> net/core/dst_cache.c:31:6: sparse: symbol 'dst_cache_per_cpu_dst_set' was >> not declared. Should it be static? >> net/core/dst_cache.c:42:18: sparse: symbol 'dst_cache_per_cpu_get' was not >> declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH net-next 6/6] bridge: a netlink notification should be sent when those attributes are changed by ioctl
On 03/16/2016 02:34 PM, Xin Long wrote: > Now when we change the attributes of bridge or br_port by netlink, > a relevant netlink notification will be sent, but if we change them > by ioctl or sysfs, no notification will be sent. > > We should ensure that whenever those attributes change internally or from > sysfs/ioctl, that a netlink notification is sent out to listeners. > > Also, NetworkManager will use this in the future to listen for out-of-band > bridge master attribute updates and incorporate them into the runtime > configuration. > > This patch is used for ioctl. > > Signed-off-by: Xin Long > --- > net/bridge/br_ioctl.c | 40 > 1 file changed, 24 insertions(+), 16 deletions(-) > LGTM, Acked-by: Nikolay Aleksandrov
RE: [PATCH] iwlwifi: dvm: convert create_singlethread_workqueue() to alloc_workqueue()
>
> Use alloc_workqueue() to allocate the workqueue instead of
> create_singlethread_workqueue() since the latter is deprecated and is
> scheduled
> for removal.
I can't see any indication of that in the code of workqueue.
Can you share details about that?
>
> There are work items doing related operations that shouldn't be swapped
> when
> queued in a certain order hence preserve the strict execution ordering of a
> single threaded (ST) workqueue by setting max_active to 1 and adding the
> WQ_UNBOUND flag.
>
> In addition, there are work items dealing with temperature throttling
> (tt_work,
> ct_enter, ct_exit). Adding the WQ_HIGHPRI flag would place the work items
> in a
> high priority workqueue.
>
> Lastly, guarantee forward progress for work items depended upon during
> memory
> reclaim by the addition of the WQ_MEM_RECLAIM flag.
>
> Signed-off-by: Eva Rachel Retuya
> ---
> To the maintainers:
> Just to confirm, are work items depended upon during memory reclaim? If
> not, the WQ_MEM_RECLAIM flag will be dropped. I added it just in case since
> create_singlethread_workqueue() also sets this flag.
>
> drivers/net/wireless/intel/iwlwifi/dvm/main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/main.c
> b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
> index f62c2d7..37fa11c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/main.c
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
> @@ -1071,7 +1071,8 @@ static void iwl_bg_restart(struct work_struct *data)
>
> static void iwl_setup_deferred_work(struct iwl_priv *priv)
> {
> - priv->workqueue = create_singlethread_workqueue(DRV_NAME);
> + priv->workqueue = alloc_workqueue(DRV_NAME, WQ_HIGHPRI |
> WQ_UNBOUND |
> + WQ_MEM_RECLAIM, 1);
>
> INIT_WORK(&priv->restart, iwl_bg_restart);
> INIT_WORK(&priv->beacon_update, iwl_bg_beacon_update);
> --
> 1.9.1
Re: [PATCH] Add support to control PHY LEDs
On Thu, Mar 17, 2016 at 02:59:06PM +0100, Vishal Thanki wrote: > Hi all, > > We had a requirement to disable the PHY link LEDs during system > standby mode without turning off the ethernet module. To achieve that, > I have prepared the sysfs interface turn on/off the PHY link LEDs. Hi Vishal Could you implement this in at803x_suspend()? Andrew
[PATCH net 0/3] flowi6_tos fixes
This set is a follow-up to address Jiri's recent feedback [1] on the flowi6_tos issue, that it is not used for IPv6 route lookups. The three patches fix all current users of flowi6_tos and remove the define to avoid any future confusion on this. Tested the vxlan and geneve ones with IPv6 routing rules. For details, please see individual patches. [ As fixes are currently applied against net-next tree, I've rebased it against that. ] Thanks! [1] http://patchwork.ozlabs.org/patch/592055/ Daniel Borkmann (3): vxlan: fix populating tclass in vxlan6_get_route geneve: fix populating tclass in geneve_get_v6_dst ipv6, trace: fix tos reporting on fib6_table_lookup drivers/net/geneve.c| 11 ++- drivers/net/vxlan.c | 3 +-- include/net/flow.h | 2 +- include/net/ipv6.h | 6 ++ include/trace/events/fib6.h | 2 +- 5 files changed, 15 insertions(+), 9 deletions(-) -- 1.9.3
Re: [PATCH v2 3/3] phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.
On 03/16/2016 03:50 PM, Andreas Färber wrote: Hi, Am 11.03.2016 um 18:53 schrieb David Daney: diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 40faec9..075a4cc 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -196,6 +196,17 @@ config MDIO_OCTEON buses. It is required by the Octeon and ThunderX ethernet device drivers on some systems. +config MDIO_THUNDER + tristate "Support for MDIO buses on on ThunderX SOCs" Double "on", spotted in next-20160316. + depends on 64BIT + depends on PCI + select MDIO_CAVIUM + help + This driver supports the MDIO interfaces found on Cavium + ThunderX SoCs when the MDIO bus device appears on as a PCI + device. While at it, this sentence sounds weird. Did you mean s/as/is/? Or is there another verb missing in there? Should be "... appears as a PCI device." davem already merged the patch, so this would have to be fixed as a follow-on patch. Since you found this, do you want to send the patch? Thanks, David Daney Regards, Andreas + + config MDIO_SUN4I tristate "Allwinner sun4i MDIO interface support" depends on ARCH_SUNXI [snip]
[patch net-next RFC 13/13] mlxsw: spectrum: Implement shared buffer configuration
From: Jiri Pirko
Implement previously introduced devlink shared buffer API. In mlxsw that
is done utilizing registers SBPR, SBCM and SBPM.
Signed-off-by: Jiri Pirko
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 8 +
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 21 +++
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 161 -
3 files changed, 189 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 324848d..60fc109 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -2136,6 +2136,7 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
err_switchdev_init:
err_lag_init:
+ mlxsw_sp_buffers_fini(mlxsw_sp);
err_buffers_init:
err_flood_init:
mlxsw_sp_traps_fini(mlxsw_sp);
@@ -2150,6 +2151,7 @@ static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
{
struct mlxsw_sp *mlxsw_sp = mlxsw_core_driver_priv(mlxsw_core);
+ mlxsw_sp_buffers_fini(mlxsw_sp);
mlxsw_sp_switchdev_fini(mlxsw_sp);
mlxsw_sp_traps_fini(mlxsw_sp);
mlxsw_sp_event_unregister(mlxsw_sp, MLXSW_TRAP_ID_PUDE);
@@ -2200,6 +2202,12 @@ static struct mlxsw_driver mlxsw_sp_driver = {
.fini = mlxsw_sp_fini,
.port_split = mlxsw_sp_port_split,
.port_unsplit = mlxsw_sp_port_unsplit,
+ .sb_pool_get= mlxsw_sp_sb_pool_get,
+ .sb_pool_set= mlxsw_sp_sb_pool_set,
+ .sb_port_pool_get = mlxsw_sp_sb_port_pool_get,
+ .sb_port_pool_set = mlxsw_sp_sb_port_pool_set,
+ .sb_tc_pool_bind_get= mlxsw_sp_sb_tc_pool_bind_get,
+ .sb_tc_pool_bind_set= mlxsw_sp_sb_tc_pool_bind_set,
.txhdr_construct= mlxsw_sp_txhdr_construct,
.txhdr_len = MLXSW_TXHDR_LEN,
.profile= &mlxsw_sp_config_profile,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index ed3c871..4c3d8a7 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -272,7 +272,28 @@ enum mlxsw_sp_flood_table {
};
int mlxsw_sp_buffers_init(struct mlxsw_sp *mlxsw_sp);
+void mlxsw_sp_buffers_fini(struct mlxsw_sp *mlxsw_sp);
int mlxsw_sp_port_buffers_init(struct mlxsw_sp_port *mlxsw_sp_port);
+int mlxsw_sp_sb_pool_get(struct mlxsw_core *mlxsw_core,
+unsigned int sb_index, u16 pool_index,
+struct devlink_sb_pool_info *pool_info);
+int mlxsw_sp_sb_pool_set(struct mlxsw_core *mlxsw_core,
+unsigned int sb_index, u16 pool_index, u32 size,
+enum devlink_sb_threshold_type threshold_type);
+int mlxsw_sp_sb_port_pool_get(struct mlxsw_core_port *mlxsw_core_port,
+ unsigned int sb_index, u16 pool_index,
+ u32 *p_threshold);
+int mlxsw_sp_sb_port_pool_set(struct mlxsw_core_port *mlxsw_core_port,
+ unsigned int sb_index, u16 pool_index,
+ u32 threshold);
+int mlxsw_sp_sb_tc_pool_bind_get(struct mlxsw_core_port *mlxsw_core_port,
+unsigned int sb_index, u16 tc_index,
+enum devlink_sb_pool_type pool_type,
+u16 *p_pool_index, u32 *p_threshold);
+int mlxsw_sp_sb_tc_pool_bind_set(struct mlxsw_core_port *mlxsw_core_port,
+unsigned int sb_index, u16 tc_index,
+enum devlink_sb_pool_type pool_type,
+u16 pool_index, u32 threshold);
int mlxsw_sp_switchdev_init(struct mlxsw_sp *mlxsw_sp);
void mlxsw_sp_switchdev_fini(struct mlxsw_sp *mlxsw_sp);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
index beca792..17f8564 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
@@ -470,6 +470,8 @@ static int mlxsw_sp_sb_mms_init(struct mlxsw_sp *mlxsw_sp)
return 0;
}
+#define MLXSW_SP_SB_SIZE (16 * 1024 * 1024)
+
int mlxsw_sp_buffers_init(struct mlxsw_sp *mlxsw_sp)
{
int err;
@@ -484,7 +486,16 @@ int mlxsw_sp_buffers_init(struct mlxsw_sp *mlxsw_sp)
if (err)
return err;
- return 0;
+ return devlink_sb_register(priv_to_devlink(mlxsw_sp->core), 0,
+ MLXSW_SP_SB_SIZE,
+ MLXSW_SP_SB_POOL_COUNT,
+ MLXSW_SP_SB_POOL_COUNT,
+ MLXSW_SP_SB_TC_COUNT);
+}
+
+void mlxsw_sp_buffers_fini(struct mlxsw_sp *mlxsw_sp)
+{
+ devlink_sb_unregister(priv_to_devlink(mlxs
Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB
[expand cc a bit more]
Hello,
On Wed, Mar 16, 2016 at 06:25:59PM +0100, Sebastian Frias wrote:
> Commit 687908c2b649 ("net: phy: at803x: simplify using
> devm_gpiod_get_optional and its 4th argument") introduced a dependency
> on GPIOLIB that was not there before.
>
> This commit removes such dependency by checking the return code and
> comparing it against ENOSYS which is returned when GPIOLIB is not
> selected.
>
> Fixes: 687908c2b649 ("net: phy: at803x: simplify using
> devm_gpiod_get_optional and its 4th argument")
>
> Signed-off-by: Sebastian Frias
> ---
> drivers/net/phy/at803x.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index 2174ec9..88b7ff3 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -252,7 +252,9 @@ static int at803x_probe(struct phy_device *phydev)
> return -ENOMEM;
>
> gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
> - if (IS_ERR(gpiod_reset))
> + if (PTR_ERR(gpiod_reset) == -ENOSYS)
> + gpiod_reset = NULL;
> + else if (IS_ERR(gpiod_reset))
this isn't better either (IMHO it's worse, but maybe this is debatable
and also depends on your POV).
With 687908c2b649 I made kernels without GPIOLIB fail to bind this
device. I admit this is not maximally nice.
Your change makes the driver bind in this case again and then the reset
gpio isn't handled at all which might result in a later and harder to
debug error.
The better approach to fix your problem is: make the driver depend (or
force) on GPIOLIB. Or alternatively, drop reset-handling from the
driver.
>From a driver perspecitive, it would be nice if devm_gpiod_get_optional
returned NULL iff the respective gpio isn't specified even with
GPIOLIB=n, but this isn't sensible either because it would result in
quite some gpiolib code to not being conditionally compiled on
CONFIG_GPIOLIB any more.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers
On Fri, Mar 18, 2016 at 04:46:23PM -0400, Tejun Heo wrote: > Hello, Jeff. > > On Thu, Mar 17, 2016 at 09:32:16PM -0400, Jeff Layton wrote: > > > * Are network devices expected to be able to serve as a part of > > > storage stack which is depended upon for memory reclamation? > > > > I think they should be. Cached NFS pages can consume a lot of memory, > > and flushing them generally takes network device access. > > But does that actually work? It's pointless to add WQ_MEM_RECLAIM to > workqueues unless all other things are also guaranteed to make forward > progress regardless of memory pressure. It's supposed to work. Also note there was a bunch of work done to allow swap on NFS: see a564b8f0 "nfs: enable swap on NFS". > > > > * If so, are all the pieces in place for that to work for all (or at > > > least most) network devices? If it's only for a subset of NICs, how > > > can one tell whether a given driver needs forward progress guarantee > > > or not? > > > > > > * I assume that wireless drivers aren't and can't be used in this > > > fashion. Is that a correction assumption? > > > > > > > People do mount NFS over wireless interfaces. It's not terribly common > > though, in my experience. > > Ditto, I'm very skeptical that this actually works in practice and > people expect and depend on it. I don't follow wireless development > closely but haven't heard anyone talking about reserving memory pools > or people complaining about wireless being the cause of OOM. > > So, I really want to avoid spraying WQ_MEM_RECLAIM if it doesn't serve > actual purposes. It's wasteful, sets bad precedences and confuses > future readers. I use NFS mounts over wifi at home. I may just be odd. I seem to recall some bug reports about suspend vs. NFS--were those also on laptops using NFS? I wonder if home media centers might do writes over wifi to network storage? Googling for "nfs wifi" turns up lots of individuals doing this. My first impulse is to say that it's probably not perfect but that we shouldn't make it worse. But, I don't claim to understand the WQ_MEM_RECLAIM-proliferation issue you're seeing --b.
[PATCH net 1/3] vxlan: fix populating tclass in vxlan6_get_route
Jiri mentioned that flowi6_tos of struct flowi6 is never used/read
anywhere. In fact, rest of the kernel uses the flowi6's flowlabel,
where the traffic class _and_ the flowlabel (aka flowinfo) is encoded.
For example, for policy routing, fib6_rule_match() uses ip6_tclass()
that is applied on the flowlabel member for matching on tclass. Similar
fix is needed for geneve, where flowi6_tos is set as well. Installing
a v6 blackhole rule that f.e. matches on tos is now working with vxlan.
Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class")
Reported-by: Jiri Benc
Signed-off-by: Daniel Borkmann
---
drivers/net/vxlan.c | 3 +--
include/net/ipv6.h | 6 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 800106a7..7bfcb9a62a 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1810,10 +1810,9 @@ static struct dst_entry *vxlan6_get_route(struct
vxlan_dev *vxlan,
memset(&fl6, 0, sizeof(fl6));
fl6.flowi6_oif = oif;
- fl6.flowi6_tos = RT_TOS(tos);
fl6.daddr = *daddr;
fl6.saddr = vxlan->cfg.saddr.sin6.sin6_addr;
- fl6.flowlabel = label;
+ fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tos), label);
fl6.flowi6_mark = skb->mark;
fl6.flowi6_proto = IPPROTO_UDP;
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index f3c9857..d0aeb97 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -835,6 +835,12 @@ static inline u8 ip6_tclass(__be32 flowinfo)
{
return ntohl(flowinfo & IPV6_TCLASS_MASK) >> IPV6_TCLASS_SHIFT;
}
+
+static inline __be32 ip6_make_flowinfo(unsigned int tclass, __be32 flowlabel)
+{
+ return htonl(tclass << IPV6_TCLASS_SHIFT) | flowlabel;
+}
+
/*
* Prototypes exported by ipv6
*/
--
1.9.3
[PATCH net] tcp/dccp: remove obsolete WARN_ON() in icmp handlers
From: Eric Dumazet
Now SYN_RECV request sockets are installed in ehash table, an ICMP
handler can find a request socket while another cpu handles an incoming
packet transforming this SYN_RECV request socket into an ESTABLISHED
socket.
We need to remove the now obsolete WARN_ON(req->sk), since req->sk
is set when a new child is created and added into listener accept queue.
If this race happens, the ICMP will do nothing special.
Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table")
Signed-off-by: Eric Dumazet
Reported-by: Ben Lazarus
Reported-by: Neal Cardwell
---
net/dccp/ipv4.c |2 --
net/ipv4/tcp_ipv4.c |2 --
2 files changed, 4 deletions(-)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index b5672e5fe649..9c67a961ba53 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -204,8 +204,6 @@ void dccp_req_err(struct sock *sk, u64 seq)
* ICMPs are not backlogged, hence we cannot get an established
* socket here.
*/
- WARN_ON(req->sk);
-
if (!between48(seq, dccp_rsk(req)->dreq_iss, dccp_rsk(req)->dreq_gss)) {
NET_INC_STATS_BH(net, LINUX_MIB_OUTOFWINDOWICMPS);
} else {
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0b02ef773705..e7528b101e68 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -319,8 +319,6 @@ void tcp_req_err(struct sock *sk, u32 seq, bool abort)
/* ICMPs are not backlogged, hence we cannot get
* an established socket here.
*/
- WARN_ON(req->sk);
-
if (seq != tcp_rsk(req)->snt_isn) {
NET_INC_STATS_BH(net, LINUX_MIB_OUTOFWINDOWICMPS);
} else if (abort) {
Re: [PATCH net-next v2 0/4] vxlan: implement Generic Protocol Extension (GPE)
From: Jiri Benc Date: Wed, 16 Mar 2016 17:51:08 +0100 > This patchset implements VXLAN-GPE. Sorry, this is too late for net-next, please resubmit after the current merge window.
Re: [PATCH v3 2/9] net: arc_emac: add phy reset is optional for device tree
Hi Sergei,
在 2016年03月16日 21:57, Sergei Shtylyov 写道:
Hello.
On 3/14/2016 11:01 AM, Caesar Wang wrote:
This patch adds the following property for arc_emac.
1) phy-reset-gpios:
The phy-reset-gpio is an optional property for arc emac device tree
boot.
Change the binding document to match the driver code.
2) phy-reset-duration:
Different boards may require different phy reset duration. Add property
phy-reset-duration for device tree probe, so that the boards that need
a longer reset duration can specify it in their device tree.
Anyway, we can add the above property for arc emac.
Signed-off-by: Caesar Wang
Could you have a look at drivers/net/ethernet/cadence/macb/? It
seems to be the only driver which places the PHY's "reset-gpios" prop
correctly, into the PHY subnode? I'm currently working on adding
support of this prop into phylib...
I see the driver on now.
/* Power up the PHY if there is a GPIO reset */
phy_node = of_get_next_available_child(np, NULL);
if (phy_node) {
int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
if (gpio_is_valid(gpio))
bp->reset_gpio = gpio_to_desc(gpio);
gpiod_set_value(bp->reset_gpio, GPIOD_OUT_HIGH);
}
of_node_put(phy_node);
...
Frankly, I don't like this way in device drivers.
That's seem same with the /drivers/mmc/core/pwrseq_simple.c, power up
the device.
Is it not really reset hardware PHY from the gpio reset pin? Just power up.
Of course, I hope to see and test it if you improve the PHY framework to
support the phy reset.:-)
---
Anyway, David had applied this series patches into net branch.
Although the clock and dts patches should be applied into Heiko branch,
I'm glad to see David's way.
Heiko branch:
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/
I wish won't destory Heiko to merge in the future.
-Caesar
MBR, Sergei
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
Thanks,
Caesar
[PATCH net-next 1/2] ovs: split ovs_flow_stats_update into skb and stats
The function to update statistics takes a skbuff as parameter. It
would be handy to have the statistics update part in one function, and
the skbuff part in another one.
The next commit will make use of the new ovs_flow_stats_update
function.
Signed-off-by: Samuel Gauthier
---
net/openvswitch/datapath.c | 2 +-
net/openvswitch/flow.c | 17 -
net/openvswitch/flow.h | 4 ++--
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 0cc66a4e492d..8c6dcffe9b62 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -284,7 +284,7 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct
sw_flow_key *key)
goto out;
}
- ovs_flow_stats_update(flow, key->tp.flags, skb);
+ ovs_flow_stats_update_skb(flow, key->tp.flags, skb);
sf_acts = rcu_dereference(flow->sf_acts);
ovs_execute_actions(dp, skb, sf_acts, key);
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 0ea128eeeab2..831db351fef9 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -67,12 +67,11 @@ u64 ovs_flow_used_time(unsigned long flow_jiffies)
#define TCP_FLAGS_BE16(tp) (*(__be16 *)&tcp_flag_word(tp) & htons(0x0FFF))
-void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
- const struct sk_buff *skb)
+static void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
+ unsigned int count, unsigned int len)
{
struct flow_stats *stats;
int node = numa_node_id();
- int len = skb->len + (skb_vlan_tag_present(skb) ? VLAN_HLEN : 0);
stats = rcu_dereference(flow->stats[node]);
@@ -109,7 +108,7 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16
tcp_flags,
node);
if (likely(new_stats)) {
new_stats->used = jiffies;
- new_stats->packet_count = 1;
+ new_stats->packet_count = count;
new_stats->byte_count = len;
new_stats->tcp_flags = tcp_flags;
spin_lock_init(&new_stats->lock);
@@ -124,13 +123,21 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16
tcp_flags,
}
stats->used = jiffies;
- stats->packet_count++;
+ stats->packet_count += count;
stats->byte_count += len;
stats->tcp_flags |= tcp_flags;
unlock:
spin_unlock(&stats->lock);
}
+void ovs_flow_stats_update_skb(struct sw_flow *flow, __be16 tcp_flags,
+ const struct sk_buff *skb)
+{
+ int len = skb->len + (skb_vlan_tag_present(skb) ? VLAN_HLEN : 0);
+
+ ovs_flow_stats_update(flow, tcp_flags, 1, len);
+}
+
/* Must be called with rcu_read_lock or ovs_mutex. */
void ovs_flow_stats_get(const struct sw_flow *flow,
struct ovs_flow_stats *ovs_stats,
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index 1d055c559eaf..51e10c4b1ce6 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -210,8 +210,8 @@ static inline bool ovs_identifier_is_key(const struct
sw_flow_id *sfid)
return !ovs_identifier_is_ufid(sfid);
}
-void ovs_flow_stats_update(struct sw_flow *, __be16 tcp_flags,
- const struct sk_buff *);
+void ovs_flow_stats_update_skb(struct sw_flow *, __be16 tcp_flags,
+ const struct sk_buff *);
void ovs_flow_stats_get(const struct sw_flow *, struct ovs_flow_stats *,
unsigned long *used, __be16 *tcp_flags);
void ovs_flow_stats_clear(struct sw_flow *);
--
2.2.1.62.g3f15098
[PATCH] Add support to control PHY LEDs
Hi all, We had a requirement to disable the PHY link LEDs during system standby mode without turning off the ethernet module. To achieve that, I have prepared the sysfs interface turn on/off the PHY link LEDs. Please suggest if there is any better way to achieve this. Thanks, Vishal Vishal Thanki (1): net: phy: at803x: Add support to control PHY LEDs drivers/net/phy/Kconfig | 7 + drivers/net/phy/at803x.c | 71 2 files changed, 78 insertions(+) -- 2.4.3
Re: [PATCH] net: consolidate lock/unlock into unlock_wait
On Fri, Mar 18, 2016 at 03:35:18PM -0700, Joe Perches wrote: > On Fri, 2016-03-18 at 17:37 -0400, David Miller wrote: > > From: Nicholas Mc Guire > > > The spin_lock()/spin_unlock() is synchronizing on the adapter->work_lock > > > as the comment also suggests, which is equivalent to spin_unlock_wait() > > > but the later should be more efficient. > [] > > There really is no justification for this change. > > This is an optimization in a slow-path of the driver. > > The device is a rarely used older piece of hardware. > > It really might be nice to take some of the ancient > hardware drivers in drivers/net and move them into > some separate subdirectory like: > > drivers/net/ancient > or > drivers/net/antiques > or > drivers/net/archaic > etc... > > so there's some clear designation that these crufty > old drivers don't need to be touched anymore except > for maybe when kernel wide changes occur. > actually thats just the problem - some of those did not perform such kernel wide changes lock/unlock -> unlock_wait being one of them. But having a distinction as proposed to keep people like me from scanning them, sounds like a good idea. Will add an "age of code" check before submitting API cleanups. thx! hofrat
Re: [PATCH net-next 3/6] bridge: simplify the stp_state_store by calling store_bridge_parm
On 03/16/2016 02:34 PM, Xin Long wrote: > There are some repetitive codes in stp_state_store, we can remove > them by calling store_bridge_parm. > > Signed-off-by: Xin Long > --- > net/bridge/br_sysfs_br.c | 24 +++- > 1 file changed, 7 insertions(+), 17 deletions(-) > LGTM. Note: it introduces a bug (missing rtnl) until patch 04 is applied. Acked-by: Nikolay Aleksandrov
ipv6 not bringing up due to qdisc_tx_is_noop failing
Hello Dave, I've been chasing a rather strange problem and I saw you were the person that authored most of the code involved so I'm addresing you, but will be happy to receive assistance from any one feeling knowledgeable enough on the issue. Basically I have an infiniband card on which I want to run ipv6 to this effect I load modules ib_qib (the infiniband card is qlogic QLE7342) and then I load module ib_ipoib and I get : IPv6: ADDRCONF(NETDEV_UP): ib0: link is not ready even though for example ibping and all that works. This happens because the check if (!addrconf_qdisc_ok(dev)) in addrconf_notify fails, since the dev's txq ->qdisc points to noop_qdisc. Now, here is what happens : 1. When the ib_ipoib module is loaded register_netdevice->dev_init_scheduler is called which sets the device's qdisc to noop_qdisc 2. Then via a netlink message the device is being activate, which calls into dev_activate->attach_one_default_qdisc which attaches the newly created default qdisc to the dev->sleeping_qdisc member 3. The addrconf_notify is invoked which fails the check since the netdev_queue's qdisk member was never updated (just the sleeping_qdisc) to anything different than the initial state (which is noop_qdisc). I have stack traces which do show this sequence of events, so my questions now are: 1. What's the difference between netdev_queue->qdisc and netdev_queue->qdisc_sleeping. Git blaming indicates those member haves existed even before the git history was started. 2. Shouldn't the netdev_queue->qdisc also be updated during attach_one_default_qdisc? Regards, Nikolay
Re: [PATCH ethtool 2/3] Add IPv6 support to NFC
On 13/03/16 16:43, Ben Hutchings wrote:
> On Mon, 2016-02-15 at 14:59 +, Edward Cree wrote:
>> Signed-off-by: Edward Cree
> [...]
>> @@ -950,6 +1154,19 @@ static int rxclass_get_mask(char *str, unsigned char
>> *p,
>> *(__be32 *)&p[opt->moffset] = ~val;
>> break;
>> }
>> + case OPT_IP6: {
>> + __be32 val[4];
>> + int i;
>> + err = rxclass_get_ipv6(str, val);
>> + if (err)
>> + return -1;
>> + for (i = 0; i < 4; i++) {
>> + ((__be32 *)&p[opt->offset])[i] = val[i];
>> + if (opt->moffset >= 0)
>> + ((__be32 *)&p[opt->moffset])[i] = ~val[i];
> This pointer arithmetic looks terrible. I think memcpy() would be much
> clearer here.
I've changed the version in rxclass_get_val to use memcpy() (and memset() the
mask). Unfortunately, we can't do that here, because we need to complement
the mask valueas we go, and afaik there's no library function to copy-and-
complement a byte array.
Glibc does, however, have a function memfrob(), which XORs every byte of an
arraywiththe constant 42. Useful feature, that.
On the other hand, the quoted code is still wrong because it's also writing
throughopt->offset and checking for opt->moffset>= 0, both daft copy-and-
paste errors onmypart. Will fix in next version.
> I won't apply patches labelled as "confidential". You need to stop
> including this nonsense in your public messages (I thought you fixed
> this once before).
In theory it's been fixed harder now - please let me know if not.
-Ed
Re: [PATCH net-next 5/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_if
On Wed, Mar 16, 2016 at 10:45 PM, Xin Long wrote: > yeah, because port fdb_flush is called by brport_store(), in the > common function. > do you think it''s redundant if we add a notification in bridge > fdb_flush to keep > consistence with port fdb_flush? just change it on patch 1/6.
Re: Extreme slowness in IPIP tunnel when routing through kernel 3.18 and later
On 03/17/2016 03:27 PM, Jesse Gross wrote: On Thu, Mar 17, 2016 at 7:02 AM, Patrick Boutilier wrote: I have an IPIP tunnel setup between two hosts in different buildings. The Linux router they route through causes extreme slowness in the tunnel when running kernels from 3.18 on . tcpdump shows many cksum errors which don't show up in the 3.17 and earlier kernels. Speed goes back to normal when rx-checksumming and tx-checksumming are turned off using ethtool on the Linux router . Would this be an effect of bulk network packet transmission that was introduced in 3.18 or some other issue? I just sent out a likely fix, would you mind testing it? https://patchwork.ozlabs.org/patch/599213/ Yes, that patch fixes the problem. Thanks. <>
Re: [PATCH net-next] ethtool: Set cmd field in ETHTOOL_GLINKSETTINGS response to wrong nwords
From: Ben Hutchings
Date: Mon, 14 Mar 2016 01:05:38 +
> When the ETHTOOL_GLINKSETTINGS implementation finds that userland is
> using the wrong number of words of link mode bitmaps (or is trying to
> find out the right numbers) it sets the cmd field to 0 in the response
> structure.
>
> This is inconsistent with the implementation of every other ethtool
> command, so let's remove that inconsistency before it gets into a
> stable release.
>
> Fixes: 3f1ac7a700d03 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS API")
> Signed-off-by: Ben Hutchings
Applied and queued up for -stable, thanks Ben.
[PATCH net-next 2/2] ovs: support to refresh a flow via netlink
The used parameter of a flow tells us when it was used for the last
time. It is possible to set this parameter to 0 using the
OVS_FLOW_ATTR_CLEAR attribute, which means 'never used'. But it is not
possible to set this parameter to 'now'.
With this commit, adding OVS_FLOW_ATTR_USED to a 'set flow' netlink
message refreshes the flow used time to the current time. The value in
OVS_FLOW_ATTR_USED attribute is not used in this case.
Signed-off-by: Samuel Gauthier
---
net/openvswitch/datapath.c | 2 ++
net/openvswitch/flow.c | 6 ++
net/openvswitch/flow.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 8c6dcffe9b62..f2050af3965a 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1183,6 +1183,8 @@ static int ovs_flow_cmd_set(struct sk_buff *skb, struct
genl_info *info)
/* Clear stats. */
if (a[OVS_FLOW_ATTR_CLEAR])
ovs_flow_stats_clear(flow);
+ if (a[OVS_FLOW_ATTR_USED])
+ ovs_flow_refresh(flow);
ovs_unlock();
if (reply)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 831db351fef9..602795dd3656 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -167,6 +167,12 @@ void ovs_flow_stats_get(const struct sw_flow *flow,
}
}
+/* Must be called with rcu_read_lock or ovs_mutex. */
+void ovs_flow_refresh(struct sw_flow *flow)
+{
+ ovs_flow_stats_update(flow, 0, 0, 0);
+}
+
/* Called with ovs_mutex. */
void ovs_flow_stats_clear(struct sw_flow *flow)
{
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index 51e10c4b1ce6..4b6b64c999ed 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -214,6 +214,7 @@ void ovs_flow_stats_update_skb(struct sw_flow *, __be16
tcp_flags,
const struct sk_buff *);
void ovs_flow_stats_get(const struct sw_flow *, struct ovs_flow_stats *,
unsigned long *used, __be16 *tcp_flags);
+void ovs_flow_refresh(struct sw_flow *);
void ovs_flow_stats_clear(struct sw_flow *);
u64 ovs_flow_used_time(unsigned long flow_jiffies);
--
2.2.1.62.g3f15098
Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
On Fri, Mar 18, 2016 at 10:45 AM, Wei Wang wrote: > Thanks all for the comments. > > Cong, you are right that for ipv6, the code does not take care of updating > sk_dst_cache entry like Ipv4. And this patch is updating the entry by > calling ip6_dst_store() to achieve similar functionality as Ipv4. My question is why not updating ip6_sk_update_pmtu() to sync with ipv4?
[PATCH (net-next.git) 2/2] stmmac: fix MDIO settings
Initially the phy_bus_name was added to manipulate the
driver name but it was recently just used to manage the
fixed-link and then to take some decision at run-time.
So the patch uses the is_pseudo_fixed_link and removes
the phy_bus_name variable not necessary anymore.
The driver can manage the mdio registration by using phy-handle,
dwmac-mdio and own parameter e.g. snps,phy-addr.
This patch takes care about all these possible configurations
and fixes the mdio registration in case of there is a real
transceiver or a switch (that needs to be managed by using
fixed-link).
Signed-off-by: Giuseppe Cavallaro
Reviewed-by: Andreas Färber
Tested-by: Frank Schäfer
Cc: Gabriel Fernandez
Cc: Dinh Nguyen
Cc: David S. Miller
Cc: Phil Reid
---
V2: fix NULL pointer
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16 +---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 19 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 84 +++
include/linux/stmmac.h |2 +-
4 files changed, 73 insertions(+), 48 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4c5ce98..943500b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -278,7 +278,6 @@ static void stmmac_eee_ctrl_timer(unsigned long arg)
*/
bool stmmac_eee_init(struct stmmac_priv *priv)
{
- char *phy_bus_name = priv->plat->phy_bus_name;
unsigned long flags;
bool ret = false;
@@ -290,7 +289,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
goto out;
/* Never init EEE in case of a switch is attached */
- if (phy_bus_name && (!strcmp(phy_bus_name, "fixed")))
+ if (priv->phydev->is_pseudo_fixed_link)
goto out;
/* MAC core supports the EEE feature. */
@@ -827,12 +826,8 @@ static int stmmac_init_phy(struct net_device *dev)
phydev = of_phy_connect(dev, priv->plat->phy_node,
&stmmac_adjust_link, 0, interface);
} else {
- if (priv->plat->phy_bus_name)
- snprintf(bus_id, MII_BUS_ID_SIZE, "%s-%x",
-priv->plat->phy_bus_name, priv->plat->bus_id);
- else
- snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
-priv->plat->bus_id);
+ snprintf(bus_id, MII_BUS_ID_SIZE, "stmmac-%x",
+priv->plat->bus_id);
snprintf(phy_id_fmt, MII_BUS_ID_SIZE + 3, PHY_ID_FMT, bus_id,
priv->plat->phy_addr);
@@ -871,9 +866,8 @@ static int stmmac_init_phy(struct net_device *dev)
}
/* If attached to a switch, there is no reason to poll phy handler */
- if (priv->plat->phy_bus_name)
- if (!strcmp(priv->plat->phy_bus_name, "fixed"))
- phydev->irq = PHY_IGNORE_INTERRUPT;
+ if (phydev->is_pseudo_fixed_link)
+ phydev->irq = PHY_IGNORE_INTERRUPT;
pr_debug("stmmac_init_phy: %s: attached to PHY (UID 0x%x)"
" Link = %d\n", dev->name, phydev->phy_id, phydev->link);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 0faf163..3f5512f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -198,29 +198,12 @@ int stmmac_mdio_register(struct net_device *ndev)
struct mii_bus *new_bus;
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
+ struct device_node *mdio_node = priv->plat->mdio_node;
int addr, found;
- struct device_node *mdio_node = NULL;
- struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
- if (IS_ENABLED(CONFIG_OF)) {
- for_each_child_of_node(priv->device->of_node, child_node) {
- if (of_device_is_compatible(child_node,
- "snps,dwmac-mdio")) {
- mdio_node = child_node;
- break;
- }
- }
-
- if (mdio_node) {
- netdev_dbg(ndev, "FOUND MDIO subnode\n");
- } else {
- netdev_warn(ndev, "No MDIO subnode found\n");
- }
- }
-
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 9cf181f..cf37ea5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stm
Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU
Hello.
On 3/16/2016 12:04 AM, Aaron Conole wrote:
This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it
exists, read the advised MTU and use it.
No proper error handling is provided for the case where a user changes the
negotiated MTU. A future commit will add proper error handling. Instead, a
warning is emitted if the guest changes the device MTU after previously
being given advice.
Signed-off-by: Aaron Conole
---
v2:
* Whitespace cleanup in the last hunk
* Code style change around the pr_warn
* Additional test for mtu change before printing warning
drivers/net/virtio_net.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 767ab11..429fe01 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
[...]
@@ -1390,8 +1391,11 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
{
+ struct virtnet_info *vi = netdev_priv(dev);
if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
return -EINVAL;
+ if ((vi->negotiated_mtu) && (dev->mtu != new_mtu))
Inner parens not needed, please be consistent with the code above.
[...]
MBR, Sergei
Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
On Wed, 2016-03-16 at 19:53 -0400, David Miller wrote:
> From: Wei Wang
> Date: Mon, 14 Mar 2016 13:59:47 -0700
>
> > From: Wei Wang
> >
> > When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> > the new mtu value is not properly updated in the dst_entry associated
> > with the socket.
> > This leads to the issue that the mtu value returned by getsockopt(sockfd,
> > IPPROTO_IPV6, IPV6_MTU, ...) is wrong.
> > The fix is to update sk->sk_dst_cache and other corresponding fields
> > when a new routing cache is allocated for the new pmtu in UDP connected
> > socket case.
> >
> > Signed-off-by: Wei Wang
>
> Wait a second:
>
> > if (nrt6) {
> > rt6_do_update_pmtu(nrt6, mtu);
> > -
> > - /* ip6_ins_rt(nrt6) will bump the
> > -* rt6->rt6i_node->fn_sernum
> > -* which will fail the next rt6_check() and
> > -* invalidate the sk->sk_dst_cache.
> > -*/
> > + if (sk)
> > + ip6_dst_store(sk, &nrt6->dst, daddr, saddr);
> > ip6_ins_rt(nrt6);
> > }
> > }
>
> I still haven't seen a satisfactory answer as to why the as-designed
> invalidation mechanism using fn_sernum is not working.
>
> If that's broken, then a lot of other things won't work properly
> either.
>
> I've read the ip6_ins_rt() code path several times, and it always
> increments the serial number, and therefore the next dst->check() call
> (which every cached route usage should invoke) should invalide
> this socket's route and lookup the new one.
>
> Why does this not work?
One of the issue is that IPV6_MTU getsockopt() will not check the dst,
but simply use __sk_dst_get() : It will then report old mtu.
Not sure we want to use the full check and then if dst appears to be
obsolete, do another route lookup ?
[PATCH v2 net-next 2/2] lan78xx: add ndo_get_stats64
From: Woojung Huh
Add lan78xx_get_stats64 of ndo_get_stats64 to report
all statistics counters including errors from HW statistics.
Read from HW when auto suspend is disabled, use saved counter when
auto suspend is enabled because periodic call to ndo_get_stats64
prevents USB auto suspend.
Signed-off-by: Woojung Huh
---
drivers/net/usb/lan78xx.c | 49 +++
1 file changed, 49 insertions(+)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index f20890e..d36d5eb 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -3261,6 +3261,54 @@ void lan78xx_tx_timeout(struct net_device *net)
tasklet_schedule(&dev->bh);
}
+struct rtnl_link_stats64 *lan78xx_get_stats64(struct net_device *netdev,
+ struct rtnl_link_stats64 *storage)
+{
+ struct lan78xx_net *dev = netdev_priv(netdev);
+ struct lan78xx_statstage64 stats;
+
+ /* curr_stat is updated by timer.
+* periodic reading from HW will prevent from entering USB auto suspend.
+* if autosuspend is disabled, read from HW.
+*/
+ if (!dev->udev->dev.power.runtime_auto)
+ lan78xx_update_stats(dev);
+
+ mutex_lock(&dev->stats.access_lock);
+ memcpy(&stats, &dev->stats.curr_stat, sizeof(stats));
+ mutex_unlock(&dev->stats.access_lock);
+
+ /* calc by driver */
+ storage->rx_packets = (__u64)netdev->stats.rx_packets;
+ storage->tx_packets = (__u64)netdev->stats.tx_packets;
+ storage->rx_bytes = (__u64)netdev->stats.rx_bytes;
+ storage->tx_bytes = (__u64)netdev->stats.tx_bytes;
+
+ /* use counter */
+ storage->rx_length_errors = stats.rx_undersize_frame_errors +
+ stats.rx_oversize_frame_errors;
+ storage->rx_crc_errors = stats.rx_fcs_errors;
+ storage->rx_frame_errors = stats.rx_alignment_errors;
+ storage->rx_fifo_errors = stats.rx_dropped_frames;
+ storage->rx_over_errors = stats.rx_oversize_frame_errors;
+ storage->rx_errors = stats.rx_fcs_errors +
+stats.rx_alignment_errors +
+stats.rx_fragment_errors +
+stats.rx_jabber_errors +
+stats.rx_undersize_frame_errors +
+stats.rx_oversize_frame_errors +
+stats.rx_dropped_frames;
+
+ storage->tx_carrier_errors = stats.tx_carrier_errors;
+ storage->tx_errors = stats.tx_fcs_errors +
+stats.tx_excess_deferral_errors +
+stats.tx_carrier_errors;
+
+ storage->multicast = stats.rx_multicast_frames;
+
+ return storage;
+}
+
static const struct net_device_ops lan78xx_netdev_ops = {
.ndo_open = lan78xx_open,
.ndo_stop = lan78xx_stop,
@@ -3274,6 +3322,7 @@ static const struct net_device_ops lan78xx_netdev_ops = {
.ndo_set_features = lan78xx_set_features,
.ndo_vlan_rx_add_vid= lan78xx_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = lan78xx_vlan_rx_kill_vid,
+ .ndo_get_stats64= lan78xx_get_stats64,
};
static void lan78xx_stat_monitor(unsigned long param)
--
2.7.0
[PATCH net-next 5/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_if
Now when we change the attributes of bridge or br_port by netlink,
a relevant netlink notification will be sent, but if we change them
by ioctl or sysfs, no notification will be sent.
We should ensure that whenever those attributes change internally or from
sysfs/ioctl, that a netlink notification is sent out to listeners.
Also, NetworkManager will use this in the future to listen for out-of-band
bridge master attribute updates and incorporate them into the runtime
configuration.
This patch is used for br_sysfs_if, and we also move br_ifinfo_notify out
of store_flag.
Signed-off-by: Xin Long
---
net/bridge/br_sysfs_if.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
index efe415a..1e04d4d 100644
--- a/net/bridge/br_sysfs_if.c
+++ b/net/bridge/br_sysfs_if.c
@@ -61,7 +61,6 @@ static int store_flag(struct net_bridge_port *p, unsigned
long v,
if (flags != p->flags) {
p->flags = flags;
br_port_flags_change(p, mask);
- br_ifinfo_notify(RTM_NEWLINK, p);
}
return 0;
}
@@ -253,8 +252,10 @@ static ssize_t brport_store(struct kobject *kobj,
spin_lock_bh(&p->br->lock);
ret = brport_attr->store(p, val);
spin_unlock_bh(&p->br->lock);
- if (ret == 0)
+ if (!ret) {
+ br_ifinfo_notify(RTM_NEWLINK, p);
ret = count;
+ }
}
rtnl_unlock();
}
--
2.1.0
Re: Extreme slowness in IPIP tunnel when routing through kernel 3.18 and later
On 03/17/2016 01:47 PM, Tom Herbert wrote: On Thu, Mar 17, 2016 at 7:02 AM, Patrick Boutilier wrote: I have an IPIP tunnel setup between two hosts in different buildings. The Linux router they route through causes extreme slowness in the tunnel when running kernels from 3.18 on . tcpdump shows many cksum errors which don't show up in the 3.17 and earlier kernels. Speed goes back to normal when rx-checksumming and tx-checksumming are turned off using ethtool on the Linux router . Would this be an effect of bulk network packet transmission that was introduced in 3.18 or some other issue? If this is happening on a router then the only case where checksums are pertinent should be if GSO/GRO is enabled. Please try disabling these. Also, are these showing up as checksum errors on the receiver (netstat -s). Yes, turning off GSO/GRO also fixes the issue. Not sure which value of netstat I am looking for. Compiling a new kernel now with Jesse's patch to test. Will report back in a bit. eth2 driver: igb version: 5.2.15-k firmware-version: 1.5.1 bus-info: :06:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no eth6 driver: ixgbe version: 3.19.1-k firmware-version: 0x8389 bus-info: :41:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no Example of cksum from tcpdump: Flags [.], cksum 0x2237 (incorrect -> 0xbb02), seq 424119200:424120648, ack 1, win 115, options [nop,nop,TS val 303173784 ecr 3971495454], length 1448 Results of nuttcp test with rx-checksumming and tx-checksumming on: Testing upload inside tunnel 0.0625 MB / 5.00 sec =0.1048 Mbps79 retrans 0.0625 MB / 5.00 sec =0.1048 Mbps59 retrans 0.0625 MB / 5.00 sec =0.1049 Mbps27 retrans 0.2096 MB / 16.11 sec =0.1092 Mbps 0 %TX 0 %RX 186 retrans 0.47 msRTT Testing download inside tunnel 0.5000 MB / 5.00 sec =0.8389 Mbps 112 retrans 2.6250 MB / 5.00 sec =4.4040 Mbps 412 retrans 0.8750 MB / 5.00 sec =1.4680 Mbps 156 retrans 4.0243 MB / 15.48 sec =2.1809 Mbps 0 %TX 0 %RX 705 retrans 0.47 msRTT Testing upload outside tunnel 423. MB / 5.00 sec = 709.4949 Mbps 275 retrans 442.0625 MB / 5.00 sec = 741.7008 Mbps53 retrans 418.5625 MB / 5.00 sec = 702.1329 Mbps 133 retrans 1287.0080 MB / 15.08 sec = 715.9252 Mbps 1 %TX 30 %RX 461 retrans 0.43 msRTT Testing download outside tunnel 552.4375 MB / 5.00 sec = 926.8347 Mbps26 retrans 555.1875 MB / 5.00 sec = 931.4499 Mbps17 retrans 553. MB / 5.00 sec = 927.7802 Mbps16 retrans 1664.2149 MB / 15.03 sec = 928.6737 Mbps 9 %TX 5 %RX 60 retrans 0.46 msRTT Results of nuttcp test with rx-checksumming and tx-checksumming off: Testing upload inside tunnel 440. MB / 5.00 sec = 738.0112 Mbps 117 retrans 433. MB / 5.00 sec = 726.4892 Mbps 135 retrans 447.9375 MB / 5.00 sec = 751.5714 Mbps 112 retrans 1321.0069 MB / 15.04 sec = 736.7213 Mbps 3 %TX 21 %RX 364 retrans 0.51 msRTT Testing download inside tunnel 494.0625 MB / 5.00 sec = 828.8973 Mbps 335 retrans 471. MB / 5.00 sec = 790.2050 Mbps 219 retrans 469.8750 MB / 5.00 sec = 788.3174 Mbps 220 retrans 1435.1875 MB / 15.00 sec = 802.4203 Mbps 89 %TX 12 %RX 774 retrans 0.46 msRTT Testing upload outside tunnel 431.2500 MB / 5.00 sec = 723.2808 Mbps33 retrans 446.3750 MB / 5.00 sec = 748.9268 Mbps10 retrans 475.4375 MB / 5.00 sec = 797.7044 Mbps 0 retrans 1355.0834 MB / 15.06 sec = 754.6438 Mbps 1 %TX 33 %RX 43 retrans 0.53 msRTT Testing download outside tunnel 424.8125 MB / 5.00 sec = 712.7061 Mbps 102 retrans 456.5625 MB / 5.00 sec = 765.9872 Mbps80 retrans 454. MB / 5.00 sec = 761.6935 Mbps 116 retrans 1335.7823 MB / 15.01 sec = 746.6959 Mbps 4 %TX 5 %RX 298 retrans 0.55 msRTT <>
Re: [PATCH v3 2/9] net: arc_emac: add phy reset is optional for device tree
Hello. On 3/14/2016 11:01 AM, Caesar Wang wrote: This patch adds the following property for arc_emac. 1) phy-reset-gpios: The phy-reset-gpio is an optional property for arc emac device tree boot. Change the binding document to match the driver code. 2) phy-reset-duration: Different boards may require different phy reset duration. Add property phy-reset-duration for device tree probe, so that the boards that need a longer reset duration can specify it in their device tree. Anyway, we can add the above property for arc emac. Signed-off-by: Caesar Wang Could you have a look at drivers/net/ethernet/cadence/macb/? It seems to be the only driver which places the PHY's "reset-gpios" prop correctly, into the PHY subnode? I'm currently working on adding support of this prop into phylib... MBR, Sergei
Re: linux-next: manual merge of the rdma tree with the net-next tree
2016-03-16 2:58 GMT+02:00 Stephen Rothwell :
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
>
> between commit:
>
> 60ab4584f5bf ("net/mlx5_core: Set flow steering dest only for forward
> rules")
>
> from the net-next tree and commit:
>
> b3638e1a7664 ("net/mlx5_core: Introduce forward to next priority action")
>
> from the rdma tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> index e848d708d2b7,bf3446794bd5..
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
> @@@ -73,10 -73,13 +73,13 @@@
> #define BY_PASS_MIN_LEVEL (KENREL_MIN_LEVEL + MLX5_BY_PASS_NUM_PRIOS +\
>LEFTOVERS_MAX_FT)
>
> -#define KERNEL_MAX_FT 2
> -#define KERNEL_NUM_PRIOS 1
> +#define KERNEL_MAX_FT 3
> +#define KERNEL_NUM_PRIOS 2
> #define KENREL_MIN_LEVEL 2
>
> + #define ANCHOR_MAX_FT 1
> + #define ANCHOR_NUM_PRIOS 1
> + #define ANCHOR_MIN_LEVEL (BY_PASS_MIN_LEVEL + 1)
> struct node_caps {
> size_t arr_sz;
> long*caps;
> @@@ -360,8 -367,13 +367,13 @@@ static void del_rule(struct fs_node *no
> memcpy(match_value, fte->val, sizeof(fte->val));
> fs_get_obj(ft, fg->node.parent);
> list_del(&rule->node.list);
> + if (rule->sw_action == MLX5_FLOW_CONTEXT_ACTION_FWD_NEXT_PRIO) {
> + mutex_lock(&rule->dest_attr.ft->lock);
> + list_del(&rule->next_ft);
> + mutex_unlock(&rule->dest_attr.ft->lock);
> + }
> - fte->dests_size--;
> - if (fte->dests_size) {
> + if ((fte->action & MLX5_FLOW_CONTEXT_ACTION_FWD_DEST) &&
> + --fte->dests_size) {
> err = mlx5_cmd_update_fte(dev, ft,
> fg->id, fte);
> if (err)
> @@@ -762,9 -835,9 +835,10 @@@ static struct mlx5_flow_rule *alloc_rul
> if (!rule)
> return NULL;
>
> + INIT_LIST_HEAD(&rule->next_ft);
> rule->node.type = FS_TYPE_FLOW_DEST;
> - memcpy(&rule->dest_attr, dest, sizeof(*dest));
> + if (dest)
> + memcpy(&rule->dest_attr, dest, sizeof(*dest));
>
> return rule;
> }
> @@@ -783,12 -856,16 +857,17 @@@ static struct mlx5_flow_rule *add_rule_
> return ERR_PTR(-ENOMEM);
>
> fs_get_obj(ft, fg->node.parent);
> - /* Add dest to dests list- added as first element after the head */
> + /* Add dest to dests list- we need flow tables to be in the
> +* end of the list for forward to next prio rules.
> +*/
> tree_init_node(&rule->node, 1, del_rule);
> - list_add_tail(&rule->node.list, &fte->node.children);
> + if (dest && dest->type != MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE)
> + list_add(&rule->node.list, &fte->node.children);
> + else
> + list_add_tail(&rule->node.list, &fte->node.children);
> - fte->dests_size++;
> - if (fte->dests_size == 1)
> + if (dest)
> + fte->dests_size++;
> + if (fte->dests_size == 1 || !dest)
> err = mlx5_cmd_create_fte(get_dev(&ft->node),
> ft, fg->id, fte);
> else
Hi Stephen,
I reveiwed your merge and it's fine.
Thanks,
Maor
Re: [net-next 1/2] bonding: remove duplicate set of flag IFF_MULTICAST
On Wed, Mar 16, 2016 at 09:59:15AM +, Zhang Shengju wrote: > Remove unnecessary set of flag IFF_MULTICAST, since ether_setup > already does this. > > Signed-off-by: Zhang Shengju Signed-off-by: Andy Gospodarek > --- > drivers/net/bonding/bond_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c > index b6236ff..270b39c 100644 > --- a/drivers/net/bonding/bond_main.c > +++ b/drivers/net/bonding/bond_main.c > @@ -4175,7 +4175,7 @@ void bond_setup(struct net_device *bond_dev) > SET_NETDEV_DEVTYPE(bond_dev, &bond_type); > > /* Initialize the device options */ > - bond_dev->flags |= IFF_MASTER|IFF_MULTICAST; > + bond_dev->flags |= IFF_MASTER; > bond_dev->priv_flags |= IFF_BONDING | IFF_UNICAST_FLT | IFF_NO_QUEUE; > bond_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE | IFF_TX_SKB_SHARING); > > -- > 1.8.3.1 > > >
Re: [PATCH] rtlwifi: btcoexist: Convert BTC_PRINTK to btc__dbg
Joe Perches writes: > On Thu, 2016-03-17 at 21:54 -0500, Larry Finger wrote: >> On 03/17/2016 07:00 PM, Joe Perches wrote: >> > Use a more common logging style. > > [ 300K+ quote without comment ] Yeah, please try to avoid that. For example this makes the patchwork page for the patch really hard to read: https://patchwork.kernel.org/patch/8615131/ -- Kalle Valo
[net-next RFC 1/4] bindtosubnet: infrastructure
Signed-off-by: Gilberto Bertin
---
include/net/sock.h| 20 +++
include/uapi/asm-generic/socket.h | 1 +
net/core/sock.c | 111 ++
3 files changed, 132 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index f5ea148..c115c48 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -109,6 +109,16 @@ typedef struct {
#endif
} socket_lock_t;
+struct ipv4_subnet {
+ __be32 net;
+ u_char plen;
+};
+
+struct ipv6_subnet {
+ struct in6_addr net;
+ u_char plen;
+};
+
struct sock;
struct proto;
struct net;
@@ -176,6 +186,13 @@ struct sock_common {
unsigned char skc_ipv6only:1;
unsigned char skc_net_refcnt:1;
int skc_bound_dev_if;
+
+ unsigned char skc_bind_to_subnet;
+ union {
+ struct ipv4_subnet skc_bind_subnet4;
+ struct ipv6_subnet skc_bind_subnet6;
+ };
+
union {
struct hlist_node skc_bind_node;
struct hlist_nulls_node skc_portaddr_node;
@@ -327,6 +344,9 @@ struct sock {
#define sk_state __sk_common.skc_state
#define sk_reuse __sk_common.skc_reuse
#define sk_reuseport __sk_common.skc_reuseport
+#define sk_bind_to_subnet __sk_common.skc_bind_to_subnet
+#define sk_bind_subnet4__sk_common.skc_bind_subnet4
+#define sk_bind_subnet6__sk_common.skc_bind_subnet6
#define sk_ipv6only__sk_common.skc_ipv6only
#define sk_net_refcnt __sk_common.skc_net_refcnt
#define sk_bound_dev_if__sk_common.skc_bound_dev_if
diff --git a/include/uapi/asm-generic/socket.h
b/include/uapi/asm-generic/socket.h
index fb8a416..b4bcac2 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -30,6 +30,7 @@
#define SO_SNDLOWAT19
#define SO_RCVTIMEO20
#define SO_SNDTIMEO21
+#define SO_BINDTOSUBNET 22
#endif
/* Security levels - as per NRL IPv6 - don't actually do anything */
diff --git a/net/core/sock.c b/net/core/sock.c
index 6c1c8bc..7626153 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -571,6 +571,68 @@ out:
return ret;
}
+static int sock_setbindtosubnet(struct sock *sk, char __user *optval,
+ int optlen)
+{
+ int ret = -ENOPROTOOPT;
+
+ if (sk->sk_family == AF_INET) {
+ struct ipv4_subnet bind_subnet4;
+
+ ret = -EFAULT;
+ if (optlen != sizeof(struct ipv4_subnet))
+ goto out;
+
+ if (copy_from_user(&bind_subnet4, optval,
+ sizeof(struct ipv4_subnet)))
+ goto out;
+
+ ret = -EINVAL;
+ if (bind_subnet4.plen > 32)
+ goto out;
+
+ lock_sock(sk);
+
+ sk->sk_bind_to_subnet = 1;
+ sk->sk_bind_subnet4.net = bind_subnet4.net;
+ sk->sk_bind_subnet4.plen = bind_subnet4.plen;
+ sk_dst_reset(sk);
+
+ release_sock(sk);
+
+ ret = 0;
+ } else if (sk->sk_family == AF_INET6) {
+ struct ipv6_subnet bind_subnet6;
+
+ ret = -EFAULT;
+ if (optlen != sizeof(struct ipv6_subnet))
+ goto out;
+
+ if (copy_from_user(&bind_subnet6, optval,
+ sizeof(struct ipv6_subnet)))
+ goto out;
+
+ ret = -EINVAL;
+ if (bind_subnet6.plen > 128)
+ goto out;
+
+ lock_sock(sk);
+
+ sk->sk_bind_to_subnet = 1;
+ memcpy(&sk->sk_bind_subnet6.net, &bind_subnet6.net,
+ sizeof(struct in6_addr));
+ sk->sk_bind_subnet6.plen = bind_subnet6.plen;
+ sk_dst_reset(sk);
+
+ release_sock(sk);
+
+ ret = 0;
+ }
+
+out:
+ return ret;
+}
+
static int sock_getbindtodevice(struct sock *sk, char __user *optval,
int __user *optlen, int len)
{
@@ -611,6 +673,49 @@ out:
return ret;
}
+static int sock_getbindtosubnet(struct sock *sk, char __user *optval,
+ int __user *optlen, int len)
+{
+ int ret;
+
+ if (sk->sk_bind_to_subnet == 0) {
+ len = 0;
+ goto zero;
+ }
+
+ if (sk->sk_family == AF_INET) {
+ ret = -EINVAL;
+ if (len < sizeof(struct ipv4_subnet))
+ goto out;
+
+ len = sizeof(struct ipv4_subnet);
+
+ ret = -EFAULT;
+ if (copy_to_user(optval, &sk->sk_bind_subnet4, len))
+ goto out;
+
+ } else if (sk->sk_family == AF_INET6) {
+ ret = -EINVAL;
+
Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
On Thu, Mar 17, 2016 at 4:28 PM, Andrew Lunn wrote: >> > You should however consider writing a DSA driver for the switch. >> >> Do you mean SWITCHDEV or is this more or less the same? From time to >> time I'm looking at DSA/switchdev patches in the mailing list, but >> there seems to be not so many example in kernel. What are the latest >> slides, papers aside from Documentation/networking/switchdev.txt? > > I don't have access to the datasheet for this device. So i've no idea > how easy/hard it would be. > > Documentation/networking/switchdev.txt and > Documentation/networking/dsa/dsa.txt would be a good place to start. > > The mv88e6060.c is the simplest driver and gives you the minimum you > need to start with. Looking at the marketing brief, it looks like the > device can do more. But it is best to start simple, get the minimal > accepted, and then incrementally add more. Will do. Thanks. Yegor
Re: [PATCH 0/5] net: macb: Checkpatch cleanups
Nicolas, On Wed, Mar 16, 2016 at 6:39 AM, Nicolas Ferre wrote: > Le 13/03/2016 20:10, Moritz Fischer a écrit : >> Hi all, >> >> I backed out the variable scope changes and made a separate >> patch for the ether_addr_copy change. >> >> Changes from v1: > > As it's v2, it's better to add it in each subject of the patch series like: > "[PATCH v2 0/5] net: macb: Checkpatch cleanups" Yeah, I fat-fingered that. Figured it is less annoying than resending the series immediately. Do you want me to resend the series as v3 with Acked-bys and fixed patch 5? Through which tree will this go? Merci, Moritz
Re: [PATCH] xfrm: don't segment UFO packets
On Thu, Mar 17, 2016 at 10:41:15AM +0100, Jiri Bohac wrote: > On Thu, Mar 17, 2016 at 01:03:59PM +0800, Herbert Xu wrote: > > On Wed, Mar 16, 2016 at 05:00:26PM +0100, Jiri Bohac wrote: > > > Prevent xfrm_output() from segmenting UFO packets so that they will be > > > fragmented after the xfrm transforms. > > > > Fair enough. But I wonder if this is enough. Wouldn't UDP notice > > that we're doing IPsec and prefragment the packet anyway? So I think > > this check may also be needed in the UDP output path. > > Fixes my broken case. Is this IPv4 or IPv6? IPv4 should not create a GSO skb if IPsec is done. It checks for rt->dst.header_len in __ip_append_data() and does a fallback to the standard case if rt->dst.header_len is non zero. In IPv6 this check is missing, so this could be the problem if this is IPv6.
Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
On Thu, Mar 17, 2016 at 09:14:17AM +0100, Yegor Yefremov wrote:
> On Thu, Mar 17, 2016 at 12:05 AM, Andrew Lunn wrote:
> > On Wed, Mar 16, 2016 at 11:23:59PM +0100, Yegor Yefremov wrote:
> >> Hi Andrew,
> >>
> >> On Wed, Mar 16, 2016 at 5:18 PM, Andrew Lunn wrote:
> >> > On Wed, Mar 16, 2016 at 04:59:23PM +0100, Yegor Yefremov wrote:
> >> >
> >> >> This patch breaks my am335x based board, where one of the CPSW slaves
> >> >> is connected to IP175D switch chip via RMII interface. Since this
> >> >> patch packet reception is not working.
> >> >
> >> > Hi Yegor
> >> >
> >> > Which phy is causing the problem? A PHY inside the switch?
> >> >
> >> > Do you have two back to back PHYs between the MAC and the switch, or
> >> > is the CPSW RMII connected directly to the switch?
> >>
> >> CPSW RMII is connected directly to the switch.
> >
> > So which PHY is causing you problems?
Hi Yegor
Thanks for the details. This helps explain what is going on.
I'm looking at:
http://www.icplus.com.tw/pp-IP175D.html
> First of all this is the system in question [1]. am335x CPSW has two
> slaves and in this particular configuration CPSW is working in Dual
> EMAC mode, so that both slaves are independent interfaces eth0 and
> eth1.
>
> eth1 is connected to Atheros 8035 PHY via RGMII channel and is working
> as expected. eth0 is connected to ICPlus IP175D via RMII interface, so
> from CPSW point of view ICPlus IP175D is just an ordinary PHY. Both
> Atheros 8035 and ICPlus IP175D are connected via MDIO, so that both of
> them will be detected at runtime:
>
> davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
> davinci_mdio 4a101000.mdio: detected phy mask f00fff00
> Atheros 8035 ethernet 4a101000.mdio:07: GPIO lookup for consumer reset
> Atheros 8035 ethernet 4a101000.mdio:07: using lookup tables for GPIO lookup
> Atheros 8035 ethernet 4a101000.mdio:07: lookup for GPIO reset failed
> libphy: 4a101000.mdio: probed
> davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver
> ICPlus IP175C
> davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver
> ICPlus IP175C
> davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver
> ICPlus IP175C
> davinci_mdio 4a101000.mdio: phy[3]: device 4a101000.mdio:03, driver
> ICPlus IP175C
> davinci_mdio 4a101000.mdio: phy[4]: device 4a101000.mdio:04, driver
> ICPlus IP175C
So here we see the 5 PHYs connected to the switch. What we don't see
is what phy it connected to eth0. Since there is no PHY connected to
eth0, you should have a fixed_link node in your device tree.
I assume you are using am335x-baltos-ir5221.dts?
&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rmii";
dual_emac_res_vlan = <1>;
};
I'm assuming this means use the PHY at address 0 on the MDIO bus. This
is your problem. You have logically connected PHY0 to the eth0. So if
PHY0 is down, the MAC logically has no carrier. Hence you don't see
any packets. You should be able to quickly prove this. See what
happens when you connect a peer to port0 so the link comes up.
In reality, your hardware does not have a PHY connected to the MAC. It
goes straight to the switch. So you should be using a fixed-link here.
Try something like:
&cpsw_emac0 {
ixed-link {
speed = <100>;
full-duplex;
};
phy-mode = "rmii";
dual_emac_res_vlan = <1>;
};
Andrew
Re: [PATCH net-next] net/mlx4_core: Fix backward compatibility on VFs
On 03/18/2016 03:49 AM, Eli Cohen wrote:
Commit 85743f1eb345 ("net/mlx4_core: Set UAR page size to 4KB regardless
of system page size") introduced dependency where old VF drivers without
this fix fail to load if the PF driver runs with this commit.
To resolve this add a module parameter which disables that functionality
by default. If both the PF and VFs are running with a driver with that
commit the administrator may set the module param to true.
The module parameter is called enable_4k_uar.
Fixes: 85743f1eb345 ('net/mlx4_core: Set UAR page size to 4KB ...')
Signed-off-by: Eli Cohen
Thanks!
Tested-by: Alexey Kardashevskiy
---
drivers/net/ethernet/mellanox/mlx4/main.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c
b/drivers/net/ethernet/mellanox/mlx4/main.c
index 503ec23e84cc..358f7230da58 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -105,6 +105,11 @@ module_param(enable_64b_cqe_eqe, bool, 0444);
MODULE_PARM_DESC(enable_64b_cqe_eqe,
"Enable 64 byte CQEs/EQEs when the FW supports this (default:
True)");
+static bool enable_4k_uar;
+module_param(enable_4k_uar, bool, 0444);
+MODULE_PARM_DESC(enable_4k_uar,
+"Enable using 4K UAR. Should not be enabled if have VFs which do
not support 4K UARs (default: false)");
+
#define PF_CONTEXT_BEHAVIOUR_MASK (MLX4_FUNC_CAP_64B_EQE_CQE | \
MLX4_FUNC_CAP_EQE_CQE_STRIDE | \
MLX4_FUNC_CAP_DMFS_A0_STATIC)
@@ -423,7 +428,11 @@ static int mlx4_dev_cap(struct mlx4_dev *dev, struct
mlx4_dev_cap *dev_cap)
/* Virtual PCI function needs to determine UAR page size from
* firmware. Only master PCI function can set the uar page size
*/
- dev->uar_page_shift = DEFAULT_UAR_PAGE_SHIFT;
+ if (enable_4k_uar)
+ dev->uar_page_shift = DEFAULT_UAR_PAGE_SHIFT;
+ else
+ dev->uar_page_shift = PAGE_SHIFT;
+
mlx4_set_num_reserved_uars(dev, dev_cap);
}
@@ -2233,11 +2242,14 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
dev->caps.max_fmr_maps = (1 << (32 -
ilog2(dev->caps.num_mpts))) - 1;
- /* Always set UAR page size 4KB, set log_uar_sz accordingly */
- init_hca.log_uar_sz = ilog2(dev->caps.num_uars) +
- PAGE_SHIFT -
- DEFAULT_UAR_PAGE_SHIFT;
- init_hca.uar_page_sz = DEFAULT_UAR_PAGE_SHIFT - 12;
+ if (enable_4k_uar) {
+ init_hca.log_uar_sz = ilog2(dev->caps.num_uars) +
+ PAGE_SHIFT -
DEFAULT_UAR_PAGE_SHIFT;
+ init_hca.uar_page_sz = DEFAULT_UAR_PAGE_SHIFT - 12;
+ } else {
+ init_hca.log_uar_sz = ilog2(dev->caps.num_uars);
+ init_hca.uar_page_sz = PAGE_SHIFT - 12;
+ }
init_hca.mw_enabled = 0;
if (dev->caps.flags & MLX4_DEV_CAP_FLAG_MEM_WINDOW ||
--
Alexey
[PATCH net-next 1/6] bridge: add rtnl_lock in fdb_flush in br_sysfs_br.c
In fdb_delete, it will send rtnl msg, so before that, we should hold rtnl_lock in the function that call it in sysfs. Signed-off-by: Xin Long --- net/bridge/br_sysfs_br.c | 5 + 1 file changed, 5 insertions(+) diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c index 6b80914..095a751 100644 --- a/net/bridge/br_sysfs_br.c +++ b/net/bridge/br_sysfs_br.c @@ -345,7 +345,12 @@ static ssize_t flush_store(struct device *d, if (!ns_capable(dev_net(br->dev)->user_ns, CAP_NET_ADMIN)) return -EPERM; + if (!rtnl_trylock()) + return restart_syscall(); + br_fdb_flush(br); + rtnl_unlock(); + return len; } static DEVICE_ATTR_WO(flush); -- 2.1.0
Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
On Thu, Mar 17, 2016 at 4:12 PM, Andrew Lunn wrote:
>> After changing cpsw_emac0 entry to:
>>
>> &cpsw_emac0 {
>> phy-mode = "rmii";
>> dual_emac_res_vlan = <1>;
>> fixed-link {
>> speed = <100>;
>> full-duplex;
>> };
>> };
>>
>> I've got packets running in both directions.
>
> Great.
>
>> Now I have another problem: I cannot disable ICPlus IP175D ports via
>> SIOCSMIIREG as I could do previously. I get not ioctl errors [1], but
>> the ports are always on.
>>
>> [1]
>> https://github.com/visionsystemsgmbh/libonrisc/blob/master/src/onrisc.c#L83
>
> The MDIO bus is now logically not connected to eth0. Instead you have
> the fixed-link mdio device connected to eth0. So SIOCSMIIREG calls on
> eth0 now try to manipulate the fixed link phys.
>
> However, i think you can still access the MDIO bus, just use eth1 in
> your ioctl call.
Good trick :-)
> You should however consider writing a DSA driver for the switch.
Do you mean SWITCHDEV or is this more or less the same? From time to
time I'm looking at DSA/switchdev patches in the mailing list, but
there seems to be not so many example in kernel. What are the latest
slides, papers aside from Documentation/networking/switchdev.txt?
Yegor
net/bluetooth: use-after-free in hci_event_packet
Dear all,
I've hit the following use-after-free in hci_event_packet while
fuzzying kernel(4.4, on commit
9638685e32af961943b679fcb72d4ddd458eb18f) using syzkaller. I
cannot reproduce it with a standalone C program. But it reproduces
easily by replaying the fuzzer log using Go toolchain:
$ go get github.com/google/syzkaller
$ cd $GOPATH/src/github.com/google/syzkaller
$ make executor execprog
$ scp bin/syz-executor bin/syz-execprog (your@testmachine)
$ scp poc_file your@testmachine
on your test machine:
$ ./bin/syz-execprog -executor ./bin/syz-executor -cover=0 -repeat=0
-procs=16 poc_file
The content of the poc_file is as the following:
mmap(&(0x7f00)=nil, (0xd77000), 0x3, 0x32, 0x,
0x0)
r0 = syz_open_dev$vhci(&(0x7f78a000-0x2)="2f6465762f7668636900",
0x0, 0x2081)
writev(r0, &(0x7fd72000+0xce4)=[{&(0x7fd6d000)="ff00", 0x2}],
0x1)
write(r0,
&(0x7fd77000-0x56)="0422e1e37a57f86c13ecf1267dbc33d62693e36b1518dee20b325c6c99f61c416e7dc6dd0452224180f8197ba570311b02cf04e1875f9a9a70c9393c9d42175b341af060368bafea5e028b50be8afea2f53a9564d00b",
0x56)
After running about a few seconds, we will get the following reports:
(in /var/log/kern.log)
BUG: KASAN: use-after-free in hci_event_packet+0x8d45/0x9f90 at addr
88043ef6e310
Read of size 1 by task kworker/u17:11/9348
=
BUG kmalloc-512 (Tainted: GB ): kasan: bad access
detected
-
INFO: Allocated in __alloc_workqueue_key+0xf7/0xe50 age=2844 cpu=2
pid=9403
[< none >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
[< none >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
[< inline >] slab_alloc_node kernel/mm/slub.c:2532
[< inline >] slab_alloc kernel/mm/slub.c:2574
[< none >] __kmalloc+0x28f/0x320 kernel/mm/slub.c:3534
[< inline >] kmalloc kernel/include/linux/slab.h:468
[< inline >] kzalloc kernel/include/linux/slab.h:607
[< none >] __alloc_workqueue_key+0xf7/0xe50
kernel/kernel/workqueue.c:3853
[< none >] hci_register_dev+0x21b/0x870
kernel/net/bluetooth/hci_core.c:3053
[< none >] vhci_create_device+0x275/0x520
kernel/drivers/bluetooth/hci_vhci.c:135
[< inline >] vhci_get_user kernel/drivers/bluetooth/hci_vhci.c:209
[< none >] vhci_write+0x2ad/0x430
kernel/drivers/bluetooth/hci_vhci.c:289
[< none >] do_iter_readv_writev+0x18b/0x250 kernel/fs/read_write.c:703
[< none >] do_readv_writev+0x3b9/0x6e0 kernel/fs/read_write.c:847
[< none >] vfs_writev+0x86/0xc0 kernel/fs/read_write.c:886
[< inline >] SYSC_writev kernel/fs/read_write.c:919
[< none >] SyS_writev+0x111/0x2b0 kernel/fs/read_write.c:911
[< none >] entry_SYSCALL_64_fastpath+0x16/0x7a
kernel/arch/x86/entry/entry_64.S:185
INFO: Freed in rcu_free_wq+0xb6/0x110 age=353 cpu=5 pid=4134
[< none >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
[< inline >] slab_free kernel/mm/slub.c:2805
[< none >] kfree+0x279/0x2a0 kernel/mm/slub.c:3634
[< none >] rcu_free_wq+0xb6/0x110 kernel/kernel/workqueue.c:3159
[< inline >] __rcu_reclaim kernel/kernel/rcu/rcu.h:118
[< inline >] rcu_do_batch kernel/kernel/rcu/tree.c:2704
[< inline >] invoke_rcu_callbacks kernel/kernel/rcu/tree.c:2970
[< inline >] __rcu_process_callbacks kernel/kernel/rcu/tree.c:2937
[< none >] rcu_process_callbacks+0xb08/0x1230
kernel/kernel/rcu/tree.c:2954
[< none >] __do_softirq+0x23b/0x8a0 kernel/kernel/softirq.c:273
[< inline >] invoke_softirq kernel/kernel/softirq.c:350
[< none >] irq_exit+0x15d/0x190 kernel/kernel/softirq.c:391
[< inline >] exiting_irq kernel/./arch/x86/include/asm/apic.h:659
[< none >] smp_apic_timer_interrupt+0x7b/0xa0
kernel/arch/x86/kernel/apic/apic.c:932
[< none >] apic_timer_interrupt+0x8c/0xa0
kernel/arch/x86/entry/entry_64.S:520
[< inline >] zero_user_segments kernel/include/linux/highmem.h:202
[< none >] ext4_block_write_begin+0xb2e/0xd20
kernel/fs/ext4/inode.c:938
[< none >] ext4_da_write_begin+0x3ec/0xa30 kernel/fs/ext4/inode.c:2724
[< none >] generic_perform_write+0x297/0x540 kernel/mm/filemap.c:2537
[< none >] __generic_file_write_iter+0x351/0x5a0
kernel/mm/filemap.c:2662
[< none >] ext4_file_write_iter+0x2e7/0xc80 kernel/fs/ext4/file.c:171
[< inline >] new_sync_write kernel/fs/read_write.c:517
[< none >] __vfs_write+0x300/0x470 kernel/fs/read_write.c:530
[< none >] vfs_write+0x167/0x4a0 kernel/fs/read_write.c:577
[< inline >] SYSC_write kernel/fs/read_write.c:624
[< none >] SyS_write+0x111/0x220 kernel/fs/read_write.c:616
INFO: Slab 0xea0010fbdb00 objects=20 used=19 fp=0x88043ef6e310
flags=0x2fffc004080
Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket
From: Wei Wang
Date: Mon, 14 Mar 2016 13:59:47 -0700
> From: Wei Wang
>
> When ICMPV6_PKT_TOOBIG message is received by a connected UDP socket,
> the new mtu value is not properly updated in the dst_entry associated
> with the socket.
> This leads to the issue that the mtu value returned by getsockopt(sockfd,
> IPPROTO_IPV6, IPV6_MTU, ...) is wrong.
> The fix is to update sk->sk_dst_cache and other corresponding fields
> when a new routing cache is allocated for the new pmtu in UDP connected
> socket case.
>
> Signed-off-by: Wei Wang
Wait a second:
> if (nrt6) {
> rt6_do_update_pmtu(nrt6, mtu);
> -
> - /* ip6_ins_rt(nrt6) will bump the
> - * rt6->rt6i_node->fn_sernum
> - * which will fail the next rt6_check() and
> - * invalidate the sk->sk_dst_cache.
> - */
> + if (sk)
> + ip6_dst_store(sk, &nrt6->dst, daddr, saddr);
> ip6_ins_rt(nrt6);
> }
> }
I still haven't seen a satisfactory answer as to why the as-designed
invalidation mechanism using fn_sernum is not working.
If that's broken, then a lot of other things won't work properly
either.
I've read the ip6_ins_rt() code path several times, and it always
increments the serial number, and therefore the next dst->check() call
(which every cached route usage should invoke) should invalide
this socket's route and lookup the new one.
Why does this not work?
[PATCH] sctp: align MTU to a word
SCTP is a protocol that is aligned to a word (4 bytes). Thus using bare
MTU can sometimes return values that are not aligned, like for loopback,
which is 65536 but ipv4_mtu() limits that to 65535. This mis-alignment
will cause the last non-aligned bytes to never be used and can cause
issues with congestion control.
So it's better to just consider a lower MTU and keep congestion control
calcs saner as they are based on PMTU.
Same applies to icmp frag needed messages, which is also fixed by this
patch.
One other effect of this is the inability to send MTU-sized packet
without queueing or fragmentation and without hitting Nagle. As the
check performed at sctp_packet_can_append_data():
if (chunk->skb->len + q->out_qlen >= transport->pathmtu - packet->overhead)
/* Enough data queued to fill a packet */
return SCTP_XMIT_OK;
with the above example of MTU, if there are no other messages queued,
one cannot send a packet that just fits one packet (65532 bytes) and
without causing DATA chunk fragmentation or a delay.
Signed-off-by: Marcelo Ricardo Leitner
---
net/sctp/associola.c | 2 +-
net/sctp/input.c | 2 +-
net/sctp/transport.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index
a19b3e60770382507050a56a172ffc5adb2f497a..f89862194093f160c2801c22050690789d956b44
100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -1406,7 +1406,7 @@ void sctp_assoc_sync_pmtu(struct sock *sk, struct
sctp_association *asoc)
list_for_each_entry(t, &asoc->peer.transport_addr_list,
transports) {
if (t->pmtu_pending && t->dst) {
- sctp_transport_update_pmtu(sk, t, dst_mtu(t->dst));
+ sctp_transport_update_pmtu(sk, t, dst_mtu(t->dst) & ~3);
t->pmtu_pending = 0;
}
if (!pmtu || (t->pathmtu < pmtu))
diff --git a/net/sctp/input.c b/net/sctp/input.c
index
db76f1ab4ac2cb16b4568f0d9fbe4e3b90deaa1c..fda32738986971648ff73b05318b8a306d496446
100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -606,7 +606,7 @@ void sctp_v4_err(struct sk_buff *skb, __u32 info)
/* PMTU discovery (RFC1191) */
if (ICMP_FRAG_NEEDED == code) {
- sctp_icmp_frag_needed(sk, asoc, transport, info);
+ sctp_icmp_frag_needed(sk, asoc, transport, info & ~3);
goto out_unlock;
} else {
if (ICMP_PROT_UNREACH == code) {
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index
d517153891a6efca6242ce1a4b3d86afb9026542..22219e8e6e510469d9d5868245bd7e2a9e2faf78
100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -226,7 +226,7 @@ void sctp_transport_pmtu(struct sctp_transport *transport,
struct sock *sk)
}
if (transport->dst) {
- transport->pathmtu = dst_mtu(transport->dst);
+ transport->pathmtu = dst_mtu(transport->dst) & ~3;
} else
transport->pathmtu = SCTP_DEFAULT_MAXSEGMENT;
}
@@ -280,7 +280,7 @@ void sctp_transport_route(struct sctp_transport *transport,
return;
}
if (transport->dst) {
- transport->pathmtu = dst_mtu(transport->dst);
+ transport->pathmtu = dst_mtu(transport->dst) & ~3;
/* Initialize sk->sk_rcv_saddr, if the transport is the
* association's active path for getsockname().
--
2.5.0
[PATCH v5 0/4] Add Ethernet support on STM32F429
STM32F429 Chip embeds a Synopsys 3.50a MAC IP. This series: -enhance current stmmac driver to control it (code already available) and adds basic glue for STM32F429 chip. -Enable basic Net config in kernel. Note that DT patches are not present because STM32 pinctrl code is not yet avalaible. Changes since v4: -Fix dirty copy/past in bindings documentation patch. Changes since v3: -Fix "tx-clk" and "rx-clk" as required clocks. Driver and bindings are modified. Changes since v2: -Fix alphabetic order in Kconfig and Makefile. -Improve code according to Joachim review. -Binding: remove useless entry. Changes since v1: -Fix Kbuild issue in Kconfig. -Remove init/exit callbacks. Suspend/Resume and remove driver is no more driven in stmmac_pltfr but directly in dwmac-stm32 glue driver. -Take into account Joachim review. Regards. Alexandre. Alexandre TORGUE (4): net: ethernet: dwmac: add Ethernet glue logic for stm32 chip Documentation: Bindings: Add STM32 DWMAC glue net: ethernet: stmmac: add support of Synopsys 3.50a MAC IP ARM: STM32: Enable Ethernet in stm32_defconfig .../devicetree/bindings/net/stm32-dwmac.txt| 32 arch/arm/configs/stm32_defconfig | 9 + drivers/net/ethernet/stmicro/stmmac/Kconfig| 12 ++ drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 193 + .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 + 6 files changed, 248 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.txt create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c -- 1.9.1
[net-next RFC 3/4] bindtosubnet: TCP/IPv6 implementation
Signed-off-by: Gilberto Bertin
---
net/ipv6/inet6_connection_sock.c | 17 -
net/ipv6/inet6_hashtables.c | 6 ++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index 36c3f01..288bab6 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -27,6 +27,20 @@
#include
#include
+int inet6_csk_bind_subnet_conflict(const struct sock *sk,
+ const struct sock *sk2)
+{
+ u_char plen;
+
+ plen = min(sk->sk_bind_subnet6.plen, sk2->sk_bind_subnet6.plen);
+
+ if (sk->sk_bind_to_subnet && sk2->sk_bind_to_subnet)
+ return ipv6_prefix_equal(&sk->sk_bind_subnet6.net,
+&sk2->sk_bind_subnet6.net, plen);
+
+ return 0;
+}
+
int inet6_csk_bind_conflict(const struct sock *sk,
const struct inet_bind_bucket *tb, bool relax)
{
@@ -44,7 +58,8 @@ int inet6_csk_bind_conflict(const struct sock *sk,
if (sk != sk2 &&
(!sk->sk_bound_dev_if ||
!sk2->sk_bound_dev_if ||
-sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
+sk->sk_bound_dev_if == sk2->sk_bound_dev_if) &&
+inet6_csk_bind_subnet_conflict(sk, sk2)) {
if ((!reuse || !sk2->sk_reuse ||
sk2->sk_state == TCP_LISTEN) &&
(!reuseport || !sk2->sk_reuseport ||
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index 21ace5a..e88c82d 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -114,6 +114,12 @@ static inline int compute_score(struct sock *sk, struct
net *net,
return -1;
score++;
}
+ if (sk->sk_bind_to_subnet) {
+ if (!ipv6_prefix_equal(&sk->sk_bind_subnet6.net, daddr,
+ sk->sk_bind_subnet6.plen))
+ return -1;
+ score++;
+ }
if (sk->sk_incoming_cpu == raw_smp_processor_id())
score++;
}
--
2.7.2
[PATCH net-next v2 1/4] vxlan: move Ethernet initialization to a separate function
This will allow to initialize vxlan in ARPHRD_NONE mode based on the passed
rtnl attributes.
v2: renamed "l2mode" to "ether".
Signed-off-by: Jiri Benc
---
drivers/net/vxlan.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 1eb8347f440c..bfa1e2a5ba9e 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2405,7 +2405,7 @@ static int vxlan_fill_metadata_dst(struct net_device
*dev, struct sk_buff *skb)
return 0;
}
-static const struct net_device_ops vxlan_netdev_ops = {
+static const struct net_device_ops vxlan_netdev_ether_ops = {
.ndo_init = vxlan_init,
.ndo_uninit = vxlan_uninit,
.ndo_open = vxlan_open,
@@ -2459,10 +2459,6 @@ static void vxlan_setup(struct net_device *dev)
struct vxlan_dev *vxlan = netdev_priv(dev);
unsigned int h;
- eth_hw_addr_random(dev);
- ether_setup(dev);
-
- dev->netdev_ops = &vxlan_netdev_ops;
dev->destructor = free_netdev;
SET_NETDEV_DEVTYPE(dev, &vxlan_type);
@@ -2477,8 +2473,7 @@ static void vxlan_setup(struct net_device *dev)
dev->hw_features |= NETIF_F_GSO_SOFTWARE;
dev->hw_features |= NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_STAG_TX;
netif_keep_dst(dev);
- dev->priv_flags &= ~IFF_TX_SKB_SHARING;
- dev->priv_flags |= IFF_LIVE_ADDR_CHANGE | IFF_NO_QUEUE;
+ dev->priv_flags |= IFF_NO_QUEUE;
INIT_LIST_HEAD(&vxlan->next);
spin_lock_init(&vxlan->hash_lock);
@@ -2497,6 +2492,15 @@ static void vxlan_setup(struct net_device *dev)
INIT_HLIST_HEAD(&vxlan->fdb_head[h]);
}
+static void vxlan_ether_setup(struct net_device *dev)
+{
+ eth_hw_addr_random(dev);
+ ether_setup(dev);
+ dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+ dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+ dev->netdev_ops = &vxlan_netdev_ether_ops;
+}
+
static const struct nla_policy vxlan_policy[IFLA_VXLAN_MAX + 1] = {
[IFLA_VXLAN_ID] = { .type = NLA_U32 },
[IFLA_VXLAN_GROUP] = { .len = FIELD_SIZEOF(struct iphdr, daddr) },
@@ -2723,6 +2727,8 @@ static int vxlan_dev_configure(struct net *src_net,
struct net_device *dev,
__be16 default_port = vxlan->cfg.dst_port;
struct net_device *lowerdev = NULL;
+ vxlan_ether_setup(dev);
+
vxlan->net = src_net;
dst->remote_vni = conf->vni;
--
1.8.3.1
Re: [net-next v2] virtio_net: replace netdev_alloc_skb_ip_align() with napi_alloc_skb()
On Fri, Mar 18, 2016 at 8:42 AM, Paolo Abeni wrote: > This gives small but noticeable rx performance improvement (2-3%) > and will allow exploiting future napi improvement. > > Signed-off-by: Paolo Abeni > > -- > v2: replace also netdev_alloc_skb_ip_align() invocation in > add_recvbuf_small(), suggested by Venkatesh Srinivas > --- > drivers/net/virtio_net.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index fb0eae4..100e039 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -260,7 +260,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info > *vi, > p = page_address(page) + offset; > > /* copy small packet so we can reuse these pages for small data */ > - skb = netdev_alloc_skb_ip_align(vi->dev, GOOD_COPY_LEN); > + skb = napi_alloc_skb(&rq->napi, GOOD_COPY_LEN); > if (unlikely(!skb)) > return NULL; > > @@ -541,7 +541,7 @@ static int add_recvbuf_small(struct virtnet_info *vi, > struct receive_queue *rq, > struct virtio_net_hdr_mrg_rxbuf *hdr; > int err; > > - skb = __netdev_alloc_skb_ip_align(vi->dev, GOOD_PACKET_LEN, gfp); > + skb = __napi_alloc_skb(&rq->napi, GOOD_PACKET_LEN, gfp); > if (unlikely(!skb)) > return -ENOMEM; Sorry, I should've mentioned more in my first reply -- add_recvbuf_small is called from try_fill_recv in both NAPI and non-NAPI context (NAPI: via virtnet_receive from virtnet_poll; non-NAPI: via scheduled work, via virtnet_probe, and via virtnet_restore). I don't believe you can use __napi_alloc_skb() for the non-NAPI paths, it'd be a bit more work to plumb the context as an argument if you think its worth doing here. Looking forward to bulk skb allocation either way. HTH, -- vs;
SEC Filing
SEC XBRL Filings (www.secxbrlfilings.com) is offering new clients FIRST FILING FREE for a limited period of time and for a limited number of companies. In addition, will guarantee that we save you at least 20% ongoing versus any competitor in the industry. We have dedicated 24/7 Project management and round the clock production for all our services. If you are looking to improve the process, get supreme quality EDGAR and XBRL, save time and money then consider SEC XBRL Filings as a solution. It is worth calling to find out more (347) 480-4275. What's more, we will also update or create your INVESTOR RELATIONS(XBRL Web posting) page for FREE!!! Regards, Paul Smith SEC XBRL Filings E: i...@secxbrlfilings.com T: (347) 480-4275 www.secxbrlfilings.com
Re: [PATCH] net: phy: at803x: don't depend on GPIOLIB
Mason writes: > On 18/03/2016 21:11, Uwe Kleine-König wrote: > >> Hello, >> >> On Fri, Mar 18, 2016 at 08:31:20PM +0100, Mason wrote: >> >>> On 18/03/2016 20:12, Uwe Kleine-König wrote: >>> On Fri, Mar 18, 2016 at 04:56:21PM +0100, Sebastian Frias wrote: > What would you think of making at803x_link_change_notify() print a > message every time it should do a reset but does not has a way to do it? Then this question is obsolete because the device doesn't probe. >>> >>> I don't understand this statement. >>> >>> What does it mean for a question to be obsolete? >> >> If the driver doesn't probe because it cannot control the reset line, >> you don't need to think about how it should behave in >> at803x_link_change_notify without control of the reset line, because >> this code isn't reached then. > > If I understand correctly, it is possible to soft-reset the PHY > by writing to a specific register. The GPIO pin is useful only to > force a hardware-reset when the PHY is wedged by some random event. Yes, and some variants of this phy are broken and require a hard reset in certain situations. At least that's what the comment in the code says. -- Måns Rullgård
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
Am 07.03.2016 um 07:57 schrieb Holger Schurig: > I know that in Germany a good amount of land-line telephone line are > still using ISDN. [...] > Especially company line are using ISDN still, and there are some Linux > programs that act on then, e.g. Asterisk and derived PBX software has > ISDN support which is actively used. AFAIK none of these uses I4L anymore. Asterisk dropped I4L support with version 2 if my memory is correct and nowadays uses CAPI, mISDN or its own DAHDI interface. -- Tilman Schmidt E-Mail: til...@imap.cc Bonn, Germany Nous, on a des fleurs et des bougies pour nous protéger. signature.asc Description: OpenPGP digital signature
[PATCH v3 1/3] net: hns: Add reset function support for RoCE driver
It added reset function for RoCE driver. RoCE is a feature of hns.
In hip06 SoC, in RoCE reset process, it's needed to configure dsaf
channel reset, port and sl map info. Reset function of RoCE is
located in dsaf module, we only call it in RoCE driver when needed.
Signed-off-by: Lijun Ou
Signed-off-by: Wei Hu(Xavier)
Signed-off-by: Lisheng
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 84 ++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 30
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 62 +---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 13
4 files changed, 179 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 38fc5be..9370d46 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2593,6 +2594,89 @@ static struct platform_driver g_dsaf_driver = {
module_platform_driver(g_dsaf_driver);
+/**
+ * hns_dsaf_roce_reset - reset dsaf and roce
+ * @dsaf_fwnode: Pointer to framework node for the dasf
+ * @val: 0 - request reset , 1 - drop reset
+ * retuen 0 - success , negative -fail
+ */
+int hns_dsaf_roce_reset(struct fwnode_handle *dsaf_fwnode, u32 val)
+{
+ struct dsaf_device *dsaf_dev;
+ struct platform_device *pdev;
+ unsigned int mp;
+ unsigned int sl;
+ unsigned int credit;
+ int i;
+ const u32 port_map[DSAF_ROCE_CREDIT_CHN][DSAF_ROCE_CHAN_MODE_NUM] = {
+ {DSAF_ROCE_PORT_0, DSAF_ROCE_PORT_0, DSAF_ROCE_PORT_0},
+ {DSAF_ROCE_PORT_1, DSAF_ROCE_PORT_0, DSAF_ROCE_PORT_0},
+ {DSAF_ROCE_PORT_2, DSAF_ROCE_PORT_1, DSAF_ROCE_PORT_0},
+ {DSAF_ROCE_PORT_3, DSAF_ROCE_PORT_1, DSAF_ROCE_PORT_0},
+ {DSAF_ROCE_PORT_4, DSAF_ROCE_PORT_2, DSAF_ROCE_PORT_1},
+ {DSAF_ROCE_PORT_4, DSAF_ROCE_PORT_2, DSAF_ROCE_PORT_1},
+ {DSAF_ROCE_PORT_5, DSAF_ROCE_PORT_3, DSAF_ROCE_PORT_1},
+ {DSAF_ROCE_PORT_5, DSAF_ROCE_PORT_3, DSAF_ROCE_PORT_1},
+ };
+ const u32 sl_map[DSAF_ROCE_CREDIT_CHN][DSAF_ROCE_CHAN_MODE_NUM] = {
+ {DSAF_ROCE_SL_0, DSAF_ROCE_SL_0, DSAF_ROCE_SL_0},
+ {DSAF_ROCE_SL_0, DSAF_ROCE_SL_1, DSAF_ROCE_SL_1},
+ {DSAF_ROCE_SL_0, DSAF_ROCE_SL_0, DSAF_ROCE_SL_2},
+ {DSAF_ROCE_SL_0, DSAF_ROCE_SL_1, DSAF_ROCE_SL_3},
+ {DSAF_ROCE_SL_0, DSAF_ROCE_SL_0, DSAF_ROCE_SL_0},
+ {DSAF_ROCE_SL_1, DSAF_ROCE_SL_1, DSAF_ROCE_SL_1},
+ {DSAF_ROCE_SL_0, DSAF_ROCE_SL_0, DSAF_ROCE_SL_2},
+ {DSAF_ROCE_SL_1, DSAF_ROCE_SL_1, DSAF_ROCE_SL_3},
+ };
+
+ if (!is_of_node(dsaf_fwnode)) {
+ pr_err("Only support DT node!\n");
+ return -EINVAL;
+ }
+ pdev = of_find_device_by_node(to_of_node(dsaf_fwnode));
+ dsaf_dev = dev_get_drvdata(&pdev->dev);
+ if (AE_IS_VER1(dsaf_dev->dsaf_ver)) {
+ dev_err(dsaf_dev->dev, "%s v1 chip do not support roce!\n",
+ dsaf_dev->ae_dev.name);
+ return -ENODEV;
+ }
+
+ if (!val) {
+ /* Reset rocee-channels in dsaf and rocee */
+ hns_dsaf_srst_chns(dsaf_dev, 0x3f000, 0);
+ hns_dsaf_roce_srst(dsaf_dev, 0);
+ } else {
+ /* Configure dsaf tx roce correspond to port map and sl map */
+ mp = dsaf_read_dev(dsaf_dev, DSAF_ROCE_PORT_MAP_REG);
+ for (i = 0; i < DSAF_ROCE_CREDIT_CHN; i++)
+ dsaf_set_field(mp, 7 << i * 3, i * 3,
+ port_map[i][DSAF_ROCE_6PORT_MODE]);
+ dsaf_set_field(mp, 3 << i * 3, i * 3, 0);
+ dsaf_write_dev(dsaf_dev, DSAF_ROCE_PORT_MAP_REG, mp);
+
+ sl = dsaf_read_dev(dsaf_dev, DSAF_ROCE_SL_MAP_REG);
+ for (i = 0; i < DSAF_ROCE_CREDIT_CHN; i++)
+ dsaf_set_field(sl, 3 << i * 2, i * 2,
+ sl_map[i][DSAF_ROCE_6PORT_MODE]);
+ dsaf_write_dev(dsaf_dev, DSAF_ROCE_SL_MAP_REG, sl);
+
+ /* De-reset rocee-channels in dsaf and rocee */
+ hns_dsaf_srst_chns(dsaf_dev, 0x3f000, 1);
+ msleep(20);
+ hns_dsaf_roce_srst(dsaf_dev, 1);
+
+ /* Eanble dsaf channel rocee credit */
+ credit = dsaf_read_dev(dsaf_dev, DSAF_SBM_ROCEE_CFG_REG_REG);
+ dsaf_set_bit(credit, DSAF_SBM_ROCEE_CFG_CRD_EN_B, 0);
+ dsaf_write_dev(dsaf_dev, DSAF_SBM_ROCEE_CFG_REG_REG, credit);
+
+ dsaf_set_bit(credit, DSAF_SBM_ROCEE_CFG_CRD_EN_B, 1);
+ dsaf_write_dev(dsaf_dev, DSAF_SBM_ROCEE_CFG_REG_REG, credit);
+ }
+
Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
On Wed, Mar 16, 2016 at 11:23:59PM +0100, Yegor Yefremov wrote: > Hi Andrew, > > On Wed, Mar 16, 2016 at 5:18 PM, Andrew Lunn wrote: > > On Wed, Mar 16, 2016 at 04:59:23PM +0100, Yegor Yefremov wrote: > > > >> This patch breaks my am335x based board, where one of the CPSW slaves > >> is connected to IP175D switch chip via RMII interface. Since this > >> patch packet reception is not working. > > > > Hi Yegor > > > > Which phy is causing the problem? A PHY inside the switch? > > > > Do you have two back to back PHYs between the MAC and the switch, or > > is the CPSW RMII connected directly to the switch? > > CPSW RMII is connected directly to the switch. So which PHY is causing you problems? Andrew
Re: [PATCH net-next 0/3] Minor BPF follow-ups
From: Daniel Borkmann Date: Wed, 16 Mar 2016 01:42:48 +0100 > Some minor last follow-ups I still had in my queue. The first one adds > readability support for __sk_buff's tc_classid member, the remaining > two are some minor cleanups. For details please see individual patches. Series applied.
[PATCH v3 3/3] IB/hns: Add binding document for HiSilicon RoCE driver
This patch adds related DTS binding document for HiSilicon RoCE driver.
Signed-off-by: Lijun Ou
Signed-off-by: Wei Hu(Xavier)
---
.../bindings/infiniband/hisilicon-hns-roce.txt | 107 +
1 file changed, 107 insertions(+)
create mode 100644
Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
diff --git
a/Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
b/Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
new file mode 100644
index 000..5180fef
--- /dev/null
+++ b/Documentation/devicetree/bindings/infiniband/hisilicon-hns-roce.txt
@@ -0,0 +1,107 @@
+HiSilicon RoCE DT description
+
+HiSilicon RoCE engine is a part of network subsystem.
+It works depending on other part of network wubsytem, such as, gmac and
+dsa fabric.
+
+Additional properties are described here:
+
+Required properties:
+- compatible: Should contain "hisilicon,hns-roce-v1".
+- reg: Physical base address of the roce driver and
+length of memory mapped region.
+- eth-handle: phandle, specifies a reference to a node
+representing a ethernet device.
+- dsaf-handle: phandle, specifies a reference to a node
+representing a dsaf device.
+- #address-cells: must be 2
+- #size-cells: must be 2
+Optional properties:
+- dma-coherent: Present if DMA operations are coherent.
+- interrupt-parent: the interrupt parent of this device.
+- interrupts: should contain 32 completion event irq,1 async event irq
+and 1 event overflow irq.
+- interrupt-names:should be one of 34 irqs for roce device
+ - roce_ce0_irq ~ roce_ce31_irq: 32 complete event irq
+ - roce_ae_irq: 1 async event irq
+ - roce_common_irq: named common exception warning irq
+Example:
+ infiniband@c400 {
+ compatible = "hisilicon,hns-roce-v1";
+ reg = <0x0 0xc400 0x0 0x10>;
+ dma-coherent;
+ eth-handle = <ð2 ð3 ð4 ð5 ð6 ð7>;
+ dsaf-handle = <&soc0_dsa>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mbigen_dsa>;
+ interrupts = <722 1>,
+ <723 1>,
+ <724 1>,
+ <725 1>,
+ <726 1>,
+ <727 1>,
+ <728 1>,
+ <729 1>,
+ <730 1>,
+ <731 1>,
+ <732 1>,
+ <733 1>,
+ <734 1>,
+ <735 1>,
+ <736 1>,
+ <737 1>,
+ <738 1>,
+ <739 1>,
+ <740 1>,
+ <741 1>,
+ <742 1>,
+ <743 1>,
+ <744 1>,
+ <745 1>,
+ <746 1>,
+ <747 1>,
+ <748 1>,
+ <749 1>,
+ <750 1>,
+ <751 1>,
+ <752 1>,
+ <753 1>,
+ <785 1>,
+ <754 4>;
+
+ interrupt-names = "roce_ce0_irq",
+ "roce_ce1_irq",
+ "roce_ce2_irq",
+ "roce_ce3_irq",
+ "roce_ce4_irq",
+ "roce_ce5_irq",
+ "roce_ce6_irq",
+ "roce_ce7_irq",
+ "roce_ce8_irq",
+ "roce_ce9_irq",
+ "roce_ce10_irq",
+ "roce_ce11_irq",
+ "roce_ce12_irq",
+ "roce_ce13_irq",
+ "roce_ce14_irq",
+ "roce_ce15_irq",
+ "roce_ce16_irq",
+ "roce_ce17_irq",
+ "roce_ce18_irq",
+ "roce_ce19_irq",
+ "roc
[PATCH net-next] vxlan: fix too large pskb_may_pull with remote checksum
The vxlan header is pulled at this point, don't include it again in the
calculation.
Signed-off-by: Jiri Benc
---
This was previously part of the VXLAN-GPE patchset but it's not really
related (especially not after the discussion that RCO should not be allowed
together with GPE). I'm sending it separately.
---
drivers/net/vxlan.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 800106a7246c..1eb8347f440c 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1143,7 +1143,7 @@ static int vxlan_igmp_leave(struct vxlan_dev *vxlan)
static bool vxlan_remcsum(struct vxlanhdr *unparsed,
struct sk_buff *skb, u32 vxflags)
{
- size_t start, offset, plen;
+ size_t start, offset;
if (!(unparsed->vx_flags & VXLAN_HF_RCO) || skb->remcsum_offload)
goto out;
@@ -1151,9 +1151,7 @@ static bool vxlan_remcsum(struct vxlanhdr *unparsed,
start = vxlan_rco_start(unparsed->vx_vni);
offset = start + vxlan_rco_offset(unparsed->vx_vni);
- plen = sizeof(struct vxlanhdr) + offset + sizeof(u16);
-
- if (!pskb_may_pull(skb, plen))
+ if (!pskb_may_pull(skb, offset + sizeof(u16)))
return false;
skb_remcsum_process(skb, (void *)(vxlan_hdr(skb) + 1), start, offset,
--
1.8.3.1
[PATCH net-next v2 3/4] ip_tunnel: implement __iptunnel_pull_header
Allow calling of iptunnel_pull_header without special casing ETH_P_TEB inner
protocol.
Signed-off-by: Jiri Benc
---
New in v2.
---
include/net/ip_tunnels.h | 11 +--
net/ipv4/ip_tunnel_core.c | 8
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 5dc2e454f866..e9056dab1eb0 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -288,8 +288,15 @@ static inline u8 ip_tunnel_ecn_encap(u8 tos, const struct
iphdr *iph,
return INET_ECN_encapsulate(tos, inner);
}
-int iptunnel_pull_header(struct sk_buff *skb, int hdr_len, __be16 inner_proto,
-bool xnet);
+int __iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
+ __be16 inner_proto, bool raw_proto, bool xnet);
+
+static inline int iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
+ __be16 inner_proto, bool xnet)
+{
+ return __iptunnel_pull_header(skb, hdr_len, inner_proto, false, xnet);
+}
+
void iptunnel_xmit(struct sock *sk, struct rtable *rt, struct sk_buff *skb,
__be32 src, __be32 dst, u8 proto,
u8 tos, u8 ttl, __be16 df, bool xnet);
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index eaca2449a09a..ccff5682cd38 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -86,15 +86,15 @@ void iptunnel_xmit(struct sock *sk, struct rtable *rt,
struct sk_buff *skb,
}
EXPORT_SYMBOL_GPL(iptunnel_xmit);
-int iptunnel_pull_header(struct sk_buff *skb, int hdr_len, __be16 inner_proto,
-bool xnet)
+int __iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
+ __be16 inner_proto, bool raw_proto, bool xnet)
{
if (unlikely(!pskb_may_pull(skb, hdr_len)))
return -ENOMEM;
skb_pull_rcsum(skb, hdr_len);
- if (inner_proto == htons(ETH_P_TEB)) {
+ if (!raw_proto && inner_proto == htons(ETH_P_TEB)) {
struct ethhdr *eh;
if (unlikely(!pskb_may_pull(skb, ETH_HLEN)))
@@ -116,7 +116,7 @@ int iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
__be16 inner_proto,
skb_scrub_packet(skb, xnet);
return 0;
}
-EXPORT_SYMBOL_GPL(iptunnel_pull_header);
+EXPORT_SYMBOL_GPL(__iptunnel_pull_header);
struct metadata_dst *iptunnel_metadata_reply(struct metadata_dst *md,
gfp_t flags)
--
1.8.3.1
Re: [PATCH] net: consolidate lock/unlock into unlock_wait
From: Nicholas Mc Guire Date: Fri, 18 Mar 2016 10:32:05 +0100 > The spin_lock()/spin_unlock() is synchronizing on the adapter->work_lock > as the comment also suggests, which is equivalent to spin_unlock_wait() > but the later should be more efficient. > > Signed-off-by: Nicholas Mc Guire There really is no justification for this change. This is an optimization in a slow-path of the driver. The device is a rarely used older piece of hardware. The amount of testers of this driver is probably approximating zero. So there is only risk of breakage from this change, and absolutely zero upside. Therefore, I'm not applying this patch, and I'd kindly like to ask you to please consider such issues in the future for these kinds of transformations. Thanks.
[patch net-next RFC 11/13] mlxsw: spectrum_buffers: Rename "pool" to "pr" in initialization
From: Jiri Pirko
Be consintent with rest of the registers (pm, cm) and use "pr" here.
Signed-off-by: Jiri Pirko
---
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 70 +++---
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
index 820a19c0..41212c0 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_buffers.c
@@ -100,78 +100,78 @@ static int mlxsw_sp_port_pb_init(struct mlxsw_sp_port
*mlxsw_sp_port)
#define MLXSW_SP_SB_BYTES_PER_CELL 96
-struct mlxsw_sp_sb_pool {
+struct mlxsw_sp_sb_pr {
enum mlxsw_reg_sbpr_mode mode;
u32 size;
};
-#define MLXSW_SP_SB_POOL_INGRESS_SIZE \
+#define MLXSW_SP_SB_PR_INGRESS_SIZE\
((1500 - (2 * 2 * MLXSW_PORT_MAX_PORTS)) / \
MLXSW_SP_SB_BYTES_PER_CELL)
-#define MLXSW_SP_SB_POOL_EGRESS_SIZE \
+#define MLXSW_SP_SB_PR_EGRESS_SIZE \
((1400 - (8 * 1500 * MLXSW_PORT_MAX_PORTS)) / \
MLXSW_SP_SB_BYTES_PER_CELL)
-#define MLXSW_SP_SB_POOL(_mode, _size) \
+#define MLXSW_SP_SB_PR(_mode, _size) \
{ \
.mode = _mode, \
.size = _size, \
}
-static const struct mlxsw_sp_sb_pool mlxsw_sp_sb_pools_ingress[] = {
- MLXSW_SP_SB_POOL(MLXSW_REG_SBPR_MODE_DYNAMIC,
-MLXSW_SP_SB_POOL_INGRESS_SIZE),
- MLXSW_SP_SB_POOL(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
- MLXSW_SP_SB_POOL(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
- MLXSW_SP_SB_POOL(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
+static const struct mlxsw_sp_sb_pr mlxsw_sp_sb_prs_ingress[] = {
+ MLXSW_SP_SB_PR(MLXSW_REG_SBPR_MODE_DYNAMIC,
+ MLXSW_SP_SB_PR_INGRESS_SIZE),
+ MLXSW_SP_SB_PR(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
+ MLXSW_SP_SB_PR(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
+ MLXSW_SP_SB_PR(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
};
-#define MLXSW_SP_SB_POOLS_INGRESS_LEN ARRAY_SIZE(mlxsw_sp_sb_pools_ingress)
+#define MLXSW_SP_SB_PRS_INGRESS_LEN ARRAY_SIZE(mlxsw_sp_sb_prs_ingress)
-static const struct mlxsw_sp_sb_pool mlxsw_sp_sb_pools_egress[] = {
+static const struct mlxsw_sp_sb_pr mlxsw_sp_sb_prs_egress[] = {
- MLXSW_SP_SB_POOL(MLXSW_REG_SBPR_MODE_DYNAMIC,
-MLXSW_SP_SB_POOL_EGRESS_SIZE),
- MLXSW_SP_SB_POOL(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
- MLXSW_SP_SB_POOL(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
- MLXSW_SP_SB_POOL(MLXSW_REG_SBPR_MODE_DYNAMIC,
-MLXSW_SP_SB_POOL_EGRESS_SIZE),
+ MLXSW_SP_SB_PR(MLXSW_REG_SBPR_MODE_DYNAMIC,
+ MLXSW_SP_SB_PR_EGRESS_SIZE),
+ MLXSW_SP_SB_PR(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
+ MLXSW_SP_SB_PR(MLXSW_REG_SBPR_MODE_DYNAMIC, 0),
+ MLXSW_SP_SB_PR(MLXSW_REG_SBPR_MODE_DYNAMIC,
+ MLXSW_SP_SB_PR_EGRESS_SIZE),
};
-#define MLXSW_SP_SB_POOLS_EGRESS_LEN ARRAY_SIZE(mlxsw_sp_sb_pools_egress)
+#define MLXSW_SP_SB_PRS_EGRESS_LEN ARRAY_SIZE(mlxsw_sp_sb_prs_egress)
-static int __mlxsw_sp_sb_pools_init(struct mlxsw_sp *mlxsw_sp,
- enum mlxsw_reg_sbxx_dir dir,
- const struct mlxsw_sp_sb_pool *pools,
- size_t pools_len)
+static int __mlxsw_sp_sb_prs_init(struct mlxsw_sp *mlxsw_sp,
+ enum mlxsw_reg_sbxx_dir dir,
+ const struct mlxsw_sp_sb_pr *prs,
+ size_t prs_len)
{
int i;
int err;
- for (i = 0; i < pools_len; i++) {
- const struct mlxsw_sp_sb_pool *pool;
+ for (i = 0; i < prs_len; i++) {
+ const struct mlxsw_sp_sb_pr *pr;
- pool = &pools[i];
+ pr = &prs[i];
err = mlxsw_sp_sb_pr_write(mlxsw_sp, i, dir,
- pool->mode, pool->size);
+ pr->mode, pr->size);
if (err)
return err;
}
return 0;
}
-static int mlxsw_sp_sb_pools_init(struct mlxsw_sp *mlxsw_sp)
+static int mlxsw_sp_sb_prs_init(struct mlxsw_sp *mlxsw_sp)
{
int err;
- err = __mlxsw_sp_sb_pools_init(mlxsw_sp, MLXSW_REG_SBXX_DIR_INGRESS,
- mlxsw_sp_sb_pools_ingress,
- MLXSW_SP_SB_POOLS_INGRESS_LEN);
+ err = __mlxsw_sp_sb_prs_init(mlxsw_sp, MLXSW_REG_SBXX_DIR_INGRESS,
+mlxsw_sp_sb_prs_ingress,
+MLXSW_SP_SB_PRS_INGRESS_LEN);
if (err)
return err;
- return __mlxsw_sp_sb_pools_init(mlxs
[PATCH] net: phy: at803x: Add support to control PHY LEDs
The LEDs can be turned on and off by a sysfs interface
now. Write 0 to "led_enable" file to turn off the LEDs
and write 1 to turn on. The support is experimental
and can be enabled by kernel configuration option.
Signed-off-by: Vishal Thanki
---
drivers/net/phy/Kconfig | 7 +
drivers/net/phy/at803x.c | 71
2 files changed, 78 insertions(+)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 075a4cc..16f78cf 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -24,6 +24,13 @@ config AT803X_PHY
---help---
Currently supports the AT8030 and AT8035 model
+config AT803X_PHY_LED_CONTROL
+ depends on AT803X_PHY
+ bool "Support for PHY LED control (Experimental)"
+ ---help---
+ This option enables a sysfs interface to turn on and off the link
+ LEDs attached to phy.
+
config AMD_PHY
tristate "Drivers for the AMD PHYs"
---help---
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 1e901c7..a606d52 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -59,12 +59,19 @@
#define ATH8031_PHY_ID 0x004dd074
#define ATH8035_PHY_ID 0x004dd072
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+#define LED_OFF0xF71F
+#endif
+
MODULE_DESCRIPTION("Atheros 803x PHY driver");
MODULE_AUTHOR("Matus Ujhelyi");
MODULE_LICENSE("GPL");
struct at803x_priv {
bool phy_reset:1;
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+ int led_status;
+#endif
struct gpio_desc *gpiod_reset;
};
@@ -267,6 +274,42 @@ done:
return 0;
}
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+static ssize_t at803x_led_get(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+ int read = phy_read(phydev, AT803X_LED_CONTROL);
+
+ read = (read == LED_OFF) ? 0 : 1;
+ return sprintf(buf, "%x\n", read);
+}
+
+static ssize_t at803x_led_set(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+ struct at803x_priv *priv = phydev->priv;
+ int val;
+
+ if (!strncmp(buf, "0", 1)) {
+ priv->led_status = phy_read(phydev, AT803X_LED_CONTROL);
+ val = LED_OFF;
+ } else if (!strncmp(buf, "1", 1)) {
+ val = priv->led_status;
+ } else {
+ return -EINVAL;
+ }
+
+ phy_write(phydev, AT803X_LED_CONTROL, val);
+
+ return count;
+}
+
+static DEVICE_ATTR(led_enable, 0600, at803x_led_get, at803x_led_set);
+#endif
+
static int at803x_probe(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
@@ -285,12 +328,31 @@ static int at803x_probe(struct phy_device *phydev)
phydev->priv = priv;
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+ dev_set_drvdata(dev, phydev);
+ return device_create_file(dev, &dev_attr_led_enable);
+#else
return 0;
+#endif
+}
+
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+static void at803x_remove(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ device_remove_file(dev, &dev_attr_led_enable);
}
+#endif
static int at803x_config_init(struct phy_device *phydev)
{
int ret;
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+ struct at803x_priv *priv;
+
+ priv = phydev->priv;
+ priv->led_status = phy_read(phydev, AT803X_LED_CONTROL);
+#endif
ret = genphy_config_init(phydev);
if (ret < 0)
@@ -396,6 +458,9 @@ static struct phy_driver at803x_driver[] = {
.flags = PHY_HAS_INTERRUPT,
.config_aneg= genphy_config_aneg,
.read_status= genphy_read_status,
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+ .remove = at803x_remove,
+#endif
.ack_interrupt = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
}, {
@@ -414,6 +479,9 @@ static struct phy_driver at803x_driver[] = {
.flags = PHY_HAS_INTERRUPT,
.config_aneg= genphy_config_aneg,
.read_status= genphy_read_status,
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+ .remove = at803x_remove,
+#endif
.ack_interrupt = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
}, {
@@ -432,6 +500,9 @@ static struct phy_driver at803x_driver[] = {
.flags = PHY_HAS_INTERRUPT,
.config_aneg= genphy_config_aneg,
.read_status= genphy_read_status,
+#ifdef CONFIG_AT803X_PHY_LED_CONTROL
+ .remove = at803x_remove,
+#endif
.ack_interrupt = &at803x_ack_interrupt,
.config_intr= &at803x_config_int
[PATCH 2/3] tc: f_u32: trivial coding style cleanups
Signed-off-by: Luca Lemmo
---
tc/f_u32.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 2a6c971..5ca60c8 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -80,7 +80,7 @@ static int get_u32_handle(__u32 *handle, const char *str)
return 0;
}
-static char * sprint_u32_handle(__u32 handle, char *buf)
+static char *sprint_u32_handle(__u32 handle, char *buf)
{
int bsize = SPRINT_BSIZE-1;
__u32 htid = TC_U32_HTID(handle);
@@ -382,7 +382,7 @@ static int parse_ip6_addr(int *argc_p, char ***argv_p,
plen = addr.bitlen;
for (i = 0; i < plen; i += 32) {
-// if (((i + 31) & ~0x1F) <= plen) {
+ /* if (((i + 31) & ~0x1F) <= plen) { */
if (i + 31 <= plen) {
res = pack_key(sel, addr.data[i / 32],
0x, off + 4 * (i / 32), offmask);
@@ -1109,14 +1109,14 @@ static int u32_parse_opt(struct filter_util *qu, char
*handle,
continue;
} else if (strcmp(*argv, "indev") == 0) {
char ind[IFNAMSIZ + 1];
- memset(ind, 0, sizeof (ind));
+ memset(ind, 0, sizeof(ind));
argc--;
argv++;
if (argc < 1) {
fprintf(stderr, "Illegal indev\n");
return -1;
}
- strncpy(ind, *argv, sizeof (ind) - 1);
+ strncpy(ind, *argv, sizeof(ind) - 1);
addattr_l(n, MAX_MSG, TCA_U32_INDEV, ind, strlen(ind) +
1);
} else if (matches(*argv, "action") == 0) {
--
2.7.3
[PATCH net-next 3/6] bridge: simplify the stp_state_store by calling store_bridge_parm
There are some repetitive codes in stp_state_store, we can remove
them by calling store_bridge_parm.
Signed-off-by: Xin Long
---
net/bridge/br_sysfs_br.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index c846bf9..5d9fee2 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -128,27 +128,17 @@ static ssize_t stp_state_show(struct device *d,
}
+static int set_stp_state(struct net_bridge *br, unsigned long val)
+{
+ br_stp_set_enabled(br, val);
+ return 0;
+}
+
static ssize_t stp_state_store(struct device *d,
struct device_attribute *attr, const char *buf,
size_t len)
{
- struct net_bridge *br = to_bridge(d);
- char *endp;
- unsigned long val;
-
- if (!ns_capable(dev_net(br->dev)->user_ns, CAP_NET_ADMIN))
- return -EPERM;
-
- val = simple_strtoul(buf, &endp, 0);
- if (endp == buf)
- return -EINVAL;
-
- if (!rtnl_trylock())
- return restart_syscall();
- br_stp_set_enabled(br, val);
- rtnl_unlock();
-
- return len;
+ return store_bridge_parm(d, buf, len, set_stp_state);
}
static DEVICE_ATTR_RW(stp_state);
--
2.1.0
Re: [PATCH] sctp: keep fragmentation point aligned to word size
On Fri, Mar 18, 2016 at 06:39:17PM -0300, Marcelo Ricardo Leitner wrote: > If the user supply a different fragmentation point or if there is a > network header that cause it to not be aligned, force it to be aligned. > > Fragmentation point at a value that is not aligned is not optimal. It > causes extra padding to be used and has just no pros. > > Signed-off-by: Marcelo Ricardo Leitner > --- > include/net/sctp/sctp.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h > index > 835aa2ed987092634a4242314e9eabb51d1e4e35..f27d38113c7926783a9bf2863e14e963ed0ad5d6 > 100644 > --- a/include/net/sctp/sctp.h > +++ b/include/net/sctp/sctp.h > @@ -426,7 +426,7 @@ static inline int sctp_frag_point(const struct > sctp_association *asoc, int pmtu) > if (asoc->user_frag) > frag = min_t(int, frag, asoc->user_frag); > > - frag = min_t(int, frag, SCTP_MAX_CHUNK_LEN); > + frag = min_t(int, frag, SCTP_MAX_CHUNK_LEN) & ~3; Will submit a v2 with a helper for this & ~3 thing
Re: [PATCH] sh_eth: do not call netif_start_queue() from sh_eth_dev_init()
From: Sergei Shtylyov Date: Mon, 14 Mar 2016 01:09:53 +0300 > Iff sh_eth_phy_start() call fails in sh_eth_open(), the netif_start_queue() > call done by sh_eth_dev_init() is not undone. In order to deal with that, > stop calling netif_start_queue() from there, so that it can be called only > when the device is fully opened and sh_eth_dev_init() only deals with the > hardware initialization, symmetrically to sh_eth_dev_exit()... > > Signed-off-by: Sergei Shtylyov Applied.
