Netdev List
 help / color / mirror / Atom feed
* AF_VSOCK loopback
From: Stefan Hajnoczi @ 2016-11-10 14:43 UTC (permalink / raw)
  To: Jorgen Hansen; +Cc: cavery, netdev

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

Hi Jorgen,
Cathy Avery found that the AF_VSOCK VMCI transport does loopback inside
the guest (but not on the host?).  The virtio transport currently does
no loopback.

The loopback scenario I'm thinking of is where process A listens on port
1234 and process B on the same machine connects to port 1234 both with
the same CID.

I'd like to make the virtio transport compatible with VMCI transport
semantics so AF_VSOCK behaves the same regardless of the transport.
This means loopback must be added to virtio-vsock.

The core net/vmware/af_vsock.c code does not implement loopback.  How
does VMCI do loopback?  Are the loopback packets reflected back from the
host?  Or does the guest driver notice the loopback and avoid passing
packets to the host in the first place?

Maybe we can make the loopback code common in af_vsock.c if that avoids
code duplication.

Thanks,
Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

^ permalink raw reply

* Re: [PATCH net-next resend 10/13] debugfs: constify argument to debugfs_real_fops()
From: Greg Kroah-Hartman @ 2016-11-10 14:25 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: netdev, Nicolai Stange, Christian Lamparter, LKML
In-Reply-To: <1478193129-23476-11-git-send-email-jakub.kicinski@netronome.com>

