Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On Wed, 6 Sep 2017 02:47:03 +0200 Andrew Lunn wrote: > > The third and last issue will be explained in a followup email. > > Hi DSA hackers > > So there is the third issue. It affects just DSA, but it possible > affects all DSA drivers. > > This patchset broken broadcast

[net-next:master 491/511] xt_hashlimit.c:undefined reference to `__aeabi_uldivmod'

Hi Arnd, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 66bed8465a808400eb14562510e26c8818082cb8 commit: 2c08ab3f2504bc7ba816ce6fde051b8bd5f028e4 [491/511] soc: ti/knav_dma: include dmaengine

[PATCH net-next] xdp: implement xdp_redirect_map for generic XDP

Using bpf_redirect_map is allowed for generic XDP programs, but the appropriate map lookup was never performed in xdp_do_generic_redirect(). Instead the map-index is directly used as the ifindex. For the xdp_redirect_map sample in SKB-mode '-S', this resulted in trying sending on ifindex 0 which

Re: [iproute PATCH 1/6] utils: Implement strlcpy() and strlcat()

On Wed, 6 Sep 2017 13:59:27 + David Laight wrote: > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: 04 September 2017 19:25 > > On Mon, 4 Sep 2017 17:00:15 +0200 > > Phil Sutter wrote: > > > > > On Mon, Sep 04, 2017 at

Re: [PATCH 6/10] ixgbe: Use ARRAY_SIZE macro

On Wed, 2017-09-06 at 11:08 +0200, Thomas Meyer wrote: > On Tue, Sep 05, 2017 at 02:22:05PM -0700, David Miller wrote: > > nothing prevented you from CC:'ing the maintainer, > > Jeff Kirscher. [] > That's the other condition in my script. I only send to the role > "maintainer" from the output of

[PATCH net-next 0/1] netvsc hot plug fix

This is one fix for problems with hot add of network device on Windows Server. Stephen Hemminger (1): hv_netvsc: fix deadlock on hotplug drivers/net/hyperv/hyperv_net.h | 1 + drivers/net/hyperv/netvsc_drv.c | 8 +-- drivers/net/hyperv/rndis_filter.c | 106

[PATCH net-next 1/1] hv_netvsc: fix deadlock on hotplug

When a virtual device is added dynamically (via host console), then the vmbus sends an offer message for the primary channel. The processing of this message for networking causes the network device to then initialize the sub channels. The problem is that setting up the sub channels needs to wait

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On Wed, Sep 06, 2017 at 04:46:51PM +0200, Matthias May wrote: > > Hi Andrew > We are using the 88E6321. > In our setup we are using openvswitch and not a bridge, however the problem > you describe seems to be the same. > > We had to configure the switch to flood unknown multicast (Egress Floods

Re: hung task in mac80211

On Wed, 2017-09-06 at 17:04 +0200, Matteo Croce wrote: > > I confirm that this patch fixes the hang too. Cool, I'll go apply it. > I'm curious to see if there are noticeable performance differences > between the two solutions. Nope, you hit this code path essentially once. johannes

[PATCH 0/2] 9p: Fixes for hard-to-hit bugs

These two patches fix two hard-to-hit (but really annoying) bugs in 9p. The first one was posted earlier in February (with one R-b), the second is a new one. Both of these have had soaking in NixOS distribution kernels for a couple of months with no ill effects. Tuomas Tynkkynen (2): fs/9p:

[PATCH 2/2] net/9p: Switch to wait_event_killable()

Because userspace gets Very Unhappy when calls like stat() and execve() return -EINTR on 9p filesystem mounts. For instance, when bash is looking in PATH for things to execute and some SIGCHLD interrupts stat(), bash can throw a spurious 'command not found' since it doesn't retry the stat(). In

[PATCH 1/2] fs/9p: Compare qid.path in v9fs_test_inode

Commit fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.") transformed v9fs_qid_iget() to use iget5_locked() instead of iget_locked(). However, the test() callback is not checking fid.path at all, which means that a lookup in the inode cache can now

Re: [PATCH v2 rfc 8/8] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID

> > Use the MAC address of the master interface as the parent ID. This is > > the same for all switches in a cluster, and should be unique if there > > are multiple clusters. > > That is not correct. Support for multiple CPU ports is coming and in > this case, you can have two CPU host interfaces

Re: hung task in mac80211

On Wed, Sep 6, 2017 at 2:58 PM, Johannes Berg wrote: > On Wed, 2017-09-06 at 13:57 +0200, Matteo Croce wrote: > >> I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. >> The problem is present both on my AP and on my notebook, >> so it seems it affects

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 21:18, Florian Fainelli wrote: On 08/31/2017 12:09 PM, Mason wrote: 1) nb8800_link_reconfigure() calls phy_print_status() which prints the "Link down" and "Link up" messages to the console. With the patch reverted, nothing is printed when the link goes down, and the result is

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On 06/09/17 02:47, Andrew Lunn wrote: >> The third and last issue will be explained in a followup email. > > Hi DSA hackers > > So there is the third issue. It affects just DSA, but it possible > affects all DSA drivers. > > This patchset broken broadcast with the Marvell drivers. It could >

Re: [PATCH v2 rfc 8/8] net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID

Hi Andrew, Andrew Lunn writes: > SWITCHDEV_ATTR_ID_PORT_PARENT_ID is used by the software bridge when > determining which ports to flood a packet out. If the packet > originated from a switch, it assumes the switch has already flooded > the packet out the switches ports, so the

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 20:29, Florian Fainelli wrote: On 08/31/2017 11:12 AM, Mason wrote: On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: On 31/08/2017 18:57, Florian Fainelli wrote: And the race is between phy_detach() setting phydev->attached_dev = NULL and

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

Hi Andrew, Andrew Lunn writes: > Getting the frames to the bridge as requested turned up an issue or > three. The offload_fwd_mark is not being set by DSA, so the bridge > floods the received frames back to the switch ports, resulting in > duplication since the hardware has

Re: hung task in mac80211

On Wed, 2017-09-06 at 16:27 +0200, Stefano Brivio wrote: > > Sorry for the extended bothering :) but here, you're extending quite > a bit the scope of the lock also > when__ieee80211_start_rx_ba_session() is called by > ieee80211_process_addba_request(). I know, but it doesn't matter. > No idea

Re: hung task in mac80211

On Wed, 06 Sep 2017 14:58:48 +0200 Johannes Berg wrote: > +void __ieee80211_start_rx_ba_session(struct sta_info *sta, > + u8 dialog_token, u16 timeout, > + u16 start_seq_num, u16 ba_policy, u16 tid, > +

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On 06/09/17 02:47, Andrew Lunn wrote: Should this be done at the DSA level, or at the driver level? Do any chips do broadcast flooding in hardware already? Hence they currently see broadcast duplication? If i add a broadcast mdb at the DSA level, and the chip is already hard wired to flooding

Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode

On Wed, Sep 6, 2017 at 12:24 AM, Jiri Pirko wrote: > Wed, Sep 06, 2017 at 06:04:17AM CEST, ro...@cumulusnetworks.com wrote: >>On Tue, Sep 5, 2017 at 3:45 PM, Daniel Borkmann wrote: >>> On 09/06/2017 12:01 AM, Roopa Prabhu wrote: On Tue, Sep 5,

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

> > What i found is that the Marvell chips don't flood broadcast frames > > between bridged ports. What appears to happen is there is a fdb miss, > > so it gets forwarded to the CPU port for the host to deal with. The > > software bridge when floods it out all ports of the bridge. > > Do you have

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

> On Aug 31, 2017, at 1:54 PM, Stefan Hajnoczi wrote: > > On Tue, Aug 29, 2017 at 03:37:07PM +, Jorgen S. Hansen wrote: >>> On Aug 29, 2017, at 4:36 AM, Dexuan Cui wrote: >> If we allow multiple host side transports, virtio host side support and >>

Re: [PATCH net 3/4] lan78xx: Fix for eeprom read/write when device autosuspend

Hi Nisar > + else if ((ee->magic == LAN78XX_EEPROM_MAGIC) && > + (ee->offset >= 0 && ee->offset < MAX_EEPROM_SIZE) && > + (ee->len > 0 && (ee->offset + ee->len) <= MAX_EEPROM_SIZE)) > + ret = lan78xx_write_raw_eeprom(dev, ee->offset, ee->len, data); This

Re: [PATCH net 2/4] lan78xx: Add fixed_phy device support for LAN7801 device

On Wed, Sep 06, 2017 at 10:51:44AM +, nisar.sa...@microchip.com wrote: > From: Nisar Sayed > > Add fixed_phy device support for LAN7801 device > > When LAN7801 device connected to PHY Device which does not have > MDIO/MDC access, fixex_phy device will be added.

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

Hi Andrew, Andrew Lunn writes: > So there is the third issue. It affects just DSA, but it possible > affects all DSA drivers. > > This patchset broken broadcast with the Marvell drivers. It could > break broadcast on others drivers as well. > > What i found is that the Marvell

Re: [PATCH net 1/4] lan78xx: Fix for crash associated with System suspend

On Wed, Sep 06, 2017 at 10:51:31AM +, nisar.sa...@microchip.com wrote: > From: Nisar Sayed > > Fix for crash associated with System suspend > > Since ndo_stop removes phydev which makes phydev NULL. > Whenever system suspend is initiated or after "ifconfig down",

RE: [iproute PATCH 1/6] utils: Implement strlcpy() and strlcat()

From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: 04 September 2017 19:25 > On Mon, 4 Sep 2017 17:00:15 +0200 > Phil Sutter wrote: > > > On Mon, Sep 04, 2017 at 02:49:20PM +, David Laight wrote: > > > From: Phil Sutter > > > > Sent: 01 September 2017 17:53 > >

[PATCH] isdn: isdnloop: fix logic error in isdnloop_sendbuf

gcc-7 found an ancient bug in the loop driver, leading to a condition that is always false, meaning we ignore the contents of 'card->flags' here: drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in boolean context, the expression will always evaluate to 'true'

Re: hung task in mac80211

On Wed, 06 Sep 2017 15:30:10 +0200 Johannes Berg wrote: > So for example replacing the loop of tid = 0..NUM_TIDS-1 with a > list_for_each_entry() would already be unsafe with the dropping if the > list were to require the mutex for locking. Sure. Still, it would need

Re: hung task in mac80211

On Wed, 2017-09-06 at 15:27 +0200, Stefano Brivio wrote: > > Yes, that was based on the assumption that the initial part of > __ieee80211_start_rx_ba_session() can't really affect the AMPDU > state-machine in any way. That's not really the point, if that changes that function would have to move

Re: hung task in mac80211

On Wed, 2017-09-06 at 15:19 +0200, Stefano Brivio wrote: > On Wed, 06 Sep 2017 14:48:35 +0200 > Johannes Berg wrote: > > > I'll look in a bit - but > > > > > + mutex_unlock(>ampdu_mlme.mtx); > > >   ___ieee80211_stop_rx_ba_session( > >

Re: hung task in mac80211

On Wed, 06 Sep 2017 15:21:00 +0200 Johannes Berg wrote: > On Wed, 2017-09-06 at 15:19 +0200, Stefano Brivio wrote: > > On Wed, 06 Sep 2017 14:48:35 +0200 > > Johannes Berg wrote: > > > > > I'll look in a bit - but > > > > > > > +

Re: hung task in mac80211

Am 06.09.2017 um 15:03 schrieb Johannes Berg: On Wed, 2017-09-06 at 14:48 +0200, Johannes Berg wrote: I'm surprised nobody saw this before - though perhaps Sebastian's useless report is the same. Oh, that's because this is only for the offloaded manager thing, and that's only ath10k. johannes

Re: hung task in mac80211

On Wed, 06 Sep 2017 14:48:35 +0200 Johannes Berg wrote: > I'll look in a bit - but > > > + mutex_unlock(>ampdu_mlme.mtx); > >   ___ieee80211_stop_rx_ba_session( > >   sta, tid, WLAN_BACK_RECIPIENT, > >  

Re: hung task in mac80211

On Wed, Sep 6, 2017 at 2:40 PM, Stefano Brivio wrote: > On Wed, 6 Sep 2017 13:57:47 +0200 > Matteo Croce wrote: > >> Hi, >> >> I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. >> The problem is present both on my AP and on my notebook, >>

Re: hung task in mac80211

On Wed, 2017-09-06 at 14:48 +0200, Johannes Berg wrote: > > I'm surprised nobody saw this before - though perhaps Sebastian's > useless report is the same. Oh, that's because this is only for the offloaded manager thing, and that's only ath10k. johannes

[PATCH] ath10: mark PM functions as __maybe_unused

When CONFIG_PM_SLEEP is disabled, we get a compile-time warning: drivers/net/wireless/ath/ath10k/pci.c:3417:12: error: 'ath10k_pci_pm_resume' defined but not used [-Werror=unused-function] static int ath10k_pci_pm_resume(struct device *dev) ^~~~

Re: hung task in mac80211

On Wed, 2017-09-06 at 13:57 +0200, Matteo Croce wrote: > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > > INFO: task kworker/u16:6:120

Re: [PATCH] tipc: remove unnecessary call to dev_net()

On 09/06/2017 05:08 PM, Kleber Sacilotto de Souza wrote: > The net device is already stored in the 'net' variable, so no need to call > dev_net() again. > > Signed-off-by: Kleber Sacilotto de Souza Acked-by: Ying Xue > --- >

Re: hung task in mac80211

I'll look in a bit - but > + mutex_unlock(>ampdu_mlme.mtx); >   ___ieee80211_stop_rx_ba_session( >   sta, tid, WLAN_BACK_RECIPIENT, >   WLAN_REASON_QSTA_TIMEOUT, true); This already has three

[PATCH net] udp: drop head states only when all skb references are gone

After commit 0ddf3fb2c43d ("udp: preserve skb->dst if required for IP options processing") we clear the skb head state as soon as the skb carrying them is first processed. Since the same skb can be processed several times when MSG_PEEK is used, we can end up lacking the required head states, and

Re: hung task in mac80211

On Wed, 6 Sep 2017 13:57:47 +0200 Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > >

Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree

On 6 September 2017 at 14:17, Greg Kroah-Hartman wrote: > On Wed, Sep 06, 2017 at 01:01:32PM +0200, Jonas Gorski wrote: >> Hi Greg, >> >> On 2 August 2017 at 11:34, Jonas Gorski wrote: >> > Codify using a named clock for the refclk of the uart.

Re: hung task in mac80211

On Wednesday, September 6, 2017 1:57:47 PM CEST Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > > INFO:

Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree

On Wed, Sep 06, 2017 at 01:01:32PM +0200, Jonas Gorski wrote: > Hi Greg, > > On 2 August 2017 at 11:34, Jonas Gorski wrote: > > Codify using a named clock for the refclk of the uart. This makes it > > easier if we might need to add a gating clock (like present on the > >

hung task in mac80211

Hi, I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. The problem is present both on my AP and on my notebook, so it seems it affects AP and STA mode as well. The generated messages are: INFO: task kworker/u16:6:120 blocked for more than 120 seconds. Not tainted 4.13.0

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

On Wed, Sep 06, 2017 at 04:03:29PM +0800, Hannes Frederic Sowa wrote: > "Yang, Yi" writes: > >> > >> > If you check GENEVE implementation, tun_metadata* can be set or matched > >> > as any other match field. > >> > >> Yes, I wrote that in my previous mail. I wonder why NSH

[patch net] net: sched: fix memleak for chain zero

From: Jiri Pirko There's a memleak happening for chain 0. The thing is, chain 0 needs to be always present, not created on demand. Therefore tcf_block_get upon creation of block calls the tcf_chain_create function directly. The chain is created with refcnt == 1, which is not

Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree

Hi Greg, On 2 August 2017 at 11:34, Jonas Gorski wrote: > Codify using a named clock for the refclk of the uart. This makes it > easier if we might need to add a gating clock (like present on the > BCM6345). > > Signed-off-by: Jonas Gorski Could

Re: [PATCH 6/8] bcm63xx_enet: just use "enet" as the clock name

Hi David, On 2 August 2017 at 11:34, Jonas Gorski wrote: > Now that we have the individual clocks available as "enet" we > don't need to rely on the device id for them anymore. > > Signed-off-by: Jonas Gorski Could I please get a (N)Ack so Ralf

[PATCH net 3/4] lan78xx: Fix for eeprom read/write when device autosuspend

From: Nisar Sayed Fix for eeprom read/write when device autosuspend Signed-off-by: Nisar Sayed --- drivers/net/usb/lan78xx.c | 26 ++ 1 file changed, 22 insertions(+), 4 deletions(-) diff --git

Re: [net 0/2][pull request] Intel Wired LAN Driver Updates 2017-09-05

On Tue, 5 Sep 2017 18:04:16 -0700 Jeff Kirsher wrote: > This series contains fixes for i40e only. > > These two patches fix an issue where our nvmupdate tool does not work on RHEL > 7.4 > and newer kernels, in fact, the use of the nvmupdate tool on newer kernels

[PATCH net 1/4] lan78xx: Fix for crash associated with System suspend

From: Nisar Sayed Fix for crash associated with System suspend Since ndo_stop removes phydev which makes phydev NULL. Whenever system suspend is initiated or after "ifconfig down", if set_wol or get_wol is triggered phydev is NULL leads system crash. Hence

[PATCH net 4/4] lan78xx: Use default value loaded from EEPROM/OTP when resetting the chip

From: Nisar Sayed Use default value loaded from EEPROM/OTP when resetting the chip Signed-off-by: Nisar Sayed --- drivers/net/usb/lan78xx.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/usb/lan78xx.c

[PATCH net 2/4] lan78xx: Add fixed_phy device support for LAN7801 device

From: Nisar Sayed Add fixed_phy device support for LAN7801 device When LAN7801 device connected to PHY Device which does not have MDIO/MDC access, fixex_phy device will be added. Signed-off-by: Nisar Sayed --- drivers/net/usb/Kconfig |

[PATCH net 0/4] lan78xx: Fixes and Enhancements to lan78xx driver

From: Nisar Sayed This series of patches are for lan78xx driver. These patches supports fixes and enhancements to lan78xx driver Nisar Sayed (4): Fix for crash associated with System suspend Add fixed_phy device support for LAN7801 device Fix for eeprom

Re: ipset losing entries on its own

On 2017-09-06 13:08, Akshat Kakkar wrote: I am having ipset 6.32 The hash type is hash:ip I am adding/deleting IP addresses to it dynamically using scripts. However, it has been observed that at times few IPs (3-4 out of 4000) are not found in the set though it was added. Also, logs show

Re: ipset losing entries on its own

output of ipset -L -t Name: STORE Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 50480 References: 1

Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode

On 06/09/17 01:45, Daniel Borkmann wrote: > On 09/06/2017 12:01 AM, Roopa Prabhu wrote: >> On Tue, Sep 5, 2017 at 11:18 AM, Cong Wang wrote: >>> On Tue, Sep 5, 2017 at 5:48 AM, Nikolay Aleksandrov >>> wrote: Hi all, This RFC adds a

ipset losing entries on its own

I am having ipset 6.32 The hash type is hash:ip I am adding/deleting IP addresses to it dynamically using scripts. However, it has been observed that at times few IPs (3-4 out of 4000) are not found in the set though it was added. Also, logs show there was not request for deletion of that IP

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

Jan Scheurich writes: >> > There is no way we can re-use the existing TLV tunnel metadata >> > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We >> > will need to introduce a new (perhaps similar) scheme for modelling >> > generic TLV match

RE: [PATCH net-next v6 3/3] openvswitch: enable NSH support

> > There is no way we can re-use the existing TLV tunnel metadata > > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We > > will need to introduce a new (perhaps similar) scheme for modelling > > generic TLV match registers in OVS that are assigned to protocol TLVs > > by the

Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On 06/09/17 03:11, Stephen Hemminger wrote: > On Wed, 6 Sep 2017 01:35:02 +0200 > Andrew Lunn wrote: > >> After the very useful feedback from Nikolay, i threw away what i had, >> and started again. To recap: >> >> The linux bridge supports IGMP snooping. It will listen to IGMP

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

Jan Scheurich writes: >> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata >> >> is not in tun_metadata as well? >> > >> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is >> > not so, NSH can't directly use tun_metadata,

Re: [PATCH net-next RFC 1/2] tun: enable NAPI for TUN/TAP driver

On Wed, Sep 6, 2017 at 12:51 AM, Stephen Hemminger wrote: > On Tue, 5 Sep 2017 15:35:50 -0700 > Petar Penkov wrote: > >> Changes TUN driver to use napi_gro_receive() upon receiving packets >> rather than netif_rx_ni(). Adds flag CONFIG_TUN_NAPI

Re: [PATCH] DSA support for Micrel KSZ8895

2017-08-31 0:32 GMT+03:00 : >> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote: >> > > I may be confused here, but AFAICT: >> > > >> > > 1) Yes, it has standard layout when accessed over MDIO. >> > >> > >> > Section 4.8 of the datasheet says: >> > >> > All the

[PATCH v13 1/5] block: DAC960: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin Tested-by: Peter Senna Tschudin

[PATCH v13 0/5] Replace PCI pool by DMA pool API

by the dma pool API and remove the defines. Changes in v13: - Rebased series onto next-20170906 - Added a new commit for the hinic ethernet driver - Remove previously merged patches Changes in v12: - Rebased series onto next-20170822 Changes in v11: - Rebased series onto next-20170809 - Removed

[PATCH v13 3/5] net: e100: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin Acked-by: Jeff Kirsher

[PATCH v13 5/5] PCI: Remove PCI pool macro functions

Now that all the drivers use dma pool API, we can remove the macro functions for PCI pool. Signed-off-by: Romain Perier Reviewed-by: Peter Senna Tschudin --- include/linux/pci.h | 9 - 1 file changed, 9 deletions(-) diff --git

[PATCH v13 2/5] dmaengine: pch_dma: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier Acked-by: Peter Senna Tschudin Tested-by: Peter Senna Tschudin

[PATCH v13 4/5] hinic: Replace PCI pool old API

The PCI pool API is deprecated. This commit replaces the PCI pool old API by the appropriate function with the DMA pool API. Signed-off-by: Romain Perier --- drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 10 +-

Re: [PATCH 6/10] ixgbe: Use ARRAY_SIZE macro

On Tue, Sep 05, 2017 at 02:22:05PM -0700, David Miller wrote: > From: Joe Perches > Date: Tue, 05 Sep 2017 13:01:18 -0700 > > > On Tue, 2017-09-05 at 21:45 +0200, Thomas Meyer wrote: > >> On Tue, Sep 05, 2017 at 11:50:44AM -0700, David Miller wrote: > >> > From: Thomas Meyer

[PATCH] tipc: remove unnecessary call to dev_net()

The net device is already stored in the 'net' variable, so no need to call dev_net() again. Signed-off-by: Kleber Sacilotto de Souza --- net/tipc/bearer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c index

Re: [PATCH net-next] net: cpsw: Don't handle SIOC[GS]HWTSTAMP when CPTS is disabled

On Tue, Sep 05, 2017 at 04:25:22PM -0500, Grygorii Strashko wrote: > I'd like to clarify one thing here - what is the preferable time-stamping > device: PHY over MAC, or MAC over PHY? > my understanding it's PHY and ethtool_get_ts_info() seems already implemented > this way. We simply do not

RE: hns3 use of pci_enable_msix_range

Hi Christoph, Thanks for bringing this into notice. I will change and send this patch in the next cycle after we have tested it internally. Best regards Salil > -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Friday, September 01, 2017 9:27 AM > To: Salil Mehta

RE: [PATCH net-next v6 3/3] openvswitch: enable NSH support

> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata > >> is not in tun_metadata as well? > > > > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is > > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a > > lot of rework on

[PATCH net 2/2] i40e: Avoid some useless variables and initializers in nvm functions

Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM update") Signed-off-by: Stefano Brivio --- drivers/net/ethernet/intel/i40e/i40e_nvm.c | 20 +++- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git

[PATCH net 1/2] i40e: Fix comment about locking for __i40e_read_nvm_word()

Caller needs to acquire the lock. Called functions will not. Fixes: 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM update") Signed-off-by: Stefano Brivio --- drivers/net/ethernet/intel/i40e/i40e_nvm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH net 0/2] i40e: Two trivial fixes for 09f79fd49d94

Two trivial fixes for recently introduced 09f79fd49d94 ("i40e: avoid NVM acquire deadlock during NVM update"): 1/2 fixes a comment about locking and 2/2 gets rid of two useless variables and one initializer in nvm functions. Stefano Brivio (2): i40e: Fix comment about locking for

Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support

"Yang, Yi" writes: > On Tue, Sep 05, 2017 at 09:12:09PM +0800, Hannes Frederic Sowa wrote: >> "Yang, Yi" writes: >> >> > We can change this later if we really find a better way to handle this >> > because it isn't defined in

Re: [Patch net] net_sched: fix a memory leak of filter chain

Wed, Sep 06, 2017 at 07:03:10AM CEST, xiyou.wangc...@gmail.com wrote: >tcf_chain_destroy() is called by tcf_block_put() and tcf_chain_put(). >tcf_chain_put() is refcn'ed and paired with tcf_chain_get(), >but tcf_block_put() is not, it should be paired with tcf_block_get() >and we still need to

Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode

Wed, Sep 06, 2017 at 06:04:17AM CEST, ro...@cumulusnetworks.com wrote: >On Tue, Sep 5, 2017 at 3:45 PM, Daniel Borkmann wrote: >> On 09/06/2017 12:01 AM, Roopa Prabhu wrote: >>> >>> On Tue, Sep 5, 2017 at 11:18 AM, Cong Wang >>> wrote: On

Re: [Intel-wired-lan] [PATCH net-next v3] e1000e: Be drop monitor friendly

On 8/26/2017 04:14, Florian Fainelli wrote: e1000e_put_txbuf() can be called from normal reclamation path as well as when a DMA mapping failure, so we need to differentiate these two cases when freeing SKBs to be drop monitor friendly. e1000e_tx_hwtstamp_work() and e1000_remove() are processing

Re: [PATCH v3 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md mode

> On 2017年9月6日, at 上午11:14, Alexei Starovoitov wrote: > > On 9/4/17 1:36 AM, Haishuang Yan wrote: >> In collect_md mode, if the tun dev is down, it still can call >> __ip6_tnl_rcv to receive on packets, and the rx statistics increase >> improperly. >> >> Fixes: 8d79266bc48c

<    1   2