* Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
From: Tom Herbert @ 2016-11-01 16:17 UTC (permalink / raw)
To: Thomas Graf
Cc: David S. Miller, Alexei Starovoitov, Daniel Borkmann, roopa,
Linux Kernel Network Developers
In-Reply-To: <cover.1477959702.git.tgraf@suug.ch>
On Mon, Oct 31, 2016 at 5:37 PM, Thomas Graf <tgraf@suug.ch> wrote:
> {Open question:
> Tom brought up the question on whether it is safe to modify the packet
> in artbirary ways before dst_output(). This is the equivalent to a raw
> socket injecting illegal headers. This v2 currently assumes that
> dst_output() is ready to accept invalid header values. This needs to be
> verified and if not the case, then raw sockets or dst_output() handlers
> must be fixed as well. Another option is to mark lwtunnel_output() as
> read-only for now.}
>
The question might not be so much about illegal headers but whether
fields in the skbuff related to the packet contents are kept correct.
We have protocol, header offsets, offsets for inner protocols also,
encapsulation settings, checksum status, checksum offset, checksum
complete value, vlan information. Any or all of which I believe could
be turned into being incorrect if we allow the packet to be
arbitrarily modified by BPF. This problem is different than raw
sockets because LWT operates in the middle of the stack, the skbuff
has already been set up which such things.
> This series implements BPF program invocation from dst entries via the
> lightweight tunnels infrastructure. The BPF program can be attached to
> lwtunnel_input(), lwtunnel_output() or lwtunnel_xmit() and sees an L3
> skb as context. input is read-only, output can write, xmit can write,
> push headers, and redirect.
>
> Motiviation for this work:
> - Restricting outgoing routes beyond what the route tuple supports
> - Per route accounting byond realms
> - Fast attachment of L2 headers where header does not require resolving
> L2 addresses
> - ILA like uses cases where L3 addresses are resolved and then routed
> in an async manner
> - Fast encapsulation + redirect. For now limited to use cases where not
> setting inner and outer offset/protocol is OK.
>
Is checksum offload supported? By default, at least for Linux, we
offload the outer UDP checksum in VXLAN and the other UDP
encapsulations for performance.
Tom
> A couple of samples on how to use it can be found in patch 04.
>
> v1 -> v2:
> - Added new BPF_LWT_REROUTE return code for program to indicate
> that new route lookup should be performed. Suggested by Tom.
> - New sample to illustrate rerouting
> - New patch 05: Recursion limit for lwtunnel_output for the case
> when user creates circular dst redirection. Also resolves the
> issue for ILA.
> - Fix to ensure headroom for potential future L2 header is still
> guaranteed
>
> Thomas Graf (5):
> route: Set orig_output when redirecting to lwt on locally generated
> traffic
> route: Set lwtstate for local traffic and cached input dsts
> bpf: BPF for lightweight tunnel encapsulation
> bpf: Add samples for LWT-BPF
> lwtunnel: Limit number of recursions on output to 5
>
> include/linux/filter.h | 2 +-
> include/uapi/linux/bpf.h | 37 +++-
> include/uapi/linux/lwtunnel.h | 21 ++
> kernel/bpf/verifier.c | 16 +-
> net/Kconfig | 1 +
> net/core/Makefile | 2 +-
> net/core/filter.c | 148 ++++++++++++-
> net/core/lwt_bpf.c | 504 ++++++++++++++++++++++++++++++++++++++++++
> net/core/lwtunnel.c | 15 +-
> net/ipv4/route.c | 37 +++-
> samples/bpf/bpf_helpers.h | 4 +
> samples/bpf/lwt_bpf.c | 235 ++++++++++++++++++++
> samples/bpf/test_lwt_bpf.sh | 370 +++++++++++++++++++++++++++++++
> 13 files changed, 1373 insertions(+), 19 deletions(-)
> create mode 100644 net/core/lwt_bpf.c
> create mode 100644 samples/bpf/lwt_bpf.c
> create mode 100755 samples/bpf/test_lwt_bpf.sh
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net/sched: cls_flower: merge filter delete/destroy common code
From: Sergei Shtylyov @ 2016-11-01 16:17 UTC (permalink / raw)
To: Roi Dayan, David S. Miller; +Cc: netdev, Jiri Pirko
In-Reply-To: <1478009309-63180-3-git-send-email-roid@mellanox.com>
On 11/01/2016 05:08 PM, Roi Dayan wrote:
> Move common code from fl_delete and fl_detroy to __fl_delete.
fl_destroy().
> Signed-off-by: Roi Dayan <roid@mellanox.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: ensure coalesce settings survive read-modify-write
From: David Miller @ 2016-11-01 16:18 UTC (permalink / raw)
To: rmk+kernel; +Cc: sebastian.hesselbarth, netdev
In-Reply-To: <E1c1Wdl-0000tO-Ql@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 01 Nov 2016 10:50:01 +0000
> The coalesce settings behave badly when changing just one value:
>
> ... # ethtool -c eth0
> rx-usecs: 249
> ... # ethtool -C eth0 tx-usecs 250
> ... # ethtool -c eth0
> rx-usecs: 248
>
> This occurs due to rounding errors when calculating the microseconds
> value - the divisons round down. This causes (eg) the rx-usecs to
> decrease by one every time the tx-usecs value is set as per the above.
>
> Fix this by making the divison round-to-nearest.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Hannes Frederic Sowa @ 2016-11-01 16:25 UTC (permalink / raw)
To: Tom Herbert, Jakub Sitnicki
Cc: Linux Kernel Network Developers, LKML, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <CALx6S36r0gzZ7ndmivsygZD9vX+EEv2sVEP=rmhQVzGB46Rkdg@mail.gmail.com>
On 31.10.2016 20:25, Tom Herbert wrote:
> The normal hash for TCP or UDP using ECMP is over <protocol, srcIP,
> dstIP, srcPort, dstPort>. For an ICMP packet ECMP would most likely be
> done over <protocol, srcIP, dstIP>. There really is no way to ensure
> that an ICMP packet will follow the same path as TCP or any other
> protocol. Fortunately, this is really isn't so terrible. The Internet
> has worked this way ever since routers started using ports as input to
> ECMP and that hasn't caused any major meltdown.
The normal hash for forwarding is without srcPort or dstPort, so the
same as ICMP and especially also because of fragmentation problematic I
don't think a lot of routers use L4 port information for ECMP either.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Jakub Sitnicki @ 2016-11-01 16:26 UTC (permalink / raw)
To: David Miller; +Cc: tom, netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20161101.113505.1429989348222226550.davem@davemloft.net>
On Tue, Nov 01, 2016 at 03:35 PM GMT, David Miller wrote:
> From: Jakub Sitnicki <jkbs@redhat.com>
> Date: Tue, 01 Nov 2016 16:13:51 +0100
>
>> On Mon, Oct 31, 2016 at 07:15 PM GMT, David Miller wrote:
>>> From: Jakub Sitnicki <jkbs@redhat.com>
>>> Date: Sun, 30 Oct 2016 14:03:11 +0100
>>>
>>>> 2) ensure the flow labels used in both directions are the same (either
>>>> reflected by one side, or fixed, e.g. not used and set to 0), so that
>>>> the 4-tuple we hash over when forwarding, <src addr, dst addr, flow
>>>> label, next hdr>, is the same both ways, modulo the order of
>>>> addresses.
>>>
>>> Even Linux, by default, does not do reflection.
>>>
>>> See the flowlabel_consistency sysctl, which we set by default to '1'.
>>
>> Yes, unfortunately, if Linux-based hosts are used as sending/receiving
>> IPv6, ICMP error forwarding will not work out of the box. Users will be
>> burdened with adjusting the runtime network stack config, as you point
>> out, or otherwise instructing the apps to set the flow label,
>> e.g. traceroute6 -I <flow label> ...
>
> I'm pretty sure that sysctl default was choosen intentionally, and we
> actively are _encouraging_ the world to not depend upon reflection in
> any way, shape, or form.
>
> And it's kind of pointless to suggest a facility that can't work with
> Linux endpoints out of the box.
>
> This was the point I'm trying to make.
>
> If the intentions of that sysctl default does pan out, the idea is for
> the world to move towards arbitrary flow label settings, even perhaps
> changing over time. The intention is to make this more, not less,
> common. And the idea is to give maximum flexibility for endpoints to
> set these flow labels, in order to increase entropy wherever possible.
>
> I have a really hard time accepting a "fix" that depends upon behavior
> that the Linux ipv6 stack doesn't even have.
Fair enough. I'm not questioning the defaults or the benefits of
widespread use of flow labels.
I was trying to do this without changing as to how we hash the packets
and balance traffic over multiple paths, but that does yield a solution
that does not work out of the box with Linux endpoints. Hard to sell, I
agree.
As a potential way out, I can rework it so that we exclude the flow
label from the multipath hash. That way we lose some entropy (not worse
than IPv4), but do not depend any more on how flow labels are set
(flexible). This could be made runtime configurable, as it changes
existing behavior.
Thanks,
Jakub
^ permalink raw reply
* Re: [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-01 16:26 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <20161101155950.GA19378@broadcom.com>
> > > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> > > + /* Lane Swap - Undocumented register...magic! */
> > > + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> > > + 0x11B);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > +
> >
> > I wounder if this property could be made generic? What exactly are you
> > swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
>
> Are you envisioning adding a DT check (similar to the
> of_property_read_bool above, only with a more generic string) in
> phy_device_create(), which will then set a PHY device flag? This flag
> would then be checked for in the PHY driver and the appropriate action
> taken (in this case the bcm_phy_write_exp above).
I would keep the parsing of the property in the driver. But if we
think other PHYs could also support this feature, it would be good to
avoid having "brcm,enet-phy-lane-swap", "marvell,enet-phy-lane-swap",
"davicom,enet-phy-lane-swap", etc. It would be better to have one well
defined property documented in phy.txt which any PHY is free to
implement.
Andrew
^ permalink raw reply
* Re: [PATCH net 2/4] net: ethernet: ti: cpsw: fix device and of_node leaks
From: David Miller @ 2016-11-01 16:27 UTC (permalink / raw)
To: johan
Cc: f.fainelli, mugunthanvnm, yisen.zhuang, salil.mehta, netdev,
linux-kernel
In-Reply-To: <1477998217-30143-3-git-send-email-johan@kernel.org>
From: Johan Hovold <johan@kernel.org>
Date: Tue, 1 Nov 2016 12:03:35 +0100
> diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> index 054a8dd23dae..589beb843f56 100644
> --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
> +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> @@ -176,8 +176,11 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
> }
>
> dev = bus_find_device(&platform_bus_type, NULL, node, match);
> + of_node_put(node);
> priv = dev_get_drvdata(dev);
>
> + put_device(dev);
> +
> priv->cpsw_phy_sel(priv, phy_mode, slave);
> }
> EXPORT_SYMBOL_GPL(cpsw_phy_sel);
The only reference you have to 'dev' is the one obtained from the
bus_find_device() call, therefore you must at least hold onto
'dev' until after the priv->cpsw_phy_sel(priv, phy_mode, slave); call.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Hannes Frederic Sowa @ 2016-11-01 16:27 UTC (permalink / raw)
To: David Miller, jkbs
Cc: tom, netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20161101.113505.1429989348222226550.davem@davemloft.net>
On 01.11.2016 16:35, David Miller wrote:
> I have a really hard time accepting a "fix" that depends upon behavior
> that the Linux ipv6 stack doesn't even have.
We actually support this feature:
commit df3687ffc6653e4d32168338b4dee20c164ed7c9
Author: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Date: Fri Jan 17 17:15:03 2014 +0100
ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
Add that time I tried to stick to the common practices at that time and
was against any kind of global sysctl enabling a reflection mode for
flowlabels. State of art was to keep some uniqueness in flowlabels, thus
also the introduction of the flowlabel_consistency label.
We basically can support reflection nowadays globally pretty easy, as we
have soften these rules a lot.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next V2 3/3] net/mlx4_en: Add ethtool statistics for XDP cases
From: Saeed Mahameed @ 2016-11-01 11:57 UTC (permalink / raw)
To: Tariq Toukan, David S. Miller
Cc: netdev, Eran Ben Elisha, Brenden Blanco, Alexei Starovoitov
In-Reply-To: <1478000186-5158-4-git-send-email-tariqt@mellanox.com>
On 11/01/2016 01:36 PM, Tariq Toukan wrote:
> XDP statistics are reported in ethtool as follows:
> - xdp_drop: the number of packets dropped by xdp.
> - xdp_tx: the number of packets forwarded by xdp.
> - xdp_tx_full: the number of times an xdp forward failed
> due to a full tx xdp ring.
>
> In addition, all packets that are dropped/forwarded by XDP
> are no longer accounted in rx_packets/rx_bytes of the ring,
> so that they count traffic that is passed to the stack.
>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: mlx5 bug in error path of mlx5e_open_channel()
From: Jesper Dangaard Brouer @ 2016-11-01 16:30 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Tariq Toukan, Tariq Toukan, Eran Ben Elisha,
netdev@vger.kernel.org, brouer
In-Reply-To: <f677c8e8-206b-eaf4-c72e-3c79fbbde07f@mellanox.com>
On Tue, 1 Nov 2016 17:48:31 +0200 Saeed Mahameed <saeedm@mellanox.com> wrote:
> On 11/01/2016 04:44 PM, Jesper Dangaard Brouer wrote:
> >
> > In driver mlx5 function mlx5e_open_channel() does not handle error
> > path correctly. (Tested by letting mlx5e_create_rq fail with -ENOMEM,
> > propagates to mlx5e_open_rq)
> >
> > This first seemed related to commit b5503b994ed5 ("net/mlx5e: XDP TX
> > forwarding support"). As a failed call of mlx5e_open_rq() always
> > calls mlx5e_close_sq(&c->xdp_sq) on "xdp_sq" even-though a XDP program
> > is not attached.
> >
>
> Indeed, Nice catch.
>
> > Fixing this like:
> >
> > @@ -1504,24 +1533,38 @@ static int mlx5e_open_channel(struct mlx5e_priv *priv, int ix,
> >
> > c->xdp = !!priv->xdp_prog;
> > err = mlx5e_open_rq(c, &cparam->rq, &c->rq);
> > - if (err)
> > - goto err_close_xdp_sq;
> > + if (err) {
> > + if (c->xdp)
> > + goto err_close_xdp_sq;
> > + else
> > + goto err_close_sqs;
> > + }
> >
> > The fix does remove one problem, but the error path still cause the
> > kernel to crash. This time it seems related to correct disabling of
> > NAPI polling before disabling the queues.
> >
>
> Well a more proper fix will be to add a xdp check in close_xdp_sq error flow,
> rather than complicating the error handling branching decision.
>
> i.e:
> Keep:
> err = mlx5e_open_rq(c, &cparam->rq, &c->rq);
> if (err)
> goto err_close_xdp_sq;
> [...]
> err_close_xdp_sq:
> - mlx5e_close_sq(&c->xdp_sq);
> + if (priv->xdp_prog)
> + mlx5e_close_sq(&c->xdp_sq);
Agree, that would be better.
> One more thing, the error flow handling is missing mlx5e_close_cq(&c->xdp_sq.cq);
> which might be related to the other bug you reported below.
>
> > Now with another error:
> >
> > XXX: call mlx5e_close_sqs(c)
> > BUG: unable to handle kernel NULL pointer dereference at (null)
> > IP: [< (null)>] (null)
> > PGD 401e00067
> > PUD 40746e067 PMD 0
> > Oops: 0010 [#1] PREEMPT SMP
> > Modules linked in: mlx5_core coretemp kvm_intel kvm irqbypass intel_cstate mxm_wmi i2c_i801 i2c_smbus]
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc3-page_pool04+ #124
> > Hardware name: To Be Filled By O.E.M./Z97 Extreme4, BIOS P2.10 05/12/2015
> > task: ffffffff81c0c4c0 task.stack: ffffffff81c00000
> > RIP: 0010:[<0000000000000000>] [< (null)>] (null)
> > RSP: 0018:ffff88041fa03e70 EFLAGS: 00010286
> > RAX: 0000000000000000 RBX: ffff880401ecc000 RCX: 0000000000000005
> > RDX: 0000000000000000 RSI: ffff880401c38000 RDI: ffff880401ecc000
> > RBP: ffff88041fa03e88 R08: 0000000000000001 R09: ffff8803ea6a7230
> > R10: 0000000000000000 R11: 0000000000000040 R12: ffff880401c38000
> > R13: ffff880401ecf148 R14: 0000000000000040 R15: ffff880401ecc000
> > FS: 0000000000000000(0000) GS:ffff88041fa00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000000000000 CR3: 000000040c468000 CR4: 00000000001406f0
> > Stack:
> > ffffffffa02e62e0 0000000000000000 0000000000000001 ffff88041fa03ed0
> > ffffffffa02e84c2 0000ffff00000000 ffffffff00000040 ffff880401ecf148
> > 0000000000000040 0000000000000000 000000000000012c 0000000000000000
> > Call Trace:
> > <IRQ> [ 428.032595] [<ffffffffa02e62e0>] ? mlx5e_post_rx_wqes+0x80/0xc0 [mlx5_core]
> > [<ffffffffa02e84c2>] mlx5e_napi_poll+0xf2/0x530 [mlx5_core]
> > [<ffffffff8160e50c>] net_rx_action+0x1fc/0x350
> > [<ffffffff8172aff8>] __do_softirq+0xc8/0x2c6
> > [<ffffffff8106728e>] irq_exit+0xbe/0xd0
> > [<ffffffff8172ad44>] do_IRQ+0x54/0xd0
> > [<ffffffff8172937f>] common_interrupt+0x7f/0x7f
> > <EOI> [ 428.075157] [<ffffffff817285d0>] ? _raw_spin_unlock_irq+0x10/0x20
> > [<ffffffff81086db8>] ? finish_task_switch+0x78/0x200
> > [<ffffffff81722dfa>] __schedule+0x17a/0x670
> > [<ffffffff8172332d>] schedule+0x3d/0x90
> > [<ffffffff817236a5>] schedule_preempt_disabled+0x15/0x20
> > [<ffffffff810a560c>] cpu_startup_entry+0x12c/0x1c0
> > [<ffffffff8171c274>] rest_init+0x84/0x90
> > [<ffffffff81d95f14>] start_kernel+0x3fe/0x40b
> > [<ffffffff81d9528f>] x86_64_start_reservations+0x2a/0x2c
> > [<ffffffff81d953f9>] x86_64_start_kernel+0x168/0x176
> > Code: Bad RIP value.
> > RIP [< (null)>] (null)
> > RSP <ffff88041fa03e70>
> > CR2: 0000000000000000
> > ---[ end trace a871278f0d0523ac ]---
> >
> > Could you please look at fixing your driver?
> >
>
> Will handle it ASAP, Thank you Jesper.
Thanks for your quick response :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: net/dccp: warning in dccp_feat_clone_sp_val/__might_sleep
From: Andrey Konovalov @ 2016-11-01 16:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: Cong Wang, Peter Zijlstra, Gerrit Renker, David S. Miller, dccp,
netdev, LKML, Dmitry Vyukov, Eric Dumazet
In-Reply-To: <1477939216.7065.305.camel@edumazet-glaptop3.roam.corp.google.com>
Hi Cong,
Yes, your patches fix the warnings.
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Thanks!
On Mon, Oct 31, 2016 at 7:40 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2016-10-31 at 11:00 -0700, Cong Wang wrote:
>> On Sun, Oct 30, 2016 at 6:20 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > On Sun, 2016-10-30 at 05:41 +0100, Andrey Konovalov wrote:
>> >> Sorry, the warning is still there.
>> >>
>> >> I'm not sure adding sched_annotate_sleep() does anything, since it's
>> >> defined as (in case CONFIG_DEBUG_ATOMIC_SLEEP is not set):
>> >> # define sched_annotate_sleep() do { } while (0)
>> >
>> > Thanks again for testing.
>> >
>> > But you do have CONFIG_DEBUG_ATOMIC_SLEEP set, which triggers a check in
>> > __might_sleep() :
>> >
>> > WARN_ONCE(current->state != TASK_RUNNING && current->task_state_change,
>> >
>> > Relevant commit is 00845eb968ead28007338b2bb852b8beef816583
>> > ("sched: don't cause task state changes in nested sleep debugging")
>> >
>> > Another relevant commit was 26cabd31259ba43f68026ce3f62b78094124333f
>> > ("sched, net: Clean up sk_wait_event() vs. might_sleep()")
>> >
>> > Before release_sock() could process the backlog in process context, only
>> > lock_sock() could trigger the issue, so my fix at that time was commit
>> > cb7cf8a33ff73cf638481d1edf883d8968f934f8 ("inet: Clean up
>> > inet_csk_wait_for_connect() vs. might_sleep()")
>> >
>>
>> Thanks for the context, but isn't the original warning reported by Andrey is
>> from inet_wait_for_connect()? You seem only patch some dccp function
>> which is why it is still there?
>>
>> It should be the following, no?
>>
>>
>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
>> index 9648c97..bbd8159 100644
>> --- a/net/ipv4/af_inet.c
>> +++ b/net/ipv4/af_inet.c
>> @@ -544,6 +544,7 @@ static long inet_wait_for_connect(struct sock *sk,
>> long timeo, int writebias)
>> * without closing the socket.
>> */
>> while ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
>> + sched_annotate_sleep();
>> release_sock(sk);
>> timeo = schedule_timeout(timeo);
>> lock_sock(sk);
>
> Yes, this would be one of the locations needing this.
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] tcp: enhance tcp collapsing
From: Neal Cardwell @ 2016-11-01 16:35 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ilya Lesokhin, David Miller, netdev@vger.kernel.org,
Ilpo Järvinen, Yuchung Cheng
In-Reply-To: <1478014346.7065.342.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, Nov 1, 2016 at 11:32 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> From: Eric Dumazet <edumazet@google.com>
>
> As Ilya Lesokhin suggested, we can collapse two skbs at retransmit
> time even if the skb at the right has fragments.
>
> We simply have to use more generic skb_copy_bits() instead of
> skb_copy_from_linear_data() in tcp_collapse_retrans()
>
> Tested:
>
> Used following packetdrill test
>
> // Establish a connection.
> 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> +0 bind(3, ..., ...) = 0
> +0 listen(3, 1) = 0
>
> +0 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 8>
> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
> +.100 < . 1:1(0) ack 1 win 257
> +0 accept(3, ..., ...) = 4
>
> +0 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> +0 write(4, ..., 200) = 200
> +0 > P. 1:201(200) ack 1
> +.001 write(4, ..., 200) = 200
> +0 > P. 201:401(200) ack 1
> +.001 write(4, ..., 200) = 200
> +0 > P. 401:601(200) ack 1
> +.001 write(4, ..., 200) = 200
> +0 > P. 601:801(200) ack 1
> +.001 write(4, ..., 200) = 200
> +0 > P. 801:1001(200) ack 1
> +.001 write(4, ..., 100) = 100
> +0 > P. 1001:1101(100) ack 1
> +.001 write(4, ..., 100) = 100
> +0 > P. 1101:1201(100) ack 1
> +.001 write(4, ..., 100) = 100
> +0 > P. 1201:1301(100) ack 1
> +.001 write(4, ..., 100) = 100
> +0 > P. 1301:1401(100) ack 1
>
> +.100 < . 1:1(0) ack 1 win 257 <nop,nop,sack 1001:1401>
> // Check that TCP collapse works :
> +0 > P. 1:1001(1000) ack 1
>
>
> Reported-by: Ilya Lesokhin <ilyal@mellanox.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> ---
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks, Eric!
neal
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: David Miller @ 2016-11-01 16:39 UTC (permalink / raw)
To: hannes; +Cc: jkbs, tom, netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <7f83a405-0520-a3ed-fc21-402d702483f9@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 1 Nov 2016 17:27:56 +0100
> On 01.11.2016 16:35, David Miller wrote:
>> I have a really hard time accepting a "fix" that depends upon behavior
>> that the Linux ipv6 stack doesn't even have.
>
> We actually support this feature:
But it is forbidden when the sysctl I mentioned is set, which is the
default.
I'm talking about default behavior, which is to not reflect.
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Tom Herbert @ 2016-11-01 16:39 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Jakub Sitnicki, Linux Kernel Network Developers, LKML,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <af3e302e-4fd0-e63c-4520-63a6e2341c22@stressinduktion.org>
On Tue, Nov 1, 2016 at 9:25 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On 31.10.2016 20:25, Tom Herbert wrote:
>> The normal hash for TCP or UDP using ECMP is over <protocol, srcIP,
>> dstIP, srcPort, dstPort>. For an ICMP packet ECMP would most likely be
>> done over <protocol, srcIP, dstIP>. There really is no way to ensure
>> that an ICMP packet will follow the same path as TCP or any other
>> protocol. Fortunately, this is really isn't so terrible. The Internet
>> has worked this way ever since routers started using ports as input to
>> ECMP and that hasn't caused any major meltdown.
>
> The normal hash for forwarding is without srcPort or dstPort, so the
> same as ICMP and especially also because of fragmentation problematic I
> don't think a lot of routers use L4 port information for ECMP either.
>
I don't think we can define a "normal hash". There is no requirement
that routers do ECMP a certain way, or that they do ECMP, or that for
that matter that they even consistently route packets for the same
flow. All of this is optimization, not something we can rely on
operationally. So in the general case, regardless of anything we do in
the stack, either ICMP packets will follow the same path as the flow
are they won't. If they don't things still need to to work. So I still
don't see what material benefit this patch gives us.
Tom
> Bye,
> Hannes
>
^ permalink raw reply
* Re: [PATCH net 2/4] net: ethernet: ti: cpsw: fix device and of_node leaks
From: Johan Hovold @ 2016-11-01 16:42 UTC (permalink / raw)
To: David Miller
Cc: johan, f.fainelli, mugunthanvnm, yisen.zhuang, salil.mehta,
netdev, linux-kernel
In-Reply-To: <20161101.122711.1685573538225505004.davem@davemloft.net>
On Tue, Nov 01, 2016 at 12:27:11PM -0400, David Miller wrote:
> From: Johan Hovold <johan@kernel.org>
> Date: Tue, 1 Nov 2016 12:03:35 +0100
>
> > diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> > index 054a8dd23dae..589beb843f56 100644
> > --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
> > +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> > @@ -176,8 +176,11 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
> > }
> >
> > dev = bus_find_device(&platform_bus_type, NULL, node, match);
> > + of_node_put(node);
> > priv = dev_get_drvdata(dev);
> >
> > + put_device(dev);
> > +
> > priv->cpsw_phy_sel(priv, phy_mode, slave);
> > }
> > EXPORT_SYMBOL_GPL(cpsw_phy_sel);
>
> The only reference you have to 'dev' is the one obtained from the
> bus_find_device() call, therefore you must at least hold onto
> 'dev' until after the priv->cpsw_phy_sel(priv, phy_mode, slave); call.
As I mentioned in the commit message "...there is no guarantee that the
devres-managed struct cpsw_phy_sel_priv will continue to be valid until
this function returns regardless of this change".
Specifically, holding a reference to dev does not prevent the
cpsw_phy_sel driver from being unbound and priv from being freed.
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Jon Mason @ 2016-11-01 16:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <20161101162648.GG10785@lunn.ch>
On Tue, Nov 01, 2016 at 05:26:48PM +0100, Andrew Lunn wrote:
> > > > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> > > > + /* Lane Swap - Undocumented register...magic! */
> > > > + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> > > > + 0x11B);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > + }
> > > > +
> > >
> > > I wounder if this property could be made generic? What exactly are you
> > > swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
> >
> > Are you envisioning adding a DT check (similar to the
> > of_property_read_bool above, only with a more generic string) in
> > phy_device_create(), which will then set a PHY device flag? This flag
> > would then be checked for in the PHY driver and the appropriate action
> > taken (in this case the bcm_phy_write_exp above).
>
> I would keep the parsing of the property in the driver. But if we
> think other PHYs could also support this feature, it would be good to
> avoid having "brcm,enet-phy-lane-swap", "marvell,enet-phy-lane-swap",
> "davicom,enet-phy-lane-swap", etc. It would be better to have one well
> defined property documented in phy.txt which any PHY is free to
> implement.
Okay, I understand what you are saying now. I will assume that if
nothing exists today aside from this Broadcom errata, something in the
future will happen. So, I agree that making it generic is a good idea.
I'll make the generic string be "enet-phy-lane-swap" (without the
previous "brcm"), and add the flag to phy.txt to document it.
Thanks,
Jon
>
> Andrew
^ permalink raw reply
* Re: [PATCH net 2/4] net: ethernet: ti: cpsw: fix device and of_node leaks
From: David Miller @ 2016-11-01 16:48 UTC (permalink / raw)
To: johan
Cc: f.fainelli, mugunthanvnm, yisen.zhuang, salil.mehta, netdev,
linux-kernel
In-Reply-To: <20161101164225.GC2664@localhost>
From: Johan Hovold <johan@kernel.org>
Date: Tue, 1 Nov 2016 17:42:25 +0100
> On Tue, Nov 01, 2016 at 12:27:11PM -0400, David Miller wrote:
>> From: Johan Hovold <johan@kernel.org>
>> Date: Tue, 1 Nov 2016 12:03:35 +0100
>>
>> > diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
>> > index 054a8dd23dae..589beb843f56 100644
>> > --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
>> > +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
>> > @@ -176,8 +176,11 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
>> > }
>> >
>> > dev = bus_find_device(&platform_bus_type, NULL, node, match);
>> > + of_node_put(node);
>> > priv = dev_get_drvdata(dev);
>> >
>> > + put_device(dev);
>> > +
>> > priv->cpsw_phy_sel(priv, phy_mode, slave);
>> > }
>> > EXPORT_SYMBOL_GPL(cpsw_phy_sel);
>>
>> The only reference you have to 'dev' is the one obtained from the
>> bus_find_device() call, therefore you must at least hold onto
>> 'dev' until after the priv->cpsw_phy_sel(priv, phy_mode, slave); call.
>
> As I mentioned in the commit message "...there is no guarantee that the
> devres-managed struct cpsw_phy_sel_priv will continue to be valid until
> this function returns regardless of this change".
>
> Specifically, holding a reference to dev does not prevent the
> cpsw_phy_sel driver from being unbound and priv from being freed.
But you should at least hold onto the object while you call a function
pointer embedded in a data structure referred by it.
^ permalink raw reply
* Re: [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-01 16:48 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
rafal-g1n6cQUeyibVItvQsEIGlw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161101164337.GA19654-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> I'll make the generic string be "enet-phy-lane-swap" (without the
> previous "brcm"), and add the flag to phy.txt to document it.
Great.
Please be quite verbose as to what it means.
Thanks
Andrew
--
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-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Hannes Frederic Sowa @ 2016-11-01 16:54 UTC (permalink / raw)
To: Tom Herbert
Cc: Jakub Sitnicki, Linux Kernel Network Developers, LKML,
David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <CALx6S35gXFU47i5_LF7Hs1JKGvh40OyJ5Sn-TWacbwiFb0VZ9A@mail.gmail.com>
Hello,
On 01.11.2016 17:39, Tom Herbert wrote:
> On Tue, Nov 1, 2016 at 9:25 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>> On 31.10.2016 20:25, Tom Herbert wrote:
>>> The normal hash for TCP or UDP using ECMP is over <protocol, srcIP,
>>> dstIP, srcPort, dstPort>. For an ICMP packet ECMP would most likely be
>>> done over <protocol, srcIP, dstIP>. There really is no way to ensure
>>> that an ICMP packet will follow the same path as TCP or any other
>>> protocol. Fortunately, this is really isn't so terrible. The Internet
>>> has worked this way ever since routers started using ports as input to
>>> ECMP and that hasn't caused any major meltdown.
>>
>> The normal hash for forwarding is without srcPort or dstPort, so the
>> same as ICMP and especially also because of fragmentation problematic I
>> don't think a lot of routers use L4 port information for ECMP either.
>>
> I don't think we can define a "normal hash". There is no requirement
> that routers do ECMP a certain way, or that they do ECMP, or that for
> that matter that they even consistently route packets for the same
> flow. All of this is optimization, not something we can rely on
> operationally. So in the general case, regardless of anything we do in
> the stack, either ICMP packets will follow the same path as the flow
> are they won't. If they don't things still need to to work. So I still
> don't see what material benefit this patch gives us.
There certainly is no standard ECMP hash algorithm. ;)
Even Linux IPv6 ECMP behaved like that for a long time (very bad). It
just routed put packets on different links without consulting any hash.
That exactly was the reason why it was unusable and was upgraded some
while ago.
I do remember a lot of IPv6 PMTU blackholes in the past, so every patch
that improves connectivity here seems valuable to me, even if it does
not fix the problem completely in the end.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet
From: Hannes Frederic Sowa @ 2016-11-01 16:59 UTC (permalink / raw)
To: David Miller
Cc: jkbs, tom, netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <20161101.123904.1432761986039949225.davem@davemloft.net>
On 01.11.2016 17:39, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Tue, 1 Nov 2016 17:27:56 +0100
>
>> On 01.11.2016 16:35, David Miller wrote:
>>> I have a really hard time accepting a "fix" that depends upon behavior
>>> that the Linux ipv6 stack doesn't even have.
>>
>> We actually support this feature:
>
> But it is forbidden when the sysctl I mentioned is set, which is the
> default.
>
> I'm talking about default behavior, which is to not reflect.
Oh, yes, understood.
I think we can flip this sysctl by default to off: current default
kernel config actually generates flow labels on its own, so the
description of this sysctl is violated by default anyway, as it doesn't
preserve the uniqueness anymore.
Bye,
Hannes
^ permalink raw reply
* Re: [net-next PATCH 0/7] stmmac: dwmac-sti refactor+cleanup
From: Joachim Eastwood @ 2016-11-01 17:00 UTC (permalink / raw)
To: David Miller, Patrice Chotard
Cc: peppe.cavallaro, alexandre.torgue, netdev, kernel
In-Reply-To: <20161101.115634.415403364673533569.davem@davemloft.net>
Hi,
On 1 November 2016 at 16:56, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
> Date: Mon, 31 Oct 2016 15:47:26 -0400 (EDT)
>
>> From: Joachim Eastwood <manabian@gmail.com>
>> Date: Sun, 30 Oct 2016 21:05:00 +0100
>>
>>> This patch set aims to remove the init/exit callbacks from the
>>> dwmac-sti driver and instead use standard PM callbacks. Doing this
>>> will also allow us to cleanup the driver.
>>>
>>> Eventually the init/exit callbacks will be deprecated and removed
>>> from all drivers dwmac-* except for dwmac-generic. Drivers will be
>>> refactored to use standard PM and remove callbacks.
>>>
>>> Note that this patch set has only been test compiled and no functional
>>> change is intended.
>>
>> I would really like to see some review and testing before applying this
>> series.
>
> Ping?
Adding some more ST people.
Could anyone with a stih407 platform please give these patches a try?
The series can found at https://github.com/manabian/linux-lpc.git in
the net-sti-dwmac branch (based on net-next).
Alternatively they can also be picked from netdev's patchwork.
regards,
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH net-next v2] ipv4: fib: Replay events when registering FIB notifier
From: Ido Schimmel @ 2016-11-01 17:03 UTC (permalink / raw)
To: Roopa Prabhu
Cc: Eric Dumazet, netdev, davem, jiri, mlxsw, dsa, nikolay, andy,
vivien.didelot, andrew, f.fainelli, alexander.h.duyck, kuznet,
jmorris, yoshfuji, kaber, Ido Schimmel
In-Reply-To: <5818B146.20209@cumulusnetworks.com>
Hi Roopa,
On Tue, Nov 01, 2016 at 08:14:14AM -0700, Roopa Prabhu wrote:
> On 11/1/16, 7:19 AM, Eric Dumazet wrote:
> > On Tue, 2016-11-01 at 00:57 +0200, Ido Schimmel wrote:
> >> On Mon, Oct 31, 2016 at 02:24:06PM -0700, Eric Dumazet wrote:
> >>> How well will this work for large FIB tables ?
> >>>
> >>> Holding rtnl while sending thousands of skb will prevent consumers to
> >>> make progress ?
> >> Can you please clarify what do you mean by "while sending thousands of
> >> skb"? This patch doesn't generate notifications to user space, but
> >> instead invokes notification routines inside the kernel. I probably
> >> misunderstood you.
> >>
> >> Are you suggesting this be done using RCU instead? Well, there are a
> >> couple of reasons why I took RTNL here:
> >>
> > No, I do not believe RCU is wanted here, in control path where we might
> > sleep anyway.
> >
> >> 1) The FIB notification chain is blocking, so listeners are expected to
> >> be able to sleep. This isn't possible if we use RCU. Note that this
> >> chain is mainly useful for drivers that reflect the FIB table into a
> >> capable device and hardware operations usually involve sleeping.
> >>
> >> 2) The insertion of a single route is done with RTNL held. I didn't want
> >> to differentiate between both cases. This property is really useful for
> >> listeners, as they don't need to worry about locking in writer-side.
> >> Access to data structs is serialized by RTNL.
> > My concern was that for large iterations, you might hold RTNL and/or
> > current cpu for hundred of ms or even seconds...
> >
> I have the same concern as Eric here.
>
> I understand why you need it, but can the driver request for an initial dump and that
> dump be made more efficient somehow ie not hold rtnl for the whole dump ?.
> instead of making the fib notifier registration code doing it.
We can do what we suggested in the last bi-weekly meeting, which is
still holding rtnl, but moving the hardware operation to delayed work.
This is possible because upper layers always assume operation was
successful and driver is responsible for invoking its abort mechanism in
case of failure.
> these routing table sizes can be huge and an analogy for this in user-space:
> We do request a netlink dump of routing tables at initialization (on driver starts or resets)...
> but, existing netlink routing table dumps for that scale don't hold rtnl for the whole dump.
> The dump is split into multiple responses to the user and hence it does not starve other rtnl users.
In my reply to Eric I mentioned that when we register and unregister
from this chain the tables aren't really huge, but instead quite small.
I understand your concerns, but I don't wish to make things more
complicated than they should be only to address concerns that aren't
really realistic.
I believe current patch is quite simple and also consistent with other
notification chains in the kernel, such as the netdevice, where rtnl is
held during replay of events.
http://lxr.free-electrons.com/source/net/core/dev.c#L1535
^ permalink raw reply
* Re: [PATCH net 2/4] net: ethernet: ti: cpsw: fix device and of_node leaks
From: Johan Hovold @ 2016-11-01 17:04 UTC (permalink / raw)
To: David Miller
Cc: johan, f.fainelli, mugunthanvnm, yisen.zhuang, salil.mehta,
netdev, linux-kernel
In-Reply-To: <20161101.124848.1812844488411463169.davem@davemloft.net>
On Tue, Nov 01, 2016 at 12:48:48PM -0400, David Miller wrote:
> From: Johan Hovold <johan@kernel.org>
> Date: Tue, 1 Nov 2016 17:42:25 +0100
>
> > On Tue, Nov 01, 2016 at 12:27:11PM -0400, David Miller wrote:
> >> From: Johan Hovold <johan@kernel.org>
> >> Date: Tue, 1 Nov 2016 12:03:35 +0100
> >>
> >> > diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> >> > index 054a8dd23dae..589beb843f56 100644
> >> > --- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
> >> > +++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
> >> > @@ -176,8 +176,11 @@ void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
> >> > }
> >> >
> >> > dev = bus_find_device(&platform_bus_type, NULL, node, match);
> >> > + of_node_put(node);
> >> > priv = dev_get_drvdata(dev);
> >> >
> >> > + put_device(dev);
> >> > +
> >> > priv->cpsw_phy_sel(priv, phy_mode, slave);
> >> > }
> >> > EXPORT_SYMBOL_GPL(cpsw_phy_sel);
> >>
> >> The only reference you have to 'dev' is the one obtained from the
> >> bus_find_device() call, therefore you must at least hold onto
> >> 'dev' until after the priv->cpsw_phy_sel(priv, phy_mode, slave); call.
> >
> > As I mentioned in the commit message "...there is no guarantee that the
> > devres-managed struct cpsw_phy_sel_priv will continue to be valid until
> > this function returns regardless of this change".
> >
> > Specifically, holding a reference to dev does not prevent the
> > cpsw_phy_sel driver from being unbound and priv from being freed.
>
> But you should at least hold onto the object while you call a function
> pointer embedded in a data structure referred by it.
But there is no such reference to be held (currently). While priv is
valid (i.e. dev has a driver bound), driver core will hold a reference
to dev. If someone unbinds the driver, priv will be gone long before dev
and all bets are off anyway.
So I released the reference to dev before dereferencing priv on purpose
to avoid having someone make false assumptions about the lifetime of priv.
Johan
^ permalink raw reply
* RE: [PATCH v3 net-next] lan78xx: Use irq_domain for phy interrupt from USB Int. EP
From: Woojung.Huh @ 2016-11-01 17:07 UTC (permalink / raw)
To: davem; +Cc: netdev, f.fainelli, andrew, UNGLinuxDriver
In-Reply-To: <20161101.120322.716031785792281107.davem@davemloft.net>
> > @@ -2668,6 +2821,13 @@ static int lan78xx_bind(struct lan78xx_net *dev,
> struct usb_interface *intf)
> >
> > dev->net->hw_features = dev->net->features;
> >
> > + ret = lan78xx_setup_irq_domain(dev);
> > + if (ret < 0) {
> > + netdev_warn(dev->net,
> > + "lan78xx_setup_irq_domain() failed : %d", ret);
> > + return ret;
> > + }
> > +
>
> This error path leaks the memory allocated at the beginning of this function.
>
> That would normally be freed up by lan78xx_unbind() but the caller will not
> invoke that if lan78xx_bind() fails so you have to take care of the kfree
> here.
David,
Thanks for review and finding.
Will fix and post new patch.
- Woojung
^ permalink raw reply
* [PATCH] [RFC] net: phy: phy drivers should not set SUPPORTED_Pause or SUPPORTED_Asym_Pause
From: Timur Tabi @ 2016-11-01 17:18 UTC (permalink / raw)
To: David Miller, Florian Fainelli, netdev
Pause frames are a feature that is supported by the MAC. It is the MAC
that generates the frames and that processes them. Thy PHY can only be
configured to allow them to pass. Therefore, pause frame support in the
PHY should only be enabled if the MAC wants it enabled. It should not be
forced on all the time.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/phy/bcm-cygnus.c | 3 +--
drivers/net/phy/bcm63xx.c | 5 ++---
drivers/net/phy/bcm7xxx.c | 6 ++----
drivers/net/phy/broadcom.c | 39 +++++++++++++--------------------------
drivers/net/phy/icplus.c | 6 ++----
drivers/net/phy/intel-xway.c | 24 ++++++++----------------
drivers/net/phy/micrel.c | 30 ++++++++++++------------------
drivers/net/phy/microchip.c | 3 +--
drivers/net/phy/national.c | 2 +-
drivers/net/phy/smsc.c | 18 ++++++------------
drivers/net/phy/ste10Xp.c | 4 ++--
11 files changed, 50 insertions(+), 90 deletions(-)
diff --git a/drivers/net/phy/bcm-cygnus.c b/drivers/net/phy/bcm-cygnus.c
index 49bbc68..12c6d49 100644
--- a/drivers/net/phy/bcm-cygnus.c
+++ b/drivers/net/phy/bcm-cygnus.c
@@ -134,8 +134,7 @@ static int bcm_cygnus_resume(struct phy_device *phydev)
.phy_id = PHY_ID_BCM_CYGNUS,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom Cygnus PHY",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.config_init = bcm_cygnus_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
diff --git a/drivers/net/phy/bcm63xx.c b/drivers/net/phy/bcm63xx.c
index e741bf6..5e9922e 100644
--- a/drivers/net/phy/bcm63xx.c
+++ b/drivers/net/phy/bcm63xx.c
@@ -48,8 +48,7 @@ static int bcm63xx_config_init(struct phy_device *phydev)
.phy_id = 0x00406000,
.phy_id_mask = 0xfffffc00,
.name = "Broadcom BCM63XX (1)",
- /* ASYM_PAUSE bit is marked RO in datasheet, so don't cheat */
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_IS_INTERNAL,
.config_init = bcm63xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -61,7 +60,7 @@ static int bcm63xx_config_init(struct phy_device *phydev)
.phy_id = 0x002bdc00,
.phy_id_mask = 0xfffffc00,
.name = "Broadcom BCM63XX (2)",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_IS_INTERNAL,
.config_init = bcm63xx_config_init,
.config_aneg = genphy_config_aneg,
diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index 9636da0..c1629df 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -308,8 +308,7 @@ static int bcm7xxx_suspend(struct phy_device *phydev)
.phy_id = (_oui), \
.phy_id_mask = 0xfffffff0, \
.name = _name, \
- .features = PHY_GBIT_FEATURES | \
- SUPPORTED_Pause | SUPPORTED_Asym_Pause, \
+ .features = PHY_GBIT_FEATURES, \
.flags = PHY_IS_INTERNAL, \
.config_init = bcm7xxx_28nm_config_init, \
.config_aneg = genphy_config_aneg, \
@@ -322,8 +321,7 @@ static int bcm7xxx_suspend(struct phy_device *phydev)
.phy_id = (_oui), \
.phy_id_mask = 0xfffffff0, \
.name = _name, \
- .features = PHY_BASIC_FEATURES | \
- SUPPORTED_Pause | SUPPORTED_Asym_Pause, \
+ .features = PHY_BASIC_FEATURES, \
.flags = PHY_IS_INTERNAL, \
.config_init = bcm7xxx_config_init, \
.config_aneg = genphy_config_aneg, \
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 583ef8a..1d5ee5f 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -487,8 +487,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM5411,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5411",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -499,8 +498,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM5421,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5421",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -511,8 +509,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM5461,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5461",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -523,8 +520,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM54612E,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM54612E",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = bcm54612e_config_aneg,
@@ -535,8 +531,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM54616S,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM54616S",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -547,8 +542,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM5464,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5464",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -559,8 +553,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM5481,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5481",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = bcm5481_config_aneg,
@@ -571,8 +564,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM5482,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5482",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm5482_config_init,
.config_aneg = genphy_config_aneg,
@@ -583,8 +575,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM50610,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM50610",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -595,8 +586,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM50610M,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM50610M",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -607,8 +597,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM57780,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM57780",
- .features = PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = bcm54xx_config_init,
.config_aneg = genphy_config_aneg,
@@ -619,8 +608,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCMAC131,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCMAC131",
- .features = PHY_BASIC_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = brcm_fet_config_init,
.config_aneg = genphy_config_aneg,
@@ -631,8 +619,7 @@ static int brcm_fet_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_BCM5241,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5241",
- .features = PHY_BASIC_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = brcm_fet_config_init,
.config_aneg = genphy_config_aneg,
diff --git a/drivers/net/phy/icplus.c b/drivers/net/phy/icplus.c
index e5f251b..22b51f0 100644
--- a/drivers/net/phy/icplus.c
+++ b/drivers/net/phy/icplus.c
@@ -225,8 +225,7 @@ static int ip101a_g_ack_interrupt(struct phy_device *phydev)
.phy_id = 0x02430d90,
.name = "ICPlus IP1001",
.phy_id_mask = 0x0ffffff0,
- .features = PHY_GBIT_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.config_init = &ip1001_config_init,
.config_aneg = &genphy_config_aneg,
.read_status = &genphy_read_status,
@@ -236,8 +235,7 @@ static int ip101a_g_ack_interrupt(struct phy_device *phydev)
.phy_id = 0x02430c54,
.name = "ICPlus IP101A/G",
.phy_id_mask = 0x0ffffff0,
- .features = PHY_BASIC_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause,
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.ack_interrupt = ip101a_g_ack_interrupt,
.config_init = &ip101a_g_config_init,
diff --git a/drivers/net/phy/intel-xway.c b/drivers/net/phy/intel-xway.c
index c300ab5..b1fd7bb 100644
--- a/drivers/net/phy/intel-xway.c
+++ b/drivers/net/phy/intel-xway.c
@@ -239,8 +239,7 @@ static int xway_gphy_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_PHY11G_1_3,
.phy_id_mask = 0xffffffff,
.name = "Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.3",
- .features = (PHY_GBIT_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = xway_gphy_config_init,
.config_aneg = xway_gphy14_config_aneg,
@@ -254,8 +253,7 @@ static int xway_gphy_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_PHY22F_1_3,
.phy_id_mask = 0xffffffff,
.name = "Intel XWAY PHY22F (PEF 7061) v1.3",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = xway_gphy_config_init,
.config_aneg = xway_gphy14_config_aneg,
@@ -269,8 +267,7 @@ static int xway_gphy_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_PHY11G_1_4,
.phy_id_mask = 0xffffffff,
.name = "Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.4",
- .features = (PHY_GBIT_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = xway_gphy_config_init,
.config_aneg = xway_gphy14_config_aneg,
@@ -284,8 +281,7 @@ static int xway_gphy_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_PHY22F_1_4,
.phy_id_mask = 0xffffffff,
.name = "Intel XWAY PHY22F (PEF 7061) v1.4",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = xway_gphy_config_init,
.config_aneg = xway_gphy14_config_aneg,
@@ -299,8 +295,7 @@ static int xway_gphy_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_PHY11G_1_5,
.phy_id_mask = 0xffffffff,
.name = "Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.5 / v1.6",
- .features = (PHY_GBIT_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = xway_gphy_config_init,
.config_aneg = genphy_config_aneg,
@@ -314,8 +309,7 @@ static int xway_gphy_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_PHY22F_1_5,
.phy_id_mask = 0xffffffff,
.name = "Intel XWAY PHY22F (PEF 7061) v1.5 / v1.6",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = xway_gphy_config_init,
.config_aneg = genphy_config_aneg,
@@ -329,8 +323,7 @@ static int xway_gphy_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_PHY11G_VR9,
.phy_id_mask = 0xffffffff,
.name = "Intel XWAY PHY11G (xRX integrated)",
- .features = (PHY_GBIT_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = xway_gphy_config_init,
.config_aneg = genphy_config_aneg,
@@ -344,8 +337,7 @@ static int xway_gphy_config_intr(struct phy_device *phydev)
.phy_id = PHY_ID_PHY22F_VR9,
.phy_id_mask = 0xffffffff,
.name = "Intel XWAY PHY22F (xRX integrated)",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = xway_gphy_config_init,
.config_aneg = genphy_config_aneg,
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 081df68..76cc727 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -790,7 +790,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KS8737,
.phy_id_mask = MICREL_PHY_ID_MASK,
.name = "Micrel KS8737",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ks8737_type,
.config_init = kszphy_config_init,
@@ -807,8 +807,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8021,
.phy_id_mask = 0x00ffffff,
.name = "Micrel KSZ8021 or KSZ8031",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8021_type,
.probe = kszphy_probe,
@@ -826,8 +825,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8031,
.phy_id_mask = 0x00ffffff,
.name = "Micrel KSZ8031",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
- SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8021_type,
.probe = kszphy_probe,
@@ -845,8 +843,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8041,
.phy_id_mask = MICREL_PHY_ID_MASK,
.name = "Micrel KSZ8041",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
- | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8041_type,
.probe = kszphy_probe,
@@ -864,8 +861,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8041RNLI,
.phy_id_mask = MICREL_PHY_ID_MASK,
.name = "Micrel KSZ8041RNLI",
- .features = PHY_BASIC_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8041_type,
.probe = kszphy_probe,
@@ -883,8 +879,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8051,
.phy_id_mask = MICREL_PHY_ID_MASK,
.name = "Micrel KSZ8051",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
- | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8051_type,
.probe = kszphy_probe,
@@ -902,7 +897,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8001,
.name = "Micrel KSZ8001 or KS8721",
.phy_id_mask = 0x00fffffc,
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8041_type,
.probe = kszphy_probe,
@@ -920,7 +915,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8081,
.name = "Micrel KSZ8081 or KSZ8091",
.phy_id_mask = MICREL_PHY_ID_MASK,
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz8081_type,
.probe = kszphy_probe,
@@ -938,7 +933,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8061,
.name = "Micrel KSZ8061",
.phy_id_mask = MICREL_PHY_ID_MASK,
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = kszphy_config_init,
.config_aneg = genphy_config_aneg,
@@ -954,7 +949,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ9021,
.phy_id_mask = 0x000ffffe,
.name = "Micrel KSZ9021 Gigabit PHY",
- .features = (PHY_GBIT_FEATURES | SUPPORTED_Pause),
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz9021_type,
.config_init = ksz9021_config_init,
@@ -973,7 +968,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ9031,
.phy_id_mask = MICREL_PHY_ID_MASK,
.name = "Micrel KSZ9031 Gigabit PHY",
- .features = (PHY_GBIT_FEATURES | SUPPORTED_Pause),
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.driver_data = &ksz9021_type,
.config_init = ksz9031_config_init,
@@ -990,7 +985,6 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ8873MLL,
.phy_id_mask = MICREL_PHY_ID_MASK,
.name = "Micrel KSZ8873MLL Switch",
- .features = (SUPPORTED_Pause | SUPPORTED_Asym_Pause),
.flags = PHY_HAS_MAGICANEG,
.config_init = kszphy_config_init,
.config_aneg = ksz8873mll_config_aneg,
@@ -1004,7 +998,7 @@ static int kszphy_probe(struct phy_device *phydev)
.phy_id = PHY_ID_KSZ886X,
.phy_id_mask = MICREL_PHY_ID_MASK,
.name = "Micrel KSZ886X Switch",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
.config_init = kszphy_config_init,
.config_aneg = genphy_config_aneg,
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 7c00e50..4c83229 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -112,8 +112,7 @@ static int lan88xx_set_wol(struct phy_device *phydev,
.phy_id_mask = 0xfffffff0,
.name = "Microchip LAN88xx",
- .features = (PHY_GBIT_FEATURES |
- SUPPORTED_Pause | SUPPORTED_Asym_Pause),
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,
.probe = lan88xx_probe,
diff --git a/drivers/net/phy/national.c b/drivers/net/phy/national.c
index 2a1b490..2addf1d 100644
--- a/drivers/net/phy/national.c
+++ b/drivers/net/phy/national.c
@@ -133,7 +133,7 @@ static int ns_config_init(struct phy_device *phydev)
.phy_id = DP83865_PHY_ID,
.phy_id_mask = 0xfffffff0,
.name = "NatSemi DP83865",
- .features = PHY_GBIT_FEATURES | SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = ns_config_init,
.config_aneg = genphy_config_aneg,
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index b62c4aa..fb32eaf 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -168,8 +168,7 @@ static int smsc_phy_probe(struct phy_device *phydev)
.phy_id_mask = 0xfffffff0,
.name = "SMSC LAN83C185",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
- | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,
.probe = smsc_phy_probe,
@@ -191,8 +190,7 @@ static int smsc_phy_probe(struct phy_device *phydev)
.phy_id_mask = 0xfffffff0,
.name = "SMSC LAN8187",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
- | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,
.probe = smsc_phy_probe,
@@ -214,8 +212,7 @@ static int smsc_phy_probe(struct phy_device *phydev)
.phy_id_mask = 0xfffffff0,
.name = "SMSC LAN8700",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
- | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,
.probe = smsc_phy_probe,
@@ -237,8 +234,7 @@ static int smsc_phy_probe(struct phy_device *phydev)
.phy_id_mask = 0xfffffff0,
.name = "SMSC LAN911x Internal PHY",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
- | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,
.probe = smsc_phy_probe,
@@ -259,8 +255,7 @@ static int smsc_phy_probe(struct phy_device *phydev)
.phy_id_mask = 0xfffffff0,
.name = "SMSC LAN8710/LAN8720",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
- | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,
.probe = smsc_phy_probe,
@@ -282,8 +277,7 @@ static int smsc_phy_probe(struct phy_device *phydev)
.phy_id_mask = 0xfffffff0,
.name = "SMSC LAN8740",
- .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
- | SUPPORTED_Asym_Pause),
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,
.probe = smsc_phy_probe,
diff --git a/drivers/net/phy/ste10Xp.c b/drivers/net/phy/ste10Xp.c
index d00cfb6..1af1a4a 100644
--- a/drivers/net/phy/ste10Xp.c
+++ b/drivers/net/phy/ste10Xp.c
@@ -86,7 +86,7 @@ static int ste10Xp_ack_interrupt(struct phy_device *phydev)
.phy_id = STE101P_PHY_ID,
.phy_id_mask = 0xfffffff0,
.name = "STe101p",
- .features = PHY_BASIC_FEATURES | SUPPORTED_Pause,
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = ste10Xp_config_init,
.config_aneg = genphy_config_aneg,
@@ -99,7 +99,7 @@ static int ste10Xp_ack_interrupt(struct phy_device *phydev)
.phy_id = STE100P_PHY_ID,
.phy_id_mask = 0xffffffff,
.name = "STe100p",
- .features = PHY_BASIC_FEATURES | SUPPORTED_Pause,
+ .features = PHY_BASIC_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.config_init = ste10Xp_config_init,
.config_aneg = genphy_config_aneg,
--
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 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