* Re: No traffic with Marvell switch and latest linux-next
From: Russell King - ARM Linux admin @ 2019-02-24 19:41 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Heiner Kallweit, Florian Fainelli, netdev@vger.kernel.org
In-Reply-To: <20190224172848.GI26626@lunn.ch>
On Sun, Feb 24, 2019 at 06:28:48PM +0100, Andrew Lunn wrote:
> On Sun, Feb 24, 2019 at 03:31:26PM +0000, Russell King - ARM Linux admin wrote:
> > On Sun, Feb 24, 2019 at 12:42:35AM +0100, Andrew Lunn wrote:
> > > Looking forward, at some point we are going to have to make fixed-link
> > > support higher speeds. That probably means we need a swphy-c45 which
> > > emulates the standard registers for 2.5G, 5G and 10G. At that point
> > > genphy will not work...
> >
> > Do we _need_ to emulate Clause 45 PHYs?
>
> Hi Russell
>
> One use case would be a mv88e6390X port 9 or 10 connected to a SoC
> which can only do 2.5G.
>
> We have defined that DSA drivers should configure CPU and DSA ports to
> their maximum speed. So if port 9 or 10 is used, it should be
> configured to 10G.
>
> We then need some way to reconfigure the MAC to a slower speed.
>
> We need to do this with ZII boards. We do this with:
>
> port@0 {
> reg = <0>;
> label = "cpu";
> ethernet = <&fec1>;
>
> fixed-link {
> speed = <100>;
> full-duplex;
> };
> };
>
> The FEC can only do 100Mbs, but the switch defaults to 1G. So the
> fixed link it used to tell the switch MAC to use 100/Full.
>
> In the example of the 6390X, we would want to set the link speed to
> 2500, which we cannot do at the moment. Either we need fixed-link to
> support higher speeds, or we need a different mechanism.
>
> We also have a similar issue on the SoC side. The FEC has no PHY
> connected to it. It needs to be told what speed to do:
>
> &fec1 {
> phy-mode = "rmii";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_fec1>;
> status = "okay";
>
> fixed-link {
> speed = <100>;
> full-duplex;
> };
>
> In the case of a SoC with an interface which can do 2.5G, you need to
> tell it to do 2.5G. Ideally we want a mechanism that allows a MAC to
> 'see' a PHY operating at 2.5G using the standard phylib/phylink API.
>
> In the past this has been achieved with an emulated PHY. But so long
> as the phydev/phylink structure has the correct values, it does not
> matter how they get those values.
You'll get a mac_config() with the mode set to MLO_AN_FIXED.
state->speed set to whatever was set in the "speed =" and state->duplex
set according to the duplex property. If pause modes are also defined,
you'll get those through state->pause MLO_PAUSE_SYM and MLO_PAUSE_ASYM,
but there won't be any resolution of those modes since a fixed link
doesn't know the other ends properties, and of course AN is disabled.
Apart from the pause modes, the information passed to the MAC for a
fixed link is exactly the same as if it came from a PHY in phylib,
which basically means the MAC side doesn't actually need to care
whether it has a PHY or fixed-link - but without the complication of
needing phylib to provide an emulated PHY to the network driver.
phylink does provide an emulated PHY for the mii ioctls since that is
an established interface for speeds <= 1G.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [PATCH net-next] dsa: Remove phydev parameter from disable_port call
From: Andrew Lunn @ 2019-02-24 19:44 UTC (permalink / raw)
To: David Miller
Cc: netdev, Florian Fainelli, Vivien Didelot, hauke, Woojung.Huh,
sean.wang, linus.walleij, Andrew Lunn
No current DSA driver makes use of the phydev parameter passed to the
disable_port call. Remove it.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/b53/b53_common.c | 4 ++--
drivers/net/dsa/b53/b53_priv.h | 2 +-
drivers/net/dsa/bcm_sf2.c | 9 ++++-----
drivers/net/dsa/lan9303-core.c | 3 +--
drivers/net/dsa/lantiq_gswip.c | 5 ++---
drivers/net/dsa/microchip/ksz_common.c | 2 +-
drivers/net/dsa/microchip/ksz_common.h | 2 +-
drivers/net/dsa/mt7530.c | 5 ++---
drivers/net/dsa/mv88e6xxx/chip.c | 3 +--
drivers/net/dsa/qca8k.c | 3 +--
drivers/net/dsa/rtl8366rb.c | 3 +--
drivers/net/dsa/vitesse-vsc73xx.c | 3 +--
include/net/dsa.h | 3 +--
net/dsa/dsa_priv.h | 2 +-
net/dsa/port.c | 4 ++--
net/dsa/slave.c | 2 +-
16 files changed, 23 insertions(+), 32 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 0e4bbdcc614f..50cebb96e685 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -534,7 +534,7 @@ int b53_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
}
EXPORT_SYMBOL(b53_enable_port);
-void b53_disable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
+void b53_disable_port(struct dsa_switch *ds, int port)
{
struct b53_device *dev = ds->priv;
u8 reg;
@@ -944,7 +944,7 @@ static int b53_setup(struct dsa_switch *ds)
if (dsa_is_cpu_port(ds, port))
b53_enable_cpu_port(dev, port);
else if (dsa_is_unused_port(ds, port))
- b53_disable_port(ds, port, NULL);
+ b53_disable_port(ds, port);
}
return ret;
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index ec796482792d..6b315ae52a79 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -353,7 +353,7 @@ enum dsa_tag_protocol b53_get_tag_protocol(struct dsa_switch *ds, int port);
void b53_mirror_del(struct dsa_switch *ds, int port,
struct dsa_mall_mirror_tc_entry *mirror);
int b53_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
-void b53_disable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
+void b53_disable_port(struct dsa_switch *ds, int port);
void b53_brcm_hdr_setup(struct dsa_switch *ds, int port);
void b53_eee_enable_set(struct dsa_switch *ds, int port, bool enable);
int b53_eee_init(struct dsa_switch *ds, int port, struct phy_device *phy);
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 5193da67dcdc..aade0aa39aed 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -221,8 +221,7 @@ static int bcm_sf2_port_setup(struct dsa_switch *ds, int port,
return b53_enable_port(ds, port, phy);
}
-static void bcm_sf2_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+static void bcm_sf2_port_disable(struct dsa_switch *ds, int port)
{
struct bcm_sf2_priv *priv = bcm_sf2_to_priv(ds);
u32 reg;
@@ -241,7 +240,7 @@ static void bcm_sf2_port_disable(struct dsa_switch *ds, int port,
if (priv->int_phy_mask & 1 << port && priv->hw_params.num_gphy == 1)
bcm_sf2_gphy_enable_set(ds, false);
- b53_disable_port(ds, port, phy);
+ b53_disable_port(ds, port);
/* Power down the port memory */
reg = core_readl(priv, CORE_MEM_PSM_VDD_CTRL);
@@ -692,7 +691,7 @@ static int bcm_sf2_sw_suspend(struct dsa_switch *ds)
*/
for (port = 0; port < DSA_MAX_PORTS; port++) {
if (dsa_is_user_port(ds, port) || dsa_is_cpu_port(ds, port))
- bcm_sf2_port_disable(ds, port, NULL);
+ bcm_sf2_port_disable(ds, port);
}
return 0;
@@ -786,7 +785,7 @@ static int bcm_sf2_sw_setup(struct dsa_switch *ds)
else if (dsa_is_cpu_port(ds, port))
bcm_sf2_imp_setup(ds, port);
else
- bcm_sf2_port_disable(ds, port, NULL);
+ bcm_sf2_port_disable(ds, port);
}
b53_configure_vlan(ds);
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index b4f6e1a67dd9..2ffab7ee3d80 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -1091,8 +1091,7 @@ static int lan9303_port_enable(struct dsa_switch *ds, int port,
return lan9303_enable_processing_port(chip, port);
}
-static void lan9303_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+static void lan9303_port_disable(struct dsa_switch *ds, int port)
{
struct lan9303 *chip = ds->priv;
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 27d092cab40e..ee1455758764 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -480,8 +480,7 @@ static int gswip_port_enable(struct dsa_switch *ds, int port,
return 0;
}
-static void gswip_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+static void gswip_port_disable(struct dsa_switch *ds, int port)
{
struct gswip_priv *priv = ds->priv;
@@ -549,7 +548,7 @@ static int gswip_setup(struct dsa_switch *ds)
/* disable port fetch/store dma on all ports */
for (i = 0; i < priv->hw_info->max_ports; i++)
- gswip_port_disable(ds, i, NULL);
+ gswip_port_disable(ds, i);
/* enable Switch */
gswip_mdio_mask(priv, 0, GSWIP_MDIO_GLOB_ENABLE, GSWIP_MDIO_GLOB);
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 8a5111f9414c..b83337e1566f 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -247,7 +247,7 @@ int ksz_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
}
EXPORT_SYMBOL_GPL(ksz_enable_port);
-void ksz_disable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
+void ksz_disable_port(struct dsa_switch *ds, int port)
{
struct ksz_device *dev = ds->priv;
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 2dd832de0d52..ee3fc9bba292 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -30,7 +30,7 @@ void ksz_port_mdb_add(struct dsa_switch *ds, int port,
int ksz_port_mdb_del(struct dsa_switch *ds, int port,
const struct switchdev_obj_port_mdb *mdb);
int ksz_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
-void ksz_disable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
+void ksz_disable_port(struct dsa_switch *ds, int port);
/* Common register access functions */
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index c2b61500f958..0390c5e8271a 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -729,8 +729,7 @@ mt7530_port_enable(struct dsa_switch *ds, int port,
}
static void
-mt7530_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+mt7530_port_disable(struct dsa_switch *ds, int port)
{
struct mt7530_priv *priv = ds->priv;
@@ -1301,7 +1300,7 @@ mt7530_setup(struct dsa_switch *ds)
if (dsa_is_cpu_port(ds, i))
mt7530_cpu_port_enable(priv, i);
else
- mt7530_port_disable(ds, i, NULL);
+ mt7530_port_disable(ds, i);
}
/* Flush the FDB table */
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 835f126adedf..058ea5d0ab7e 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2388,8 +2388,7 @@ static int mv88e6xxx_port_enable(struct dsa_switch *ds, int port,
return err;
}
-static void mv88e6xxx_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phydev)
+static void mv88e6xxx_port_disable(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 a4b6cda38016..6d5bfe39265f 100644
--- a/drivers/net/dsa/qca8k.c
+++ b/drivers/net/dsa/qca8k.c
@@ -789,8 +789,7 @@ qca8k_port_enable(struct dsa_switch *ds, int port,
}
static void
-qca8k_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+qca8k_port_disable(struct dsa_switch *ds, int port)
{
struct qca8k_priv *priv = (struct qca8k_priv *)ds->priv;
diff --git a/drivers/net/dsa/rtl8366rb.c b/drivers/net/dsa/rtl8366rb.c
index a4d5049df692..40b3974970c6 100644
--- a/drivers/net/dsa/rtl8366rb.c
+++ b/drivers/net/dsa/rtl8366rb.c
@@ -1073,8 +1073,7 @@ rtl8366rb_port_enable(struct dsa_switch *ds, int port,
}
static void
-rtl8366rb_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+rtl8366rb_port_disable(struct dsa_switch *ds, int port)
{
struct realtek_smi *smi = ds->priv;
int ret;
diff --git a/drivers/net/dsa/vitesse-vsc73xx.c b/drivers/net/dsa/vitesse-vsc73xx.c
index 9f1b5f2e8a64..d4780610ea8a 100644
--- a/drivers/net/dsa/vitesse-vsc73xx.c
+++ b/drivers/net/dsa/vitesse-vsc73xx.c
@@ -1013,8 +1013,7 @@ static int vsc73xx_port_enable(struct dsa_switch *ds, int port,
return 0;
}
-static void vsc73xx_port_disable(struct dsa_switch *ds, int port,
- struct phy_device *phy)
+static void vsc73xx_port_disable(struct dsa_switch *ds, int port)
{
struct vsc73xx *vsc = ds->priv;
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 7f2a668ef2cc..d7af808d8500 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -364,8 +364,7 @@ struct dsa_switch_ops {
*/
int (*port_enable)(struct dsa_switch *ds, int port,
struct phy_device *phy);
- void (*port_disable)(struct dsa_switch *ds, int port,
- struct phy_device *phy);
+ void (*port_disable)(struct dsa_switch *ds, int port);
/*
* Port's MAC EEE settings
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 1f4972dab9f2..01ff6e606d46 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -143,7 +143,7 @@ static inline struct net_device *dsa_master_find_slave(struct net_device *dev,
int dsa_port_set_state(struct dsa_port *dp, u8 state,
struct switchdev_trans *trans);
int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy);
-void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy);
+void dsa_port_disable(struct dsa_port *dp);
int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br);
void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br);
int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b23572..17c55ce75c39 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -85,7 +85,7 @@ int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy)
return 0;
}
-void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy)
+void dsa_port_disable(struct dsa_port *dp)
{
struct dsa_switch *ds = dp->ds;
int port = dp->index;
@@ -93,7 +93,7 @@ void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy)
dsa_port_set_state_now(dp, BR_STATE_DISABLED);
if (ds->ops->port_disable)
- ds->ops->port_disable(ds, port, phy);
+ ds->ops->port_disable(ds, port);
}
int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 2e5e7c04821b..8f3f090b7e2d 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -122,7 +122,7 @@ static int dsa_slave_close(struct net_device *dev)
phylink_stop(dp->pl);
- dsa_port_disable(dp, dev->phydev);
+ dsa_port_disable(dp);
dev_mc_unsync(master, dev);
dev_uc_unsync(master, dev);
--
2.20.1
^ permalink raw reply related
* Re: stmmac / meson8b-dwmac
From: Sebastian Gottschall @ 2019-02-24 19:42 UTC (permalink / raw)
To: Simon Huelck, Jerome Brunet, Jose Abreu, Martin Blumenstingl
Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue,
Emiliano Ingrassia, netdev
In-Reply-To: <8ec64936-c8fa-1f0e-68bf-2ad1d6e8f5d9@gmx.de>
> **
>
> **its clearly visible when i activated the other stream for getting
> duplex load ... The highest rate also stays alot under the possible
> 930MBits that i have seen earlier with 4.14.
> **
>
> **
> **
>
> **the parallel stream reached around 450Mbits , which almost sums up to
> 660Mbits. This is what i meant when i said that duplex might be broken.
> **
>
> **
> **
>
> **Connecting to host 10.10.11.100, port 5201
> [ 5] local 10.10.11.1 port 38658 connected to 10.10.11.100 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 62.9 MBytes 528 Mbits/sec 0 65.6 KBytes
> [ 5] 1.00-2.00 sec 56.9 MBytes 477 Mbits/sec 0 65.6 KBytes
> [ 5] 2.00-3.00 sec 55.9 MBytes 469 Mbits/sec 0 65.6 KBytes
> [ 5] 3.00-4.00 sec 53.0 MBytes 445 Mbits/sec 0 65.6 KBytes
> [ 5] 4.00-5.00 sec 54.3 MBytes 455 Mbits/sec 0 65.6 KBytes
> [ 5] 5.00-6.00 sec 54.8 MBytes 460 Mbits/sec 0 65.6 KBytes
> [ 5] 6.00-7.00 sec 45.3 MBytes 380 Mbits/sec 0 65.6 KBytes
> [ 5] 7.00-8.00 sec 51.2 MBytes 429 Mbits/sec 0 65.6 KBytes
> [ 5] 8.00-9.00 sec 56.1 MBytes 470 Mbits/sec 0 65.6 KBytes
> [ 5] 9.00-10.00 sec 55.3 MBytes 464 Mbits/sec 0 65.6 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 546 MBytes 458 Mbits/sec 0 sender
> [ 5] 0.00-10.00 sec 545 MBytes 457 Mbits/sec
> receiver**
>
> **
> **
>
> **regards,**
>
> **Simon
> **
>
> **
> **
which stmac device are you talking about? its not your windows pc. if
its a ipq8064 based device or something like that you should look
on a very different location. this platform like the r7800 has stmac
performance problems since the kernel clk code for this device is lets
say "very wrong".
so alot of clocks arent correct and so the ethernet performance will
suffer.
i can tell you that i'm able to get 930 mbit on a stmmac based device.
but as i said. the kernel needs other numerous fixes to get a good
performance
root@TEW827:~# iperf3 -c 10.88.193.134 -i 1
Connecting to host 10.88.193.134, port 5201
[ 5] local 10.88.193.90 port 36024 connected to 10.88.193.134 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 108 MBytes 903 Mbits/sec 0 5.17 MBytes
[ 5] 1.00-2.00 sec 112 MBytes 943 Mbits/sec 0 5.17 MBytes
[ 5] 2.00-3.00 sec 109 MBytes 913 Mbits/sec 0 6.02 MBytes
[ 5] 3.00-4.00 sec 112 MBytes 944 Mbits/sec 0 6.02 MBytes
[ 5] 4.00-5.00 sec 109 MBytes 910 Mbits/sec 1 6.02 MBytes
[ 5] 5.00-6.00 sec 111 MBytes 935 Mbits/sec 0 6.02 MBytes
[ 5] 6.00-7.00 sec 109 MBytes 912 Mbits/sec 1 6.02 MBytes
^C[ 5] 7.00-7.51 sec 56.2 MBytes 935 Mbits/sec 0 6.02 MBytes
>
>
^ permalink raw reply
* [PATCH net-next 0/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 20:06 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
This series adds HWMON support for the temperature sensor and the
related alarms on the 107/108/109 chips.
Heiner Kallweit (2):
net: phy: aquantia: rename aquantia.c to aquantia_main.c
net: phy: aquantia: add hwmon support
drivers/net/phy/Makefile | 1 +
drivers/net/phy/aquantia_hwmon.c | 263 ++++++++++++++++++
drivers/net/phy/aquantia_hwmon.h | 15 +
.../net/phy/{aquantia.c => aquantia_main.c} | 4 +
4 files changed, 283 insertions(+)
create mode 100644 drivers/net/phy/aquantia_hwmon.c
create mode 100644 drivers/net/phy/aquantia_hwmon.h
rename drivers/net/phy/{aquantia.c => aquantia_main.c} (98%)
--
2.20.1
^ permalink raw reply
* [PATCH net-next 1/2] net: phy: aquantia: rename aquantia.c to aquantia_main.c
From: Heiner Kallweit @ 2019-02-24 20:07 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <0a05279a-ab9e-a978-df4d-f09869c3bba2@gmail.com>
Rename aquantia.c to aquantia_main.c to be prepared for adding new
functionality to separate source code files.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/Makefile | 1 +
drivers/net/phy/{aquantia.c => aquantia_main.c} | 0
2 files changed, 1 insertion(+)
rename drivers/net/phy/{aquantia.c => aquantia_main.c} (100%)
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b7d..b0845adaf 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -45,6 +45,7 @@ sfp-obj-$(CONFIG_SFP) += sfp-bus.o
obj-y += $(sfp-obj-y) $(sfp-obj-m)
obj-$(CONFIG_AMD_PHY) += amd.o
+aquantia-objs += aquantia_main.o
obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
obj-$(CONFIG_ASIX_PHY) += asix.o
obj-$(CONFIG_AT803X_PHY) += at803x.o
diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia_main.c
similarity index 100%
rename from drivers/net/phy/aquantia.c
rename to drivers/net/phy/aquantia_main.c
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 20:09 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <0a05279a-ab9e-a978-df4d-f09869c3bba2@gmail.com>
This adds HWMON support for the temperature sensor and the related
alarms on the 107/108/109 chips. This patch is based on work from
Nikita and Andrew. I added:
- support for changing alarm thresholds via sysfs
- move HWMON code to a separate source file to improve maintainability
- smaller changes like using IS_REACHABLE instead of ifdef
(avoids problems if PHY driver is built in and HWMON is a module)
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/aquantia_hwmon.c | 263 +++++++++++++++++++++++++++++++
drivers/net/phy/aquantia_hwmon.h | 15 ++
drivers/net/phy/aquantia_main.c | 4 +
4 files changed, 283 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/phy/aquantia_hwmon.c
create mode 100644 drivers/net/phy/aquantia_hwmon.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index b0845adaf..c48596626 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -45,7 +45,7 @@ sfp-obj-$(CONFIG_SFP) += sfp-bus.o
obj-y += $(sfp-obj-y) $(sfp-obj-m)
obj-$(CONFIG_AMD_PHY) += amd.o
-aquantia-objs += aquantia_main.o
+aquantia-objs += aquantia_main.o aquantia_hwmon.o
obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
obj-$(CONFIG_ASIX_PHY) += asix.o
obj-$(CONFIG_AT803X_PHY) += at803x.o
diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
new file mode 100644
index 000000000..c0dd695f6
--- /dev/null
+++ b/drivers/net/phy/aquantia_hwmon.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0
+/* HWMON driver for Aquantia PHY
+ *
+ * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
+ * Author: Andrew Lunn <andrew@lunn.ch>
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ */
+
+#include <linux/phy.h>
+#include <linux/device.h>
+#include <linux/ctype.h>
+#include <linux/hwmon.h>
+
+#include "aquantia_hwmon.h"
+
+/* Vendor specific 1, MDIO_MMD_VEND1 */
+#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
+#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
+#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
+#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
+#define VEND1_THERMAL_STAT1 0xc820
+#define VEND1_THERMAL_STAT2 0xc821
+#define VEND1_THERMAL_STAT2_VALID BIT(0)
+#define VEND1_GENERAL_STAT1 0xc830
+#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
+#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
+#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
+#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
+
+struct aqr_priv {
+ struct device *hwmon_dev;
+ char *hwmon_name;
+};
+
+#if IS_REACHABLE(CONFIG_HWMON)
+
+static umode_t aqr_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ if (type != hwmon_temp)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ case hwmon_temp_min_alarm:
+ case hwmon_temp_max_alarm:
+ case hwmon_temp_lcrit_alarm:
+ case hwmon_temp_crit_alarm:
+ return 0444;
+ case hwmon_temp_min:
+ case hwmon_temp_max:
+ case hwmon_temp_lcrit:
+ case hwmon_temp_crit:
+ return 0644;
+ default:
+ return 0;
+ }
+}
+
+static int aqr_hwmon_get(struct phy_device *phydev, int reg, long *value)
+{
+ int temp = phy_read_mmd(phydev, MDIO_MMD_VEND1, reg);
+
+ if (temp < 0)
+ return temp;
+
+ /* register value is 2's complement with LSB = 1/256th degree Celsius */
+ if (temp > 0x8000)
+ temp -= 0x10000;
+
+ *value = temp * 1000 / 256;
+
+ return 0;
+}
+
+static int aqr_hwmon_set(struct phy_device *phydev, int reg, long value)
+{
+ int temp;
+
+ if (value >= 128000 || value < -128000)
+ return -ERANGE;
+
+ temp = value * 256 / 1000;
+
+ if (temp < 0)
+ temp += 0x10000;
+
+ return phy_write_mmd(phydev, MDIO_MMD_VEND1, reg, temp);
+}
+
+static int aqr_hwmon_status1(struct phy_device *phydev, int bit, long *value)
+{
+ int reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_GENERAL_STAT1);
+
+ if (reg < 0)
+ return reg;
+
+ *value = !!(reg & bit);
+
+ return 0;
+}
+
+static int aqr_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *value)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+ int reg;
+
+ if (type != hwmon_temp)
+ return -EOPNOTSUPP;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ reg = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+ VEND1_THERMAL_STAT2);
+ if (reg < 0)
+ return reg;
+ if (!(reg & VEND1_THERMAL_STAT2_VALID))
+ return -EIO;
+
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_STAT1, value);
+
+ case hwmon_temp_lcrit:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_FAIL,
+ value);
+ case hwmon_temp_lcrit_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL,
+ value);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int aqr_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long value)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+
+ if (type != hwmon_temp)
+ return -EOPNOTSUPP;
+
+ switch (attr) {
+ case hwmon_temp_lcrit:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_FAIL,
+ value);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops aqr_hwmon_ops = {
+ .is_visible = aqr_hwmon_is_visible,
+ .read = aqr_hwmon_read,
+ .write = aqr_hwmon_write,
+};
+
+static u32 aqr_hwmon_chip_config[] = {
+ HWMON_C_REGISTER_TZ,
+ 0,
+};
+
+static const struct hwmon_channel_info aqr_hwmon_chip = {
+ .type = hwmon_chip,
+ .config = aqr_hwmon_chip_config,
+};
+
+static u32 aqr_hwmon_temp_config[] = {
+ HWMON_T_INPUT |
+ HWMON_T_MAX | HWMON_T_MIN |
+ HWMON_T_MAX_ALARM | HWMON_T_MIN_ALARM |
+ HWMON_T_CRIT | HWMON_T_LCRIT |
+ HWMON_T_CRIT_ALARM | HWMON_T_LCRIT_ALARM,
+ 0,
+};
+
+static const struct hwmon_channel_info aqr_hwmon_temp = {
+ .type = hwmon_temp,
+ .config = aqr_hwmon_temp_config,
+};
+
+static const struct hwmon_channel_info *aqr_hwmon_info[] = {
+ &aqr_hwmon_chip,
+ &aqr_hwmon_temp,
+ NULL,
+};
+
+static const struct hwmon_chip_info aqr_hwmon_chip_info = {
+ .ops = &aqr_hwmon_ops,
+ .info = aqr_hwmon_info,
+};
+
+static int aqr_hwmon_really_probe(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ struct aqr_priv *priv = phydev->priv;
+ int i, j;
+
+ priv->hwmon_name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
+ if (!priv->hwmon_name)
+ return -ENOMEM;
+
+ for (i = j = 0; priv->hwmon_name[i]; i++) {
+ if (isalnum(priv->hwmon_name[i])) {
+ if (i != j)
+ priv->hwmon_name[j] = priv->hwmon_name[i];
+ j++;
+ }
+ }
+ priv->hwmon_name[j] = '\0';
+
+ priv->hwmon_dev = devm_hwmon_device_register_with_info(dev,
+ priv->hwmon_name, phydev,
+ &aqr_hwmon_chip_info, NULL);
+
+ return PTR_ERR_OR_ZERO(priv->hwmon_dev);
+}
+
+int aqr_hwmon_probe(struct phy_device *phydev)
+{
+ struct aqr_priv *priv;
+
+ priv = devm_kzalloc(&phydev->mdio.dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ phydev->priv = priv;
+
+ return aqr_hwmon_really_probe(phydev);
+}
+
+#endif
diff --git a/drivers/net/phy/aquantia_hwmon.h b/drivers/net/phy/aquantia_hwmon.h
new file mode 100644
index 000000000..607e68758
--- /dev/null
+++ b/drivers/net/phy/aquantia_hwmon.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0
+ * HWMON driver for Aquantia PHY
+ *
+ * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
+ * Author: Andrew Lunn <andrew@lunn.ch>
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ */
+
+#include <linux/phy.h>
+
+#if IS_REACHABLE(CONFIG_HWMON)
+int aqr_hwmon_probe(struct phy_device *phydev);
+#else
+static inline int aqr_hwmon_probe(struct phy_device *phydev) { return 0; }
+#endif
diff --git a/drivers/net/phy/aquantia_main.c b/drivers/net/phy/aquantia_main.c
index 0f0eb5682..af6dc3588 100644
--- a/drivers/net/phy/aquantia_main.c
+++ b/drivers/net/phy/aquantia_main.c
@@ -12,6 +12,8 @@
#include <linux/delay.h>
#include <linux/phy.h>
+#include "aquantia_hwmon.h"
+
#define PHY_ID_AQ1202 0x03a1b445
#define PHY_ID_AQ2104 0x03a1b460
#define PHY_ID_AQR105 0x03a1b4a2
@@ -231,6 +233,7 @@ static struct phy_driver aqr_driver[] = {
.name = "Aquantia AQR107",
.aneg_done = genphy_c45_aneg_done,
.get_features = genphy_c45_pma_read_abilities,
+ .probe = aqr_hwmon_probe,
.config_aneg = aqr_config_aneg,
.config_intr = aqr_config_intr,
.ack_interrupt = aqr_ack_interrupt,
@@ -241,6 +244,7 @@ static struct phy_driver aqr_driver[] = {
.name = "Aquantia AQCS109",
.aneg_done = genphy_c45_aneg_done,
.get_features = genphy_c45_pma_read_abilities,
+ .probe = aqr_hwmon_probe,
.config_init = aqcs109_config_init,
.config_aneg = aqr_config_aneg,
.config_intr = aqr_config_intr,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Documentation: networking: switchdev: Update port parent ID section
From: David Miller @ 2019-02-24 20:13 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, idosch, jiri
In-Reply-To: <20190224.112630.1072776894762356933.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 24 Feb 2019 11:26:30 -0800 (PST)
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sun, 24 Feb 2019 08:46:59 -0800
>
>> Looks like you applied this to the "net" tree, and I missed prefixing
>> the patch to indicate this was targeted at the "net-next" tree. Are you
>> planning a merge from "net" to "net-next" anytime soon?
>
> Yes, I am working on that right now.
This is now done.
^ permalink raw reply
* marvell10g.c merge into net-next
From: David Miller @ 2019-02-24 20:15 UTC (permalink / raw)
To: hkallweit1; +Cc: netdev
Heiner, please look at net-next which I just merged net into.
Net had a bug fix wherein the MDIO_AN_10GBT_CTRL_ADV_NBT_MASK
bits are cleared in the 10gbt control register to work around
a problem with some marvell10g phy chips.
In the merge I preserved your usage of the generic c45 helpers
in this area, but I suspect part of that will have to be undone
in order to accomodate the above fix.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Andrew Lunn @ 2019-02-24 20:29 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <590d1e26-999e-3b09-fcd9-6d570cadb3bf@gmail.com>
> diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
> new file mode 100644
> index 000000000..c0dd695f6
> --- /dev/null
> +++ b/drivers/net/phy/aquantia_hwmon.c
> @@ -0,0 +1,263 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* HWMON driver for Aquantia PHY
> + *
> + * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> + * Author: Andrew Lunn <andrew@lunn.ch>
> + * Author: Heiner Kallweit <hkallweit1@gmail.com>
> + */
> +
> +#include <linux/phy.h>
> +#include <linux/device.h>
> +#include <linux/ctype.h>
> +#include <linux/hwmon.h>
> +
> +#include "aquantia_hwmon.h"
> +
> +/* Vendor specific 1, MDIO_MMD_VEND1 */
> +#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
> +#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
> +#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
> +#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
> +#define VEND1_THERMAL_STAT1 0xc820
> +#define VEND1_THERMAL_STAT2 0xc821
> +#define VEND1_THERMAL_STAT2_VALID BIT(0)
> +#define VEND1_GENERAL_STAT1 0xc830
> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
> +#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
> +#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
> +
> +struct aqr_priv {
> + struct device *hwmon_dev;
> + char *hwmon_name;
> +};
Hi Heiner
It seems a bit odd having the driver private structure here. I expect
with time we are going to need other things in it which are not
HWMON. e.g many of the statistics counters are clear on read. So we
need to keep the running totals somewhere.
I would keep the probe code and the allocation of this structure in
the main driver file.
Andrew
^ permalink raw reply
* Re: [PATCH 5/5] net: dsa: fix a leaked reference by adding missing of_node_put
From: David Miller @ 2019-02-24 20:32 UTC (permalink / raw)
To: wen.yang99
Cc: linus.walleij, andrew, vivien.didelot, f.fainelli, netdev,
linux-kernel, alexandre.belloni, UNGLinuxDriver, nbd,
lorenzo.bianconi83, kvalo, matthias.bgg, linux-wireless,
linux-arm-kernel, linux-mediatek, anirudh, John.Linn,
michal.simek, wang.yi59
In-Reply-To: <1550819742-32155-5-git-send-email-wen.yang99@zte.com.cn>
From: Wen Yang <wen.yang99@zte.com.cn>
Date: Fri, 22 Feb 2019 15:15:42 +0800
> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> index 8c431e0..89823f0 100644
> --- a/net/dsa/dsa2.c
> +++ b/net/dsa/dsa2.c
> @@ -613,7 +613,7 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
> struct device_node *ports, *port;
> struct dsa_port *dp;
> u32 reg;
> - int err;
> + int err = 0;
Please preserve the reverse christmas tree ordering of variables here.
Thank you.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Michal Kubecek @ 2019-02-24 20:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Tariq Toukan, John W. Linville, netdev, Eran Ben Elisha,
Aya Levin
In-Reply-To: <20190224194015.GM26626@lunn.ch>
On Sun, Feb 24, 2019 at 08:40:15PM +0100, Andrew Lunn wrote:
> > > This is getting less friendly all the time, and it was never very
> > > friendly to start with. We have the strings which represent these link
> > > modes in the table used for dumping caps. How about allowing the user
> > > to list a comma separate list of modes.
> > >
> > > ethtool -s lan42 advertise 100000baseKR2/Full,100000baseSR2/Full,100000baseCR2/Full
> >
> > In my preliminary netlink patchset, I'm adding support for e.g.
> >
> > ethtool -s eth0 advertise 100baseT/Half off 1000baseT/Full on
> >
> > I'm not sure what would be more useful, if switching individual modes or
> > listing the whole set. After all, we can also support both. But I fully
> > agree that the numeric bitmaps are already too inconvenient.
>
> Hi Michal
>
> So are you doing a read/modify/write? In that case, off/on makes
> sense. For a pure write, i don't see the need for off/on.
When using netlink interface, the read/modify/write cycle is limited to
kernel code and is done under rtnl_lock. The netlink interface allows
userspace to send only attributes it wants to change and for bit sets
(like link modes) to tell kernel which bits it wants to change so that
there is no need to read current values first (and open a race window).
When using ioctl interface, ethtool does read the value first even now
as ETHTOOL_SLINKSETTINGS command uses struct ethtool_link_usettings
which has also other members and there is no way to say we only want to
change advertised link modes.
Michal
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-24 20:34 UTC (permalink / raw)
To: Sebastian Gottschall, Jerome Brunet, Jose Abreu,
Martin Blumenstingl
Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue,
Emiliano Ingrassia, netdev
In-Reply-To: <f08f2659-dde0-41ec-9233-6b4d5f375ffe@newmedia-net.de>
Am 24.02.2019 um 20:42 schrieb Sebastian Gottschall:
> vice are you talking about? its not your windows pc. if its a ipq8064
> based device or something like that you should look
> on a very different location. this platform like the r7800 has stmac
> performance problems since the kernel clk code for this device is lets
> say "very wrong".
> so alot of clocks arent correct and so the ethernet performance will
> suffer.
>
> i can tell you that i'm able to get 930 mbit on a stmmac based device.
> but as i said. the kernel needs other numerous fixes to get a good
> performance
Hi,
the topic is about ODROID C2 / Amlogic S905X since the start. we have a
performance regression since 4.14.
regards,
Simon
^ permalink raw reply
* Re: [PATCH net-next] net: phy: let genphy_c45_read_abilities also check aneg capability
From: David Miller @ 2019-02-24 20:35 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev, maxime.chevallier
In-Reply-To: <a798f789-94a9-f1ac-1cba-276a2c517089@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 22 Feb 2019 08:23:04 +0100
> When using genphy_c45_read_abilities() as get_features callback we
> also have to set the autoneg capability in phydev->supported.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: marvell10g.c merge into net-next
From: Heiner Kallweit @ 2019-02-24 20:35 UTC (permalink / raw)
To: David Miller, Maxime Chevallier; +Cc: netdev
In-Reply-To: <20190224.121517.833334110230552517.davem@davemloft.net>
On 24.02.2019 21:15, David Miller wrote:
>
> Heiner, please look at net-next which I just merged net into.
>
> Net had a bug fix wherein the MDIO_AN_10GBT_CTRL_ADV_NBT_MASK
> bits are cleared in the 10gbt control register to work around
> a problem with some marvell10g phy chips.
>
> In the merge I preserved your usage of the generic c45 helpers
> in this area, but I suspect part of that will have to be undone
> in order to accomodate the above fix.
>
Thanks for the info. Let me add Maxime as author of the fix.
I think we talk about his one "net: phy: marvell10g:
Fix Multi-G advertisement to only advertise 10G" and we talk
about net-next.
IMO the proper way to fix this is removing the unsupported
modes from phydev->advertising in config_init.
Then mv3310_config_aneg doesn't have to be touched.
A similar exercise I did here:
0974f1f03b07 ("net: phy: aquantia: remove false 5G and 10G speed ability for AQCS109")
> Thanks.
>
Heiner
^ permalink raw reply
* Re: [PATCH][net-next] net: Use RCU_INIT_POINTER() to set sk_wq
From: David Miller @ 2019-02-24 20:37 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1550826502-15554-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Fri, 22 Feb 2019 17:08:22 +0800
> This pointer is RCU protected, so proper primitives should be used.
>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: phylink: update mac_config() documentation
From: David Miller @ 2019-02-24 20:39 UTC (permalink / raw)
To: rmk+kernel; +Cc: linux-doc, netdev
In-Reply-To: <E1gx93N-00046w-6j@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Fri, 22 Feb 2019 11:31:41 +0000
> A detail for mac_config() had been missed in the documentation for the
> method - it is expected that the method will update the MAC to the
> settings, rather than completely reprogram the MAC on each call.
> Update the documentation for this method for this detail.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] doc: add phylink documentation to the networking book
From: David Miller @ 2019-02-24 20:40 UTC (permalink / raw)
To: rmk+kernel; +Cc: linux-doc, netdev, corbet
In-Reply-To: <E1gx93S-00047E-CW@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Fri, 22 Feb 2019 11:31:46 +0000
> Add some phylink documentation to the networking book detailing how
> to convert network drivers from phylib to phylink.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> v2: updated with comments from Randy and updated to apply to net-next
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: Skip GSO length estimation if transport header is not set
From: David Miller @ 2019-02-24 20:41 UTC (permalink / raw)
To: maximmi; +Cc: willemb, saeedm, jasowang, edumazet, netdev, eranbe, tariqt
In-Reply-To: <20190222125457.8509-1-maximmi@mellanox.com>
From: Maxim Mikityanskiy <maximmi@mellanox.com>
Date: Fri, 22 Feb 2019 12:55:22 +0000
> qdisc_pkt_len_init expects transport_header to be set for GSO packets.
> Patch [1] skips transport_header validation for GSO packets that don't
> have network_header set at the moment of calling virtio_net_hdr_to_skb,
> and allows them to pass into the stack. After patch [2] no placeholder
> value is assigned to transport_header if dissection fails, so this patch
> adds a check to the place where the value of transport_header is used.
>
> [1] https://patchwork.ozlabs.org/patch/1044429/
> [2] https://patchwork.ozlabs.org/patch/1046122/
>
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Applied, thanks Maxim.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Andrew Lunn @ 2019-02-24 20:43 UTC (permalink / raw)
To: Michal Kubecek
Cc: Tariq Toukan, John W. Linville, netdev, Eran Ben Elisha,
Aya Levin
In-Reply-To: <20190224203333.GC1914@unicorn.suse.cz>
> > Hi Michal
> >
> > So are you doing a read/modify/write? In that case, off/on makes
> > sense. For a pure write, i don't see the need for off/on.
>
> When using netlink interface, the read/modify/write cycle is limited to
> kernel code and is done under rtnl_lock. The netlink interface allows
> userspace to send only attributes it wants to change and for bit sets
> (like link modes) to tell kernel which bits it wants to change so that
> there is no need to read current values first (and open a race window).
Nice.
But it would still be good to get feedback from people who use this
more often. I guess that is top of rack switches with all these odd
link modes.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/8] Add tests for unlocked flower classifier implementation
From: David Miller @ 2019-02-24 20:50 UTC (permalink / raw)
To: vladbu
Cc: netdev, jhs, xiyou.wangcong, shuah, batuhanosmantaskaya, lucasb,
dcaratti, marcelo.leitner, chrism
In-Reply-To: <20190222140047.13215-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Fri, 22 Feb 2019 16:00:39 +0200
> Implement tests for tdc testsuite to verify concurrent rules update with
> rtnl-unlocked flower classifier implementation. The goal of these tests
> is to verify general flower classifier correctness by updating filters
> on same classifier instance in parallel and to verify its atomicity by
> concurrently updating filters in same handle range. All three filter
> update operations (add, replace, delete) are tested.
>
> Existing script tdc_batch.py is re-used for batch file generation. It is
> extended with several optional CLI arguments that are needed for
> concurrency tests. Thin wrapper tdc_multibatch.py is implemented on top
> of tdc_batch.py to simplify its usage when generating multiple batch
> files for several test configurations.
>
> Parallelism in tests is implemented by running multiple instances of tc
> in batch mode with xargs tool. Xargs is chosen for its ease of use and
> because it is available by default on most modern Linux distributions.
Series applied, thanks Vlad.
^ permalink raw reply
* 32-bit Amlogic SoCs: avoid using Ethernet MAC addresses
From: Martin Blumenstingl @ 2019-02-24 20:55 UTC (permalink / raw)
To: linux.amoon, linux-amlogic; +Cc: netdev
I have seen Anand's your question in [0]:
> only issue is I have is the each time their is random MAC address so I
> get new IP from dhcp server.
> How can I avoid this. I have tried to enable eFuse driver but with no success.
u-boot on the 64-bit SoCs can read the MAC address from the eFuse and
pass it (via the .dtb) to the kernel.
This requires an ethernet0 alias in the mainline .dts though, see [1]
for and example.
I'm not sure if this also works with the older u-boot on the 32-bit SoCs.
if it doesn't then there's a nvmem-cells binding for all Ethernet
controllers: [2] (please note that the function implementing this
binding was recently renamed: [3])
as far as I can tell the stmmac driver doesn't support the nvmem-cells
based binding yet
Anand, if you want to work on this: feel free to do so!
I have the SDHC MMC driver and a discussion about the power-domain
drivers on my TODO-list, so I'm pretty busy at the moment.
Regards
Martin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2019-February/010464.html
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c36209c46c4d162202b65eed2e66962ad8c3c1
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9217e566bdee4583d0a9ea4879c8f5e004886eac
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=afa64a72b862a7a9d04f8d07fba632eaf06b23f8
^ permalink raw reply
* Re: marvell10g.c merge into net-next
From: Maxime Chevallier @ 2019-02-24 20:56 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: David Miller, netdev
In-Reply-To: <d6f79c5a-57c6-87e2-5408-b778f58838b3@gmail.com>
Hello Dave, Heiner,
On Sun, 24 Feb 2019 21:35:11 +0100
Heiner Kallweit <hkallweit1@gmail.com> wrote:
>On 24.02.2019 21:15, David Miller wrote:
>>
>> Heiner, please look at net-next which I just merged net into.
>>
>> Net had a bug fix wherein the MDIO_AN_10GBT_CTRL_ADV_NBT_MASK
>> bits are cleared in the 10gbt control register to work around
>> a problem with some marvell10g phy chips.
>>
>> In the merge I preserved your usage of the generic c45 helpers
>> in this area, but I suspect part of that will have to be undone
>> in order to accomodate the above fix.
>>
>Thanks for the info. Let me add Maxime as author of the fix.
>I think we talk about his one "net: phy: marvell10g:
>Fix Multi-G advertisement to only advertise 10G" and we talk
>about net-next.
>
>IMO the proper way to fix this is removing the unsupported
>modes from phydev->advertising in config_init.
>Then mv3310_config_aneg doesn't have to be touched.
>
>A similar exercise I did here:
>0974f1f03b07 ("net: phy: aquantia: remove false 5G and 10G speed ability for AQCS109")
From what I've seen and tested, the issue itself doesn't appear in
net-next, since mv3310_config_aneg calls the newly introduced
genphy_c45_an_config_aneg() which clears the 2.5G/5G advertising bits.
So the use of the generic C45 helpers should be enough to prevent the
issue from happening. The only difference really is that the -net patch
also masks the 2.5/5G Fast Retrain abilities, but this should make no
difference given that 2.5/5G are masked-out in both cases.
I'm sorry for the confusion, I wasn't sure how to deal with such a
scenario.
Thanks,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: protodown support for macvlan and vxlan
From: David Miller @ 2019-02-24 21:01 UTC (permalink / raw)
To: aroulin; +Cc: netdev, roopa
In-Reply-To: <20190222180638.10904-1-aroulin@cumulusnetworks.com>
From: Andy Roulin <aroulin@cumulusnetworks.com>
Date: Fri, 22 Feb 2019 18:06:35 +0000
> This patch series adds dev_change_proto_down_generic, a generic
> implementation of ndo_change_proto_down, which sets the netdev carrier
> state according to the new proto_down value.
>
> This handler adds the ability to set protodown on macvlan and vxlan
> interfaces in a generic way for use by control protocols like VRRPD.
>
> Patch (1) introduces the handler in net/code/dev.c. Patch (2) and (3) add
> support for change_proto_down in macvlan and vxlan drivers, respectively,
> using the new function.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 21:14 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190224202952.GA20855@lunn.ch>
On 24.02.2019 21:29, Andrew Lunn wrote:
>> diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
>> new file mode 100644
>> index 000000000..c0dd695f6
>> --- /dev/null
>> +++ b/drivers/net/phy/aquantia_hwmon.c
>> @@ -0,0 +1,263 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* HWMON driver for Aquantia PHY
>> + *
>> + * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
>> + * Author: Andrew Lunn <andrew@lunn.ch>
>> + * Author: Heiner Kallweit <hkallweit1@gmail.com>
>> + */
>> +
>> +#include <linux/phy.h>
>> +#include <linux/device.h>
>> +#include <linux/ctype.h>
>> +#include <linux/hwmon.h>
>> +
>> +#include "aquantia_hwmon.h"
>> +
>> +/* Vendor specific 1, MDIO_MMD_VEND1 */
>> +#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
>> +#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
>> +#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
>> +#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
>> +#define VEND1_THERMAL_STAT1 0xc820
>> +#define VEND1_THERMAL_STAT2 0xc821
>> +#define VEND1_THERMAL_STAT2_VALID BIT(0)
>> +#define VEND1_GENERAL_STAT1 0xc830
>> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
>> +#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
>> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
>> +#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
>> +
>> +struct aqr_priv {
>> + struct device *hwmon_dev;
>> + char *hwmon_name;
>> +};
>
> Hi Heiner
>
> It seems a bit odd having the driver private structure here. I expect
> with time we are going to need other things in it which are not
> HWMON. e.g many of the statistics counters are clear on read. So we
> need to keep the running totals somewhere.
>
> I would keep the probe code and the allocation of this structure in
> the main driver file.
>
I just see that we don't need struct aqr_priv at all for hwmon
because it uses device-managed versions of the relevant functions.
So we can add such a struct when it's actually needed.
> Andrew
>
Heiner
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Florian Fainelli @ 2019-02-24 21:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Russell King - ARM Linux admin, Heiner Kallweit,
netdev@vger.kernel.org
In-Reply-To: <20190224170455.GH26626@lunn.ch>
On February 24, 2019 9:04:55 AM PST, Andrew Lunn <andrew@lunn.ch> wrote:
>> The added difficulty here and the reason why Andrew went with the
>> approach that is used by the code currently is because neither do the
>> CPU or DSA ports are backed by a net_device. It is somewhere on my
>TODO
>> to permit the use of PHYLINK without the need of a net_device to
>cover
>> those specific DSA cases unless we just brute force the whole thing
>and
>> allocate a net_device structure but not register that net_device? Yes
>in
>> fact, why don't we do that?
>
>Hi Florian
>
>At the moment, we are using a phydev which is not connected to a
>MAC. That is rather odd, but the phylib maintainers mostly know about
>this, and keep an eye out for changes which might break any
>assumptions. And the phylib API is quite small.
I would argue that this very thread is a proof against your argument since we all failed to predict that Heiner's changes would change those assumptions. Having a certain of assumptions is fine but given all the recent PHYLIB helpers that have been added I am not sure how well that will scale.
>
>How many assumptions are going to break with a netdev which is not
>registered? The API is much bigger, more people hack on it, and it is
>going to be much harder to review changes to make sure assumptions are
>not changed.
A non registered net_device appears easier to manage and debug since there is state tracking all over the network stack for those cases.
>
>If we are going to do something odd, we should keep the scope as small
>as possible.
Hence my suggestion to allocate a dummy net_device object just so calls to netif_carrier_{on,off} (and possibly more in the future) do nothing. I don't think that teaching either PHYLIB or PHYLINK about a NULL net_device is going to scale really well over time nor make it easier for respective maintainers. If we make the net_device optional, it will be harder to review changes as well as make sure that we do not create locking/object interactions issues.
Another approach could be to define a minimal network port object (struct devlink, maybe?) which could be used independently from a net_device, or a lightweight net_device with no visibility into existing namespaces. None of these ideas are new though and would probably require several cycles to get done right.
Heiner, Russell, which approach would you take?
--
Florian
^ 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