* Re: [PATCH] net: stmicro: fix LS field mask in EEE configuration
From: Rayagond Kokatanur @ 2017-01-23 5:31 UTC (permalink / raw)
To: Joao Pinto; +Cc: David Miller, netdev
In-Reply-To: <ed690f703a3c82193737f1a9813dff8b1ff403dd.1484927665.git.jpinto@synopsys.com>
Acked-by:Rayagond Kokatanur <rayagond@vayavyalabs.com>
On Fri, Jan 20, 2017 at 9:30 PM, Joao Pinto <Joao.Pinto@synopsys.com> wrote:
> This patch fixes the LS mask when setting EEE timer.
> LS field is 10 bits long and not 11 as currently.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> Reported-By: Rayagond Kokatanur <rayagond@vayavyalabs.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> index 834f40f..202216c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
> @@ -184,7 +184,7 @@ static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
> static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
> {
> void __iomem *ioaddr = hw->pcsr;
> - int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
> + int value = ((tw & 0xffff)) | ((ls & 0x3ff) << 16);
>
> /* Program the timers in the LPI timer control register:
> * LS: minimum time (ms) for which the link
> --
> 2.9.3
>
--
wwr
Rayagond
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: Fix inverted test for multiple CPU interface
From: Florian Fainelli @ 2017-01-23 5:26 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: Vivien Didelot, netdev
In-Reply-To: <1485119805-30338-1-git-send-email-andrew@lunn.ch>
On 01/22/2017 01:16 PM, Andrew Lunn wrote:
> Remove the wrong !, otherwise we get false positives about having
> multiple CPU interfaces.
>
> Fixes: b22de490869d ("net: dsa: store CPU switch structure in the tree")
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH net-next 2/2] net: dsa: b53: Utilize mdio_module_driver
From: Florian Fainelli @ 2017-01-23 5:17 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
In-Reply-To: <20170123051733.10316-1-f.fainelli@gmail.com>
Eliminate a bit of boilerplate code.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_mdio.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/net/dsa/b53/b53_mdio.c b/drivers/net/dsa/b53/b53_mdio.c
index 477a16b5660a..fa7556f5d4fb 100644
--- a/drivers/net/dsa/b53/b53_mdio.c
+++ b/drivers/net/dsa/b53/b53_mdio.c
@@ -375,18 +375,7 @@ static struct mdio_driver b53_mdio_driver = {
.of_match_table = b53_of_match,
},
};
-
-static int __init b53_mdio_driver_register(void)
-{
- return mdio_driver_register(&b53_mdio_driver);
-}
-module_init(b53_mdio_driver_register);
-
-static void __exit b53_mdio_driver_unregister(void)
-{
- mdio_driver_unregister(&b53_mdio_driver);
-}
-module_exit(b53_mdio_driver_unregister);
+mdio_module_driver(b53_mdio_driver);
MODULE_DESCRIPTION("B53 MDIO access driver");
MODULE_LICENSE("Dual BSD/GPL");
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 1/2] net: phy: Fix typo for MDIO module boilerplate comment
From: Florian Fainelli @ 2017-01-23 5:17 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
In-Reply-To: <20170123051733.10316-1-f.fainelli@gmail.com>
The module boilerplate macro is named mdio_module_driver and not
module_mdio_driver, fix that.
Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
include/linux/mdio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index b6587a4b32e7..55a80d73cfc1 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -265,7 +265,7 @@ bool mdiobus_is_registered_device(struct mii_bus *bus, int addr);
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr);
/**
- * module_mdio_driver() - Helper macro for registering mdio drivers
+ * mdio_module_driver() - Helper macro for registering mdio drivers
*
* Helper macro for MDIO drivers which do not do anything special in module
* init/exit. Each module may only use this macro once, and calling it
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 0/2] net: couple mdio_module_driver changes
From: Florian Fainelli @ 2017-01-23 5:17 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, Florian Fainelli
Hi David,
Small patch series fixing a comment for mdio_module_driver and
finally utilizing it in b53_mdio.
Thanks!
Florian Fainelli (2):
net: phy: Fix typo for MDIO module boilerplate comment
net: dsa: b53: Utilize mdio_module_driver
drivers/net/dsa/b53/b53_mdio.c | 13 +------------
include/linux/mdio.h | 2 +-
2 files changed, 2 insertions(+), 13 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: ignore null_entry on route dumps
From: David Miller @ 2017-01-23 4:58 UTC (permalink / raw)
To: dsa; +Cc: netdev, xiaolong.ye
In-Reply-To: <1485147377-11922-1-git-send-email-dsa@cumulusnetworks.com>
David, please slow down.
How is the NULL entry getting selected to be dumped and passed
down here in the first place?
The problem seems to be higher up in the chain here, don't
just special case check for this in rt6_dump_route().
Thanks.
^ permalink raw reply
* [PATCH net-next] net: ipv6: ignore null_entry on route dumps
From: David Ahern @ 2017-01-23 4:56 UTC (permalink / raw)
To: netdev; +Cc: xiaolong.ye, David Ahern
lkp-robot reported a BUG:
[ 10.151226] BUG: unable to handle kernel NULL pointer dereference at 00000198
[ 10.152525] IP: rt6_fill_node+0x164/0x4b8
[ 10.153307] *pdpt = 0000000012ee5001 *pde = 0000000000000000
[ 10.153309]
[ 10.154492] Oops: 0000 [#1]
[ 10.154987] CPU: 0 PID: 909 Comm: netifd Not tainted 4.10.0-rc4-00722-g41e8c70ee162-dirty #10
[ 10.156482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 10.158254] task: d0deb000 task.stack: d0e0c000
[ 10.159059] EIP: rt6_fill_node+0x164/0x4b8
[ 10.159780] EFLAGS: 00010296 CPU: 0
[ 10.160404] EAX: 00000000 EBX: d10c2358 ECX: c1f7c6cc EDX: c1f6ff44
[ 10.161469] ESI: 00000000 EDI: c2059900 EBP: d0e0dc4c ESP: d0e0dbe4
[ 10.162534] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[ 10.163482] CR0: 80050033 CR2: 00000198 CR3: 10d94660 CR4: 000006b0
[ 10.164535] Call Trace:
[ 10.164993] ? paravirt_sched_clock+0x9/0xd
[ 10.165727] ? sched_clock+0x9/0xc
[ 10.166329] ? sched_clock_cpu+0x19/0xe9
[ 10.166991] ? lock_release+0x13e/0x36c
[ 10.167652] rt6_dump_route+0x4c/0x56
[ 10.168276] fib6_dump_node+0x1d/0x3d
[ 10.168913] fib6_walk_continue+0xab/0x167
[ 10.169611] fib6_walk+0x2a/0x40
[ 10.170182] inet6_dump_fib+0xfb/0x1e0
[ 10.170855] netlink_dump+0xcd/0x21f
This happens when the loopback device is set down and a ipv6 fib route
dump is requested.
The ipv6 route dump code passes ip6_null_entry to rt6_fill_node. This
route uses the loopback device but does not have idev set. When the
loopback is set down, the netif_running check added by a1a22c1206 fails
and the fill_node descends to checking rt->rt6i_idev for
ignore_routes_with_linkdown. Since idev is null for the ip6_null_entry
route it triggers the BUG.
The null_entry route should not be processed in a dump request. Catch
and ignore.
Fixes: a1a22c1206("net: ipv6: Keep nexthop of multipath route on admin down")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv6/route.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 4b1f0f98a0e9..47499ed429da 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3320,6 +3320,10 @@ static int rt6_fill_node(struct net *net,
int rt6_dump_route(struct rt6_info *rt, void *p_arg)
{
struct rt6_rtnl_dump_arg *arg = (struct rt6_rtnl_dump_arg *) p_arg;
+ struct net *net = arg->net;
+
+ if (rt == net->ipv6.ip6_null_entry)
+ return 0;
if (nlmsg_len(arg->cb->nlh) >= sizeof(struct rtmsg)) {
struct rtmsg *rtm = nlmsg_data(arg->cb->nlh);
@@ -3332,7 +3336,7 @@ int rt6_dump_route(struct rt6_info *rt, void *p_arg)
}
}
- return rt6_fill_node(arg->net,
+ return rt6_fill_node(net,
arg->skb, rt, NULL, NULL, 0, RTM_NEWROUTE,
NETLINK_CB(arg->cb->skb).portid, arg->cb->nlh->nlmsg_seq,
NLM_F_MULTI);
--
2.1.4
^ permalink raw reply related
* RE: [PATCH v3 net-next] net: mvneta: implement .set_wol and .get_wol
From: YUAN Linyu @ 2017-01-23 4:55 UTC (permalink / raw)
To: Jingju Hou, davem@davemloft.net
Cc: jszhang@marvell.com, thomas.petazzoni@free-electrons.com,
netdev@vger.kernel.org
In-Reply-To: <1485144678-11777-1-git-send-email-houjingj@marvell.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Jingju Hou
> Sent: Monday, January 23, 2017 12:11 PM
> To: davem@davemloft.net
> Cc: jszhang@marvell.com; thomas.petazzoni@free-electrons.com;
> netdev@vger.kernel.org; Jingju Hou
> Subject: [PATCH v3 net-next] net: mvneta: implement .set_wol and .get_wol
>
> The mvneta itself does not support WOL, but the PHY might.
> So pass the calls to the PHY
>
> Signed-off-by: Jingju Hou <houjingj@marvell.com>
> ---
> Since v2:
> - it should be phydev member not phy_dev
>
> drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c
> b/drivers/net/ethernet/marvell/mvneta.c
> index e05e227..fea4968 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3908,6 +3908,25 @@ static int mvneta_ethtool_get_rxfh(struct
> net_device *dev, u32 *indir, u8 *key,
> return 0;
> }
>
> +static void
> +mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo
> *wol)
> +{
> + wol->supported = 0;
> + wol->wolopts = 0;
> +
> + if (dev->phy_dev)
Not changed,
> + return phy_ethtool_get_wol(dev->phydev, wol);
> +}
> +
> +static int
> +mvneta_ethtool_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> +{
> + if (!dev->phydev)
> + return -EOPNOTSUPP;
> +
> + return phy_ethtool_set_wol(dev->phydev, wol);
> +}
> +
> static const struct net_device_ops mvneta_netdev_ops = {
> .ndo_open = mvneta_open,
> .ndo_stop = mvneta_stop,
> @@ -3937,6 +3956,8 @@ static int mvneta_ethtool_get_rxfh(struct
> net_device *dev, u32 *indir, u8 *key,
> .set_rxfh = mvneta_ethtool_set_rxfh,
> .get_link_ksettings = phy_ethtool_get_link_ksettings,
> .set_link_ksettings = mvneta_ethtool_set_link_ksettings,
> + .get_wol = mvneta_ethtool_get_wol,
> + .set_wol = mvneta_ethtool_set_wol,
> };
>
> /* Initialize hw */
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Check that idev is non-NULL in rt6_fill_node
From: David Ahern @ 2017-01-23 4:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, xiaolong.ye
In-Reply-To: <20170122.233239.720617884825007357.davem@davemloft.net>
On 1/22/17 9:32 PM, David Miller wrote:
> From: David Ahern <dsa@cumulusnetworks.com>
> Date: Sun, 22 Jan 2017 20:08:00 -0800
>
>> The ipv6 route dump code passes ip6_null_entry to rt6_fill_node.
>
> Doesn't this fact cause you to take a pause?
yes, it did.
>
> I can't see a legitimate reason to dump the null entry, it's
> a marker rather than a real entry.
>
neither do I. I was rather surprised to see it hit rt6_fill_node and that the rc is 0.
I can send a v2 that drops null_entry.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Check that idev is non-NULL in rt6_fill_node
From: David Miller @ 2017-01-23 4:32 UTC (permalink / raw)
To: dsa; +Cc: netdev, xiaolong.ye
In-Reply-To: <1485144480-4460-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Sun, 22 Jan 2017 20:08:00 -0800
> The ipv6 route dump code passes ip6_null_entry to rt6_fill_node.
Doesn't this fact cause you to take a pause?
I can't see a legitimate reason to dump the null entry, it's
a marker rather than a real entry.
^ permalink raw reply
* Re: Potential issues (security and otherwise) with the current cgroup-bpf API
From: Alexei Starovoitov @ 2017-01-23 4:31 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Tejun Heo, Michal Hocko, Peter Zijlstra, David Ahern,
Andy Lutomirski, Daniel Mack, Mickaël Salaün, Kees Cook,
Jann Horn, David S. Miller, Thomas Graf, Michael Kerrisk,
Linux API, linux-kernel@vger.kernel.org, Network Development
In-Reply-To: <CALCETrV6NArtFa89iW+QO3udxpJYpMXLbOEk6ZYyWsw7oZDS2Q@mail.gmail.com>
On Thu, Jan 19, 2017 at 08:04:59PM -0800, Andy Lutomirski wrote:
> On Thu, Jan 19, 2017 at 6:39 PM, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > On Wed, Jan 18, 2017 at 06:29:22PM -0800, Andy Lutomirski wrote:
> >> I think it could work by making a single socket cgroup controller that
> >> handles all cgroup things that are bound to a socket. Using
> >
> > Such 'socket cgroup controller' would limit usability of the feature
> > to sockets and force all other use cases like landlock to invent
> > their own wheel, which is undesirable. Everyone will be
> > inventing new 'foo cgroup controller', while all of them
> > are really bpf features. They are different bpf program
> > types that attach to different hooks and use cgroup for scoping.
>
> Can you elaborate on why that would be a problem? In a cgroup v1
> world, users who want different hierarchies for different types of
> control could easily want one hierarchy for socket hooks and a
> different hierarchy for lsm hooks. In a cgroup v2 delegation world, I
> could easily imagine the decision to delegate socket hooks being
> different from the decision to delegate lsm hooks. Almost all of the
> code would be shared between different bpf-using cgroup controllers.
how do you think it can be enforced when directory is chowned?
> >> Having thought about this some more, I think that making it would
> >> alleviate a bunch of my concerns, as it would make the semantics if
> >> the capable() check were relaxed to ns_capable() be sane. Here's what
> >
> > here we're on the same page. For any meaningful discussion about
> > 'bpf cgroup controller' to happen bpf itself needs to become
> > delegatable in cgroup sense. In other words BPF_PROG_TYPE_CGROUP*
> > program types need to become available for unprivileged users.
> > The only unprivileged prog type today is BPF_PROG_TYPE_SOCKET_FILTER.
> > To make it secure we severely limited its functionality.
> > All bpf advances since then (like new map types and verifier extensions)
> > were done for root only. If early on the priv vs unpriv bpf features
> > were 80/20. Now it's close to 95/5. No work has been done to
> > make socket filter type more powerful. It still has to use
> > slow-ish ld_abs skb access while tc/xdp have direct packet access.
> > Things like register value tracking is root only as well and so on
> > and so forth.
> > We cannot just flip the switch and allow type_cgroup* to unpriv
> > and I don't see any volunteers willing to do this work.
> > Until that happens there is no point coming up with designs
> > for 'cgroup bpf controller'... whatever that means.
>
> Sure there is. If delegation can be turned on without changing the
> API, then the result will be easier to work with and have fewer
> compatibility issues.
... and open() of the directory done by the current api will preserve
cgroup delegation when and only when bpf_prog_type_cgroup_*
becomes unprivileged.
I'm not proposing creating new api here.
> >
> >> I currently should happen before bpf+cgroup is enabled in a release:
> >>
> >> 1. Make it netns-aware. This could be as simple as making it only
> >> work in the root netns because then real netns awareness can be added
> >> later without breaking anything. The current situation is bad in that
> >> network namespaces are just ignored and it's plausible that people
> >> will start writing user code that depends on having network namespaces
> >> be ignored.
> >
> > nothing in bpf today is netns-aware and frankly I don't see
> > how cgroup+bpf has anything to do with netns.
> > For regular sockets+bpf we don't check netns.
> > When tcpdump opens raw socket and attaches bpf there are no netns
> > checks, since socket itself gives a scope for the program to run.
> > Same thing applies to cgroup+bpf. cgroup gives a scope for the program.
> > But, say, we indeed add 'if !root ns' check to BPF_CGROUP_INET_*
> > hooks.
>
>
> Here I completely disagree with you. tcpdump sees packets in its
> network namespace. Regular sockets apply bpf filters to the packets
> seen by that socket, and the socket itself is scoped to a netns.
>
> Meanwhile, cgroup+bpf actually appears to be buggy in this regard even
> regardless of what semantics you think are better. sk_bound_dev_if is
> exposed as a u32 value, but sk_bound_dev_if only has meaning within a
> given netns. The "ip vrf" stuff will straight-up malfunction if a
> process affected by its hook runs in a different netns from the netns
> that "ip vrf" was run in.
how is that any different from normal 'ip netns exec'?
that is expected user behavior.
> IOW, the current code is buggy.
>
> > Then if the hooks are used for security, the process
> > only needs to do setns() to escape security sandbox. Obviously
> > broken semantics.
>
> This could go both ways. If the goal is to filter packets, then it's
> not really important to have the filter keep working if the sandboxed
> task unshares netns -- in the new netns, there isn't any access to the
> network at all. If the goal is to reduce attack surface by
in container networking based on netns all netns-es are connected
at l2 or l3, whereas socket is l4+ abstraction. Therefore doing
'if (!root_ns) allow' at socket layer is simply broken from security
point of view.
> restricting the types of sockets that can be created, then you do want
> the filter to work across namespaces, but seccomp can do that too and
> the current code doesn't handle netns correctly.
are you saying that seccomp supports netns filtering? please show the proof.
> >> 2. Make it inherit properly. Inner cgroups should not override outer
> >> hooks. As in (1), this could be simplified by preventing the same
> >> hook from being configured in both an ancestor and a descendent
> >> cgroup. Then inheritance could be added for real later on.
> >
> > In general it sounds fine, but it seems the reasoning to add
> > such restriction now (instead of later), so that program chain can
> > be added without breaking abi, since if we don't restrict it now
> > there will be no way to add it without breaking abi?!
>
> Adding it the straightforward way (by simply making all the hooks in
> scope run) would break ABI. Of course there are more complicated ways
> to do it, but those are more complicated and messier. Do actually
adding 'prog override is not allowed' flag will obviously _not_ break abi.
If program is attached to a cgroup in this mode, the descendants won't
be able to attach. Trivial boolean flag check at attach time.
Just like 'priority' mode will not break it.
> have a use case in which overriding of hooks is a good thing? As far
> as I can tell, the original version of the patch set didn't have hooks
> get overridden by descendents, and I don't know why this changed in
> the first place.
what's been missing since the beginning of the thread that cgroup+bpf is
the bpf feature and on bpf side we can handle program chaining with priority
in flexible way. bpf prog needs to be able to attach to descendent
and make sure that the attached program is the only one that makes the
decision. Our main use case is application network analytics and
enforcement when apps are not malicious. In this case the container
management framework will attach one program to a particular
part of the hierarchy and will create whatever necessary combinations
of the programs for descendents, since it's one common framework
for them all and running single program is faster than walking link lists
and doing parsing and IP lookups several times. It's often the case that
prep work like skb parsing and map lookups are common across programs, but
filtering/monitoring logic is different, so dumb link list and call
all programs one by one is inferior. Whereas multiple program combining on
the user space side can be done efficiently.
To summarize, I think the 'prog override is not allowed' flag would be
ok feature to have and I wouldn't mind making it the default when no 'flag'
field is passed to bpf syscall, but it's not acceptable to remove current
'prog override is allowed' behavior.
So if you insist on changing the default, please implement the flag asap.
Though from security point of view and ABI point of view there is absolutely
no difference whether this flag is added today or a year later while
the default is kept as-is.
> > Also until bpf_type_cgroup* becomes unprivileged there is no reason
> > to add this 'priority/prog chaining' feature, since if it's
> > used for security the root can always override it no matter cgroup
> > hierarchy.
> >
> >> 3. Give cgroup delegation support some serious thought. In
> >> particular, if delegation would be straightforward but the current API
> >> wouldn't work well with delegation, then at least consider whether the
> >> API should change before it becomes stable so that two APIs don't need
> >> to be supported going forward.
> >
> > please see example above. Since we went with bpf syscall (instead of
> > inextensible ioctl) we can add any new cgroup+bpf logic without
> > breaking current abi.
>
> But then you end up with two ABIs. Ideally delegation would just work
> -- then programs written now could run unmodified in unprivileged
> containers in future kernels.
At this point I don't see a reason to have two APIs.
When bpf_type_cgroup* becomes available to unprivileged users
the same api will work as-is.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: mvneta: implement .set_wol and .get_wol
From: David Miller @ 2017-01-23 4:29 UTC (permalink / raw)
To: houjingj; +Cc: jszhang, thomas.petazzoni, netdev
In-Reply-To: <1485144678-11777-1-git-send-email-houjingj@marvell.com>
From: Jingju Hou <houjingj@marvell.com>
Date: Mon, 23 Jan 2017 12:11:18 +0800
> The mvneta itself does not support WOL, but the PHY might.
> So pass the calls to the PHY
>
> Signed-off-by: Jingju Hou <houjingj@marvell.com>
> ---
> Since v2:
> - it should be phydev member not phy_dev
>
> drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index e05e227..fea4968 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3908,6 +3908,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
> return 0;
> }
>
> +static void
> +mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> +{
> + wol->supported = 0;
> + wol->wolopts = 0;
> +
> + if (dev->phy_dev)
You are not testing the build of this patch, you are still using
phy_dev here. Either that or your commit message is not accurate.
Either way this patch or it's commit message is wrong.
I think you need to stop, take a deep breath, and take your time
fixing this.
Right now you are spitting out a new patch just minutes after
a previous submission, and these patches still have the same
bugs.
^ permalink raw reply
* Re: [PATCHv2 net-next] net: mvneta: implement .set_wol and .get_wol
From: David Miller @ 2017-01-23 4:27 UTC (permalink / raw)
To: lkp; +Cc: houjingj, kbuild-all, jszhang, thomas.petazzoni, netdev
In-Reply-To: <201701231207.slqpC1Wl%fengguang.wu@intel.com>
The same build error exists in all submissions of your patch.
At this point you must absolutely reproduce this build failure
yourself, and stop submitting this patch until you can test that the
build failure is fixed.
^ permalink raw reply
* [PATCH v3 net-next] net: mvneta: implement .set_wol and .get_wol
From: Jingju Hou @ 2017-01-23 4:11 UTC (permalink / raw)
To: davem; +Cc: jszhang, thomas.petazzoni, netdev, Jingju Hou
The mvneta itself does not support WOL, but the PHY might.
So pass the calls to the PHY
Signed-off-by: Jingju Hou <houjingj@marvell.com>
---
Since v2:
- it should be phydev member not phy_dev
drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index e05e227..fea4968 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3908,6 +3908,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
return 0;
}
+static void
+mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ wol->supported = 0;
+ wol->wolopts = 0;
+
+ if (dev->phy_dev)
+ return phy_ethtool_get_wol(dev->phydev, wol);
+}
+
+static int
+mvneta_ethtool_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ if (!dev->phydev)
+ return -EOPNOTSUPP;
+
+ return phy_ethtool_set_wol(dev->phydev, wol);
+}
+
static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open = mvneta_open,
.ndo_stop = mvneta_stop,
@@ -3937,6 +3956,8 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
.set_rxfh = mvneta_ethtool_set_rxfh,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = mvneta_ethtool_set_link_ksettings,
+ .get_wol = mvneta_ethtool_get_wol,
+ .set_wol = mvneta_ethtool_set_wol,
};
/* Initialize hw */
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] net: ipv6: Check that idev is non-NULL in rt6_fill_node
From: David Ahern @ 2017-01-23 4:08 UTC (permalink / raw)
To: netdev; +Cc: xiaolong.ye, David Ahern
lkp-robot reported a BUG:
[ 10.151226] BUG: unable to handle kernel NULL pointer dereference at 00000198
[ 10.152525] IP: rt6_fill_node+0x164/0x4b8
[ 10.153307] *pdpt = 0000000012ee5001 *pde = 0000000000000000
[ 10.153309]
[ 10.154492] Oops: 0000 [#1]
[ 10.154987] CPU: 0 PID: 909 Comm: netifd Not tainted 4.10.0-rc4-00722-g41e8c70ee162-dirty #10
[ 10.156482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 10.158254] task: d0deb000 task.stack: d0e0c000
[ 10.159059] EIP: rt6_fill_node+0x164/0x4b8
[ 10.159780] EFLAGS: 00010296 CPU: 0
[ 10.160404] EAX: 00000000 EBX: d10c2358 ECX: c1f7c6cc EDX: c1f6ff44
[ 10.161469] ESI: 00000000 EDI: c2059900 EBP: d0e0dc4c ESP: d0e0dbe4
[ 10.162534] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[ 10.163482] CR0: 80050033 CR2: 00000198 CR3: 10d94660 CR4: 000006b0
[ 10.164535] Call Trace:
[ 10.164993] ? paravirt_sched_clock+0x9/0xd
[ 10.165727] ? sched_clock+0x9/0xc
[ 10.166329] ? sched_clock_cpu+0x19/0xe9
[ 10.166991] ? lock_release+0x13e/0x36c
[ 10.167652] rt6_dump_route+0x4c/0x56
[ 10.168276] fib6_dump_node+0x1d/0x3d
[ 10.168913] fib6_walk_continue+0xab/0x167
[ 10.169611] fib6_walk+0x2a/0x40
[ 10.170182] inet6_dump_fib+0xfb/0x1e0
[ 10.170855] netlink_dump+0xcd/0x21f
This happens when the loopback device is set down and a ipv6 fib route
dump is requested.
The ipv6 route dump code passes ip6_null_entry to rt6_fill_node. This
route uses the loopback device but does not have idev set. When the
loopback is set down, the netif_running check added by a1a22c1206 fails
and the fill_node descends to checking rt->rt6i_idev for
ignore_routes_with_linkdown. Since idev is null for the ip6_null_entry
route it triggers the BUG.
Fixes: a1a22c1206("net: ipv6: Keep nexthop of multipath route on admin down")
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/ipv6/route.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 5585c501a540..9a7cc7558104 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3218,7 +3218,8 @@ static int rt6_fill_node(struct net *net,
rtm->rtm_flags = 0;
if (!netif_carrier_ok(rt->dst.dev)) {
rtm->rtm_flags |= RTNH_F_LINKDOWN;
- if (rt->rt6i_idev->cnf.ignore_routes_with_linkdown)
+ if (rt->rt6i_idev &&
+ rt->rt6i_idev->cnf.ignore_routes_with_linkdown)
rtm->rtm_flags |= RTNH_F_DEAD;
}
rtm->rtm_scope = RT_SCOPE_UNIVERSE;
--
2.1.4
^ permalink raw reply related
* Re: [PATCHv2 net-next] net: mvneta: implement .set_wol and .get_wol
From: kbuild test robot @ 2017-01-23 4:04 UTC (permalink / raw)
To: Jingju Hou
Cc: kbuild-all, davem, jszhang, thomas.petazzoni, netdev, Jingju Hou
In-Reply-To: <1485139447-11067-1-git-send-email-houjingj@marvell.com>
[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]
Hi Jingju,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jingju-Hou/net-mvneta-implement-set_wol-and-get_wol/20170123-105218
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All errors (new ones prefixed by >>):
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_ethtool_get_wol':
>> drivers/net/ethernet/marvell/mvneta.c:3938:9: error: 'struct net_device' has no member named 'phy_dev'
if (dev->phy_dev)
^
drivers/net/ethernet/marvell/mvneta.c:3939:33: error: 'struct net_device' has no member named 'phy_dev'
return phy_ethtool_get_wol(dev->phy_dev, wol);
^
drivers/net/ethernet/marvell/mvneta.c:3939:3: warning: 'return' with a value, in function returning void
return phy_ethtool_get_wol(dev->phy_dev, wol);
^
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_ethtool_set_wol':
drivers/net/ethernet/marvell/mvneta.c:3945:10: error: 'struct net_device' has no member named 'phy_dev'
if (!dev->phy_dev)
^
drivers/net/ethernet/marvell/mvneta.c:3948:32: error: 'struct net_device' has no member named 'phy_dev'
return phy_ethtool_set_wol(dev->phy_dev, wol);
^
drivers/net/ethernet/marvell/mvneta.c:3949:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
vim +3938 drivers/net/ethernet/marvell/mvneta.c
3932 static void
3933 mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
3934 {
3935 wol->supported = 0;
3936 wol->wolopts = 0;
3937
> 3938 if (dev->phy_dev)
3939 return phy_ethtool_get_wol(dev->phy_dev, wol);
3940 }
3941
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 39187 bytes --]
^ permalink raw reply
* Re: [PATCHv2 net-next] net: mvneta: implement .set_wol and .get_wol
From: kbuild test robot @ 2017-01-23 4:02 UTC (permalink / raw)
To: Jingju Hou
Cc: kbuild-all, davem, jszhang, thomas.petazzoni, netdev, Jingju Hou
In-Reply-To: <1485139447-11067-1-git-send-email-houjingj@marvell.com>
[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]
Hi Jingju,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jingju-Hou/net-mvneta-implement-set_wol-and-get_wol/20170123-105218
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All errors (new ones prefixed by >>):
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_ethtool_get_wol':
>> drivers/net/ethernet/marvell/mvneta.c:3938:9: error: 'struct net_device' has no member named 'phy_dev'; did you mean 'phydev'?
if (dev->phy_dev)
^~
drivers/net/ethernet/marvell/mvneta.c:3939:33: error: 'struct net_device' has no member named 'phy_dev'; did you mean 'phydev'?
return phy_ethtool_get_wol(dev->phy_dev, wol);
^~
drivers/net/ethernet/marvell/mvneta.c:3939:10: warning: 'return' with a value, in function returning void
return phy_ethtool_get_wol(dev->phy_dev, wol);
^~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/marvell/mvneta.c:3933:1: note: declared here
mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_ethtool_set_wol':
drivers/net/ethernet/marvell/mvneta.c:3945:10: error: 'struct net_device' has no member named 'phy_dev'; did you mean 'phydev'?
if (!dev->phy_dev)
^~
drivers/net/ethernet/marvell/mvneta.c:3948:32: error: 'struct net_device' has no member named 'phy_dev'; did you mean 'phydev'?
return phy_ethtool_set_wol(dev->phy_dev, wol);
^~
drivers/net/ethernet/marvell/mvneta.c:3949:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
vim +3938 drivers/net/ethernet/marvell/mvneta.c
3932 static void
3933 mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
3934 {
3935 wol->supported = 0;
3936 wol->wolopts = 0;
3937
> 3938 if (dev->phy_dev)
3939 return phy_ethtool_get_wol(dev->phy_dev, wol);
3940 }
3941
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 45821 bytes --]
^ permalink raw reply
* EPOLLERR on memory mapped netlink socket
From: prashantkumar dhotre @ 2017-01-23 3:49 UTC (permalink / raw)
To: netdev
Hi experts,
I am new to netlink sockets.
In my app , I am getting EPOLLERR in epoll_wait() on netlink socket
continuously.
epoll just notifies that there is a read event on socket (it does not
tell if it is read or epollerr).
What could be cause of this and what EPOLLERR on memory mapped netlink
socket mean.is this Other side of netlink (kernel side) closed
connection ?even if kernel side closed connection why non-stop
repeated EPOLLERR s on netlink sockets ?
What action should we take in such cases ? just close the socket or
call getsockopt(SO_ERROR) to retrieve the pending error state from the
socket and just continue without closing socket?
how do we detect if kernel side closed the connection ?
My understanding is :
if we get read event notification from epoll on memory mapped netlink
socket and in RX ring if the frame is neither NL_MMAP_STATUS_VALID and
nor NL_MMAP_STATUS_COPY then we can conclude that this is a 'close()'
from remote kernel socket and I can close connection by calling
close() on my netlink socket.
Is above understanding correct ?
Please
^ permalink raw reply
* Re: [PATCH v2 net-next] net: phy: marvell: Add Wake from LAN support for 88E1510 PHY
From: Jisheng Zhang @ 2017-01-23 3:00 UTC (permalink / raw)
To: Jingju Hou; +Cc: davem, thomas.petazzoni, netdev
In-Reply-To: <1485140295-11339-1-git-send-email-houjingj@marvell.com>
On Mon, 23 Jan 2017 10:58:15 +0800 wrote:
> This is test on BG4CT platform with 88E1518 marvell PHY.
>
> Signed-off-by: Jingju Hou <houjingj@marvell.com>
Reviewed-by: Jisheng Zhang <jszhang@marvell.com>
> ---
> Since v1:
> - add some commit messages
>
> drivers/net/phy/marvell.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 0b78210..ed0d235 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -1679,6 +1679,8 @@ static int marvell_probe(struct phy_device *phydev)
> .ack_interrupt = &marvell_ack_interrupt,
> .config_intr = &marvell_config_intr,
> .did_interrupt = &m88e1121_did_interrupt,
> + .get_wol = &m88e1318_get_wol,
> + .set_wol = &m88e1318_set_wol,
> .resume = &marvell_resume,
> .suspend = &marvell_suspend,
> .get_sset_count = marvell_get_sset_count,
^ permalink raw reply
* Re: [PATCH] net: mvneta: implement .set_wol and .get_wol
From: Jisheng Zhang @ 2017-01-23 2:58 UTC (permalink / raw)
To: Jingju Hou; +Cc: davem, thomas.petazzoni, netdev
In-Reply-To: <1485139388-11003-1-git-send-email-houjingj@marvell.com>
Hi Jingju,
On Mon, 23 Jan 2017 10:43:08 +0800 wrote:
> The mvneta itself does not support WOL, but the PHY might.
> So pass the calls to the PHY
>
> Signed-off-by: Jingju Hou <houjingj@marvell.com>
> ---
> Since v1:
> - using phy_dev member in struct net_device
I noticed that you send a new v2 patch. So this patch should be ignored.
Some tips:
*the v2 patch title should be like:
[PATCH v2] net: mvneta: implement .set_wol and .get_wol
*you also add a commit msg in v2, you'd better mention it
in changes since v1.
Thanks,
Jisheng
>
> drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index e05e227..78869fa 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3908,6 +3908,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
> return 0;
> }
>
> +static void
> +mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> +{
> + wol->supported = 0;
> + wol->wolopts = 0;
> +
> + if (dev->phy_dev)
> + return phy_ethtool_get_wol(dev->phy_dev, wol);
> +}
> +
> +static int
> +mvneta_ethtool_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> +{
> + if (!dev->phy_dev)
> + return -EOPNOTSUPP;
> +
> + return phy_ethtool_set_wol(dev->phy_dev, wol);
> +}
> +
> static const struct net_device_ops mvneta_netdev_ops = {
> .ndo_open = mvneta_open,
> .ndo_stop = mvneta_stop,
> @@ -3937,6 +3956,8 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
> .set_rxfh = mvneta_ethtool_set_rxfh,
> .get_link_ksettings = phy_ethtool_get_link_ksettings,
> .set_link_ksettings = mvneta_ethtool_set_link_ksettings,
> + .get_wol = mvneta_ethtool_get_wol,
> + .set_wol = mvneta_ethtool_set_wol,
> };
>
> /* Initialize hw */
^ permalink raw reply
* [PATCH v2 net-next] net: phy: marvell: Add Wake from LAN support for 88E1510 PHY
From: Jingju Hou @ 2017-01-23 2:58 UTC (permalink / raw)
To: davem, thomas.petazzoni; +Cc: jszhang, netdev, Jingju Hou
This is test on BG4CT platform with 88E1518 marvell PHY.
Signed-off-by: Jingju Hou <houjingj@marvell.com>
---
Since v1:
- add some commit messages
drivers/net/phy/marvell.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 0b78210..ed0d235 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1679,6 +1679,8 @@ static int marvell_probe(struct phy_device *phydev)
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.did_interrupt = &m88e1121_did_interrupt,
+ .get_wol = &m88e1318_get_wol,
+ .set_wol = &m88e1318_set_wol,
.resume = &marvell_resume,
.suspend = &marvell_suspend,
.get_sset_count = marvell_get_sset_count,
--
1.9.1
^ permalink raw reply related
* Re: [PATCHv2 net-next] net: mvneta: implement .set_wol and .get_wol
From: Jisheng Zhang @ 2017-01-23 2:52 UTC (permalink / raw)
To: Jingju Hou; +Cc: davem, thomas.petazzoni, netdev
In-Reply-To: <1485139447-11067-1-git-send-email-houjingj@marvell.com>
On Mon, 23 Jan 2017 10:44:07 +0800
Jingju Hou <houjingj@marvell.com> wrote:
> The mvneta itself does not support WOL, but the PHY might.
> So pass the calls to the PHY
>
> Signed-off-by: Jingju Hou <houjingj@marvell.com>
Reviewed-by: Jisheng Zhang <jszhang@marvell.com>
> ---
> Since v1:
> - using phy_dev member in struct net_device
>
> drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index e05e227..78869fa 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3908,6 +3908,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
> return 0;
> }
>
> +static void
> +mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> +{
> + wol->supported = 0;
> + wol->wolopts = 0;
> +
> + if (dev->phy_dev)
> + return phy_ethtool_get_wol(dev->phy_dev, wol);
> +}
> +
> +static int
> +mvneta_ethtool_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> +{
> + if (!dev->phy_dev)
> + return -EOPNOTSUPP;
> +
> + return phy_ethtool_set_wol(dev->phy_dev, wol);
> +}
> +
> static const struct net_device_ops mvneta_netdev_ops = {
> .ndo_open = mvneta_open,
> .ndo_stop = mvneta_stop,
> @@ -3937,6 +3956,8 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
> .set_rxfh = mvneta_ethtool_set_rxfh,
> .get_link_ksettings = phy_ethtool_get_link_ksettings,
> .set_link_ksettings = mvneta_ethtool_set_link_ksettings,
> + .get_wol = mvneta_ethtool_get_wol,
> + .set_wol = mvneta_ethtool_set_wol,
> };
>
> /* Initialize hw */
^ permalink raw reply
* Business Proposal
From: Quatif Group of Companies @ 2017-01-21 16:55 UTC (permalink / raw)
Dear Friend,
I would like to discuss a very important issue with you. I am writing to
find out if this is your valid email. Please, let me know if this email is
valid
Kind regards
Adrien Saif
Attorney to Quatif Group of Companies
^ permalink raw reply
* [PATCHv2 net-next] net: mvneta: implement .set_wol and .get_wol
From: Jingju Hou @ 2017-01-23 2:44 UTC (permalink / raw)
To: davem; +Cc: jszhang, thomas.petazzoni, netdev, Jingju Hou
The mvneta itself does not support WOL, but the PHY might.
So pass the calls to the PHY
Signed-off-by: Jingju Hou <houjingj@marvell.com>
---
Since v1:
- using phy_dev member in struct net_device
drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index e05e227..78869fa 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3908,6 +3908,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
return 0;
}
+static void
+mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ wol->supported = 0;
+ wol->wolopts = 0;
+
+ if (dev->phy_dev)
+ return phy_ethtool_get_wol(dev->phy_dev, wol);
+}
+
+static int
+mvneta_ethtool_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ if (!dev->phy_dev)
+ return -EOPNOTSUPP;
+
+ return phy_ethtool_set_wol(dev->phy_dev, wol);
+}
+
static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open = mvneta_open,
.ndo_stop = mvneta_stop,
@@ -3937,6 +3956,8 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
.set_rxfh = mvneta_ethtool_set_rxfh,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = mvneta_ethtool_set_link_ksettings,
+ .get_wol = mvneta_ethtool_get_wol,
+ .set_wol = mvneta_ethtool_set_wol,
};
/* Initialize hw */
--
1.9.1
^ permalink raw reply related
* [PATCH] net: mvneta: implement .set_wol and .get_wol
From: Jingju Hou @ 2017-01-23 2:43 UTC (permalink / raw)
To: davem; +Cc: jszhang, thomas.petazzoni, netdev, Jingju Hou
The mvneta itself does not support WOL, but the PHY might.
So pass the calls to the PHY
Signed-off-by: Jingju Hou <houjingj@marvell.com>
---
Since v1:
- using phy_dev member in struct net_device
drivers/net/ethernet/marvell/mvneta.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index e05e227..78869fa 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3908,6 +3908,25 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
return 0;
}
+static void
+mvneta_ethtool_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ wol->supported = 0;
+ wol->wolopts = 0;
+
+ if (dev->phy_dev)
+ return phy_ethtool_get_wol(dev->phy_dev, wol);
+}
+
+static int
+mvneta_ethtool_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
+{
+ if (!dev->phy_dev)
+ return -EOPNOTSUPP;
+
+ return phy_ethtool_set_wol(dev->phy_dev, wol);
+}
+
static const struct net_device_ops mvneta_netdev_ops = {
.ndo_open = mvneta_open,
.ndo_stop = mvneta_stop,
@@ -3937,6 +3956,8 @@ static int mvneta_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 *key,
.set_rxfh = mvneta_ethtool_set_rxfh,
.get_link_ksettings = phy_ethtool_get_link_ksettings,
.set_link_ksettings = mvneta_ethtool_set_link_ksettings,
+ .get_wol = mvneta_ethtool_get_wol,
+ .set_wol = mvneta_ethtool_set_wol,
};
/* Initialize hw */
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox