* [PATCH][net-next][v2] net/ipv6: compute anycast address hash only if dev is null
From: Li RongQing @ 2018-11-08 6:58 UTC (permalink / raw)
To: netdev
avoid to compute the hash value if dev is not null, since
hash value is not used
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/ipv6/anycast.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 94999058e110..cca3b3603c42 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -433,7 +433,6 @@ static bool ipv6_chk_acast_dev(struct net_device *dev, const struct in6_addr *ad
bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
const struct in6_addr *addr)
{
- unsigned int hash = inet6_acaddr_hash(net, addr);
struct net_device *nh_dev;
struct ifacaddr6 *aca;
bool found = false;
@@ -441,7 +440,9 @@ bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
rcu_read_lock();
if (dev)
found = ipv6_chk_acast_dev(dev, addr);
- else
+ else {
+ unsigned int hash = inet6_acaddr_hash(net, addr);
+
hlist_for_each_entry_rcu(aca, &inet6_acaddr_lst[hash],
aca_addr_lst) {
nh_dev = fib6_info_nh_dev(aca->aca_rt);
@@ -452,6 +453,7 @@ bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
break;
}
}
+ }
rcu_read_unlock();
return found;
}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net-next 0/3] nfp: add and use tunnel netdev helpers
From: David Miller @ 2018-11-08 7:00 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, oss-drivers, jakub.kicinski
In-Reply-To: <1541615570-523-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Wed, 7 Nov 2018 18:32:47 +0000
> A recent patch introduced the function netif_is_vxlan() to verify the
> tunnel type of a given netdev as vxlan.
>
> Add a similar function to detect geneve netdevs and make use of this
> function in the NFP driver. Also make use of the vxlan helper where
> applicable.
Series applied.
^ permalink raw reply
* [PATCH 1/3] ath6kl: Only use match sets when firmware supports it
From: Kyle Roeschley @ 2018-11-08 16:36 UTC (permalink / raw)
To: Kalle Valo
Cc: David S . Miller, linux-wireless, netdev, linux-kernel,
Kyle Roeschley
Commit dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan")
merged the probed and matched SSID lists before sending them to the
firmware. In the process, it assumed match set support is always available
in ath6kl_set_probed_ssids, which breaks scans for hidden SSIDs. Now, check
that the firmware supports matching SSIDs in scheduled scans before setting
MATCH_SSID_FLAG.
Fixes: dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan")
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index e121187f371f..6c98d7903ffb 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -939,7 +939,7 @@ static int ath6kl_set_probed_ssids(struct ath6kl *ar,
else
ssid_list[i].flag = ANY_SSID_FLAG;
- if (n_match_ssid == 0)
+ if (ar->wiphy->max_match_sets != 0 && n_match_ssid == 0)
ssid_list[i].flag |= MATCH_SSID_FLAG;
}
--
2.19.1
^ permalink raw reply related
* [PATCH 2/3] ath6kl: Fix off by one error in scan completion
From: Kyle Roeschley @ 2018-11-08 16:36 UTC (permalink / raw)
To: Kalle Valo
Cc: David S . Miller, linux-wireless, netdev, linux-kernel,
Kyle Roeschley
In-Reply-To: <20181108163659.19535-1-kyle.roeschley@ni.com>
When ath6kl was reworked to share code between regular and scheduled scans
in commit 3b8ffc6a22ba ("ath6kl: Configure probed SSID list consistently"),
probed SSID entry changed from 1-index to 0-indexed. However,
ath6kl_cfg80211_scan_complete_event() was missed in that change. Fix its
indexing so that we correctly clear out the probed SSID list.
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index 6c98d7903ffb..d7c626d9594e 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -1093,7 +1093,7 @@ void ath6kl_cfg80211_scan_complete_event(struct ath6kl_vif *vif, bool aborted)
if (vif->scan_req->n_ssids && vif->scan_req->ssids[0].ssid_len) {
for (i = 0; i < vif->scan_req->n_ssids; i++) {
ath6kl_wmi_probedssid_cmd(ar->wmi, vif->fw_vif_idx,
- i + 1, DISABLE_SSID_FLAG,
+ i, DISABLE_SSID_FLAG,
0, NULL);
}
}
--
2.19.1
^ permalink raw reply related
* Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2018-11-07
From: David Miller @ 2018-11-08 7:07 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20181107224830.9737-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 7 Nov 2018 14:48:18 -0800
> This series contains updates to almost all of the Intel wired LAN
> drivers.
...
> The following are changes since commit 7c588c7468ea3f9b2fc8fa6840bed6262b5d1b00:
> Merge branch 'net-systemport-Unmap-queues-upon-DSA-unregister-event'
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: phy: improve and simplify phylib state machine
From: Heiner Kallweit @ 2018-11-08 7:20 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <67c3bafb-5b4b-c33e-fd84-4cc6919b4bcb@gmail.com>
On 07.11.2018 21:45, Heiner Kallweit wrote:
> On 07.11.2018 21:21, Andrew Lunn wrote:
>> On Wed, Nov 07, 2018 at 09:05:49PM +0100, Heiner Kallweit wrote:
>>> On 07.11.2018 20:48, Andrew Lunn wrote:
>>>> On Wed, Nov 07, 2018 at 08:41:52PM +0100, Heiner Kallweit wrote:
>>>>> This patch series is based on two axioms:
>>>>>
>>>>> - During autoneg a PHY always reports the link being down
>>>>
>>>> Hi Heiner
>>>>
>>>> I think that is a risky assumption to make.
>>>>
>>> I wasn't sure initially too (found no clear rule in 802.3 clause 22)
>>> and therefore asked around. Florian agrees to the assumption,
>>> see here: https://www.spinics.net/lists/netdev/msg519242.html
>>>
>>> If a PHY reports the link as up then every user would assume that
>>> data can be transferred. But that's not the case during aneg.
>>> Therefore reporting the link as up during aneg wouldn't make sense.
>>
>> Hi Heiner
>>
>> If auto-neg has already been completed once before, i can see a lazy
>> hardware designed not reporting link down, or at least, not until
>> auto-neg actually fails.
>>
> "aneg finished" flag means that the aneg parameters in the register set
> are valid. Once the link goes down that's not necessarily the case any
> longer. E.g. some PHYs have an "auto speed down" feature and reduce
> the speed to save power once they detect the link is down.
> Of course I can not rule out that there are broken designs (or as you
> stated more politely: lazy designs) out there. But in this case I assume
> we would see issues already. And we would have to think about whether we
> want to support such broken / lazy designs in phylib.
>
Had one more look at the changes to check what happens if "link up" and
"aneg done" are not in sync.
When link goes down the changes don't change current behavior. We just
check the "link up" bit.
When link goes up and aneg isn't finished yet, then we would report
"link is up" earlier to userspace than we do now. If userspace starts
some network activity based on the "link up" event then they may fail.
But it really would be a major flaw if a PHY signals "link up" whilst
it's not actually ready yet to transfer data.
In case of such a broken design we would have issues with the current
code already, at least if interrupts are used. The "link up" interrupt
would cause the state machine to go to PHY_CHANGELINK which doesn't
check for aneg status.
>> And what about if link is down for too short a time for us to notice?
>> I've seen some code fail because the kernel went off and did something
>> else for too long, and a state change was missed.
>>
> This is a case we have already, independent of my change.
> genphy_update_link() reads BMSR twice, thus ignoring potential latched
> info about a temporary link failure. When polling phylib ignores
> everything that happens between two poll intervals.
>
>>>> What happens if this assumption is incorrect?
>>>>
>>> Then we have to flush this patch series down the drain ;)
>>> At least I would have to check in detail which parts need to be
>>> changed. I clearly mention the assumptions so that every
>>> reviewer can check whether he agrees.
>>
>> Thanks for doing that. I want to be happy this is safe, and not going
>> to introduce regressions.
>>
>> Andrew
>>
>
^ permalink raw reply
* [RFC PATCH 0/3] acpi: Add acpi mdio support code
From: Wang Dongsheng @ 2018-11-08 7:21 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <20181029124044.GB9174@lunn.ch>
Originally I just push "phy-handle" support for ACPI on the QCOM QDF2400
platform. After some discussion and following Andrew's advice, I send
out with a generic version of ACPI.
Current there is no clear documentation about MDIO/PHY for ACPI, so when
I reading some documents about ACPI [1], I think we just need to reuse the
DT binding in the ACPI.[2]. However, this series of patches are not
fully compatible with all contents specified in DT binding.
The most important thing about this iseries is link the phy device and
fwnode of acpi. Besides, we need to carry out bus scan at the mdio
register. Therefore, I am not compatible with more DT binding properties
in this series of patches. More support will be in the follow-up patches
support, or some people do the support.
Example:
Based on ACPI doc:
Documentation/acpi/dsd/data-node-references.txt
Documentation/acpi/dsd/graph.txt
With _DSD device properties we can finally do this:
Device (MDIO) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@0", PHY0 }, }
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x0 }, }
})
}
Device (MACO) {
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
})
}
Tested: QDF2400 (ACPI), buildin/insmod/rmmod
[1]:
Documentation/acpi/dsd/data-node-references.txt
Documentation/acpi/dsd/graph.txt
[2]:
Documentation/devicetree/bindings/phy/phy-bindings.txt
https://lore.kernel.org/patchwork/patch/597296/
Wang Dongsheng (3):
acpi: Add acpi mdio support code
net: qcom/emac: split phy_config to mdio bus create and get phy device
net: qcom/emac: add phy-handle support for ACPI
drivers/acpi/Kconfig | 6 +
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_mdio.c | 167 ++++++++++++++++++
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 19 +-
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 142 ++++++++++-----
drivers/net/phy/mdio_bus.c | 3 +
include/linux/acpi_mdio.h | 82 +++++++++
7 files changed, 369 insertions(+), 51 deletions(-)
create mode 100644 drivers/acpi/acpi_mdio.c
create mode 100644 include/linux/acpi_mdio.h
--
2.18.0
^ permalink raw reply
* [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Wang Dongsheng @ 2018-11-08 7:22 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <cover.1541660504.git.dongsheng.wang@hxt-semitech.com>
Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
The current implementation depend on mdio bus scan.
With _DSD device properties we can finally do this:
Device (MDIO) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@0", PHY0 }, }
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x0 }, }
})
}
Device (MACO) {
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
})
}
Documentations:
The DT "phy-handle" binding that we reuse for ACPI is documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt
Documentation/acpi/dsd/data-node-references.txt
Documentation/acpi/dsd/graph.txt
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
---
drivers/acpi/Kconfig | 6 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
drivers/net/phy/mdio_bus.c | 3 +
include/linux/acpi_mdio.h | 82 ++++++++++++++++++
5 files changed, 259 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 9705fc986da9..0fefa3410ce9 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
config ACPI_MCFG
bool
+config ACPI_MDIO
+ def_tristate PHYLIB
+ depends on PHYLIB
+ help
+ ACPI MDIO bus (Ethernet PHY) accessors
+
config ACPI_CPPC_LIB
bool
depends on ACPI_PROCESSOR
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 6d59aa109a91..ec7461a064fc 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,6 +41,7 @@ acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
+acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
acpi-y += acpi_lpss.o acpi_apd.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
new file mode 100644
index 000000000000..293bf9a63197
--- /dev/null
+++ b/drivers/acpi/acpi_mdio.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Lots of code in this file is copy from drivers/of/of_mdio.c
+// Copyright (c) 2018 Huaxintong Semiconductor Technology Co., Ltd.
+
+#include <linux/acpi.h>
+#include <linux/acpi_mdio.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/netdevice.h>
+#include <linux/err.h>
+#include <linux/phy.h>
+#include <linux/phy_fixed.h>
+
+/* Helper function for acpi_phy_find_device */
+static int phy_match(struct device *dev, void *fwnode)
+{
+ return dev->fwnode == fwnode;
+}
+
+/**
+ * acpi_phy_find_device - Give a PHY fwnode, find the phy_device
+ * @fwnode: Pointer to the phy's acpi data node
+ *
+ * If successful, returns a pointer to the phy_device with the embedded
+ * struct device refcount incremented by one, or NULL on failure.
+ */
+struct phy_device *acpi_phy_find_device(struct fwnode_handle *fwnode)
+{
+ struct device *d;
+ struct mdio_device *mdiodev;
+
+ if (!fwnode)
+ return NULL;
+
+ d = bus_find_device(&mdio_bus_type, NULL, fwnode, phy_match);
+ if (d) {
+ mdiodev = to_mdio_device(d);
+ if (mdiodev->flags & MDIO_DEVICE_FLAG_PHY)
+ return to_phy_device(d);
+ put_device(d);
+ }
+ return NULL;
+}
+EXPORT_SYMBOL(acpi_phy_find_device);
+
+static int do_acpi_mdiodev_match(struct fwnode_handle *fwnode,
+ struct mdio_device *mdiodev)
+{
+ struct device *dev = &mdiodev->dev;
+ struct fwnode_handle *child_node;
+ int addr;
+ int ret;
+
+ fwnode_for_each_child_node(fwnode, child_node) {
+ do {
+ addr = acpi_mdio_parse_addr(dev, child_node);
+ if (addr < 0)
+ break;
+
+ if (mdiodev->addr != addr)
+ break;
+
+ dev->fwnode = child_node;
+ return 0;
+ } while (0);
+
+ /* Walk hierarchical extension data nodes */
+ ret = do_acpi_mdiodev_match(child_node, mdiodev);
+ if (!ret)
+ return 0;
+ }
+
+ return -ENODEV;
+}
+
+/* Walk the list of subnodes of a mdio bus and look for a node that
+ * matches the mdio device's address with its 'reg' property. If
+ * found, set the fwnode pointer for the mdio device.
+ */
+void acpi_mdiobus_link_mdiodev(struct mii_bus *bus,
+ struct mdio_device *mdiodev)
+{
+ struct device *dev = &mdiodev->dev;
+
+ if (dev->fwnode || !bus->dev.fwnode)
+ return;
+
+ if (!has_acpi_companion(&bus->dev))
+ return;
+
+ do_acpi_mdiodev_match(bus->dev.fwnode, mdiodev);
+}
+
+/**
+ * acpi_phy_connect - Connect to the phy
+ * @dev: pointer to net_device claiming the phy
+ * @fwnode: Pointer to ACPI data node for the PHY
+ * @hndlr: Link state callback for the network device
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ *
+ * If successful, returns a pointer to the phy_device with the embedded
+ * struct device refcount incremented by one, or NULL on failure. The
+ * refcount must be dropped by calling phy_disconnect() or phy_detach().
+ */
+struct phy_device *acpi_phy_connect(struct net_device *dev,
+ struct fwnode_handle *fwnode,
+ void (*hndlr)(struct net_device *),
+ u32 flags,
+ phy_interface_t iface)
+{
+ struct phy_device *phy = acpi_phy_find_device(fwnode);
+ int ret;
+
+ if (!phy)
+ return NULL;
+
+ phy->dev_flags = flags;
+
+ ret = phy_connect_direct(dev, phy, hndlr, iface);
+
+ /* refcount is held by phy_connect_direct() on success */
+ put_device(&phy->mdio.dev);
+
+ return ret ? NULL : phy;
+}
+EXPORT_SYMBOL(acpi_phy_connect);
+
+static int acpi_mdio_node_verify(struct fwnode_handle *fwnode)
+{
+ return is_acpi_device_node(fwnode) ? 0 : -ENODEV;
+}
+
+static int fwnode_mdiobus_verify_node(struct fwnode_handle *fwnode)
+{
+ if (!is_acpi_node(fwnode))
+ return -ENODEV;
+ return acpi_mdio_node_verify(fwnode);
+}
+
+/**
+ * acpi_mdiobus_register - Register mii_bus and create PHYs
+ * @mdio: pointer to mii_bus structure
+ * @fwnode: pointer to fw_node of MDIO bus.
+ *
+ * This function registers the mii_bus structure and scan the phy_devices
+ * for each child node of @fwnode.
+ */
+int acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode)
+{
+ int ret;
+
+ if (!fwnode)
+ return mdiobus_register(mdio);
+
+ ret = fwnode_mdiobus_verify_node(fwnode);
+ if (ret)
+ return ret;
+
+ /* Scan PHYs on MDIO bus */
+ mdio->phy_mask = 0;
+ mdio->dev.fwnode = fwnode;
+
+ /* Register the MDIO bus */
+ return mdiobus_register(mdio);
+}
+EXPORT_SYMBOL(acpi_mdiobus_register);
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 2e59a8419b17..d7bca2145d0f 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -13,6 +13,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include <linux/acpi_mdio.h>
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/errno.h>
@@ -516,6 +517,8 @@ struct phy_device *mdiobus_scan(struct mii_bus *bus, int addr)
* in the bus node, and set the of_node pointer in this case.
*/
of_mdiobus_link_mdiodev(bus, &phydev->mdio);
+ /* Link the phy device with ACPI phy fwnode. */
+ acpi_mdiobus_link_mdiodev(bus, &phydev->mdio);
err = phy_device_register(phydev);
if (err) {
diff --git a/include/linux/acpi_mdio.h b/include/linux/acpi_mdio.h
new file mode 100644
index 000000000000..1a4a30258ebc
--- /dev/null
+++ b/include/linux/acpi_mdio.h
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+// Copyright (c) 2018 Huaxintong Semiconductor Technology Co., Ltd.
+
+#ifndef __LINUX_ACPI_MDIO_H
+#define __LINUX_ACPI_MDIO_H
+
+#include <linux/acpi.h>
+#include <linux/device.h>
+#include <linux/phy.h>
+#include <linux/property.h>
+
+#if IS_ENABLED(CONFIG_ACPI_MDIO)
+static inline int acpi_mdio_parse_addr(struct device *dev,
+ const struct fwnode_handle *fwnode)
+{
+ u32 addr;
+
+ if (!is_acpi_data_node(fwnode))
+ return -ENODEV;
+
+ if (!fwnode_property_present(fwnode, "reg"))
+ return -ENODEV;
+
+ if (fwnode_property_read_u32(fwnode, "reg", &addr)) {
+ dev_err(dev, "Invalid PHY address\n");
+ return -ENODEV;
+ }
+
+ /* A PHY must have a reg property in the range [0-31] */
+ if (addr >= PHY_MAX_ADDR) {
+ dev_err(dev, "PHY address %i is too large\n", addr);
+ return -EINVAL;
+ }
+
+ return addr;
+}
+
+struct phy_device *acpi_phy_find_device(struct fwnode_handle *fwnode);
+struct phy_device *acpi_phy_connect(struct net_device *dev,
+ struct fwnode_handle *fwnode,
+ void (*hndlr)(struct net_device *),
+ u32 flags, phy_interface_t iface);
+int acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode);
+void acpi_mdiobus_link_mdiodev(struct mii_bus *bus,
+ struct mdio_device *mdiodev);
+#else
+static inline int acpi_mdio_parse_addr(struct device *dev,
+ const struct fwnode_handle *fwnode)
+{
+ return -EINVAL;
+}
+
+static inline struct phy_device *
+acpi_phy_find_device(struct fwnode_handle *fwnode)
+{
+ return NULL;
+}
+
+static inline struct phy_device *
+acpi_phy_connect(struct net_device *dev, struct fwnode_handle *fwnode,
+ void (*hndlr)(struct net_device *), u32 flags,
+ phy_interface_t iface)
+{
+ return NULL;
+}
+
+static inline int acpi_mdiobus_register(struct mii_bus *mdio,
+ struct fwnode_handle *fwnode)
+{
+ return -ENODEV;
+}
+
+static inline void
+acpi_mdiobus_link_mdiodev(struct mii_bus *bus, struct mdio_device *mdiodev) { }
+#endif
+
+static inline struct fwnode_handle *acpi_get_phy_node(struct phy_device *phydev)
+{
+ return !phydev ? NULL : phydev->mdio.dev.fwnode;
+}
+
+#endif /* __LINUX_ACPI_MDIO_H */
--
2.18.0
^ permalink raw reply related
* [RFC PATCH 2/3] net: qcom/emac: split phy_config to mdio bus create and get phy device
From: Wang Dongsheng @ 2018-11-08 7:22 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <cover.1541660504.git.dongsheng.wang@hxt-semitech.com>
This patch separate emac_mdio_bus_create and emac_get_phydev from
emac_phy_config, and do some codes clean.
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
---
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 96 +++++++++++--------
1 file changed, 56 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index 53dbf1e163a8..8289fdda4be7 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -96,15 +96,15 @@ static int emac_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
return 0;
}
-/* Configure the MDIO bus and connect the external PHY */
-int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
+static int emac_mdio_bus_create(struct platform_device *pdev,
+ struct emac_adapter *adpt)
{
struct device_node *np = pdev->dev.of_node;
struct mii_bus *mii_bus;
int ret;
/* Create the mii_bus object for talking to the MDIO bus */
- adpt->mii_bus = mii_bus = devm_mdiobus_alloc(&pdev->dev);
+ mii_bus = devm_mdiobus_alloc(&pdev->dev);
if (!mii_bus)
return -ENOMEM;
@@ -115,50 +115,66 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
mii_bus->parent = &pdev->dev;
mii_bus->priv = adpt;
- if (has_acpi_companion(&pdev->dev)) {
- u32 phy_addr;
-
- ret = mdiobus_register(mii_bus);
- if (ret) {
- dev_err(&pdev->dev, "could not register mdio bus\n");
- return ret;
- }
- ret = device_property_read_u32(&pdev->dev, "phy-channel",
- &phy_addr);
- if (ret)
- /* If we can't read a valid phy address, then assume
- * that there is only one phy on this mdio bus.
- */
- adpt->phydev = phy_find_first(mii_bus);
- else
- adpt->phydev = mdiobus_get_phy(mii_bus, phy_addr);
-
- /* of_phy_find_device() claims a reference to the phydev,
- * so we do that here manually as well. When the driver
- * later unloads, it can unilaterally drop the reference
- * without worrying about ACPI vs DT.
- */
- if (adpt->phydev)
- get_device(&adpt->phydev->mdio.dev);
- } else {
- struct device_node *phy_np;
-
- ret = of_mdiobus_register(mii_bus, np);
- if (ret) {
- dev_err(&pdev->dev, "could not register mdio bus\n");
- return ret;
- }
+ ret = of_mdiobus_register(mii_bus, has_acpi_companion(&pdev->dev) ?
+ NULL : np);
+ if (ret)
+ dev_err(&pdev->dev, "Could not register mdio bus\n");
+
+ adpt->mii_bus = ret ? NULL : mii_bus;
+ return ret;
+}
+
+static int emac_get_phydev(struct platform_device *pdev,
+ struct emac_adapter *adpt)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct mii_bus *bus = adpt->mii_bus;
+ struct device_node *phy_np;
+ struct phy_device *phydev;
+ u32 phy_addr;
+ int ret;
+
+ if (!has_acpi_companion(&pdev->dev)) {
phy_np = of_parse_phandle(np, "phy-handle", 0);
adpt->phydev = of_phy_find_device(phy_np);
of_node_put(phy_np);
+ return adpt->phydev ? 0 : -ENODEV;
}
- if (!adpt->phydev) {
- dev_err(&pdev->dev, "could not find external phy\n");
- mdiobus_unregister(mii_bus);
+ ret = device_property_read_u32(&pdev->dev, "phy-channel",
+ &phy_addr);
+ /* If we can't read a valid phy address, then assume
+ * that there is only one phy on this mdio bus.
+ */
+ phydev = ret ? phy_find_first(bus) : mdiobus_get_phy(bus, phy_addr);
+ if (!phydev)
return -ENODEV;
- }
+ /* of_phy_find_device() claims a reference to the phydev,
+ * so we do that here manually as well. When the driver
+ * later unloads, it can unilaterally drop the reference
+ * without worrying about ACPI vs DT.
+ */
+ get_device(&phydev->mdio.dev);
+ adpt->phydev = phydev;
return 0;
}
+
+/* Configure the MDIO bus and connect the external PHY */
+int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
+{
+ int ret;
+
+ ret = emac_mdio_bus_create(pdev, adpt);
+ if (ret)
+ return ret;
+
+ ret = emac_get_phydev(pdev, adpt);
+ if (ret) {
+ dev_err(&pdev->dev, "Could not find external phy\n");
+ mdiobus_unregister(adpt->mii_bus);
+ }
+
+ return ret;
+}
--
2.18.0
^ permalink raw reply related
* [RFC PATCH 3/3] net: qcom/emac: add phy-handle support for ACPI
From: Wang Dongsheng @ 2018-11-08 7:22 UTC (permalink / raw)
To: andrew, timur
Cc: Wang Dongsheng, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <cover.1541660504.git.dongsheng.wang@hxt-semitech.com>
Use "phy-handle" to point to an internal MDIO device port.
Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
---
drivers/net/ethernet/qualcomm/emac/emac-mac.c | 19 ++---
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 78 ++++++++++++++-----
2 files changed, 70 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index 031f6e6ee9c1..74cfe7b95bb3 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -13,6 +13,7 @@
/* Qualcomm Technologies, Inc. EMAC Ethernet Controller MAC layer support
*/
+#include <linux/acpi_mdio.h>
#include <linux/tcp.h>
#include <linux/ip.h>
#include <linux/ipv6.h>
@@ -939,28 +940,28 @@ static void emac_adjust_link(struct net_device *netdev)
int emac_mac_up(struct emac_adapter *adpt)
{
struct net_device *netdev = adpt->netdev;
- int ret;
+ struct phy_device *phydev = adpt->phydev;
+ struct fwnode_handle *phy_np = acpi_get_phy_node(phydev);
emac_mac_rx_tx_ring_reset_all(adpt);
emac_mac_config(adpt);
emac_mac_rx_descs_refill(adpt, &adpt->rx_q);
- adpt->phydev->irq = PHY_POLL;
- ret = phy_connect_direct(netdev, adpt->phydev, emac_adjust_link,
- PHY_INTERFACE_MODE_SGMII);
- if (ret) {
+ phydev->irq = PHY_POLL;
+ phydev = acpi_phy_connect(netdev, phy_np, emac_adjust_link,
+ 0, PHY_INTERFACE_MODE_SGMII);
+ if (!phydev) {
netdev_err(adpt->netdev, "could not connect phy\n");
- return ret;
+ return -ENODEV;
}
- phy_attached_print(adpt->phydev, NULL);
+ phy_attached_print(phydev, NULL);
/* enable mac irq */
writel((u32)~DIS_INT, adpt->base + EMAC_INT_STATUS);
writel(adpt->irq.mask, adpt->base + EMAC_INT_MASK);
- phy_start(adpt->phydev);
-
+ phy_start(phydev);
napi_enable(&adpt->rx_q.napi);
netif_start_queue(netdev);
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index 8289fdda4be7..6616014292b0 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -17,6 +17,7 @@
#include <linux/phy.h>
#include <linux/iopoll.h>
#include <linux/acpi.h>
+#include <linux/acpi_mdio.h>
#include "emac.h"
/* EMAC base register offsets */
@@ -96,10 +97,60 @@ static int emac_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
return 0;
}
+static struct phy_device *
+emac_acpi_get_phydev_from_phy_handle(struct platform_device *pdev)
+{
+ struct fwnode_reference_args args = {0};
+ struct fwnode_handle *fw_node;
+ struct phy_device *phydev;
+ int ret;
+
+ /* Get PHY Port reference from phy-handle */
+ fw_node = acpi_fwnode_handle(ACPI_COMPANION(&pdev->dev));
+ ret = acpi_node_get_property_reference(fw_node, "phy-handle", 0,
+ &args);
+ if (ret)
+ return ERR_PTR(-ENODEV);
+
+ if (!is_acpi_data_node(args.fwnode))
+ return ERR_PTR(-ENODEV);
+
+ phydev = acpi_phy_find_device(args.fwnode);
+ return phydev ? phydev : ERR_PTR(-ENODEV);
+}
+
+static struct phy_device *
+emac_acpi_get_phydev(struct platform_device *pdev, struct emac_adapter *adpt)
+{
+ struct phy_device *phydev = NULL;
+ int phy_addr;
+ int ret;
+
+ /* Compatible with "phy-channel" */
+ ret = device_property_read_u32(&pdev->dev, "phy-channel",
+ &phy_addr);
+ if (!ret)
+ phydev = mdiobus_get_phy(adpt->mii_bus, phy_addr);
+ if (phydev)
+ return phydev;
+
+ /* Get PHY Port reference from phy-handle */
+ phydev = emac_acpi_get_phydev_from_phy_handle(pdev);
+ if (!IS_ERR(phydev))
+ return phydev;
+
+ /* If we can't read a valid phy address from "phy-channel"/"phy-handle",
+ * then assume that there is only one phy on local mdio bus.
+ */
+ phydev = phy_find_first(adpt->mii_bus);
+ return phydev ? phydev : ERR_PTR(-ENODEV);
+}
+
static int emac_mdio_bus_create(struct platform_device *pdev,
struct emac_adapter *adpt)
{
struct device_node *np = pdev->dev.of_node;
+ struct fwnode_handle *fwnode = pdev->dev.fwnode;
struct mii_bus *mii_bus;
int ret;
@@ -115,8 +166,8 @@ static int emac_mdio_bus_create(struct platform_device *pdev,
mii_bus->parent = &pdev->dev;
mii_bus->priv = adpt;
- ret = of_mdiobus_register(mii_bus, has_acpi_companion(&pdev->dev) ?
- NULL : np);
+ ret = is_of_node(fwnode) ? of_mdiobus_register(mii_bus, np) :
+ acpi_mdiobus_register(mii_bus, fwnode);
if (ret)
dev_err(&pdev->dev, "Could not register mdio bus\n");
@@ -128,13 +179,9 @@ static int emac_get_phydev(struct platform_device *pdev,
struct emac_adapter *adpt)
{
struct device_node *np = pdev->dev.of_node;
- struct mii_bus *bus = adpt->mii_bus;
struct device_node *phy_np;
struct phy_device *phydev;
- u32 phy_addr;
- int ret;
-
if (!has_acpi_companion(&pdev->dev)) {
phy_np = of_parse_phandle(np, "phy-handle", 0);
adpt->phydev = of_phy_find_device(phy_np);
@@ -142,14 +189,9 @@ static int emac_get_phydev(struct platform_device *pdev,
return adpt->phydev ? 0 : -ENODEV;
}
- ret = device_property_read_u32(&pdev->dev, "phy-channel",
- &phy_addr);
- /* If we can't read a valid phy address, then assume
- * that there is only one phy on this mdio bus.
- */
- phydev = ret ? phy_find_first(bus) : mdiobus_get_phy(bus, phy_addr);
- if (!phydev)
- return -ENODEV;
+ phydev = emac_acpi_get_phydev(pdev, adpt);
+ if (IS_ERR(phydev))
+ return PTR_ERR(phydev);
/* of_phy_find_device() claims a reference to the phydev,
* so we do that here manually as well. When the driver
@@ -171,10 +213,10 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
return ret;
ret = emac_get_phydev(pdev, adpt);
- if (ret) {
- dev_err(&pdev->dev, "Could not find external phy\n");
- mdiobus_unregister(adpt->mii_bus);
- }
+ if (!ret)
+ return 0;
+ dev_err(&pdev->dev, "Could not find external phy\n");
+ mdiobus_unregister(adpt->mii_bus);
return ret;
}
--
2.18.0
^ permalink raw reply related
* Re: [PATCH net] ipv6/mcast: update mc_qrv when join new group
From: Hangbin Liu @ 2018-11-08 7:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1540521054-17825-1-git-send-email-liuhangbin@gmail.com>
On Fri, Oct 26, 2018 at 10:30:54AM +0800, Hangbin Liu wrote:
> Currently we only set mc_qrv to sysctl_mld_qrv when interface up. If we
> change sysctl_mld_qrv after interface up, it will has no effect.
>
> Fix it by assigning latest sysctl_mld_qrv to idev mc_qrv when join new group.
>
> Reported-by: Ying Xu <yinxu@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Hi David,
Any comments for this patch?
Thanks
Hangbin
> ---
> net/ipv6/mcast.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> index dbab62e..bed4890 100644
> --- a/net/ipv6/mcast.c
> +++ b/net/ipv6/mcast.c
> @@ -680,6 +680,7 @@ static void igmp6_group_added(struct ifmcaddr6 *mc)
> if (!(dev->flags & IFF_UP) || (mc->mca_flags & MAF_NOREPORT))
> return;
>
> + mc->idev->mc_qrv = sysctl_mld_qrv;
> if (mld_in_v1_mode(mc->idev)) {
> igmp6_join_group(mc);
> return;
> --
> 2.5.5
>
^ permalink raw reply
* Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Rafael J. Wysocki @ 2018-11-08 7:45 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: andrew, timur, yu.zheng, f.fainelli, linux-acpi, netdev
In-Reply-To: <2bf82b60c52bd3fc38b733e38fd991c9d31af6b9.1541660504.git.dongsheng.wang@hxt-semitech.com>
On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
> The current implementation depend on mdio bus scan.
> With _DSD device properties we can finally do this:
>
> Device (MDIO) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> })
> Name (PHY0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x0 }, }
> })
> }
>
> Device (MACO) {
> Name (_DSD, Package () {
> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
> })
> }
>
> Documentations:
> The DT "phy-handle" binding that we reuse for ACPI is documented in
> Documentation/devicetree/bindings/phy/phy-bindings.txt
>
> Documentation/acpi/dsd/data-node-references.txt
> Documentation/acpi/dsd/graph.txt
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
> ---
> drivers/acpi/Kconfig | 6 ++
> drivers/acpi/Makefile | 1 +
> drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
> drivers/net/phy/mdio_bus.c | 3 +
> include/linux/acpi_mdio.h | 82 ++++++++++++++++++
> 5 files changed, 259 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 9705fc986da9..0fefa3410ce9 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
> config ACPI_MCFG
> bool
>
> +config ACPI_MDIO
> + def_tristate PHYLIB
> + depends on PHYLIB
> + help
> + ACPI MDIO bus (Ethernet PHY) accessors
> +
> config ACPI_CPPC_LIB
> bool
> depends on ACPI_PROCESSOR
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 6d59aa109a91..ec7461a064fc 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -41,6 +41,7 @@ acpi-y += ec.o
> acpi-$(CONFIG_ACPI_DOCK) += dock.o
> acpi-y += pci_root.o pci_link.o pci_irq.o
> obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
> +acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
> acpi-y += acpi_lpss.o acpi_apd.o
> acpi-y += acpi_platform.o
> acpi-y += acpi_pnp.o
> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
> new file mode 100644
> index 000000000000..293bf9a63197
> --- /dev/null
> +++ b/drivers/acpi/acpi_mdio.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Lots of code in this file is copy from drivers/of/of_mdio.c
Would it be possible to re-factor that code and share it instead?
Thanks,
Rafael
^ permalink raw reply
* Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Wang, Dongsheng @ 2018-11-08 7:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: andrew@lunn.ch, timur@kernel.org, Zheng, Joey,
f.fainelli@gmail.com, linux-acpi@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <2150057.QtixCRFV9x@aspire.rjw.lan>
On 2018/11/8 15:44, Rafael J. Wysocki wrote:
> On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
>> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
>> The current implementation depend on mdio bus scan.
>> With _DSD device properties we can finally do this:
>>
>> Device (MDIO) {
>> Name (_DSD, Package () {
>> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
>> Package () { Package () { "ethernet-phy@0", PHY0 }, }
>> })
>> Name (PHY0, Package() {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () { "reg", 0x0 }, }
>> })
>> }
>>
>> Device (MACO) {
>> Name (_DSD, Package () {
>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
>> })
>> }
>>
>> Documentations:
>> The DT "phy-handle" binding that we reuse for ACPI is documented in
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Documentation/acpi/dsd/data-node-references.txt
>> Documentation/acpi/dsd/graph.txt
>>
>> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
>> ---
>> drivers/acpi/Kconfig | 6 ++
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
>> drivers/net/phy/mdio_bus.c | 3 +
>> include/linux/acpi_mdio.h | 82 ++++++++++++++++++
>> 5 files changed, 259 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 9705fc986da9..0fefa3410ce9 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
>> config ACPI_MCFG
>> bool
>>
>> +config ACPI_MDIO
>> + def_tristate PHYLIB
>> + depends on PHYLIB
>> + help
>> + ACPI MDIO bus (Ethernet PHY) accessors
>> +
>> config ACPI_CPPC_LIB
>> bool
>> depends on ACPI_PROCESSOR
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 6d59aa109a91..ec7461a064fc 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -41,6 +41,7 @@ acpi-y += ec.o
>> acpi-$(CONFIG_ACPI_DOCK) += dock.o
>> acpi-y += pci_root.o pci_link.o pci_irq.o
>> obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
>> +acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
>> acpi-y += acpi_lpss.o acpi_apd.o
>> acpi-y += acpi_platform.o
>> acpi-y += acpi_pnp.o
>> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
>> new file mode 100644
>> index 000000000000..293bf9a63197
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_mdio.c
>> @@ -0,0 +1,167 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +// Lots of code in this file is copy from drivers/of/of_mdio.c
> Would it be possible to re-factor that code and share it instead?
I thought about it, we can actually do it with fwnode.
But I don't have a lot of concentrate to do this. I'm going to focus on
a few other things...:(
Maybe in the second half of 2019 I can re-factor them if there is no one
re-factor them.
Cheers,
Dongsheng
> Thanks,
> Rafael
>
>
^ permalink raw reply
* RE:(2) (2) (2) [Kernel][NET] Bug report on packet defragmenting
From: 배석진 @ 2018-11-08 7:58 UTC (permalink / raw)
To: Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <b03af88f-8f18-bdac-ae64-c3c0688008d3@gmail.com>
>--------- Original Message ---------
>Sender : Eric Dumazet <eric.dumazet@gmail.com>
>Date : 2018-11-08 15:13 (GMT+9)
>Title : Re: (2) (2) [Kernel][NET] Bug report on packet defragmenting
>
>On 11/07/2018 08:26 PM, Eric Dumazet wrote:
>>
>>
>> On 11/07/2018 08:10 PM, 배석진 wrote:
>>>> --------- Original Message ---------
>>>> Sender : Eric Dumazet <eric.dumazet@gmail.com>
>>>> Date : 2018-11-08 12:57 (GMT+9)
>>>> Title : Re: (2) [Kernel][NET] Bug report on packet defragmenting
>>>>
>>>> On 11/07/2018 07:24 PM, Eric Dumazet wrote:
>>>>
>>>>> Sure, it is better if RPS is smarter, but if there is a bug in IPv6 defrag unit
>>>>> we must investigate and root-cause it.
>>>>
>>>> BTW, IPv4 defrag seems to have the same issue.
>>>
>>>
>>> yes, it could be.
>>> key point isn't limitted to ipv6.
>>>
>>> maybe because of faster air-network and modem,
>>> it looks like occure more often and we got recognized that.
>>>
>>> anyway,
>>> we'll apply our patch to resolve this problem.
>>
>> Yeah, and I will fix the defrag units.
>>
>> We can not rely on other layers doing proper no-reorder logic for us.
>>
>> Problem here is that multiple cpus attempt concurrent rhashtable_insert_fast()
>> and do not properly recover in case -EEXIST is returned.
>>
>> This is silly, of course :/
>
>Patch would be https://patchwork.ozlabs.org/patch/994658/
Dear Dumazet,
with your patch, kernel got the panic when packet recieved.
I double checked after disable your patch, then no problem.
<6>[ 119.702054] I[3: kworker/u18:1: 1705] LNK-RX(1464): 6b 80 00 00 05 90 2c 3e 20 01 44 30 00 05 04 01 ...
<6>[ 119.702120] I[3: kworker/u18:1: 1705] __skb_flow_dissect: ports: 77500000
<6>[ 119.702153] I[3: kworker/u18:1: 1705] get_rps_cpu: cpu:2, hash:2055028308
<6>[ 119.702203] I[3: kworker/u18:1: 1705] LNK-RX(1212): 6b 80 00 00 04 94 2c 3e 20 01 44 30 00 05 04 01 ...
<6>[ 119.702231] I[3: kworker/u18:1: 1705] __skb_flow_dissect: ports: 3c7e2c6b
<6>[ 119.702258] I[3: kworker/u18:1: 1705] get_rps_cpu: cpu:1, hash:671343869
<6>[ 119.702365] I[1: Binder:11369_2:11382] ipv6_rcv +++
<6>[ 119.702375] I[2: swapper/2: 0] ipv6_rcv +++
<6>[ 119.702406] I[2: swapper/2: 0] ipv6_defrag +++
<6>[ 119.702425] I[1: Binder:11369_2:11382] ipv6_defrag +++
<6>[ 119.702494] I[2: swapper/2: 0] ipv6_defrag: EINPROGRESS
<6>[ 119.702522] I[2: swapper/2: 0] ipv6_rcv ---
<6>[ 119.702628] I[1: Binder:11369_2:11382] ipv6_defrag ---
<6>[ 119.702892] I[1: Binder:11369_2:11382] ipv6_defrag +++
<6>[ 119.702922] I[1: Binder:11369_2:11382] ipv6_defrag ---
<6>[ 119.702966] I[1: Binder:11369_2:11382] ipv6_rcv ---
<0>[ 119.703792] [1: Binder:11369_2:11382] BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:518
<3>[ 119.703826] [1: Binder:11369_2:11382] in_atomic(): 0, irqs_disabled(): 0, pid: 11382, name: Binder:11369_2
<3>[ 119.703854] [1: Binder:11369_2:11382] Preemption disabled at:
<4>[ 119.703888] [1: Binder:11369_2:11382] [<ffffff80080b13d4>] __do_softirq+0x68/0x3c4
<4>[ 119.703934] [1: Binder:11369_2:11382] CPU: 1 PID: 11382 Comm: Binder:11369_2 Tainted: G S W 4.14.75-20181108-163447-eng #0
<4>[ 119.703960] [1: Binder:11369_2:11382] Hardware name: Samsung BEYOND2LTE KOR SINGLE 19 board based on EXYNOS9820 (DT)
<4>[ 119.703987] [1: Binder:11369_2:11382] Call trace:
<4>[ 119.704015] [1: Binder:11369_2:11382] [<ffffff80080bd87c>] dump_backtrace+0x0/0x280
<4>[ 119.704045] [1: Binder:11369_2:11382] [<ffffff80080bddd4>] show_stack+0x18/0x24
<4>[ 119.704074] [1: Binder:11369_2:11382] [<ffffff80090bb3f8>] dump_stack+0xb8/0xf8
<4>[ 119.704104] [1: Binder:11369_2:11382] [<ffffff800811f180>] ___might_sleep+0x16c/0x178
<4>[ 119.704132] [1: Binder:11369_2:11382] [<ffffff800811efdc>] __might_sleep+0x4c/0x84
<4>[ 119.704164] [1: Binder:11369_2:11382] [<ffffff80090dcf60>] do_page_fault+0x2e8/0x4b8
<4>[ 119.704193] [1: Binder:11369_2:11382] [<ffffff80090dcbf4>] do_translation_fault+0x7c/0x100
<4>[ 119.704219] [1: Binder:11369_2:11382] [<ffffff80080b0d70>] do_mem_abort+0x4c/0x12c
<4>[ 119.704243] [1: Binder:11369_2:11382] Exception stack(0xffffff8038bf3ec0 to 0xffffff8038bf4000)
<4>[ 119.704266] [1: Binder:11369_2:11382] 3ec0: 00000077b8262600 00000077b1bd0800 00000000708fcae0 0000000000000018
...
<4>[ 119.704459] [1: Binder:11369_2:11382] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
<4>[ 119.704480] [1: Binder:11369_2:11382] [<ffffff80080b33d0>] el0_da+0x20/0x24
<4>[ 119.704509] [1: Binder:11369_2:11382] ------------[ cut here ]------------
<0>[ 119.704541] [1: Binder:11369_2:11382] kernel BUG at kernel/sched/core.c:6152!
<2>[ 119.704563] [1: Binder:11369_2:11382] sec_debug_set_extra_info_fault = BUG / 0xffffff800811f180
<0>[ 119.704603] [1: Binder:11369_2:11382] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
^ permalink raw reply
* Re: [RFC PATCH 1/3] acpi: Add acpi mdio support code
From: Rafael J. Wysocki @ 2018-11-08 8:01 UTC (permalink / raw)
To: Wang, Dongsheng
Cc: andrew@lunn.ch, timur@kernel.org, Zheng, Joey,
f.fainelli@gmail.com, linux-acpi@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <ad8eaa316b15403fa7f0b8f79d744331@HXTBJIDCEMVIW02.hxtcorp.net>
On Thursday, November 8, 2018 8:55:47 AM CET Wang, Dongsheng wrote:
> On 2018/11/8 15:44, Rafael J. Wysocki wrote:
> > On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
> >> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
> >> The current implementation depend on mdio bus scan.
> >> With _DSD device properties we can finally do this:
> >>
> >> Device (MDIO) {
> >> Name (_DSD, Package () {
> >> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> >> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> >> })
> >> Name (PHY0, Package() {
> >> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >> Package () { Package () { "reg", 0x0 }, }
> >> })
> >> }
> >>
> >> Device (MACO) {
> >> Name (_DSD, Package () {
> >> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >> Package () { Package () { "phy-handle", \_SB.MDIO, "ethernet-phy@0" }, }
> >> })
> >> }
> >>
> >> Documentations:
> >> The DT "phy-handle" binding that we reuse for ACPI is documented in
> >> Documentation/devicetree/bindings/phy/phy-bindings.txt
> >>
> >> Documentation/acpi/dsd/data-node-references.txt
> >> Documentation/acpi/dsd/graph.txt
> >>
> >> Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com>
> >> ---
> >> drivers/acpi/Kconfig | 6 ++
> >> drivers/acpi/Makefile | 1 +
> >> drivers/acpi/acpi_mdio.c | 167 +++++++++++++++++++++++++++++++++++++
> >> drivers/net/phy/mdio_bus.c | 3 +
> >> include/linux/acpi_mdio.h | 82 ++++++++++++++++++
> >> 5 files changed, 259 insertions(+)
> >>
> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> >> index 9705fc986da9..0fefa3410ce9 100644
> >> --- a/drivers/acpi/Kconfig
> >> +++ b/drivers/acpi/Kconfig
> >> @@ -252,6 +252,12 @@ config ACPI_PROCESSOR_IDLE
> >> config ACPI_MCFG
> >> bool
> >>
> >> +config ACPI_MDIO
> >> + def_tristate PHYLIB
> >> + depends on PHYLIB
> >> + help
> >> + ACPI MDIO bus (Ethernet PHY) accessors
> >> +
> >> config ACPI_CPPC_LIB
> >> bool
> >> depends on ACPI_PROCESSOR
> >> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> >> index 6d59aa109a91..ec7461a064fc 100644
> >> --- a/drivers/acpi/Makefile
> >> +++ b/drivers/acpi/Makefile
> >> @@ -41,6 +41,7 @@ acpi-y += ec.o
> >> acpi-$(CONFIG_ACPI_DOCK) += dock.o
> >> acpi-y += pci_root.o pci_link.o pci_irq.o
> >> obj-$(CONFIG_ACPI_MCFG) += pci_mcfg.o
> >> +acpi-$(CONFIG_ACPI_MDIO) += acpi_mdio.o
> >> acpi-y += acpi_lpss.o acpi_apd.o
> >> acpi-y += acpi_platform.o
> >> acpi-y += acpi_pnp.o
> >> diff --git a/drivers/acpi/acpi_mdio.c b/drivers/acpi/acpi_mdio.c
> >> new file mode 100644
> >> index 000000000000..293bf9a63197
> >> --- /dev/null
> >> +++ b/drivers/acpi/acpi_mdio.c
> >> @@ -0,0 +1,167 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +// Lots of code in this file is copy from drivers/of/of_mdio.c
> > Would it be possible to re-factor that code and share it instead?
>
> I thought about it, we can actually do it with fwnode.
>
> But I don't have a lot of concentrate to do this. I'm going to focus on
> a few other things...:(
>
> Maybe in the second half of 2019 I can re-factor them if there is no one
> re-factor them.
Well, I'd rather avoid code duplication upfront if possible.
Thanks,
Rafael
^ permalink raw reply
* [PATCHv2] net: stmmac: Fix RX packet size > 8191
From: thor.thayer @ 2018-11-08 17:39 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, davem
Cc: netdev, linux-kernel, Thor Thayer
From: Thor Thayer <thor.thayer@linux.intel.com>
Ping problems with packets > 8191 as shown:
PING 192.168.1.99 (192.168.1.99) 8150(8178) bytes of data.
8158 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=0.669 ms
wrong data byte 8144 should be 0xd0 but was 0x0
16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
%< ---------------snip--------------------------------------
8112 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
8144 0 0 0 0 d0 d1
^^^^^^^
Notice the 4 bytes of 0 before the expected byte of d0.
Databook notes that the RX buffer must be a multiple of 4/8/16
bytes [1].
Update the DMA Buffer size define to 8188 instead of 8192. Remove
the -1 from the RX buffer size allocations and use the new
DMA Buffer size directly.
[1] Synopsys DesignWare Cores Ethernet MAC Universal v3.70a
[section 8.4.2 - Table 8-24]
Tested on SoCFPGA Stratix10 with ping sweep from 100 to 8300 byte packets.
Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)")
Suggested-by: Jose Abreu <jose.abreu@synopsys.com>
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
v2 Change BUF_SIZE_8KiB directly instead of separate define in RFT.
---
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/descs_com.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index b1b305f8f414..272b9ca66314 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -365,7 +365,8 @@ struct dma_features {
/* GMAC TX FIFO is 8K, Rx FIFO is 16K */
#define BUF_SIZE_16KiB 16384
-#define BUF_SIZE_8KiB 8192
+/* RX Buffer size must be < 8191 and multiple of 4/8/16 bytes */
+#define BUF_SIZE_8KiB 8188
#define BUF_SIZE_4KiB 4096
#define BUF_SIZE_2KiB 2048
diff --git a/drivers/net/ethernet/stmicro/stmmac/descs_com.h b/drivers/net/ethernet/stmicro/stmmac/descs_com.h
index ca9d7e48034c..40d6356a7e73 100644
--- a/drivers/net/ethernet/stmicro/stmmac/descs_com.h
+++ b/drivers/net/ethernet/stmicro/stmmac/descs_com.h
@@ -31,7 +31,7 @@
/* Enhanced descriptors */
static inline void ehn_desc_rx_set_on_ring(struct dma_desc *p, int end)
{
- p->des1 |= cpu_to_le32(((BUF_SIZE_8KiB - 1)
+ p->des1 |= cpu_to_le32((BUF_SIZE_8KiB
<< ERDES1_BUFFER2_SIZE_SHIFT)
& ERDES1_BUFFER2_SIZE_MASK);
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 77914c89d749..5ef91a790f9d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -262,7 +262,7 @@ static void enh_desc_init_rx_desc(struct dma_desc *p, int disable_rx_ic,
int mode, int end)
{
p->des0 |= cpu_to_le32(RDES0_OWN);
- p->des1 |= cpu_to_le32((BUF_SIZE_8KiB - 1) & ERDES1_BUFFER1_SIZE_MASK);
+ p->des1 |= cpu_to_le32(BUF_SIZE_8KiB & ERDES1_BUFFER1_SIZE_MASK);
if (mode == STMMAC_CHAIN_MODE)
ehn_desc_rx_set_on_chain(p);
diff --git a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
index abc3f85270cd..d8c5bc412219 100644
--- a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
@@ -140,7 +140,7 @@ static void clean_desc3(void *priv_ptr, struct dma_desc *p)
static int set_16kib_bfsize(int mtu)
{
int ret = 0;
- if (unlikely(mtu >= BUF_SIZE_8KiB))
+ if (unlikely(mtu > BUF_SIZE_8KiB))
ret = BUF_SIZE_16KiB;
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCHv2] net: stmmac: Fix RX packet size > 8191
From: thor.thayer @ 2018-11-08 17:42 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, davem
Cc: netdev, linux-kernel, Thor Thayer
From: Thor Thayer <thor.thayer@linux.intel.com>
Ping problems with packets > 8191 as shown:
PING 192.168.1.99 (192.168.1.99) 8150(8178) bytes of data.
8158 bytes from 192.168.1.99: icmp_seq=1 ttl=64 time=0.669 ms
wrong data byte 8144 should be 0xd0 but was 0x0
16 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
%< ---------------snip--------------------------------------
8112 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf
c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf
8144 0 0 0 0 d0 d1
^^^^^^^
Notice the 4 bytes of 0 before the expected byte of d0.
Databook notes that the RX buffer must be a multiple of 4/8/16
bytes [1].
Update the DMA Buffer size define to 8188 instead of 8192. Remove
the -1 from the RX buffer size allocations and use the new
DMA Buffer size directly.
[1] Synopsys DesignWare Cores Ethernet MAC Universal v3.70a
[section 8.4.2 - Table 8-24]
Tested on SoCFPGA Stratix10 with ping sweep from 100 to 8300 byte packets.
Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)")
Suggested-by: Jose Abreu <jose.abreu@synopsys.com>
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
---
v2 Change BUF_SIZE_8KiB directly instead of separate define in RFT.
---
drivers/net/ethernet/stmicro/stmmac/common.h | 3 ++-
drivers/net/ethernet/stmicro/stmmac/descs_com.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/ring_mode.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index b1b305f8f414..272b9ca66314 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -365,7 +365,8 @@ struct dma_features {
/* GMAC TX FIFO is 8K, Rx FIFO is 16K */
#define BUF_SIZE_16KiB 16384
-#define BUF_SIZE_8KiB 8192
+/* RX Buffer size must be < 8191 and multiple of 4/8/16 bytes */
+#define BUF_SIZE_8KiB 8188
#define BUF_SIZE_4KiB 4096
#define BUF_SIZE_2KiB 2048
diff --git a/drivers/net/ethernet/stmicro/stmmac/descs_com.h b/drivers/net/ethernet/stmicro/stmmac/descs_com.h
index ca9d7e48034c..40d6356a7e73 100644
--- a/drivers/net/ethernet/stmicro/stmmac/descs_com.h
+++ b/drivers/net/ethernet/stmicro/stmmac/descs_com.h
@@ -31,7 +31,7 @@
/* Enhanced descriptors */
static inline void ehn_desc_rx_set_on_ring(struct dma_desc *p, int end)
{
- p->des1 |= cpu_to_le32(((BUF_SIZE_8KiB - 1)
+ p->des1 |= cpu_to_le32((BUF_SIZE_8KiB
<< ERDES1_BUFFER2_SIZE_SHIFT)
& ERDES1_BUFFER2_SIZE_MASK);
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 77914c89d749..5ef91a790f9d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -262,7 +262,7 @@ static void enh_desc_init_rx_desc(struct dma_desc *p, int disable_rx_ic,
int mode, int end)
{
p->des0 |= cpu_to_le32(RDES0_OWN);
- p->des1 |= cpu_to_le32((BUF_SIZE_8KiB - 1) & ERDES1_BUFFER1_SIZE_MASK);
+ p->des1 |= cpu_to_le32(BUF_SIZE_8KiB & ERDES1_BUFFER1_SIZE_MASK);
if (mode == STMMAC_CHAIN_MODE)
ehn_desc_rx_set_on_chain(p);
diff --git a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
index abc3f85270cd..d8c5bc412219 100644
--- a/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
+++ b/drivers/net/ethernet/stmicro/stmmac/ring_mode.c
@@ -140,7 +140,7 @@ static void clean_desc3(void *priv_ptr, struct dma_desc *p)
static int set_16kib_bfsize(int mtu)
{
int ret = 0;
- if (unlikely(mtu >= BUF_SIZE_8KiB))
+ if (unlikely(mtu > BUF_SIZE_8KiB))
ret = BUF_SIZE_16KiB;
return ret;
}
--
2.7.4
^ permalink raw reply related
* a propose of snmp counter document
From: peng yu @ 2018-11-08 8:08 UTC (permalink / raw)
To: netdev
I'm planing to write a document which explains the meaning of the
kernel snmp counters, and combine the explanations with some tests,
because I found lots of the 'TcpExt' and 'IpExt' counters are not
explained in any document. Here is a draft:
https://github.com/yupeng0921/iproute2_learning/blob/master/nstat.md
It is still on going. I think it might be useful. Besides put it on my
git repo, could someone have any suggestion about any place I
could contribute this document to?
Best regards
^ permalink raw reply
* Re: [PATCH net] ipv6/mcast: update mc_qrv when join new group
From: David Miller @ 2018-11-08 8:12 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev
In-Reply-To: <20181108074410.GO24677@leo.usersys.redhat.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Thu, 8 Nov 2018 15:44:10 +0800
> On Fri, Oct 26, 2018 at 10:30:54AM +0800, Hangbin Liu wrote:
>> Currently we only set mc_qrv to sysctl_mld_qrv when interface up. If we
>> change sysctl_mld_qrv after interface up, it will has no effect.
>>
>> Fix it by assigning latest sysctl_mld_qrv to idev mc_qrv when join new group.
>>
>> Reported-by: Ying Xu <yinxu@redhat.com>
>> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
>
> Hi David,
>
> Any comments for this patch?
I did give you feedback and you never responded:
https://patchwork.ozlabs.org/patch/989422/
So I tossed your patch.
^ permalink raw reply
* [PATCH] net: phy: leds: Don't make our own link speed names
From: Kyle Roeschley @ 2018-11-08 17:51 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli
Cc: David S . Miller, netdev, linux-kernel, Kyle Roeschley
The phy core provides a handy phy_speed_to_str() helper, so use that
instead of doing our own formatting of the different known link speeds.
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
drivers/net/phy/phy_led_triggers.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
index 491efc1bf5c4..2827eb413c9c 100644
--- a/drivers/net/phy/phy_led_triggers.c
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -77,20 +77,9 @@ static int phy_led_trigger_register(struct phy_device *phy,
struct phy_led_trigger *plt,
unsigned int speed)
{
- char name_suffix[PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE];
-
plt->speed = speed;
-
- if (speed < SPEED_1000)
- snprintf(name_suffix, sizeof(name_suffix), "%dMbps", speed);
- else if (speed == SPEED_2500)
- snprintf(name_suffix, sizeof(name_suffix), "2.5Gbps");
- else
- snprintf(name_suffix, sizeof(name_suffix), "%dGbps",
- DIV_ROUND_CLOSEST(speed, 1000));
-
phy_led_trigger_format_name(phy, plt->name, sizeof(plt->name),
- name_suffix);
+ phy_speed_to_str(speed));
plt->trigger.name = plt->name;
return led_trigger_register(&plt->trigger);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH 2/5] VSOCK: support fill data to mergeable rx buffer in host
From: Jason Wang @ 2018-11-08 8:20 UTC (permalink / raw)
To: jiangyiwen, stefanha, stefanha
Cc: netdev, kvm, virtualization, Michael S. Tsirkin
In-Reply-To: <5BE397CA.5060000@huawei.com>
On 2018/11/8 上午9:56, jiangyiwen wrote:
> On 2018/11/7 21:32, Jason Wang wrote:
>> On 2018/11/7 下午3:11, jiangyiwen wrote:
>>> On 2018/11/7 14:18, Jason Wang wrote:
>>>> On 2018/11/6 下午2:30, jiangyiwen wrote:
>>>>>> Seems duplicated with the one used by vhost-net.
>>>>>>
>>>>>> In packed virtqueue implementation, I plan to move this to vhost.c.
>>>>>>
>>>>> Yes, this code is full copied from vhost-net, if it can be packed into
>>>>> vhost.c, it would be great.
>>>>>
>>>> If you try to reuse vhost-net, you don't even need to care about this:)
>>>>
>>>> Thanks
>>>>
>>>>
>>>> .
>>>>
>>> Hi Jason,
>>>
>>> Thank your advice, I will consider your idea. But I don't know
>>> what's stefan's suggestion? It seems that he doesn't care much
>>> about this community.:(
>> I think not. He is probably busy these days.
>>
>>
>>> I still hope this community can have some vitality.
>>>
>> Let's wait for few more days for the possible comments from Stefan or Michael. But I do prefer to unify the virtio networking datapath which will be easier to be extended and maintained.
>>
>> Thanks
>>
>>
>> .
>>
> Hi Jason,
>
> Actually vsock use virtio-net as transport path should be a better idea,
> I will try to consider the new idea.
>
> Thanks,
> Yiwen.
>
Good to know this and thanks!
^ permalink raw reply
* Re: [PATCH] net: phy: leds: Don't make our own link speed names
From: Florian Fainelli @ 2018-11-08 17:59 UTC (permalink / raw)
To: Kyle Roeschley, Andrew Lunn; +Cc: David S . Miller, netdev, linux-kernel
In-Reply-To: <20181108175106.25684-1-kyle.roeschley@ni.com>
On 11/8/18 9:51 AM, Kyle Roeschley wrote:
> The phy core provides a handy phy_speed_to_str() helper, so use that
> instead of doing our own formatting of the different known link speeds.
In case the speed is not supported, phy_speed_to_str() would return
"Unsupported (update phy-core.c)" which is bigger (by 21 characters)
than name_suffix.
If you bumped name_suffix/PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE to 11
characters, that would be just large enough to accommodate for the
"Unsupported" part of the string and that might be an acceptable
solution in between.
>
> Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
> ---
> drivers/net/phy/phy_led_triggers.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
> index 491efc1bf5c4..2827eb413c9c 100644
> --- a/drivers/net/phy/phy_led_triggers.c
> +++ b/drivers/net/phy/phy_led_triggers.c
> @@ -77,20 +77,9 @@ static int phy_led_trigger_register(struct phy_device *phy,
> struct phy_led_trigger *plt,
> unsigned int speed)
> {
> - char name_suffix[PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE];
> -
> plt->speed = speed;
> -
> - if (speed < SPEED_1000)
> - snprintf(name_suffix, sizeof(name_suffix), "%dMbps", speed);
> - else if (speed == SPEED_2500)
> - snprintf(name_suffix, sizeof(name_suffix), "2.5Gbps");
> - else
> - snprintf(name_suffix, sizeof(name_suffix), "%dGbps",
> - DIV_ROUND_CLOSEST(speed, 1000));
> -
> phy_led_trigger_format_name(phy, plt->name, sizeof(plt->name),
> - name_suffix);
> + phy_speed_to_str(speed));
> plt->trigger.name = plt->name;
>
> return led_trigger_register(&plt->trigger);
>
--
Florian
^ permalink raw reply
* Re: SACK compression patch causing performance drop
From: Jean-Louis Dupond @ 2018-11-08 8:23 UTC (permalink / raw)
To: netdev, edumazet
In-Reply-To: <89214271-4496-c438-c4e8-b39f0ae72af7@dupond.be>
Hi,
Was somebody able to check this?
Really think this should be fixed :)
Thanks
Jean-Louis
On 3/11/18 16:59, Jean-Louis Dupond wrote:
> Hi All,
>
> On recent kernels we noticed a way lower throughput to our SAN system
> than before.
> While on pre 4.18 kernels we had 400-700MB/sec read speed, on 4.18+ we
> only had 70-120MB/sec.
>
> The SAN is connected via iSCSI over a 10G network (ixgbe/X520 NICS if
> it matters).
>
> After some debugging, I tried to bisect between 4.17 and 4.18 to see
> what commit caused the slowdown.
> It showed that the addition of the SACK compression
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d9f4262b7ea41ca9981cc790e37cca6e37c789e)
> was the cause.
>
> And indeed, if I set net.ipv4.tcp_comp_sack_nr to 0 on 4.19 for
> example, the throughput is (almost) back to normal again.
> So it seems like this change causes quite some performance issues.
>
> Any ideas?
>
> Thanks
> Jean-Louis
>
^ permalink raw reply
* Re: [PATCH 2/5] phy: core: add PHY_MODE_ETHERNET
From: Grygorii Strashko @ 2018-11-08 18:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Alexandre Belloni, Quentin Schulz, Tony Lindgren, netdev,
Antoine Tenart, Sekhar Nori, linux-kernel, Kishon Vijay Abraham I,
Manu Gautam, Chen-Yu Tsai, Chunfeng Yun, linux-mediatek,
Vivek Gautam, Maxime Ripard, linux-amlogic, Carlo Caione,
David S. Miller, linux-arm-kernel, Matthias Brugger
In-Reply-To: <20181108004200.GW30658@n2100.armlinux.org.uk>
hi Russell,
On 11/7/18 6:42 PM, Russell King - ARM Linux wrote:
> On Wed, Nov 07, 2018 at 06:36:14PM -0600, Grygorii Strashko wrote:
>> Add new PHY's mode to be used by Ethernet PHY interface drivers or
>> multipurpose PHYs like serdes. It will be reused in further changes.
>>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>> include/linux/phy/phy.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>> index b17e770..02c9ef0 100644
>> --- a/include/linux/phy/phy.h
>> +++ b/include/linux/phy/phy.h
>> @@ -42,6 +42,7 @@ enum phy_mode {
>> PHY_MODE_UFS_HS_A,
>> PHY_MODE_UFS_HS_B,
>> PHY_MODE_PCIE,
>> + PHY_MODE_ETHERNET,
>
> Are you sure about this - we already have a bunch of "ethernet" modes
> that are more specific, like PHY_MODE_SGMII, PHY_MODE_2500SGMII and
> PHY_MODE_10GKR which require PHYs to be configured differently. Having
> a very generic "ethernet" mode brings up questions about when it should
> be used vs the more specific modes.
yes. the idea of this series is to split PHY mode on - PHY mode (generic)
and PHY submode (subsystem specific), so multi-functional PHY like serdes will do
(for example):
phy_set_mode_ext(port->comphy, PHY_MODE_ETHERNET, PHY_INTERFACE_MODE_SGMII);
where PHY_INTERFACE_MODE_SGMII is defined by phy_interface_t enum.
instead of
phy_set_mode(port->comphy, PHY_MODE_SGMII);
In patches 3-5 I've converted users of existing PHY "ethernet" modes to use
this approach and, finally, in patch 5 removed
PHY_MODE_SGMII/2500SGMII/QSGMII/10GKR
>
> (I've already mentioned that the SGMII modes are mis-named, since
> they also apply to 1000base-X and 2500base-X - the only difference
> is how one 16-bit word in the data stream is used which has no effect
> on the PHY.)
>
--
regards,
-grygorii
^ permalink raw reply
* Re: [RFC perf,bpf 1/5] perf, bpf: Introduce PERF_RECORD_BPF_EVENT
From: David Ahern @ 2018-11-08 18:26 UTC (permalink / raw)
To: Song Liu, Peter Zijlstra
Cc: Netdev, lkml, Kernel Team, ast@kernel.org, daniel@iogearbox.net,
acme@kernel.org
In-Reply-To: <C858C862-E523-4CE8-AB39-CC9B27BE2538@fb.com>
On 11/8/18 11:04 AM, Song Liu wrote:
> On the other hand, processing BPF load/unload events synchronously should
> not introduce too much overhead for meaningful use cases. If many BPF progs
> are being loaded/unloaded within short period of time, it is not the steady
> state that profiling works care about.
but, profiling is not the only use case, and perf-record is common with
those other use cases.
I think that answers why your RFC set does not fork a thread for the bpf
events. You are focused on profiling and for already loaded programs or
for a small number of programs loaded by a specific workload started by
perf.
^ 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