On Thu, Nov 03, 2016 at 05:12:06PM +0000, Jakub Kicinski wrote:
> seq_file users can only access const version of file pointer,
> because the ->file member of struct seq_operations is marked
> as such.  Make parameter to debugfs_real_fops() const.
> 
> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> CC: Nicolai Stange <nicstange@gmail.com>
> CC: Christian Lamparter <chunkeey@gmail.com>
> CC: LKML <linux-kernel@vger.kernel.org>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
>  include/linux/debugfs.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
> index 4d3f0d1aec73..bf1907d96097 100644
> --- a/include/linux/debugfs.h
> +++ b/include/linux/debugfs.h
> @@ -52,7 +52,8 @@ struct debugfs_regset32 {
>   * Must only be called under the protection established by
>   * debugfs_use_file_start().
>   */
> -static inline const struct file_operations *debugfs_real_fops(struct file *filp)
> +static inline const struct file_operations *
> +debugfs_real_fops(const struct file *filp)

Ick.  Tell me that looks better :(

Please just don't wrap things like that, just make it go longer than 80
columns, I can handle the complaints...

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH v9 7/8] thunderbolt: Networking doc
From: Jonathan Corbet @ 2016-11-10 14:24 UTC (permalink / raw)
  To: Greg KH
  Cc: Amir Levy, andreas.noever, bhelgaas, linux-kernel, linux-pci,
	netdev, linux-doc, mario_limonciello, thunderbolt-linux,
	mika.westerberg, tomas.winkler, xiong.y.zhang
In-Reply-To: <20161109160002.GA9111@kroah.com>

On Wed, 9 Nov 2016 17:00:02 +0100
Greg KH <gregkh@linuxfoundation.org> wrote:

> >  Documentation/00-INDEX                   |   2 +
> >  Documentation/thunderbolt/networking.txt | 132 +++++++++++++++++++++++++++++++  
> 
> Note, new files should be in .rst format, and live in the new
> subdirectory for them (somewhere in Documentation, don't know off the
> top of my head...)

This one's almost in RST already, happily.

We haven't really figured out a hierarchy for device-specific docs like
this yet; I should get on that, I guess.

I do believe that we should separate documents for end users from those
aimed at kernel developers; those are two very different audiences
looking for different kinds of information.

Thanks,

jon

^ permalink raw reply

* [PATCH] net: phy: marvell: optimize logic for page changing during init
From: Uwe Kleine-König @ 2016-11-10 14:03 UTC (permalink / raw)
  To: Florian Fainelli; +Cc: netdev

Instead of remembering if the page was changed, just compare the current
page to the saved one. This is easier and has the advantage to save a
register write if the page was already restored.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
 drivers/net/phy/marvell.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index c2dcf02df202..fa31f50824d3 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -361,7 +361,7 @@ static int m88e1111_config_aneg(struct phy_device *phydev)
 static int marvell_of_reg_init(struct phy_device *phydev)
 {
 	const __be32 *paddr;
-	int len, i, saved_page, current_page, page_changed, ret;
+	int len, i, saved_page, current_page, ret;
 
 	if (!phydev->mdio.dev.of_node)
 		return 0;
@@ -374,7 +374,6 @@ static int marvell_of_reg_init(struct phy_device *phydev)
 	saved_page = phy_read(phydev, MII_MARVELL_PHY_PAGE);
 	if (saved_page < 0)
 		return saved_page;
-	page_changed = 0;
 	current_page = saved_page;
 
 	ret = 0;
@@ -388,7 +387,6 @@ static int marvell_of_reg_init(struct phy_device *phydev)
 
 		if (reg_page != current_page) {
 			current_page = reg_page;
-			page_changed = 1;
 			ret = phy_write(phydev, MII_MARVELL_PHY_PAGE, reg_page);
 			if (ret < 0)
 				goto err;
@@ -411,7 +409,7 @@ static int marvell_of_reg_init(struct phy_device *phydev)
 
 	}
 err:
-	if (page_changed) {
+	if (current_page != saved_page) {
 		i = phy_write(phydev, MII_MARVELL_PHY_PAGE, saved_page);
 		if (ret == 0)
 			ret = i;
-- 
2.10.2

^ permalink raw reply related

* Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Hisashi T Fujinaka @ 2016-11-10 13:48 UTC (permalink / raw)
  To: Corinna Vinschen
  Cc: Alexander Duyck, Netdev, linux-kernel@vger.kernel.org, Cao jin,
	intel-wired-lan, Izumi, Taku/泉 拓
In-Reply-To: <20161110093549.GA24351@calimero.vinschen.de>

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Thu, 10 Nov 2016, Corinna Vinschen wrote:

> On Nov  8 11:33, Alexander Duyck wrote:
...
>> The question I would have is what is reading the device when it is in
>> this state.  The watchdog and any other functions that would read the
>> device should be disabled.
>>
>> One possibility could be a race between a call to igb_close and the
>> igb_suspend function.  We have seen some of those pop up recently on
>> ixgbe and it looks like igb has the same bug.  We should probably be
>> using the rtnl_lock to guarantee that netif_device_detach and the call
>> to __igb_close are completed before igb_close could possibly be called
>> by the network stack.
>
> Do you have a pointer to the related ixgbe patch, by any chance?
...
>> The thing is that a suspended device should not be accessed at all.
>> If we are accessing it while it is suspended then that is a bug.  If
>> you could throw a WARN_ON call in igb_rd32 to capture where this is
>> being triggered that might be useful.
>>
>>> - Otherwise assume it's actually a surprise removal.  In theory that
>>>   should somehow trigger a device removal sequence, kind of like
>>>   calling igb_remove, no?
>>
>> Well a read of the MMIO region while suspended is more of a surprise
>> read since there shouldn't be anything going on.  We need to isolate
>> where that read is coming from and fix it.
>
> That would be ideal, but the problem couldn't be reproduced yet apart
> from at a customer's customer site.  It's not clear yet if we can access
> the machine for further testing.

Here's the initial patch for igb I have, but it's on hold awaiting more
changes in ixgbe regarding AER.

-- 
Hisashi T Fujinaka - htodd@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee

[-- Attachment #2: Type: text/plain, Size: 2306 bytes --]

From todd.fujinaka@intel.com Thu Nov 10 05:44:02 2016
Date: Thu, 10 Nov 2016 05:36:13 -0800
From: Todd Fujinaka <todd.fujinaka@intel.com>
To: htodd@twofifty.com
Subject: [PATCH] igb: handle close/suspend race netif_device_detach

Similar to ixgbe, when an interface is part of a namespace it is
possible that igb_close() may be called while __igb_shutdown() is
running ending up in a double free WARN and/or a BUG in
free_msi_irqs().

Extend the rtnl_lock() to protect the call to netif_device_detach() and
igb_clear_interrupt_scheme() in __igb_shutdown() and check for
netif_device_present() to avoid clearing the interrupts second time in
igb_close().

Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
---
 drivers/net/ethernet/intel/igb/igb_main.c | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 4feca69..ce5add6 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3275,7 +3275,10 @@ static int __igb_close(struct net_device *netdev, bool suspending)
 
 int igb_close(struct net_device *netdev)
 {
-	return __igb_close(netdev, false);
+	if (netif_device_present(netdev))
+		return __igb_close(netdev, false);
+
+	return 0;
 }
 
 /**
@@ -7537,6 +7540,7 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
 	int retval = 0;
 #endif
 
+	rtnl_lock();
 	netif_device_detach(netdev);
 
 	if (netif_running(netdev))
@@ -7545,6 +7549,7 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
 	igb_ptp_suspend(adapter);
 
 	igb_clear_interrupt_scheme(adapter);
+	rtnl_unlock();
 
 #ifdef CONFIG_PM
 	retval = pci_save_state(pdev);
@@ -7663,16 +7668,17 @@ static int igb_resume(struct device *dev)
 
 	wr32(E1000_WUS, ~0);
 
-	if (netdev->flags & IFF_UP) {
-		rtnl_lock();
+	rtnl_lock();
+
+	if (!err && netif_running(netdev))
 		err = __igb_open(netdev, true);
-		rtnl_unlock();
-		if (err)
-			return err;
-	}
 
-	netif_device_attach(netdev);
-	return 0;
+	if (!err)
+		netif_device_attach(netdev);
+
+	rtnl_unlock();
+
+	return err;
 }
 
 static int igb_runtime_idle(struct device *dev)
-- 
2.7.4

^ permalink raw reply related

* ATENCIÓN;
From: Administrador @ 2016-11-10 12:47 UTC (permalink / raw)
  To: Recipients

ATENCIÓN;

Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que
vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:

nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:

Si usted no puede revalidar su buzón, el buzón se deshabilitará!

Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2016

¡gracias
Sistemas administrador

^ permalink raw reply

* Re: [PATCH net-next] ipv6: sr: fix IPv6 initialization failure without lwtunnels
From: kbuild test robot @ 2016-11-10 12:32 UTC (permalink / raw)
  To: David Lebrun; +Cc: kbuild-all, netdev, lorenzo, davem, David Lebrun
In-Reply-To: <1478771715-23137-1-git-send-email-david.lebrun@uclouvain.be>

[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]

Hi David,

[auto build test ERROR on net-next/master]

url:    https://github.com/0day-ci/linux/commits/David-Lebrun/ipv6-sr-fix-IPv6-initialization-failure-without-lwtunnels/20161110-175753
config: i386-randconfig-s0-201645 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from net/ipv6/seg6_iptunnel.c:24:0:
   include/net/seg6.h: In function 'seg6_pernet':
>> include/net/seg6.h:52:12: error: 'struct net' has no member named 'ipv6'; did you mean 'ipv4'?
     return net->ipv6.seg6_data;
               ^~
   include/net/seg6.h:53:1: warning: control reaches end of non-void function [-Wreturn-type]
    }
    ^

vim +52 include/net/seg6.h

1ababeba David Lebrun 2016-11-08  36  		to[0], to[1], to[2], to[3],
1ababeba David Lebrun 2016-11-08  37  	};
1ababeba David Lebrun 2016-11-08  38  
1ababeba David Lebrun 2016-11-08  39  	skb->csum = ~csum_partial((char *)diff, sizeof(diff), ~skb->csum);
1ababeba David Lebrun 2016-11-08  40  }
1ababeba David Lebrun 2016-11-08  41  
915d7e5e David Lebrun 2016-11-08  42  struct seg6_pernet_data {
915d7e5e David Lebrun 2016-11-08  43  	struct mutex lock;
915d7e5e David Lebrun 2016-11-08  44  	struct in6_addr __rcu *tun_src;
bf355b8d David Lebrun 2016-11-08  45  #ifdef CONFIG_IPV6_SEG6_HMAC
bf355b8d David Lebrun 2016-11-08  46  	struct rhashtable hmac_infos;
bf355b8d David Lebrun 2016-11-08  47  #endif
915d7e5e David Lebrun 2016-11-08  48  };
915d7e5e David Lebrun 2016-11-08  49  
915d7e5e David Lebrun 2016-11-08  50  static inline struct seg6_pernet_data *seg6_pernet(struct net *net)
915d7e5e David Lebrun 2016-11-08  51  {
915d7e5e David Lebrun 2016-11-08 @52  	return net->ipv6.seg6_data;
915d7e5e David Lebrun 2016-11-08  53  }
915d7e5e David Lebrun 2016-11-08  54  
915d7e5e David Lebrun 2016-11-08  55  extern int seg6_init(void);
915d7e5e David Lebrun 2016-11-08  56  extern void seg6_exit(void);
6c8702c6 David Lebrun 2016-11-08  57  extern int seg6_iptunnel_init(void);
6c8702c6 David Lebrun 2016-11-08  58  extern void seg6_iptunnel_exit(void);
6c8702c6 David Lebrun 2016-11-08  59  
6c8702c6 David Lebrun 2016-11-08  60  extern bool seg6_validate_srh(struct ipv6_sr_hdr *srh, int len);

:::::: The code at line 52 was first introduced by commit
:::::: 915d7e5e5930b4f01d0971d93b9b25ed17d221aa ipv6: sr: add code base for control plane support of SR-IPv6

:::::: TO: David Lebrun <david.lebrun@uclouvain.be>
:::::: CC: David S. Miller <davem@davemloft.net>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 21480 bytes --]

^ permalink raw reply

* [PATCH net-next v2] ipv6: sr: fix IPv6 initialization failure without lwtunnels
From: David Lebrun @ 2016-11-10 12:26 UTC (permalink / raw)
  To: netdev; +Cc: lorenzo, davem, David Lebrun
In-Reply-To: <CAKD1Yr0fDFdDv9+S3i_rH6W6btEuvs9s-h33_N67iM4qrtDezQ@mail.gmail.com>

v2: fix conditional compilation for seg6_iptunnel.o in Makefile

This patch compiles SR lwtunnels support only if CONFIG_LWTUNNEL=y.

If IPv6 is enabled and CONFIG_LWTUNNEL=n, then seg6_iptunnel_init()
fails with EOPNOTSUPP which in turn makes seg6_init() fail, blocking
the IPv6 initialization, with the following messages:

NET: Registered protocol family 10
IPv6: Attempt to unregister permanent protocol 6
IPv6: Attempt to unregister permanent protocol 136
IPv6: Attempt to unregister permanent protocol 17
NET: Unregistered protocol family 10

Fix commit 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")

Tested with various combinations of CONFIG_IPV6 and CONFIG_LWTUNNEL.

Reported-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
 net/ipv6/Kconfig  | 1 +
 net/ipv6/Makefile | 3 ++-
 net/ipv6/seg6.c   | 8 ++++++++
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index 0f00811..030cdb6 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -292,6 +292,7 @@ config IPV6_PIMSM_V2
 config IPV6_SEG6_INLINE
 	bool "IPv6: direct Segment Routing Header insertion "
 	depends on IPV6
+	depends on LWTUNNEL
 	---help---
 	  Support for direct insertion of the Segment Routing Header,
 	  also known as inline mode. Be aware that direct insertion of
diff --git a/net/ipv6/Makefile b/net/ipv6/Makefile
index 129cad2..8979d53 100644
--- a/net/ipv6/Makefile
+++ b/net/ipv6/Makefile
@@ -9,7 +9,7 @@ ipv6-objs :=	af_inet6.o anycast.o ip6_output.o ip6_input.o addrconf.o \
 		route.o ip6_fib.o ipv6_sockglue.o ndisc.o udp.o udplite.o \
 		raw.o icmp.o mcast.o reassembly.o tcp_ipv6.o ping.o \
 		exthdrs.o datagram.o ip6_flowlabel.o inet6_connection_sock.o \
-		udp_offload.o seg6.o seg6_iptunnel.o
+		udp_offload.o seg6.o
 
 ipv6-offload :=	ip6_offload.o tcpv6_offload.o exthdrs_offload.o
 
@@ -53,5 +53,6 @@ obj-$(subst m,y,$(CONFIG_IPV6)) += inet6_hashtables.o
 
 ifneq ($(CONFIG_IPV6),)
 obj-$(CONFIG_NET_UDP_TUNNEL) += ip6_udp_tunnel.o
+obj-$(CONFIG_LWTUNNEL) += seg6_iptunnel.o
 obj-y += mcast_snoop.o
 endif
diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
index 50f6e06..0f74f90 100644
--- a/net/ipv6/seg6.c
+++ b/net/ipv6/seg6.c
@@ -451,9 +451,11 @@ int __init seg6_init(void)
 	if (err)
 		goto out_unregister_genl;
 
+#ifdef CONFIG_LWTUNNEL
 	err = seg6_iptunnel_init();
 	if (err)
 		goto out_unregister_pernet;
+#endif
 
 #ifdef CONFIG_IPV6_SEG6_HMAC
 	err = seg6_hmac_init();
@@ -467,10 +469,14 @@ int __init seg6_init(void)
 	return err;
 #ifdef CONFIG_IPV6_SEG6_HMAC
 out_unregister_iptun:
+#ifdef CONFIG_LWTUNNEL
 	seg6_iptunnel_exit();
 #endif
+#endif
+#ifdef CONFIG_LWTUNNEL
 out_unregister_pernet:
 	unregister_pernet_subsys(&ip6_segments_ops);
+#endif
 out_unregister_genl:
 	genl_unregister_family(&seg6_genl_family);
 	goto out;
@@ -481,7 +487,9 @@ void seg6_exit(void)
 #ifdef CONFIG_IPV6_SEG6_HMAC
 	seg6_hmac_exit();
 #endif
+#ifdef CONFIG_LWTUNNEL
 	seg6_iptunnel_exit();
+#endif
 	unregister_pernet_subsys(&ip6_segments_ops);
 	genl_unregister_family(&seg6_genl_family);
 }
-- 
2.7.3

^ permalink raw reply related

* Re: [PATCH v3 3/5] net: asix: Fix AX88772x resume failures
From: Jon Hunter @ 2016-11-10 12:01 UTC (permalink / raw)
  To: robert.foss-ZGY8ohtN/8qB+jHODAdFcQ, freddy-knRN6Y/kmf1NUHwG+Fw1Kw,
	Dean_Jenkins-nmGgyN9QBj3QT0dZR+AlfA,
	Mark_Craske-nmGgyN9QBj3QT0dZR+AlfA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	ivecera-H+wXaHxf7aLQT0dZR+AlfA,
	john.stultz-QSEj5FYQhm4dnm+yROfE0A,
	vpalatin-F7+t8E8rja9g9hUCZPvPmw,
	stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
	grundler-F7+t8E8rja9g9hUCZPvPmw,
	changchias-Re5JQEeQqe8AvxtiuMwx3w, allan-knRN6Y/kmf1NUHwG+Fw1Kw,
	andrew-g2DYL2Zd6BY, tremyfr-Re5JQEeQqe8AvxtiuMwx3w,
	colin.king-Z7WLFzj8eWMS+FvcfC7Uqw,
	linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	vpalatin-hpIqsD4AKlfQT0dZR+AlfA
In-Reply-To: <c708db3f1e006df543284cf5215b965ce4fc44ec.1472155176.git-series.robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>

Hi Robert,

On 29/08/16 14:32, robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org wrote:
> From: Robert Foss <robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> 
> From: Allan Chou <allan-knRN6Y/kmf1NUHwG+Fw1Kw@public.gmane.org>
> 
> The change fixes AX88772x resume failure by
> - Restore incorrect AX88772A PHY registers when resetting
> - Need to stop MAC operation when suspending
> - Need to restart MII when restoring PHY
> 
> Signed-off-by: Allan Chou <allan-knRN6Y/kmf1NUHwG+Fw1Kw@public.gmane.org>
> Signed-off-by: Robert Foss <robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Tested-by: Robert Foss <robert.foss-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>

After this commit, I have started seeing the following messages
during system suspend on various tegra boards using asix ethernet
dongles ...

[  288.667010] PM: Syncing filesystems ... done.
[  288.672223] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  288.680505] Double checking all user space processes after OOM killer disable... (elapsed 0.000 seconds) 
[  288.690193] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  288.698987] Suspending console(s) (use no_console_suspend to debug)
[  288.706605] asix 1-1:1.0 eth0: Failed to read reg index 0x0000: -19
[  288.706613] asix 1-1:1.0 eth0: Error reading Medium Status register: ffffffed
[  288.706621] asix 1-1:1.0 eth0: Failed to write reg index 0x0000: -19
[  288.706629] asix 1-1:1.0 eth0: Failed to write Medium Mode mode to 0xfeed: ffffffed
[  288.759167] PM: suspend of devices complete after 52.772 msecs

Interestingly, it only seems to happen if the ethernet is in a
disconnected state when entering suspend. I have not had chance
to look at this any further, but wanted to see if you had any
thoughts.

Cheers
Jon

-- 
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v9 7/8] thunderbolt: Networking doc
From: Greg KH @ 2016-11-10 11:53 UTC (permalink / raw)
  To: Levy, Amir (Jer)
  Cc: andreas.noever@gmail.com, bhelgaas@google.com, corbet@lwn.net,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	mario_limonciello@dell.com, thunderbolt-linux, Westerberg, Mika,
	Winkler, Tomas, Zhang, Xiong Y
In-Reply-To: <E607265CB020454880711A6F96C05A03B677F516@hasmsx107.ger.corp.intel.com>

On Thu, Nov 10, 2016 at 11:47:57AM +0000, Levy, Amir (Jer) wrote:
> On Wed, Nov 9 2016, 06:00 PM, Greg KH wrote:
> > On Wed, Nov 09, 2016 at 04:20:07PM +0200, Amir Levy wrote:
> > > Adding Thunderbolt(TM) networking documentation.
> > >
> > > Signed-off-by: Amir Levy <amir.jer.levy@intel.com>
> > > ---
> > >  Documentation/00-INDEX                   |   2 +
> > >  Documentation/thunderbolt/networking.txt | 132
> > > +++++++++++++++++++++++++++++++
> > 
> > Note, new files should be in .rst format, and live in the new subdirectory for
> > them (somewhere in Documentation, don't know off the top of my head...)
> > 
> > >  2 files changed, 134 insertions(+)
> > >  create mode 100644 Documentation/thunderbolt/networking.txt
> > >
> > > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index
> > > 3acc4f1..0239e68 100644
> > > --- a/Documentation/00-INDEX
> > > +++ b/Documentation/00-INDEX
> > > @@ -440,6 +440,8 @@ this_cpu_ops.txt
> > >  	- List rationale behind and the way to use this_cpu operations.
> > >  thermal/
> > >  	- directory with information on managing thermal issues (CPU/temp)
> > > +thunderbolt/
> > > +	- directory with info regarding Thunderbolt.
> > >  trace/
> > >  	- directory with info on tracing technologies within linux
> > > unaligned-memory-access.txt
> > 
> > This change is probably not needed.
> > 
> > > diff --git a/Documentation/thunderbolt/networking.txt
> > > b/Documentation/thunderbolt/networking.txt
> > > new file mode 100644
> > > index 0000000..88d1c12
> > > --- /dev/null
> > > +++ b/Documentation/thunderbolt/networking.txt
> > > @@ -0,0 +1,132 @@
> > > +Intel Thunderbolt(TM) Networking driver
> > > +=======================================
> > > +
> > > +Copyright(c) 2013 - 2016 Intel Corporation.
> > > +
> > > +Contact Information:
> > > +Intel Thunderbolt mailing list <thunderbolt-software@lists.01.org>
> > > +Edited by Amir Levy <amir.jer.levy@intel.com>
> > > +
> > > +Overview
> > > +========
> > > +
> > > +* The Thunderbolt Networking driver enables peer to peer networking
> > > +on non-Apple
> > > +  platforms running Linux.
> > > +
> > > +* The driver creates a virtual Ethernet device that enables computer
> > > +to computer
> > > +  communication over the Thunderbolt cable.
> > > +
> > > +* Using Thunderbolt Networking you can perform high speed file
> > > +transfers between
> > > +  computers, perform PC migrations and/or set up small workgroups
> > > +with shared
> > > +  storage without compromising any other Thunderbolt functionality.
> > > +
> > > +* The driver is located in drivers/thunderbolt/icm.
> > > +
> > > +* This driver will function only on non-Apple platforms with firmware
> > > +based
> > > +  Thunderbolt controllers that support Thunderbolt Networking.
> > > +
> > > +  +----------------+            +----------------+
> > > +  |Host 1          |            |Host 2          |
> > > +  |                |            |                |
> > > +  |   +-------+    |            |    +-------+   |
> > > +  |   |Network|    |            |    |Network|   |
> > > +  |   |Stack  |    |            |    |Stack  |   |
> > > +  |   +-------+    |            |    +-------+   |
> > > +  |       ^        |            |        ^       |
> > > +  |       |        |            |        |       |
> > > +  |       v        |            |        v       |
> > > +  | +-----------+  |            |  +-----------+ |
> > > +  | |Thunderbolt|  |            |  |Thunderbolt| |
> > > +  | |Networking |  |            |  |Networking | |
> > > +  | |Driver     |  |            |  |Driver     | |
> > > +  | +-----------+  |            |  +-----------+ |
> > > +  |       ^        |            |        ^       |
> > > +  |       |        |            |        |       |
> > > +  |       v        |            |        v       |
> > > +  | +-----------+  |            |  +-----------+ |
> > > +  | |Thunderbolt|  |            |  |Thunderbolt| |
> > > +  | |Controller |<-+------------+->|Controller | |
> > > +  | |with ICM   |  |            |  |with ICM   | |
> > > +  | |enabled    |  |            |  |enabled    | |
> > > +  | +-----------+  |            |  +-----------+ |
> > > +  +----------------+            +----------------+
> > > +
> > > +Files
> > > +=====
> > > +
> > > +The following files are located in the drivers/thunderbolt/icm directory:
> > > +
> > > +- icm_nhi.c/h:	These files allow communication with the firmware
> > (Intel
> > > +  Connection Manager) based controller. They also create an interface
> > > +for
> > > +  netlink communication with a user space daemon.
> > > +
> > > +- net.c/net.h:	These files implement the 'eth' interface for the
> > > +  Thunderbolt(TM) Networking.
> > 
> > You don't have to list the files, right?
> > 
> > > +
> > > +Interface to User Space
> > > +=======================
> > > +
> > > +The interface to the user space module is implemented through a Generic
> > Netlink.
> > 
> > Huh?  Not a normal network device?
> > 
> > > +This is the communications protocol between the Thunderbolt driver
> > > +and the user space application.
> > 
> > What userspace application?
> > 
> > > +Note that this interface mediates user space communication with ICM.
> > 
> > What is ICM?
> > 
> > > +(Existing Linux tools can be used to configure the network
> > > +interface.)
> > 
> > Why aren't they sufficient for everything here?
> > 
> > > +
> > > +The Thunderbolt Daemon utilizes this interface to communicate with the
> > driver.
> > 
> > What "Thunderbolt Daemon"?  What is "this"?
> > 
> > > +To be accessed by the user space module, both kernel and user space
> > > +modules have to register with the same GENL_NAME.
> > 
> > What userspace modules?
> > 
> > How do you set GENL_NAME?  What is that?
> > 
> > > +For the purpose of the Thunderbolt Network driver, "thunderbolt" is
> > used.
> > 
> > What do you mean?
> > 
> > > +The registration is done at driver initialization time for all
> > > +instances of the Thunderbolt controllers.
> > 
> > Who does this?
> > 
> > > The communication is carried through pre-defined
> > > +Thunderbolt messages. Each specific message has a callback function
> > > +that is called when the related message is received.
> > 
> > Is this the internal structure of the driver?  If so, why not just put it all in the
> > code itself and build the documentation from it?
> > 
> > > +
> > > +Message Definitions:
> > > +* NHI_CMD_UNSPEC: Not used.
> > > +* NHI_CMD_SUBSCRIBE: Subscription request from daemon to driver to
> > > +open the
> > > +  communication channel.
> > > +* NHI_CMD_UNSUBSCRIBE: Request from daemon to driver to
> > unsubscribe
> > > +and
> > > +  to close communication channel.
> > > +* NHI_CMD_QUERY_INFORMATION: Request information from the driver
> > such
> > > +as
> > > +  driver version, FW version offset, number of ports in the
> > > +controller
> > > +  and DMA port.
> > > +* NHI_CMD_MSG_TO_ICM: Message from user space module to FW.
> > > +* NHI_CMD_MSG_FROM_ICM: Response from FW to user space module.
> > > +* NHI_CMD_MAILBOX: Message that uses mailbox mechanism such as
> > FW
> > > +policy
> > > +  changes or disconnect path.
> > > +* NHI_CMD_APPROVE_TBT_NETWORKING: Request from user space
> > module to
> > > +FW to
> > > +  establish path.
> > > +* NHI_CMD_ICM_IN_SAFE_MODE: Indication that the FW has entered
> > safe mode.
> > > +
> > > +Communication with Intel Connection Manager(ICM) Firmware
> > >
> > +=========================================================
> > > +
> > > +There are several circular buffers in Thunderbolt each using Direct
> > > +Memory Access (DMA).
> > 
> > Again, internal documentation?
> > 
> > Isn't this just a "normal" network device?  Why document any of this in a
> > separate way?  What can a user do with this?  Who is the audience of this
> > file?
> > 
> > still confused,
> > 
> > greg k-h
> 
> This document was one of the suggestions we got from internal-Intel kernel developers.
> If you think it isn't needed, I'll remove it from next patch set.

I'm not saying it is not needed, I'm saying that if you want it, it
needs to actually be useful :)

As it is, look at the questions I asked above, I really don't understand
this document.  And if I'm not the target audience for this, then great,
who is?

thanks,

greg k-h

^ permalink raw reply

* RE: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
From: Levy, Amir (Jer) @ 2016-11-10 11:48 UTC (permalink / raw)
  To: Greg KH
  Cc: andreas.noever@gmail.com, bhelgaas@google.com, corbet@lwn.net,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	mario_limonciello@dell.com, thunderbolt-linux, Westerberg, Mika,
	Winkler, Tomas, Zhang, Xiong Y
In-Reply-To: <20161110114411.GA4155@kroah.com>

On Thu, Nov 10 2016, 01:44 PM, Greg KH wrote:
> On Thu, Nov 10, 2016 at 11:39:19AM +0000, Levy, Amir (Jer) wrote:
> > > And how about getting some internal-Intel kernel developers to
> > > review and sign-off on this code?  Don't make the community do the
> > > review when you have access to resources like this.  You have an
> > > internal mailing list for this very purpose, use it!
> > >
> >
> > The review with the internal-Intel kernel developers was done before
> > submitting the first patch set.
> 
> Then why is their signed-off-by:s not on the patchset showing that they
> "bless" this series?
> 

Working on it.

> thanks,
> 
> greg k-h

^ permalink raw reply

* RE: [PATCH v9 7/8] thunderbolt: Networking doc
From: Levy, Amir (Jer) @ 2016-11-10 11:47 UTC (permalink / raw)
  To: Greg KH
  Cc: andreas.noever@gmail.com, bhelgaas@google.com, corbet@lwn.net,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	mario_limonciello@dell.com, thunderbolt-linux, Westerberg, Mika,
	Winkler, Tomas, Zhang, Xiong Y
In-Reply-To: <20161109160002.GA9111@kroah.com>

On Wed, Nov 9 2016, 06:00 PM, Greg KH wrote:
> On Wed, Nov 09, 2016 at 04:20:07PM +0200, Amir Levy wrote:
> > Adding Thunderbolt(TM) networking documentation.
> >
> > Signed-off-by: Amir Levy <amir.jer.levy@intel.com>
> > ---
> >  Documentation/00-INDEX                   |   2 +
> >  Documentation/thunderbolt/networking.txt | 132
> > +++++++++++++++++++++++++++++++
> 
> Note, new files should be in .rst format, and live in the new subdirectory for
> them (somewhere in Documentation, don't know off the top of my head...)
> 
> >  2 files changed, 134 insertions(+)
> >  create mode 100644 Documentation/thunderbolt/networking.txt
> >
> > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index
> > 3acc4f1..0239e68 100644
> > --- a/Documentation/00-INDEX
> > +++ b/Documentation/00-INDEX
> > @@ -440,6 +440,8 @@ this_cpu_ops.txt
> >  	- List rationale behind and the way to use this_cpu operations.
> >  thermal/
> >  	- directory with information on managing thermal issues (CPU/temp)
> > +thunderbolt/
> > +	- directory with info regarding Thunderbolt.
> >  trace/
> >  	- directory with info on tracing technologies within linux
> > unaligned-memory-access.txt
> 
> This change is probably not needed.
> 
> > diff --git a/Documentation/thunderbolt/networking.txt
> > b/Documentation/thunderbolt/networking.txt
> > new file mode 100644
> > index 0000000..88d1c12
> > --- /dev/null
> > +++ b/Documentation/thunderbolt/networking.txt
> > @@ -0,0 +1,132 @@
> > +Intel Thunderbolt(TM) Networking driver
> > +=======================================
> > +
> > +Copyright(c) 2013 - 2016 Intel Corporation.
> > +
> > +Contact Information:
> > +Intel Thunderbolt mailing list <thunderbolt-software@lists.01.org>
> > +Edited by Amir Levy <amir.jer.levy@intel.com>
> > +
> > +Overview
> > +========
> > +
> > +* The Thunderbolt Networking driver enables peer to peer networking
> > +on non-Apple
> > +  platforms running Linux.
> > +
> > +* The driver creates a virtual Ethernet device that enables computer
> > +to computer
> > +  communication over the Thunderbolt cable.
> > +
> > +* Using Thunderbolt Networking you can perform high speed file
> > +transfers between
> > +  computers, perform PC migrations and/or set up small workgroups
> > +with shared
> > +  storage without compromising any other Thunderbolt functionality.
> > +
> > +* The driver is located in drivers/thunderbolt/icm.
> > +
> > +* This driver will function only on non-Apple platforms with firmware
> > +based
> > +  Thunderbolt controllers that support Thunderbolt Networking.
> > +
> > +  +----------------+            +----------------+
> > +  |Host 1          |            |Host 2          |
> > +  |                |            |                |
> > +  |   +-------+    |            |    +-------+   |
> > +  |   |Network|    |            |    |Network|   |
> > +  |   |Stack  |    |            |    |Stack  |   |
> > +  |   +-------+    |            |    +-------+   |
> > +  |       ^        |            |        ^       |
> > +  |       |        |            |        |       |
> > +  |       v        |            |        v       |
> > +  | +-----------+  |            |  +-----------+ |
> > +  | |Thunderbolt|  |            |  |Thunderbolt| |
> > +  | |Networking |  |            |  |Networking | |
> > +  | |Driver     |  |            |  |Driver     | |
> > +  | +-----------+  |            |  +-----------+ |
> > +  |       ^        |            |        ^       |
> > +  |       |        |            |        |       |
> > +  |       v        |            |        v       |
> > +  | +-----------+  |            |  +-----------+ |
> > +  | |Thunderbolt|  |            |  |Thunderbolt| |
> > +  | |Controller |<-+------------+->|Controller | |
> > +  | |with ICM   |  |            |  |with ICM   | |
> > +  | |enabled    |  |            |  |enabled    | |
> > +  | +-----------+  |            |  +-----------+ |
> > +  +----------------+            +----------------+
> > +
> > +Files
> > +=====
> > +
> > +The following files are located in the drivers/thunderbolt/icm directory:
> > +
> > +- icm_nhi.c/h:	These files allow communication with the firmware
> (Intel
> > +  Connection Manager) based controller. They also create an interface
> > +for
> > +  netlink communication with a user space daemon.
> > +
> > +- net.c/net.h:	These files implement the 'eth' interface for the
> > +  Thunderbolt(TM) Networking.
> 
> You don't have to list the files, right?
> 
> > +
> > +Interface to User Space
> > +=======================
> > +
> > +The interface to the user space module is implemented through a Generic
> Netlink.
> 
> Huh?  Not a normal network device?
> 
> > +This is the communications protocol between the Thunderbolt driver
> > +and the user space application.
> 
> What userspace application?
> 
> > +Note that this interface mediates user space communication with ICM.
> 
> What is ICM?
> 
> > +(Existing Linux tools can be used to configure the network
> > +interface.)
> 
> Why aren't they sufficient for everything here?
> 
> > +
> > +The Thunderbolt Daemon utilizes this interface to communicate with the
> driver.
> 
> What "Thunderbolt Daemon"?  What is "this"?
> 
> > +To be accessed by the user space module, both kernel and user space
> > +modules have to register with the same GENL_NAME.
> 
> What userspace modules?
> 
> How do you set GENL_NAME?  What is that?
> 
> > +For the purpose of the Thunderbolt Network driver, "thunderbolt" is
> used.
> 
> What do you mean?
> 
> > +The registration is done at driver initialization time for all
> > +instances of the Thunderbolt controllers.
> 
> Who does this?
> 
> > The communication is carried through pre-defined
> > +Thunderbolt messages. Each specific message has a callback function
> > +that is called when the related message is received.
> 
> Is this the internal structure of the driver?  If so, why not just put it all in the
> code itself and build the documentation from it?
> 
> > +
> > +Message Definitions:
> > +* NHI_CMD_UNSPEC: Not used.
> > +* NHI_CMD_SUBSCRIBE: Subscription request from daemon to driver to
> > +open the
> > +  communication channel.
> > +* NHI_CMD_UNSUBSCRIBE: Request from daemon to driver to
> unsubscribe
> > +and
> > +  to close communication channel.
> > +* NHI_CMD_QUERY_INFORMATION: Request information from the driver
> such
> > +as
> > +  driver version, FW version offset, number of ports in the
> > +controller
> > +  and DMA port.
> > +* NHI_CMD_MSG_TO_ICM: Message from user space module to FW.
> > +* NHI_CMD_MSG_FROM_ICM: Response from FW to user space module.
> > +* NHI_CMD_MAILBOX: Message that uses mailbox mechanism such as
> FW
> > +policy
> > +  changes or disconnect path.
> > +* NHI_CMD_APPROVE_TBT_NETWORKING: Request from user space
> module to
> > +FW to
> > +  establish path.
> > +* NHI_CMD_ICM_IN_SAFE_MODE: Indication that the FW has entered
> safe mode.
> > +
> > +Communication with Intel Connection Manager(ICM) Firmware
> >
> +=========================================================
> > +
> > +There are several circular buffers in Thunderbolt each using Direct
> > +Memory Access (DMA).
> 
> Again, internal documentation?
> 
> Isn't this just a "normal" network device?  Why document any of this in a
> separate way?  What can a user do with this?  Who is the audience of this
> file?
> 
> still confused,
> 
> greg k-h

This document was one of the suggestions we got from internal-Intel kernel developers.
If you think it isn't needed, I'll remove it from next patch set.

^ permalink raw reply

* Re: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
From: Greg KH @ 2016-11-10 11:44 UTC (permalink / raw)
  To: Levy, Amir (Jer)
  Cc: andreas.noever@gmail.com, bhelgaas@google.com, corbet@lwn.net,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	mario_limonciello@dell.com, thunderbolt-linux, Westerberg, Mika,
	Winkler, Tomas, Zhang, Xiong Y
In-Reply-To: <E607265CB020454880711A6F96C05A03B677F4D9@hasmsx107.ger.corp.intel.com>

On Thu, Nov 10, 2016 at 11:39:19AM +0000, Levy, Amir (Jer) wrote:
> > And how about getting some internal-Intel kernel developers to review and
> > sign-off on this code?  Don't make the community do the review when you
> > have access to resources like this.  You have an internal mailing list for this
> > very purpose, use it!
> > 
> 
> The review with the internal-Intel kernel developers was done before submitting
> the first patch set.

Then why is their signed-off-by:s not on the patchset showing that they
"bless" this series?

thanks,

greg k-h

^ permalink raw reply

* RE: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
From: Levy, Amir (Jer) @ 2016-11-10 11:39 UTC (permalink / raw)
  To: Greg KH
  Cc: andreas.noever@gmail.com, bhelgaas@google.com, corbet@lwn.net,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	mario_limonciello@dell.com, thunderbolt-linux, Westerberg, Mika,
	Winkler, Tomas, Zhang, Xiong Y
In-Reply-To: <20161109160219.GB9111@kroah.com>

On Wed, Nov 9 2016, 06:02 PM, Greg KH wrote:
> On Wed, Nov 09, 2016 at 04:20:00PM +0200, Amir Levy wrote:
> > This driver enables Thunderbolt Networking on non-Apple platforms
> > running Linux.
> >
> > Thunderbolt Networking provides peer-to-peer connections to transfer
> > files between computers, perform PC migrations, and/or set up small
> > workgroups with shared storage.
> >
> > This is a virtual connection that emulates an Ethernet adapter that
> > enables Ethernet networking with the benefit of Thunderbolt superfast
> > medium capability.
> >
> > Thunderbolt Networking enables two hosts and several devices that have
> > a Thunderbolt controller to be connected together in a linear (Daisy
> > chain) series from a single port.
> >
> > Thunderbolt Networking for Linux is compatible with Thunderbolt
> > Networking on systems running macOS or Windows and also supports
> > Thunderbolt generation 2 and 3 controllers.
> >
> > Note that all pre-existing Thunderbolt generation 3 features, such as
> > USB, Display and other Thunderbolt device connectivity will continue
> > to function exactly as they did prior to enabling Thunderbolt Networking.
> >
> > Code and Software Specifications:
> > This kernel code creates a virtual ethernet device for computer to
> > computer communication over a Thunderbolt cable.
> > The new driver is a separate driver to the existing Thunderbolt driver.
> > It is designed to work on systems running Linux that interface with
> > Intel Connection Manager (ICM) firmware based Thunderbolt controllers
> > that support Thunderbolt Networking.
> > The kernel code operates in coordination with the Thunderbolt user-
> > space daemon to implement full Thunderbolt networking functionality.
> >
> > Hardware Specifications:
> > Thunderbolt Hardware specs have not yet been published but are used
> > where necessary for register definitions.
> >
> > Acked-by: Andreas Noever <andreas.noever@gmail.com>
> > Tested-by: Mario Limonciello <mario.limonciello@dell.com>
> 
> This whole series is acked and tested by these people?  If so, why did you not
> include that in each patch?
> 

Will add in next patch set.

> And how about getting some internal-Intel kernel developers to review and
> sign-off on this code?  Don't make the community do the review when you
> have access to resources like this.  You have an internal mailing list for this
> very purpose, use it!
> 

The review with the internal-Intel kernel developers was done before submitting
the first patch set.
Version 9 that we have here isn't so different from Version 0.

> thanks,
> 
> greg k-h

^ permalink raw reply

* [mm PATCH v3 22/23] igb: Update driver to make use of DMA_ATTR_SKIP_CPU_SYNC
From: Alexander Duyck @ 2016-11-10 11:36 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: netdev, Jeff Kirsher, linux-kernel
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

The ARM architecture provides a mechanism for deferring cache line
invalidation in the case of map/unmap.  This patch makes use of this
mechanism to avoid unnecessary synchronization.

A secondary effect of this change is that the portion of the page that has
been synchronized for use by the CPU should be writable and could be passed
up the stack (at least on ARM).

The last bit that occurred to me is that on architectures where the
sync_for_cpu call invalidates cache lines we were prefetching and then
invalidating the first 128 bytes of the packet.  To avoid that I have moved
the sync up to before we perform the prefetch and allocate the skbuff so
that we can actually make use of it.

Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 drivers/net/ethernet/intel/igb/igb_main.c |   53 ++++++++++++++++++-----------
 1 file changed, 33 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 942a89f..ba97392 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3922,10 +3922,21 @@ static void igb_clean_rx_ring(struct igb_ring *rx_ring)
 		if (!buffer_info->page)
 			continue;
 
-		dma_unmap_page(rx_ring->dev,
-			       buffer_info->dma,
-			       PAGE_SIZE,
-			       DMA_FROM_DEVICE);
+		/* Invalidate cache lines that may have been written to by
+		 * device so that we avoid corrupting memory.
+		 */
+		dma_sync_single_range_for_cpu(rx_ring->dev,
+					      buffer_info->dma,
+					      buffer_info->page_offset,
+					      IGB_RX_BUFSZ,
+					      DMA_FROM_DEVICE);
+
+		/* free resources associated with mapping */
+		dma_unmap_page_attrs(rx_ring->dev,
+				     buffer_info->dma,
+				     PAGE_SIZE,
+				     DMA_FROM_DEVICE,
+				     DMA_ATTR_SKIP_CPU_SYNC);
 		__free_page(buffer_info->page);
 
 		buffer_info->page = NULL;
@@ -6791,12 +6802,6 @@ static void igb_reuse_rx_page(struct igb_ring *rx_ring,
 
 	/* transfer page from old buffer to new buffer */
 	*new_buff = *old_buff;
-
-	/* sync the buffer for use by the device */
-	dma_sync_single_range_for_device(rx_ring->dev, old_buff->dma,
-					 old_buff->page_offset,
-					 IGB_RX_BUFSZ,
-					 DMA_FROM_DEVICE);
 }
 
 static inline bool igb_page_is_reserved(struct page *page)
@@ -6917,6 +6922,13 @@ static struct sk_buff *igb_fetch_rx_buffer(struct igb_ring *rx_ring,
 	page = rx_buffer->page;
 	prefetchw(page);
 
+	/* we are reusing so sync this buffer for CPU use */
+	dma_sync_single_range_for_cpu(rx_ring->dev,
+				      rx_buffer->dma,
+				      rx_buffer->page_offset,
+				      size,
+				      DMA_FROM_DEVICE);
+
 	if (likely(!skb)) {
 		void *page_addr = page_address(page) +
 				  rx_buffer->page_offset;
@@ -6941,21 +6953,15 @@ static struct sk_buff *igb_fetch_rx_buffer(struct igb_ring *rx_ring,
 		prefetchw(skb->data);
 	}
 
-	/* we are reusing so sync this buffer for CPU use */
-	dma_sync_single_range_for_cpu(rx_ring->dev,
-				      rx_buffer->dma,
-				      rx_buffer->page_offset,
-				      size,
-				      DMA_FROM_DEVICE);
-
 	/* pull page into skb */
 	if (igb_add_rx_frag(rx_ring, rx_buffer, size, rx_desc, skb)) {
 		/* hand second half of page back to the ring */
 		igb_reuse_rx_page(rx_ring, rx_buffer);
 	} else {
 		/* we are not reusing the buffer so unmap it */
-		dma_unmap_page(rx_ring->dev, rx_buffer->dma,
-			       PAGE_SIZE, DMA_FROM_DEVICE);
+		dma_unmap_page_attrs(rx_ring->dev, rx_buffer->dma,
+				     PAGE_SIZE, DMA_FROM_DEVICE,
+				     DMA_ATTR_SKIP_CPU_SYNC);
 	}
 
 	/* clear contents of rx_buffer */
@@ -7213,7 +7219,8 @@ static bool igb_alloc_mapped_page(struct igb_ring *rx_ring,
 	}
 
 	/* map page for use */
-	dma = dma_map_page(rx_ring->dev, page, 0, PAGE_SIZE, DMA_FROM_DEVICE);
+	dma = dma_map_page_attrs(rx_ring->dev, page, 0, PAGE_SIZE,
+				 DMA_FROM_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
 
 	/* if mapping failed free memory back to system since
 	 * there isn't much point in holding memory we can't use
@@ -7254,6 +7261,12 @@ void igb_alloc_rx_buffers(struct igb_ring *rx_ring, u16 cleaned_count)
 		if (!igb_alloc_mapped_page(rx_ring, bi))
 			break;
 
+		/* sync the buffer for use by the device */
+		dma_sync_single_range_for_device(rx_ring->dev, bi->dma,
+						 bi->page_offset,
+						 IGB_RX_BUFSZ,
+						 DMA_FROM_DEVICE);
+
 		/* Refresh the desc even if buffer_addrs didn't change
 		 * because each write-back erases this info.
 		 */

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 21/23] mm: Add support for releasing multiple instances of a page
From: Alexander Duyck @ 2016-11-10 11:36 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: netdev, linux-kernel
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This patch adds a function that allows us to batch free a page that has
multiple references outstanding.  Specifically this function can be used to
drop a page being used in the page frag alloc cache.  With this drivers can
make use of functionality similar to the page frag alloc cache without
having to do any workarounds for the fact that there is no function that
frees multiple references.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 include/linux/gfp.h |    2 ++
 mm/page_alloc.c     |   14 ++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index f8041f9de..4175dca 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -506,6 +506,8 @@ extern void free_hot_cold_page(struct page *page, bool cold);
 extern void free_hot_cold_page_list(struct list_head *list, bool cold);
 
 struct page_frag_cache;
+extern void __page_frag_drain(struct page *page, unsigned int order,
+			      unsigned int count);
 extern void *__alloc_page_frag(struct page_frag_cache *nc,
 			       unsigned int fragsz, gfp_t gfp_mask);
 extern void __free_page_frag(void *addr);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0fbfead..54fea40 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3912,6 +3912,20 @@ static struct page *__page_frag_refill(struct page_frag_cache *nc,
 	return page;
 }
 
+void __page_frag_drain(struct page *page, unsigned int order,
+		       unsigned int count)
+{
+	VM_BUG_ON_PAGE(page_ref_count(page) == 0, page);
+
+	if (page_ref_sub_and_test(page, count)) {
+		if (order == 0)
+			free_hot_cold_page(page, false);
+		else
+			__free_pages_ok(page, order);
+	}
+}
+EXPORT_SYMBOL(__page_frag_drain);
+
 void *__alloc_page_frag(struct page_frag_cache *nc,
 			unsigned int fragsz, gfp_t gfp_mask)
 {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 20/23] dma: Add calls for dma_map_page_attrs and dma_unmap_page_attrs
From: Alexander Duyck @ 2016-11-10 11:36 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: netdev, linux-kernel
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

Add support for mapping and unmapping a page with attributes.  The primary
use for this is currently to allow for us to pass the
DMA_ATTR_SKIP_CPU_SYNC attribute when mapping and unmapping a page.  On
some architectures such as ARM the synchronization has significant overhead
and if we are already taking care of the sync_for_cpu and sync_for_device
from the driver there isn't much need to handle this in the map/unmap calls
as well.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 include/linux/dma-mapping.h |   20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 15400b4..2520a1d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -237,29 +237,33 @@ static inline void dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sg
 		ops->unmap_sg(dev, sg, nents, dir, attrs);
 }
 
-static inline dma_addr_t dma_map_page(struct device *dev, struct page *page,
-				      size_t offset, size_t size,
-				      enum dma_data_direction dir)
+static inline dma_addr_t dma_map_page_attrs(struct device *dev,
+					    struct page *page,
+					    size_t offset, size_t size,
+					    enum dma_data_direction dir,
+					    unsigned long attrs)
 {
 	struct dma_map_ops *ops = get_dma_ops(dev);
 	dma_addr_t addr;
 
 	kmemcheck_mark_initialized(page_address(page) + offset, size);
 	BUG_ON(!valid_dma_direction(dir));
-	addr = ops->map_page(dev, page, offset, size, dir, 0);
+	addr = ops->map_page(dev, page, offset, size, dir, attrs);
 	debug_dma_map_page(dev, page, offset, size, dir, addr, false);
 
 	return addr;
 }
 
-static inline void dma_unmap_page(struct device *dev, dma_addr_t addr,
-				  size_t size, enum dma_data_direction dir)
+static inline void dma_unmap_page_attrs(struct device *dev,
+					dma_addr_t addr, size_t size,
+					enum dma_data_direction dir,
+					unsigned long attrs)
 {
 	struct dma_map_ops *ops = get_dma_ops(dev);
 
 	BUG_ON(!valid_dma_direction(dir));
 	if (ops->unmap_page)
-		ops->unmap_page(dev, addr, size, dir, 0);
+		ops->unmap_page(dev, addr, size, dir, attrs);
 	debug_dma_unmap_page(dev, addr, size, dir, false);
 }
 
@@ -344,6 +348,8 @@ dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
 #define dma_unmap_single(d, a, s, r) dma_unmap_single_attrs(d, a, s, r, 0)
 #define dma_map_sg(d, s, n, r) dma_map_sg_attrs(d, s, n, r, 0)
 #define dma_unmap_sg(d, s, n, r) dma_unmap_sg_attrs(d, s, n, r, 0)
+#define dma_map_page(d, p, o, s, r) dma_map_page_attrs(d, p, o, s, r, 0)
+#define dma_unmap_page(d, a, s, r) dma_unmap_page_attrs(d, a, s, r, 0)
 
 extern int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
 			   void *cpu_addr, dma_addr_t dma_addr, size_t size);

^ permalink raw reply related

* [mm PATCH v3 19/23] arch/xtensa: Add option to skip DMA sync as a part of mapping
From: Alexander Duyck @ 2016-11-10 11:35 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: Max Filippov, linux-kernel, netdev
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.

Cc: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 arch/xtensa/kernel/pci-dma.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/xtensa/kernel/pci-dma.c b/arch/xtensa/kernel/pci-dma.c
index 1e68806..6a16dec 100644
--- a/arch/xtensa/kernel/pci-dma.c
+++ b/arch/xtensa/kernel/pci-dma.c
@@ -189,7 +189,9 @@ static dma_addr_t xtensa_map_page(struct device *dev, struct page *page,
 {
 	dma_addr_t dma_handle = page_to_phys(page) + offset;
 
-	xtensa_sync_single_for_device(dev, dma_handle, size, dir);
+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+		xtensa_sync_single_for_device(dev, dma_handle, size, dir);
+
 	return dma_handle;
 }
 
@@ -197,7 +199,8 @@ static void xtensa_unmap_page(struct device *dev, dma_addr_t dma_handle,
 			      size_t size, enum dma_data_direction dir,
 			      unsigned long attrs)
 {
-	xtensa_sync_single_for_cpu(dev, dma_handle, size, dir);
+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+		xtensa_sync_single_for_cpu(dev, dma_handle, size, dir);
 }
 
 static int xtensa_map_sg(struct device *dev, struct scatterlist *sg,

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 18/23] arch/tile: Add option to skip DMA sync as a part of map and unmap
From: Alexander Duyck @ 2016-11-10 11:35 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: netdev, Chris Metcalf, linux-kernel
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.

Cc: Chris Metcalf <cmetcalf@mellanox.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 arch/tile/kernel/pci-dma.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/tile/kernel/pci-dma.c b/arch/tile/kernel/pci-dma.c
index 09bb774..24e0f8c 100644
--- a/arch/tile/kernel/pci-dma.c
+++ b/arch/tile/kernel/pci-dma.c
@@ -213,10 +213,12 @@ static int tile_dma_map_sg(struct device *dev, struct scatterlist *sglist,
 
 	for_each_sg(sglist, sg, nents, i) {
 		sg->dma_address = sg_phys(sg);
-		__dma_prep_pa_range(sg->dma_address, sg->length, direction);
 #ifdef CONFIG_NEED_SG_DMA_LENGTH
 		sg->dma_length = sg->length;
 #endif
+		if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+			continue;
+		__dma_prep_pa_range(sg->dma_address, sg->length, direction);
 	}
 
 	return nents;
@@ -232,6 +234,8 @@ static void tile_dma_unmap_sg(struct device *dev, struct scatterlist *sglist,
 	BUG_ON(!valid_dma_direction(direction));
 	for_each_sg(sglist, sg, nents, i) {
 		sg->dma_address = sg_phys(sg);
+		if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+			continue;
 		__dma_complete_pa_range(sg->dma_address, sg->length,
 					direction);
 	}
@@ -245,7 +249,8 @@ static dma_addr_t tile_dma_map_page(struct device *dev, struct page *page,
 	BUG_ON(!valid_dma_direction(direction));
 
 	BUG_ON(offset + size > PAGE_SIZE);
-	__dma_prep_page(page, offset, size, direction);
+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+		__dma_prep_page(page, offset, size, direction);
 
 	return page_to_pa(page) + offset;
 }
@@ -256,6 +261,9 @@ static void tile_dma_unmap_page(struct device *dev, dma_addr_t dma_address,
 {
 	BUG_ON(!valid_dma_direction(direction));
 
+	if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+		return;
+
 	__dma_complete_page(pfn_to_page(PFN_DOWN(dma_address)),
 			    dma_address & (PAGE_SIZE - 1), size, direction);
 }

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 17/23] arch/sparc: Add option to skip DMA sync as a part of map and unmap
From: Alexander Duyck @ 2016-11-10 11:35 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: sparclinux, netdev, David S. Miller, linux-kernel
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.

Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 arch/sparc/kernel/iommu.c  |    4 ++--
 arch/sparc/kernel/ioport.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c
index 5c615ab..8fda4e4 100644
--- a/arch/sparc/kernel/iommu.c
+++ b/arch/sparc/kernel/iommu.c
@@ -415,7 +415,7 @@ static void dma_4u_unmap_page(struct device *dev, dma_addr_t bus_addr,
 		ctx = (iopte_val(*base) & IOPTE_CONTEXT) >> 47UL;
 
 	/* Step 1: Kick data out of streaming buffers if necessary. */
-	if (strbuf->strbuf_enabled)
+	if (strbuf->strbuf_enabled && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
 		strbuf_flush(strbuf, iommu, bus_addr, ctx,
 			     npages, direction);
 
@@ -640,7 +640,7 @@ static void dma_4u_unmap_sg(struct device *dev, struct scatterlist *sglist,
 		base = iommu->page_table + entry;
 
 		dma_handle &= IO_PAGE_MASK;
-		if (strbuf->strbuf_enabled)
+		if (strbuf->strbuf_enabled && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
 			strbuf_flush(strbuf, iommu, dma_handle, ctx,
 				     npages, direction);
 
diff --git a/arch/sparc/kernel/ioport.c b/arch/sparc/kernel/ioport.c
index 2344103..6ffaec4 100644
--- a/arch/sparc/kernel/ioport.c
+++ b/arch/sparc/kernel/ioport.c
@@ -527,7 +527,7 @@ static dma_addr_t pci32_map_page(struct device *dev, struct page *page,
 static void pci32_unmap_page(struct device *dev, dma_addr_t ba, size_t size,
 			     enum dma_data_direction dir, unsigned long attrs)
 {
-	if (dir != PCI_DMA_TODEVICE)
+	if (dir != PCI_DMA_TODEVICE && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
 		dma_make_coherent(ba, PAGE_ALIGN(size));
 }
 
@@ -572,7 +572,7 @@ static void pci32_unmap_sg(struct device *dev, struct scatterlist *sgl,
 	struct scatterlist *sg;
 	int n;
 
-	if (dir != PCI_DMA_TODEVICE) {
+	if (dir != PCI_DMA_TODEVICE && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) {
 		for_each_sg(sgl, sg, nents, n) {
 			dma_make_coherent(sg_phys(sg), PAGE_ALIGN(sg->length));
 		}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 16/23] arch/sh: Add option to skip DMA sync as a part of mapping
From: Alexander Duyck @ 2016-11-10 11:35 UTC (permalink / raw)
  To: linux-mm, akpm
  Cc: netdev, Rich Felker, linux-kernel, Yoshinori Sato, linux-sh
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.

Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 arch/sh/kernel/dma-nommu.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/sh/kernel/dma-nommu.c b/arch/sh/kernel/dma-nommu.c
index eadb669..47fee3b 100644
--- a/arch/sh/kernel/dma-nommu.c
+++ b/arch/sh/kernel/dma-nommu.c
@@ -18,7 +18,9 @@ static dma_addr_t nommu_map_page(struct device *dev, struct page *page,
 	dma_addr_t addr = page_to_phys(page) + offset;
 
 	WARN_ON(size == 0);
-	dma_cache_sync(dev, page_address(page) + offset, size, dir);
+
+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+		dma_cache_sync(dev, page_address(page) + offset, size, dir);
 
 	return addr;
 }
@@ -35,7 +37,8 @@ static int nommu_map_sg(struct device *dev, struct scatterlist *sg,
 	for_each_sg(sg, s, nents, i) {
 		BUG_ON(!sg_page(s));
 
-		dma_cache_sync(dev, sg_virt(s), s->length, dir);
+		if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+			dma_cache_sync(dev, sg_virt(s), s->length, dir);
 
 		s->dma_address = sg_phys(s);
 		s->dma_length = s->length;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 15/23] arch/powerpc: Add option to skip DMA sync as a part of mapping
From: Alexander Duyck @ 2016-11-10 11:35 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: Michael Ellerman, linux-kernel, netdev
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.

Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 arch/powerpc/kernel/dma.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index e64a601..6877e3f 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -203,6 +203,10 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
 	for_each_sg(sgl, sg, nents, i) {
 		sg->dma_address = sg_phys(sg) + get_dma_offset(dev);
 		sg->dma_length = sg->length;
+
+		if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+			continue;
+
 		__dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
 	}
 
@@ -235,7 +239,10 @@ static inline dma_addr_t dma_direct_map_page(struct device *dev,
 					     unsigned long attrs)
 {
 	BUG_ON(dir == DMA_NONE);
-	__dma_sync_page(page, offset, size, dir);
+
+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+		__dma_sync_page(page, offset, size, dir);
+
 	return page_to_phys(page) + offset + get_dma_offset(dev);
 }
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 14/23] arch/parisc: Add option to skip DMA sync as a part of map and unmap
From: Alexander Duyck @ 2016-11-10 11:35 UTC (permalink / raw)
  To: linux-mm, akpm
  Cc: netdev, Helge Deller, James E.J. Bottomley, linux-parisc,
	linux-kernel
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.

Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 arch/parisc/kernel/pci-dma.c |   20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index 02d9ed0..be55ede 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -459,7 +459,9 @@ static dma_addr_t pa11_dma_map_page(struct device *dev, struct page *page,
 	void *addr = page_address(page) + offset;
 	BUG_ON(direction == DMA_NONE);
 
-	flush_kernel_dcache_range((unsigned long) addr, size);
+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+		flush_kernel_dcache_range((unsigned long) addr, size);
+
 	return virt_to_phys(addr);
 }
 
@@ -469,8 +471,11 @@ static void pa11_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
 {
 	BUG_ON(direction == DMA_NONE);
 
+	if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+		return;
+
 	if (direction == DMA_TO_DEVICE)
-	    return;
+		return;
 
 	/*
 	 * For PCI_DMA_FROMDEVICE this flush is not necessary for the
@@ -479,7 +484,6 @@ static void pa11_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
 	 */
 
 	flush_kernel_dcache_range((unsigned long) phys_to_virt(dma_handle), size);
-	return;
 }
 
 static int pa11_dma_map_sg(struct device *dev, struct scatterlist *sglist,
@@ -496,6 +500,10 @@ static int pa11_dma_map_sg(struct device *dev, struct scatterlist *sglist,
 
 		sg_dma_address(sg) = (dma_addr_t) virt_to_phys(vaddr);
 		sg_dma_len(sg) = sg->length;
+
+		if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+			continue;
+
 		flush_kernel_dcache_range(vaddr, sg->length);
 	}
 	return nents;
@@ -510,14 +518,16 @@ static void pa11_dma_unmap_sg(struct device *dev, struct scatterlist *sglist,
 
 	BUG_ON(direction == DMA_NONE);
 
+	if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+		return;
+
 	if (direction == DMA_TO_DEVICE)
-	    return;
+		return;
 
 	/* once we do combining we'll need to use phys_to_virt(sg_dma_address(sglist)) */
 
 	for_each_sg(sglist, sg, nents, i)
 		flush_kernel_vmap_range(sg_virt(sg), sg->length);
-	return;
 }
 
 static void pa11_dma_sync_single_for_cpu(struct device *dev,

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 13/23] arch/openrisc: Add option to skip DMA sync as a part of mapping
From: Alexander Duyck @ 2016-11-10 11:35 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: Jonas Bonn, netdev, linux-kernel
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.

Cc: Jonas Bonn <jonas@southpole.se>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 arch/openrisc/kernel/dma.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/openrisc/kernel/dma.c b/arch/openrisc/kernel/dma.c
index 140c991..906998b 100644
--- a/arch/openrisc/kernel/dma.c
+++ b/arch/openrisc/kernel/dma.c
@@ -141,6 +141,9 @@ or1k_map_page(struct device *dev, struct page *page,
 	unsigned long cl;
 	dma_addr_t addr = page_to_phys(page) + offset;
 
+	if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+		return addr;
+
 	switch (dir) {
 	case DMA_TO_DEVICE:
 		/* Flush the dcache for the requested range */

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [mm PATCH v3 12/23] arch/nios2: Add option to skip DMA sync as a part of map and unmap
From: Alexander Duyck @ 2016-11-10 11:35 UTC (permalink / raw)
  To: linux-mm, akpm; +Cc: Ley Foon Tan, linux-kernel, netdev
In-Reply-To: <20161110113027.76501.63030.stgit@ahduyck-blue-test.jf.intel.com>

This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
avoid invoking cache line invalidation if the driver will just handle it
via a sync_for_cpu or sync_for_device call.

Cc: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 arch/nios2/mm/dma-mapping.c |   26 ++++++++++++++++++--------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch/nios2/mm/dma-mapping.c b/arch/nios2/mm/dma-mapping.c
index d800fad..f6a5dcf 100644
--- a/arch/nios2/mm/dma-mapping.c
+++ b/arch/nios2/mm/dma-mapping.c
@@ -98,13 +98,17 @@ static int nios2_dma_map_sg(struct device *dev, struct scatterlist *sg,
 	int i;
 
 	for_each_sg(sg, sg, nents, i) {
-		void *addr;
+		void *addr = sg_virt(sg);
 
-		addr = sg_virt(sg);
-		if (addr) {
-			__dma_sync_for_device(addr, sg->length, direction);
-			sg->dma_address = sg_phys(sg);
-		}
+		if (!addr)
+			continue;
+
+		sg->dma_address = sg_phys(sg);
+
+		if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+			continue;
+
+		__dma_sync_for_device(addr, sg->length, direction);
 	}
 
 	return nents;
@@ -117,7 +121,9 @@ static dma_addr_t nios2_dma_map_page(struct device *dev, struct page *page,
 {
 	void *addr = page_address(page) + offset;
 
-	__dma_sync_for_device(addr, size, direction);
+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+		__dma_sync_for_device(addr, size, direction);
+
 	return page_to_phys(page) + offset;
 }
 
@@ -125,7 +131,8 @@ static void nios2_dma_unmap_page(struct device *dev, dma_addr_t dma_address,
 		size_t size, enum dma_data_direction direction,
 		unsigned long attrs)
 {
-	__dma_sync_for_cpu(phys_to_virt(dma_address), size, direction);
+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+		__dma_sync_for_cpu(phys_to_virt(dma_address), size, direction);
 }
 
 static void nios2_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
@@ -138,6 +145,9 @@ static void nios2_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
 	if (direction == DMA_TO_DEVICE)
 		return;
 
+	if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
+		return;
+
 	for_each_sg(sg, sg, nhwentries, i) {
 		addr = sg_virt(sg);
 		if (addr)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related


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