* Re: DSA support for Micrel KSZ8895
From: Andrew Lunn @ 2017-08-28 13:19 UTC (permalink / raw)
To: Pavel Machek
Cc: Woojung.Huh, nathan.leigh.conrad, vivien.didelot, f.fainelli,
netdev, linux-kernel, Tristram.Ha
In-Reply-To: <20170828101451.GC18012@amd>
> I'm working at 4.13-rc.
For network code, it is a good idea to use net-next. That is what you
need to target in order to get patches with new features merged.
Andrew
^ permalink raw reply
* [PATCH net-next] hinic: don't build the module by default
From: Vitaly Kuznetsov @ 2017-08-28 13:16 UTC (permalink / raw)
To: netdev; +Cc: Aviad Krawczyk, linux-kernel
We probably don't want to enable code supporting particular hardware by
default e.g. when someone does 'make defconfig'. Other ethernet modules
don't do it.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
drivers/net/ethernet/huawei/hinic/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/huawei/hinic/Kconfig b/drivers/net/ethernet/huawei/hinic/Kconfig
index 69f2b1fba48d..08db24954f7e 100644
--- a/drivers/net/ethernet/huawei/hinic/Kconfig
+++ b/drivers/net/ethernet/huawei/hinic/Kconfig
@@ -5,7 +5,6 @@
config HINIC
tristate "Huawei Intelligent PCIE Network Interface Card"
depends on (PCI_MSI && X86)
- default m
---help---
This driver supports HiNIC PCIE Ethernet cards.
To compile this driver as part of the kernel, choose Y here.
--
2.13.5
^ permalink raw reply related
* Re: [PATCH 3/8] tty/bcm63xx_uart: use refclk for the expected clock name
From: Greg Kroah-Hartman @ 2017-08-28 12:51 UTC (permalink / raw)
To: Jonas Gorski
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Mark Rutland, Ralf Baechle, Florian Fainelli,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Kevin Cernekee,
Jiri Slaby, David S. Miller, Russell King
In-Reply-To: <20170802093429.12572-4-jonas.gorski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Aug 02, 2017 at 11:34:24AM +0200, Jonas Gorski wrote:
> We now have the clock available under refclk, so use that.
>
> Signed-off-by: Jonas Gorski <jonas.gorski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [ethtool] ethtool: Remove UDP Fragmentation Offload use from ethtool
From: Tariq Toukan @ 2017-08-28 12:38 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Eran Ben Elisha, Shaker Daibes, Tariq Toukan
From: Shaker Daibes <shakerd@mellanox.com>
UFO was removed in kernel, here we remove it in ethtool app.
Fixes the following issue:
Features for ens8:
Cannot get device udp-fragmentation-offload settings: Operation not supported
Tested with "make check"
Signed-off-by: Shaker Daibes <shakerd@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
---
ethtool.8.in | 3 ---
ethtool.c | 2 --
internal.h | 5 ++---
test-features.c | 36 +++++-------------------------------
4 files changed, 7 insertions(+), 39 deletions(-)
diff --git a/ethtool.8.in b/ethtool.8.in
index 7224b04b8f2f..f14ac53118c8 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -480,9 +480,6 @@ Specifies whether scatter-gather should be enabled.
.A2 tso on off
Specifies whether TCP segmentation offload should be enabled.
.TP
-.A2 ufo on off
-Specifies whether UDP fragmentation offload should be enabled
-.TP
.A2 gso on off
Specifies whether generic segmentation offload should be enabled
.TP
diff --git a/ethtool.c b/ethtool.c
index ad18704e7c5f..f3514447c18e 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -166,8 +166,6 @@ static const struct off_flag_def off_flag_def[] = {
ETHTOOL_GSG, ETHTOOL_SSG, ETH_FLAG_SG, 0 },
{ "tso", "tcp-segmentation-offload", "tx-tcp*-segmentation",
ETHTOOL_GTSO, ETHTOOL_STSO, ETH_FLAG_TSO, 0 },
- { "ufo", "udp-fragmentation-offload", "tx-udp-fragmentation",
- ETHTOOL_GUFO, ETHTOOL_SUFO, ETH_FLAG_UFO, 0 },
{ "gso", "generic-segmentation-offload", "tx-generic-segmentation",
ETHTOOL_GGSO, ETHTOOL_SGSO, ETH_FLAG_GSO, 0 },
{ "gro", "generic-receive-offload", "rx-gro",
diff --git a/internal.h b/internal.h
index 4e658ea54307..c033e080e4ff 100644
--- a/internal.h
+++ b/internal.h
@@ -112,12 +112,11 @@ static inline int test_bit(unsigned int nr, const unsigned long *addr)
#define ETH_FLAG_TXCSUM (1 << 1)
#define ETH_FLAG_SG (1 << 2)
#define ETH_FLAG_TSO (1 << 3)
-#define ETH_FLAG_UFO (1 << 4)
#define ETH_FLAG_GSO (1 << 5)
#define ETH_FLAG_GRO (1 << 6)
#define ETH_FLAG_INT_MASK (ETH_FLAG_RXCSUM | ETH_FLAG_TXCSUM | \
- ETH_FLAG_SG | ETH_FLAG_TSO | ETH_FLAG_UFO | \
- ETH_FLAG_GSO | ETH_FLAG_GRO),
+ ETH_FLAG_SG | ETH_FLAG_TSO | ETH_FLAG_GSO | \
+ ETH_FLAG_GRO),
/* Mask of all flags defined for ETHTOOL_{G,S}FLAGS. */
#define ETH_FLAG_EXT_MASK (ETH_FLAG_LRO | ETH_FLAG_RXVLAN | \
ETH_FLAG_TXVLAN | ETH_FLAG_NTUPLE | \
diff --git a/test-features.c b/test-features.c
index 6ebb364803a2..31e2a223d19c 100644
--- a/test-features.c
+++ b/test-features.c
@@ -37,10 +37,6 @@ cmd_gtso_off = { ETHTOOL_GTSO, 0 },
cmd_gtso_on = { ETHTOOL_GTSO, 1 },
cmd_stso_off = { ETHTOOL_STSO, 0 },
cmd_stso_on = { ETHTOOL_STSO, 1 },
-cmd_gufo_off = { ETHTOOL_GUFO, 0 },
-cmd_gufo_on = { ETHTOOL_GUFO, 1 },
-cmd_sufo_off = { ETHTOOL_SUFO, 0 },
-cmd_sufo_on = { ETHTOOL_SUFO, 1 },
cmd_ggso_off = { ETHTOOL_GGSO, 0 },
cmd_ggso_on = { ETHTOOL_GGSO, 1 },
cmd_sgso_off = { ETHTOOL_SGSO, 0 },
@@ -73,7 +69,6 @@ static const struct cmd_expect cmd_expect_get_features_off_old[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -86,7 +81,6 @@ static const struct cmd_expect cmd_expect_get_features_off_old_some_unsup[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, -EOPNOTSUPP },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4, -EOPNOTSUPP },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -99,7 +93,6 @@ static const struct cmd_expect cmd_expect_get_features_off_old_some_priv[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4, -EPERM },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -112,7 +105,6 @@ static const struct cmd_expect cmd_expect_set_features_off_old[] = {
{ &cmd_gtxcsum_on, 4, 0, &cmd_gtxcsum_on, sizeof(cmd_gtxcsum_on) },
{ &cmd_gsg_on, 4, 0, &cmd_gsg_on, sizeof(cmd_gsg_on) },
{ &cmd_gtso_on, 4, 0, &cmd_gtso_on, sizeof(cmd_gtso_on) },
- { &cmd_gufo_on, 4, 0, &cmd_gufo_on, sizeof(cmd_gufo_on) },
{ &cmd_ggso_on, 4, 0, &cmd_ggso_on, sizeof(cmd_ggso_on) },
{ &cmd_ggro_on, 4,0, &cmd_ggro_on, sizeof(cmd_ggro_on) },
{ &cmd_gflags_on, 4, 0, &cmd_gflags_on, sizeof(cmd_sflags_on) },
@@ -120,7 +112,6 @@ static const struct cmd_expect cmd_expect_set_features_off_old[] = {
{ &cmd_stxcsum_off, sizeof(cmd_stxcsum_off), 0, 0, 0 },
{ &cmd_ssg_off, sizeof(cmd_ssg_off), 0, 0, 0 },
{ &cmd_stso_off, sizeof(cmd_stso_off), 0, 0, 0 },
- { &cmd_sufo_off, sizeof(cmd_sufo_off), 0, 0, 0 },
{ &cmd_sgso_off, sizeof(cmd_sgso_off), 0, 0, 0 },
{ &cmd_sgro_off, sizeof(cmd_sgro_off), 0, 0, 0 },
{ &cmd_sflags_off, sizeof(cmd_sflags_off), 0, 0, 0 },
@@ -128,7 +119,6 @@ static const struct cmd_expect cmd_expect_set_features_off_old[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_sflags_off) },
@@ -141,7 +131,6 @@ static const struct cmd_expect cmd_expect_set_features_on_old[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -149,7 +138,6 @@ static const struct cmd_expect cmd_expect_set_features_on_old[] = {
{ &cmd_stxcsum_on, sizeof(cmd_stxcsum_on), 0, 0, 0 },
{ &cmd_ssg_on, sizeof(cmd_ssg_on), 0, 0, 0 },
{ &cmd_stso_on, sizeof(cmd_stso_on), 0, 0, 0 },
- { &cmd_sufo_on, sizeof(cmd_sufo_on), 0, 0, 0 },
{ &cmd_sgso_on, sizeof(cmd_sgso_on), 0, 0, 0 },
{ &cmd_sgro_on, sizeof(cmd_sgro_on), 0, 0, 0 },
{ &cmd_sflags_on, sizeof(cmd_sflags_on), 0, 0, 0 },
@@ -157,7 +145,6 @@ static const struct cmd_expect cmd_expect_set_features_on_old[] = {
{ &cmd_gtxcsum_on, 4, 0, &cmd_gtxcsum_on, sizeof(cmd_gtxcsum_on) },
{ &cmd_gsg_on, 4, 0, &cmd_gsg_on, sizeof(cmd_gsg_on) },
{ &cmd_gtso_on, 4, 0, &cmd_gtso_on, sizeof(cmd_gtso_on) },
- { &cmd_gufo_on, 4, 0, &cmd_gufo_on, sizeof(cmd_gufo_on) },
{ &cmd_ggso_on, 4, 0, &cmd_ggso_on, sizeof(cmd_ggso_on) },
{ &cmd_ggro_on, 4,0, &cmd_ggro_on, sizeof(cmd_ggro_on) },
{ &cmd_gflags_on, 4, 0, &cmd_gflags_on, sizeof(cmd_sflags_on) },
@@ -170,7 +157,6 @@ static const struct cmd_expect cmd_expect_set_features_unsup_on_old[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -290,7 +276,6 @@ static const struct cmd_expect cmd_expect_get_features_min_off[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -308,7 +293,6 @@ static const struct cmd_expect cmd_expect_get_features_max_on[] = {
{ &cmd_gtxcsum_on, 4, 0, &cmd_gtxcsum_on, sizeof(cmd_gtxcsum_on) },
{ &cmd_gsg_on, 4, 0, &cmd_gsg_on, sizeof(cmd_gsg_on) },
{ &cmd_gtso_on, 4, 0, &cmd_gtso_on, sizeof(cmd_gtso_on) },
- { &cmd_gufo_on, 4, 0, &cmd_gufo_on, sizeof(cmd_gufo_on) },
{ &cmd_ggso_on, 4, 0, &cmd_ggso_on, sizeof(cmd_ggso_on) },
{ &cmd_ggro_on, 4,0, &cmd_ggro_on, sizeof(cmd_ggro_on) },
{ &cmd_gflags_on, 4, 0, &cmd_gflags_on, sizeof(cmd_sflags_on) },
@@ -326,7 +310,6 @@ static const struct cmd_expect cmd_expect_set_features_min_off_min_on[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -338,7 +321,6 @@ static const struct cmd_expect cmd_expect_set_features_min_off_min_on[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_on, 4,0, &cmd_ggro_on, sizeof(cmd_ggro_on) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -356,7 +338,6 @@ static const struct cmd_expect cmd_expect_set_features_min_off_min_off[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -367,7 +348,6 @@ static const struct cmd_expect cmd_expect_set_features_min_off_min_off[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -385,7 +365,6 @@ static const struct cmd_expect cmd_expect_set_features_min_on_min_off[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_on, 4,0, &cmd_ggro_on, sizeof(cmd_ggro_on) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -396,7 +375,6 @@ static const struct cmd_expect cmd_expect_set_features_min_on_min_off[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -414,7 +392,6 @@ static const struct cmd_expect cmd_expect_set_features_min_off_unsup_on[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -425,7 +402,6 @@ static const struct cmd_expect cmd_expect_set_features_min_off_unsup_on[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -443,7 +419,6 @@ static const struct cmd_expect cmd_expect_set_features_ipv4_off_many_on[] = {
{ &cmd_gtxcsum_off, 4, 0, &cmd_gtxcsum_off, sizeof(cmd_gtxcsum_off) },
{ &cmd_gsg_off, 4, 0, &cmd_gsg_off, sizeof(cmd_gsg_off) },
{ &cmd_gtso_off, 4, 0, &cmd_gtso_off, sizeof(cmd_gtso_off) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_off, 4, 0, &cmd_ggso_off, sizeof(cmd_ggso_off) },
{ &cmd_ggro_off, 4,0, &cmd_ggro_off, sizeof(cmd_ggro_off) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -454,7 +429,6 @@ static const struct cmd_expect cmd_expect_set_features_ipv4_off_many_on[] = {
{ &cmd_gtxcsum_on, 4, 0, &cmd_gtxcsum_on, sizeof(cmd_gtxcsum_on) },
{ &cmd_gsg_on, 4, 0, &cmd_gsg_on, sizeof(cmd_gsg_on) },
{ &cmd_gtso_on, 4, 0, &cmd_gtso_on, sizeof(cmd_gtso_on) },
- { &cmd_gufo_off, 4, 0, &cmd_gufo_off, sizeof(cmd_gufo_off) },
{ &cmd_ggso_on, 4, 0, &cmd_ggso_on, sizeof(cmd_ggso_on) },
{ &cmd_ggro_on, 4,0, &cmd_ggro_on, sizeof(cmd_ggro_on) },
{ &cmd_gflags_off, 4, 0, &cmd_gflags_off, sizeof(cmd_gflags_off) },
@@ -471,18 +445,18 @@ static struct test_case {
{ 0, "-k devname", cmd_expect_get_features_off_old },
{ 0, "-k dev_unsup", cmd_expect_get_features_off_old_some_unsup },
{ 0, "-k dev_priv", cmd_expect_get_features_off_old_some_priv },
- { 0, "-K devname rx off tx off sg off tso off ufo off gso off lro off rxvlan off txvlan off ntuple off rxhash off gro off",
+ { 0, "-K devname rx off tx off sg off tso off gso off lro off rxvlan off txvlan off ntuple off rxhash off gro off",
cmd_expect_set_features_off_old },
- { 0, "-K devname rx on tx on sg on tso on ufo on gso on lro on rxvlan on txvlan on ntuple on rxhash on gro on",
+ { 0, "-K devname rx on tx on sg on tso on gso on lro on rxvlan on txvlan on ntuple on rxhash on gro on",
cmd_expect_set_features_on_old },
{ 1, "-K devname tx on sg on", cmd_expect_set_features_unsup_on_old },
{ 0, "--show-offload devname", cmd_expect_get_features_min_off },
{ 0, "--show-features devname", cmd_expect_get_features_max_on },
- { 0, "-K devname rx on tx on sg on tso on ufo on gso on gro on",
+ { 0, "-K devname rx on tx on sg on tso on gso on gro on",
cmd_expect_set_features_min_off_min_on },
- { 0, "-K devname rx off tx off sg off tso off ufo off gso off gro off",
+ { 0, "-K devname rx off tx off sg off tso off gso off gro off",
cmd_expect_set_features_min_off_min_off },
- { 0, "-K devname rx off tx off sg off tso off ufo off gso off gro off",
+ { 0, "-K devname rx off tx off sg off tso off gso off gro off",
cmd_expect_set_features_min_on_min_off },
{ 1, "-K devname tx on sg on",
cmd_expect_set_features_min_off_unsup_on },
--
1.8.3.1
^ permalink raw reply related
* Re: PTP: PHY timestamping when MAC is PTP capable
From: Richard Cochran @ 2017-08-28 12:33 UTC (permalink / raw)
To: Sørensen, Stefan; +Cc: netdev@vger.kernel.org
In-Reply-To: <1503909582.2455.2.camel@spectralink.com>
On Mon, Aug 28, 2017 at 08:39:44AM +0000, Sørensen, Stefan wrote:
> I have run into a problem with packet timestamping on a platform (cpsw
> + dp83640) where both the PHY and the MAC is PTP capable and I need
> the PHY to perform the timestamping. In the current code,
> SIOCGHWTSTAMP is passed to the MAC driver and only if it does not
> support PTP itself will it pass it on to the PHY driver.
>
> I see two ways to fix this:
Just disable CONFIG_CPTS and patch cpsw.c to pass SIOC[GS]HWTSTAMP.
I don't see any reasonable way to make this sort of thing configurable
at run time.
Thanks,
Richard
^ permalink raw reply
* Re: [patch net-next 2/3] net/sched: Change cls_flower to use IDR
From: Simon Horman @ 2017-08-28 11:37 UTC (permalink / raw)
To: Chris Mi; +Cc: netdev, jhs, xiyou.wangcong, jiri, davem, mawilcox
In-Reply-To: <1503902477-39829-3-git-send-email-chrism@mellanox.com>
On Mon, Aug 28, 2017 at 02:41:16AM -0400, Chris Mi wrote:
> Currently, all filters with the same priority are linked in a doubly
> linked list. Every filter should have a unique handle. To make the
> handle unique, we need to iterate the list every time to see if the
> handle exists or not when inserting a new filter. It is time-consuming.
> For example, it takes about 5m3.169s to insert 64K rules.
>
> This patch changes cls_flower to use IDR. With this patch, it
> takes about 0m1.127s to insert 64K rules. The improvement is huge.
Very nice :)
> But please note that in this testing, all filters share the same action.
> If every filter has a unique action, that is another bottleneck.
> Follow-up patch in this patchset addresses that.
>
> Signed-off-by: Chris Mi <chrism@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> net/sched/cls_flower.c | 55 +++++++++++++++++++++-----------------------------
> 1 file changed, 23 insertions(+), 32 deletions(-)
>
> diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
> index bd9dab4..3d041d2 100644
> --- a/net/sched/cls_flower.c
> +++ b/net/sched/cls_flower.c
...
> @@ -890,6 +870,7 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> struct cls_fl_filter *fnew;
> struct nlattr **tb;
> struct fl_flow_mask mask = {};
> + unsigned long idr_index;
> int err;
>
> if (!tca[TCA_OPTIONS])
> @@ -920,13 +901,21 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> goto errout;
>
> if (!handle) {
> - handle = fl_grab_new_handle(tp, head);
> - if (!handle) {
> - err = -EINVAL;
> + err = idr_alloc_ext(&head->handle_idr, fnew, &idr_index,
> + 1, 0x80000000, GFP_KERNEL);
> + if (err)
> goto errout;
> - }
> + fnew->handle = idr_index;
> + }
> +
> + /* user specifies a handle and it doesn't exist */
> + if (handle && !fold) {
> + err = idr_alloc_ext(&head->handle_idr, fnew, &idr_index,
> + handle, handle + 1, GFP_KERNEL);
> + if (err)
> + goto errout;
> + fnew->handle = idr_index;
> }
> - fnew->handle = handle;
>
> if (tb[TCA_FLOWER_FLAGS]) {
> fnew->flags = nla_get_u32(tb[TCA_FLOWER_FLAGS]);
> @@ -980,6 +969,8 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
> *arg = fnew;
>
> if (fold) {
> + fnew->handle = handle;
Can it be the case that fold is non-NULL and handle is zero?
The handling of that case seem to have changed in this patch.
> + idr_replace_ext(&head->handle_idr, fnew, fnew->handle);
> list_replace_rcu(&fold->list, &fnew->list);
> tcf_unbind_filter(tp, &fold->res);
> call_rcu(&fold->rcu, fl_destroy_filter);
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] net: mvpp2: do not force the link mode
From: Antoine Tenart @ 2017-08-28 11:32 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, Marcin Wojtas, David S. Miller, kishon,
Andrew Lunn, Jason Cooper, Sebastian Hesselbarth,
Gregory Clément, Thomas Petazzoni, nadavh, linux-kernel,
Stefan Chulski, Miquèl Raynal, netdev
In-Reply-To: <20170828110624.GG20805@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]
On Mon, Aug 28, 2017 at 12:06:24PM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 28, 2017 at 11:40:51AM +0200, Antoine Tenart wrote:
> > On Mon, Aug 28, 2017 at 09:51:52AM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Aug 28, 2017 at 10:38:37AM +0200, Marcin Wojtas wrote:
> > > >
> > > > Can you be 100% sure that when using SGMII with PHY's (like Marvell
> > > > Alaska 88E1xxx series), is in-band link information always available?
> > > > I'd be very cautious with such assumption and use in-band management
> > > > only when set in the DT, like mvneta. I think phylib can properly can
> > > > do its work when MDIO connection is provided on the board.
> > >
> > > There is another issue to be aware of: if you're wanting to use flow
> > > control autonegotiation, that is not carried across SGMII's in-band
> > > signalling. If you want to use SGMII's in-band signalling for the
> > > duplex and speed information, you still need phylib's notification
> > > to properly set the flow control.
> > >
> > > <plug>
> > > Switching mvpp2 to use phylink (which is needed for the 1G SFP slot on
> > > mcbin) will handle all this for you - dealing with both in-band and
> > > out-of-band negotiation methods, and combining them in the appropriate
> > > manner for the selected operation mode.
> > > </plug>
> >
> > So probably the best move here is to remove this patch, and wait for the
> > phylink support in the PPv2 driver.
>
> I've nothing on that specifically for the mvpp2 driver - what I have is
> for mvneta and the Marvell mvpp2x driver, with GMAC support extracted
> from mvneta (that last bit is rather dirty at the moment so not
> published anywhere, and doesn't cater for PP v2.1 at all.)
>
> I ought to have posted the mvneta part of the phylink patches, but I
> didn't get around to it early enough in this cycle - there are probably
> quite a number of conflicts with net-next now, so I think it's too late
> to submit it for mainline.
>
> I know Andrew has already looked at them in my git tree as part of the
> review of phylink when that was merged - which should be adequate to
> give an example of how to implement it for the mainline PP v2 driver.
OK, good. When looking at the phylink support in the PPv2 driver we'll
look into what you did for mvneta (I saw it as well on your tree). In
the meantime I'll respin this series without this patch.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] net: mvpp2: do not force the link mode
From: Russell King - ARM Linux @ 2017-08-28 11:06 UTC (permalink / raw)
To: Antoine Tenart
Cc: Marcin Wojtas, David S. Miller, kishon, Andrew Lunn, Jason Cooper,
Sebastian Hesselbarth, Gregory Clément, Thomas Petazzoni,
nadavh, linux-kernel, Stefan Chulski, Miquèl Raynal, netdev
In-Reply-To: <20170828094051.GE2568@kwain>
On Mon, Aug 28, 2017 at 11:40:51AM +0200, Antoine Tenart wrote:
> On Mon, Aug 28, 2017 at 09:51:52AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Aug 28, 2017 at 10:38:37AM +0200, Marcin Wojtas wrote:
> > >
> > > Can you be 100% sure that when using SGMII with PHY's (like Marvell
> > > Alaska 88E1xxx series), is in-band link information always available?
> > > I'd be very cautious with such assumption and use in-band management
> > > only when set in the DT, like mvneta. I think phylib can properly can
> > > do its work when MDIO connection is provided on the board.
> >
> > There is another issue to be aware of: if you're wanting to use flow
> > control autonegotiation, that is not carried across SGMII's in-band
> > signalling. If you want to use SGMII's in-band signalling for the
> > duplex and speed information, you still need phylib's notification
> > to properly set the flow control.
> >
> > <plug>
> > Switching mvpp2 to use phylink (which is needed for the 1G SFP slot on
> > mcbin) will handle all this for you - dealing with both in-band and
> > out-of-band negotiation methods, and combining them in the appropriate
> > manner for the selected operation mode.
> > </plug>
>
> So probably the best move here is to remove this patch, and wait for the
> phylink support in the PPv2 driver.
I've nothing on that specifically for the mvpp2 driver - what I have is
for mvneta and the Marvell mvpp2x driver, with GMAC support extracted
from mvneta (that last bit is rather dirty at the moment so not
published anywhere, and doesn't cater for PP v2.1 at all.)
I ought to have posted the mvneta part of the phylink patches, but I
didn't get around to it early enough in this cycle - there are probably
quite a number of conflicts with net-next now, so I think it's too late
to submit it for mainline.
I know Andrew has already looked at them in my git tree as part of the
review of phylink when that was merged - which should be adequate to
give an example of how to implement it for the mainline PP v2 driver.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH] dt-binding: net/phy: fix interrupts description
From: Baruch Siach @ 2017-08-28 10:20 UTC (permalink / raw)
To: David S. Miller
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Mark Rutland
In-Reply-To: <b3756346473feadfeba70ecb71960cad48e66621.1503468660.git.baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
Hi Dave,
On Wed, Aug 23, 2017 at 09:11:00AM +0300, Baruch Siach wrote:
> Commit b053dc5a722ea (powerpc: Refactor device tree binding) split the
> Ethernet PHY binding documentation out of the big booting-without-of.txt
> file, leaving a dangling reference to "section 2" in the 'interrupts'
> property description. Drop that reference, and make the description look
> more like the rest.
>
> While at it, make the example interrupt-parent phandle look more like a
> real world phandle, and use an IRQ_TYPE_ macro for the 'interrupts'
> type.
This patch is now marked 'Not Applicable' in the netdev patchwork. Why is
that? Should it go through some other tree?
baruch
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index b55857696fc3..86ba72af6163 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -2,11 +2,7 @@ PHY nodes
>
> Required properties:
>
> - - interrupts : <a b> where a is the interrupt number and b is a
> - field that represents an encoding of the sense and level
> - information for the interrupt. This should be encoded based on
> - the information in section 2) depending on the type of interrupt
> - controller you have.
> + - interrupts : interrupt specifier for the sole interrupt.
> - interrupt-parent : the phandle for the interrupt controller that
> services interrupts for this device.
> - reg : The ID number for the phy, usually a small integer
> @@ -56,7 +52,7 @@ Example:
>
> ethernet-phy@0 {
> compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22";
> - interrupt-parent = <40000>;
> - interrupts = <35 1>;
> + interrupt-parent = <&PIC>;
> + interrupts = <35 IRQ_TYPE_EDGE_RISING>;
> reg = <0>;
> };
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: DSA support for Micrel KSZ8895
From: Pavel Machek @ 2017-08-28 10:14 UTC (permalink / raw)
To: Woojung.Huh
Cc: nathan.leigh.conrad, vivien.didelot, f.fainelli, netdev,
linux-kernel, Tristram.Ha, andrew
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40B05FFF@CHN-SV-EXMX02.mchp-main.com>
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
Hi!
> > > I'll forward your email to our support.
> > > AFAIK, KSZ8895 has different register mapping from KSZ9477,
> > > it will be more than ID changes in current driver.
> >
> > More than ID changes, indeed. As layout is completely different, it
> > looks like different source file will be needed for support.
> >
> > I'm not nearly there; but I can ifconfig lanX up, already, and perform
> > some pings.
> >
> > Any ideas how to do the work in a way to minimize code duplication are
> > welcome...
>
> Which version do you use to create patch?
> Getting error when applying patch to the latest net-next.
I'm working at 4.13-rc.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/4] net/core: Add violation counters to VF statisctics
From: Saeed Mahameed @ 2017-08-28 9:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Saeed Mahameed, David S. Miller, Linux Netdev List,
Eugenia Emantayev
In-Reply-To: <20170827204306.0fb98e31@cakuba>
On Mon, Aug 28, 2017 at 3:43 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Sun, 27 Aug 2017 14:06:17 +0300, Saeed Mahameed wrote:
>> From: Eugenia Emantayev <eugenia@mellanox.com>
>>
>> Add receive and transmit violation counters to be
>> displayed in iproute2 VF statistics.
>>
>> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
>> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
>> ---
>> include/linux/if_link.h | 2 ++
>> include/uapi/linux/if_link.h | 2 ++
>> net/core/rtnetlink.c | 10 +++++++++-
>> 3 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
>> index da70af27e42e..ebf3448acb5b 100644
>> --- a/include/linux/if_link.h
>> +++ b/include/linux/if_link.h
>> @@ -12,6 +12,8 @@ struct ifla_vf_stats {
>> __u64 tx_bytes;
>> __u64 broadcast;
>> __u64 multicast;
>> + __u64 rx_dropped;
>> + __u64 tx_dropped;
>
> I'm a little concerned that you call those violation counters in the
> commit message. Do you expect them to only be used if the VF traffic
> indeed violates some admin-set rules? I would imaging HW/FW may drop
> frames in certain situations and naming the counters *_dropped suggests
> it would be OK to increment them even if the drop reason was not any
> sort of violation. Would you mind clarifying?
Yes, the rx/tx_dropped counters serve as a general purpose VF drop
counter including VF violations.
We will fix the commit message.
Thanks !
Saeed.
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: Add SRIOV VGT+ support
From: Saeed Mahameed @ 2017-08-28 9:50 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Saeed Mahameed, David S. Miller, Linux Netdev List,
Eugenia Emantayev, Mohamad Haj Yahia
In-Reply-To: <20170827203857.369c2b16@cakuba>
On Mon, Aug 28, 2017 at 3:38 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Sun, 27 Aug 2017 14:06:15 +0300, Saeed Mahameed wrote:
>> From: Mohamad Haj Yahia <mohamad@mellanox.com>
>>
>> VGT+ is a security feature that gives the administrator the ability of
>> controlling the allowed vlan-ids list that can be transmitted/received
>> from/to the VF.
>> The allowed vlan-ids list is called "trunk".
>> Admin can add/remove a range of allowed vlan-ids via iptool.
>> Example:
>> After this series of configuration :
>> 1) ip link set eth3 vf 0 trunk add 10 100 (allow vlan-id 10-100, default tpid 0x8100)
>> 2) ip link set eth3 vf 0 trunk add 105 proto 802.1q (allow vlan-id 105 tpid 0x8100)
>> 3) ip link set eth3 vf 0 trunk add 105 proto 802.1ad (allow vlan-id 105 tpid 0x88a8)
>> 4) ip link set eth3 vf 0 trunk rem 90 (block vlan-id 90)
>> 5) ip link set eth3 vf 0 trunk rem 50 60 (block vlan-ids 50-60)
>>
>> The VF 0 can only communicate on vlan-ids: 10-49,61-89,91-100,105 with
>> tpid 0x8100 and vlan-id 105 with tpid 0x88a8.
>>
>> For this purpose we added the following netlink sr-iov commands:
>>
>> 1) IFLA_VF_VLAN_RANGE: used to add/remove allowed vlan-ids range.
>> We added the ifla_vf_vlan_range struct to specify the range we want to
>> add/remove from the userspace.
>> We added ndo_add_vf_vlan_trunk_range and ndo_del_vf_vlan_trunk_range
>> netdev ops to add/remove allowed vlan-ids range in the netdev.
>>
>> 2) IFLA_VF_VLAN_TRUNK: used to query the allowed vlan-ids trunk.
>> We added trunk bitmap to the ifla_vf_info struct to get the current
>> allowed vlan-ids trunk from the netdev.
>> We added ifla_vf_vlan_trunk struct for sending the allowed vlan-ids
>> trunk to the userspace.
>>
>> Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com>
>> Signed-off-by: Eugenia Emantayev <eugenia@mellanox.com>
>> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
>
> Interesting work, I have some minor questions if you don't mind :)
>
Hi Jakub, Thanks for the review.
> I was under impression that "trunk" is a vendor-specific term, would it
> make sense to drop it from the APIs?
>
Well, the term trunk is widely used in switches APIs and since those
patches refer to SRIOV architecture
where an E-Switch is running in the HW level operating as an L2
switch, I think it makes sense to use the same term for the
same functionality we already have in the switches.
>> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>> index 8d062c58d5cb..3aa895c5fbc1 100644
>> --- a/include/uapi/linux/if_link.h
>> +++ b/include/uapi/linux/if_link.h
>> @@ -168,6 +168,8 @@ enum {
>> #ifndef __KERNEL__
>> #define IFLA_RTA(r) ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifinfomsg))))
>> #define IFLA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifinfomsg))
>> +#define BITS_PER_BYTE 8
>> +#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
>> #endif
>>
>> enum {
>> @@ -645,6 +647,8 @@ enum {
>> IFLA_VF_IB_NODE_GUID, /* VF Infiniband node GUID */
>> IFLA_VF_IB_PORT_GUID, /* VF Infiniband port GUID */
>> IFLA_VF_VLAN_LIST, /* nested list of vlans, option for QinQ */
>> + IFLA_VF_VLAN_RANGE, /* add/delete vlan range filtering */
>> + IFLA_VF_VLAN_TRUNK, /* vlan trunk filtering */
>> __IFLA_VF_MAX,
>> };
>>
>> @@ -669,6 +673,7 @@ enum {
>>
>> #define IFLA_VF_VLAN_INFO_MAX (__IFLA_VF_VLAN_INFO_MAX - 1)
>> #define MAX_VLAN_LIST_LEN 1
>> +#define VF_VLAN_N_VID 4096
>>
>> struct ifla_vf_vlan_info {
>> __u32 vf;
>> @@ -677,6 +682,21 @@ struct ifla_vf_vlan_info {
>> __be16 vlan_proto; /* VLAN protocol either 802.1Q or 802.1ad */
>> };
>>
>> +struct ifla_vf_vlan_range {
>> + __u32 vf;
>> + __u32 start_vid; /* 1 - 4095 */
>> + __u32 end_vid; /* 1 - 4095 */
>> + __u32 setting;
>> + __be16 vlan_proto; /* VLAN protocol either 802.1Q or 802.1ad */
>> +};
>> +
>> +#define VF_VLAN_BITMAP DIV_ROUND_UP(VF_VLAN_N_VID, sizeof(__u64) * BITS_PER_BYTE)
>> +struct ifla_vf_vlan_trunk {
>> + __u32 vf;
>> + __u64 allowed_vlans_8021q_bm[VF_VLAN_BITMAP];
>> + __u64 allowed_vlans_8021ad_bm[VF_VLAN_BITMAP];
>> +};
>
> Would you mind explaining why you chose to make the API asymmetrical
> like that? I mean the set operation is range-based, yet the get
> returns a bitmask. You seem to solely depend on the bitmasks in the
> driver anyway...
>
It is not about driver dependency, simply we would like to store the
allowed vlan in a simple data structure and bitmap is
the simplest form, otherwise we would complicate the APIs to transfer
Lists and ranges back and forth between userspace and kernel.
>> struct ifla_vf_tx_rate {
>> __u32 vf;
>> __u32 rate; /* Max TX bandwidth in Mbps, 0 disables throttling */
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index a78fd61da0ec..56909f11d88e 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -827,6 +827,7 @@ static inline int rtnl_vfinfo_size(const struct net_device *dev,
>> nla_total_size(MAX_VLAN_LIST_LEN *
>> sizeof(struct ifla_vf_vlan_info)) +
>> nla_total_size(sizeof(struct ifla_vf_spoofchk)) +
>> + nla_total_size(sizeof(struct ifla_vf_vlan_trunk)) +
>> nla_total_size(sizeof(struct ifla_vf_tx_rate)) +
>> nla_total_size(sizeof(struct ifla_vf_rate)) +
>> nla_total_size(sizeof(struct ifla_vf_link_state)) +
>> @@ -1098,31 +1099,43 @@ static noinline_for_stack int rtnl_fill_vfinfo(struct sk_buff *skb,
>> struct ifla_vf_link_state vf_linkstate;
>> struct ifla_vf_vlan_info vf_vlan_info;
>> struct ifla_vf_spoofchk vf_spoofchk;
>> + struct ifla_vf_vlan_trunk *vf_trunk;
>> struct ifla_vf_tx_rate vf_tx_rate;
>> struct ifla_vf_stats vf_stats;
>> struct ifla_vf_trust vf_trust;
>> struct ifla_vf_vlan vf_vlan;
>> struct ifla_vf_rate vf_rate;
>> struct ifla_vf_mac vf_mac;
>> - struct ifla_vf_info ivi;
>> + struct ifla_vf_info *ivi;
>>
>> - memset(&ivi, 0, sizeof(ivi));
>> + ivi = kzalloc(sizeof(*ivi), GFP_KERNEL);
>> + if (!ivi)
>> + return -ENOMEM;
>
> In the future please try to split code adjustments like allocating ivi
> here into a separate patch. Makes the changes a little more obvious to
> read.
Since we extended ivi struct, it passed the stack limit, so we did it
in the same patch,
but I agree it would simplify the review to break it into two pieces.
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] net: mvpp2: do not force the link mode
From: Antoine Tenart @ 2017-08-28 9:40 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Marcin Wojtas, Antoine Tenart, David S. Miller, kishon,
Andrew Lunn, Jason Cooper, Sebastian Hesselbarth,
Gregory Clément, Thomas Petazzoni, nadavh, linux-kernel,
Stefan Chulski, Miquèl Raynal, netdev
In-Reply-To: <20170828085152.GF20805@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Mon, Aug 28, 2017 at 09:51:52AM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 28, 2017 at 10:38:37AM +0200, Marcin Wojtas wrote:
> >
> > Can you be 100% sure that when using SGMII with PHY's (like Marvell
> > Alaska 88E1xxx series), is in-band link information always available?
> > I'd be very cautious with such assumption and use in-band management
> > only when set in the DT, like mvneta. I think phylib can properly can
> > do its work when MDIO connection is provided on the board.
>
> There is another issue to be aware of: if you're wanting to use flow
> control autonegotiation, that is not carried across SGMII's in-band
> signalling. If you want to use SGMII's in-band signalling for the
> duplex and speed information, you still need phylib's notification
> to properly set the flow control.
>
> <plug>
> Switching mvpp2 to use phylink (which is needed for the 1G SFP slot on
> mcbin) will handle all this for you - dealing with both in-band and
> out-of-band negotiation methods, and combining them in the appropriate
> manner for the selected operation mode.
> </plug>
So probably the best move here is to remove this patch, and wait for the
phylink support in the PPv2 driver.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] xen-netback: update ubuf_info initialization to anonymous union
From: Wei Liu @ 2017-08-28 9:16 UTC (permalink / raw)
To: Willem de Bruijn
Cc: netdev, davem, wei.liu2, paul.durrant, kbuild-all,
Willem de Bruijn
In-Reply-To: <20170825171043.84011-1-willemdebruijn.kernel@gmail.com>
On Fri, Aug 25, 2017 at 01:10:43PM -0400, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> The xen driver initializes struct ubuf_info fields using designated
> initializers. I recently moved these fields inside a nested anonymous
> struct inside an anonymous union. I had missed this use case.
>
> This breaks compilation of xen-netback with older compilers.
> From kbuild bot with gcc-4.4.7:
>
> drivers/net//xen-netback/interface.c: In function
> 'xenvif_init_queue':
> >> drivers/net//xen-netback/interface.c:554: error: unknown field 'ctx' specified in initializer
> >> drivers/net//xen-netback/interface.c:554: warning: missing braces around initializer
> drivers/net//xen-netback/interface.c:554: warning: (near initialization for '(anonymous).<anonymous>')
> >> drivers/net//xen-netback/interface.c:554: warning: initialization makes integer from pointer without a cast
> >> drivers/net//xen-netback/interface.c:555: error: unknown field 'desc' specified in initializer
>
> Add double braces around the designated initializers to match their
> nested position in the struct. After this, compilation succeeds again.
>
> Fixes: 4ab6c99d99bb ("sock: MSG_ZEROCOPY notification coalescing")
> Reported-by: kbuild bot <lpk@intel.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
^ permalink raw reply
* pull-request: wireless-drivers-next 2017-08-28
From: Kalle Valo @ 2017-08-28 9:22 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next for 4.14. Because I pulled
wireless-drivers (at least that's my suspicion) the diffstat was wrong
again and I created it manually. I recall Linus somewhere saying that in
certain cases this is normal and it's ok to create the diffstat
manually, so I don't worry about this anymore.
In this pull request we also add SDIO_DEVICE_ID_CYPRESS_4373 to
include/linux/mmc/sdio_ids.h which stands out in the diffstat.
Please let me know if there are any problems.
Kalle
The following changes since commit e9bf53ab1ee34bb05c104bbfd2b77c844773f8e6:
brcmfmac: feature check for multi-scheduled scan fails on bcm4343x devices (2017-08-14 11:09:30 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-08-28
for you to fetch changes up to 5307eca1362492ce28f1572b430997d9053c021d:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git (2017-08-24 14:47:42 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.14
rsi driver is getting a lot of new features lately, but as usual
active development happening on iwlwifi as well as other drivers.
I pulled wireless-drivers to fix multiple conflicts in iwlwifi and to
make it easier further development.
Major changes:
ath10k
* initial UBS bus support (no full support yet)
* add tdls support for 10.4 firmware
ath9k
* add Dell Wireless 1802
wil6210
* support FW RSSI reporting
rsi
* support legacy power save, U-APSD, rf-kill and AP mode
* RTS threshold configuration
brcmfmac
* support CYW4373 SDIO/USB chipset
iwlwifi
* some more code moved to a new directory
* add new PCI ID for 7265D
----------------------------------------------------------------
Arvind Yadav (19):
ar5523: constify usb_device_id
carl9170: constify usb_device_id
at76c50x: constify usb_device_id
orinoco: constify usb_device_id
p54: constify usb_device_id
libertas: constify usb_device_id
libertas_tf: constify usb_device_id
mwifiex: constify usb_device_id
mt7601u: constify usb_device_id
rt2500usb: constify usb_device_id
rt2800usb: constify usb_device_id
rt73usb: constify usb_device_id
rtl8187: constify usb_device_id
rtl8xxxu: constify usb_device_id
rtl8192cu: constify usb_device_id
zd1201: constify usb_device_id
zd1211rw: constify usb_device_id
brcm80211: constify usb_device_id
net: rsi: mac80211: constify ieee80211_ops
Avraham Stern (1):
iwlwifi: mvm: remove session protection to allow channel switch
Bhumika Goyal (4):
wlcore: add const to bin_attribute structure
rtlwifi: constify rate_control_ops structure
iwlwifi: mvm: add const to thermal_cooling_device_ops structure
wireless: ipw2x00: make iw_handler_def const
Chaya Rachel Ivgi (2):
iwlwifi: mvm: add debugfs to force CT-kill
iwlwifi: mvm: set the default cTDP budget
Chi-Hsien Lin (1):
brcmfmac: Add support for CYW4373 SDIO/USB chipset
Christoph Fritz (1):
ath9k: fix debugfs file permission
Christophe Jaillet (1):
mt7601u: check memory allocation failure
Chung-Hsien Hsu (1):
brcmfmac: add setting carrier state ON for successful roaming
Colin Ian King (1):
rtlwifi: rtl8821ae: fix spelling mistake: "faill" -> "failed"
Dan Carpenter (1):
rtlwifi: make a couple arrays larger
Emmanuel Grumbach (10):
iwlwifi: pcie: don't init a Tx queue with an SSN > size of the queue
iwlwifi: pcie: free the TSO page when a Tx queue is unmapped on A000 devices
iwlwifi: mvm: fix the coex firmware API
iwlwifi: mvm: remove the corunning support
iwlwifi: mvm: support new Coex firmware API
iwlwifi: pcie: support short Tx queues for A000 device family
iwlwifi: mvm: add command name for FRAME_RELEASE
iwlwifi: mvm: include more debug data when we get an unexpected baid
iwlwifi: mvm: update the firmware API in TX
iwlwifi: mvm: don't send BAR on flushed frames
Erik Stromdahl (3):
ath10k: various usb related definitions
ath10k: add initial USB support
ath10k: sdio: fix compile warning
Ganapathi Bhat (3):
mwifiex: replace netif_carrier_on/off by netif_device_attach/dettach
mwifiex: do not use random MAC for pre-association scanning
mwifiex: check for NL80211_SCAN_FLAG_RANDOM_ADDR during hidden SSID scan
Golan Ben-Ami (2):
iwlwifi: dump smem configuration when firmware crashes
iwlwifi: fix nmi triggering from host
Gregory Greenman (1):
iwlwifi: mvm: change open and close criteria of a BA session
Gustavo A. R. Silva (1):
rtlwifi: btcoex: 23b 1ant: fix duplicated code for different branches
Haim Dreyfuss (1):
iwlwifi: mvm: support new beacon template command
Ilan Peer (1):
iwlwifi: mvm: Fix channel switch in case of count <= 1
Johannes Berg (2):
iwlwifi: mvm: remove useless condition in LED code
iwlwifi: mvm: use firmware LED command where applicable
João Paulo Rechi Vita (1):
iwlwifi: Demote messages about fw flags size to info
Kalle Valo (4):
Merge tag 'iwlwifi-next-for-kalle-2017-08-11' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge tag 'iwlwifi-next-for-kalle-2017-08-18' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Merge git://git.kernel.org/.../kvalo/wireless-drivers.git
Karun Eagalapati (6):
rsi: add support for legacy power save
rsi: add support for U-APSD power save
rsi: rename sdio_read_buffer_status_register
rsi: buffer full check optimization
rsi: buffer available interrupt handling
rsi: RTS threshold configuration
Liad Kaufman (1):
iwlwifi: fix a000 RF_ID define
Luca Coelho (14):
iwlwifi: fix a few instances of misaligned kerneldoc parameters
iwlwifi: remove references to unsupported HW
iwlwifi: mvm: consider RFKILL during INIT as success
iwlwifi: call iwl_remove_notification from iwl_wait_notification
iwlwifi: mvm: group all dummy SAR function declarations together
iwlwifi: mvm: use mvmsta consistently in rs.c
iwlwifi: move BT_MBOX_PRINT macro to common header
iwlwifi: pci: add new PCI ID for 7265D
iwlwifi: update channel flags parser
iwlwifi: add workaround to disable wide channels in 5GHz
iwlwifi: fw: fix lar_enabled endian problem in iwl_fw_get_nvm
iwlwifi: mvm: remove useless argument in iwl_nvm_init()
iwlwifi: mvm: remove useless check for mvm->cfg in iwl_parse_nvm_section()
iwlwifi: use big-endian for the hw section of the nvm
Manikanta Pubbisetty (3):
ath10k: extend wmi service map to accommodate new services
ath10k: add tdls support for 10.4 firmwares
ath10k: push peer type to target for TDLS peers
Matt Chen (1):
iwlwifi: mvm: don't send CTDP commands via debugfs if not supported
Matthias Frei (1):
ath10k: set a-mpdu receiver reference number
Michael Skeffington (1):
rt2x00: Fix MMIC Countermeasures
Pavani Muthyala (2):
rsi: add support for rf-kill functionality
rsi: update set_antenna command frame
Philipp Zabel (1):
ath10k: explicitly request exclusive reset control
Prameela Rani Garnepudi (12):
rsi: fix uninitialized descriptor pointer issue
rsi: advertise ap mode support
rsi: add interface changes for ap mode
rsi: remove interface changes for AP mode
rsi: add beacon changes for AP mode
rsi: handle station connection in AP mode
rsi: handle station disconnection in AP mode
rsi: data and managemet path changes for AP mode
rsi: use common descriptor for auto rate frame
rsi: update tx auto rate command frame for AP mode
rsi: aggregation parameters frame for AP mode
rsi: security enhancements for AP mode
Reizer, Eyal (1):
wlcore: add missing nvs file name info for wilink8
Rob Clark (1):
wcn36xx: check dma_mapping_error()
Romain Perier (1):
wireless: ipw2200: Replace PCI pool old API
Rosen Penev (1):
ath9k: Add Dell Wireless 1802 with wowlan capability
Sergey Matyukevich (8):
qtnfmac: remove unused qtnf_rx_frame declaration
qtnfmac: switch to napi_gro_receive
qtnfmac: use __netdev_alloc_skb_ip_align
qtnfmac: skb2rbd_attach cleanup
qtnfmac: decrease default Tx queue size
qtnfmac: switch to kernel circ_buf implementation
qtnfmac: introduce counter for Rx underflow events
qtnfmac: modify tx reclaim locking
Sharon Dvir (1):
iwlwifi: change functions that can only return 0 to void
Shaul Triebitz (2):
iwlwifi: mvm: move a000 device NVM retrieval to a common place
iwlwifi: mvm: add station before allocating a queue
Tzipi Peres (2):
iwlwifi: add support of FPGA fw
iwlwifi: distinguish different RF modules in A000 devices
Vincent Legoll (1):
bcma: make BCMA a menuconfig to ease disabling it all
Wright Feng (2):
brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/OPEN security mode
brcmfmac: fix wrong num_different_channels when mchan feature enabled
Xinming Hu (4):
mwifiex: Do not change bss_num in change_virtual_intf
mwifiex: wrapper wps ie in pass through tlv
mwifiex: p2p: use separate device address
mwifiex: uap: enable 11d based on userspace configruation
drivers/bcma/Kconfig | 9 +-
drivers/net/wireless/ath/ar5523/ar5523.c | 2 +-
drivers/net/wireless/ath/ath10k/Kconfig | 7 +
drivers/net/wireless/ath/ath10k/Makefile | 3 +
drivers/net/wireless/ath/ath10k/ahb.c | 15 +-
drivers/net/wireless/ath/ath10k/core.c | 10 +
drivers/net/wireless/ath/ath10k/core.h | 5 +
drivers/net/wireless/ath/ath10k/debug.h | 2 +
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 +-
drivers/net/wireless/ath/ath10k/hw.h | 5 +
drivers/net/wireless/ath/ath10k/mac.c | 5 +-
drivers/net/wireless/ath/ath10k/sdio.c | 8 +-
drivers/net/wireless/ath/ath10k/usb.c | 1106 +++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/usb.h | 128 ++++
drivers/net/wireless/ath/ath10k/wmi.c | 164 ++++-
drivers/net/wireless/ath/ath10k/wmi.h | 271 +++++++-
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/pci.c | 5 +
drivers/net/wireless/ath/carl9170/usb.c | 2 +-
drivers/net/wireless/ath/wcn36xx/dxe.c | 5 +
drivers/net/wireless/atmel/at76c50x-usb.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 18 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 11 +-
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 +
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 4 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 15 +-
drivers/net/wireless/intel/iwlwifi/Makefile | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 42 ++
drivers/net/wireless/intel/iwlwifi/dvm/commands.h | 8 +-
drivers/net/wireless/intel/iwlwifi/fw/api/coex.h | 62 +-
drivers/net/wireless/intel/iwlwifi/fw/api/commands.h | 17 +-
drivers/net/wireless/intel/iwlwifi/fw/api/config.h | 8 -
drivers/net/wireless/intel/iwlwifi/fw/api/led.h | 71 ++
drivers/net/wireless/intel/iwlwifi/fw/api/tx.h | 28 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 38 +-
drivers/net/wireless/intel/iwlwifi/fw/error-dump.h | 30 +
drivers/net/wireless/intel/iwlwifi/fw/file.h | 4 +
drivers/net/wireless/intel/iwlwifi/fw/notif-wait.c | 25 +-
drivers/net/wireless/intel/iwlwifi/fw/nvm.c | 162 +++++
drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 2 +
drivers/net/wireless/intel/iwlwifi/fw/smem.c | 3 +
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 3 +
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 11 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 36 +-
drivers/net/wireless/intel/iwlwifi/iwl-io.c | 14 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 116 +++-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 5 +-
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 13 +-
drivers/net/wireless/intel/iwlwifi/mvm/coex.c | 308 +--------
drivers/net/wireless/intel/iwlwifi/mvm/constants.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 54 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 69 +-
drivers/net/wireless/intel/iwlwifi/mvm/led.c | 59 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 47 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 16 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 37 +-
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 197 ++----
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 7 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 142 ++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 108 +--
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 7 +
drivers/net/wireless/intel/iwlwifi/mvm/time-event.c | 34 +-
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 9 +-
drivers/net/wireless/intel/iwlwifi/pcie/ctxt-info.c | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 24 +-
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 15 +-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 22 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 55 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 17 +-
drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 2 +-
drivers/net/wireless/intersil/p54/p54usb.c | 2 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 29 +-
drivers/net/wireless/marvell/mwifiex/join.c | 2 +-
drivers/net/wireless/marvell/mwifiex/main.c | 40 +-
drivers/net/wireless/marvell/mwifiex/main.h | 7 +
drivers/net/wireless/marvell/mwifiex/scan.c | 4 +-
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 34 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 2 +-
drivers/net/wireless/mediatek/mt7601u/dma.c | 5 +
drivers/net/wireless/mediatek/mt7601u/usb.c | 2 +-
drivers/net/wireless/quantenna/qtnfmac/bus.h | 1 -
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 279 ++++----
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h | 15 +-
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_ipc.h | 1 +
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_regs_pearl.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 13 +-
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 17 +-
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 2 +-
drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 10 +-
drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 5 +-
drivers/net/wireless/rsi/Makefile | 1 +
drivers/net/wireless/rsi/rsi_91x_core.c | 70 +-
drivers/net/wireless/rsi/rsi_91x_hal.c | 136 +++-
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 415 ++++++++++--
drivers/net/wireless/rsi/rsi_91x_main.c | 2 +
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 285 ++++++--
drivers/net/wireless/rsi/rsi_91x_ps.c | 146 ++++
drivers/net/wireless/rsi/rsi_91x_sdio.c | 2 +-
drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 40 +-
drivers/net/wireless/rsi/rsi_common.h | 1 +
drivers/net/wireless/rsi/rsi_hal.h | 4 +-
drivers/net/wireless/rsi/rsi_main.h | 38 +-
drivers/net/wireless/rsi/rsi_mgmt.h | 87 ++-
drivers/net/wireless/rsi/rsi_ps.h | 64 ++
drivers/net/wireless/rsi/rsi_sdio.h | 3 +-
drivers/net/wireless/ti/wlcore/main.c | 23 +
drivers/net/wireless/ti/wlcore/sdio.c | 1 +
drivers/net/wireless/ti/wlcore/spi.c | 1 +
drivers/net/wireless/ti/wlcore/sysfs.c | 2 +-
drivers/net/wireless/ti/wlcore/wlcore.h | 3 +
drivers/net/wireless/zydas/zd1201.c | 2 +-
drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 2 +-
include/linux/mmc/sdio_ids.h | 1 +
127 files changed, 4310 insertions(+), 1272 deletions(-)
create mode 100644 drivers/net/wireless/ath/ath10k/usb.c
create mode 100644 drivers/net/wireless/ath/ath10k/usb.h
create mode 100644 drivers/net/wireless/intel/iwlwifi/fw/api/led.h
create mode 100644 drivers/net/wireless/intel/iwlwifi/fw/nvm.c
create mode 100644 drivers/net/wireless/rsi/rsi_91x_ps.c
create mode 100644 drivers/net/wireless/rsi/rsi_ps.h
^ permalink raw reply
* Re: [PATCH 6/6] mpls: VPLS support
From: Amine Kherbouche @ 2017-08-28 9:21 UTC (permalink / raw)
To: David Lamparter, netdev, bridge; +Cc: roopa, stephen
In-Reply-To: <20170821171523.951260-7-equinox@diac24.net>
any opinion on vpls driver path ?
On 08/21/2017 07:15 PM, David Lamparter wrote:
> [work-in-progress, works but needs changes]
> [v2: refactored lots of things, e.g. dst_metadata, no more genetlink]
> [v4: removed pointless include/net/vpls.h, squashed pseudowire control
> word support, squashed netlink lwtunnel access bits]
>
> Signed-off-by: David Lamparter <equinox@diac24.net>
> ---
> include/net/dst_metadata.h | 24 ++
> include/uapi/linux/lwtunnel.h | 8 +
> net/core/lwtunnel.c | 1 +
> net/mpls/Kconfig | 11 +
> net/mpls/Makefile | 1 +
> net/mpls/vpls.c | 550 ++++++++++++++++++++++++++++++++++++++++++
> 6 files changed, 595 insertions(+)
> create mode 100644 net/mpls/vpls.c
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] net: mvpp2: do not force the link mode
From: Russell King - ARM Linux @ 2017-08-28 8:51 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Antoine Tenart, David S. Miller, kishon, Andrew Lunn,
Jason Cooper, Sebastian Hesselbarth, Gregory Clément,
Thomas Petazzoni, nadavh, linux-kernel, Stefan Chulski,
Miquèl Raynal, netdev
In-Reply-To: <CAPv3WKfSGfSAfade163-Q29SR5mxkV19LmYRxVdRBbfW-e-xfg@mail.gmail.com>
On Mon, Aug 28, 2017 at 10:38:37AM +0200, Marcin Wojtas wrote:
> Hi Antoine,
>
> Can you be 100% sure that when using SGMII with PHY's (like Marvell
> Alaska 88E1xxx series), is in-band link information always available?
> I'd be very cautious with such assumption and use in-band management
> only when set in the DT, like mvneta. I think phylib can properly can
> do its work when MDIO connection is provided on the board.
There is another issue to be aware of: if you're wanting to use flow
control autonegotiation, that is not carried across SGMII's in-band
signalling. If you want to use SGMII's in-band signalling for the
duplex and speed information, you still need phylib's notification
to properly set the flow control.
<plug>
Switching mvpp2 to use phylink (which is needed for the 1G SFP slot on
mcbin) will handle all this for you - dealing with both in-band and
out-of-band negotiation methods, and combining them in the appropriate
manner for the selected operation mode.
</plug>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* PTP: PHY timestamping when MAC is PTP capable
From: Sørensen, Stefan @ 2017-08-28 8:39 UTC (permalink / raw)
To: netdev@vger.kernel.org, richardcochran@gmail.com
Hi,
I have run into a problem with packet timestamping on a platform (cpsw
+ dp83640) where both the PHY and the MAC is PTP capable and I need
the PHY to perform the timestamping. In the current code,
SIOCGHWTSTAMP is passed to the MAC driver and only if it does not
support PTP itself will it pass it on to the PHY driver.
I see two ways to fix this:
1. Prefer PHY timestamping by passing SIOCGHWTSTAMP to the PHY
driver first, and only if it does not support PTP, pass is on to
the MAC driver. To me this seems reasonable as PHY timestamps
will usually be of better quality, and with a hardware design
using a PTP capable PHY you will most likely want to utilize
it. Note that the ethtool get_ts_info op takes this route and as
such may currently return incorrect info when both MAC and PHY is
PTP capable.
2. Let the user decide, by e.g. a new ethtool op.
For now I am using the patch below, but it does not seem quite right
to me.
Any suggestions on the best way forward?
Regards,
Stefan
---
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index 709a4e6fb447..52f4d2dfad11 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -4,6 +4,7 @@
#include <linux/rtnetlink.h>
#include <linux/net_tstamp.h>
#include <linux/wireless.h>
+#include <linux/phy.h>
#include <net/wext.h>
/*
@@ -316,6 +317,14 @@ static int dev_ifsioc(struct net *net, struct
ifreq *ifr, unsigned int cmd)
return err;
/* fall through */
+ case SIOCGHWTSTAMP:
+ if (dev->phydev) {
+ err = phy_mii_ioctl(dev->phydev, ifr, cmd);
+ if (err != -EOPNOTSUPP)
+ return err;
+ }
+ /* fall through */
+
/*
* Unknown or private ioctl
*/
^ permalink raw reply related
* Re: [PATCH] NFC: fix device-allocation error return
From: Johan Hovold @ 2017-08-28 8:39 UTC (permalink / raw)
To: Samuel Ortiz, David S. Miller
Cc: linux-wireless, netdev, Dan Carpenter, Johan Hovold, stable,
Greg Kroah-Hartman, linux-kernel, Andrew Morton, Ben Hutchings
In-Reply-To: <20170722133228.GE2729@localhost>
Samuel or David,
On Sat, Jul 22, 2017 at 03:32:28PM +0200, Johan Hovold wrote:
> On Sun, Jul 09, 2017 at 01:08:58PM +0200, Johan Hovold wrote:
> > A recent change fixing NFC device allocation itself introduced an
> > error-handling bug by returning an error pointer in case device-id
> > allocation failed. This is clearly broken as the callers still expected
> > NULL to be returned on errors as detected by Dan's static checker.
> >
> > Fix this up by returning NULL in the event that we've run out of memory
> > when allocating a new device id.
> >
> > Note that the offending commit is marked for stable (3.8) so this fix
> > needs to be backported along with it.
> >
> > Fixes: 20777bc57c34 ("NFC: fix broken device allocation")
> > Cc: stable <stable@vger.kernel.org> # 3.8
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> Could you apply this follow-up fix so that it can be backported along
> with the offending commit (which was just added to the stable queues)?
>
> We would only hit this error path if an ida allocation fails due to OOM;
> so while this is not critical, it would still be nice to get it fixed.
Another reminder about this one; can you apply it so we can get it into
4.14-rc1?
Note that the offending commit has now been backported to the stable
trees and we really want this trivial follow-up fix to be backported as
well.
Let me know if you want me to resend the patch.
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] net: mvpp2: do not force the link mode
From: Marcin Wojtas @ 2017-08-28 8:38 UTC (permalink / raw)
To: Antoine Tenart
Cc: Russell King - ARM Linux, David S. Miller, kishon, Andrew Lunn,
Jason Cooper, Sebastian Hesselbarth, Gregory Clément,
Thomas Petazzoni, nadavh, linux-kernel, Stefan Chulski,
Miquèl Raynal, netdev
In-Reply-To: <20170828065545.GC2568@kwain>
Hi Antoine,
2017-08-28 8:55 GMT+02:00 Antoine Tenart <antoine.tenart@free-electrons.com>:
> Hi Russell,
>
> On Fri, Aug 25, 2017 at 11:43:13PM +0100, Russell King - ARM Linux wrote:
>> On Fri, Aug 25, 2017 at 04:48:12PM +0200, Antoine Tenart wrote:
>> > The link mode (speed, duplex) was forced based on what the phylib
>> > returns. This should not be the case, and only forced by ethtool
>> > functions manually. This patch removes the link mode enforcement from
>> > the phylib link_event callback.
>>
>> So how does RGMII work (which has no in-band signalling between the PHY
>> and MAC)?
>>
>> phylib expects the network driver to configure it according to the PHY
>> state at link_event time - I think you need to explain more why you
>> think that this is not necessary.
>
> Good catch, this won't work properly with RGMII. This could be done
> out-of-band according to the spec, but that would use PHY polling and we
> do not want that (the same concern was raised by Andrew on another
> patch).
>
> I'll keep this mode enforcement for RGMII then.
>
Can you be 100% sure that when using SGMII with PHY's (like Marvell
Alaska 88E1xxx series), is in-band link information always available?
I'd be very cautious with such assumption and use in-band management
only when set in the DT, like mvneta. I think phylib can properly can
do its work when MDIO connection is provided on the board.
Did you check the change also on A375?
Best regards,
Marcin
^ permalink raw reply
* Re: [PATCH] net: sunrpc: svcsock: fix NULL-pointer exception
From: Vadim Lomovtsev @ 2017-08-28 8:38 UTC (permalink / raw)
To: J. Bruce Fields
Cc: trond.myklebust, anna.schumaker, jlayton, davem, linux-nfs,
netdev, linux-kernel, pabeni, vlomovts
In-Reply-To: <20170825220128.GA6276@fieldses.org>
On Fri, Aug 25, 2017 at 06:01:28PM -0400, J. Bruce Fields wrote:
> On Fri, Aug 18, 2017 at 06:00:47AM -0400, Vadim Lomovtsev wrote:
> > While running nfs/connectathon tests kernel NULL-pointer exception
> > has been observed due to races in svcsock.c.
> >
> > Race is appear when kernel accepts connection by kernel_accept
> > (which creates new socket) and start queuing ingress packets
> > to new socket. This happanes in ksoftirq context which concurrently
> > on a differnt core while new socket setup is not done yet.
> >
> > The fix is to re-order socket user data init sequence, add NULL-ptr
> > check before callback call along with barriers to prevent kernel crash.
> >
> > Test results: nfs/connectathon reports '0' failed tests for about 200+ iterations.
>
> By the way, is there anything special about your setup that allows you
> to reproduce this? There's nothing special about connectathon tests, so
> I'm just wondering why we haven't had a lot of reports of this.
>From what I have now - nothing special in test setup and/or configuration.
I believe it is because or high amount of CPU running. It was found at 32
cores CPU, while simply invoking test by "make run" command.
WBR,
Vadim
>
> --b.
>
> >
> > Crash log:
> > ---<-snip->---
> > [ 6708.638984] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > [ 6708.647093] pgd = ffff0000094e0000
> > [ 6708.650497] [00000000] *pgd=0000010ffff90003, *pud=0000010ffff90003, *pmd=0000010ffff80003, *pte=0000000000000000
> > [ 6708.660761] Internal error: Oops: 86000005 [#1] SMP
> > [ 6708.665630] Modules linked in: nfsv3 nfnetlink_queue nfnetlink_log nfnetlink rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache overlay xt_CONNSECMARK xt_SECMARK xt_conntrack iptable_security ip_tables ah4 xfrm4_mode_transport sctp tun binfmt_misc ext4 jbd2 mbcache loop tcp_diag udp_diag inet_diag rpcrdma ib_isert iscsi_target_mod ib_iser rdma_cm iw_cm libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_ucm ib_uverbs ib_umad ib_cm ib_core nls_koi8_u nls_cp932 ts_kmp nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack vfat fat ghash_ce sha2_ce sha1_ce cavium_rng_vf i2c_thunderx sg thunderx_edac i2c_smbus edac_core cavium_rng nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c nicvf nicpf ast i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysim
gblt fb_sys_fops
> > [ 6708.736446] ttm drm i2c_core thunder_bgx thunder_xcv mdio_thunder mdio_cavium dm_mirror dm_region_hash dm_log dm_mod [last unloaded: stap_3c300909c5b3f46dcacd49aab3334af_87021]
> > [ 6708.752275] CPU: 84 PID: 0 Comm: swapper/84 Tainted: G W OE 4.11.0-4.el7.aarch64 #1
> > [ 6708.760787] Hardware name: www.cavium.com CRB-2S/CRB-2S, BIOS 0.3 Mar 13 2017
> > [ 6708.767910] task: ffff810006842e80 task.stack: ffff81000689c000
> > [ 6708.773822] PC is at 0x0
> > [ 6708.776739] LR is at svc_data_ready+0x38/0x88 [sunrpc]
> > [ 6708.781866] pc : [<0000000000000000>] lr : [<ffff0000029d7378>] pstate: 60000145
> > [ 6708.789248] sp : ffff810ffbad3900
> > [ 6708.792551] x29: ffff810ffbad3900 x28: ffff000008c73d58
> > [ 6708.797853] x27: 0000000000000000 x26: ffff81000bbe1e00
> > [ 6708.803156] x25: 0000000000000020 x24: ffff800f7410bf28
> > [ 6708.808458] x23: ffff000008c63000 x22: ffff000008c63000
> > [ 6708.813760] x21: ffff800f7410bf28 x20: ffff81000bbe1e00
> > [ 6708.819063] x19: ffff810012412400 x18: 00000000d82a9df2
> > [ 6708.824365] x17: 0000000000000000 x16: 0000000000000000
> > [ 6708.829667] x15: 0000000000000000 x14: 0000000000000001
> > [ 6708.834969] x13: 0000000000000000 x12: 722e736f622e676e
> > [ 6708.840271] x11: 00000000f814dd99 x10: 0000000000000000
> > [ 6708.845573] x9 : 7374687225000000 x8 : 0000000000000000
> > [ 6708.850875] x7 : 0000000000000000 x6 : 0000000000000000
> > [ 6708.856177] x5 : 0000000000000028 x4 : 0000000000000000
> > [ 6708.861479] x3 : 0000000000000000 x2 : 00000000e5000000
> > [ 6708.866781] x1 : 0000000000000000 x0 : ffff81000bbe1e00
> > [ 6708.872084]
> > [ 6708.873565] Process swapper/84 (pid: 0, stack limit = 0xffff81000689c000)
> > [ 6708.880341] Stack: (0xffff810ffbad3900 to 0xffff8100068a0000)
> > [ 6708.886075] Call trace:
> > [ 6708.888513] Exception stack(0xffff810ffbad3710 to 0xffff810ffbad3840)
> > [ 6708.894942] 3700: ffff810012412400 0001000000000000
> > [ 6708.902759] 3720: ffff810ffbad3900 0000000000000000 0000000060000145 ffff800f79300000
> > [ 6708.910577] 3740: ffff000009274d00 00000000000003ea 0000000000000015 ffff000008c63000
> > [ 6708.918395] 3760: ffff810ffbad3830 ffff800f79300000 000000000000004d 0000000000000000
> > [ 6708.926212] 3780: ffff810ffbad3890 ffff0000080f88dc ffff800f79300000 000000000000004d
> > [ 6708.934030] 37a0: ffff800f7930093c ffff000008c63000 0000000000000000 0000000000000140
> > [ 6708.941848] 37c0: ffff000008c2c000 0000000000040b00 ffff81000bbe1e00 0000000000000000
> > [ 6708.949665] 37e0: 00000000e5000000 0000000000000000 0000000000000000 0000000000000028
> > [ 6708.957483] 3800: 0000000000000000 0000000000000000 0000000000000000 7374687225000000
> > [ 6708.965300] 3820: 0000000000000000 00000000f814dd99 722e736f622e676e 0000000000000000
> > [ 6708.973117] [< (null)>] (null)
> > [ 6708.977824] [<ffff0000086f9fa4>] tcp_data_queue+0x754/0xc5c
> > [ 6708.983386] [<ffff0000086fa64c>] tcp_rcv_established+0x1a0/0x67c
> > [ 6708.989384] [<ffff000008704120>] tcp_v4_do_rcv+0x15c/0x22c
> > [ 6708.994858] [<ffff000008707418>] tcp_v4_rcv+0xaf0/0xb58
> > [ 6709.000077] [<ffff0000086df784>] ip_local_deliver_finish+0x10c/0x254
> > [ 6709.006419] [<ffff0000086dfea4>] ip_local_deliver+0xf0/0xfc
> > [ 6709.011980] [<ffff0000086dfad4>] ip_rcv_finish+0x208/0x3a4
> > [ 6709.017454] [<ffff0000086e018c>] ip_rcv+0x2dc/0x3c8
> > [ 6709.022328] [<ffff000008692fc8>] __netif_receive_skb_core+0x2f8/0xa0c
> > [ 6709.028758] [<ffff000008696068>] __netif_receive_skb+0x38/0x84
> > [ 6709.034580] [<ffff00000869611c>] netif_receive_skb_internal+0x68/0xdc
> > [ 6709.041010] [<ffff000008696bc0>] napi_gro_receive+0xcc/0x1a8
> > [ 6709.046690] [<ffff0000014b0fc4>] nicvf_cq_intr_handler+0x59c/0x730 [nicvf]
> > [ 6709.053559] [<ffff0000014b1380>] nicvf_poll+0x38/0xb8 [nicvf]
> > [ 6709.059295] [<ffff000008697a6c>] net_rx_action+0x2f8/0x464
> > [ 6709.064771] [<ffff000008081824>] __do_softirq+0x11c/0x308
> > [ 6709.070164] [<ffff0000080d14e4>] irq_exit+0x12c/0x174
> > [ 6709.075206] [<ffff00000813101c>] __handle_domain_irq+0x78/0xc4
> > [ 6709.081027] [<ffff000008081608>] gic_handle_irq+0x94/0x190
> > [ 6709.086501] Exception stack(0xffff81000689fdf0 to 0xffff81000689ff20)
> > [ 6709.092929] fde0: 0000810ff2ec0000 ffff000008c10000
> > [ 6709.100747] fe00: ffff000008c70ef4 0000000000000001 0000000000000000 ffff810ffbad9b18
> > [ 6709.108565] fe20: ffff810ffbad9c70 ffff8100169d3800 ffff810006843ab0 ffff81000689fe80
> > [ 6709.116382] fe40: 0000000000000bd0 0000ffffdf979cd0 183f5913da192500 0000ffff8a254ce4
> > [ 6709.124200] fe60: 0000ffff8a254b78 0000aaab10339808 0000000000000000 0000ffff8a0c2a50
> > [ 6709.132018] fe80: 0000ffffdf979b10 ffff000008d6d450 ffff000008c10000 ffff000008d6d000
> > [ 6709.139836] fea0: 0000000000000054 ffff000008cd3dbc 0000000000000000 0000000000000000
> > [ 6709.147653] fec0: 0000000000000000 0000000000000000 0000000000000000 ffff81000689ff20
> > [ 6709.155471] fee0: ffff000008085240 ffff81000689ff20 ffff000008085244 0000000060000145
> > [ 6709.163289] ff00: ffff81000689ff10 ffff00000813f1e4 ffffffffffffffff ffff00000813f238
> > [ 6709.171107] [<ffff000008082eb4>] el1_irq+0xb4/0x140
> > [ 6709.175976] [<ffff000008085244>] arch_cpu_idle+0x44/0x11c
> > [ 6709.181368] [<ffff0000087bf3b8>] default_idle_call+0x20/0x30
> > [ 6709.187020] [<ffff000008116d50>] do_idle+0x158/0x1e4
> > [ 6709.191973] [<ffff000008116ff4>] cpu_startup_entry+0x2c/0x30
> > [ 6709.197624] [<ffff00000808e7cc>] secondary_start_kernel+0x13c/0x160
> > [ 6709.203878] [<0000000001bc71c4>] 0x1bc71c4
> > [ 6709.207967] Code: bad PC value
> > [ 6709.211061] SMP: stopping secondary CPUs
> > [ 6709.218830] Starting crashdump kernel...
> > [ 6709.222749] Bye!
> > ---<-snip>---
> >
> > Signed-off-by: Vadim Lomovtsev <vlomovts@redhat.com>
> > ---
> > net/sunrpc/svcsock.c | 24 ++++++++++++++++++------
> > 1 file changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> > index 2b720fa..b6496f3 100644
> > --- a/net/sunrpc/svcsock.c
> > +++ b/net/sunrpc/svcsock.c
> > @@ -421,7 +421,9 @@ static void svc_data_ready(struct sock *sk)
> > dprintk("svc: socket %p(inet %p), busy=%d\n",
> > svsk, sk,
> > test_bit(XPT_BUSY, &svsk->sk_xprt.xpt_flags));
> > - svsk->sk_odata(sk);
> > + rmb();
> > + if (svsk->sk_odata)
> > + svsk->sk_odata(sk);
> > if (!test_and_set_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags))
> > svc_xprt_enqueue(&svsk->sk_xprt);
> > }
> > @@ -437,7 +439,9 @@ static void svc_write_space(struct sock *sk)
> > if (svsk) {
> > dprintk("svc: socket %p(inet %p), write_space busy=%d\n",
> > svsk, sk, test_bit(XPT_BUSY, &svsk->sk_xprt.xpt_flags));
> > - svsk->sk_owspace(sk);
> > + rmb();
> > + if (svsk->sk_owspace)
> > + svsk->sk_owspace(sk);
> > svc_xprt_enqueue(&svsk->sk_xprt);
> > }
> > }
> > @@ -760,8 +764,12 @@ static void svc_tcp_listen_data_ready(struct sock *sk)
> > dprintk("svc: socket %p TCP (listen) state change %d\n",
> > sk, sk->sk_state);
> >
> > - if (svsk)
> > - svsk->sk_odata(sk);
> > + if (svsk) {
> > + rmb();
> > + if (svsk->sk_odata)
> > + svsk->sk_odata(sk);
> > + }
> > +
> > /*
> > * This callback may called twice when a new connection
> > * is established as a child socket inherits everything
> > @@ -794,7 +802,10 @@ static void svc_tcp_state_change(struct sock *sk)
> > if (!svsk)
> > printk("svc: socket %p: no user data\n", sk);
> > else {
> > - svsk->sk_ostate(sk);
> > + rmb();
> > + if (svsk->sk_ostate)
> > + svsk->sk_ostate(sk);
> > +
> > if (sk->sk_state != TCP_ESTABLISHED) {
> > set_bit(XPT_CLOSE, &svsk->sk_xprt.xpt_flags);
> > svc_xprt_enqueue(&svsk->sk_xprt);
> > @@ -1381,12 +1392,13 @@ static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
> > return ERR_PTR(err);
> > }
> >
> > - inet->sk_user_data = svsk;
> > svsk->sk_sock = sock;
> > svsk->sk_sk = inet;
> > svsk->sk_ostate = inet->sk_state_change;
> > svsk->sk_odata = inet->sk_data_ready;
> > svsk->sk_owspace = inet->sk_write_space;
> > + wmb();
> > + inet->sk_user_data = svsk;
> >
> > /* Initialize the socket */
> > if (sock->type == SOCK_DGRAM)
> > --
> > 1.8.3.1
^ permalink raw reply
* RE: Question about ip_defrag
From: liujian (CE) @ 2017-08-28 8:08 UTC (permalink / raw)
To: liujian (CE), Jesper Dangaard Brouer
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, elena.reshetova@intel.com,
edumazet@google.com, netdev@vger.kernel.org, Wangkefeng (Kevin),
weiyongjun (A)
In-Reply-To: <20170824205926.2c45e3a1@redhat.com>
Hi
I checked our 3.10 kernel, we had backported all percpu_counter bug fix in lib/percpu_counter.c and include/linux/percpu_counter.h.
And I check 4.13-rc6, also has the issue if NIC's rx cpu num big enough.
> > > > the issue:
> > > > Ip_defrag fail caused by frag_mem_limit reached 4M(frags.high_thresh).
> > > > At this moment,sum_frag_mem_limit is about 10K.
So should we change ipfrag high/low thresh to a reasonable value ?
And if it is, is there a standard to change the value?
root@RH8100-V3:/proc/net# cat sockstat
sockets: used 1485
TCP: inuse 4 orphan 0 tw 0 alloc 5 mem 1
UDP: inuse 203 mem 201
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 1 memory 16048, 3156696.
root@RH8100-V3:/proc/net#
In order to print frag_mem_limit, change the code as below:
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 43eb6567..38bfb20 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -73,7 +73,7 @@ static int sockstat_seq_show(struct seq_file *seq, void *v)
seq_printf(seq, "RAW: inuse %d\n",
sock_prot_inuse_get(net, &raw_prot));
frag_mem = ip_frag_mem(net);
- seq_printf(seq, "FRAG: inuse %u memory %u\n", !!frag_mem, frag_mem);
+ seq_printf(seq, "FRAG: inuse %u memory %u, %u.\n", !!frag_mem, frag_mem, frag_mem_limit(&net->ipv4.frags));
return 0;
}
Best Regards,
liujian
> -----Original Message-----
> From: liujian (CE)
> Sent: Friday, August 25, 2017 9:33 AM
> To: 'Jesper Dangaard Brouer'
> Cc: davem@davemloft.net; kuznet@ms2.inr.ac.ru; yoshfuji@linux-ipv6.org;
> elena.reshetova@intel.com; edumazet@google.com; netdev@vger.kernel.org;
> Wangkefeng (Kevin); weiyongjun (A)
> Subject: RE: Question about ip_defrag
>
>
> > -----Original Message-----
> > From: Jesper Dangaard Brouer [mailto:brouer@redhat.com]
> > Sent: Friday, August 25, 2017 2:59 AM
> > To: liujian (CE)
> > Cc: davem@davemloft.net; kuznet@ms2.inr.ac.ru;
> > yoshfuji@linux-ipv6.org; elena.reshetova@intel.com;
> > edumazet@google.com; netdev@vger.kernel.org; brouer@redhat.com
> > Subject: Re: Question about ip_defrag
> >
> >
> > On Thu, 24 Aug 2017 16:04:41 +0000 "liujian (CE)"
> > <liujian56@huawei.com>
> > wrote:
> >
> > > >What kernel version have you seen this issue with?
> > >
> > > 3.10，with some backport.
> > >
> > > >As far as I remember, this issue have been fixed before...
> > >
> > > which one patch? I didnot find out the patch:(
> >
> > AFAIK it was some bugs in the percpu_counter code. If you need to
> > backport look at the git commits:
> >
> > git log lib/percpu_counter.c include/linux/percpu_counter.h
> >
> > Are you maintaining your own 3.10 kernel?
> >
> > I know that for RHEL7 (also kernel 3.10) we backported the
> > percpu_counter fixes...
> >
> Could you tell me which one patch? we have backported most of the two
> files's change.
> Thank you ~
>
>
> > --Jesper
> >
> >
> > > 发件人： Jesper Dangaard Brouer
> > > 收件人： liujian
> > (CE)<liujian56@huawei.com<mailto:liujian56@huawei.com>>
> > > 抄送：
> > >
> >
> davem@davemloft.net<mailto:davem@davemloft.net>;kuznet@ms2.inr.ac.ru
> > <m
> > > ailto:kuznet@ms2.inr.ac.ru>;yoshfuji@linux-ipv6.org<mailto:yoshfuji@
> > > li
> > > nux-ipv6.org>;elena.reshetova@intel.com<mailto:elena.reshetova@intel
> > > .c
> > >
> >
> om>;edumazet@google.com<mailto:edumazet@google.com>;netdev@vger.k
> > ernel
> > > .org<mailto:netdev@vger.kernel.org>;brouer@redhat.com<mailto:brouer
> @
> > > r
> > e
> > > dhat.com>
> > > 主题： Re: Question about ip_defrag
> > > 时间： 2017-08-24 21:53:17
> > >
> > >
> > > On Thu, 24 Aug 2017 13:15:33 +0000 "liujian (CE)"
> > > <liujian56@huawei.com>
> > wrote:
> > > > Hello,
> > > >
> > > > With below patch we met one issue.
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > > /c ommit/?h=v4.13-rc6&id=6d7b857d541e
> > > >
> > > > the issue:
> > > > Ip_defrag fail caused by frag_mem_limit reached 4M(frags.high_thresh).
> > > > At this moment,sum_frag_mem_limit is about 10K.
> > > > and my test machine's cpu num is 64.
> > > >
> > > > Can i only change frag_mem_limit to sum_ frag_mem_limit?
> > > >
> > > >
> > > > diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> > > > index 96e95e8..f09c00b 100644
> > > > --- a/net/ipv4/inet_fragment.c
> > > > +++ b/net/ipv4/inet_fragment.c
> > > > @@ -120,7 +120,7 @@ static void inet_frag_secret_rebuild(struct
> > > > inet_frags *f) static bool inet_fragq_should_evict(const struct
> > > > inet_frag_queue *q) {
> > > > return q->net->low_thresh == 0 ||
> > > > - frag_mem_limit(q->net) >= q->net->low_thresh;
> > > > + sum_frag_mem_limit(q->net) >= q->net->low_thresh;
> > > > }
> > > >
> > > > static unsigned int
> > > > @@ -355,7 +355,7 @@ static struct inet_frag_queue
> > > > *inet_frag_alloc(struct netns_frags *nf, {
> > > > struct inet_frag_queue *q;
> > > >
> > > > - if (!nf->high_thresh || frag_mem_limit(nf) > nf->high_thresh) {
> > > > + if (!nf->high_thresh || sum_frag_mem_limit(nf) >
> > > > + nf->high_thresh) {
> > > > inet_frag_schedule_worker(f);
> > > > return NULL;
> > > > }
> > > > @@ -396,7 +396,7 @@ struct inet_frag_queue *inet_frag_find(struct
> > netns_frags *nf,
> > > > struct inet_frag_queue *q;
> > > > int depth = 0;
> > > >
> > > > - if (frag_mem_limit(nf) > nf->low_thresh)
> > > > + if (sum_frag_mem_limit(nf) > nf->low_thresh)
> > > > inet_frag_schedule_worker(f);
> > > >
> > > > hash &= (INETFRAGS_HASHSZ - 1);
> > > > --
> > > >
> > > > Thank you for your time.
> > >
> > > What kernel version have you seen this issue with?
> > >
> > > As far as I remember, this issue have been fixed before...
> > >
> > > --
> > > Best regards,
> > > Jesper Dangaard Brouer
> > > MSc.CS, Principal Kernel Engineer at Red Hat
> > > LinkedIn: http://www.linkedin.com/in/brouer
> >
> >
> >
> > --
> > Best regards,
> > Jesper Dangaard Brouer
> > MSc.CS, Principal Kernel Engineer at Red Hat
> > LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply related
* Re: connector: Delete an error message for a failed memory allocation in cn_queue_alloc_callback_entry()
From: SF Markus Elfring @ 2017-08-28 7:09 UTC (permalink / raw)
To: Peter Waskiewicz Jr, netdev@vger.kernel.org
Cc: Evgeniy Polyakov, LKML, kernel-janitors
In-Reply-To: <E0D909EE5BB15A4699798539EA149D7F0779689E@ORSMSX103.amr.corp.intel.com>
> Did coccinelle trip on the message
I suggest to reconsider this implementation detail with the combination
of a function call like “kzalloc”.
A script for the semantic patch language can point various update candidates
out according to a source code search pattern which is similar to “OOM_MESSAGE”
in the script “checkpatch.pl”.
> or the fact you weren't returning NULL?
How does this concern fit to my update suggestion?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: Pavel Machek @ 2017-08-28 7:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung.Huh, nathan.leigh.conrad, vivien.didelot, f.fainelli,
netdev, linux-kernel, Tristram.Ha
In-Reply-To: <20170827163122.GG13622@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]
Hi!
Thanks for review.
> > + case PHY_REG_STATUS:
> > + ksz_pread8(sw, p, P_LINK_STATUS, &link);
> > + ksz_pread8(sw, p, P_SPEED_STATUS, &speed);
> > + data = PHY_100BTX_FD_CAPABLE |
> > + PHY_100BTX_CAPABLE |
> > + PHY_10BT_FD_CAPABLE |
> > + PHY_10BT_CAPABLE |
> > + PHY_AUTO_NEG_CAPABLE;
> > + if (link & PORT_AUTO_NEG_COMPLETE)
> > + data |= PHY_AUTO_NEG_ACKNOWLEDGE;
> > + if (link & PORT_STAT_LINK_GOOD)
> > + data |= PHY_LINK_STATUS;
> > + break;
> > + case PHY_REG_ID_1:
> > + data = KSZ8895_ID_HI;
> > + break;
> > + case PHY_REG_ID_2:
> > + data = KSZ8895_ID_LO;
> > + break;
>
> According to the datasheet, the PHY has the normal ID registers,
> which have the value 0x0022, 0x1450. So it should be possible to have
> a standard PHY driver in drivers/net/phy.
>
> In fact, the IDs suggest it is a micrel phy, and 1430, 1435 are
> already supported. So it could be you only need minor modifications to
> the micrel.c.
I may be confused here, but AFAICT:
1) Yes, it has standard layout when accessed over MDIO. But then
there's no access to the bridging functionality, and MDIO access may
not be available. [I was told not to use it for this design, so I did
not].
2) drivers/net/phy/spi_ks8995.c can be trivially modified to work with
this chip.. but then you don't get the bridge functionality. (And I'm
not sure how it works / who translates layouts in this case.)
I'd like to get rid of this code, or use some existing code instead,
but I don't think it is possible while keeping the SPI accesss. Let me
know if I'm wrong.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] net: mvpp2: do not force the link mode
From: Antoine Tenart @ 2017-08-28 6:55 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, andrew, jason,
sebastian.hesselbarth, gregory.clement, thomas.petazzoni, nadavh,
linux-kernel, mw, stefanc, miquel.raynal, netdev
In-Reply-To: <20170825224312.GD20805@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
Hi Russell,
On Fri, Aug 25, 2017 at 11:43:13PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 25, 2017 at 04:48:12PM +0200, Antoine Tenart wrote:
> > The link mode (speed, duplex) was forced based on what the phylib
> > returns. This should not be the case, and only forced by ethtool
> > functions manually. This patch removes the link mode enforcement from
> > the phylib link_event callback.
>
> So how does RGMII work (which has no in-band signalling between the PHY
> and MAC)?
>
> phylib expects the network driver to configure it according to the PHY
> state at link_event time - I think you need to explain more why you
> think that this is not necessary.
Good catch, this won't work properly with RGMII. This could be done
out-of-band according to the spec, but that would use PHY polling and we
do not want that (the same concern was raised by Andrew on another
patch).
I'll keep this mode enforcement for RGMII then.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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