* [PATCH net-next 0/5] Export SERDES stats via ethtool -S
From: Andrew Lunn @ 2018-01-03 14:09 UTC (permalink / raw)
To: David Miller
Cc: Vivien Didelot, Florian Fainelli, netdev, Russell King,
Andrew Lunn
The mv88e6352 family has a SERDES interface which can be used for
example to connect to SFF/SFP modules. This interface has a couple of
statistics counters. Add support for including these counters in the
output of ethtool -S.
Andrew Lunn (5):
dsa: Pass the port to get_sset_count()
net: dsa: mv88e6xxx: Hold mutex while doing stats operations
net: dsa: mv88e6xxx: Allow the SERDES interfaces to have statistics
net: dsa: mv88e6xxx: Add helper to determining if port has SERDES
net: dsa: mv88e6xxx: Get mv88e6352 SERDES statistics
drivers/net/dsa/b53/b53_common.c | 2 +-
drivers/net/dsa/b53/b53_priv.h | 2 +-
drivers/net/dsa/dsa_loop.c | 2 +-
drivers/net/dsa/lan9303-core.c | 2 +-
drivers/net/dsa/microchip/ksz_common.c | 2 +-
drivers/net/dsa/mt7530.c | 2 +-
drivers/net/dsa/mv88e6xxx/chip.c | 94 +++++++++++++++++++++--------
drivers/net/dsa/mv88e6xxx/chip.h | 20 ++++++-
drivers/net/dsa/mv88e6xxx/serdes.c | 106 +++++++++++++++++++++++++++++++--
drivers/net/dsa/mv88e6xxx/serdes.h | 6 +-
drivers/net/dsa/qca8k.c | 2 +-
include/net/dsa.h | 2 +-
net/dsa/master.c | 4 +-
net/dsa/slave.c | 2 +-
14 files changed, 204 insertions(+), 44 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH net-next 5/5] net: dsa: mv88e6xxx: Get mv88e6352 SERDES statistics
From: Andrew Lunn @ 2018-01-03 14:09 UTC (permalink / raw)
To: David Miller
Cc: Vivien Didelot, Florian Fainelli, netdev, Russell King,
Andrew Lunn
In-Reply-To: <1514988562-20079-1-git-send-email-andrew@lunn.ch>
Add support for reading the SERDES statistics of the mv88e8352, using
the standard ethtool -S option. The SERDES interface can be mapped to
either port 4 or 5, so only return statistics on those ports, if the
SERDES interface is in use.
The counters are reset on read, so need to be accumulated. Add a per
port structure to hold the stats counters. The 6352 only has a single
SERDES interface and so only one port will using the newly added
array. However the 6390 family has as many SERDES interfaces as ports,
each with statistics counters. Also, PTP has a number of counters per
port which will also need accumulating.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 3 ++
drivers/net/dsa/mv88e6xxx/chip.h | 7 ++++
drivers/net/dsa/mv88e6xxx/serdes.c | 84 ++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx/serdes.h | 6 ++-
4 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5274e8292451..a335ef2f1087 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3129,6 +3129,9 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
.serdes_power = mv88e6352_serdes_power,
+ .serdes_get_sset_count = mv88e6352_serdes_get_sset_count,
+ .serdes_get_strings = mv88e6352_serdes_get_strings,
+ .serdes_get_stats = mv88e6352_serdes_get_stats,
};
static const struct mv88e6xxx_ops mv88e6390_ops = {
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index 1787fc43167d..c5accbb84eea 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -154,6 +154,10 @@ struct mv88e6xxx_irq {
unsigned int nirqs;
};
+struct mv88e6xxx_port {
+ u64 serdes_stats[2];
+};
+
struct mv88e6xxx_chip {
const struct mv88e6xxx_info *info;
@@ -207,6 +211,9 @@ struct mv88e6xxx_chip {
int irq;
int device_irq;
int watchdog_irq;
+
+ /* Array of port structures. */
+ struct mv88e6xxx_port ports[DSA_MAX_PORTS];
};
struct mv88e6xxx_bus_ops {
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index d32522276fea..3b911b80da33 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -87,6 +87,90 @@ int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
return 0;
}
+struct mv88e6352_serdes_hw_stat {
+ char string[ETH_GSTRING_LEN];
+ int sizeof_stat;
+ int reg;
+};
+
+static struct mv88e6352_serdes_hw_stat mv88e6352_serdes_hw_stats[] = {
+ { "serdes_fibre_rx_error", 16, 21 },
+ { "serdes_PRBS_error", 32, 24 },
+};
+
+int mv88e6352_serdes_get_sset_count(struct mv88e6xxx_chip *chip, int port)
+{
+ if (mv88e6352_port_has_serdes(chip, port))
+ return ARRAY_SIZE(mv88e6352_serdes_hw_stats);
+
+ return 0;
+}
+
+void mv88e6352_serdes_get_strings(struct mv88e6xxx_chip *chip,
+ int port, uint8_t *data)
+{
+ struct mv88e6352_serdes_hw_stat *stat;
+ int i;
+
+ if (!mv88e6352_port_has_serdes(chip, port))
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(mv88e6352_serdes_hw_stats); i++) {
+ stat = &mv88e6352_serdes_hw_stats[i];
+ memcpy(data + i * ETH_GSTRING_LEN, stat->string,
+ ETH_GSTRING_LEN);
+ }
+}
+
+static uint64_t mv88e6352_serdes_get_stat(struct mv88e6xxx_chip *chip,
+ struct mv88e6352_serdes_hw_stat *stat)
+{
+ u64 val = 0;
+ u16 reg;
+ int err;
+
+ err = mv88e6352_serdes_read(chip, stat->reg, ®);
+ if (err) {
+ dev_err(chip->dev, "failed to read statistic\n");
+ return 0;
+ }
+
+ val = reg;
+
+ if (stat->sizeof_stat == 32) {
+ err = mv88e6352_serdes_read(chip, stat->reg + 1, ®);
+ if (err) {
+ dev_err(chip->dev, "failed to read statistic\n");
+ return 0;
+ }
+ val = val << 16 | reg;
+ }
+
+ return val;
+}
+
+void mv88e6352_serdes_get_stats(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data)
+{
+ struct mv88e6xxx_port *mv88e6xxx_port = &chip->ports[port];
+ struct mv88e6352_serdes_hw_stat *stat;
+ u64 value;
+ int i;
+
+ if (!mv88e6352_port_has_serdes(chip, port))
+ return;
+
+ BUILD_BUG_ON(ARRAY_SIZE(mv88e6352_serdes_hw_stats) >
+ ARRAY_SIZE(mv88e6xxx_port->serdes_stats));
+
+ for (i = 0; i < ARRAY_SIZE(mv88e6352_serdes_hw_stats); i++) {
+ stat = &mv88e6352_serdes_hw_stats[i];
+ value = mv88e6352_serdes_get_stat(chip, stat);
+ mv88e6xxx_port->serdes_stats[i] += value;
+ data[i] = mv88e6xxx_port->serdes_stats[i];
+ }
+}
+
/* Set the power on/off for 10GBASE-R and 10GBASE-X4/X2 */
static int mv88e6390_serdes_10g(struct mv88e6xxx_chip *chip, int addr, bool on)
{
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.h b/drivers/net/dsa/mv88e6xxx/serdes.h
index 5c1cd6d8e9a5..641baa75f910 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.h
+++ b/drivers/net/dsa/mv88e6xxx/serdes.h
@@ -44,5 +44,9 @@
int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
int mv88e6390_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
-
+int mv88e6352_serdes_get_sset_count(struct mv88e6xxx_chip *chip, int port);
+void mv88e6352_serdes_get_strings(struct mv88e6xxx_chip *chip,
+ int port, uint8_t *data);
+void mv88e6352_serdes_get_stats(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data);
#endif
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 1/5] dsa: Pass the port to get_sset_count()
From: Andrew Lunn @ 2018-01-03 14:09 UTC (permalink / raw)
To: David Miller
Cc: Vivien Didelot, Florian Fainelli, netdev, Russell King,
Andrew Lunn
In-Reply-To: <1514988562-20079-1-git-send-email-andrew@lunn.ch>
By passing the port, we allow different ports to have different
statistics. This is useful since some ports have SERDES interfaces
with their own statistic counters.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 2 +-
drivers/net/dsa/b53/b53_priv.h | 2 +-
drivers/net/dsa/dsa_loop.c | 2 +-
drivers/net/dsa/lan9303-core.c | 2 +-
drivers/net/dsa/microchip/ksz_common.c | 2 +-
drivers/net/dsa/mt7530.c | 2 +-
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
drivers/net/dsa/qca8k.c | 2 +-
include/net/dsa.h | 2 +-
net/dsa/master.c | 4 ++--
net/dsa/slave.c | 2 +-
11 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 561b05089cb6..0c1d814573b3 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -852,7 +852,7 @@ void b53_get_ethtool_stats(struct dsa_switch *ds, int port, uint64_t *data)
}
EXPORT_SYMBOL(b53_get_ethtool_stats);
-int b53_get_sset_count(struct dsa_switch *ds)
+int b53_get_sset_count(struct dsa_switch *ds, int port)
{
struct b53_device *dev = ds->priv;
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index d954cf36ecd8..1187ebd79287 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -288,7 +288,7 @@ void b53_imp_vlan_setup(struct dsa_switch *ds, int cpu_port);
int b53_configure_vlan(struct dsa_switch *ds);
void b53_get_strings(struct dsa_switch *ds, int port, uint8_t *data);
void b53_get_ethtool_stats(struct dsa_switch *ds, int port, uint64_t *data);
-int b53_get_sset_count(struct dsa_switch *ds);
+int b53_get_sset_count(struct dsa_switch *ds, int port);
int b53_br_join(struct dsa_switch *ds, int port, struct net_device *bridge);
void b53_br_leave(struct dsa_switch *ds, int port, struct net_device *bridge);
void b53_br_set_stp_state(struct dsa_switch *ds, int port, u8 state);
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index 7aa84ee4e771..f77be9f85cb3 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -86,7 +86,7 @@ static int dsa_loop_setup(struct dsa_switch *ds)
return 0;
}
-static int dsa_loop_get_sset_count(struct dsa_switch *ds)
+static int dsa_loop_get_sset_count(struct dsa_switch *ds, int port)
{
return __DSA_LOOP_CNT_MAX;
}
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 944901f03f8b..ba46dd319b10 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -1011,7 +1011,7 @@ static void lan9303_get_ethtool_stats(struct dsa_switch *ds, int port,
}
}
-static int lan9303_get_sset_count(struct dsa_switch *ds)
+static int lan9303_get_sset_count(struct dsa_switch *ds, int port)
{
return ARRAY_SIZE(lan9303_mib);
}
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 663b0d5b982b..bcb3e6c734f2 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -439,7 +439,7 @@ static void ksz_disable_port(struct dsa_switch *ds, int port,
ksz_port_cfg(dev, port, REG_PORT_CTRL_0, PORT_MAC_LOOPBACK, true);
}
-static int ksz_sset_count(struct dsa_switch *ds)
+static int ksz_sset_count(struct dsa_switch *ds, int port)
{
return TOTAL_SWITCH_COUNTER_NUM;
}
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 8a0bb000d056..511ca134f13f 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -604,7 +604,7 @@ mt7530_get_ethtool_stats(struct dsa_switch *ds, int port,
}
static int
-mt7530_get_sset_count(struct dsa_switch *ds)
+mt7530_get_sset_count(struct dsa_switch *ds, int port)
{
return ARRAY_SIZE(mt7530_mib);
}
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fc512c98f2f8..504407adc7aa 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -692,7 +692,7 @@ static int mv88e6320_stats_get_sset_count(struct mv88e6xxx_chip *chip)
STATS_TYPE_BANK1);
}
-static int mv88e6xxx_get_sset_count(struct dsa_switch *ds)
+static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
{
struct mv88e6xxx_chip *chip = ds->priv;
diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c
index 9df22ebee822..600d5ad1fbde 100644
--- a/drivers/net/dsa/qca8k.c
+++ b/drivers/net/dsa/qca8k.c
@@ -631,7 +631,7 @@ qca8k_get_ethtool_stats(struct dsa_switch *ds, int port,
}
static int
-qca8k_get_sset_count(struct dsa_switch *ds)
+qca8k_get_sset_count(struct dsa_switch *ds, int port)
{
return ARRAY_SIZE(ar8327_mib);
}
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 6cb602dd970c..35433386c314 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -357,7 +357,7 @@ struct dsa_switch_ops {
void (*get_strings)(struct dsa_switch *ds, int port, uint8_t *data);
void (*get_ethtool_stats)(struct dsa_switch *ds,
int port, uint64_t *data);
- int (*get_sset_count)(struct dsa_switch *ds);
+ int (*get_sset_count)(struct dsa_switch *ds, int port);
/*
* ethtool Wake-on-LAN
diff --git a/net/dsa/master.c b/net/dsa/master.c
index 00589147f042..f20a9600318f 100644
--- a/net/dsa/master.c
+++ b/net/dsa/master.c
@@ -42,7 +42,7 @@ static int dsa_master_get_sset_count(struct net_device *dev, int sset)
count += ops->get_sset_count(dev, sset);
if (sset == ETH_SS_STATS && ds->ops->get_sset_count)
- count += ds->ops->get_sset_count(ds);
+ count += ds->ops->get_sset_count(ds, cpu_dp->index);
return count;
}
@@ -76,7 +76,7 @@ static void dsa_master_get_strings(struct net_device *dev, uint32_t stringset,
* constructed earlier
*/
ds->ops->get_strings(ds, port, ndata);
- count = ds->ops->get_sset_count(ds);
+ count = ds->ops->get_sset_count(ds, cpu_dp->index);
for (i = 0; i < count; i++) {
memmove(ndata + (i * len + sizeof(pfx)),
ndata + i * len, len - sizeof(pfx));
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index f52307296de4..0d07004d59d4 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -559,7 +559,7 @@ static int dsa_slave_get_sset_count(struct net_device *dev, int sset)
count = 4;
if (ds->ops->get_sset_count)
- count += ds->ops->get_sset_count(ds);
+ count += ds->ops->get_sset_count(ds, dp->index);
return count;
}
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 4/5] net: dsa: mv88e6xxx: Add helper to determining if port has SERDES
From: Andrew Lunn @ 2018-01-03 14:09 UTC (permalink / raw)
To: David Miller
Cc: Vivien Didelot, Florian Fainelli, netdev, Russell King,
Andrew Lunn
In-Reply-To: <1514988562-20079-1-git-send-email-andrew@lunn.ch>
Refactor the existing code. This helper will be used for SERDES
statistics.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/mv88e6xxx/serdes.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index f3c01119b3d1..d32522276fea 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -55,18 +55,30 @@ static int mv88e6352_serdes_power_set(struct mv88e6xxx_chip *chip, bool on)
return err;
}
-int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
+static int mv88e6352_port_has_serdes(struct mv88e6xxx_chip *chip, int port)
{
- int err;
u8 cmode;
+ int err;
err = mv88e6xxx_port_get_cmode(chip, port, &cmode);
- if (err)
- return err;
+ if (err) {
+ dev_err(chip->dev, "failed to read cmode\n");
+ return 0;
+ }
if ((cmode == MV88E6XXX_PORT_STS_CMODE_100BASE_X) ||
(cmode == MV88E6XXX_PORT_STS_CMODE_1000BASE_X) ||
- (cmode == MV88E6XXX_PORT_STS_CMODE_SGMII)) {
+ (cmode == MV88E6XXX_PORT_STS_CMODE_SGMII))
+ return 1;
+
+ return 0;
+}
+
+int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
+{
+ int err;
+
+ if (mv88e6352_port_has_serdes(chip, port)) {
err = mv88e6352_serdes_power_set(chip, on);
if (err < 0)
return err;
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 3/5] net: dsa: mv88e6xxx: Allow the SERDES interfaces to have statistics
From: Andrew Lunn @ 2018-01-03 14:09 UTC (permalink / raw)
To: David Miller
Cc: Vivien Didelot, Florian Fainelli, netdev, Russell King,
Andrew Lunn
In-Reply-To: <1514988562-20079-1-git-send-email-andrew@lunn.ch>
When gettting the number of statistics, the strings and the actual
statistics, call the SERDES ops if implemented. This means the stats
code needs to return the number of strings/stats they have placed into
the data, so that the SERDES strings/stats can follow on.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 72 +++++++++++++++++++++++++++-------------
drivers/net/dsa/mv88e6xxx/chip.h | 13 ++++++--
2 files changed, 59 insertions(+), 26 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 12e274a3ff24..5274e8292451 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -627,8 +627,8 @@ static uint64_t _mv88e6xxx_get_ethtool_stat(struct mv88e6xxx_chip *chip,
return value;
}
-static void mv88e6xxx_stats_get_strings(struct mv88e6xxx_chip *chip,
- uint8_t *data, int types)
+static int mv88e6xxx_stats_get_strings(struct mv88e6xxx_chip *chip,
+ uint8_t *data, int types)
{
struct mv88e6xxx_hw_stat *stat;
int i, j;
@@ -641,31 +641,39 @@ static void mv88e6xxx_stats_get_strings(struct mv88e6xxx_chip *chip,
j++;
}
}
+
+ return j;
}
-static void mv88e6095_stats_get_strings(struct mv88e6xxx_chip *chip,
- uint8_t *data)
+static int mv88e6095_stats_get_strings(struct mv88e6xxx_chip *chip,
+ uint8_t *data)
{
- mv88e6xxx_stats_get_strings(chip, data,
- STATS_TYPE_BANK0 | STATS_TYPE_PORT);
+ return mv88e6xxx_stats_get_strings(chip, data,
+ STATS_TYPE_BANK0 | STATS_TYPE_PORT);
}
-static void mv88e6320_stats_get_strings(struct mv88e6xxx_chip *chip,
- uint8_t *data)
+static int mv88e6320_stats_get_strings(struct mv88e6xxx_chip *chip,
+ uint8_t *data)
{
- mv88e6xxx_stats_get_strings(chip, data,
- STATS_TYPE_BANK0 | STATS_TYPE_BANK1);
+ return mv88e6xxx_stats_get_strings(chip, data,
+ STATS_TYPE_BANK0 | STATS_TYPE_BANK1);
}
static void mv88e6xxx_get_strings(struct dsa_switch *ds, int port,
uint8_t *data)
{
struct mv88e6xxx_chip *chip = ds->priv;
+ int count = 0;
mutex_lock(&chip->reg_lock);
if (chip->info->ops->stats_get_strings)
- chip->info->ops->stats_get_strings(chip, data);
+ count = chip->info->ops->stats_get_strings(chip, data);
+
+ if (chip->info->ops->serdes_get_strings) {
+ data += count * ETH_GSTRING_LEN;
+ chip->info->ops->serdes_get_strings(chip, port, data);
+ }
mutex_unlock(&chip->reg_lock);
}
@@ -699,11 +707,21 @@ static int mv88e6320_stats_get_sset_count(struct mv88e6xxx_chip *chip)
static int _mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
{
struct mv88e6xxx_chip *chip = ds->priv;
+ int serdes_count = 0;
+ int count = 0;
if (chip->info->ops->stats_get_sset_count)
- return chip->info->ops->stats_get_sset_count(chip);
+ count = chip->info->ops->stats_get_sset_count(chip);
+ if (count < 0)
+ return count;
- return 0;
+ if (chip->info->ops->serdes_get_sset_count)
+ serdes_count = chip->info->ops->serdes_get_sset_count(chip,
+ port);
+ if (serdes_count < 0)
+ return serdes_count;
+
+ return count + serdes_count;
}
static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
@@ -719,9 +737,9 @@ static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
}
-static void mv88e6xxx_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
- uint64_t *data, int types,
- u16 bank1_select, u16 histogram)
+static int mv88e6xxx_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data, int types,
+ u16 bank1_select, u16 histogram)
{
struct mv88e6xxx_hw_stat *stat;
int i, j;
@@ -735,18 +753,19 @@ static void mv88e6xxx_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
j++;
}
}
+ return j;
}
-static void mv88e6095_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
- uint64_t *data)
+static int mv88e6095_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data)
{
return mv88e6xxx_stats_get_stats(chip, port, data,
STATS_TYPE_BANK0 | STATS_TYPE_PORT,
0, MV88E6XXX_G1_STATS_OP_HIST_RX_TX);
}
-static void mv88e6320_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
- uint64_t *data)
+static int mv88e6320_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data)
{
return mv88e6xxx_stats_get_stats(chip, port, data,
STATS_TYPE_BANK0 | STATS_TYPE_BANK1,
@@ -754,8 +773,8 @@ static void mv88e6320_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
MV88E6XXX_G1_STATS_OP_HIST_RX_TX);
}
-static void mv88e6390_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
- uint64_t *data)
+static int mv88e6390_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data)
{
return mv88e6xxx_stats_get_stats(chip, port, data,
STATS_TYPE_BANK0 | STATS_TYPE_BANK1,
@@ -766,8 +785,15 @@ static void mv88e6390_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
static void mv88e6xxx_get_stats(struct mv88e6xxx_chip *chip, int port,
uint64_t *data)
{
+ int count = 0;
+
if (chip->info->ops->stats_get_stats)
- chip->info->ops->stats_get_stats(chip, port, data);
+ count = chip->info->ops->stats_get_stats(chip, port, data);
+
+ if (chip->info->ops->serdes_get_stats) {
+ data += count;
+ chip->info->ops->serdes_get_stats(chip, port, data);
+ }
}
static void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds, int port,
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index 334f6f7544ba..1787fc43167d 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -325,9 +325,9 @@ struct mv88e6xxx_ops {
/* Return the number of strings describing statistics */
int (*stats_get_sset_count)(struct mv88e6xxx_chip *chip);
- void (*stats_get_strings)(struct mv88e6xxx_chip *chip, uint8_t *data);
- void (*stats_get_stats)(struct mv88e6xxx_chip *chip, int port,
- uint64_t *data);
+ int (*stats_get_strings)(struct mv88e6xxx_chip *chip, uint8_t *data);
+ int (*stats_get_stats)(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data);
int (*set_cpu_port)(struct mv88e6xxx_chip *chip, int port);
int (*set_egress_port)(struct mv88e6xxx_chip *chip, int port);
const struct mv88e6xxx_irq_ops *watchdog_ops;
@@ -337,6 +337,13 @@ struct mv88e6xxx_ops {
/* Power on/off a SERDES interface */
int (*serdes_power)(struct mv88e6xxx_chip *chip, int port, bool on);
+ /* Statistics from the SERDES interface */
+ int (*serdes_get_sset_count)(struct mv88e6xxx_chip *chip, int port);
+ void (*serdes_get_strings)(struct mv88e6xxx_chip *chip, int port,
+ uint8_t *data);
+ void (*serdes_get_stats)(struct mv88e6xxx_chip *chip, int port,
+ uint64_t *data);
+
/* VLAN Translation Unit operations */
int (*vtu_getnext)(struct mv88e6xxx_chip *chip,
struct mv88e6xxx_vtu_entry *entry);
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 2/5] net: dsa: mv88e6xxx: Hold mutex while doing stats operations
From: Andrew Lunn @ 2018-01-03 14:09 UTC (permalink / raw)
To: David Miller
Cc: Vivien Didelot, Florian Fainelli, netdev, Russell King,
Andrew Lunn
In-Reply-To: <1514988562-20079-1-git-send-email-andrew@lunn.ch>
Until now, there has been no need to hold the reg mutex while getting
the count of statistics, or the strings, because the hardware was not
accessed. When adding support for SERDES statistics, it is necessary
to access the hardware, to determine if a port is using the SERDES
interface. So add mutex lock/unlocks.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/mv88e6xxx/chip.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 504407adc7aa..12e274a3ff24 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -662,8 +662,12 @@ static void mv88e6xxx_get_strings(struct dsa_switch *ds, int port,
{
struct mv88e6xxx_chip *chip = ds->priv;
+ mutex_lock(&chip->reg_lock);
+
if (chip->info->ops->stats_get_strings)
chip->info->ops->stats_get_strings(chip, data);
+
+ mutex_unlock(&chip->reg_lock);
}
static int mv88e6xxx_stats_get_sset_count(struct mv88e6xxx_chip *chip,
@@ -692,7 +696,7 @@ static int mv88e6320_stats_get_sset_count(struct mv88e6xxx_chip *chip)
STATS_TYPE_BANK1);
}
-static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
+static int _mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
{
struct mv88e6xxx_chip *chip = ds->priv;
@@ -702,6 +706,19 @@ static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
return 0;
}
+static int mv88e6xxx_get_sset_count(struct dsa_switch *ds, int port)
+{
+ struct mv88e6xxx_chip *chip = ds->priv;
+ int ret;
+
+ mutex_lock(&chip->reg_lock);
+ ret = _mv88e6xxx_get_sset_count(ds, port);
+ mutex_unlock(&chip->reg_lock);
+
+ return ret;
+}
+
+
static void mv88e6xxx_stats_get_stats(struct mv88e6xxx_chip *chip, int port,
uint64_t *data, int types,
u16 bank1_select, u16 histogram)
--
2.15.1
^ permalink raw reply related
* Re: [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor
From: Michael S. Tsirkin @ 2018-01-03 14:03 UTC (permalink / raw)
To: Jason Baron; +Cc: netdev, virtualization, qemu-devel, jasowang
In-Reply-To: <44da522ecee60792ec918234ee4d61a84e4574f0.1513974243.git.jbaron@akamai.com>
On Fri, Dec 22, 2017 at 04:54:01PM -0500, Jason Baron wrote:
> The ability to set speed and duplex for virtio_net in useful in various
> scenarios as described here:
>
> 16032be virtio_net: add ethtool support for set and get of settings
>
> However, it would be nice to be able to set this from the hypervisor,
> such that virtio_net doesn't require custom guest ethtool commands.
>
> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
> the hypervisor to export a linkspeed and duplex setting. The user can
> subsequently overwrite it later if desired via: 'ethtool -s'.
>
> Signed-off-by: Jason Baron <jbaron@akamai.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
Same as any host/guest API change, please send a copy to the virtio TC
to make sure we avoid conflicts.
> ---
> drivers/net/virtio_net.c | 17 ++++++++++++++++-
> include/uapi/linux/virtio_net.h | 5 +++++
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 511f833..4168d82 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2621,6 +2621,20 @@ static int virtnet_probe(struct virtio_device *vdev)
> netif_set_real_num_rx_queues(dev, vi->curr_queue_pairs);
>
> virtnet_init_settings(dev);
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_SPEED_DUPLEX)) {
> + u32 speed;
> + u8 duplex;
> +
> + speed = virtio_cread32(vdev, offsetof(struct virtio_net_config,
> + speed));
> + if (ethtool_validate_speed(speed))
> + vi->speed = speed;
> + duplex = virtio_cread8(vdev,
> + offsetof(struct virtio_net_config,
> + duplex));
> + if (ethtool_validate_duplex(duplex))
> + vi->duplex = duplex;
> + }
>
> err = register_netdev(dev);
> if (err) {
> @@ -2746,7 +2760,8 @@ static struct virtio_device_id id_table[] = {
> VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN, \
> VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
> VIRTIO_NET_F_CTRL_MAC_ADDR, \
> - VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS
> + VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
> + VIRTIO_NET_F_SPEED_DUPLEX
>
> static unsigned int features[] = {
> VIRTNET_FEATURES,
> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> index fc353b5..0f1548e 100644
> --- a/include/uapi/linux/virtio_net.h
> +++ b/include/uapi/linux/virtio_net.h
> @@ -57,6 +57,8 @@
> * Steering */
> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>
> +#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Host set linkspeed and duplex */
> +
> #ifndef VIRTIO_NET_NO_LEGACY
> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> #endif /* VIRTIO_NET_NO_LEGACY */
> @@ -76,6 +78,9 @@ struct virtio_net_config {
> __u16 max_virtqueue_pairs;
> /* Default maximum transmit unit advice */
> __u16 mtu;
> + /* Host exported linkspeed and duplex */
> + __u32 speed;
> + __u8 duplex;
> } __attribute__((packed));
>
> /*
> --
> 2.6.1
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor
From: Michael S. Tsirkin @ 2018-01-03 14:01 UTC (permalink / raw)
To: Jason Baron; +Cc: netdev, virtualization, qemu-devel, jasowang
In-Reply-To: <44da522ecee60792ec918234ee4d61a84e4574f0.1513974243.git.jbaron@akamai.com>
On Fri, Dec 22, 2017 at 04:54:01PM -0500, Jason Baron wrote:
> The ability to set speed and duplex for virtio_net in useful in various
> scenarios as described here:
>
> 16032be virtio_net: add ethtool support for set and get of settings
>
> However, it would be nice to be able to set this from the hypervisor,
> such that virtio_net doesn't require custom guest ethtool commands.
>
> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
> the hypervisor to export a linkspeed and duplex setting. The user can
> subsequently overwrite it later if desired via: 'ethtool -s'.
>
> Signed-off-by: Jason Baron <jbaron@akamai.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/virtio_net.c | 17 ++++++++++++++++-
> include/uapi/linux/virtio_net.h | 5 +++++
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 511f833..4168d82 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2621,6 +2621,20 @@ static int virtnet_probe(struct virtio_device *vdev)
> netif_set_real_num_rx_queues(dev, vi->curr_queue_pairs);
>
> virtnet_init_settings(dev);
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_SPEED_DUPLEX)) {
> + u32 speed;
> + u8 duplex;
> +
> + speed = virtio_cread32(vdev, offsetof(struct virtio_net_config,
> + speed));
> + if (ethtool_validate_speed(speed))
> + vi->speed = speed;
> + duplex = virtio_cread8(vdev,
> + offsetof(struct virtio_net_config,
> + duplex));
> + if (ethtool_validate_duplex(duplex))
> + vi->duplex = duplex;
> + }
>
> err = register_netdev(dev);
> if (err) {
It would seem that speed/duplex can change at link up time.
Update it from virtnet_config_changed_work please.
> @@ -2746,7 +2760,8 @@ static struct virtio_device_id id_table[] = {
> VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN, \
> VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
> VIRTIO_NET_F_CTRL_MAC_ADDR, \
> - VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS
> + VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
> + VIRTIO_NET_F_SPEED_DUPLEX
>
> static unsigned int features[] = {
> VIRTNET_FEATURES,
> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> index fc353b5..0f1548e 100644
> --- a/include/uapi/linux/virtio_net.h
> +++ b/include/uapi/linux/virtio_net.h
> @@ -57,6 +57,8 @@
> * Steering */
> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>
> +#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Host set linkspeed and duplex */
> +
Host -> device, to match virtio spec terminology.
> #ifndef VIRTIO_NET_NO_LEGACY
> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
> #endif /* VIRTIO_NET_NO_LEGACY */
> @@ -76,6 +78,9 @@ struct virtio_net_config {
> __u16 max_virtqueue_pairs;
> /* Default maximum transmit unit advice */
> __u16 mtu;
> + /* Host exported linkspeed and duplex */
I would rather drop this and document each field.
/*
speed, in units of 1Mb. All values 0 to INT_MAX are legal.
Any other value stands for unknown.
*/
> + __u32 speed;
/*
0x00 - half duplex
0x01 - full duplex
Any other value stands for unknown.
*/
> + __u8 duplex;
> } __attribute__((packed));
>
> /*
> --
> 2.6.1
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor
From: Michael S. Tsirkin @ 2018-01-03 13:49 UTC (permalink / raw)
To: Jason Baron; +Cc: qemu-devel, netdev, David Miller, virtualization
In-Reply-To: <93b66082-f37c-0463-e977-d4b430a44008@akamai.com>
On Thu, Dec 28, 2017 at 10:53:54AM -0500, Jason Baron wrote:
>
>
> On 12/27/2017 04:43 PM, David Miller wrote:
> > From: Jason Baron <jbaron@akamai.com>
> > Date: Fri, 22 Dec 2017 16:54:01 -0500
> >
> >> The ability to set speed and duplex for virtio_net in useful in various
> >> scenarios as described here:
> >>
> >> 16032be virtio_net: add ethtool support for set and get of settings
> >>
> >> However, it would be nice to be able to set this from the hypervisor,
> >> such that virtio_net doesn't require custom guest ethtool commands.
> >>
> >> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
> >> the hypervisor to export a linkspeed and duplex setting. The user can
> >> subsequently overwrite it later if desired via: 'ethtool -s'.
> >>
> >> Signed-off-by: Jason Baron <jbaron@akamai.com>
> >> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> >> Cc: Jason Wang <jasowang@redhat.com>
> >
> > Looks mostly fine to me but need some virtio_net reviewers on this one.
> >
> >> @@ -57,6 +57,8 @@
> >> * Steering */
> >> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> >>
> >> +#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Host set linkspeed and duplex */
> >> +
> >
> > Why use a value so far away from the largest existing one?
> >
> > Just curious.
> >
>
> So that came from a discussion with Michael about which bit to use for
> this, and he suggested using 63:
>
> "
> Transports started from bit 24 and are growing up.
> So I would say devices should start from bit 63 and grow down.
> "
>
> https://patchwork.ozlabs.org/patch/848814/#1826669
>
> I will add a comment to explain it.
Maybe in the commit log. I don't think we need it in the header.
> Thanks,
>
> -Jason
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2018-01-03 13:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Graeme Gregory, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <20180103133341.GJ15036@lunn.ch>
2018-01-03 14:33 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> On Wed, Jan 03, 2018 at 02:13:09PM +0100, Marcin Wojtas wrote:
>> Hi Andrew,
>>
>> 2018-01-03 13:47 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>> >> I already agreed with 'reg' being awkward in the later emails.
>> >> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
>> >
>> > Also, how do you specify which MDIO bus the PHY is on. To fully
>> > specify a PHY, you need both bits of information.
>> >
>> > In DT, the phy-handle phandle can point to any PHY anywhere in the
>> > system. This is particularly important when a Ethernet device has two
>> > MDIO busses.
>> >
>>
>> For now, my local MDIO bus description is pretty DT-like, i.e. master
>> bus with children PHYs:
>> Device (MDIO)
>> {
>> Name (_HID, "MRVL0100") //
>> _HID: Hardware ID
>> Name (_UID, 0x00) //
>> _UID: Unique ID
>> Name (_CRS, ResourceTemplate ()
>> {
>> Memory32Fixed (ReadWrite,
>> 0xf212a200, // Address Base
>> 0x00000010, //
>> Address Length
>> )
>> })
>> Device (GPHY)
>> {
>> Name (_ADR, 0x0)
>> }
>> }
>>
>> Device (XSMI)
>> {
>> Name (_HID, "MRVL0101") //
>> _HID: Hardware ID
>> Name (_UID, 0x00) //
>> _UID: Unique ID
>> Name (_CRS, ResourceTemplate ()
>> {
>> Memory32Fixed (ReadWrite,
>> 0xf212a600, // Address Base
>> 0x00000010, //
>> Address Length
>> )
>> })
>> Device (PHY0)
>> {
>> Name (_ADR, 0x0)
>> Name (_CID, "ethernet-phy-ieee802.3-c45")
>> }
>> Device (PHY8)
>> {
>> Name (_ADR, 0x8)
>> Name (_CID, "ethernet-phy-ieee802.3-c45")
>> }
>> }
>>
>> Which is referenced in the port's node:
>>
>> Package () { "phy", Package (){\_SB.XSMI.PHY0}},
>
> Hi Marcin
>
> This reference looks good, giving both the bus and the PHY on the bus.
>
> I assume you can use references like this within the Device (PHY8)
> node?
Yes.
> You need to be able to reference a GPIO used for resetting the
> PHY. And you also need to reference a GPIO at the Device (MDIO) level
> for resetting all the PHYs on the MDIO bus.
>
Yes, for full support of PHYs the GPIO must be supported, as well as
the PHY's IRQs.
Best regards,
Marcin
^ permalink raw reply
* Re: [PATCH net] sctp: fix handling of ICMP Frag Needed for too small MTUs
From: Marcelo Ricardo Leitner @ 2018-01-03 13:35 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Vlad Yasevich, Neil Horman
In-Reply-To: <CADvbK_cCftba3-O+Hub29sx6K8jWsvROhMiRLgdHg9tYi6wskg@mail.gmail.com>
On Wed, Jan 03, 2018 at 03:31:00PM +0800, Xin Long wrote:
> On Wed, Jan 3, 2018 at 5:44 AM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > syzbot reported a hang involving SCTP, on which it kept flooding dmesg
> > with the message:
> > [ 246.742374] sctp: sctp_transport_update_pmtu: Reported pmtu 508 too
> > low, using default minimum of 512
> >
> > That happened because whenever SCTP hits an ICMP Frag Needed, it tries
> > to adjust to the new MTU and triggers an immediate retransmission. But
> > it didn't consider the fact that MTUs smaller than the SCTP minimum MTU
> > allowed (512) would not cause the PMTU to change, and issued the
> > retransmission anyway (thus leading to another ICMP Frag Needed, and so
> > on).
> >
> > The fix is to disable Path MTU discovery for such transport and to skip
> > the retransmission in such cases. By doing this, SCTP will do the
> > backoff retransmissions as needed and will likely switch to another
> > transport if available.
> >
> > See-also: https://lkml.org/lkml/2017/12/22/811
> > Reported-by: syzbot <syzkaller@googlegroups.com>
> > Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> > ---
> > net/sctp/input.c | 5 ++++-
> > net/sctp/transport.c | 2 ++
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/sctp/input.c b/net/sctp/input.c
> > index 621b5ca3fd1c17c3d7ef7bb1c7677ab98cebbe77..a24658c6f181e03d85f12dbe929c8bb4abaefcbd 100644
> > --- a/net/sctp/input.c
> > +++ b/net/sctp/input.c
> > @@ -412,8 +412,11 @@ void sctp_icmp_frag_needed(struct sock *sk, struct sctp_association *asoc,
> > * Needed will never be sent, but if a message was sent before
> > * PMTU discovery was disabled that was larger than the PMTU, it
> > * would not be fragmented, so it must be re-transmitted fragmented.
> > + * If the new PMTU is invalid, we will keep getting ICMP Frag
> > + * Needed. In this case, simply avoid the retransmit.
> > */
> > - sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
> > + if (pmtu >= SCTP_DEFAULT_MINSEGMENT)
> > + sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
> > }
> >
> > void sctp_icmp_redirect(struct sock *sk, struct sctp_transport *t,
> > diff --git a/net/sctp/transport.c b/net/sctp/transport.c
> > index 1e5a22430cf56e40a6f323081beb97836b506384..fbd9fe25764d4d98f93c60a48eccefd9cc6b4165 100644
> > --- a/net/sctp/transport.c
> > +++ b/net/sctp/transport.c
> > @@ -259,6 +259,8 @@ void sctp_transport_update_pmtu(struct sctp_transport *t, u32 pmtu)
> > * pmtu discovery on this transport.
> > */
> > t->pathmtu = SCTP_DEFAULT_MINSEGMENT;
> > + t->param_flags = (t->param_flags & ~SPP_PMTUD) |
> > + SPP_PMTUD_DISABLE;
> It seems that once it hits here, this transport will have the minimum pmtu
> forever, even after t->dst has expired. It means this tx path will not come
> back to normal any more even when it gets a needfrag with reasonable
> pmtu. is it too harsh to this transport ?
That was the idea. That is what the comment above these lines is
describing already. Though I missed 06ad391919b2 ("[SCTP] Don't
disable PMTU discovery when mtu is small") and yes, too harsh.
>
> Another thing is on sctp_sendmsg, it also checks pmtu_pending that may
> be set by needfrag, and goes to sctp_assoc_sync_pmtu to trigger this
> warning again.
That is true but that's not an issue, is it? We are not trying to get
ride of the warning, instead we want to not cause a flood of
bogus retransmissions (which led to the flood of warnings).
By not disabling PMTU discovery (as above) we will have such warning
every now and then again for the same transport. We may add
_ratelimited to it, that would help in the case of we have like a
thousand transports suddenly being affected by such small MTU, but
won't omit it completely.
I'll spin a v2, thanks.
>
> > } else {
> > t->pathmtu = pmtu;
> > }
> > --
> > 2.14.3
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2018-01-03 13:33 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Graeme Gregory, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <CAPv3WKfZN+=9wFJ5ct+8nttd=bikaZ=Ei741pyTVXjQz2zq2dg@mail.gmail.com>
On Wed, Jan 03, 2018 at 02:13:09PM +0100, Marcin Wojtas wrote:
> Hi Andrew,
>
> 2018-01-03 13:47 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> >> I already agreed with 'reg' being awkward in the later emails.
> >> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
> >
> > Also, how do you specify which MDIO bus the PHY is on. To fully
> > specify a PHY, you need both bits of information.
> >
> > In DT, the phy-handle phandle can point to any PHY anywhere in the
> > system. This is particularly important when a Ethernet device has two
> > MDIO busses.
> >
>
> For now, my local MDIO bus description is pretty DT-like, i.e. master
> bus with children PHYs:
> Device (MDIO)
> {
> Name (_HID, "MRVL0100") //
> _HID: Hardware ID
> Name (_UID, 0x00) //
> _UID: Unique ID
> Name (_CRS, ResourceTemplate ()
> {
> Memory32Fixed (ReadWrite,
> 0xf212a200, // Address Base
> 0x00000010, //
> Address Length
> )
> })
> Device (GPHY)
> {
> Name (_ADR, 0x0)
> }
> }
>
> Device (XSMI)
> {
> Name (_HID, "MRVL0101") //
> _HID: Hardware ID
> Name (_UID, 0x00) //
> _UID: Unique ID
> Name (_CRS, ResourceTemplate ()
> {
> Memory32Fixed (ReadWrite,
> 0xf212a600, // Address Base
> 0x00000010, //
> Address Length
> )
> })
> Device (PHY0)
> {
> Name (_ADR, 0x0)
> Name (_CID, "ethernet-phy-ieee802.3-c45")
> }
> Device (PHY8)
> {
> Name (_ADR, 0x8)
> Name (_CID, "ethernet-phy-ieee802.3-c45")
> }
> }
>
> Which is referenced in the port's node:
>
> Package () { "phy", Package (){\_SB.XSMI.PHY0}},
Hi Marcin
This reference looks good, giving both the bus and the PHY on the bus.
I assume you can use references like this within the Device (PHY8)
node? You need to be able to reference a GPIO used for resetting the
PHY. And you also need to reference a GPIO at the Device (MDIO) level
for resetting all the PHYs on the MDIO bus.
Andrew
^ permalink raw reply
* Re: [PATCHv1 1/6] net: dsa: Support internal phy on 'cpu' port
From: Andrew Lunn @ 2018-01-03 13:21 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Vivien Didelot, Florian Fainelli, Shawn Guo, Sascha Hauer,
Fabio Estevam, Ian Ray, Nandor Han, Rob Herring, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180103122609.5482-2-sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
On Wed, Jan 03, 2018 at 01:26:04PM +0100, Sebastian Reichel wrote:
> This adds support for enabling the internal phy for a 'cpu' port.
> It has been tested on GE B850v3 and B650v3, which have a built-in
> MV88E6240 switch connected to a PCIe based network card. Without
> this patch the link does not come up and no traffic can be routed
> through the switch.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> ---
> net/dsa/port.c | 26 ++++++++++++++++++++++----
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/net/dsa/port.c b/net/dsa/port.c
> index bb4be2679904..f99c1d34416c 100644
> --- a/net/dsa/port.c
> +++ b/net/dsa/port.c
> @@ -282,6 +282,10 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> int mode;
> int err;
>
> + mode = of_get_phy_mode(dn);
> + if (mode < 0)
> + mode = PHY_INTERFACE_MODE_NA;
> +
> if (of_phy_is_fixed_link(dn)) {
> err = of_phy_register_fixed_link(dn);
> if (err) {
> @@ -292,10 +296,6 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> }
>
> phydev = of_phy_find_device(dn);
> -
> - mode = of_get_phy_mode(dn);
> - if (mode < 0)
> - mode = PHY_INTERFACE_MODE_NA;
> phydev->interface = mode;
>
> genphy_config_init(phydev);
> @@ -305,6 +305,24 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
> ds->ops->adjust_link(ds, port, phydev);
>
> put_device(&phydev->mdio.dev);
> + } else if (mode == PHY_INTERFACE_MODE_INTERNAL ||
> + mode == PHY_INTERFACE_MODE_NA) {
Hi Sebastian
I understand what you are trying to do, i've got boards which also
have back-to-back PHYs for the CPU port. These boards however have the
strapping correct, so nothing needs doing in software.
But the way you are doing it is wrong. PHY_INTERFACE_MODE_NA means
something else has already setup the interface mode, leave it alone.
PHY_INTERFACE_MODE_INTERNAL means there is some other sort of bus
between the MAC and the PHY than the normal MII.
What you want to say is that there is a PHY on this port, and that you
want to configure it to a given fixed configuration, probably 1000
Full, with auto-neg turned off. This is something completely different
to a fixed phy, which is used when there is no PHY at all.
What state is the PHY in, if you don't have this patch? Is it powered
down?
Andrew
--
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: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2018-01-03 13:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: Graeme Gregory, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <20180103124720.GG15036@lunn.ch>
Hi Andrew,
2018-01-03 13:47 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>> I already agreed with 'reg' being awkward in the later emails.
>> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
>
> Also, how do you specify which MDIO bus the PHY is on. To fully
> specify a PHY, you need both bits of information.
>
> In DT, the phy-handle phandle can point to any PHY anywhere in the
> system. This is particularly important when a Ethernet device has two
> MDIO busses.
>
For now, my local MDIO bus description is pretty DT-like, i.e. master
bus with children PHYs:
Device (MDIO)
{
Name (_HID, "MRVL0100") //
_HID: Hardware ID
Name (_UID, 0x00) //
_UID: Unique ID
Name (_CRS, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0xf212a200, // Address Base
0x00000010, //
Address Length
)
})
Device (GPHY)
{
Name (_ADR, 0x0)
}
}
Device (XSMI)
{
Name (_HID, "MRVL0101") //
_HID: Hardware ID
Name (_UID, 0x00) //
_UID: Unique ID
Name (_CRS, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0xf212a600, // Address Base
0x00000010, //
Address Length
)
})
Device (PHY0)
{
Name (_ADR, 0x0)
Name (_CID, "ethernet-phy-ieee802.3-c45")
}
Device (PHY8)
{
Name (_ADR, 0x8)
Name (_CID, "ethernet-phy-ieee802.3-c45")
}
}
Which is referenced in the port's node:
Package () { "phy", Package (){\_SB.XSMI.PHY0}},
I'm studying an alternatives with graphs, as suggested by Tomasz
Nowicki, but to me above is pretty natural and not complicated.
Best regards,
Marcin
^ permalink raw reply
* Re: [PATCHv1 2/6] net: dsa: mv88e6xxx: add 88E6240 DT compatible
From: Andrew Lunn @ 2018-01-03 12:55 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Vivien Didelot, Florian Fainelli, Shawn Guo, Sascha Hauer,
Fabio Estevam, Ian Ray, Nandor Han, Rob Herring, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180103122609.5482-3-sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
On Wed, Jan 03, 2018 at 01:26:05PM +0100, Sebastian Reichel wrote:
> Add compatible for Marvell 88E6240 switch.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/dsa/marvell.txt | 6 ++++--
> drivers/net/dsa/mv88e6xxx/chip.c | 4 ++++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt
> index 1d4d0f49c9d0..cf437b526f7f 100644
> --- a/Documentation/devicetree/bindings/net/dsa/marvell.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt
> @@ -14,8 +14,10 @@ The properties described here are those specific to Marvell devices.
> Additional required and optional properties can be found in dsa.txt.
>
> Required properties:
> -- compatible : Should be one of "marvell,mv88e6085" or
> - "marvell,mv88e6190"
> +- compatible : Should be one of the following
> + * "marvell,mv88e6085"
> + * "marvell,mv88e6190"
> + * "marvell,mv88e6240"
Hi Sebastian
This is not required. The 6240 is compatible with the 6085, so please
use "marvell,mv88e6085". We don't add compatible strings per
device. All the compatible string is used for is to find the ID
register in the device. Nothing more.
Andrew
--
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: [PATCH v6 4/6] can: m_can: Support higher speed CAN-FD bitrates
From: Faiz Abbas @ 2018-01-03 12:55 UTC (permalink / raw)
To: Marc Kleine-Budde, wg, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, nsekhar, fcooper,
robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <f2a063cd-9456-c21d-2544-02179e0f4f27@pengutronix.de>
Hi,
On Tuesday 02 January 2018 07:05 PM, Marc Kleine-Budde wrote:
> On 12/22/2017 02:31 PM, Faiz Abbas wrote:
>> From: Franklin S Cooper Jr <fcooper@ti.com>
>>
>> During test transmitting using CAN-FD at high bitrates (> 2 Mbps)
>> would fail. Scoping the signals I noticed that only a single bit
>> was being transmitted and with a bit more investigation realized the actual
>> MCAN IP would go back to initialization mode automatically.
>>
>> It appears this issue is due to the MCAN needing to use the Transmitter
>> Delay Compensation Mode with the correct value for the transmitter delay
>> compensation offset (tdco). What impacts the tdco value isn't 100% clear
>> but to calculate it you use an equation defined in the MCAN User's Guide.
>>
>> The user guide mentions that this register needs to be set based on clock
>> values, secondary sample point and the data bitrate. One of the key
>> variables that can't automatically be determined is the secondary
>> sample point (ssp). This ssp is similar to the sp but is specific to this
>> transmitter delay compensation mode. The guidelines for configuring
>> ssp is rather vague but via some CAN test it appears for DRA76x that putting
>> the value same as data sampling point works.
>>
>> The CAN-CIA's "Bit Time Requirements for CAN FD" paper presented at
>> the International CAN Conference 2013 indicates that this TDC mode is
>> only needed for data bit rates above 2.5 Mbps. Therefore, only enable
>> this mode when the data bit rate is above 2.5 Mbps.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> ---
>> drivers/net/can/m_can/m_can.c | 41 ++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 40 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>> index 53e764f..371ffc1 100644
>> --- a/drivers/net/can/m_can/m_can.c
>> +++ b/drivers/net/can/m_can/m_can.c
>> @@ -127,6 +127,12 @@ enum m_can_mram_cfg {
>> #define DBTP_DSJW_SHIFT 0
>> #define DBTP_DSJW_MASK (0xf << DBTP_DSJW_SHIFT)
>>
>> +/* Transmitter Delay Compensation Register (TDCR) */
>> +#define TDCR_TDCO_SHIFT 8
>> +#define TDCR_TDCO_MASK (0x7F << TDCR_TDCO_SHIFT)
>> +#define TDCR_TDCF_SHIFT 0
>> +#define TDCR_TDCF_MASK (0x7F << TDCR_TDCF_SHIFT)
>> +
>> /* Test Register (TEST) */
>> #define TEST_LBCK BIT(4)
>>
>> @@ -991,7 +997,8 @@ static int m_can_set_bittiming(struct net_device *dev)
>> const struct can_bittiming *bt = &priv->can.bittiming;
>> const struct can_bittiming *dbt = &priv->can.data_bittiming;
>> u16 brp, sjw, tseg1, tseg2;
>> - u32 reg_btp;
>> + u32 reg_btp, tdco, ssp;
>
> Please move the tdco and the ssp into "if (dbt->bitrate > 2500000)" scope.
Ok.
>
> Initialize "reg_btp = 0", see below.
>
>> + bool enable_tdc = false;
>
> Please remove, see below.
>
>>
>> brp = bt->brp - 1;
>> sjw = bt->sjw - 1;
>> @@ -1006,9 +1013,41 @@ static int m_can_set_bittiming(struct net_device *dev)
>> sjw = dbt->sjw - 1;
>> tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
>> tseg2 = dbt->phase_seg2 - 1;
>> +
>> + /* TDC is only needed for bitrates beyond 2.5 MBit/s.
>> + * This is mentioned in the "Bit Time Requirements for CAN FD"
>> + * paper presented at the International CAN Conference 2013
>> + */
>> + if (dbt->bitrate > 2500000) {
>> + /* Use the same value of secondary sampling point
>> + * as the data sampling point
>> + */
>> + ssp = dbt->sample_point;
>> +
>> + /* Equation based on Bosch's M_CAN User Manual's
>> + * Transmitter Delay Compensation Section
>> + */
>> + tdco = (priv->can.clock.freq / 1000) *
>> + ssp / dbt->bitrate;
>> +
>> + /* Max valid TDCO value is 127 */
>> + if (tdco > 127) {
>> + netdev_warn(dev, "TDCO value of %u is beyond maximum limit. Disabling Transmitter Delay Compensation mode\n",
>
> "maximum limit"? Either "maximum" or "limit" should be enough. If the
> value is above 127, does it make sense to disable the tdco completely?
I guess we can put the closest possible value (127) so that the ssp
calculated by the IP is as close to the chosen one as possible.
>
>> + tdco);
>> + } else {
>> + enable_tdc = true;
>
> Why not set "reg_btp |= DBTP_TDC;" here directly?
>
>> + m_can_write(priv, M_CAN_TDCR,
>> + tdco << TDCR_TDCO_SHIFT);
>> + }
>> + }
>> +
>> reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
>> (tseg1 << DBTP_DTSEG1_SHIFT) |
>> (tseg2 << DBTP_DTSEG2_SHIFT);
>
> Adjust this to "reg_btp |=".
>
>> +
>> + if (enable_tdc)
>> + reg_btp |= DBTP_TDC;
>
> Please remove.
Sure, will remove.
Thanks,
Faiz
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2018-01-03 12:47 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Graeme Gregory, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <CAPv3WKcM8WWvh64A=FTtuWkEr6V_QSKjBpNpWnMpp_P=cMU9sw@mail.gmail.com>
> I already agreed with 'reg' being awkward in the later emails.
> Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
Also, how do you specify which MDIO bus the PHY is on. To fully
specify a PHY, you need both bits of information.
In DT, the phy-handle phandle can point to any PHY anywhere in the
system. This is particularly important when a Ethernet device has two
MDIO busses.
Andrew
^ permalink raw reply
* Re: [PATCH v6 3/6] can: m_can: Add PM Runtime
From: Faiz Abbas @ 2018-01-03 12:39 UTC (permalink / raw)
To: Marc Kleine-Budde, wg-5Yr1BZd7O62+XT7JhA+gdA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
fcooper-l0cyMroinI0, robh-DgEjT+Ai2ygdnm+yROfE0A,
Wenyou.Yang-UWL1GkI3JZL3oGB3hsPCZA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8
In-Reply-To: <aea8638a-c847-b55e-ff2d-37999980ba7b-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi,
On Tuesday 02 January 2018 09:37 PM, Marc Kleine-Budde wrote:
> On 12/22/2017 02:31 PM, Faiz Abbas wrote:
>> From: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
>>
>> Add support for PM Runtime which is the new way to handle managing clocks.
>> However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
>> management approach in place.
>
> There is no PM_RUNTIME anymore since 464ed18ebdb6 ("PM: Eliminate
> CONFIG_PM_RUNTIME")
Ok. Will change the commit message.
>
> Have a look at the discussion: https://patchwork.kernel.org/patch/9436507/ :
>
>>> Well, I admit it would be nicer if drivers didn't have to worry about
>>> whether or not CONFIG_PM was enabled. A slightly cleaner approach
>>> from the one outlined above would have the probe routine do this:
>>>
>>> my_power_up(dev);
>>> pm_runtime_set_active(dev);
>>> pm_runtime_get_noresume(dev);
>>> pm_runtime_enable(dev);
This discussion seems to be about cases in which CONFIG_PM is not
enabled. CONFIG_PM is always selected in the case of omap devices.
>
>> PM_RUNTIME is required by OMAP based devices to handle clock management.
>> Therefore, this allows future Texas Instruments SoCs that have the MCAN IP
>> to work with this driver.
>
> Who will set the SET_RUNTIME_PM_OPS in this case?
It is set with a common SET_RUNTIME_PM_OPS in the case of omap at
arch/arm/mach-omap2/omap_device.c:632
struct dev_pm_domain omap_device_pm_domain = {
.ops = {
SET_RUNTIME_PM_OPS(_od_runtime_suspend, _od_runtime_resume,
NULL)
USE_PLATFORM_PM_SLEEP_OPS
SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(_od_suspend_noirq,
_od_resume_noirq)
}
};
>
>> Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
>> [nsekhar-l0cyMroinI0@public.gmane.org: handle pm_runtime_get_sync() failure, fix some bugs]
>> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
>> Signed-off-by: Faiz Abbas <faiz_abbas-l0cyMroinI0@public.gmane.org>
>> ---
>> drivers/net/can/m_can/m_can.c | 38 ++++++++++++++++++++++++++++++++++----
>> 1 file changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>> index f72116e..53e764f 100644
>> --- a/drivers/net/can/m_can/m_can.c
>> +++ b/drivers/net/can/m_can/m_can.c
>> @@ -23,6 +23,7 @@
>> #include <linux/of.h>
>> #include <linux/of_device.h>
>> #include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> #include <linux/iopoll.h>
>> #include <linux/can/dev.h>
>>
>> @@ -625,19 +626,33 @@ static int m_can_clk_start(struct m_can_priv *priv)
>> {
>> int err;
>>
>> + err = pm_runtime_get_sync(priv->device);
>> + if (err) {
>> + pm_runtime_put_noidle(priv->device);
>
> Why do you call this in case of an error?
pm_runtime_get_sync() increments the usage count of the device before
any error is returned. This needs to be decremented using
pm_runtime_put_noidle().
>
>> + return err;
>> + }
>> +
>> err = clk_prepare_enable(priv->hclk);
>> if (err)
>> - return err;
>> + goto pm_runtime_put;
>>
>> err = clk_prepare_enable(priv->cclk);
>> if (err)
>> - clk_disable_unprepare(priv->hclk);
>> + goto disable_hclk;
>>
>> return err;
>> +
>> +disable_hclk:
>> + clk_disable_unprepare(priv->hclk);
>> +pm_runtime_put:
>> + pm_runtime_put_sync(priv->device);
>> + return err;
>> }
>>
>> static void m_can_clk_stop(struct m_can_priv *priv)
>> {
>> + pm_runtime_put_sync(priv->device);
>> +
>> clk_disable_unprepare(priv->cclk);
>> clk_disable_unprepare(priv->hclk);
>> }
>> @@ -1577,13 +1592,20 @@ static int m_can_plat_probe(struct platform_device *pdev)
>> /* Enable clocks. Necessary to read Core Release in order to determine
>> * M_CAN version
>> */
>> + pm_runtime_enable(&pdev->dev);
>> + ret = pm_runtime_get_sync(&pdev->dev);
>> + if (ret) {
>> + pm_runtime_put_noidle(&pdev->dev);
>
> Why do you call this in case of error?
Same here.
Thanks,
Faiz
--
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: [PATCH] rt2x00: Delete an error message for a failed memory allocation in rt2x00queue_allocate()
From: Stanislaw Gruszka @ 2018-01-03 12:26 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linux-wireless, netdev, Helmut Schaa, Kalle Valo, LKML,
kernel-janitors
In-Reply-To: <cdeaa8a2-06bb-10e9-05d7-f531c00eef5d@users.sourceforge.net>
On Fri, Dec 29, 2017 at 10:18:14PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 29 Dec 2017 22:11:42 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* [PATCHv1 6/6] ARM: dts: imx6q-b450v3: Add switch port configuration
From: Sebastian Reichel @ 2018-01-03 12:26 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Shawn Guo,
Sascha Hauer, Fabio Estevam
Cc: Ian Ray, Nandor Han, Rob Herring, David S. Miller, netdev,
devicetree, linux-kernel, Sebastian Reichel
In-Reply-To: <20180103122609.5482-1-sebastian.reichel@collabora.co.uk>
This adds support for the Marvell switch and names the network
ports according to the labels, that can be found next to the
connectors. The switch is connected to the host system using a
PCI based network card.
The PCI bus configuration has been written using the following
information:
root@b450v3# lspci -tv
-[0000:00]---00.0-[01]----00.0 Intel Corporation I210 Gigabit Network Connection
root@b450v3# lspci -nn
00:00.0 PCI bridge [0604]: Synopsys, Inc. Device [16c3:abcd] (rev 01)
01:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
arch/arm/boot/dts/imx6q-b450v3.dts | 47 ++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts b/arch/arm/boot/dts/imx6q-b450v3.dts
index 404a93d9596b..693dfa7d751d 100644
--- a/arch/arm/boot/dts/imx6q-b450v3.dts
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -112,3 +112,50 @@
line-name = "PCA9539-P07";
};
};
+
+&pci_root {
+ /* Intel Corporation I210 Gigabit Network Connection */
+ switch_nic: ethernet@3,0 {
+ compatible = "pci8086,1533";
+ reg = <0x00010000 0 0 0 0>;
+ };
+};
+
+&switch_ports {
+ port@0 {
+ reg = <0>;
+ label = "enacq";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "eneport1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "enix";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "enid";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "cpu";
+ ethernet = <&switch_nic>;
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "enembc";
+
+ /* connected to Ethernet MAC of AT91RM9200 in MII mode */
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCHv1 5/6] ARM: dts: imx6q-b650v3: Add switch port configuration
From: Sebastian Reichel @ 2018-01-03 12:26 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Shawn Guo,
Sascha Hauer, Fabio Estevam
Cc: Ian Ray, Nandor Han, Rob Herring, David S. Miller, netdev,
devicetree, linux-kernel, Sebastian Reichel
In-Reply-To: <20180103122609.5482-1-sebastian.reichel@collabora.co.uk>
This adds support for the Marvell switch and names the network
ports according to the labels, that can be found next to the
connectors. The switch is connected to the host system using a
PCI based network card.
The PCI bus configuration has been written using the following
information:
root@b650v3# lspci -tv
-[0000:00]---00.0-[01]----00.0 Intel Corporation I210 Gigabit Network Connection
root@b650v3# lspci -nn
00:00.0 PCI bridge [0604]: Synopsys, Inc. Device [16c3:abcd] (rev 01)
01:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
arch/arm/boot/dts/imx6q-b650v3.dts | 47 ++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts b/arch/arm/boot/dts/imx6q-b650v3.dts
index 7f9f176901d4..928f6cd8d5ae 100644
--- a/arch/arm/boot/dts/imx6q-b650v3.dts
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -111,3 +111,50 @@
fsl,tx-cal-45-dp-ohms = <55>;
fsl,tx-d-cal = <100>;
};
+
+&pci_root {
+ /* Intel Corporation I210 Gigabit Network Connection */
+ switch_nic: ethernet@3,0 {
+ compatible = "pci8086,1533";
+ reg = <0x00010000 0 0 0 0>;
+ };
+};
+
+&switch_ports {
+ port@0 {
+ reg = <0>;
+ label = "enacq";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "eneport1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "enix";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "enid";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "cpu";
+ ethernet = <&switch_nic>;
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "enembc";
+
+ /* connected to Ethernet MAC of AT91RM9200 in MII mode */
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCHv1 4/6] ARM: dts: imx6q-b850v3: Add switch port configuration
From: Sebastian Reichel @ 2018-01-03 12:26 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Shawn Guo,
Sascha Hauer, Fabio Estevam
Cc: Ian Ray, Nandor Han, Rob Herring, David S. Miller, netdev,
devicetree, linux-kernel, Sebastian Reichel
In-Reply-To: <20180103122609.5482-1-sebastian.reichel@collabora.co.uk>
This adds support for the Marvell switch and names the network
ports according to the labels, that can be found next to the
connectors ("ID", "IX", "ePort 1", "ePort 2"). The switch is
connected to the host system using a PCI based network card.
The PCI bus configuration has been written using the following
information:
root@b850v3# lspci -tv
-[0000:00]---00.0-[01]----00.0-[02-05]--+-01.0-[03]----00.0 Intel Corporation I210 Gigabit Network Connection
+-02.0-[04]----00.0 Intel Corporation I210 Gigabit Network Connection
\-03.0-[05]--
root@b850v3# lspci -nn
00:00.0 PCI bridge [0604]: Synopsys, Inc. Device [16c3:abcd] (rev 01)
01:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8605 PCI Express 4-port Gen2 Switch [10b5:8605] (rev ab)
02:01.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8605 PCI Express 4-port Gen2 Switch [10b5:8605] (rev ab)
02:02.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8605 PCI Express 4-port Gen2 Switch [10b5:8605] (rev ab)
02:03.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8605 PCI Express 4-port Gen2 Switch [10b5:8605] (rev ab)
03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
04:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
arch/arm/boot/dts/imx6q-b850v3.dts | 70 ++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts b/arch/arm/boot/dts/imx6q-b850v3.dts
index 46bdc6722715..a55ccdfb341c 100644
--- a/arch/arm/boot/dts/imx6q-b850v3.dts
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -212,3 +212,73 @@
};
};
};
+
+&pci_root {
+ /* PLX Technology, Inc. PEX 8605 PCI Express 4-port Gen2 Switch */
+ bridge@1,0 {
+ compatible = "pci10b5,8605";
+ reg = <0x00010000 0 0 0 0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+
+ bridge@2,1 {
+ compatible = "pci10b5,8605";
+ reg = <0x00020800 0 0 0 0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+
+ /* Intel Corporation I210 Gigabit Network Connection */
+ ethernet@3,0 {
+ compatible = "pci8086,1533";
+ reg = <0x00030000 0 0 0 0>;
+ };
+ };
+
+ bridge@2,2 {
+ compatible = "pci10b5,8605";
+ reg = <0x00021000 0 0 0 0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+
+ /* Intel Corporation I210 Gigabit Network Connection */
+ switch_nic: ethernet@4,0 {
+ compatible = "pci8086,1533";
+ reg = <0x00040000 0 0 0 0>;
+ };
+ };
+ };
+};
+
+&switch_ports {
+ port@0 {
+ reg = <0>;
+ label = "eneport1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "eneport2";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "enix";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "enid";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "cpu";
+ ethernet = <&switch_nic>;
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCHv1 3/6] ARM: dts: imx6q-bx50v3: Add internal switch
From: Sebastian Reichel @ 2018-01-03 12:26 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Shawn Guo,
Sascha Hauer, Fabio Estevam
Cc: Ian Ray, Nandor Han, Rob Herring, David S. Miller, netdev,
devicetree, linux-kernel, Sebastian Reichel
In-Reply-To: <20180103122609.5482-1-sebastian.reichel@collabora.co.uk>
B850v3, B650v3 and B450v3 all have a GPIO bit banged MDIO bus to
communicate with a Marvell switch. On all devices the switch is
connected to a PCI based network card, which needs to be referenced
by DT, so this also adds the common PCI root node.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
index b915837bbb5f..689981e90e68 100644
--- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -92,6 +92,31 @@
mux-int-port = <1>;
mux-ext-port = <4>;
};
+
+ aliases {
+ mdio-gpio0 = &mdio0;
+ };
+
+ mdio0: mdio-gpio {
+ compatible = "virtual,mdio-gpio";
+ gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>, /* mdc */
+ <&gpio2 7 GPIO_ACTIVE_HIGH>; /* mdio */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "marvell,mv88e6240";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ switch_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+ };
};
&ecspi5 {
@@ -326,3 +351,15 @@
tcxo-clock-frequency = <26000000>;
};
};
+
+&pcie {
+ /* Synopsys, Inc. Device */
+ pci_root: root@0,0 {
+ compatible = "pci16c3,abcd";
+ reg = <0x00000000 0 0 0 0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCHv1 2/6] net: dsa: mv88e6xxx: add 88E6240 DT compatible
From: Sebastian Reichel @ 2018-01-03 12:26 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Shawn Guo,
Sascha Hauer, Fabio Estevam
Cc: Ian Ray, Nandor Han, Rob Herring, David S. Miller, netdev,
devicetree, linux-kernel, Sebastian Reichel
In-Reply-To: <20180103122609.5482-1-sebastian.reichel@collabora.co.uk>
Add compatible for Marvell 88E6240 switch.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
Documentation/devicetree/bindings/net/dsa/marvell.txt | 6 ++++--
drivers/net/dsa/mv88e6xxx/chip.c | 4 ++++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt
index 1d4d0f49c9d0..cf437b526f7f 100644
--- a/Documentation/devicetree/bindings/net/dsa/marvell.txt
+++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt
@@ -14,8 +14,10 @@ The properties described here are those specific to Marvell devices.
Additional required and optional properties can be found in dsa.txt.
Required properties:
-- compatible : Should be one of "marvell,mv88e6085" or
- "marvell,mv88e6190"
+- compatible : Should be one of the following
+ * "marvell,mv88e6085"
+ * "marvell,mv88e6190"
+ * "marvell,mv88e6240"
- reg : Address on the MII bus for the switch.
Optional properties:
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 66d33e97cbc5..78ff06239b58 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -4012,6 +4012,10 @@ static const struct of_device_id mv88e6xxx_of_match[] = {
.compatible = "marvell,mv88e6190",
.data = &mv88e6xxx_table[MV88E6190],
},
+ {
+ .compatible = "marvell,mv88e6240",
+ .data = &mv88e6xxx_table[MV88E6240],
+ },
{ /* sentinel */ },
};
--
2.15.1
^ permalink raw reply related
* [PATCHv1 1/6] net: dsa: Support internal phy on 'cpu' port
From: Sebastian Reichel @ 2018-01-03 12:26 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Shawn Guo,
Sascha Hauer, Fabio Estevam
Cc: Ian Ray, Nandor Han, Rob Herring, David S. Miller, netdev,
devicetree, linux-kernel, Sebastian Reichel
In-Reply-To: <20180103122609.5482-1-sebastian.reichel@collabora.co.uk>
This adds support for enabling the internal phy for a 'cpu' port.
It has been tested on GE B850v3 and B650v3, which have a built-in
MV88E6240 switch connected to a PCIe based network card. Without
this patch the link does not come up and no traffic can be routed
through the switch.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
net/dsa/port.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/net/dsa/port.c b/net/dsa/port.c
index bb4be2679904..f99c1d34416c 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -282,6 +282,10 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
int mode;
int err;
+ mode = of_get_phy_mode(dn);
+ if (mode < 0)
+ mode = PHY_INTERFACE_MODE_NA;
+
if (of_phy_is_fixed_link(dn)) {
err = of_phy_register_fixed_link(dn);
if (err) {
@@ -292,10 +296,6 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
}
phydev = of_phy_find_device(dn);
-
- mode = of_get_phy_mode(dn);
- if (mode < 0)
- mode = PHY_INTERFACE_MODE_NA;
phydev->interface = mode;
genphy_config_init(phydev);
@@ -305,6 +305,24 @@ int dsa_port_fixed_link_register_of(struct dsa_port *dp)
ds->ops->adjust_link(ds, port, phydev);
put_device(&phydev->mdio.dev);
+ } else if (mode == PHY_INTERFACE_MODE_INTERNAL ||
+ mode == PHY_INTERFACE_MODE_NA) {
+ phydev = mdiobus_get_phy(ds->slave_mii_bus, port);
+ if (phydev) {
+ genphy_config_init(phydev);
+ genphy_resume(phydev);
+ genphy_read_status(phydev);
+
+ if (ds->ops->adjust_link)
+ ds->ops->adjust_link(ds, port, phydev);
+
+ dev_dbg(ds->dev, "enabled cpu port's phy: %s",
+ phydev_name(phydev));
+ } else {
+ dev_warn(ds->dev, "cpu port has no internal phy and no fixed linked has been configured!");
+ }
+ } else {
+ dev_err(ds->dev, "unsupported phy mode!");
}
return 0;
--
2.15.1
^ permalink raw reply related
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