* Re: [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: Or Gerlitz @ 2019-01-27 16:39 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz
In-Reply-To: <1548587196-10746-2-git-send-email-xiangxia.m.yue@gmail.com>
On Sun, Jan 27, 2019 at 1:06 PM <xiangxia.m.yue@gmail.com> wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> In some case, we may use multiple pedit actions to modify packets.
> The command shown as below: the last pedit action is effective.
> @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
> if (!parse_attr->mod_hdr_actions)
> return -ENOMEM;
>
> - parse_attr->num_mod_hdr_actions = max_actions;
> + parse_attr->max_mod_hdr_actions = max_actions;
> + parse_attr->num_mod_hdr_actions = 0;
why would we want to do this zeroing? what purpose does it serve?
On a probably related note, I suspect that the patch broke the caching
we do for modify header contexts, see mlx5e_attach_mod_hdr where we
look if a given set of modify header operations already has hw modify header
context and we use it.
To test that, put two tc rules with different matching but same set of
modify header
(pedit) actions and see that only one modify header context is used.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2019-01-27 17:02 UTC (permalink / raw)
To: David Miller; +Cc: Andrew Morton, Netdev, Linux List Kernel Mailing
In-Reply-To: <20190125.162151.302539235913379257.davem@davemloft.net>
On Fri, Jan 25, 2019 at 4:21 PM David Miller <davem@davemloft.net> wrote:
>
> This is a resend of the previous pull request with the qed changes
> reverted.
Thanks.
I'm trying to be a bit stricter about the rc pulls, even if I normally
don't even look at yours much.
So let's try to keep it to fixes only, or at least when you sneak in
new stuff, make them small enough that I don't go "Hmm.. That looks
odd.." ;)
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: pr-tracker-bot @ 2019-01-27 17:25 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20190125.162151.302539235913379257.davem@davemloft.net>
The pull request you sent on Fri, 25 Jan 2019 16:21:51 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/037222ad3f43a45c3a601dabf893efc9264ff5a0
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT] Networking
From: pr-tracker-bot @ 2019-01-27 17:25 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20190125.115827.1407196401514719611.davem@davemloft.net>
The pull request you sent on Fri, 25 Jan 2019 11:58:27 -0800 (PST):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/abfd04f738c2625f63e04c8fc7cadb3b7a70d580
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [PATCH 0/7] sh_eth: implement simple RX checksum offload
From: Sergei Shtylyov @ 2019-01-27 17:33 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
Hello!
Here's a set of 7 patches against DaveM's 'net-next.git' repo. I'm implemeting
the simple RX checksum offload (like was done for the 'ravb' driver by Simon
Horman); it was only tested on the R8A77980 SoC, the other SoCs should just
work (according to their manuals)...
[1/7] sh_eth: rename sh_eth_cpu_data::hw_checksum
[2/7] sh_eth: RX checksum offload support
[3/7] sh_eth: offload RX checksum on R7S72100
[4/7] sh_eth: offload RX checksum on R8A7740
[5/7] sh_eth: offload RX checksum on R8A77980
[6/7] sh_eth: offload RX checksum on SH7734
[7/7] sh_eth: offload RX checksum on SH7763
MBR, Sergei
^ permalink raw reply
* [PATCH 1/7] sh_eth: rename sh_eth_cpu_data::hw_checksum
From: Sergei Shtylyov @ 2019-01-27 17:36 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <fc43bfa2-4312-b52b-a749-e3e43e242a95@cogentembedded.com>
Commit 62e04b7e0e3c ("sh_eth: rename 'sh_eth_cpu_data::hw_crc'") renamed
the field to 'hw_checksum' for the Ether DMAC "intelligent checksum",
however some Ether MACs implement a simpler checksumming scheme, so that
name now seems misleading. Rename that filed to 'csmr' as the "intelligent
checkmum" is always controlled by the CSMR register.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 14 +++++++-------
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -555,7 +555,7 @@ static int sh_eth_soft_reset_gether(stru
sh_eth_write(ndev, 0, RDFFR);
/* Reset HW CRC register */
- if (mdp->cd->hw_checksum)
+ if (mdp->cd->csmr)
sh_eth_write(ndev, 0, CSMR);
/* Select MII mode */
@@ -619,7 +619,7 @@ static struct sh_eth_cpu_data r7s72100_d
.no_trimd = 1,
.no_ade = 1,
.xdfar_rw = 1,
- .hw_checksum = 1,
+ .csmr = 1,
.tsu = 1,
.no_tx_cntrs = 1,
};
@@ -668,7 +668,7 @@ static struct sh_eth_cpu_data r8a7740_da
.no_trimd = 1,
.no_ade = 1,
.xdfar_rw = 1,
- .hw_checksum = 1,
+ .csmr = 1,
.tsu = 1,
.select_mii = 1,
.magic = 1,
@@ -793,7 +793,7 @@ static struct sh_eth_cpu_data r8a77980_d
.no_trimd = 1,
.no_ade = 1,
.xdfar_rw = 1,
- .hw_checksum = 1,
+ .csmr = 1,
.select_mii = 1,
.magic = 1,
.cexcr = 1,
@@ -1045,7 +1045,7 @@ static struct sh_eth_cpu_data sh7734_dat
.no_ade = 1,
.xdfar_rw = 1,
.tsu = 1,
- .hw_checksum = 1,
+ .csmr = 1,
.select_mii = 1,
.magic = 1,
.cexcr = 1,
@@ -1633,7 +1633,7 @@ static int sh_eth_rx(struct net_device *
* the RFS bits are from bit 25 to bit 16. So, the
* driver needs right shifting by 16.
*/
- if (mdp->cd->hw_checksum)
+ if (mdp->cd->csmr)
desc_status >>= 16;
skb = mdp->rx_skbuff[entry];
@@ -2173,7 +2173,7 @@ static size_t __sh_eth_get_regs(struct n
add_reg(MAFCR);
if (cd->rtrate)
add_reg(RTRATE);
- if (cd->hw_checksum)
+ if (cd->csmr)
add_reg(CSMR);
if (cd->select_mii)
add_reg(RMII_MII);
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -499,7 +499,7 @@ struct sh_eth_cpu_data {
unsigned no_ade:1; /* E-DMAC DOES NOT have ADE bit in EESR */
unsigned no_xdfar:1; /* E-DMAC DOES NOT have RDFAR/TDFAR */
unsigned xdfar_rw:1; /* E-DMAC has writeable RDFAR/TDFAR */
- unsigned hw_checksum:1; /* E-DMAC has CSMR */
+ unsigned csmr:1; /* E-DMAC has CSMR */
unsigned select_mii:1; /* EtherC has RMII_MII (MII select register) */
unsigned rmiimode:1; /* EtherC has RMIIMODE register */
unsigned rtrate:1; /* EtherC has RTRATE register */
^ permalink raw reply
* [PATCH 2/7] sh_eth: RX checksum offload support
From: Sergei Shtylyov @ 2019-01-27 17:37 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <fc43bfa2-4312-b52b-a749-e3e43e242a95@cogentembedded.com>
Add support for the RX checksum offload. This is enabled by default and
may be disabled and re-enabled using 'ethtool':
# ethtool -K eth0 rx {on|off}
Some Ether MACs provide a simple checksumming scheme which appears to be
completely compatible with CHECKSUM_COMPLETE: sum of all packet data after
the L2 header is appended to packet data; this may be trivially read by
the driver and used to update the skb accordingly. The same checksumming
scheme is implemented in the EtherAVB MACs and now supported by tha 'ravb'
driver.
In terms of performance, throughput is close to gigabit line rate with the
RX checksum offload both enabled and disabled. The 'perf' output, however,
appears to indicate that significantly less time is spent in do_csum() --
this is as expected.
Test results with RX checksum offload enabled:
~/netperf-2.2pl4# perf record -a ./netperf -t TCP_MAERTS -H 192.168.2.4
TCP MAERTS TEST to 192.168.2.4
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 10.01 933.93
[ perf record: Woken up 8 times to write data ]
[ perf record: Captured and wrote 1.955 MB perf.data (41940 samples) ]
~/netperf-2.2pl4# perf report
Samples: 41K of event 'cycles:ppp', Event count (approx.): 9915302763
Overhead Command Shared Object Symbol
9.44% netperf [kernel.kallsyms] [k] __arch_copy_to_user
7.75% swapper [kernel.kallsyms] [k] _raw_spin_unlock_irq
6.31% swapper [kernel.kallsyms] [k] default_idle_call
5.89% swapper [kernel.kallsyms] [k] arch_cpu_idle
4.37% swapper [kernel.kallsyms] [k] tick_nohz_idle_exit
4.02% netperf [kernel.kallsyms] [k] _raw_spin_unlock_irq
2.52% netperf [kernel.kallsyms] [k] preempt_count_sub
1.81% netperf [kernel.kallsyms] [k] tcp_recvmsg
1.80% netperf [kernel.kallsyms] [k] _raw_spin_unlock_irqres
1.78% netperf [kernel.kallsyms] [k] preempt_count_add
1.36% netperf [kernel.kallsyms] [k] __tcp_transmit_skb
1.20% netperf [kernel.kallsyms] [k] __local_bh_enable_ip
1.10% netperf [kernel.kallsyms] [k] sh_eth_start_xmit
Test results with RX checksum offload disabled:
~/netperf-2.2pl4# perf record -a ./netperf -t TCP_MAERTS -H 192.168.2.4
TCP MAERTS TEST to 192.168.2.4
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 10.01 932.04
[ perf record: Woken up 14 times to write data ]
[ perf record: Captured and wrote 3.642 MB perf.data (78817 samples) ]
~/netperf-2.2pl4# perf report
Samples: 78K of event 'cycles:ppp', Event count (approx.): 18091442796
Overhead Command Shared Object Symbol
7.00% swapper [kernel.kallsyms] [k] do_csum
3.94% swapper [kernel.kallsyms] [k] sh_eth_poll
3.83% ksoftirqd/0 [kernel.kallsyms] [k] do_csum
3.23% swapper [kernel.kallsyms] [k] _raw_spin_unlock_irq
2.87% netperf [kernel.kallsyms] [k] __arch_copy_to_user
2.86% swapper [kernel.kallsyms] [k] arch_cpu_idle
2.13% swapper [kernel.kallsyms] [k] default_idle_call
2.12% ksoftirqd/0 [kernel.kallsyms] [k] sh_eth_poll
2.02% swapper [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
1.84% swapper [kernel.kallsyms] [k] __softirqentry_text_start
1.64% swapper [kernel.kallsyms] [k] tick_nohz_idle_exit
1.53% netperf [kernel.kallsyms] [k] _raw_spin_unlock_irq
1.32% netperf [kernel.kallsyms] [k] preempt_count_sub
1.27% swapper [kernel.kallsyms] [k] __pi___inval_dcache_area
1.22% swapper [kernel.kallsyms] [k] check_preemption_disabled
1.01% ksoftirqd/0 [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
The above results collected on the R-Car V3H Starter Kit board.
Based on the commit 4d86d3818627 ("ravb: RX checksum offload")...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 60 ++++++++++++++++++++++++++++++++--
drivers/net/ethernet/renesas/sh_eth.h | 1
2 files changed, 59 insertions(+), 2 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -1532,8 +1532,9 @@ static int sh_eth_dev_init(struct net_de
mdp->irq_enabled = true;
sh_eth_write(ndev, mdp->cd->eesipr_value, EESIPR);
- /* PAUSE Prohibition */
+ /* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
sh_eth_write(ndev, ECMR_ZPF | (mdp->duplex ? ECMR_DM : 0) |
+ (ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
ECMR_TE | ECMR_RE, ECMR);
if (mdp->cd->set_rate)
@@ -1592,6 +1593,19 @@ static void sh_eth_dev_exit(struct net_d
update_mac_address(ndev);
}
+static void sh_eth_rx_csum(struct sk_buff *skb)
+{
+ u8 *hw_csum;
+
+ /* The hardware checksum is 2 bytes appended to packet data */
+ if (unlikely(skb->len < sizeof(__sum16)))
+ return;
+ hw_csum = skb_tail_pointer(skb) - sizeof(__sum16);
+ skb->csum = csum_unfold((__force __sum16)get_unaligned_le16(hw_csum));
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ skb_trim(skb, skb->len - sizeof(__sum16));
+}
+
/* Packet receive function */
static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
{
@@ -1666,6 +1680,8 @@ static int sh_eth_rx(struct net_device *
DMA_FROM_DEVICE);
skb_put(skb, pkt_len);
skb->protocol = eth_type_trans(skb, ndev);
+ if (ndev->features & NETIF_F_RXCSUM)
+ sh_eth_rx_csum(skb);
netif_receive_skb(skb);
ndev->stats.rx_packets++;
ndev->stats.rx_bytes += pkt_len;
@@ -2921,6 +2937,39 @@ static void sh_eth_set_rx_mode(struct ne
spin_unlock_irqrestore(&mdp->lock, flags);
}
+static void sh_eth_set_rx_csum(struct net_device *ndev, bool enable)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&mdp->lock, flags);
+
+ /* Disable TX and RX */
+ sh_eth_rcv_snd_disable(ndev);
+
+ /* Modify RX Checksum setting */
+ sh_eth_modify(ndev, ECMR, ECMR_RCSC, enable ? ECMR_RCSC : 0);
+
+ /* Enable TX and RX */
+ sh_eth_rcv_snd_enable(ndev);
+
+ spin_unlock_irqrestore(&mdp->lock, flags);
+}
+
+static int sh_eth_set_features(struct net_device *ndev,
+ netdev_features_t features)
+{
+ netdev_features_t changed = ndev->features ^ features;
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+
+ if (changed & NETIF_F_RXCSUM && mdp->cd->rx_csum)
+ sh_eth_set_rx_csum(ndev, features & NETIF_F_RXCSUM);
+
+ ndev->features = features;
+
+ return 0;
+}
+
static int sh_eth_get_vtag_index(struct sh_eth_private *mdp)
{
if (!mdp->port)
@@ -3102,6 +3151,7 @@ static const struct net_device_ops sh_et
.ndo_change_mtu = sh_eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
+ .ndo_set_features = sh_eth_set_features,
};
static const struct net_device_ops sh_eth_netdev_ops_tsu = {
@@ -3117,6 +3167,7 @@ static const struct net_device_ops sh_et
.ndo_change_mtu = sh_eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = eth_mac_addr,
+ .ndo_set_features = sh_eth_set_features,
};
#ifdef CONFIG_OF
@@ -3245,6 +3296,11 @@ static int sh_eth_drv_probe(struct platf
ndev->max_mtu = 2000 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
ndev->min_mtu = ETH_MIN_MTU;
+ if (mdp->cd->rx_csum) {
+ ndev->features = NETIF_F_RXCSUM;
+ ndev->hw_features = NETIF_F_RXCSUM;
+ }
+
/* set function */
if (mdp->cd->tsu)
ndev->netdev_ops = &sh_eth_netdev_ops_tsu;
@@ -3294,7 +3350,7 @@ static int sh_eth_drv_probe(struct platf
goto out_release;
}
mdp->port = port;
- ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER;
+ ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
/* Need to init only the first port of the two sharing a TSU */
if (port == 0) {
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -500,6 +500,7 @@ struct sh_eth_cpu_data {
unsigned no_xdfar:1; /* E-DMAC DOES NOT have RDFAR/TDFAR */
unsigned xdfar_rw:1; /* E-DMAC has writeable RDFAR/TDFAR */
unsigned csmr:1; /* E-DMAC has CSMR */
+ unsigned rx_csum:1; /* EtherC has ECMR.RCSC */
unsigned select_mii:1; /* EtherC has RMII_MII (MII select register) */
unsigned rmiimode:1; /* EtherC has RMIIMODE register */
unsigned rtrate:1; /* EtherC has RTRATE register */
^ permalink raw reply
* [PATCH 3/7] sh_eth: offload RX checksum on R7S72100
From: Sergei Shtylyov @ 2019-01-27 17:38 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <fc43bfa2-4312-b52b-a749-e3e43e242a95@cogentembedded.com>
The RZ/A1H (R7S721000) SoC manual describes the Ether MAC's RX checksum
offload the same way as it's implemented in the EtherAVB MACs...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -620,6 +620,7 @@ static struct sh_eth_cpu_data r7s72100_d
.no_ade = 1,
.xdfar_rw = 1,
.csmr = 1,
+ .rx_csum = 1,
.tsu = 1,
.no_tx_cntrs = 1,
};
^ permalink raw reply
* [PATCH 4/7] sh_eth: offload RX checksum on R8A7740
From: Sergei Shtylyov @ 2019-01-27 17:39 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <fc43bfa2-4312-b52b-a749-e3e43e242a95@cogentembedded.com>
The R-Mobile A1 (R8A7740) SoC manual describes the Ether MAC's RX checksum
offload the same way as it's implemented in the EtherAVB MAC...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -670,6 +670,7 @@ static struct sh_eth_cpu_data r8a7740_da
.no_ade = 1,
.xdfar_rw = 1,
.csmr = 1,
+ .rx_csum = 1,
.tsu = 1,
.select_mii = 1,
.magic = 1,
^ permalink raw reply
* [PATCH 5/7] sh_eth: offload RX checksum on R8A77980
From: Sergei Shtylyov @ 2019-01-27 17:40 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <fc43bfa2-4312-b52b-a749-e3e43e242a95@cogentembedded.com>
The R-Car V3H (R8A77980) SoC manual describes the Ether MAC's RX checksum
offload the same way as it's implemented in the EtherAVB MAC...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -796,6 +796,7 @@ static struct sh_eth_cpu_data r8a77980_d
.no_ade = 1,
.xdfar_rw = 1,
.csmr = 1,
+ .rx_csum = 1,
.select_mii = 1,
.magic = 1,
.cexcr = 1,
^ permalink raw reply
* [PATCH 6/7] sh_eth: offload RX checksum on SH7734
From: Sergei Shtylyov @ 2019-01-27 17:41 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <fc43bfa2-4312-b52b-a749-e3e43e242a95@cogentembedded.com>
The SH7734 SoC manual describes the Ether MAC's RX checksum offload
the same way as it's implemented in the EtherAVB MACs...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -1049,6 +1049,7 @@ static struct sh_eth_cpu_data sh7734_dat
.xdfar_rw = 1,
.tsu = 1,
.csmr = 1,
+ .rx_csum = 1,
.select_mii = 1,
.magic = 1,
.cexcr = 1,
^ permalink raw reply
* [PATCH 7/7] sh_eth: offload RX checksum on SH7763
From: Sergei Shtylyov @ 2019-01-27 17:42 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <fc43bfa2-4312-b52b-a749-e3e43e242a95@cogentembedded.com>
The SH7763 SoC manual describes the Ether MAC's RX checksum offload
the same way as it's implemented in the EtherAVB MACs...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 1 +
1 file changed, 1 insertion(+)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -1092,6 +1092,7 @@ static struct sh_eth_cpu_data sh7763_dat
.irq_flags = IRQF_SHARED,
.magic = 1,
.cexcr = 1,
+ .rx_csum = 1,
.dual_port = 1,
};
^ permalink raw reply
* Re: [PATCH 0/7] sh_eth: implement simple RX checksum offload
From: Heiner Kallweit @ 2019-01-27 17:52 UTC (permalink / raw)
To: Sergei Shtylyov, netdev, David S. Miller; +Cc: linux-renesas-soc, linux-sh
In-Reply-To: <fc43bfa2-4312-b52b-a749-e3e43e242a95@cogentembedded.com>
On 27.01.2019 18:33, Sergei Shtylyov wrote:
> Hello!
>
> Here's a set of 7 patches against DaveM's 'net-next.git' repo. I'm implemeting
> the simple RX checksum offload (like was done for the 'ravb' driver by Simon
> Horman); it was only tested on the R8A77980 SoC, the other SoCs should just
> work (according to their manuals)...
>
> [1/7] sh_eth: rename sh_eth_cpu_data::hw_checksum
> [2/7] sh_eth: RX checksum offload support
> [3/7] sh_eth: offload RX checksum on R7S72100
> [4/7] sh_eth: offload RX checksum on R8A7740
> [5/7] sh_eth: offload RX checksum on R8A77980
> [6/7] sh_eth: offload RX checksum on SH7734
> [7/7] sh_eth: offload RX checksum on SH7763
>
> MBR, Sergei
>
Hi Sergei,
the formatting of the patch series isn't in line with the netdev standards.
See here: https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
- cover letter isn't generated by git
- That's not ok
--- *net-next.orig/*drivers/net/ethernet/renesas/sh_eth.h
+++ *net-next/*drivers/net/ethernet/renesas/sh_eth.h
- patches miss net / net-next annotation
Heiner
^ permalink raw reply
* Re: [PATCH net-next 0/3] qed*: Error recovery process
From: David Miller @ 2019-01-27 18:17 UTC (permalink / raw)
To: mkalderon; +Cc: michal.kalderon, ariel.elior, netdev
In-Reply-To: <BLUPR18MB0130E67F11EEE010B26933E3A1950@BLUPR18MB0130.namprd18.prod.outlook.com>
From: Michal Kalderon <mkalderon@marvell.com>
Date: Sun, 27 Jan 2019 13:42:35 +0000
>> From: David Miller <davem@davemloft.net>
>> Sent: Wednesday, January 23, 2019 3:37 AM
>>
>> > Parity errors might happen in the device's memories due to momentary
>> > bit flips which are caused by radiation.
>> > Errors that are not correctable initiate a process kill event, which
>> > blocks the device access towards the host and the network, and a
>> > recovery process is started in the management FW and in the driver.
>> >
>> > This series adds the support of this process in the qed core module
>> > and in the qede driver (patches 2 & 3).
>> > Patch 1 in the series revises the load sequence, to avoid PCI errors
>> > that might be observed during a recovery process.
>>
>> Series applied.
>
> Thanks Dave, though I don't see this in net-next, I noticed this was recently applied
> and reverted from net, should I resend to have it applied to net-next ?
Yes it was my mistake, please resubmit and please integrate the follow-up fix that
was posted as well.
https://patchwork.ozlabs.org/patch/1030545/
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2019-01-27 18:19 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <CAHk-=wgJQf+eS6MeEuUL59kSr-kiiYpzSUfErvO_yTQTNPtHwg@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun, 27 Jan 2019 09:02:17 -0800
> I'm trying to be a bit stricter about the rc pulls, even if I normally
> don't even look at yours much.
>
> So let's try to keep it to fixes only, or at least when you sneak in
> new stuff, make them small enough that I don't go "Hmm.. That looks
> odd.." ;)
Completely understood.
This one was actually my bad in the most heinous way, because the
submitter did say that the changes should go to net-next.
I have to tone down the meds or something.
Sorry!
^ permalink raw reply
* Re: [PATCH] [stable pre-4.8] can: bcm: check timer values before ktime conversion
From: Oliver Hartkopp @ 2019-01-27 18:22 UTC (permalink / raw)
To: Sasha Levin
Cc: davem, netdev, stable, linux-can, lifeasageek, threeearcat,
syzkaller, nautsch2, Kyungtae Kim, Marc Kleine-Budde
In-Reply-To: <20190126181718.GE30183@sasha-vm>
Hi Sasha,
On 26.01.19 19:17, Sasha Levin wrote:
> On Thu, Jan 24, 2019 at 10:08:42AM +0100, Oliver Hartkopp wrote:
>> Kyungtae Kim detected a potential integer overflow in bcm_[rx|tx]_setup()
>> when the conversion into ktime multiplies the given value with
>> NSEC_PER_USEC
>> (1000).
>>
>> Reference: https://marc.info/?l=linux-can&m=154732118819828&w=2
>>
>> Add a check for the given tv_usec, so that the value stays below one
>> second.
>> Additionally limit the tv_sec value to a reasonable value for CAN related
>> use-cases of 400 days and ensure all values to be positive.
>>
>> This patch is the pre-4.8 version of upstream commit 93171ba6f1deffd8
>
> I can't find this commit id upstream, there's nothing with the same
> subject name, nor does this code exist upstream. What's going on?
Here we are (pulled by Linus some minutes ago):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93171ba6f1deffd82f381d36cb13177872d023f6
Can you go with this pre-4.8 version now?
Many thanks,
Oliver
^ permalink raw reply
* Re: pull request (net): ipsec 2019-01-25
From: David Miller @ 2019-01-27 18:32 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20190125074426.31053-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 25 Jan 2019 08:44:16 +0100
> 1) Several patches to fix the fallout from the recent
> tree based policy lookup work. From Florian Westphal.
>
> 2) Fix VTI for IPCOMP for 'not compressed' IPCOMP packets.
> We need an extra IPIP handler to process these packets
> correctly. From Su Yanjun.
>
> 3) Fix validation of template and selector families for
> MODE_ROUTEOPTIMIZATION with ipv4-in-ipv6 packets.
> This can lead to a stack-out-of-bounds because
> flowi4 struct is treated as flowi6 struct.
> Fix from Florian Westphal.
>
> 4) Restore the default behaviour of the xfrm set-mark
> in the output path. This was changed accidentally
> when mark setting was extended to the input path.
> From Benedict Wong.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen!
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/3] selftests: bpf: break up test_verifier
From: Jakub Kicinski @ 2019-01-27 18:33 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: daniel, oss-drivers, netdev
In-Reply-To: <20190126062120.pzb4jw2rzv6o5jp3@ast-mbp.dhcp.thefacebook.com>
On Fri, 25 Jan 2019 22:21:22 -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 10:17:28PM -0800, Jakub Kicinski wrote:
> > On Fri, 25 Jan 2019 21:55:30 -0800, Alexei Starovoitov wrote:
> > > On Fri, Jan 25, 2019 at 03:24:41PM -0800, Jakub Kicinski wrote:
> > > > Hi!
> > > >
> > > > The tools/testing/selftests/bpf/test_verifier.c file is
> > > > way too large, and since most people add their at the
> > > > end of the list it's very prone to conflicts.
> > > >
> > > > Break it up in the simplest possible way - slice the
> > > > array up into smaller C files and include them in the
> > > > right spot.
> > > >
> > > > Tested:
> > > > $ make -C tools/testing/selftests/bpf/
> > > > $ cd tools/testing/selftests/bpf/ ; make
> > > >
> > > > v2:
> > > >
> > > > The indentation is reduced further as discussed and lines folded.
> > > > The conversion was scripted, and double checked by hand.
> > >
> > > Looks great to me, but even first patch conflicts too much to apply.
> > > Please respin one more time.
> >
> > I could have sworn when I pulled bpf-next this morning Jiong's patches
> > were in it ;) I'll rebase/repost tomorrow morning.
>
> They were ;) until they were pulled off.
> Any order is fine.
Looks like v2 just applies cleanly again, should I repost?
^ permalink raw reply
* Re: [Patch net] netrom: switch to sock timer API
From: David Miller @ 2019-01-27 18:38 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, syzbot+defa700d16f1bd1b9a05, ralf, linux-hams
In-Reply-To: <20190124221818.15813-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 24 Jan 2019 14:18:18 -0800
> sk_reset_timer() and sk_stop_timer() properly handle
> sock refcnt for timer function. Switching to them
> could fix a refcounting bug reported by syzbot.
>
> Reported-and-tested-by: syzbot+defa700d16f1bd1b9a05@syzkaller.appspotmail.com
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-hams@vger.kernel.org
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH v2] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
From: David Miller @ 2019-01-27 18:41 UTC (permalink / raw)
To: atsushi.nemoto; +Cc: thor.thayer, netdev, dalon.westergreen, tomonori.sakita
In-Reply-To: <20190125.110222.956948485194493083.atsushi.nemoto@sord.co.jp>
From: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
Date: Fri, 25 Jan 2019 11:02:22 +0900
> From: Tomonori Sakita <tomonori.sakita@sord.co.jp>
>
> If fill_level was not zero and status was not BUSY,
> result of "tx_prod - tx_cons - inuse" might be zero.
> Subtracting 1 unconditionally results invalid negative return value
> on this case.
> Make sure not to return an negative value.
>
> Signed-off-by: Tomonori Sakita <tomonori.sakita@sord.co.jp>
> Signed-off-by: Atsushi Nemoto <atsushi.nemoto@sord.co.jp>
> Reviewed-by: Dalon L Westergreen <dalon.westergreen@linux.intel.com>
> ---
> Changes in v2:
> Use max_t instead of just removing the "- 1".
Applied.
^ permalink raw reply
* Re: [PATCH] net/rose: fix NULL ax25_cb kernel panic
From: David Miller @ 2019-01-27 18:41 UTC (permalink / raw)
To: dvyukov
Cc: f6bvp, linux-hams, netdev, dvyukov, syzbot+1a2c456a1ea08fa5b5f7,
ralf, linux-kernel
In-Reply-To: <20190125104640.253862-1-dvyukov@gmail.com>
From: Dmitry Vyukov <dvyukov@gmail.com>
Date: Fri, 25 Jan 2019 11:46:40 +0100
> From: Bernard Pidoux <f6bvp@free.fr>
>
> When an internally generated frame is handled by rose_xmit(),
> rose_route_frame() is called:
>
> if (!rose_route_frame(skb, NULL)) {
> dev_kfree_skb(skb);
> stats->tx_errors++;
> return NETDEV_TX_OK;
> }
>
> We have the same code sequence in Net/Rom where an internally generated
> frame is handled by nr_xmit() calling nr_route_frame(skb, NULL).
> However, in this function NULL argument is tested while it is not in
> rose_route_frame().
> Then kernel panic occurs later on when calling ax25cmp() with a NULL
> ax25_cb argument as reported many times and recently with syzbot.
>
> We need to test if ax25 is NULL before using it.
>
> Testing:
> Built kernel with CONFIG_ROSE=y.
>
> Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
> Acked-by: Dmitry Vyukov <dvyukov@google.com>
> Reported-by: syzbot+1a2c456a1ea08fa5b5f7@syzkaller.appspotmail.com
Applied and queued up for -stable, thanks.
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 0/3] qed*: Error recovery process
From: Michal Kalderon @ 2019-01-27 18:57 UTC (permalink / raw)
To: David Miller
Cc: michal.kalderon@cavium.com, ariel.elior@cavium.com,
netdev@vger.kernel.org
In-Reply-To: <20190127.101729.1774234996114932306.davem@davemloft.net>
> From: David Miller <davem@davemloft.net>
> Sent: Sunday, January 27, 2019 8:17 PM
>
> >> From: David Miller <davem@davemloft.net>
> >> Sent: Wednesday, January 23, 2019 3:37 AM
> >>
> >> > Parity errors might happen in the device's memories due to
> >> > momentary bit flips which are caused by radiation.
> >> > Errors that are not correctable initiate a process kill event,
> >> > which blocks the device access towards the host and the network,
> >> > and a recovery process is started in the management FW and in the
> driver.
> >> >
> >> > This series adds the support of this process in the qed core module
> >> > and in the qede driver (patches 2 & 3).
> >> > Patch 1 in the series revises the load sequence, to avoid PCI
> >> > errors that might be observed during a recovery process.
> >>
> >> Series applied.
> >
> > Thanks Dave, though I don't see this in net-next, I noticed this was
> > recently applied and reverted from net, should I resend to have it applied
> to net-next ?
>
> Yes it was my mistake, please resubmit and please integrate the follow-up fix
> that was posted as well.
>
> https://patchwork.ozlabs.org/patch/1030545/
Sure, thanks,
Michal
^ permalink raw reply
* Re: [PATCH] [stable pre-4.8] can: bcm: check timer values before ktime conversion
From: Greg KH @ 2019-01-27 19:34 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Sasha Levin, davem, netdev, stable, linux-can, lifeasageek,
threeearcat, syzkaller, nautsch2, Kyungtae Kim, Marc Kleine-Budde
In-Reply-To: <8a72ffa5-dac5-6de8-f01e-dfbb98b1f024@hartkopp.net>
On Sun, Jan 27, 2019 at 07:22:38PM +0100, Oliver Hartkopp wrote:
> Hi Sasha,
>
> On 26.01.19 19:17, Sasha Levin wrote:
> > On Thu, Jan 24, 2019 at 10:08:42AM +0100, Oliver Hartkopp wrote:
> > > Kyungtae Kim detected a potential integer overflow in bcm_[rx|tx]_setup()
> > > when the conversion into ktime multiplies the given value with
> > > NSEC_PER_USEC
> > > (1000).
> > >
> > > Reference: https://marc.info/?l=linux-can&m=154732118819828&w=2
> > >
> > > Add a check for the given tv_usec, so that the value stays below one
> > > second.
> > > Additionally limit the tv_sec value to a reasonable value for CAN related
> > > use-cases of 400 days and ensure all values to be positive.
> > >
> > > This patch is the pre-4.8 version of upstream commit 93171ba6f1deffd8
> >
> > I can't find this commit id upstream, there's nothing with the same
> > subject name, nor does this code exist upstream. What's going on?
>
> Here we are (pulled by Linus some minutes ago):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93171ba6f1deffd82f381d36cb13177872d023f6
>
> Can you go with this pre-4.8 version now?
Let me get the others into the newer kernels first please :)
Should be a day or so at most...
thanks,
greg k-h
^ permalink raw reply
* Re: Error in the hso driver
From: Greg KH @ 2019-01-27 19:35 UTC (permalink / raw)
To: Yavuz, Tuba; +Cc: netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <1548614320825.86428@ece.ufl.edu>
On Sun, Jan 27, 2019 at 06:38:41PM +0000, Yavuz, Tuba wrote:
> Hello,
>
>
> On an error path inside the hso_create_net_device function of the hso driver (drivers/net/usb/hso), hso_free_net_device gets called. This causes a negative reference count in the net device if register_netdev has not been called yet as hso_free_net_device calls unregister_netdev regardless. I think the driver should distinguish these cases and call unregister_netdev only if register_netdev has been called.
>
>
> Detected on v4.14-rc2 but I believe the problem still exists in the newer versions.
Can you send a patch to solve this issue? That's the best way to handle
it as you get the proper credit and we can understand exactly what you
are trying to show here.
thanks,
greg k-h
^ permalink raw reply
* Re: [pull request][net 0/6] Mellanox, mlx5 fixes 2019-01-25
From: David Miller @ 2019-01-27 19:39 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190125200140.6222-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 25 Jan 2019 12:01:34 -0800
> This series introduces some fixes to mlx5 driver.
> For more information please see tag log below.
>
> Please pull and let me know if there is any problem.
Pulled.
> For -stable v4.13
> ('net/mlx5e: Allow MAC invalidation while spoofchk is ON')
>
> For -stable v4.18
> ('Revert "net/mlx5e: E-Switch, Initialize eswitch only if eswitch manager"')
Queued up.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox