* [PATCH net-next 7/8] net: ipv4: RTM_GETROUTE: return matched fib result when requested
From: Roopa Prabhu @ 2017-05-24 18:19 UTC (permalink / raw)
To: davem; +Cc: netdev, dsahern, nikolay
In-Reply-To: <1495649951-30417-1-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds support to return matched fib result when RTM_F_FIB_MATCH
flag is specified in RTM_GETROUTE request. This is useful for user-space
applications/controllers wanting to query a matching route.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
---
net/ipv4/route.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 6e0bd40..419bdba 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -114,6 +114,8 @@
#include <net/ip_tunnels.h>
#include <net/l3mdev.h>
+#include "fib_lookup.h"
+
#define RT_FL_TOS(oldflp4) \
((oldflp4)->flowi4_tos & (IPTOS_RT_MASK | RTO_ONLINK))
@@ -2746,8 +2748,15 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh,
if (rtm->rtm_flags & RTM_F_LOOKUP_TABLE)
table_id = rt->rt_table_id;
- err = rt_fill_info(net, dst, src, table_id, &fl4, skb,
- NETLINK_CB(in_skb).portid, nlh->nlmsg_seq, rt);
+ if (rtm->rtm_flags & RTM_F_FIB_MATCH)
+ err = fib_dump_info(skb, NETLINK_CB(in_skb).portid,
+ nlh->nlmsg_seq, RTM_NEWROUTE, table_id,
+ rt->rt_type, res.prefix, res.prefixlen,
+ fl4.flowi4_tos, res.fi, 0);
+ else
+ err = rt_fill_info(net, dst, src, table_id, &fl4, skb,
+ NETLINK_CB(in_skb).portid, nlh->nlmsg_seq,
+ rt);
if (err < 0)
goto errout_free;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/2] at803x: double check SGMII side autoneg
From: Timur Tabi @ 2017-05-24 18:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Matthias May, Zefir Kurtisi, netdev, f.fainelli, David Miller,
Manoj Iyer, jhugo
In-Reply-To: <20170524140929.GC26577@lunn.ch>
On 05/24/2017 09:09 AM, Andrew Lunn wrote:
> It could be, the copper side is up, but the SGMII side is down, at the
> point at803x_aneg_done() is called. So it is correctly returning
> 0. Sometime later the SGMII side goes up, but there is not a second
> interrupt. Hence the phy core does not know that the full, 2 stage MAC
> to PHY to peer PHY link is now up.
Ok, I'm going to debug this some more. It turns out that the MAC side of
the SGMII link can send an interrupt when it thinks that auto-negotiation is
done. I might be able to use this.
What function should my MAC driver call when it wants the phy core to call
at803x_aneg_done again to see if autonegotiation is done?
Also, is there a way for the MAC driver to know that at803x_aneg_done()
previously returned 0, and that it needs to tell the phy core to check again?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v2 net-next 00/11] qed/qede: Mostly-cleanup series
From: David Miller @ 2017-05-24 19:18 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev
In-Reply-To: <1495521688-27669-1-git-send-email-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Tue, 23 May 2017 09:41:17 +0300
> This series contains some cleanup of the qed and qede code:
> - #1 contains mostly static/endian changes in order to allow qede to
> pass sparse compilation cleanly.
> - #2, #5 and #6 are either semantic or remove dead-code from driver.
> - #9, #10 and #11 relate to printing and slightly change some APIs
> between qed and the protocol drivers for that end [sharing the
> interface names and information regarding device].
>
> The rest of the patches are minor changes/fixes to various flows
> in qed.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] geneve: fix fill_info when using collect_metadata
From: Pravin Shelar @ 2017-05-24 19:20 UTC (permalink / raw)
To: Eric Garver; +Cc: Linux Kernel Network Developers
In-Reply-To: <20170523223727.15307-1-e@erig.me>
On Tue, May 23, 2017 at 3:37 PM, Eric Garver <e@erig.me> wrote:
> Since 9b4437a5b870 ("geneve: Unify LWT and netdev handling.") fill_info
> does not return UDP_ZERO_CSUM6_RX when using COLLECT_METADATA. This is
> because it uses ip_tunnel_info_af() with the device level info, which is
> not valid for COLLECT_METADATA.
>
> Fix by checking for the presence of the actual sockets.
>
> Fixes: 9b4437a5b870 ("geneve: Unify LWT and netdev handling.")
> Signed-off-by: Eric Garver <e@erig.me>
Thanks for the patch.
Acked-by: Pravin B Shelar <pshelar@ovn.org>
I noticed that the MTU and encal_len calculation in geneve_configure()
also needs to be fixed for collect metadata case. Can you send patch
to fix it?
^ permalink raw reply
* Re: [PATCH net 0/2] sctp: a bunch of fixes for processing dupcookie
From: David Miller @ 2017-05-24 19:22 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <cover.1495517205.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 23 May 2017 13:28:53 +0800
> After introducing transport hashtable and per stream info into sctp,
> some regressions were caused when processing dupcookie, this patchset
> is to fix them.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/4] nfp: register ports as devlink ports
From: Jakub Kicinski @ 2017-05-24 19:24 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, oss-drivers
In-Reply-To: <20170524123514.GB1908@nanopsycho>
On Wed, 24 May 2017 14:35:14 +0200, Jiri Pirko wrote:
> >+void nfp_devlink_port_unregister(struct nfp_port *port)
> >+{
> >+ /* Due to unpleasant lock ordering we may see the port go away before
> >+ * we have fully probed.
>
> Could you elaborate on this a bit more please?
It's partially due to peculiarities of the management FW more than
kernel stuff. Unfortunately some ethtool media config requires reboot
to be applied, so we print a friendly message to the logs and
unregister the associated netdevs. Which means once netdevs get
registered ports may go away.
Enter devlink, I need the ability to grab the adapater lock in
split/unsplit callbacks to find the ports, which implies having to drop
that lock before I register devlink. And only after I register devlink
can I register the ports.
I could do init without registering anything, drop the adapter lock,
register devlink, and then grab the adapter lock back and register
devlink ports and netdevs. But there is another issue...
Since I look for ports on a list maintained in the adapter struct,
driver code doesn't care if devlink_port has been registered or not.
The moment devlink is registered, split/unsplit requests will be
accepted - potentially trying to unregister devlink_port before the
register could happen.
Further down the line, also, the eswitch mode setting is coming. Which
means the moment I register devlink itself ports will get shuffled (due
to the plan of registering VFs as ports :)).
I feel like registering devlink should be the last action of the
driver, really. My plan was to keep that simple if() for now, and once
we get to extending devlink with SR-IOV stuff also add the ability to
pre-register ports. Allow registering ports on not-yet-registered
devlink (probably put them on a private list within struct devlink).
This would make devlink_register() a single point when everything
devlink becomes visible, atomically, instead of devlink itself coming
first and then ports following.
Does that make sense? Am I misreading the code (again :S)?
^ permalink raw reply
* Re: [PATCH v2] net: fec: add post PHY reset delay DT property
From: David Miller @ 2017-05-24 19:25 UTC (permalink / raw)
To: quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: fugang.duan-3arQi8VN3Tc, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20170523094808.11102-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
From: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Date: Tue, 23 May 2017 11:48:08 +0200
> Some PHY require to wait for a bit after the reset GPIO has been
> toggled. This adds support for the DT property `phy-reset-post-delay`
> which gives the delay in milliseconds to wait after reset.
>
> If the DT property is not given, no delay is observed. Post reset delay
> greater than 1000ms are invalid.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: rtnetlink: bail out from rtnl_fdb_dump() on parse error
From: Greg Rose @ 2017-05-24 19:29 UTC (permalink / raw)
To: Alexander Potapenko; +Cc: dvyukov, kcc, edumazet, davem, linux-kernel, netdev
In-Reply-To: <20170523112028.132630-1-glider@google.com>
On Tue, 2017-05-23 at 13:20 +0200, Alexander Potapenko wrote:
> rtnl_fdb_dump() failed to check the result of nlmsg_parse(), which led
> to contents of |ifm| being uninitialized because nlh->nlmsglen was too
> small to accommodate |ifm|. The uninitialized data may affect some
> branches and result in unwanted effects, although kernel data doesn't
> seem to leak to the userspace directly.
>
> The bug has been detected with KMSAN and syzkaller.
>
> Signed-off-by: Alexander Potapenko <glider@google.com>
> ---
> For the record, here is the KMSAN report:
>
> ==================================================================
> BUG: KMSAN: use of unitialized memory in rtnl_fdb_dump+0x5dc/0x1000
> CPU: 0 PID: 1039 Comm: probe Not tainted 4.11.0-rc5+ #2727
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16
> dump_stack+0x143/0x1b0 lib/dump_stack.c:52
> kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
> __kmsan_warning_32+0x66/0xb0 mm/kmsan/kmsan_instr.c:491
> rtnl_fdb_dump+0x5dc/0x1000 net/core/rtnetlink.c:3230
> netlink_dump+0x84f/0x1190 net/netlink/af_netlink.c:2168
> __netlink_dump_start+0xc97/0xe50 net/netlink/af_netlink.c:2258
> netlink_dump_start ./include/linux/netlink.h:165
> rtnetlink_rcv_msg+0xae9/0xb40 net/core/rtnetlink.c:4094
> netlink_rcv_skb+0x339/0x5a0 net/netlink/af_netlink.c:2339
> rtnetlink_rcv+0x83/0xa0 net/core/rtnetlink.c:4110
> netlink_unicast_kernel net/netlink/af_netlink.c:1272
> netlink_unicast+0x13b7/0x1480 net/netlink/af_netlink.c:1298
> netlink_sendmsg+0x10b8/0x10f0 net/netlink/af_netlink.c:1844
> sock_sendmsg_nosec net/socket.c:633
> sock_sendmsg net/socket.c:643
> ___sys_sendmsg+0xd4b/0x10f0 net/socket.c:1997
> __sys_sendmsg net/socket.c:2031
> SYSC_sendmsg+0x2c6/0x3f0 net/socket.c:2042
> SyS_sendmsg+0x87/0xb0 net/socket.c:2038
> do_syscall_64+0x102/0x150 arch/x86/entry/common.c:285
> entry_SYSCALL64_slow_path+0x25/0x25 arch/x86/entry/entry_64.S:246
> RIP: 0033:0x401300
> RSP: 002b:00007ffc3b0e6d58 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 00000000004002b0 RCX: 0000000000401300
> RDX: 0000000000000000 RSI: 00007ffc3b0e6d80 RDI: 0000000000000003
> RBP: 00007ffc3b0e6e00 R08: 000000000000000b R09: 0000000000000004
> R10: 000000000000000d R11: 0000000000000246 R12: 0000000000000000
> R13: 00000000004065a0 R14: 0000000000406630 R15: 0000000000000000
> origin: 000000008fe00056
> save_stack_trace+0x59/0x60 arch/x86/kernel/stacktrace.c:59
> kmsan_save_stack_with_flags mm/kmsan/kmsan.c:352
> kmsan_internal_poison_shadow+0xb1/0x1a0 mm/kmsan/kmsan.c:247
> kmsan_poison_shadow+0x6d/0xc0 mm/kmsan/kmsan.c:260
> slab_alloc_node mm/slub.c:2743
> __kmalloc_node_track_caller+0x1f4/0x390 mm/slub.c:4349
> __kmalloc_reserve net/core/skbuff.c:138
> __alloc_skb+0x2cd/0x740 net/core/skbuff.c:231
> alloc_skb ./include/linux/skbuff.h:933
> netlink_alloc_large_skb net/netlink/af_netlink.c:1144
> netlink_sendmsg+0x934/0x10f0 net/netlink/af_netlink.c:1819
> sock_sendmsg_nosec net/socket.c:633
> sock_sendmsg net/socket.c:643
> ___sys_sendmsg+0xd4b/0x10f0 net/socket.c:1997
> __sys_sendmsg net/socket.c:2031
> SYSC_sendmsg+0x2c6/0x3f0 net/socket.c:2042
> SyS_sendmsg+0x87/0xb0 net/socket.c:2038
> do_syscall_64+0x102/0x150 arch/x86/entry/common.c:285
> return_from_SYSCALL_64+0x0/0x6a arch/x86/entry/entry_64.S:246
> ==================================================================
>
> and the reproducer:
>
> ==================================================================
> #include <sys/socket.h>
> #include <net/if_arp.h>
> #include <linux/netlink.h>
> #include <stdint.h>
>
> int main()
> {
> int sock = socket(PF_NETLINK, SOCK_DGRAM | SOCK_NONBLOCK, 0);
> struct msghdr msg;
> memset(&msg, 0, sizeof(msg));
> char nlmsg_buf[32];
> memset(nlmsg_buf, 0, sizeof(nlmsg_buf));
> struct nlmsghdr *nlmsg = nlmsg_buf;
> nlmsg->nlmsg_len = 0x11;
> nlmsg->nlmsg_type = 0x1e; // RTM_NEWROUTE = RTM_BASE + 0x0e
> // type = 0x0e = 1110b
> // kind = 2
> nlmsg->nlmsg_flags = 0x101; // NLM_F_ROOT | NLM_F_REQUEST
> nlmsg->nlmsg_seq = 0;
> nlmsg->nlmsg_pid = 0;
> nlmsg_buf[16] = (char)7;
> struct iovec iov;
> iov.iov_base = nlmsg_buf;
> iov.iov_len = 17;
> msg.msg_iov = &iov;
> msg.msg_iovlen = 1;
> sendmsg(sock, &msg, 0);
> return 0;
> }
> ==================================================================
> ---
> net/core/rtnetlink.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 49a279a7cc15..9e2c0a7cb325 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -3231,8 +3231,11 @@ static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
> int err = 0;
> int fidx = 0;
>
> - if (nlmsg_parse(cb->nlh, sizeof(struct ifinfomsg), tb,
> - IFLA_MAX, ifla_policy, NULL) == 0) {
> + err = nlmsg_parse(cb->nlh, sizeof(struct ifinfomsg), tb,
> + IFLA_MAX, ifla_policy, NULL);
> + if (err < 0) {
> + return -EINVAL;
> + } else if (err == 0) {
> if (tb[IFLA_MASTER])
> br_idx = nla_get_u32(tb[IFLA_MASTER]);
> }
Fix looks right to me.
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
^ permalink raw reply
* Re: [PATCH] net: rtnetlink: bail out from rtnl_fdb_dump() on parse error
From: David Miller @ 2017-05-24 19:32 UTC (permalink / raw)
To: glider; +Cc: dvyukov, kcc, edumazet, linux-kernel, netdev
In-Reply-To: <20170523112028.132630-1-glider@google.com>
From: Alexander Potapenko <glider@google.com>
Date: Tue, 23 May 2017 13:20:28 +0200
> rtnl_fdb_dump() failed to check the result of nlmsg_parse(), which led
> to contents of |ifm| being uninitialized because nlh->nlmsglen was too
> small to accommodate |ifm|. The uninitialized data may affect some
> branches and result in unwanted effects, although kernel data doesn't
> seem to leak to the userspace directly.
>
> The bug has been detected with KMSAN and syzkaller.
>
> Signed-off-by: Alexander Potapenko <glider@google.com>
Applied, thanks.
^ permalink raw reply
* Re: pull-request: mac80211 2017-05-23
From: David Miller @ 2017-05-24 19:32 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20170523124256.23463-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 23 May 2017 14:42:55 +0200
> I have just two fixes here, one of the scheduled scan issue that
> Sander Eikelenboom found, and the other properly makes mesh more
> strictly check its extension headers.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* RE: [PATCH net-next 1/8] net: ipv4: refactor __ip_route_output_key_hash
From: Rosen, Rami @ 2017-05-24 19:33 UTC (permalink / raw)
To: Roopa Prabhu, davem@davemloft.net
Cc: netdev@vger.kernel.org, dsahern@gmail.com,
nikolay@cumulusnetworks.com
In-Reply-To: <1495649951-30417-2-git-send-email-roopa@cumulusnetworks.com>
Hi, Rupa /David Ahern,
First, thanks for this patch set!
Second, it seems to me that something might be incorrect here.
You have these additions in this patch (1/8):
...
+struct rtable *ip_route_output_key_hash_rcu(struct net *net, struct flowi4 *flp,
+ const struct sk_buff *skb,
+ struct fib_result *res);
...
+struct rtable *ip_route_output_key_hash(struct net *net, struct flowi4 *fl4,
+ const struct sk_buff *skb)
+{
+ struct fib_result res;
+ struct rtable *rth;
+
+ res.tclassid = 0;
+ res.fi = NULL;
+ res.table = NULL;
+
+ rcu_read_lock();
+ rth = ip_route_output_key_hash_rcu(net, fl4, &res, mp_hash);
rcu_read_unlock();
+
return rth;
}
-EXPORT_SYMBOL_GPL(__ip_route_output_key_hash);
+EXPORT_SYMBOL_GPL(ip_route_output_key_hash);
So the third parameter to ip_route_output_key_hash_rcu() should be skb*, and the fourth parameter should be fib_result *. However, you do not pass the skb parameter
when calling ip_route_output_key_hash_rcu() in
ip_route_output_key_hash() (in fact you don't use it at all), and you pass mp_hash as the fourth parameter.
Regards,
Rami Rosen
Intel Corporation
^ permalink raw reply
* [PATCH net-next 0/3] net: phy: Create sysfs reciprocal links for attached_dev/phydev
From: Florian Fainelli @ 2017-05-24 19:33 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
Hi David, Andrew,
This patch series addresses a device topology shortcoming where a program
scanning /sys would not be able to establish a mapping between the network
device and the PHY device.
In the process it turned out that no PHY device documentation existed for
sysfs attributes.
Thanks!
Florian Fainelli (3):
net: phy: Create sysfs reciprocal links for attached_dev/phydev
net: sysfs: Document "phydev" symbolic link
net: sysfs: Document PHY device sysfs attributes
Documentation/ABI/testing/sysfs-class-net | 8 ++++++
Documentation/ABI/testing/sysfs-class-net-phydev | 32 ++++++++++++++++++++++++
drivers/net/phy/phy_device.c | 11 ++++++++
3 files changed, 51 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-net-phydev
--
2.9.3
^ permalink raw reply
* [PATCH net-next 1/3] net: phy: Create sysfs reciprocal links for attached_dev/phydev
From: Florian Fainelli @ 2017-05-24 19:33 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
In-Reply-To: <20170524193354.10739-1-f.fainelli@gmail.com>
There is currently no way for a program scanning /sys to know whether a
network device is attached to a particular PHY device, just like the PHY
device is not pointed back to its attached network device.
Create a symbolic link in the network device's namespace named "phydev"
which points to the PHY device and create a symbolic link in the PHY
device's namespace named "attached_dev" that points back to the network
device. These links are set up during phy_attach_direct() and removed
during phy_detach() for symetry.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/phy_device.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1219eeab69d1..8151477c7027 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -960,6 +960,15 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
phydev->attached_dev = dev;
dev->phydev = phydev;
+ err = sysfs_create_link(&phydev->mdio.dev.kobj, &dev->dev.kobj,
+ "attached_dev");
+ if (err)
+ goto error;
+
+ err = sysfs_create_link(&dev->dev.kobj, &phydev->mdio.dev.kobj,
+ "phydev");
+ if (err)
+ goto error;
phydev->dev_flags = flags;
@@ -1050,6 +1059,8 @@ void phy_detach(struct phy_device *phydev)
struct mii_bus *bus;
int i;
+ sysfs_remove_link(&dev->dev.kobj, "phydev");
+ sysfs_remove_link(&phydev->mdio.dev.kobj, "attached_dev");
phydev->attached_dev->phydev = NULL;
phydev->attached_dev = NULL;
phy_suspend(phydev);
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 2/3] net: sysfs: Document "phydev" symbolic link
From: Florian Fainelli @ 2017-05-24 19:33 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
In-Reply-To: <20170524193354.10739-1-f.fainelli@gmail.com>
Now that we link the network device to its PHY device, document this
sysfs symbolic link.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/ABI/testing/sysfs-class-net | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net
index 668604fc8e06..6856da99b6f7 100644
--- a/Documentation/ABI/testing/sysfs-class-net
+++ b/Documentation/ABI/testing/sysfs-class-net
@@ -251,3 +251,11 @@ Contact: netdev@vger.kernel.org
Description:
Indicates the unique physical switch identifier of a switch this
port belongs to, as a string.
+
+What: /sys/class/net/<iface>/phydev
+Date: May 2017
+KernelVersion: 4.13
+Contact: netdev@vger.kernel.org
+Description:
+ Symbolic link to the PHY device this network device is attached
+ to.
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 3/3] net: sysfs: Document PHY device sysfs attributes
From: Florian Fainelli @ 2017-05-24 19:33 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, Florian Fainelli
In-Reply-To: <20170524193354.10739-1-f.fainelli@gmail.com>
Document the different sysfs attributes that exist for PHY devices:
attached_dev, phy_has_fixups, phy_id and phy_interface.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/ABI/testing/sysfs-class-net-phydev | 32 ++++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-net-phydev
diff --git a/Documentation/ABI/testing/sysfs-class-net-phydev b/Documentation/ABI/testing/sysfs-class-net-phydev
new file mode 100644
index 000000000000..a05831667c3d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-phydev
@@ -0,0 +1,32 @@
+What: /sys/class/mdio_bus/<bus>/<device>/attached_dev
+Date: May 2017
+KernelVersion: 4.13
+Contact: netdev@vger.kernel.org
+Description:
+ Symbolic link to the network device this PHY device is
+ attached to.
+
+What: /sys/class/mdio_bus/<bus>/<device>/phy_has_fixups
+Date: February 2014
+KernelVersion: 3.15
+Contact: netdev@vger.kernel.org
+Description:
+ Boolean value indicating whether the PHY device has
+ any fixups registered against it (phy_register_fixup)
+
+What: /sys/class/mdio_bus/<bus>/<device>/phy_id
+Date: November 2012
+KernelVersion: 3.8
+Contact: netdev@vger.kernel.org
+Description:
+ 32-bit hexadecimal value corresponding to the PHY device's OUI,
+ model and revision number.
+
+What: /sys/class/mdio_bus/<bus>/<device>/phy_interface
+Date: February 2014
+KernelVersion: 3.15
+Contact: netdev@vger.kernel.org
+Description:
+ String value indicating the PHY interface, possible
+ values are in include/linux/phy.h function phy_modes.
+
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 2/2] at803x: double check SGMII side autoneg
From: Andrew Lunn @ 2017-05-24 19:34 UTC (permalink / raw)
To: Timur Tabi
Cc: Matthias May, Zefir Kurtisi, netdev, f.fainelli, David Miller,
Manoj Iyer, jhugo
In-Reply-To: <c2a54e2e-a1b6-24b4-d125-95fa9648fe95@codeaurora.org>
On Wed, May 24, 2017 at 01:58:09PM -0500, Timur Tabi wrote:
> On 05/24/2017 09:09 AM, Andrew Lunn wrote:
> > It could be, the copper side is up, but the SGMII side is down, at the
> > point at803x_aneg_done() is called. So it is correctly returning
> > 0. Sometime later the SGMII side goes up, but there is not a second
> > interrupt. Hence the phy core does not know that the full, 2 stage MAC
> > to PHY to peer PHY link is now up.
>
> Ok, I'm going to debug this some more. It turns out that the MAC side of
> the SGMII link can send an interrupt when it thinks that auto-negotiation is
> done. I might be able to use this.
You can use this for your board. But it still leaves the phy driver
broken for everybody else.
> What function should my MAC driver call when it wants the phy core to call
> at803x_aneg_done again to see if autonegotiation is done?
You want to trigger the PHY state machine. There is only one exported
API call to do this, phy_mac_interrupt(). But you are supposed to pass
the new link state. And your MAC driver has no idea of that, it does
not know if the copper side of the PHY is up.
So it might be better if you export phy_trigger_machine().
> Also, is there a way for the MAC driver to know that at803x_aneg_done()
> previously returned 0, and that it needs to tell the phy core to check again?
Not that i know of. The MAC layer is not supposed to be messing around
in the PHY layer. However, just triggering the PHY state machine
should be enough.
Andrew
^ permalink raw reply
* Re: [PATCH net] net/mlx4: Fix the check in attaching steering rules
From: David Miller @ 2017-05-24 19:36 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, ogerlitz, talatb
In-Reply-To: <1495543807-14956-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 23 May 2017 15:50:07 +0300
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> index ae5fdc2df654..00a7cd3dcc2e 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> @@ -1562,8 +1562,7 @@ static int mlx4_en_flow_replace(struct net_device *dev,
> qpn = priv->drop_qp.qpn;
> else if (cmd->fs.ring_cookie & EN_ETHTOOL_QP_ATTACH) {
> qpn = cmd->fs.ring_cookie & (EN_ETHTOOL_QP_ATTACH - 1);
> - if (qpn < priv->rss_map.base_qpn ||
> - qpn >= priv->rss_map.base_qpn + priv->rx_ring_num) {
> + if (!mlx4_qp_lookup(priv->mdev->dev, qpn)) {
> en_warn(priv, "rxnfc: QP (0x%x) doesn't exist\n", qpn);
> return -EINVAL;
> }
> diff --git a/drivers/net/ethernet/mellanox/mlx4/qp.c b/drivers/net/ethernet/mellanox/mlx4/qp.c
> index 2d6abd4662b1..1eff2fe32a8b 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/qp.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/qp.c
> @@ -384,6 +384,20 @@ static void mlx4_qp_free_icm(struct mlx4_dev *dev, int qpn)
> __mlx4_qp_free_icm(dev, qpn);
> }
>
> +struct mlx4_qp *mlx4_qp_lookup(struct mlx4_dev *dev, u32 qpn)
...
> +EXPORT_SYMBOL_GPL(mlx4_qp_lookup);
> +
This phony separation between MLX4_CORE and MLX4_EN is the only reason
you need this unreasonable symbol export.
I doubt you'll ever use this function anywhere outside of en_ethtool.c
so this export is wasted space in the kernel image. Probably compiler
could inline it decently as well.
So find another way to do this without the symbol export. I don't
really want to hear any stories about "clean separation" or whatever.
What's happening here is exactly why this separate modules scheme
results in ugly unreasonable code, and unnecessary gymnastics and
wasted object space just to make routines available in one place from
another.
^ permalink raw reply
* Re: [PATCH v6 net-next 01/17] net: qualcomm: remove unnecessary includes
From: David Miller @ 2017-05-24 19:41 UTC (permalink / raw)
To: stefan.wahren-eS4NqCHxEME
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
LinoSanfilippo-Mmb7MZpHnFY, kubakici-5tc4TXWwyLM,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1495545173-22150-2-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
From: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
Date: Tue, 23 May 2017 15:12:37 +0200
> Most of the includes in qca_7k.c are unnecessary so we better remove them.
>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> ---
> drivers/net/ethernet/qualcomm/qca_7k.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/qca_7k.c b/drivers/net/ethernet/qualcomm/qca_7k.c
> index f0066fb..557d53c 100644
> --- a/drivers/net/ethernet/qualcomm/qca_7k.c
> +++ b/drivers/net/ethernet/qualcomm/qca_7k.c
> @@ -23,11 +23,7 @@
> * kernel-based SPI device.
> */
>
> -#include <linux/init.h>
> -#include <linux/module.h>
> -#include <linux/moduleparam.h>
> #include <linux/spi/spi.h>
> -#include <linux/version.h>
>
> #include "qca_7k.h"
>
> --
> 2.1.4
>
Changes like this drive me crazy.
The only reason you can remove those headers is because you are obtaining
things indirectly via qca_7k.h
And if that is indeed the case, you are also getting qca_spi.h which
in turn includes linux/spi/spi.h
So you could have removed that as well.
But seriously, it is so much harder to understand a driver and what
interfaces it needs via header files when you hide _all_ of it behind
these local private header files which just include _everything_
and then _every_ foo.c file in your driver gets _all_ of those kernel
headers whether they need it or not.
So if just one foo.c file needs 20 extra kernel headers than the rest
of the files in the driver, every foo.c file eats that cost of
including them.
I really don't like when drivers move in this direction for that
reason. And at best, as described at the beginning of my response,
this change is incomplete.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [pull request][net 0/8] Mellanox, mlx5 fixes 2017-05-23
From: David Miller @ 2017-05-24 19:45 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20170523141610.27833-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 23 May 2017 17:16:02 +0300
> This series contains some fixes for the mlx5 driver and one small patch that
> adds csum actions accessors in include/net/tc_act/tc_csum.h needed by some of
> mlx5 fixes patches.
>
> Details are below.
>
> Please pull and let me know if there's any problem.
>
> Note: This series doesn't introduce any merge conflict with the ongoing mlx5
> for-next submission.
>
> For -stable kernels >= 4.7:
> ("net/mlx5: Avoid using pending command interface slots")
> ("net/mlx5: Tolerate irq_set_affinity_hint() failures")
Pulled and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net/phy: fix mdio-octeon dependency and build
From: David Miller @ 2017-05-24 19:48 UTC (permalink / raw)
To: rdunlap; +Cc: netdev, andrew, f.fainelli, linux-kernel
In-Reply-To: <c37b4171-e3f2-c5cc-d734-6e1688c964f5@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Tue, 23 May 2017 08:19:49 -0700
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix build errors by making this driver depend on OF_MDIO, like
> several other similar drivers do.
>
> drivers/built-in.o: In function `octeon_mdiobus_remove':
> mdio-octeon.c:(.text+0x196ee0): undefined reference to `mdiobus_unregister'
> mdio-octeon.c:(.text+0x196ee8): undefined reference to `mdiobus_free'
> drivers/built-in.o: In function `octeon_mdiobus_probe':
> mdio-octeon.c:(.text+0x196f1d): undefined reference to `devm_mdiobus_alloc_size'
> mdio-octeon.c:(.text+0x196ffe): undefined reference to `of_mdiobus_register'
> mdio-octeon.c:(.text+0x197010): undefined reference to `mdiobus_free'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH v3 net] net: phy: marvell: Limit errata to 88m1101
From: David Miller @ 2017-05-24 19:49 UTC (permalink / raw)
To: andrew; +Cc: netdev
In-Reply-To: <1495554553-21118-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Tue, 23 May 2017 17:49:13 +0200
> The 88m1101 has an errata when configuring autoneg. However, it was
> being applied to many other Marvell PHYs as well. Limit its scope to
> just the 88m1101.
>
> Fixes: 76884679c644 ("phylib: Add support for Marvell 88e1111S and 88e1145")
> Reported-by: Daniel Walker <danielwa@cisco.com>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> Acked-by: Harini Katakam <harinik@xilinx.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] geneve: fix fill_info when using collect_metadata
From: Eric Garver @ 2017-05-24 19:58 UTC (permalink / raw)
To: Pravin Shelar; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAOrHB_CqAAWpHLuc+apQHbhL6SUS9bcKq3wW_TxbtWEWcgZrSA@mail.gmail.com>
On Wed, May 24, 2017 at 12:20:36PM -0700, Pravin Shelar wrote:
> On Tue, May 23, 2017 at 3:37 PM, Eric Garver <e@erig.me> wrote:
> > Since 9b4437a5b870 ("geneve: Unify LWT and netdev handling.") fill_info
> > does not return UDP_ZERO_CSUM6_RX when using COLLECT_METADATA. This is
> > because it uses ip_tunnel_info_af() with the device level info, which is
> > not valid for COLLECT_METADATA.
> >
> > Fix by checking for the presence of the actual sockets.
> >
> > Fixes: 9b4437a5b870 ("geneve: Unify LWT and netdev handling.")
> > Signed-off-by: Eric Garver <e@erig.me>
> Thanks for the patch.
>
> Acked-by: Pravin B Shelar <pshelar@ovn.org>
>
>
> I noticed that the MTU and encal_len calculation in geneve_configure()
> also needs to be fixed for collect metadata case. Can you send patch
> to fix it?
Ah, yes. I'll take a look at those as well.
Eric.
^ permalink raw reply
* Re: [PATCH v6 net-next 01/17] net: qualcomm: remove unnecessary includes
From: Stefan Wahren @ 2017-05-24 20:05 UTC (permalink / raw)
To: David Miller
Cc: linux-serial, jslaby, gregkh, netdev, robh+dt, linux-kernel,
kubakici, mark.rutland, LinoSanfilippo, devicetree
In-Reply-To: <20170524.154111.404338711401048909.davem@davemloft.net>
> David Miller <davem@davemloft.net> hat am 24. Mai 2017 um 21:41 geschrieben:
>
>
> From: Stefan Wahren <stefan.wahren@i2se.com>
> Date: Tue, 23 May 2017 15:12:37 +0200
>
> > Most of the includes in qca_7k.c are unnecessary so we better remove them.
> >
> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > ---
> > drivers/net/ethernet/qualcomm/qca_7k.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/qualcomm/qca_7k.c b/drivers/net/ethernet/qualcomm/qca_7k.c
> > index f0066fb..557d53c 100644
> > --- a/drivers/net/ethernet/qualcomm/qca_7k.c
> > +++ b/drivers/net/ethernet/qualcomm/qca_7k.c
> > @@ -23,11 +23,7 @@
> > * kernel-based SPI device.
> > */
> >
> > -#include <linux/init.h>
> > -#include <linux/module.h>
> > -#include <linux/moduleparam.h>
> > #include <linux/spi/spi.h>
> > -#include <linux/version.h>
> >
> > #include "qca_7k.h"
> >
> > --
> > 2.1.4
> >
>
> Changes like this drive me crazy.
>
> The only reason you can remove those headers is because you are obtaining
> things indirectly via qca_7k.h
>
> And if that is indeed the case, you are also getting qca_spi.h which
> in turn includes linux/spi/spi.h
>
> So you could have removed that as well.
>
> But seriously, it is so much harder to understand a driver and what
> interfaces it needs via header files when you hide _all_ of it behind
> these local private header files which just include _everything_
> and then _every_ foo.c file in your driver gets _all_ of those kernel
> headers whether they need it or not.
>
> So if just one foo.c file needs 20 extra kernel headers than the rest
> of the files in the driver, every foo.c file eats that cost of
> including them.
>
> I really don't like when drivers move in this direction for that
> reason. And at best, as described at the beginning of my response,
> this change is incomplete.
>
The intension of this change wasn't to hide the includes into qca_7k.h
AFAIK these ones above aren't necessary (no init, no kernel module, no kernel parameter, no kernel version) for this C file. So i will double check it.
^ permalink raw reply
* Re: [PATCH net 1/3] bpf: fix incorrect pruning decision when alignment must be tracked
From: David Miller @ 2017-05-24 20:07 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <170aa8062f2c54186a6567b5be8fca0cddec53be.1495556127.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 23 May 2017 18:30:41 +0200
> + if (!env->strict_alignment && old->off <= cur->off &&
You can't just test env->strict_alignment by itself, that's just an
override and doesn't determine the actual "strict" value we use which
is a combination of env->strict_alignment and
"!CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS".
So you'll have to update this test.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: sysfs: Document PHY device sysfs attributes
From: Andrew Lunn @ 2017-05-24 20:10 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem
In-Reply-To: <20170524193354.10739-4-f.fainelli@gmail.com>
> +What: /sys/class/mdio_bus/<bus>/<device>/phy_interface
> +Date: February 2014
> +KernelVersion: 3.15
> +Contact: netdev@vger.kernel.org
> +Description:
> + String value indicating the PHY interface, possible
> + values are in include/linux/phy.h function phy_modes.
Hi Florian
Does this suggest that these strings should be moved to
include/uapi/linux/phy.h?
Andrew
^ 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