* [GIT] Networking
From: David Miller @ 2019-01-25 19:58 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Count ttl-dropped frames properly in mac80211, from Bob Copeland.
2) Integer overflow in ktime handling of bcm can code, from Oliver
Hartkopp.
3) Fix RX desc handling wrt. hw checksumming in ravb, from Simon
Horman.
4) Various hash key fixes in hv_netvsc, from Haiyang Zhang.
5) Use after free in ax25, from Eric Dumazet.
6) Several fixes to the SSN support in SCTP, from Xin Long.
7) Do not process frames after a NAPI reschedule in ibmveth, from
Thomas Falcon.
8) Fix NLA_POLICY_NESTED arguments, from Johannes Berg.
Please pull, thanks a lot!
The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd:
Linux 5.0-rc3 (2019-01-21 13:14:44 +1300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to 517952756ed3027a9b776e331985320a829b9f62:
Merge tag 'mac80211-for-davem-2019-01-25' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2019-01-25 10:59:36 -0800)
----------------------------------------------------------------
Adrian Vladu (1):
hv_netvsc: fix typos in code comments
Andrew Lunn (1):
net: phy: Fixup GPLv2+ SPDX tags based on license text
Atsushi Nemoto (1):
net: altera_tse: fix connect_local_phy error path
Aya Levin (1):
net/mlx4_core: Add masking for a few queries on HCA caps
Balaji Pothunoori (1):
mac80211: don't initiate TDLS connection if station is not associated to AP
Bob Copeland (1):
mac80211: fix miscounting of ttl-dropped frames
Chaitanya Tata (2):
cfg80211: reg: remove warn_on for a normal case
cfg80211: extend range deviation for DMG
David S. Miller (5):
Merge branch 'qed-Error-recovery-process'
Merge branch 'mlx4_core-fixes'
Merge tag 'linux-can-fixes-for-5.0-20190122' of git://git.kernel.org/.../mkl/linux-can
Merge tag 'hyperv-fixes-signed' of git://git.kernel.org/.../hyperv/linux
Merge tag 'mac80211-for-davem-2019-01-25' of git://git.kernel.org/.../jberg/mac80211
Edward Cree (1):
sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe
Eric Dumazet (1):
ax25: fix possible use-after-free
Haiyang Zhang (3):
hv_netvsc: Fix ethtool change hash key error
hv_netvsc: Refactor assignments of struct netvsc_device_info
hv_netvsc: Fix hash key value reset after other ops
Jack Morgenstein (1):
net/mlx4_core: Fix error handling when initializing CQ bufs in the driver
Jakub Kicinski (1):
net/ipv6: don't return positive numbers when nothing was dumped
Johannes Berg (2):
mac80211_hwsim: check that n_limits makes sense
nl80211: fix NLA_POLICY_NESTED() arguments
Lorenzo Bianconi (1):
net: ip_gre: use erspan key field for tunnel lookup
Lubomir Rintel (1):
net/ipv6: lower the level of "link is not ready" messages
Maciej Żenczykowski (1):
net: dev_is_mac_header_xmit() true for ARPHRD_RAWIP
Manfred Schlaegl (1):
can: dev: __can_get_echo_skb(): fix bogous check for non-existing skb by removing it
Mathieu Malaterre (1):
mac80211: Add attribute aligned(2) to struct 'action'
Oliver Hartkopp (1):
can: bcm: check timer values before ktime conversion
Simon Horman (1):
ravb: expand rx descriptor data to accommodate hw checksum
Stefan Agner (1):
net: fec: get regulator optional
Sudarsana Reddy Kalluru (1):
MAINTAINERS: Update cavium networking drivers
Thomas Falcon (1):
ibmveth: Do not process frames after calling napi_reschedule
Thomas Gleixner (1):
net: sun: cassini: Cleanup license conflict
Tomer Tayar (3):
qed: Revise load sequence to avoid PCI errors
qed: Add infrastructure for error detection and recovery
qede: Error recovery process
Uwe Kleine-König (1):
can: flexcan: fix NULL pointer exception during bringup
Wei Yongjun (1):
virt_wifi: fix error return code in virt_wifi_newlink()
Xin Long (4):
sctp: improve the events for sctp stream reset
sctp: improve the events for sctp stream adding
sctp: set chunk transport correctly when it's a new asoc
sctp: set flow sport from saddr only when it's 0
Yangbo Lu (1):
net: dpaa2: improve PTP Kconfig option
YueHaibing (1):
can: flexcan: fix 'passing zero to ERR_PTR()' warning
Zhang Run (1):
net: usb: asix: ax88772_bind return error when hw_reset fail
wenxu (1):
ip_tunnel: Make none-tunnel-dst tunnel port work with lwtunnel
MAINTAINERS | 42 ++++++-------
drivers/net/can/dev.c | 27 ++++-----
drivers/net/can/flexcan.c | 4 +-
drivers/net/ethernet/altera/altera_tse_main.c | 4 +-
drivers/net/ethernet/freescale/dpaa2/Kconfig | 5 +-
drivers/net/ethernet/freescale/fec_main.c | 2 +-
drivers/net/ethernet/ibm/ibmveth.c | 2 -
drivers/net/ethernet/mellanox/mlx4/cq.c | 6 +-
drivers/net/ethernet/mellanox/mlx4/fw.c | 75 ++++++++++++++---------
drivers/net/ethernet/qlogic/qed/qed.h | 5 +-
drivers/net/ethernet/qlogic/qed/qed_dev.c | 158 ++++++++++++++++++++++++++++-------------------
drivers/net/ethernet/qlogic/qed/qed_dev_api.h | 12 ++++
drivers/net/ethernet/qlogic/qed/qed_hsi.h | 2 +-
drivers/net/ethernet/qlogic/qed/qed_hw.c | 11 ++++
drivers/net/ethernet/qlogic/qed/qed_int.c | 126 +++++++++++++++++++-------------------
drivers/net/ethernet/qlogic/qed/qed_int.h | 3 +
drivers/net/ethernet/qlogic/qed/qed_main.c | 30 +++++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 115 +++++++++++++++++++++++++++++++++++
drivers/net/ethernet/qlogic/qed/qed_mcp.h | 42 +++++++++++++
drivers/net/ethernet/qlogic/qed/qed_reg_addr.h | 2 +
drivers/net/ethernet/qlogic/qed/qed_spq.c | 22 +++++++
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 9 ++-
drivers/net/ethernet/qlogic/qede/qede.h | 3 +
drivers/net/ethernet/qlogic/qede/qede_main.c | 300 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------
drivers/net/ethernet/qlogic/qede/qede_rdma.c | 64 +++++++++++++------
drivers/net/ethernet/renesas/ravb_main.c | 12 ++--
drivers/net/ethernet/sfc/ef10.c | 29 ++++++---
drivers/net/ethernet/sun/cassini.c | 15 +----
drivers/net/ethernet/sun/cassini.h | 15 +----
drivers/net/hyperv/hyperv_net.h | 12 ++--
drivers/net/hyperv/netvsc.c | 4 +-
drivers/net/hyperv/netvsc_drv.c | 145 ++++++++++++++++++++++++++++----------------
drivers/net/hyperv/rndis_filter.c | 36 ++++++++---
drivers/net/phy/asix.c | 8 +--
drivers/net/phy/mdio-hisi-femac.c | 16 +----
drivers/net/phy/rockchip.c | 9 +--
drivers/net/usb/asix_devices.c | 9 ++-
drivers/net/wireless/mac80211_hwsim.c | 5 ++
drivers/net/wireless/virt_wifi.c | 4 +-
include/linux/if_arp.h | 1 +
include/linux/qed/qed_if.h | 20 ++++++
include/linux/qed/qede_rdma.h | 21 +++++--
include/net/ax25.h | 12 ++++
net/ax25/ax25_ip.c | 4 +-
net/ax25/ax25_route.c | 19 +++---
net/can/bcm.c | 27 +++++++++
net/ipv4/gre_demux.c | 17 ++++++
net/ipv4/ip_gre.c | 9 ---
net/ipv4/ip_tunnel.c | 8 ++-
net/ipv6/addrconf.c | 6 +-
net/ipv6/ip6_gre.c | 4 --
net/mac80211/cfg.c | 4 ++
net/mac80211/rx.c | 6 +-
net/sctp/ipv6.c | 3 +-
net/sctp/protocol.c | 3 +-
net/sctp/sm_make_chunk.c | 11 +++-
net/sctp/stream.c | 58 ++++++++----------
net/wireless/nl80211.c | 2 +-
net/wireless/reg.c | 13 ++--
59 files changed, 1148 insertions(+), 490 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 0/3] RV64G eBPF JIT
From: Paul Walmsley @ 2019-01-25 19:54 UTC (permalink / raw)
To: Björn Töpel; +Cc: linux-riscv, palmer, davidlee, daniel, netdev
In-Reply-To: <20190115083518.10149-1-bjorn.topel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
Hi,
thanks for taking a shot at the eBPF JIT; this will be very useful.
On Tue, 15 Jan 2019, Björn Töpel wrote:
> * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to
> arch/riscv/Kconfig. Is this assumption correct?
From a hardware point of view, this is not the case on the Linux-capable
RISC-V ASICs that the public can buy right now (to the best of my
knowledge this is only the SiFive FU540).
So I'd recommend not including this for now.
- Paul
^ permalink raw reply
* [PATCH net-next 2/2] r8169: enable EEE per default on chip versions from RTL8168g
From: Heiner Kallweit @ 2019-01-25 19:39 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <8cce9784-c943-6d52-1e40-a04fbe9b6db6@gmail.com>
Enable EEE per default on chip versions from RTL8168g.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index f46bf1187..9e335d2c7 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -2172,6 +2172,14 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
.set_link_ksettings = phy_ethtool_set_link_ksettings,
};
+static void rtl_enable_eee(struct rtl8169_private *tp)
+{
+ int supported = rtl_get_eee_supp(tp);
+
+ if (supported > 0)
+ rtl_set_eee_adv(tp, supported);
+}
+
static void rtl8169_get_mac_version(struct rtl8169_private *tp)
{
/*
@@ -3623,12 +3631,14 @@ static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp)
rtl8168g_disable_aldps(tp);
rtl8168g_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl8168g_2_hw_phy_config(struct rtl8169_private *tp)
{
rtl_apply_firmware(tp);
rtl8168g_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl8168h_1_hw_phy_config(struct rtl8169_private *tp)
@@ -3735,6 +3745,7 @@ static void rtl8168h_1_hw_phy_config(struct rtl8169_private *tp)
rtl8168g_disable_aldps(tp);
rtl8168g_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl8168h_2_hw_phy_config(struct rtl8169_private *tp)
@@ -3804,6 +3815,7 @@ static void rtl8168h_2_hw_phy_config(struct rtl8169_private *tp)
rtl8168g_disable_aldps(tp);
rtl8168g_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl8168ep_1_hw_phy_config(struct rtl8169_private *tp)
@@ -3833,6 +3845,7 @@ static void rtl8168ep_1_hw_phy_config(struct rtl8169_private *tp)
rtl8168g_disable_aldps(tp);
rtl8168g_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl8168ep_2_hw_phy_config(struct rtl8169_private *tp)
@@ -3911,6 +3924,7 @@ static void rtl8168ep_2_hw_phy_config(struct rtl8169_private *tp)
rtl8168g_disable_aldps(tp);
rtl8168g_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl8102e_hw_phy_config(struct rtl8169_private *tp)
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 1/2] r8169: add general EEE support for chip versions from RTL8168g
From: Heiner Kallweit @ 2019-01-25 19:38 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <8cce9784-c943-6d52-1e40-a04fbe9b6db6@gmail.com>
This patch adds the general framework to deal with EEE in this driver
plus EEE support for chip versions from RTL8168g. We don't touch the
default chip settings, therefore EEE will usually be disabled and it's
up to the user to enable it.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 202 +++++++++++++++++++++++++--
1 file changed, 192 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 83c4663e6..f46bf1187 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1984,6 +1984,172 @@ static int rtl_set_coalesce(struct net_device *dev, struct ethtool_coalesce *ec)
return 0;
}
+static int rtl_get_eee_supp(struct rtl8169_private *tp)
+{
+ struct phy_device *phydev = tp->phydev;
+ int ret;
+
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
+ phy_write(phydev, 0x1f, 0x0a5c);
+ ret = phy_read(phydev, 0x12);
+ phy_write(phydev, 0x1f, 0x0000);
+ break;
+ default:
+ ret = -EPROTONOSUPPORT;
+ break;
+ }
+
+ return ret;
+}
+
+static int rtl_get_eee_lpadv(struct rtl8169_private *tp)
+{
+ struct phy_device *phydev = tp->phydev;
+ int ret;
+
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
+ phy_write(phydev, 0x1f, 0x0a5d);
+ ret = phy_read(phydev, 0x11);
+ phy_write(phydev, 0x1f, 0x0000);
+ break;
+ default:
+ ret = -EPROTONOSUPPORT;
+ break;
+ }
+
+ return ret;
+}
+
+static int rtl_get_eee_adv(struct rtl8169_private *tp)
+{
+ struct phy_device *phydev = tp->phydev;
+ int ret;
+
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
+ phy_write(phydev, 0x1f, 0x0a5d);
+ ret = phy_read(phydev, 0x10);
+ phy_write(phydev, 0x1f, 0x0000);
+ break;
+ default:
+ ret = -EPROTONOSUPPORT;
+ break;
+ }
+
+ return ret;
+}
+
+static int rtl_set_eee_adv(struct rtl8169_private *tp, int val)
+{
+ struct phy_device *phydev = tp->phydev;
+ int ret = 0;
+
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
+ phy_write(phydev, 0x1f, 0x0a5d);
+ phy_write(phydev, 0x10, val);
+ phy_write(phydev, 0x1f, 0x0000);
+ break;
+ default:
+ ret = -EPROTONOSUPPORT;
+ break;
+ }
+
+ return ret;
+}
+
+static int rtl8169_get_eee(struct net_device *dev, struct ethtool_eee *data)
+{
+ struct rtl8169_private *tp = netdev_priv(dev);
+ struct device *d = tp_to_dev(tp);
+ int ret;
+
+ pm_runtime_get_noresume(d);
+
+ if (!pm_runtime_active(d)) {
+ ret = -EOPNOTSUPP;
+ goto out;
+ }
+
+ /* Get Supported EEE */
+ ret = rtl_get_eee_supp(tp);
+ if (ret < 0)
+ goto out;
+ data->supported = mmd_eee_cap_to_ethtool_sup_t(ret);
+
+ /* Get advertisement EEE */
+ ret = rtl_get_eee_adv(tp);
+ if (ret < 0)
+ goto out;
+ data->advertised = mmd_eee_adv_to_ethtool_adv_t(ret);
+ data->eee_enabled = !!data->advertised;
+
+ /* Get LP advertisement EEE */
+ ret = rtl_get_eee_lpadv(tp);
+ if (ret < 0)
+ goto out;
+ data->lp_advertised = mmd_eee_adv_to_ethtool_adv_t(ret);
+ data->eee_active = !!(data->advertised & data->lp_advertised);
+out:
+ pm_runtime_put_noidle(d);
+ return ret < 0 ? ret : 0;
+}
+
+static int rtl8169_set_eee(struct net_device *dev, struct ethtool_eee *data)
+{
+ struct rtl8169_private *tp = netdev_priv(dev);
+ struct device *d = tp_to_dev(tp);
+ int old_adv, adv = 0, cap, ret;
+
+ pm_runtime_get_noresume(d);
+
+ if (!dev->phydev || !pm_runtime_active(d)) {
+ ret = -EOPNOTSUPP;
+ goto out;
+ }
+
+ if (dev->phydev->autoneg == AUTONEG_DISABLE ||
+ dev->phydev->duplex != DUPLEX_FULL) {
+ ret = -EPROTONOSUPPORT;
+ goto out;
+ }
+
+ /* Get Supported EEE */
+ ret = rtl_get_eee_supp(tp);
+ if (ret < 0)
+ goto out;
+ cap = ret;
+
+ ret = rtl_get_eee_adv(tp);
+ if (ret < 0)
+ goto out;
+ old_adv = ret;
+
+ if (data->eee_enabled) {
+ adv = !data->advertised ? cap :
+ ethtool_adv_to_mmd_eee_adv_t(data->advertised) & cap;
+ /* Mask prohibited EEE modes */
+ adv &= ~dev->phydev->eee_broken_modes;
+ }
+
+ if (old_adv != adv) {
+ ret = rtl_set_eee_adv(tp, adv);
+ if (ret < 0)
+ goto out;
+
+ /* Restart autonegotiation so the new modes get sent to the
+ * link partner.
+ */
+ ret = phy_restart_aneg(dev->phydev);
+ }
+
+out:
+ pm_runtime_put_noidle(d);
+ return ret < 0 ? ret : 0;
+}
+
static const struct ethtool_ops rtl8169_ethtool_ops = {
.get_drvinfo = rtl8169_get_drvinfo,
.get_regs_len = rtl8169_get_regs_len,
@@ -2000,6 +2166,8 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
.get_ethtool_stats = rtl8169_get_ethtool_stats,
.get_ts_info = ethtool_op_get_ts_info,
.nway_reset = phy_ethtool_nway_reset,
+ .get_eee = rtl8169_get_eee,
+ .set_eee = rtl8169_set_eee,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = phy_ethtool_set_link_ksettings,
};
@@ -2393,6 +2561,18 @@ static void rtl_apply_firmware_cond(struct rtl8169_private *tp, u8 reg, u16 val)
rtl_apply_firmware(tp);
}
+static void rtl8168_config_eee_mac(struct rtl8169_private *tp)
+{
+ rtl_w0w1_eri(tp, 0x1b0, ERIAR_MASK_1111, 0x0003, 0x0000, ERIAR_EXGMAC);
+}
+
+static void rtl8168g_config_eee_phy(struct rtl8169_private *tp)
+{
+ phy_write(tp->phydev, 0x1f, 0x0a43);
+ phy_set_bits(tp->phydev, 0x11, BIT(4));
+ phy_write(tp->phydev, 0x1f, 0x0000);
+}
+
static void rtl8169s_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -3442,13 +3622,13 @@ static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x14, 0x1065);
rtl8168g_disable_aldps(tp);
-
- rtl_writephy(tp, 0x1f, 0x0000);
+ rtl8168g_config_eee_phy(tp);
}
static void rtl8168g_2_hw_phy_config(struct rtl8169_private *tp)
{
rtl_apply_firmware(tp);
+ rtl8168g_config_eee_phy(tp);
}
static void rtl8168h_1_hw_phy_config(struct rtl8169_private *tp)
@@ -3554,8 +3734,7 @@ static void rtl8168h_1_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0000);
rtl8168g_disable_aldps(tp);
-
- rtl_writephy(tp, 0x1f, 0x0000);
+ rtl8168g_config_eee_phy(tp);
}
static void rtl8168h_2_hw_phy_config(struct rtl8169_private *tp)
@@ -3624,8 +3803,7 @@ static void rtl8168h_2_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0000);
rtl8168g_disable_aldps(tp);
-
- rtl_writephy(tp, 0x1f, 0x0000);
+ rtl8168g_config_eee_phy(tp);
}
static void rtl8168ep_1_hw_phy_config(struct rtl8169_private *tp)
@@ -3654,8 +3832,7 @@ static void rtl8168ep_1_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0000);
rtl8168g_disable_aldps(tp);
-
- rtl_writephy(tp, 0x1f, 0x0000);
+ rtl8168g_config_eee_phy(tp);
}
static void rtl8168ep_2_hw_phy_config(struct rtl8169_private *tp)
@@ -3733,8 +3910,7 @@ static void rtl8168ep_2_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0000);
rtl8168g_disable_aldps(tp);
-
- rtl_writephy(tp, 0x1f, 0x0000);
+ rtl8168g_config_eee_phy(tp);
}
static void rtl8102e_hw_phy_config(struct rtl8169_private *tp)
@@ -5017,6 +5193,8 @@ static void rtl_hw_start_8168g(struct rtl8169_private *tp)
/* Adjust EEE LED frequency */
RTL_W8(tp, EEE_LED, RTL_R8(tp, EEE_LED) & ~0x07);
+ rtl8168_config_eee_mac(tp);
+
rtl_w0w1_eri(tp, 0x2fc, ERIAR_MASK_0001, 0x01, 0x06, ERIAR_EXGMAC);
rtl_w0w1_eri(tp, 0x1b0, ERIAR_MASK_0011, 0x0000, 0x1000, ERIAR_EXGMAC);
@@ -5119,6 +5297,8 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
/* Adjust EEE LED frequency */
RTL_W8(tp, EEE_LED, RTL_R8(tp, EEE_LED) & ~0x07);
+ rtl8168_config_eee_mac(tp);
+
RTL_W8(tp, DLLPR, RTL_R8(tp, DLLPR) & ~PFM_EN);
RTL_W8(tp, MISC_1, RTL_R8(tp, MISC_1) & ~PFM_D3COLD_EN);
@@ -5199,6 +5379,8 @@ static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
/* Adjust EEE LED frequency */
RTL_W8(tp, EEE_LED, RTL_R8(tp, EEE_LED) & ~0x07);
+ rtl8168_config_eee_mac(tp);
+
rtl_w0w1_eri(tp, 0x2fc, ERIAR_MASK_0001, 0x01, 0x06, ERIAR_EXGMAC);
RTL_W8(tp, DLLPR, RTL_R8(tp, DLLPR) & ~TX_10M_PS_EN);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 0/2] r8169: add EEE support for RTL8168g+
From: Heiner Kallweit @ 2019-01-25 19:37 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
This series adds general EEE support to be used with ethtool.
In addition it implements EEE for chip versions from RTL8168g.
The first patch leaves the default chip settings and the
second enables EEE per default. This allows us to revert patch 2
w/o removing EEE support completely if we should face issues with
EEE on particular chip versions.
Unfortunately Realtek decided not to use the standard EEE MMD
registers but to use proprietary registers. Therefore we can't
use phylib functions like phy_ethtool_set_eee and have to
reimplement the functionality.
Tested on a system with RTL8168g (chip version 40).
Heiner Kallweit (2):
r8169: add general EEE support for chip versions from RTL8168g
r8169: enable EEE per default on chip versions from RTL8168g
drivers/net/ethernet/realtek/r8169.c | 216 +++++++++++++++++++++++++--
1 file changed, 206 insertions(+), 10 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH net-next] netlink: reduce NLA_POLICY_NESTED{,_ARRAY} arguments
From: David Miller @ 2019-01-25 19:36 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev
In-Reply-To: <c3b87e72436aaae24facd2d329982ef09b9a60df.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 25 Jan 2019 20:34:57 +0100
> On Fri, 2019-01-25 at 11:04 -0800, David Miller wrote:
>>
>> > Dave, it looks like we're the only users of this right now,
>> > so let me know if you'd prefer I take it through my tree.
>> > Also, this conflicts with the fix I just made to the place
>> > where I got it wrong, but obviously the resolution is to
>> > just take the version without the maxattr argument.
>>
>> Please take it through your tree in that case. It'll probably
>> be the more painless way to merge this.
>
> Will do. The most painless would be if you'd merge net into net-next,
> then I could pull net-next into mac80211-next and resolve the conflict
> before I even apply the patch. In fact, I think either way I'll just
> wait until you do that, I suppose you will eventually anyway?
Yeah I will probably send Linus a pull request today which means the
net --> net-next merge should occur in the next 24 hours.
^ permalink raw reply
* Re: [PATCH net-next] netlink: reduce NLA_POLICY_NESTED{,_ARRAY} arguments
From: Johannes Berg @ 2019-01-25 19:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
In-Reply-To: <20190125.110403.1859522316620338548.davem@davemloft.net>
On Fri, 2019-01-25 at 11:04 -0800, David Miller wrote:
>
> > Dave, it looks like we're the only users of this right now,
> > so let me know if you'd prefer I take it through my tree.
> > Also, this conflicts with the fix I just made to the place
> > where I got it wrong, but obviously the resolution is to
> > just take the version without the maxattr argument.
>
> Please take it through your tree in that case. It'll probably
> be the more painless way to merge this.
Will do. The most painless would be if you'd merge net into net-next,
then I could pull net-next into mac80211-next and resolve the conflict
before I even apply the patch. In fact, I think either way I'll just
wait until you do that, I suppose you will eventually anyway?
johannes
^ permalink raw reply
* Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390X
From: Marek Behun @ 2019-01-25 19:25 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev, David Miller
In-Reply-To: <9f2fae06-6951-3430-0b25-33284415f037@gmail.com>
On Fri, 25 Jan 2019 10:48:38 -0800
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 1/24/19 11:39 AM, Marek Behun wrote:
> > On Thu, 24 Jan 2019 11:27:54 -0800
> > Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >> On 1/24/19 11:24 AM, Marek Behun wrote:
> >>> On Thu, 24 Jan 2019 19:11:59 +0100
> >>> Andrew Lunn <andrew@lunn.ch> wrote:
> >>>
> >>>> On Thu, Jan 24, 2019 at 07:04:51PM +0100, Marek Behun wrote:
> >>>>> What properties does the cpu port node need to contain to force
> >>>>> it? phy-mode = "2500base-x"; is not enough.
> >>>>
> >>>> Hi Marek
> >>>>
> >>>> For DSA ports we have:
> >>>>
> >>>> phy-mode =
> >>>> "rgmii-txid"; fixed-link {
> >>>> speed =
> >>>> <1000>; full-duplex;
> >>>> };
> >>>>
> >>>> See dsa_port_fixed_link_register_of()
> >>>>
> >>>> Andrew
> >>>
> >>> Hi Andrew,
> >>> the configuration
> >>> phy-mode = "2500base-x";
> >>> fixed-link {
> >>> speed = <2500>;
> >>> full-duplex;
> >>> };
> >>> does not work, because swphy does not support speed=2500 (only 10,
> >>> 100 and 1000).
> >>> managed = "in-band-status";
> >>> does not work either.
> >>>
> >>> If I use speed = <1000>, then the swphy is created correctly,
> >>> cmode is set correctly to 2500base-x, but speed register on the
> >>> port is set to 1000, and the connection does not work.
> >>>
> >>> The easiest way would probably be to implement swphy to support
> >>> speed 2500. But I don't know what values should the simulated PHY
> >>> registers contain...
> >>>
> >>> The function dsa_port_fixed_link_register_of creates this phy
> >>> device, adjusts the link and then calls
> >>> put_device(&phydev->mdio.dev); Does this mean that the phy device
> >>> is immediately destroyed?
> >>
> >> Yes, we should actually migrate that code over to PHYLINK, because
> >> in PHYLINK the fixed links don't require creating a phy_device
> >> instance. This is something that has a potential of breaking a lot
> >> of people, so I have not really started doing it just yet :)
> >
> > Can't then this patch be applied so that Turris Mox will work
> > again? At least till the cpu/dsa port connection is converted to
> > phylink.
>
> How about the following hack until we can support netdev less PHYLINK
> instances while having the Device Tree being corrected to have the
> correct phy-mode = "2500base-x" property since we will need it for
> PHYLINK on CPU/DSA ports later on:
>
> diff --git a/net/dsa/port.c b/net/dsa/port.c
> index 2d7e01b23572..9ea052c30b68 100644
> --- a/net/dsa/port.c
> +++ b/net/dsa/port.c
> @@ -359,6 +359,14 @@ static int dsa_port_fixed_link_register_of(struct
> dsa_port *dp)
> if (mode < 0)
> mode = PHY_INTERFACE_MODE_NA;
> phydev->interface = mode;
> + switch (mode) {
> + case PHY_INTERFACE_MODE_2500BASEX:
> + phydev->speed = SPEED_2500;
> + break;
> + case PHY_INTERFACE_MODE_10GKR:
> + phydev->speed = SPEED_10000;
> + break;
> + }
>
> genphy_config_init(phydev);
> genphy_read_status(phydev);
But in the dts there would still have to be speed=<1000>; otherwise
swphy will fail...
^ permalink raw reply
* Re: [PATCH] r8169: Load MAC address from device tree if present
From: Heiner Kallweit @ 2019-01-25 19:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: Thierry Reding, David S. Miller, Realtek linux nic maintainers,
netdev, devicetree, linux-kernel
In-Reply-To: <20190125190715.GG22211@lunn.ch>
On 25.01.2019 20:07, Andrew Lunn wrote:
>> Andrew, for my understanding: What do you think is wrong with the
>> alignment requirement? It was introduced because we do a 32 bit access
>> to the start address of the array and want to avoid an unaligned access.
>
> Hi Heiner
>
> Because you are doing pointer aliasing, the compiler will by default
> generate bad code, doing unaligned access. Adding the attribute works
> around this. But it is just a work around. Since this is very slow
> path code, i would just avoid the pointer aliasing, write a bit more C
> code as Thierry suggested, and the optimiser will probably figure out
> what is going on and produce reasonable code.
>
> Also, in general, by avoiding pointer aliasing, you allow static code
> checkers to work better. They are more likely to discover buffer
> overruns, etc.
>
> Andrew
>
Thanks, good to know.
The following doesn't hurt us here, but things like this have to be
considered too. According to chip spec:
"The ID registers 0-5 are only permitted to write by 4-byte access.
Read access can be byte, word, or double word access."
Heiner
^ permalink raw reply
* Re: Regression: mv88e6xxx packet loss after 4.18's PHYLINK merge
From: Russell King - ARM Linux admin @ 2019-01-25 19:15 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, Samu Nuutamo, netdev, Vivien Didelot,
David S. Miller
In-Reply-To: <27dc2e53-bff6-534d-d411-3efc8d7ff279@gmail.com>
On Fri, Jan 25, 2019 at 11:00:46AM -0800, Florian Fainelli wrote:
> > +++ b/drivers/net/phy/phylink.c
> > @@ -409,7 +409,8 @@ static void phylink_resolve(struct work_struct *w)
> >
> > case MLO_AN_FIXED:
> > phylink_get_fixed_state(pl, &link_state);
> > - phylink_mac_config(pl, &link_state);
> > + if (link_state.link != netif_carrier_ok(ndev))
> > + phylink_mac_config(pl, &link_state);
>
> With that change though, I don't think we would ever be able to disable
> the MAC upon link down which could be sucking additional power, so maybe
> we should be comparing link_state.link with the previous link_state
> (prior to calling phylink_get_fixed_state(), so something like that:
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index e7becc7379d7..88e0045ecf79 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -409,7 +409,8 @@ static void phylink_resolve(struct work_struct *w)
>
> case MLO_AN_FIXED:
> phylink_get_fixed_state(pl, &link_state);
> - phylink_mac_config(pl, &link_state);
> + if (pl->mac_link_dropped != link_state.link)
> + phylink_mac_config(pl, &link_state);
> break;
>
> case MLO_AN_INBAND:
>
>
> It seems to me that the problem might very well be mv88e6xxx specific in
> that the function mv88e6xxx_port_setup_mac() calls into multiple other
> functions in order to configure the port's MAC and that is not atomic
> from the HW's perspective, therefore there is a chance for the HW to
> latch in some register writes (even if they are the same values) trigger
> a MAC reconfiguration upon that write, which is responsible for causing
> some packets to be dropped.
The mac_config is expected to _update_ the MAC, not reprogram it in
full each time it's called.
Consider a SGMII link with a PHY on a SFP module. The SGMII link
must be placed in "negotiation" mode (so must use in-band negotiation)
but there is no mechanism on the link to convey the negotiated flow
control settings. So, mac_config() must be called whenever the link
changes to update the MAC with the flow control settings read from
the PHY. However, the MAC still needs negotiation enabled on the
link, and must not disturb that, because it could cause the PHY to
then report link-down. That would throw phylink into a continual
loop of the link bouncing up and down.
This is how I've implemented mac_config() in both mvneta and the out
of tree mvpp2x driver - in mvneta, I read the current register
settings, modify them according to the requested parameters, then
compare them, and only write the new register settings back as
required taking account of hardware restrictions (eg, port needs to
be temporarily disabled if certain settings are changed.)
If mac_config() is implemented as per that, then the above patch is
unnecessary.
I know that detail is not documented, it's something that I need to
update in the header file and my .rst documentation (also something
else that needs submitting.)
I also have a patch for phylink that allows us to use the GPIO
interrupt rather than polling with a 1s timer to check the state of
the fixed-link GPIO.
--
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
* Re: [PATCH] r8169: Load MAC address from device tree if present
From: Andrew Lunn @ 2019-01-25 19:07 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Thierry Reding, David S. Miller, Realtek linux nic maintainers,
netdev, devicetree, linux-kernel
In-Reply-To: <42d32783-c433-b859-6ba4-f2864f034871@gmail.com>
> Andrew, for my understanding: What do you think is wrong with the
> alignment requirement? It was introduced because we do a 32 bit access
> to the start address of the array and want to avoid an unaligned access.
Hi Heiner
Because you are doing pointer aliasing, the compiler will by default
generate bad code, doing unaligned access. Adding the attribute works
around this. But it is just a work around. Since this is very slow
path code, i would just avoid the pointer aliasing, write a bit more C
code as Thierry suggested, and the optimiser will probably figure out
what is going on and produce reasonable code.
Also, in general, by avoiding pointer aliasing, you allow static code
checkers to work better. They are more likely to discover buffer
overruns, etc.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] netlink: reduce NLA_POLICY_NESTED{,_ARRAY} arguments
From: David Miller @ 2019-01-25 19:04 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, johannes.berg
In-Reply-To: <20190125090828.26361-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 25 Jan 2019 10:08:28 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> In typical cases, there's no need to pass both the maxattr
> and the policy array pointer, as the maxattr should just be
> ARRAY_SIZE(policy) - 1. Therefore, to be less error prone,
> just remove the maxattr argument from the default macros
> and deduce the size accordingly.
>
> Leave the original macros with a leading underscore to use
> here and in case somebody needs to pass a policy pointer
> where the policy isn't declared in the same place and thus
> ARRAY_SIZE() cannot be used.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> Dave, it looks like we're the only users of this right now,
> so let me know if you'd prefer I take it through my tree.
> Also, this conflicts with the fix I just made to the place
> where I got it wrong, but obviously the resolution is to
> just take the version without the maxattr argument.
Please take it through your tree in that case. It'll probably
be the more painless way to merge this.
^ permalink raw reply
* Re: [RFC PATCH 0/3] RV64G eBPF JIT
From: Palmer Dabbelt @ 2019-01-25 19:02 UTC (permalink / raw)
To: bjorn.topel; +Cc: Christoph Hellwig, linux-riscv, davidlee, daniel, netdev
In-Reply-To: <CAJ+HfNhHUCM_YPUF01s=Tgh-M1_PMF6Jev1PQjwqfgva0vgeLw@mail.gmail.com>
On Tue, 15 Jan 2019 08:03:18 PST (-0800), bjorn.topel@gmail.com wrote:
> Den tis 15 jan. 2019 kl 16:40 skrev Christoph Hellwig <hch@infradead.org>:
>>
>> Hi Björn,
>>
>> at least for me patch 3 didn't make it to the list.
>>
>
> Hmm, held back: "Your message to linux-riscv awaits moderator
> approval". Exceeded the 40k limit.
>
> I'll wait until the moderator wakes up (Palmer?).
Sorry, it took me a while to wake up :)
>
>
> Björn
>
>> On Tue, Jan 15, 2019 at 09:35:15AM +0100, Björn Töpel wrote:
>> > Hi!
>> >
>> > I've been hacking on a RV64G eBPF JIT compiler, and would like some
>> > feedback.
>> >
>> > Codewise, it needs some refactoring. Currently there's a bit too much
>> > copy-and-paste going on, and I know some places where I could optimize
>> > the code generation a bit (mostly BPF_K type of instructions, dealing
>> > with immediates).
>> >
>> > From a features perspective, two things are missing:
>> >
>> > * tail calls
>> > * "far-branches", i.e. conditional branches that reach beyond 13b.
>> >
>> > The test_bpf.ko (only tested on 4.20!) passes all tests.
>> >
>> > I've done all the tests on QEMU (version 3.1.50), so no real hardware.
>> >
>> > Some questions/observations:
>> >
>> > * I've added "HAVE_EFFICIENT_UNALIGNED_ACCESS" to
>> > arch/riscv/Kconfig. Is this assumption correct?
>> >
>> > * emit_imm() just relies on lui, adds and shifts. No fancy xori cost
>> > optimizations like GCC does.
>> >
>> > * Suggestions on how to implement the tail call, given that the
>> > prologue/epilogue has variable size. I will dig into the details of
>> > mips/arm64/x86. :-)
>> >
>> > Next steps (prior patch proper) is cleaning up the code, add tail
>> > calls, and making sure that bpftool disassembly works correctly.
>> >
>> > All input are welcome. This is my first RISC-V hack, so I sure there
>> > are a lot things to improve!
>> >
>> >
>> > Thanks,
>> > Björn
>> >
>> >
>> > Björn Töpel (3):
>> > riscv: set HAVE_EFFICIENT_UNALIGNED_ACCESS
>> > riscv: add build infra for JIT compiler
>> > bpf, riscv: added eBPF JIT for RV64G
>> >
>> > arch/riscv/Kconfig | 2 +
>> > arch/riscv/Makefile | 4 +
>> > arch/riscv/net/Makefile | 5 +
>> > arch/riscv/net/bpf_jit_comp.c | 1612 +++++++++++++++++++++++++++++++++
>> > 4 files changed, 1623 insertions(+)
>> > create mode 100644 arch/riscv/net/Makefile
>> > create mode 100644 arch/riscv/net/bpf_jit_comp.c
>> >
>> > --
>> > 2.19.1
>> >
>> >
>> > _______________________________________________
>> > linux-riscv mailing list
>> > linux-riscv@lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>> ---end quoted text---
^ permalink raw reply
* Re: Regression: mv88e6xxx packet loss after 4.18's PHYLINK merge
From: Florian Fainelli @ 2019-01-25 19:00 UTC (permalink / raw)
To: Andrew Lunn, Samu Nuutamo, Russell King
Cc: netdev, Vivien Didelot, David S. Miller
In-Reply-To: <20190123021032.GG3634@lunn.ch>
On 1/22/19 6:10 PM, Andrew Lunn wrote:
>> Hi Andrew,
>>
>> I tested the patch and it has an issue that prevents the carrier from turning
>> on. I think it's caused by the change from using link_state to phy->phy_state,
>> as later in the same function the link_state attributes are read when
>> deciding if the carrier needs to be turned on.
>
> Hi Samu
>
> This version has had better testing. So i'm a bit more confident about
> it.
>
> Andrew
>
> From d093492f9aba75cb4844d15148e0efd014f193bb Mon Sep 17 00:00:00 2001
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Wed, 16 Jan 2019 20:22:04 -0600
> Subject: [PATCH] net: phy: phylink: Only change mac when fixed link changes
> state
>
> phylink polls the fixed-link once per second to see if the GPIO has
> changed state, or if the callback indicates if there has been a change
> in state. It then calls the MAC to reconfigure itself to the current
> state.
>
> For some MACs, reconfiguration can result in packets being dropped.
> Hence only reconfigure the MAC if the link state differs from the
> netdev carrier state.
>
> Reported-by: Samu Nuutamo <samu.nuutamo@vincit.fi>
> Fixes: 9cd00a8aa42e ("net: phy: phylink: Poll link GPIOs")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/phy/phylink.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index e7becc7379d7..394b1eb5b55a 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -409,7 +409,8 @@ static void phylink_resolve(struct work_struct *w)
>
> case MLO_AN_FIXED:
> phylink_get_fixed_state(pl, &link_state);
> - phylink_mac_config(pl, &link_state);
> + if (link_state.link != netif_carrier_ok(ndev))
> + phylink_mac_config(pl, &link_state);
With that change though, I don't think we would ever be able to disable
the MAC upon link down which could be sucking additional power, so maybe
we should be comparing link_state.link with the previous link_state
(prior to calling phylink_get_fixed_state(), so something like that:
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index e7becc7379d7..88e0045ecf79 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -409,7 +409,8 @@ static void phylink_resolve(struct work_struct *w)
case MLO_AN_FIXED:
phylink_get_fixed_state(pl, &link_state);
- phylink_mac_config(pl, &link_state);
+ if (pl->mac_link_dropped != link_state.link)
+ phylink_mac_config(pl, &link_state);
break;
case MLO_AN_INBAND:
It seems to me that the problem might very well be mv88e6xxx specific in
that the function mv88e6xxx_port_setup_mac() calls into multiple other
functions in order to configure the port's MAC and that is not atomic
from the HW's perspective, therefore there is a chance for the HW to
latch in some register writes (even if they are the same values) trigger
a MAC reconfiguration upon that write, which is responsible for causing
some packets to be dropped.
--
Florian
^ permalink raw reply related
* Re: pull-request: mac80211 2019-01-25
From: David Miller @ 2019-01-25 19:00 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190125132041.13375-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 25 Jan 2019 14:20:40 +0100
> Here are 8 fixes for the current cycle, nothing that seems out of
> the ordinary.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: [net 1/4] net/mlx5e: Force CHECKSUM_UNNECESSARY for short ethernet frames
From: Saeed Mahameed @ 2019-01-25 18:58 UTC (permalink / raw)
To: eric.dumazet@gmail.com, xiyou.wangcong@gmail.com
Cc: davem@davemloft.net, netdev@vger.kernel.org, Tariq Toukan,
edumazet@google.com, nikola.ciprich@linuxbox.cz
In-Reply-To: <8d7f25f7-6aa3-c5d9-084a-5202374db419@gmail.com>
On Fri, 2019-01-25 at 10:31 -0800, Eric Dumazet wrote:
>
> On 01/25/2019 10:22 AM, Saeed Mahameed wrote:
> > On Tue, 2019-01-22 at 13:30 -0800, Cong Wang wrote:
> > > On Fri, Jan 18, 2019 at 4:25 PM Saeed Mahameed <
> > > saeedm@mellanox.com>
> > > wrote:
> > > > From: Cong Wang <xiyou.wangcong@gmail.com>
> > >
> > > I don't know why you want to make me as the author here, but I
> > > never
> > > agree on _your_ updates on my previous patch.
> > >
> > > Please see below.
> > >
> >
> > sorry, i just took your patch and worked on top of it, i thought
> > you
> > would like to get the credit for this.
> >
>
> I thought the issue was that the hardware csum provided by both mlx4
> and mlx5 only
> covered the bytes included in the IP (v4 or v6) frame.
>
> Meaning that any non zero padding bytes are not checksummed.
in case of non IP, mlx5 will provide csum complete on the whole frame.
> If this can not be fixed by a firmware change, then the fix has
> nothing to do with a frame being
> smaller than ETH_ZLEN + ETH_FCS_LEN
>
Again, most of the switches/routers that have non-zero padding bug are
padding only small frames.
> Alternative would be for the driver to trim the frame (pretend the
> skb->len is exactly the expected one),
> but one could argue that tcpdump should be able to see padding bytes.
>
That requires parsing the IP headers in the driver, we are trying to
avoid that, this patch is not perfect but eliminates many of the csum
warnings seen on mlx5.
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] Devlink health updates
From: David Miller @ 2019-01-25 18:56 UTC (permalink / raw)
To: eranbe; +Cc: jiri, netdev, jiri, saeedm, moshe
In-Reply-To: <8ba329b5-f550-2c3e-08d7-1094fbe4e6fb@mellanox.com>
From: Eran Ben Elisha <eranbe@mellanox.com>
Date: Fri, 25 Jan 2019 09:16:16 +0000
> On 1/25/2019 8:08 AM, David Miller wrote:
>> I'll do it once I have Eran's confirmation.
>
> Note that you will also have to revert ARM compilation fix which was
> accepted on top.
> https://patchwork.ozlabs.org/patch/1029047/
Thanks for this heads up.
I just pushed out the revert.
If I made any mistakes, please send me a fixup. But I am pretty sure
I got it right.
Thanks!
^ permalink raw reply
* [PATCH net-next 2/2] tcp: change pingpong threshold to 3
From: Wei Wang @ 2019-01-25 18:53 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Yuchung Cheng, Neal Cardwell, Eric Dumazet, Wei Wang
In-Reply-To: <20190125185320.164580-2-weiwan@google.com>
In order to be more confident about an on-going interactive session, we
increment pingpong count by 1 for every interactive transaction and we
adjust TCP_PINGPONG_THRESH to 3.
This means, we only consider a session in pingpong mode after we see 3
interactive transactions, and start to activate delayed acks in quick
ack mode.
And in order to not over-count the credits, we only increase pingpong
count for the first packet sent in response for the previous received
packet.
This is mainly to prevent delaying the ack immediately after some
handshake protocol but no real interactive traffic pattern afterwards.
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/inet_connection_sock.h | 10 +++++++++-
net/ipv4/tcp_output.c | 15 +++++++++------
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index 5c9fa6b72c5a..6d67eede41d2 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -315,7 +315,7 @@ int inet_csk_compat_setsockopt(struct sock *sk, int level, int optname,
struct dst_entry *inet_csk_update_pmtu(struct sock *sk, u32 mtu);
-#define TCP_PINGPONG_THRESH 1
+#define TCP_PINGPONG_THRESH 3
static inline void inet_csk_enter_pingpong_mode(struct sock *sk)
{
@@ -331,4 +331,12 @@ static inline bool inet_csk_in_pingpong_mode(struct sock *sk)
{
return inet_csk(sk)->icsk_ack.pingpong >= TCP_PINGPONG_THRESH;
}
+
+static inline void inet_csk_inc_pingpong_cnt(struct sock *sk)
+{
+ struct inet_connection_sock *icsk = inet_csk(sk);
+
+ if (icsk->icsk_ack.pingpong < U8_MAX)
+ icsk->icsk_ack.pingpong++;
+}
#endif /* _INET_CONNECTION_SOCK_H */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 130e43b31210..79a25b174d0e 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -165,13 +165,16 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
if (tcp_packets_in_flight(tp) == 0)
tcp_ca_event(sk, CA_EVENT_TX_START);
- tp->lsndtime = now;
-
- /* If it is a reply for ato after last received
- * packet, enter pingpong mode.
+ /* If this is the first data packet sent in response to the
+ * previous received data,
+ * and it is a reply for ato after last received packet,
+ * increase pingpong count.
*/
- if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato)
- inet_csk_enter_pingpong_mode(sk);
+ if (before(tp->lsndtime, icsk->icsk_ack.lrcvtime) &&
+ (u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato)
+ inet_csk_inc_pingpong_cnt(sk);
+
+ tp->lsndtime = now;
}
/* Account for an ACK we sent. */
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply related
* [PATCH net-next 1/2] tcp: Refactor pingpong code
From: Wei Wang @ 2019-01-25 18:53 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Yuchung Cheng, Neal Cardwell, Eric Dumazet, Wei Wang
In-Reply-To: <20190125185320.164580-1-weiwan@google.com>
Instead of using pingpong as a single bit information, we refactor the
code to treat it as a counter. When interactive session is detected,
we set pingpong count to TCP_PINGPONG_THRESH. And when pingpong count
is >= TCP_PINGPONG_THRESH, we consider the session in pingpong mode.
This patch is a pure refactor and sets foundation for the next patch.
This patch itself does not change any pingpong logic.
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/inet_connection_sock.h | 17 +++++++++++++++++
net/dccp/input.c | 2 +-
net/dccp/timer.c | 4 ++--
net/ipv4/tcp.c | 10 +++++-----
net/ipv4/tcp_input.c | 8 ++++----
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/tcp_output.c | 4 ++--
net/ipv4/tcp_timer.c | 4 ++--
net/ipv6/tcp_ipv6.c | 2 +-
9 files changed, 35 insertions(+), 18 deletions(-)
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index 371b3b45fd5c..5c9fa6b72c5a 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -314,4 +314,21 @@ int inet_csk_compat_setsockopt(struct sock *sk, int level, int optname,
char __user *optval, unsigned int optlen);
struct dst_entry *inet_csk_update_pmtu(struct sock *sk, u32 mtu);
+
+#define TCP_PINGPONG_THRESH 1
+
+static inline void inet_csk_enter_pingpong_mode(struct sock *sk)
+{
+ inet_csk(sk)->icsk_ack.pingpong = TCP_PINGPONG_THRESH;
+}
+
+static inline void inet_csk_exit_pingpong_mode(struct sock *sk)
+{
+ inet_csk(sk)->icsk_ack.pingpong = 0;
+}
+
+static inline bool inet_csk_in_pingpong_mode(struct sock *sk)
+{
+ return inet_csk(sk)->icsk_ack.pingpong >= TCP_PINGPONG_THRESH;
+}
#endif /* _INET_CONNECTION_SOCK_H */
diff --git a/net/dccp/input.c b/net/dccp/input.c
index 85d6c879383d..8d03707abdac 100644
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -480,7 +480,7 @@ static int dccp_rcv_request_sent_state_process(struct sock *sk,
sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
}
- if (sk->sk_write_pending || icsk->icsk_ack.pingpong ||
+ if (sk->sk_write_pending || inet_csk_in_pingpong_mode(sk) ||
icsk->icsk_accept_queue.rskq_defer_accept) {
/* Save one ACK. Data will be ready after
* several ticks, if write_pending is set.
diff --git a/net/dccp/timer.c b/net/dccp/timer.c
index 1501a20a94ca..74e138495d67 100644
--- a/net/dccp/timer.c
+++ b/net/dccp/timer.c
@@ -199,7 +199,7 @@ static void dccp_delack_timer(struct timer_list *t)
icsk->icsk_ack.pending &= ~ICSK_ACK_TIMER;
if (inet_csk_ack_scheduled(sk)) {
- if (!icsk->icsk_ack.pingpong) {
+ if (!inet_csk_in_pingpong_mode(sk)) {
/* Delayed ACK missed: inflate ATO. */
icsk->icsk_ack.ato = min(icsk->icsk_ack.ato << 1,
icsk->icsk_rto);
@@ -207,7 +207,7 @@ static void dccp_delack_timer(struct timer_list *t)
/* Delayed ACK missed: leave pingpong mode and
* deflate ATO.
*/
- icsk->icsk_ack.pingpong = 0;
+ inet_csk_exit_pingpong_mode(sk);
icsk->icsk_ack.ato = TCP_ATO_MIN;
}
dccp_send_ack(sk);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 541bdb9f81d7..800ec37b24ce 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1554,7 +1554,7 @@ static void tcp_cleanup_rbuf(struct sock *sk, int copied)
(copied > 0 &&
((icsk->icsk_ack.pending & ICSK_ACK_PUSHED2) ||
((icsk->icsk_ack.pending & ICSK_ACK_PUSHED) &&
- !icsk->icsk_ack.pingpong)) &&
+ !inet_csk_in_pingpong_mode(sk))) &&
!atomic_read(&sk->sk_rmem_alloc)))
time_to_ack = true;
}
@@ -2987,16 +2987,16 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
case TCP_QUICKACK:
if (!val) {
- icsk->icsk_ack.pingpong = 1;
+ inet_csk_enter_pingpong_mode(sk);
} else {
- icsk->icsk_ack.pingpong = 0;
+ inet_csk_exit_pingpong_mode(sk);
if ((1 << sk->sk_state) &
(TCPF_ESTABLISHED | TCPF_CLOSE_WAIT) &&
inet_csk_ack_scheduled(sk)) {
icsk->icsk_ack.pending |= ICSK_ACK_PUSHED;
tcp_cleanup_rbuf(sk, 1);
if (!(val & 1))
- icsk->icsk_ack.pingpong = 1;
+ inet_csk_enter_pingpong_mode(sk);
}
}
break;
@@ -3410,7 +3410,7 @@ static int do_tcp_getsockopt(struct sock *sk, int level,
return 0;
}
case TCP_QUICKACK:
- val = !icsk->icsk_ack.pingpong;
+ val = !inet_csk_in_pingpong_mode(sk);
break;
case TCP_CONGESTION:
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 76858b14ebe9..7a027dec649b 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -221,7 +221,7 @@ void tcp_enter_quickack_mode(struct sock *sk, unsigned int max_quickacks)
struct inet_connection_sock *icsk = inet_csk(sk);
tcp_incr_quickack(sk, max_quickacks);
- icsk->icsk_ack.pingpong = 0;
+ inet_csk_exit_pingpong_mode(sk);
icsk->icsk_ack.ato = TCP_ATO_MIN;
}
EXPORT_SYMBOL(tcp_enter_quickack_mode);
@@ -236,7 +236,7 @@ static bool tcp_in_quickack_mode(struct sock *sk)
const struct dst_entry *dst = __sk_dst_get(sk);
return (dst && dst_metric(dst, RTAX_QUICKACK)) ||
- (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);
+ (icsk->icsk_ack.quick && !inet_csk_in_pingpong_mode(sk));
}
static void tcp_ecn_queue_cwr(struct tcp_sock *tp)
@@ -4094,7 +4094,7 @@ void tcp_fin(struct sock *sk)
case TCP_ESTABLISHED:
/* Move to CLOSE_WAIT */
tcp_set_state(sk, TCP_CLOSE_WAIT);
- inet_csk(sk)->icsk_ack.pingpong = 1;
+ inet_csk_enter_pingpong_mode(sk);
break;
case TCP_CLOSE_WAIT:
@@ -5889,7 +5889,7 @@ static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb,
return -1;
if (sk->sk_write_pending ||
icsk->icsk_accept_queue.rskq_defer_accept ||
- icsk->icsk_ack.pingpong) {
+ inet_csk_in_pingpong_mode(sk)) {
/* Save one ACK. Data will be ready after
* several ticks, if write_pending is set.
*
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index efc6fef692ff..662b034f1795 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2437,7 +2437,7 @@ static void get_tcp4_sock(struct sock *sk, struct seq_file *f, int i)
refcount_read(&sk->sk_refcnt), sk,
jiffies_to_clock_t(icsk->icsk_rto),
jiffies_to_clock_t(icsk->icsk_ack.ato),
- (icsk->icsk_ack.quick << 1) | icsk->icsk_ack.pingpong,
+ (icsk->icsk_ack.quick << 1) | inet_csk_in_pingpong_mode(sk),
tp->snd_cwnd,
state == TCP_LISTEN ?
fastopenq->max_qlen :
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 6527f61f59ff..130e43b31210 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -171,7 +171,7 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
* packet, enter pingpong mode.
*/
if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato)
- icsk->icsk_ack.pingpong = 1;
+ inet_csk_enter_pingpong_mode(sk);
}
/* Account for an ACK we sent. */
@@ -3568,7 +3568,7 @@ void tcp_send_delayed_ack(struct sock *sk)
const struct tcp_sock *tp = tcp_sk(sk);
int max_ato = HZ / 2;
- if (icsk->icsk_ack.pingpong ||
+ if (inet_csk_in_pingpong_mode(sk) ||
(icsk->icsk_ack.pending & ICSK_ACK_PUSHED))
max_ato = TCP_DELACK_MAX;
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index d7399a89469d..f0c86398e6a7 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -277,14 +277,14 @@ void tcp_delack_timer_handler(struct sock *sk)
icsk->icsk_ack.pending &= ~ICSK_ACK_TIMER;
if (inet_csk_ack_scheduled(sk)) {
- if (!icsk->icsk_ack.pingpong) {
+ if (!inet_csk_in_pingpong_mode(sk)) {
/* Delayed ACK missed: inflate ATO. */
icsk->icsk_ack.ato = min(icsk->icsk_ack.ato << 1, icsk->icsk_rto);
} else {
/* Delayed ACK missed: leave pingpong mode and
* deflate ATO.
*/
- icsk->icsk_ack.pingpong = 0;
+ inet_csk_exit_pingpong_mode(sk);
icsk->icsk_ack.ato = TCP_ATO_MIN;
}
tcp_mstamp_refresh(tcp_sk(sk));
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index b81eb7cb815e..e51cda79f0cc 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1864,7 +1864,7 @@ static void get_tcp6_sock(struct seq_file *seq, struct sock *sp, int i)
refcount_read(&sp->sk_refcnt), sp,
jiffies_to_clock_t(icsk->icsk_rto),
jiffies_to_clock_t(icsk->icsk_ack.ato),
- (icsk->icsk_ack.quick << 1) | icsk->icsk_ack.pingpong,
+ (icsk->icsk_ack.quick << 1) | inet_csk_in_pingpong_mode(sp),
tp->snd_cwnd,
state == TCP_LISTEN ?
fastopenq->max_qlen :
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply related
* [PATCH net-next 0/2] tcp: change pingpong to 3 in delayed ack logic
From: Wei Wang @ 2019-01-25 18:53 UTC (permalink / raw)
To: David Miller, netdev; +Cc: Yuchung Cheng, Neal Cardwell, Eric Dumazet, Wei Wang
TCP receiver today tries not to delay the ACKs to speed up the initial
slow start (a.k.a QUICK ACK mechanism). However the previous design
does not work well with modern TCP applications that starts with an
application-level handshake. For example, a HTTPs server often
receives the SSL hello and responds right away which triggers the TCP
stack to stop the quick ack and start delaying the ACKs based only one
instance of ping-pong. This patchset changes the threshold from 1 to 3
ping-pong transactions, so that we only start to delay the acks after
the receiver responds data quickly three times.
Wei Wang (2):
tcp: Refactor pingpong code
tcp: change pingpong threshold to 3
include/net/inet_connection_sock.h | 25 +++++++++++++++++++++++++
net/dccp/input.c | 2 +-
net/dccp/timer.c | 4 ++--
net/ipv4/tcp.c | 10 +++++-----
net/ipv4/tcp_input.c | 8 ++++----
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/tcp_output.c | 17 ++++++++++-------
net/ipv4/tcp_timer.c | 4 ++--
net/ipv6/tcp_ipv6.c | 2 +-
9 files changed, 51 insertions(+), 23 deletions(-)
--
2.20.1.321.g9e740568ce-goog
^ permalink raw reply
* Re: [PATCH] net: phy: at803x: Use helpers to access MMD PHY registers
From: Andrew Lunn @ 2019-01-25 18:51 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Carlo Caione, f.fainelli, davem, netdev, linux-kernel
In-Reply-To: <a7f5531b-902b-2849-02a5-a4ec8660e06d@gmail.com>
On Fri, Jan 25, 2019 at 07:11:28PM +0100, Heiner Kallweit wrote:
> On 25.01.2019 16:00, Andrew Lunn wrote:
> > On Fri, Jan 25, 2019 at 12:35:10PM +0000, Carlo Caione wrote:
> >> Libphy provides a standard set of helpers to access the MMD PHY
> >> registers. Use those instead of relying on custom driver-specific
> >> functions.
> >
> > Hi Carlo
> >
> > Maybe deja vu, but i thought a similar patch went by recently?
> >
> Andrew, maybe you mean this one?
>
> 9b420eff9fcf ("net: phy: micrel: use phy_read_mmd and phy_write_mmd")
Yes, probably that one.
Might be worth grepping of 0xd, 0xe, 0x0d, 0x0e, 13, 14, and see if
there are any more instances in PHY drivers.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390X
From: Florian Fainelli @ 2019-01-25 18:48 UTC (permalink / raw)
To: Marek Behun; +Cc: Andrew Lunn, netdev, David Miller
In-Reply-To: <20190124203905.2c79602e@nic.cz>
On 1/24/19 11:39 AM, Marek Behun wrote:
> On Thu, 24 Jan 2019 11:27:54 -0800
> Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> On 1/24/19 11:24 AM, Marek Behun wrote:
>>> On Thu, 24 Jan 2019 19:11:59 +0100
>>> Andrew Lunn <andrew@lunn.ch> wrote:
>>>
>>>> On Thu, Jan 24, 2019 at 07:04:51PM +0100, Marek Behun wrote:
>>>>> What properties does the cpu port node need to contain to force
>>>>> it? phy-mode = "2500base-x"; is not enough.
>>>>
>>>> Hi Marek
>>>>
>>>> For DSA ports we have:
>>>>
>>>> phy-mode =
>>>> "rgmii-txid"; fixed-link {
>>>> speed =
>>>> <1000>; full-duplex;
>>>> };
>>>>
>>>> See dsa_port_fixed_link_register_of()
>>>>
>>>> Andrew
>>>
>>> Hi Andrew,
>>> the configuration
>>> phy-mode = "2500base-x";
>>> fixed-link {
>>> speed = <2500>;
>>> full-duplex;
>>> };
>>> does not work, because swphy does not support speed=2500 (only 10,
>>> 100 and 1000).
>>> managed = "in-band-status";
>>> does not work either.
>>>
>>> If I use speed = <1000>, then the swphy is created correctly, cmode
>>> is set correctly to 2500base-x, but speed register on the port is
>>> set to 1000, and the connection does not work.
>>>
>>> The easiest way would probably be to implement swphy to support
>>> speed 2500. But I don't know what values should the simulated PHY
>>> registers contain...
>>>
>>> The function dsa_port_fixed_link_register_of creates this phy
>>> device, adjusts the link and then calls
>>> put_device(&phydev->mdio.dev); Does this mean that the phy device
>>> is immediately destroyed?
>>
>> Yes, we should actually migrate that code over to PHYLINK, because in
>> PHYLINK the fixed links don't require creating a phy_device instance.
>> This is something that has a potential of breaking a lot of people,
>> so I have not really started doing it just yet :)
>
> Can't then this patch be applied so that Turris Mox will work again? At
> least till the cpu/dsa port connection is converted to phylink.
How about the following hack until we can support netdev less PHYLINK
instances while having the Device Tree being corrected to have the
correct phy-mode = "2500base-x" property since we will need it for
PHYLINK on CPU/DSA ports later on:
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 2d7e01b23572..9ea052c30b68 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -359,6 +359,14 @@ static int dsa_port_fixed_link_register_of(struct
dsa_port *dp)
if (mode < 0)
mode = PHY_INTERFACE_MODE_NA;
phydev->interface = mode;
+ switch (mode) {
+ case PHY_INTERFACE_MODE_2500BASEX:
+ phydev->speed = SPEED_2500;
+ break;
+ case PHY_INTERFACE_MODE_10GKR:
+ phydev->speed = SPEED_10000;
+ break;
+ }
genphy_config_init(phydev);
genphy_read_status(phydev);
--
Florian
^ permalink raw reply related
* Re: [PATCH] net: phy: at803x: Use helpers to access MMD PHY registers
From: Florian Fainelli @ 2019-01-25 18:40 UTC (permalink / raw)
To: Carlo Caione, andrew, hkallweit1, davem, netdev, linux-kernel
In-Reply-To: <20190125123510.20511-1-ccaione@baylibre.com>
On 1/25/19 4:35 AM, Carlo Caione wrote:
> Libphy provides a standard set of helpers to access the MMD PHY
> registers. Use those instead of relying on custom driver-specific
> functions.
>
> Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: net: phylink: dsa: mv88e6xxx: flaky link detection on switch ports with internal PHYs
From: John David Anglin @ 2019-01-25 18:38 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev
In-Reply-To: <20190125164850.z7hkyr4f73q3enk5@e5254000004ec.dyn.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
On 2019-01-25 11:48 a.m., Russell King - ARM Linux admin wrote:
> If you don't have any means to reset the card like that, then the only
> workaround is to reduce the maximum speed - and avoid going to 1.8V
> signalling mode.
There is no power controller on espressobin. The regulator only
switches the I/O voltage.
The attached change fixed reboot on espressobin with problematic SD card.
Thanks,
Dave
--
John David Anglin dave.anglin@bell.net
[-- Attachment #2: armada-3720-espressobin-sdhc.d --]
[-- Type: text/plain, Size: 511 bytes --]
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
index 3ab25ad402b9..df7eeda4b73c 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
@@ -57,6 +57,8 @@
&sdhci1 {
wp-inverted;
bus-width = <4>;
+ max-frequency = <50000000>;
+ no-1-8-v;
cd-gpios = <&gpionb 3 GPIO_ACTIVE_LOW>;
marvell,pad-type = "sd";
vqmmc-supply = <&vcc_sd_reg1>;
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules
From: Florian Fainelli @ 2019-01-25 18:37 UTC (permalink / raw)
To: Miquel Raynal, Andrew Lunn, Vivien Didelot, David S. Miller
Cc: netdev, linux-kernel, Thomas Petazzoni, Gregory Clement,
Antoine Tenart, Maxime Chevallier, Nadav Haklai
In-Reply-To: <20190125095507.29334-2-miquel.raynal@bootlin.com>
Hi Miquel,
On 1/25/19 1:55 AM, Miquel Raynal wrote:
> The user might apply a specific switch configuration, with specific
> forwarding rules, VLAN, bridges, etc.
>
> During suspend to RAM the switch power will be turned off and the
> switch will lost its configuration. In an attempt to bring S2RAM
> support to the mv88e6xxx DSA, let's first save these rules in a
> per-chip list thanks to the mv88e6xxx_add/del_xxx_rule()
> helpers. These helpers are then called from various callbacks:
> * mv88e6xxx_port_fdb_add/del()
> * mv88e6xxx_port_mdb_add/del()
> * mv88e6xxx_port_vlan_add/del()
> * mv88e6xxx_port_bridge_join/leave()
> * mv88e6xxx_crosschip_bridge_join/leave()
>
> To avoid recursion problems when replaying the rules, the content of
> the above *_add()/*_join() callbacks has been moved in separate
> helpers with a '_' prefix. Hence, each callback just calls the
> corresponding helper and the corresponding *_add_xxx_rule().
None of this should be done in the driver IMHO, because this is
presumably applicable to all switch devices that lose their state during
suspend/resume, so at best, this should be moved to the core DSA layer,
but doing this means that we should also have a well established
contract between the DSA layer and individual switch drivers as far as
quiescing/saving/restoring state goes.
By moving things to the core we can also more tightly control what data
structures get used to represent e.g.: VLANs, FDBs, MDBs etc and
possibly push/utilize caching into the original subsystem. For instance
VLAN/bridge already do maintain caches of VLANs, so if we could somehow
expose those, we would not bloat the kernel's memory footprint by having
an additional layer to maintain with identical information.
Just my 2 cents.
--
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