Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Sinan Kaya @ 2016-04-20 13:38 UTC (permalink / raw)
  To: eranlinuxmellanox-Re5JQEeQqe8AvxtiuMwx3w
  Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	timur-sgV2jX0FEOL9JmXXK+q4OQ, cov-sgV2jX0FEOL9JmXXK+q4OQ,
	Yishai Hadas, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <571785A5.5040306-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

Apologies,

Replied to an older post by mistake. I was trying to reply to Eran.

>Hi Sinan,
>
>We are working in Mellanox for a solution which
>removes the vmap call and allocate contiguous memory (using dma_alloc_coherent).
>
>Thanks,
>Eran
>
>
>On 4/20/2016 9:35 AM, Sinan Kaya wrote:
> On 4/19/2016 2:22 PM, Christoph Hellwig wrote:
>> What I think we need is something like the patch below.  In the long
>> ru nwe should also kill the mlx4_buf structure which now is pretty
>> pointless.
>>
> 

It is been 1.5 years since I reported the problem. We came up with three
different solutions this week. I'd like to see a version of the solution
to get merged until Mellanox comes up with a better solution with another
patch. My proposal is to use this one.

> 
> -- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
> @@ -588,7 +588,7 @@ int mlx4_buf_alloc(struct mlx4_dev *dev, int size, int max_direct,
>  {
>         dma_addr_t t;
> 
> -       if (size <= max_direct) {
> +       if ((size <= max_direct) || (BITS_PER_LONG == 64)){
>                 buf->nbufs        = 1;
>                 buf->npages       = 1;
>                 buf->page_shift   = get_order(size) + PAGE_SHIFT;
> 
> Of course, this is assuming that you are not ready to submit your patch yet. If you 
> are, feel free to post.
> 


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH V2] net: ethernet: mellanox: correct page conversion
From: Timur Tabi @ 2016-04-20 13:41 UTC (permalink / raw)
  To: Sinan Kaya, eranlinuxmellanox-Re5JQEeQqe8AvxtiuMwx3w
  Cc: Christoph Hellwig, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
	cov-sgV2jX0FEOL9JmXXK+q4OQ, Yishai Hadas,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <57178663.4050503-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

Sinan Kaya wrote:
> I'd like to see a version of the solution
> to get merged until Mellanox comes up with a better solution with another
> patch.

Yes, I agree 100%.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation collaborative project.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* RE: [Intel-wired-lan] [PATCH net-next V5 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
From: KY Srinivasan @ 2016-04-20 13:44 UTC (permalink / raw)
  To: Jeff Kirsher, davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
	olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com,
	eli@mellanox.com, jackm@mellanox.com, yevgenyp@mellanox.com,
	john.ronciak@intel.com, intel-wired-lan@lists.osuosl.org,
	alexander.duyck@gmail.com
In-Reply-To: <1461133482.2923.28.camel@intel.com>



> -----Original Message-----
> From: Jeff Kirsher [mailto:jeffrey.t.kirsher@intel.com]
> Sent: Tuesday, April 19, 2016 11:25 PM
> To: KY Srinivasan <kys@microsoft.com>; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> jasowang@redhat.com; eli@mellanox.com; jackm@mellanox.com;
> yevgenyp@mellanox.com; john.ronciak@intel.com; intel-wired-
> lan@lists.osuosl.org; alexander.duyck@gmail.com
> Subject: Re: [Intel-wired-lan] [PATCH net-next V5 2/2] intel: ixgbevf: Support
> Windows hosts (Hyper-V)
> 
> On Tue, 2016-04-19 at 19:17 -0700, K. Y. Srinivasan wrote:
> > On Hyper-V, the VF/PF communication is a via software mediated path
> > as opposed to the hardware mailbox. Make the necessary
> > adjustments to support Hyper-V.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> >         V2: Addressed most of the comments from
> >             Alexander Duyck <alexander.duyck@gmail.com>
> >             and Rustad, Mark D <mark.d.rustad@intel.com>.
> >
> >         V3: Addressed additional comments from
> >             Alexander Duyck <alexander.duyck@gmail.com>
> >
> >         V4: Addressed kbuild errors reported by:
> >             kbuild test robot <lkp@intel.com>
> >
> >         V5: Addressed additional comments from
> >             Alexander Duyck <alexander.duyck@gmail.com>
> 
> First I commend you on actually making a proper changelog for a patch.
>  The only issue I have is that the changelog provides not actual
> changes.  Saying you reacted to comments does not summarize what the
> actual changes were.  I purposely did not review the earlier versions
> because by the time I went to do a review, there was another version
> already submitted.  So your changelog requires that users look at all
> the previous emails to actually see what Alex and Mark requested in
> changes.
> 
> I am telling you this for future patches, it will not impact these
> patches, just really disappointing.  I will take the extra time to
> track down all the previous emails and the changes requested to ensure
> you made all the changes that were requested of you. :-(  This will
> just delay when I apply the patches for testing.

Thank you for taking the time. Here is a brief summary of all the changes (from
the initial version - ignoring cosmetic changes):

1. Changed the check for running on Hyper-V to be instruction set 
architecture independent. This is now based on device IDs (since we have
unique device IDs when running on Hyper-V).

2. Introduced a bunch of stub functions to eliminate a bunch of checks I initially
had in ixgbev_main.c. I now fully populate the mac operations many of the entry
points being stubs (ixgbevf_hv_mac_ops).

3. Added a check to ensure that we return appropriate error if  PCI_MMCONFIG
Is not defined - on Hyper-V we get the mac address by reading the PCI config space
at special offset.

4. Made the following functions standalone functions:
 ixgbevf_hv_rlpml_set_vf() and
ixgbevf_negotiate_api_version()
These are the Hyper-V variants. We now have the check at the call sites
in ixgbevf_main.c.

Hope this helps and again I am sorry for not including the summary.

Regards,

K. Y
> 
> >
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf.h      |   12 ++
> >  drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c |   31 +++-
> >  drivers/net/ethernet/intel/ixgbevf/mbx.c          |   12 ++
> >  drivers/net/ethernet/intel/ixgbevf/vf.c           |  216
> > +++++++++++++++++++++
> >  drivers/net/ethernet/intel/ixgbevf/vf.h           |    2 +
> >  5 files changed, 266 insertions(+), 7 deletions(-)

^ permalink raw reply

* [PATCH net-next] macvtap: add namespace support to the sysfs device class
From: Marc Angel @ 2016-04-20 14:11 UTC (permalink / raw)
  To: netdev; +Cc: ebiederm

When creating macvtaps that are expected to have the same ifindex
in different network namespaces, only the first one will succeed.
The others will fail with a sysfs_warn_dup warning due to them trying
to create the following sysfs link (with 'NN' the ifindex of macvtapX):

/sys/class/macvtap/tapNN -> /sys/devices/virtual/net/macvtapX/tapNN

This is reproducible by running the following commands:

ip netns add ns1
ip netns add ns2
ip link add veth0 type veth peer name veth1
ip link set veth0 netns ns1
ip link set veth1 netns ns2
ip netns exec ns1 ip l add link veth0 macvtap0 type macvtap
ip netns exec ns2 ip l add link veth1 macvtap1 type macvtap

The last command will fail with "RTNETLINK answers: File exists" (along
with the kernel warning) but retrying it will work because the ifindex
was incremented.

The 'net' device class is isolated between network namespaces so each
one has its own hierarchy of net devices.
This isn't the case for the 'macvtap' device class.
The problem occurs half-way through the netdev registration, when
`macvtap_device_event` is called-back to create the 'tapNN' macvtap
class device under the 'macvtapX' net class device.

This patch adds namespace support the the 'macvtap' device class so
that /sys/class/macvtap is no longer shared between net namespaces.

However, doing this has the side effect of changing
/sys/devices/virtual/net/macvtapX/tapNN  into
/sys/devices/virtual/net/macvtapX/macvtap/tapNN

This is due to Commit 24b1442 ("Driver-core: Always create class
directories for classses that support namespaces.")

Signed-off-by: Marc Angel <marc@arista.com>
---
I'm not sure that the problems described in that commit message
apply to macvtaps so maybe it is possible to keep the 'tapNN'
device directly under 'macvtapX' and not disrupt userland.

Should it even be possible to add a device of a class that doesn't
support namespaces under one that does?
This could lead to dead symlinks in the new device class directory or
duplicate warnings because a device of the same name already exists in
another namespace.
---
 drivers/net/macvtap.c | 27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 95394ed..a76d72d 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -129,7 +129,18 @@ static DEFINE_MUTEX(minor_lock);
 static DEFINE_IDR(minor_idr);
 
 #define GOODCOPY_LEN 128
-static struct class *macvtap_class;
+static const void *macvtap_net_namespace(struct device *d)
+{
+	struct net_device *dev = to_net_dev(d->parent);
+	return dev_net(dev);
+}
+
+static struct class macvtap_class = {
+	.name = "macvtap",
+	.owner = THIS_MODULE,
+	.ns_type = &net_ns_type_operations,
+	.namespace = macvtap_net_namespace,
+};
 static struct cdev macvtap_cdev;
 
 static const struct proto_ops macvtap_socket_ops;
@@ -1295,7 +1306,7 @@ static int macvtap_device_event(struct notifier_block *unused,
 			return notifier_from_errno(err);
 
 		devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
-		classdev = device_create(macvtap_class, &dev->dev, devt,
+		classdev = device_create(&macvtap_class, &dev->dev, devt,
 					 dev, "tap%d", dev->ifindex);
 		if (IS_ERR(classdev)) {
 			macvtap_free_minor(vlan);
@@ -1304,7 +1315,7 @@ static int macvtap_device_event(struct notifier_block *unused,
 		break;
 	case NETDEV_UNREGISTER:
 		devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
-		device_destroy(macvtap_class, devt);
+		device_destroy(&macvtap_class, devt);
 		macvtap_free_minor(vlan);
 		break;
 	}
@@ -1330,11 +1341,9 @@ static int macvtap_init(void)
 	if (err)
 		goto out2;
 
-	macvtap_class = class_create(THIS_MODULE, "macvtap");
-	if (IS_ERR(macvtap_class)) {
-		err = PTR_ERR(macvtap_class);
+	err = class_register(&macvtap_class);
+	if (err)
 		goto out3;
-	}
 
 	err = register_netdevice_notifier(&macvtap_notifier_block);
 	if (err)
@@ -1349,7 +1358,7 @@ static int macvtap_init(void)
 out5:
 	unregister_netdevice_notifier(&macvtap_notifier_block);
 out4:
-	class_unregister(macvtap_class);
+	class_unregister(&macvtap_class);
 out3:
 	cdev_del(&macvtap_cdev);
 out2:
@@ -1363,7 +1372,7 @@ static void macvtap_exit(void)
 {
 	rtnl_link_unregister(&macvtap_link_ops);
 	unregister_netdevice_notifier(&macvtap_notifier_block);
-	class_unregister(macvtap_class);
+	class_unregister(&macvtap_class);
 	cdev_del(&macvtap_cdev);
 	unregister_chrdev_region(macvtap_major, MACVTAP_NUM_DEVS);
 	idr_destroy(&minor_idr);
-- 
2.8.0

^ permalink raw reply related

* Re: [PATCH] MAINTAINERS: net: add entry for TI Ethernet Switch drivers
From: Tony Lindgren @ 2016-04-20 14:23 UTC (permalink / raw)
  To: Grygorii Strashko
  Cc: netdev, linux-kernel, Sekhar Nori, linux-omap, David S. Miller,
	Mugunthan V N, Richard Cochran
In-Reply-To: <1461151509-2368-1-git-send-email-grygorii.strashko@ti.com>

* Grygorii Strashko <grygorii.strashko@ti.com> [160420 04:26]:
> Add record for TI Ethernet Switch Driver CPSW/CPDMA/MDIO HW
> (am33/am43/am57/dr7/davinci) to ensure that related patches
> will go through dedicated linux-omap list.
> 
> Also add Mugunthan as maintainer and myself as the reviewer.
> 
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Mugunthan V N <mugunthanvnm@ti.com>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1d5b4be..aca864d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11071,6 +11071,14 @@ S:	Maintained
>  F:	drivers/clk/ti/
>  F:	include/linux/clk/ti.h
>  
> +TI ETHERNET SWITCH DRIVER (CPSW)
> +M:	Mugunthan V N <mugunthanvnm@ti.com>
> +R:	Grygorii Strashko <grygorii.strashko@ti.com>
> +L:	linux-omap@vger.kernel.org
> +S:	Maintained
> +F:	drivers/net/ethernet/ti/cpsw*
> +F:	drivers/net/ethernet/ti/davinci*
> +
>  TI FLASH MEDIA INTERFACE DRIVER
>  M:	Alex Dubov <oakad@yahoo.com>
>  S:	Maintained
> -- 

Please add netdev list also there as the primary list:

L:	netdev@vger.kernel.org
L:	linux-omap@vger.kernel.org

Then we can easily review and ack the patches for Dave to apply.

Regards,

Tony

^ permalink raw reply

* [PATCH net-next] net: fix HAVE_EFFICIENT_UNALIGNED_ACCESS typos
From: Eric Dumazet @ 2016-04-20 14:31 UTC (permalink / raw)
  To: nicolas.dichtel; +Cc: netdev, davem, roopa, tgraf, jhs
In-Reply-To: <1461146278.10638.253.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <edumazet@google.com>

HAVE_EFFICIENT_UNALIGNED_ACCESS needs CONFIG_ prefix.

Also add a comment in nla_align_64bit() explaining we have
to add a padding if current skb->data is aligned, as it
certainly can be confusing.

Fixes: 35c5845957c7 ("net: Add helpers for 64-bit aligning netlink attributes.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 include/net/netlink.h |   19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/include/net/netlink.h b/include/net/netlink.h
index e644b3489acf..cf95df1fa14b 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -1238,18 +1238,21 @@ static inline int nla_validate_nested(const struct nlattr *start, int maxtype,
  * Conditionally emit a padding netlink attribute in order to make
  * the next attribute we emit have a 64-bit aligned nla_data() area.
  * This will only be done in architectures which do not have
- * HAVE_EFFICIENT_UNALIGNED_ACCESS defined.
+ * CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS defined.
  *
  * Returns zero on success or a negative error code.
  */
 static inline int nla_align_64bit(struct sk_buff *skb, int padattr)
 {
-#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
-	if (IS_ALIGNED((unsigned long)skb->data, 8)) {
-		struct nlattr *attr = nla_reserve(skb, padattr, 0);
-		if (!attr)
-			return -EMSGSIZE;
-	}
+#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+	/* The nlattr header is 4 bytes in size, that's why we test
+	 * if the skb->data _is_ aligned.  This NOP attribute, plus
+	 * nlattr header for next attribute, will make nla_data()
+	 * 8-byte aligned.
+	 */
+	if (IS_ALIGNED((unsigned long)skb->data, 8) &&
+	    !nla_reserve(skb, padattr, 0))
+		return -EMSGSIZE;
 #endif
 	return 0;
 }
@@ -1261,7 +1264,7 @@ static inline int nla_align_64bit(struct sk_buff *skb, int padattr)
 static inline int nla_total_size_64bit(int payload)
 {
 	return NLA_ALIGN(nla_attr_size(payload))
-#ifndef HAVE_EFFICIENT_UNALIGNED_ACCESS
+#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
 		+ NLA_ALIGN(nla_attr_size(0))
 #endif
 		;

^ permalink raw reply related

* Re: [PATCH net-next] net: dsa: remove tag_protocol from dsa_switch
From: Andrew Lunn @ 2016-04-20 14:39 UTC (permalink / raw)
  To: Vivien Didelot
  Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <1461018244-5371-1-git-send-email-vivien.didelot@savoirfairelinux.com>

On Mon, Apr 18, 2016 at 06:24:04PM -0400, Vivien Didelot wrote:
> Having the tag protocol in dsa_switch_driver for setup time and in
> dsa_switch_tree for runtime is enough. Remove dsa_switch's one.
> 
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>

I had to think about this one for a minute. At the moment it is good,
however, sometime in the future, we might want to revert it. Some
Marvell switches support two tagging schemes. At the moment, we have
no way to express that, so the switch driver only offers one. If we
were to extend the API to express a list of supported tagging schemes,
we would then want dsa_switch to contain the scheme actually chosen.
However, until we actually implement something like this, lets remove
it.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

	     Andrew

> ---
>  include/net/dsa.h | 5 -----
>  net/dsa/dsa.c     | 5 ++---
>  2 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index c4bc42b..2d280ab 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -136,11 +136,6 @@ struct dsa_switch {
>  	void *priv;
>  
>  	/*
> -	 * Tagging protocol understood by this switch
> -	 */
> -	enum dsa_tag_protocol	tag_protocol;
> -
> -	/*
>  	 * Configuration data for this switch.
>  	 */
>  	struct dsa_chip_data	*pd;
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index efa612f..d61ceed 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -267,7 +267,7 @@ static int dsa_switch_setup_one(struct dsa_switch *ds, struct device *parent)
>  	 * switch.
>  	 */
>  	if (dst->cpu_switch == index) {
> -		switch (ds->tag_protocol) {
> +		switch (drv->tag_protocol) {
>  #ifdef CONFIG_NET_DSA_TAG_DSA
>  		case DSA_TAG_PROTO_DSA:
>  			dst->rcv = dsa_netdev_ops.rcv;
> @@ -295,7 +295,7 @@ static int dsa_switch_setup_one(struct dsa_switch *ds, struct device *parent)
>  			goto out;
>  		}
>  
> -		dst->tag_protocol = ds->tag_protocol;
> +		dst->tag_protocol = drv->tag_protocol;
>  	}
>  
>  	/*
> @@ -411,7 +411,6 @@ dsa_switch_setup(struct dsa_switch_tree *dst, int index,
>  	ds->pd = pd;
>  	ds->drv = drv;
>  	ds->priv = priv;
> -	ds->tag_protocol = drv->tag_protocol;
>  	ds->master_dev = host_dev;
>  
>  	ret = dsa_switch_setup_one(ds, parent);
> -- 
> 2.8.0
> 

^ permalink raw reply

* [PATCH 0/1] Revert "Prevent NUll pointer dereference with two PHYs"
From: Andrew Goodbody @ 2016-04-20 14:42 UTC (permalink / raw)
  To: netdev
  Cc: linux-kernel, linux-omap, mugunthanvnm, grygorii.strashko, tony,
	davem, Andrew Goodbody

Revert this patch as not only did it use an unitialised member of a struct
but there is also a pre-existing patch that does it better.

Andrew Goodbody (1):
  Revert "Prevent NUll pointer dereference with two PHYs on cpsw"

 drivers/net/ethernet/ti/cpsw.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

-- 
2.5.0

^ permalink raw reply

* [PATCH 1/1] Revert "Prevent NUll pointer dereference with two PHYs on cpsw"
From: Andrew Goodbody @ 2016-04-20 14:42 UTC (permalink / raw)
  To: netdev
  Cc: linux-kernel, linux-omap, mugunthanvnm, grygorii.strashko, tony,
	davem, Andrew Goodbody
In-Reply-To: <1461163349-24696-1-git-send-email-andrew.goodbody@cambrionix.com>

This reverts commit cfe255600154f0072d4a8695590dbd194dfd1aeb

This can result in a "Unable to handle kernel paging request"
during boot. This was due to using an uninitialised struct member,
data->slaves.
---
 drivers/net/ethernet/ti/cpsw.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 2cd67a5..54bcc38 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -349,7 +349,6 @@ struct cpsw_slave {
 	struct cpsw_slave_data		*data;
 	struct phy_device		*phy;
 	struct net_device		*ndev;
-	struct device_node		*phy_node;
 	u32				port_vlan;
 	u32				open_stat;
 };
@@ -368,6 +367,7 @@ struct cpsw_priv {
 	spinlock_t			lock;
 	struct platform_device		*pdev;
 	struct net_device		*ndev;
+	struct device_node		*phy_node;
 	struct napi_struct		napi_rx;
 	struct napi_struct		napi_tx;
 	struct device			*dev;
@@ -1142,8 +1142,8 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
 		cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
 				   1 << slave_port, 0, 0, ALE_MCAST_FWD_2);
 
-	if (slave->phy_node)
-		slave->phy = of_phy_connect(priv->ndev, slave->phy_node,
+	if (priv->phy_node)
+		slave->phy = of_phy_connect(priv->ndev, priv->phy_node,
 				 &cpsw_adjust_link, 0, slave->data->phy_if);
 	else
 		slave->phy = phy_connect(priv->ndev, slave->data->phy_id,
@@ -2025,8 +2025,7 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
 		if (strcmp(slave_node->name, "slave"))
 			continue;
 
-		priv->slaves[i].phy_node =
-			of_parse_phandle(slave_node, "phy-handle", 0);
+		priv->phy_node = of_parse_phandle(slave_node, "phy-handle", 0);
 		parp = of_get_property(slave_node, "phy_id", &lenp);
 		if (of_phy_is_fixed_link(slave_node)) {
 			struct device_node *phy_node;
@@ -2267,22 +2266,12 @@ static int cpsw_probe(struct platform_device *pdev)
 	/* Select default pin state */
 	pinctrl_pm_select_default_state(&pdev->dev);
 
-	data = &priv->data;
-	priv->slaves = devm_kzalloc(&pdev->dev,
-				    sizeof(struct cpsw_slave) * data->slaves,
-				    GFP_KERNEL);
-	if (!priv->slaves) {
-		ret = -ENOMEM;
-		goto clean_runtime_disable_ret;
-	}
-	for (i = 0; i < data->slaves; i++)
-		priv->slaves[i].slave_num = i;
-
 	if (cpsw_probe_dt(priv, pdev)) {
 		dev_err(&pdev->dev, "cpsw: platform data missing\n");
 		ret = -ENODEV;
 		goto clean_runtime_disable_ret;
 	}
+	data = &priv->data;
 
 	if (is_valid_ether_addr(data->slave_data[0].mac_addr)) {
 		memcpy(priv->mac_addr, data->slave_data[0].mac_addr, ETH_ALEN);
@@ -2294,6 +2283,16 @@ static int cpsw_probe(struct platform_device *pdev)
 
 	memcpy(ndev->dev_addr, priv->mac_addr, ETH_ALEN);
 
+	priv->slaves = devm_kzalloc(&pdev->dev,
+				    sizeof(struct cpsw_slave) * data->slaves,
+				    GFP_KERNEL);
+	if (!priv->slaves) {
+		ret = -ENOMEM;
+		goto clean_runtime_disable_ret;
+	}
+	for (i = 0; i < data->slaves; i++)
+		priv->slaves[i].slave_num = i;
+
 	priv->slaves[0].ndev = ndev;
 	priv->emac_port = 0;
 
-- 
2.5.0

^ permalink raw reply related

* [net-next PATCH v2 0/3] Feature tweaks/fixes follow-up to GSO partial patches
From: Alexander Duyck @ 2016-04-20 14:49 UTC (permalink / raw)
  To: netdev, davem, alexander.duyck

This patch series is a set of minor fix-ups and tweaks following the GSO
partial and TSO with IPv4 ID mangling patches.  It mostly is just meant to
make certain that if we have GSO partial support at the device we can make
use of it from the far end of the tunnel.

v2: Added cover page which was forgotten with first submission.
    Added patch that enables TSOv4 IP ID mangling w/ tunnels and/or VLANs.

---

Alexander Duyck (3):
      netdev_features: Fold NETIF_F_ALL_TSO into NETIF_F_GSO_SOFTWARE
      veth: Update features to include all tunnel GSO types
      net: Add support for IP ID mangling TSO in cases that require encapsulation


 drivers/net/veth.c              |    7 +++----
 include/linux/netdev_features.h |    8 +++-----
 net/core/dev.c                  |   11 +++++++++++
 3 files changed, 17 insertions(+), 9 deletions(-)

^ permalink raw reply

* [net-next PATCH v2 1/3] netdev_features: Fold NETIF_F_ALL_TSO into NETIF_F_GSO_SOFTWARE
From: Alexander Duyck @ 2016-04-20 14:49 UTC (permalink / raw)
  To: netdev, davem, alexander.duyck
In-Reply-To: <20160420144720.3100.74116.stgit@ahduyck-xeon-server>

This patch folds NETIF_F_ALL_TSO into the bitmask for NETIF_F_GSO_SOFTWARE.
The idea is to avoid duplication of defines since the only difference
between the two was the GSO_UDP bit.

Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
 include/linux/netdev_features.h |    8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 15eb0b12fff9..bc8736266749 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -152,11 +152,6 @@ enum {
 #define NETIF_F_GSO_MASK	(__NETIF_F_BIT(NETIF_F_GSO_LAST + 1) - \
 		__NETIF_F_BIT(NETIF_F_GSO_SHIFT))
 
-/* List of features with software fallbacks. */
-#define NETIF_F_GSO_SOFTWARE	(NETIF_F_TSO | NETIF_F_TSO_ECN | \
-				 NETIF_F_TSO_MANGLEID | \
-				 NETIF_F_TSO6 | NETIF_F_UFO)
-
 /* List of IP checksum features. Note that NETIF_F_ HW_CSUM should not be
  * set in features when NETIF_F_IP_CSUM or NETIF_F_IPV6_CSUM are set--
  * this would be contradictory
@@ -170,6 +165,9 @@ enum {
 #define NETIF_F_ALL_FCOE	(NETIF_F_FCOE_CRC | NETIF_F_FCOE_MTU | \
 				 NETIF_F_FSO)
 
+/* List of features with software fallbacks. */
+#define NETIF_F_GSO_SOFTWARE	(NETIF_F_ALL_TSO | NETIF_F_UFO)
+
 /*
  * If one device supports one of these features, then enable them
  * for all in netdev_increment_features.

^ permalink raw reply related

* [net-next PATCH v2 2/3] veth: Update features to include all tunnel GSO types
From: Alexander Duyck @ 2016-04-20 14:49 UTC (permalink / raw)
  To: netdev, davem, alexander.duyck
In-Reply-To: <20160420144720.3100.74116.stgit@ahduyck-xeon-server>

This patch adds support for the checksum enabled versions of UDP and GRE
tunnels.  With this change we should be able to send and receive GSO frames
of these types over the veth pair without needing to segment the packets.

Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
 drivers/net/veth.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 4f30a6ae50d0..f37a6e61d4ad 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -312,10 +312,9 @@ static const struct net_device_ops veth_netdev_ops = {
 	.ndo_set_rx_headroom	= veth_set_rx_headroom,
 };
 
-#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_ALL_TSO |    \
-		       NETIF_F_HW_CSUM | NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
-		       NETIF_F_GSO_GRE | NETIF_F_GSO_UDP_TUNNEL |	    \
-		       NETIF_F_GSO_IPIP | NETIF_F_GSO_SIT | NETIF_F_UFO	|   \
+#define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HW_CSUM | \
+		       NETIF_F_RXCSUM | NETIF_F_HIGHDMA | \
+		       NETIF_F_GSO_SOFTWARE | NETIF_F_GSO_ENCAP_ALL | \
 		       NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX | \
 		       NETIF_F_HW_VLAN_STAG_TX | NETIF_F_HW_VLAN_STAG_RX )
 

^ permalink raw reply related

* [net-next PATCH v2 3/3] net: Add support for IP ID mangling TSO in cases that require encapsulation
From: Alexander Duyck @ 2016-04-20 14:49 UTC (permalink / raw)
  To: netdev, davem, alexander.duyck
In-Reply-To: <20160420144720.3100.74116.stgit@ahduyck-xeon-server>

This patch adds support for NETIF_F_TSO_MANGLEID if a given tunnel supports
NETIF_F_TSO.  This way if needed a device can then later enable the TSO
with IP ID mangling and the tunnels on top of that device can then also
make use of the IP ID mangling as well.

Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
 net/core/dev.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index 52d446b2cb99..6324bc9267f7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7029,8 +7029,19 @@ int register_netdevice(struct net_device *dev)
 	if (!(dev->flags & IFF_LOOPBACK))
 		dev->hw_features |= NETIF_F_NOCACHE_COPY;
 
+	/* If IPv4 TCP segmentation offload is supported we should also
+	 * allow the device to enable segmenting the frame with the option
+	 * of ignoring a static IP ID value.  This doesn't enable the
+	 * feature itself but allows the user to enable it later.
+	 */
 	if (dev->hw_features & NETIF_F_TSO)
 		dev->hw_features |= NETIF_F_TSO_MANGLEID;
+	if (dev->vlan_features & NETIF_F_TSO)
+		dev->vlan_features |= NETIF_F_TSO_MANGLEID;
+	if (dev->mpls_features & NETIF_F_TSO)
+		dev->mpls_features |= NETIF_F_TSO_MANGLEID;
+	if (dev->hw_enc_features & NETIF_F_TSO)
+		dev->hw_enc_features |= NETIF_F_TSO_MANGLEID;
 
 	/* Make NETIF_F_HIGHDMA inheritable to VLAN devices.
 	 */

^ permalink raw reply related

* Re: [PATCH net-next] net/hsr: Fixed version field in ENUM
From: David Miller @ 2016-04-20 14:51 UTC (permalink / raw)
  To: mail; +Cc: netdev, stephen, peter.heise
In-Reply-To: <20160420070829.GA24563@aircraft-controller>

From: Peter Heise <mail@pheise.de>
Date: Wed, 20 Apr 2016 09:08:29 +0200

> New field (IFLA_HSR_VERSION) was added in the middle of an existing
> ENUM and would break kernel ABI, therefore moved to the end.
> Reported by Stephen Hemminger.
> 
> Signed-off-by: Peter Heise <peter.heise@airbus.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH v2 0/1] drivers: net: cpsw: Fix NULL pointer dereference with two slave PHYs
From: David Miller @ 2016-04-20 14:56 UTC (permalink / raw)
  To: andrew.goodbody
  Cc: netdev, linux-kernel, drivshin.allworx, grygorii.strashko,
	mugunthanvnm, linux-omap, tony
In-Reply-To: <c10cbc575f4d4e15bd27a8018f77baf1@THHSTE15D2BE2.hs20.net>

From: Andrew Goodbody <andrew.goodbody@cambrionix.com>
Date: Wed, 20 Apr 2016 08:49:34 +0000

> Sorry, I had no notification that this had happened. However I
> thought that the plan was to revert v1 and go with David Rivshin's
> patch instead. I'll see if I can create a revert in a little while.

Yes, that's  fine.

^ permalink raw reply

* Re: [PATCH net 4/4] net/mlx4_en: Split SW RX dropped counter per RX ring
From: Eric Dumazet @ 2016-04-20 14:56 UTC (permalink / raw)
  To: Or Gerlitz
  Cc: David S. Miller, netdev, Eran Ben Elisha, Yishai Hadas,
	Saeed Mahameed
In-Reply-To: <1461157278-18528-5-git-send-email-ogerlitz@mellanox.com>

On Wed, 2016-04-20 at 16:01 +0300, Or Gerlitz wrote:
> From: Eran Ben Elisha <eranbe@mellanox.com>
> 
> Count SW packet drops per RX ring instead of a global counter. This
> will allow monitoring the number of rx drops per ring.
> 
> In addition, SW rx_dropped counter was overwritten by HW rx_dropped
> counter, sum both of them instead to show the accurate value.
> 
> Fixes: a3333b35da16 ('net/mlx4_en: Moderate ethtool callback to [...] ')
> Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
> Reported-by: Brenden Blanco <bblanco@plumgrid.com>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---

Reported-by: Eric Dumazet <edumazet@google.com>

( http://www.spinics.net/lists/netdev/msg371318.html )

Thanks for following up !

^ permalink raw reply

* Regression in next for smsc911x with tigthen lockdep checks
From: Tony Lindgren @ 2016-04-20 15:01 UTC (permalink / raw)
  To: Hannes Frederic Sowa, David S. Miller
  Cc: netdev, linux-arm-kernel, linux-omap

Hi,

Looks like commit fafc4e1ea1a4 ("sock: tigthen lockdep checks for
sock_owned_by_user") in next causes a regression at least for
smsc911x with CONFIG_LOCKDEP. It keeps spamming with the following
message. Any ideas?

Regards,

Tony

8< ----------------
WARNING: CPU: 0 PID: 0 at include/net/sock.h:1408 udp_queue_rcv_skb+0x398/0x640
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc4-next-20160420 #1087
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[<c01103c8>] (unwind_backtrace) from [<c010c400>] (show_stack+0x10/0x14)
[<c010c400>] (show_stack) from [<c04813ec>] (dump_stack+0xb0/0xe4)
[<c04813ec>] (dump_stack) from [<c0137afc>] (__warn+0xd8/0x104)
[<c0137afc>] (__warn) from [<c0137bd8>] (warn_slowpath_null+0x20/0x28)
[<c0137bd8>] (warn_slowpath_null) from [<c06d5310>] (udp_queue_rcv_skb+0x398/0x640)
[<c06d5310>] (udp_queue_rcv_skb) from [<c06d5a84>] (__udp4_lib_rcv+0x4cc/0xc0c)
[<c06d5a84>] (__udp4_lib_rcv) from [<c069e980>] (ip_local_deliver_finish+0xcc/0x4f4)
[<c069e980>] (ip_local_deliver_finish) from [<c069f748>] (ip_local_deliver+0xcc/0xd8)
[<c069f748>] (ip_local_deliver) from [<c069ee64>] (ip_rcv_finish+0xbc/0x700)
[<c069ee64>] (ip_rcv_finish) from [<c069fbe0>] (ip_rcv+0x48c/0x6d4)
[<c069fbe0>] (ip_rcv) from [<c0662790>] (__netif_receive_skb_core+0x380/0xa10)
[<c0662790>] (__netif_receive_skb_core) from [<c0665138>] (netif_receive_skb_internal+
0x74/0x1ec)
[<c0665138>] (netif_receive_skb_internal) from [<c05da394>] (smsc911x_poll+0xd8/0x228)
[<c05da394>] (smsc911x_poll) from [<c0665cd0>] (net_rx_action+0x124/0x470)
[<c0665cd0>] (net_rx_action) from [<c013e114>] (__do_softirq+0xc8/0x54c)
[<c013e114>] (__do_softirq) from [<c013e8b8>] (irq_exit+0xbc/0x130)
[<c013e8b8>] (irq_exit) from [<c019c8c8>] (__handle_domain_irq+0x6c/0xdc)
[<c019c8c8>] (__handle_domain_irq) from [<c07af2b8>] (__irq_svc+0x58/0x78)
[<c07af2b8>] (__irq_svc) from [<c0603884>] (cpuidle_enter_state+0xc4/0x3d4)
[<c0603884>] (cpuidle_enter_state) from [<c0183be0>] (cpu_startup_entry+0x198/0x3a0)
[<c0183be0>] (cpu_startup_entry) from [<c0b00c08>] (start_kernel+0x350/0x3c8)
[<c0b00c08>] (start_kernel) from [<8000807c>] (0x8000807c)

^ permalink raw reply

* Re: Regression in next for smsc911x with tigthen lockdep checks
From: Tony Lindgren @ 2016-04-20 15:02 UTC (permalink / raw)
  To: Hannes Frederic Sowa, David S. Miller
  Cc: netdev, linux-arm-kernel, linux-omap, Steve Glendinning
In-Reply-To: <20160420150108.GF5995@atomide.com>

* Tony Lindgren <tony@atomide.com> [160420 08:02]:
> Hi,
> 
> Looks like commit fafc4e1ea1a4 ("sock: tigthen lockdep checks for
> sock_owned_by_user") in next causes a regression at least for
> smsc911x with CONFIG_LOCKDEP. It keeps spamming with the following
> message. Any ideas?

Sorry forgot to add Steve to Cc, added now.

> Regards,
> 
> Tony
> 
> 8< ----------------
> WARNING: CPU: 0 PID: 0 at include/net/sock.h:1408 udp_queue_rcv_skb+0x398/0x640
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc4-next-20160420 #1087
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [<c01103c8>] (unwind_backtrace) from [<c010c400>] (show_stack+0x10/0x14)
> [<c010c400>] (show_stack) from [<c04813ec>] (dump_stack+0xb0/0xe4)
> [<c04813ec>] (dump_stack) from [<c0137afc>] (__warn+0xd8/0x104)
> [<c0137afc>] (__warn) from [<c0137bd8>] (warn_slowpath_null+0x20/0x28)
> [<c0137bd8>] (warn_slowpath_null) from [<c06d5310>] (udp_queue_rcv_skb+0x398/0x640)
> [<c06d5310>] (udp_queue_rcv_skb) from [<c06d5a84>] (__udp4_lib_rcv+0x4cc/0xc0c)
> [<c06d5a84>] (__udp4_lib_rcv) from [<c069e980>] (ip_local_deliver_finish+0xcc/0x4f4)
> [<c069e980>] (ip_local_deliver_finish) from [<c069f748>] (ip_local_deliver+0xcc/0xd8)
> [<c069f748>] (ip_local_deliver) from [<c069ee64>] (ip_rcv_finish+0xbc/0x700)
> [<c069ee64>] (ip_rcv_finish) from [<c069fbe0>] (ip_rcv+0x48c/0x6d4)
> [<c069fbe0>] (ip_rcv) from [<c0662790>] (__netif_receive_skb_core+0x380/0xa10)
> [<c0662790>] (__netif_receive_skb_core) from [<c0665138>] (netif_receive_skb_internal+
> 0x74/0x1ec)
> [<c0665138>] (netif_receive_skb_internal) from [<c05da394>] (smsc911x_poll+0xd8/0x228)
> [<c05da394>] (smsc911x_poll) from [<c0665cd0>] (net_rx_action+0x124/0x470)
> [<c0665cd0>] (net_rx_action) from [<c013e114>] (__do_softirq+0xc8/0x54c)
> [<c013e114>] (__do_softirq) from [<c013e8b8>] (irq_exit+0xbc/0x130)
> [<c013e8b8>] (irq_exit) from [<c019c8c8>] (__handle_domain_irq+0x6c/0xdc)
> [<c019c8c8>] (__handle_domain_irq) from [<c07af2b8>] (__irq_svc+0x58/0x78)
> [<c07af2b8>] (__irq_svc) from [<c0603884>] (cpuidle_enter_state+0xc4/0x3d4)
> [<c0603884>] (cpuidle_enter_state) from [<c0183be0>] (cpu_startup_entry+0x198/0x3a0)
> [<c0183be0>] (cpu_startup_entry) from [<c0b00c08>] (start_kernel+0x350/0x3c8)
> [<c0b00c08>] (start_kernel) from [<8000807c>] (0x8000807c)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH net-next] net: fix HAVE_EFFICIENT_UNALIGNED_ACCESS typos
From: David Miller @ 2016-04-20 15:03 UTC (permalink / raw)
  To: eric.dumazet; +Cc: nicolas.dichtel, netdev, roopa, tgraf, jhs
In-Reply-To: <1461162691.10638.260.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 20 Apr 2016 07:31:31 -0700

> From: Eric Dumazet <edumazet@google.com>
> 
> HAVE_EFFICIENT_UNALIGNED_ACCESS needs CONFIG_ prefix.
> 
> Also add a comment in nla_align_64bit() explaining we have
> to add a padding if current skb->data is aligned, as it
> certainly can be confusing.
> 
> Fixes: 35c5845957c7 ("net: Add helpers for 64-bit aligning netlink attributes.")
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH 1/1] Revert "Prevent NUll pointer dereference with two PHYs on cpsw"
From: Tony Lindgren @ 2016-04-20 15:05 UTC (permalink / raw)
  To: Andrew Goodbody
  Cc: netdev, linux-kernel, linux-omap, mugunthanvnm, grygorii.strashko,
	davem
In-Reply-To: <1461163349-24696-2-git-send-email-andrew.goodbody@cambrionix.com>

* Andrew Goodbody <andrew.goodbody@cambrionix.com> [160420 07:51]:
> This reverts commit cfe255600154f0072d4a8695590dbd194dfd1aeb
> 
> This can result in a "Unable to handle kernel paging request"
> during boot. This was due to using an uninitialised struct member,
> data->slaves.

Missing Signed-off-by?

This gets cpsw boards working in next for me again:

Tested-by: Tony Lindgren <tony@atomide.com>

^ permalink raw reply

* [PATCH v2 1/1] Revert "Prevent NUll pointer dereference with two PHYs on cpsw"
From: Andrew Goodbody @ 2016-04-20 15:14 UTC (permalink / raw)
  To: netdev
  Cc: linux-kernel, linux-omap, mugunthanvnm, grygorii.strashko, tony,
	davem, Andrew Goodbody
In-Reply-To: <1461165291-25043-1-git-send-email-andrew.goodbody@cambrionix.com>

This reverts commit cfe255600154f0072d4a8695590dbd194dfd1aeb

This can result in a "Unable to handle kernel paging request"
during boot. This was due to using an uninitialised struct member,
data->slaves.

Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
Tested-by: Tony Lindgren <tony@atomide.com>
---

v2 No code change, added signoff and collected tested-by

 drivers/net/ethernet/ti/cpsw.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 2cd67a5..54bcc38 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -349,7 +349,6 @@ struct cpsw_slave {
 	struct cpsw_slave_data		*data;
 	struct phy_device		*phy;
 	struct net_device		*ndev;
-	struct device_node		*phy_node;
 	u32				port_vlan;
 	u32				open_stat;
 };
@@ -368,6 +367,7 @@ struct cpsw_priv {
 	spinlock_t			lock;
 	struct platform_device		*pdev;
 	struct net_device		*ndev;
+	struct device_node		*phy_node;
 	struct napi_struct		napi_rx;
 	struct napi_struct		napi_tx;
 	struct device			*dev;
@@ -1142,8 +1142,8 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
 		cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
 				   1 << slave_port, 0, 0, ALE_MCAST_FWD_2);
 
-	if (slave->phy_node)
-		slave->phy = of_phy_connect(priv->ndev, slave->phy_node,
+	if (priv->phy_node)
+		slave->phy = of_phy_connect(priv->ndev, priv->phy_node,
 				 &cpsw_adjust_link, 0, slave->data->phy_if);
 	else
 		slave->phy = phy_connect(priv->ndev, slave->data->phy_id,
@@ -2025,8 +2025,7 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
 		if (strcmp(slave_node->name, "slave"))
 			continue;
 
-		priv->slaves[i].phy_node =
-			of_parse_phandle(slave_node, "phy-handle", 0);
+		priv->phy_node = of_parse_phandle(slave_node, "phy-handle", 0);
 		parp = of_get_property(slave_node, "phy_id", &lenp);
 		if (of_phy_is_fixed_link(slave_node)) {
 			struct device_node *phy_node;
@@ -2267,22 +2266,12 @@ static int cpsw_probe(struct platform_device *pdev)
 	/* Select default pin state */
 	pinctrl_pm_select_default_state(&pdev->dev);
 
-	data = &priv->data;
-	priv->slaves = devm_kzalloc(&pdev->dev,
-				    sizeof(struct cpsw_slave) * data->slaves,
-				    GFP_KERNEL);
-	if (!priv->slaves) {
-		ret = -ENOMEM;
-		goto clean_runtime_disable_ret;
-	}
-	for (i = 0; i < data->slaves; i++)
-		priv->slaves[i].slave_num = i;
-
 	if (cpsw_probe_dt(priv, pdev)) {
 		dev_err(&pdev->dev, "cpsw: platform data missing\n");
 		ret = -ENODEV;
 		goto clean_runtime_disable_ret;
 	}
+	data = &priv->data;
 
 	if (is_valid_ether_addr(data->slave_data[0].mac_addr)) {
 		memcpy(priv->mac_addr, data->slave_data[0].mac_addr, ETH_ALEN);
@@ -2294,6 +2283,16 @@ static int cpsw_probe(struct platform_device *pdev)
 
 	memcpy(ndev->dev_addr, priv->mac_addr, ETH_ALEN);
 
+	priv->slaves = devm_kzalloc(&pdev->dev,
+				    sizeof(struct cpsw_slave) * data->slaves,
+				    GFP_KERNEL);
+	if (!priv->slaves) {
+		ret = -ENOMEM;
+		goto clean_runtime_disable_ret;
+	}
+	for (i = 0; i < data->slaves; i++)
+		priv->slaves[i].slave_num = i;
+
 	priv->slaves[0].ndev = ndev;
 	priv->emac_port = 0;
 
-- 
2.5.0

^ permalink raw reply related

* [PATCH v2 0/1] Revert "Prevent NUll pointer dereference with two PHYs"
From: Andrew Goodbody @ 2016-04-20 15:14 UTC (permalink / raw)
  To: netdev
  Cc: linux-kernel, linux-omap, mugunthanvnm, grygorii.strashko, tony,
	davem, Andrew Goodbody

Revert this patch as not only did it use an unitialised member of a struct
but there is also a pre-existing patch that does it better.

V2 add signoff

Andrew Goodbody (1):
  Revert "Prevent NUll pointer dereference with two PHYs on cpsw"

 drivers/net/ethernet/ti/cpsw.c | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

-- 
2.5.0

^ permalink raw reply

* ASSALAMU ALAIKUM
From: DrHaruna Bello @ 2016-04-20 15:07 UTC (permalink / raw)

In-Reply-To: <423625983.3261692.1461164821070.JavaMail.yahoo.ref@mail.yahoo.com>



BUSINESS RELATIONSHIP

Dear Friend,


Let me start by introducing myself,I am Dr Haruna Bello,
Manager of Bank Of Africa Burkina faso.
I am writting you this letter based on the latest development at my Departmentwhich I will like to bring to your personal edification.(18.5 million U.SDollars transfer claims).
This is a legitimate transaction and I agreed to offer you 40% of this money as my foreign partner after confirmation of the fund in your bank account.
If you are interested,get back to me with the following details below.

(1)Your age........................                 
(2)Sex........................
(3)Your occupation.....
(4)Your marital status.....
(5)Your country Name......
(6)Your full residential address.......
(7)Your private phone and fax number and your complete name.......
(8)A copy of your int'l passport or ID card............
As soon as I receive these data, I will forward to you the application form whichyou will send to the bank.



Best Regard
Dr Haruna Bello

^ permalink raw reply

* Re: [PATCH net 4/4] net/mlx4_en: Split SW RX dropped counter per RX ring
From: Or Gerlitz @ 2016-04-20 15:00 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: David S. Miller, netdev, Eran Ben Elisha, Yishai Hadas,
	Saeed Mahameed
In-Reply-To: <1461164209.10638.262.camel@edumazet-glaptop3.roam.corp.google.com>

On 4/20/2016 5:56 PM, Eric Dumazet wrote:
>> >Fixes: a3333b35da16 ('net/mlx4_en: Moderate ethtool callback to [...] ')
>> >Signed-off-by: Eran Ben Elisha<eranbe@mellanox.com>
>> >Reported-by: Brenden Blanco<bblanco@plumgrid.com>
>> >Signed-off-by: Saeed Mahameed<saeedm@mellanox.com>
>> >Signed-off-by: Or Gerlitz<ogerlitz@mellanox.com>
>> >---
> Reported-by: Eric Dumazet<edumazet@google.com>
>
> (http://www.spinics.net/lists/netdev/msg371318.html  )

Hi Eric,

Just to be sure, you'd like me to re-spin this and fix the reporter name?

>
> Thanks for following up !

sure

Or.

^ permalink raw reply

* Re: Regression in next for smsc911x with tigthen lockdep checks
From: Hannes Frederic Sowa @ 2016-04-20 15:22 UTC (permalink / raw)
  To: Tony Lindgren, David S. Miller; +Cc: netdev, linux-arm-kernel, linux-omap
In-Reply-To: <20160420150108.GF5995@atomide.com>

Hi,

On 20.04.2016 17:01, Tony Lindgren wrote:
> Looks like commit fafc4e1ea1a4 ("sock: tigthen lockdep checks for
> sock_owned_by_user") in next causes a regression at least for
> smsc911x with CONFIG_LOCKDEP. It keeps spamming with the following
> message. Any ideas?

Not yet, can you quickly send me your config?

Thanks,
Hannes

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox