* [PATCH 1/3] net: socionext: Stop PHY before resetting netsec
From: masahisa.kojima @ 2018-10-19 1:08 UTC (permalink / raw)
To: netdev
Cc: ilias.apalodimas, jaswinder.singh, ard.biesheuvel,
osaki.yoshitoyo, Masahisa Kojima
In-Reply-To: <20181019010843.3605-1-masahisa.kojima@linaro.org>
From: Masahisa Kojima <masahisa.kojima@linaro.org>
After resetting netsec IP, driver have to wait until
netsec mode turns to NRM mode.
But sometimes mode transition to NRM will not complete
if the PHY is in normal operation state.
To avoid this situation, stop PHY before resetting netsec.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Signed-off-by: Yoshitoyo Osaki <osaki.yoshitoyo@socionext.com>
---
drivers/net/ethernet/socionext/netsec.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/socionext/netsec.c b/drivers/net/ethernet/socionext/netsec.c
index 4289ccb26e4e..273cc5fc07e0 100644
--- a/drivers/net/ethernet/socionext/netsec.c
+++ b/drivers/net/ethernet/socionext/netsec.c
@@ -1343,11 +1343,11 @@ static int netsec_netdev_stop(struct net_device *ndev)
netsec_uninit_pkt_dring(priv, NETSEC_RING_TX);
netsec_uninit_pkt_dring(priv, NETSEC_RING_RX);
- ret = netsec_reset_hardware(priv, false);
-
phy_stop(ndev->phydev);
phy_disconnect(ndev->phydev);
+ ret = netsec_reset_hardware(priv, false);
+
pm_runtime_put_sync(priv->dev);
return ret;
@@ -1415,7 +1415,7 @@ static const struct net_device_ops netsec_netdev_ops = {
};
static int netsec_of_probe(struct platform_device *pdev,
- struct netsec_priv *priv)
+ struct netsec_priv *priv, u32 *phy_addr)
{
priv->phy_np = of_parse_phandle(pdev->dev.of_node, "phy-handle", 0);
if (!priv->phy_np) {
@@ -1423,6 +1423,8 @@ static int netsec_of_probe(struct platform_device *pdev,
return -EINVAL;
}
+ *phy_addr = of_mdio_parse_addr(&pdev->dev, priv->phy_np);
+
priv->clk = devm_clk_get(&pdev->dev, NULL); /* get by 'phy_ref_clk' */
if (IS_ERR(priv->clk)) {
dev_err(&pdev->dev, "phy_ref_clk not found\n");
@@ -1473,6 +1475,7 @@ static int netsec_register_mdio(struct netsec_priv *priv, u32 phy_addr)
{
struct mii_bus *bus;
int ret;
+ u16 data;
bus = devm_mdiobus_alloc(priv->dev);
if (!bus)
@@ -1486,6 +1489,10 @@ static int netsec_register_mdio(struct netsec_priv *priv, u32 phy_addr)
bus->parent = priv->dev;
priv->mii_bus = bus;
+ /* set phy power down */
+ data = netsec_phy_read(bus, phy_addr, 0) | 0x800;
+ netsec_phy_write(bus, phy_addr, 0, data);
+
if (dev_of_node(priv->dev)) {
struct device_node *mdio_node, *parent = dev_of_node(priv->dev);
@@ -1623,7 +1630,7 @@ static int netsec_probe(struct platform_device *pdev)
}
if (dev_of_node(&pdev->dev))
- ret = netsec_of_probe(pdev, priv);
+ ret = netsec_of_probe(pdev, priv, &phy_addr);
else
ret = netsec_acpi_probe(pdev, priv, &phy_addr);
if (ret)
--
2.14.2
^ permalink raw reply related
* [PATCH 0/3] Bugfix for the netsec driver
From: masahisa.kojima @ 2018-10-19 1:08 UTC (permalink / raw)
To: netdev
Cc: ilias.apalodimas, jaswinder.singh, ard.biesheuvel,
osaki.yoshitoyo, Masahisa Kojima
From: Masahisa Kojima <masahisa.kojima@linaro.org>
This patch series include bugfix for the netsec ethernet
controller driver, fix the problem in interface down/up.
Masahisa Kojima (3):
net: socionext: stop PHY before resetting netsec
net: socionext: Add dummy PHY register read in phy_write()
net: socionext: reset tx queue in ndo_stop
drivers/net/ethernet/socionext/netsec.c | 36 +++++++++++++++++++++++++++------
1 file changed, 30 insertions(+), 6 deletions(-)
--
2.14.2
^ permalink raw reply
* Re: [PATCH v2] isdn: hfc_{pci,sx}: Avoid empty body if statements
From: David Miller @ 2018-10-19 0:50 UTC (permalink / raw)
To: natechancellor; +Cc: isdn, netdev, linux-kernel, yamada.masahiro
In-Reply-To: <20181019004251.GA28878@flashbox>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Thu, 18 Oct 2018 17:42:51 -0700
> On Thu, Oct 18, 2018 at 05:23:10PM -0700, David Miller wrote:
>> From: Nathan Chancellor <natechancellor@gmail.com>
>> Date: Thu, 18 Oct 2018 17:21:17 -0700
>>
>> > Thanks for the review, I went ahead and compiled with the following diff
>> > on top of v2 and got no warnings from Clang, GCC, or sparse, does this
>> > seem satisfactory for v3?
>>
>> Well, one thing I notice.
>>
>
>> > @@ -86,7 +86,7 @@ release_io_hfcpci(struct IsdnCardState *cs)
>> > pci_free_consistent(cs->hw.hfcpci.dev, 0x8000,
>> > cs->hw.hfcpci.fifos, cs->hw.hfcpci.dma);
>> > cs->hw.hfcpci.fifos = NULL;
>> > - iounmap((void *)cs->hw.hfcpci.pci_io);
>> > + iounmap(cs->hw.hfcpci.pci_io);
>> > }
>>
>> Driver uses iounmap().
>>
>> > @@ -1692,7 +1692,7 @@ setup_hfcpci(struct IsdnCard *card)
>> > printk(KERN_WARNING "HFC-PCI: No IRQ for PCI card found\n");
>> > return (0);
>> > }
>> > - cs->hw.hfcpci.pci_io = (char *)(unsigned long)dev_hfcpci->resource[1].start;
>> > + cs->hw.hfcpci.pci_io = (void __iomem *)(unsigned long)dev_hfcpci->resource[1].start;
>> > printk(KERN_INFO "HiSax: HFC-PCI card manufacturer: %s card name: %s\n", id_list[i].vendor_name, id_list[i].card_name);
>>
>> But does not use iomap(). You won't need any cast here if it did use
>> iomap() properly.
>>
>> Thanks.
>
> So this?
That's definitely a lot better, yes!
I wonder what exactly it is checking there though. I guess it wants to see if the
resource->start value is zero and bail with an error it so.
Anyways, this code has been like this for ages and what you are proposing is
definitely a significant improvement.
Thanks.
^ permalink raw reply
* Re: [PATCH v4 bpf-next 1/2] bpf: add cg_skb_is_valid_access for BPF_PROG_TYPE_CGROUP_SKB
From: Daniel Borkmann @ 2018-10-19 0:14 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: ast, kernel-team
In-Reply-To: <20181018160649.1611530-2-songliubraving@fb.com>
On 10/18/2018 06:06 PM, Song Liu wrote:
> BPF programs of BPF_PROG_TYPE_CGROUP_SKB need to access headers in the
> skb. This patch enables direct access of skb for these programs.
>
> Two helper functions bpf_compute_and_save_data_pointers() and
> bpf_restore_data_pointers() are introduced. There are used in
> __cgroup_bpf_run_filter_skb(), to compute proper data_end for the
> BPF program, and restore original data afterwards.
>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
> include/linux/filter.h | 24 ++++++++++++++++++++++++
> kernel/bpf/cgroup.c | 6 ++++++
> net/core/filter.c | 36 +++++++++++++++++++++++++++++++++++-
> 3 files changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index 5771874bc01e..96b3ee7f14c9 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -548,6 +548,30 @@ static inline void bpf_compute_data_pointers(struct sk_buff *skb)
> cb->data_end = skb->data + skb_headlen(skb);
> }
>
> +/* Similar to bpf_compute_data_pointers(), except that save orginal
> + * data in cb->data and cb->meta_data for restore.
> + */
> +static inline void bpf_compute_and_save_data_pointers(
> + struct sk_buff *skb, void *saved_pointers[2])
> +{
> + struct bpf_skb_data_end *cb = (struct bpf_skb_data_end *)skb->cb;
> +
> + saved_pointers[0] = cb->data_meta;
> + saved_pointers[1] = cb->data_end;
> + cb->data_meta = skb->data - skb_metadata_len(skb);
> + cb->data_end = skb->data + skb_headlen(skb);
Hmm, can you elaborate why populating data_meta here ...
> +}
> +
> +/* Restore data saved by bpf_compute_data_pointers(). */
> +static inline void bpf_restore_data_pointers(
> + struct sk_buff *skb, void *saved_pointers[2])
> +{
> + struct bpf_skb_data_end *cb = (struct bpf_skb_data_end *)skb->cb;
> +
> + cb->data_meta = saved_pointers[0];
> + cb->data_end = saved_pointers[1];;
> +}
> +
> static inline u8 *bpf_skb_cb(struct sk_buff *skb)
> {
> /* eBPF programs may read/write skb->cb[] area to transfer meta
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 00f6ed2e4f9a..5f5180104ddc 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -554,6 +554,7 @@ int __cgroup_bpf_run_filter_skb(struct sock *sk,
> unsigned int offset = skb->data - skb_network_header(skb);
> struct sock *save_sk;
> struct cgroup *cgrp;
> + void *saved_pointers[2];
> int ret;
>
> if (!sk || !sk_fullsock(sk))
> @@ -566,8 +567,13 @@ int __cgroup_bpf_run_filter_skb(struct sock *sk,
> save_sk = skb->sk;
> skb->sk = sk;
> __skb_push(skb, offset);
> +
> + /* compute pointers for the bpf prog */
> + bpf_compute_and_save_data_pointers(skb, saved_pointers);
> +
> ret = BPF_PROG_RUN_ARRAY(cgrp->bpf.effective[type], skb,
> bpf_prog_run_save_cb);
> + bpf_restore_data_pointers(skb, saved_pointers);
> __skb_pull(skb, offset);
> skb->sk = save_sk;
> return ret == 1 ? 0 : -EPERM;
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 1a3ac6c46873..e3ca30bd6840 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -5346,6 +5346,40 @@ static bool sk_filter_is_valid_access(int off, int size,
> return bpf_skb_is_valid_access(off, size, type, prog, info);
> }
>
> +static bool cg_skb_is_valid_access(int off, int size,
> + enum bpf_access_type type,
> + const struct bpf_prog *prog,
> + struct bpf_insn_access_aux *info)
> +{
> + switch (off) {
> + case bpf_ctx_range(struct __sk_buff, tc_classid):
> + case bpf_ctx_range(struct __sk_buff, data_meta):
> + case bpf_ctx_range(struct __sk_buff, flow_keys):
> + return false;
... if it's disallowed anyway (disallowing it is the right thing to do,
but no need to save/restore then..)?
> + }
> + if (type == BPF_WRITE) {
> + switch (off) {
> + case bpf_ctx_range(struct __sk_buff, mark):
> + case bpf_ctx_range(struct __sk_buff, priority):
> + case bpf_ctx_range_till(struct __sk_buff, cb[0], cb[4]):
> + break;
> + default:
> + return false;
> + }
> + }
> +
> + switch (off) {
> + case bpf_ctx_range(struct __sk_buff, data):
> + info->reg_type = PTR_TO_PACKET;
> + break;
> + case bpf_ctx_range(struct __sk_buff, data_end):
> + info->reg_type = PTR_TO_PACKET_END;
> + break;
> + }
> +
> + return bpf_skb_is_valid_access(off, size, type, prog, info);
> +}
> +
> static bool lwt_is_valid_access(int off, int size,
> enum bpf_access_type type,
> const struct bpf_prog *prog,
> @@ -7038,7 +7072,7 @@ const struct bpf_prog_ops xdp_prog_ops = {
>
> const struct bpf_verifier_ops cg_skb_verifier_ops = {
> .get_func_proto = cg_skb_func_proto,
> - .is_valid_access = sk_filter_is_valid_access,
> + .is_valid_access = cg_skb_is_valid_access,
> .convert_ctx_access = bpf_convert_ctx_access,
> };
>
>
^ permalink raw reply
* Re: [GIT] Networking
From: Greg KH @ 2018-10-19 8:13 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20181018.171914.1210096727703399564.davem@davemloft.net>
On Thu, Oct 18, 2018 at 05:19:14PM -0700, David Miller wrote:
>
> 1) Fix gro_cells leak in xfrm layer, from Li RongQing.
>
> 2) BPF selftests change RLIMIT_MEMLOCK blindly, don't do that.
> From Eric Dumazet.
>
> 3) AF_XDP calls synchronize_net() under RCU lock, fix from Björn
> Töpel.
>
> 4) Out of bounds packet access in _decode_session6(), from Alexei
> Starovoitov.
>
> 5) Several ethtool bugs, where we copy a struct into the kernel
> twice and our validations of the values in the first copy can
> be invalidated by the second copy due to asynchronous updates
> to the memory by the user. From Wenwen Wang.
>
> 6) Missing netlink attribute validation in cls_api, from Davide
> Caratti.
>
> 7) LLC SAP sockets neet to be SOCK_RCU FREE, from Cong Wang.
>
> 8) rxrpc operates on wrong kvec, from Yue Haibing.
>
> 9) A regression was introduced by the disassosciation of route
> neighbour references in rt6_probe(), causing probe for
> neighbourless routes to not be properly rate limited. Fix
> from Sabrina Dubroca.
>
> 10) Unsafe RCU locking in tipc, from Tung Nguyen.
>
> 11) Use after free in inet6_mc_check(), from Eric Dumazet.
>
> 12) PMTU from icmp packets should update the SCTP transport
> pathmtu, from Xin Long.
>
> 13) Missing peer put on error in rxrpc, from David Howells.
>
> 14) Fix pedit in nfp driver, from Pieter Jansen van Vuuren.
>
> 15) Fix overflowing shift statement in qla3xxx driver, from Nathan
> Chancellor.
>
> 16) Fix Spectre v1 in ptp code, from Gustavo A. R. Silva.
>
> 17) udp6_unicast_rcv_skb() interprets udpv6_queue_rcv_skb() return
> value in an inverted manner, fix from Paolo Abeni.
>
> 18) Fix missed unresolved entries in ipmr dumps, from Nikolay
> Aleksandrov.
>
> 19) Fix NAPI handling under high load, we can completely miss events
> when NAPI has to loop more than one time in a cycle. From Heiner
> Kallweit.
>
> Please pull, thanks a lot!
>
> The following changes since commit bab5c80b211035739997ebd361a679fa85b39465:
>
> Merge tag 'armsoc-fixes-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-10-12 17:41:27 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
Now merged, thanks.
greg k-h
^ permalink raw reply
* Re: [pull request][net-next 0/8] Mellanox, mlx5 updates 2018-10-18
From: David Miller @ 2018-10-19 0:02 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20181018203907.25149-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 18 Oct 2018 13:38:59 -0700
> This pull request provides some misc updates to mlx5 core and netdevice
> driver.
>
> For more details please see tag log below.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Saeed.
^ permalink raw reply
* Re: [PATCH net] ip6_tunnel: Fix encapsulation layout
From: David Miller @ 2018-10-18 23:55 UTC (permalink / raw)
To: sbrivio; +Cc: tom, kraig, pabeni, netdev
In-Reply-To: <f5f6a69915694976b6feec7ae64a89e1da4e551f.1539890448.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Thu, 18 Oct 2018 21:25:07 +0200
> Commit 058214a4d1df ("ip6_tun: Add infrastructure for doing
> encapsulation") added the ip6_tnl_encap() call in ip6_tnl_xmit(), before
> the call to ipv6_push_frag_opts() to append the IPv6 Tunnel Encapsulation
> Limit option (option 4, RFC 2473, par. 5.1) to the outer IPv6 header.
>
> As long as the option didn't actually end up in generated packets, this
> wasn't an issue. Then commit 89a23c8b528b ("ip6_tunnel: Fix missing tunnel
> encapsulation limit option") fixed sending of this option, and the
> resulting layout, e.g. for FoU, is:
>
> .-------------------.------------.----------.-------------------.----- - -
> | Outer IPv6 Header | UDP header | Option 4 | Inner IPv6 Header | Payload
> '-------------------'------------'----------'-------------------'----- - -
>
> Needless to say, FoU and GUE (at least) won't work over IPv6. The option
> is appended by default, and I couldn't find a way to disable it with the
> current iproute2.
>
> Turn this into a more reasonable:
>
> .-------------------.----------.------------.-------------------.----- - -
> | Outer IPv6 Header | Option 4 | UDP header | Inner IPv6 Header | Payload
> '-------------------'----------'------------'-------------------'----- - -
>
> With this, and with 84dad55951b0 ("udp6: fix encap return code for
> resubmitting"), FoU and GUE work again over IPv6.
>
> Fixes: 058214a4d1df ("ip6_tun: Add infrastructure for doing encapsulation")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
This goes back to v4.7 then, I can't believe this has been broken for
so long. :-/
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: Extend the sk_lookup() helper to XDP hookpoint.
From: Joe Stringer @ 2018-10-18 23:52 UTC (permalink / raw)
To: daniel, Martin KaFai Lau
Cc: Joe Stringer, Nitin Hande, netdev, ast, Jesper Brouer,
john fastabend
In-Reply-To: <f13124bf-bb4f-b681-d014-299993305262@iogearbox.net>
On Thu, 18 Oct 2018 at 14:20, Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 10/18/2018 11:06 PM, Joe Stringer wrote:
> > On Thu, 18 Oct 2018 at 11:54, Nitin Hande <nitin.hande@gmail.com> wrote:
> [...]
> >> Open Issue
> >> * The underlying code relies on presence of an skb to find out the
> >> right sk for the case of REUSEPORT socket option. Since there is
> >> no skb available at XDP hookpoint, the helper function will return
> >> the first available sk based off the 5 tuple hash. If the desire
> >> is to return a particular sk matching reuseport_cb function, please
> >> suggest way to tackle it, which can be addressed in a future commit.
>
> >> Signed-off-by: Nitin Hande <Nitin.Hande@gmail.com>
> >
> > Thanks Nitin, LGTM overall.
> >
> > The REUSEPORT thing suggests that the usage of this helper from XDP
> > layer may lead to a different socket being selected vs. the equivalent
> > call at TC hook, or other places where the selection may occur. This
> > could be a bit counter-intuitive.
> >
> > One thought I had to work around this was to introduce a flag,
> > something like BPF_F_FIND_REUSEPORT_SK_BY_HASH. This flag would
> > effectively communicate in the API that the bpf_sk_lookup_xxx()
> > functions will only select a REUSEPORT socket based on the hash and
> > not by, for example BPF_PROG_TYPE_SK_REUSEPORT programs. The absence
> > of the flag would support finding REUSEPORT sockets by other
> > mechanisms (which would be allowed for now from TC hooks but would be
> > disallowed from XDP, since there's no specific plan to support this).
>
> Hmm, given skb is NULL here the only way to lookup the socket in such
> scenario is based on hash, that is, inet_ehashfn() / inet6_ehashfn(),
> perhaps alternative is to pass this hash in from XDP itself to the
> helper so it could be custom selector. Do you have a specific use case
> on this for XDP (just curious)?
I don't have a use case for SO_REUSEPORT introspection from XDP, so
I'm primarily thinking from the perspective of making the behaviour
clear in the API in a way that leaves open the possibility for a
reasonable implementation in future. From that perspective, my main
concern is that it may surprise some BPF writers that the same
"bpf_sk_lookup_tcp()" call (with identical parameters) may have
different behaviour at TC vs. XDP layers, as the BPF selection of
sockets is respected at TC but not at XDP.
FWIW we're already out of parameters for the actual call, so if we
wanted to allow passing a hash in, we'd need to either dedicate half
the 'flags' field for this configurable hash, or consider adding the
new hash parameter to 'struct bpf_sock_tuple'.
+Martin for any thoughts on SO_REUSEPORT and XDP here.
^ permalink raw reply
* Re: [PATCH net-next] tcp: fix TCP_REPAIR xmit queue setup
From: David Miller @ 2018-10-18 23:51 UTC (permalink / raw)
To: edumazet; +Cc: ncardwell, soheil, avagin, netdev, eric.dumazet
In-Reply-To: <20181018161219.127534-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 18 Oct 2018 09:12:19 -0700
> Andrey reported the following warning triggered while running CRIU tests:
>
> tcp_clean_rtx_queue()
> ...
> last_ackt = tcp_skb_timestamp_us(skb);
> WARN_ON_ONCE(last_ackt == 0);
>
> This is caused by 5f6188a8003d ("tcp: do not change tcp_wstamp_ns
> in tcp_mstamp_refresh"), as we end up having skbs in retransmit queue
> with a zero skb->skb_mstamp_ns field.
>
> We could fix this bug in different ways, like making sure
> tp->tcp_wstamp_ns is not zero at socket creation, but as Neal pointed
> out, we also do not want that pacing status of a repaired socket
> could push tp->tcp_wstamp_ns far ahead in the future.
>
> So we prefer changing tcp_write_xmit() to not call tcp_update_skb_after_send()
> and instead do what is requested by TCP_REPAIR logic.
>
> Fixes: 5f6188a8003d ("tcp: do not change tcp_wstamp_ns in tcp_mstamp_refresh")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andrey Vagin <avagin@openvz.org>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [net 1/1] tipc: fix info leak from kernel tipc_event
From: David Miller @ 2018-10-18 23:51 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1539877109-7722-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 18 Oct 2018 17:38:29 +0200
> We initialize a struct tipc_event allocated on the kernel stack to
> zero to avert info leak to user space.
>
> Reported-by: syzbot+057458894bc8cada4dee@syzkaller.appspotmail.com
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net: ipmr: fix unresolved entry dumps
From: David Miller @ 2018-10-18 23:46 UTC (permalink / raw)
To: dsahern; +Cc: nikolay, netdev
In-Reply-To: <ec18010b-cd8a-f419-a929-c0b1a0a09928@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Thu, 18 Oct 2018 09:16:17 -0600
> On 10/17/18 11:36 PM, David Miller wrote:
>> From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>> Date: Wed, 17 Oct 2018 22:34:34 +0300
>>
>>> If the skb space ends in an unresolved entry while dumping we'll miss
>>> some unresolved entries. The reason is due to zeroing the entry counter
>>> between dumping resolved and unresolved mfc entries. We should just
>>> keep counting until the whole table is dumped and zero when we move to
>>> the next as we have a separate table counter.
>>>
>>> Reported-by: Colin Ian King <colin.king@canonical.com>
>>> Fixes: 8fb472c09b9d ("ipmr: improve hash scalability")
>>> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>>
>> Applied and queued up for -stable.
>>
>
> FYI: on the net to net-next merge, those 2 lines were moved to
> mr_table_dump.
Thanks for the heads up.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: Extend the sk_lookup() helper to XDP hookpoint.
From: Nitin Hande @ 2018-10-18 23:32 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Joe Stringer, netdev, ast, Jesper Brouer, john fastabend
In-Reply-To: <f13124bf-bb4f-b681-d014-299993305262@iogearbox.net>
On Thu, 18 Oct 2018 23:20:17 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 10/18/2018 11:06 PM, Joe Stringer wrote:
> > On Thu, 18 Oct 2018 at 11:54, Nitin Hande <nitin.hande@gmail.com> wrote:
> [...]
> >> Open Issue
> >> * The underlying code relies on presence of an skb to find out the
> >> right sk for the case of REUSEPORT socket option. Since there is
> >> no skb available at XDP hookpoint, the helper function will return
> >> the first available sk based off the 5 tuple hash. If the desire
> >> is to return a particular sk matching reuseport_cb function, please
> >> suggest way to tackle it, which can be addressed in a future commit.
>
> >> Signed-off-by: Nitin Hande <Nitin.Hande@gmail.com>
> >
> > Thanks Nitin, LGTM overall.
> >
> > The REUSEPORT thing suggests that the usage of this helper from XDP
> > layer may lead to a different socket being selected vs. the equivalent
> > call at TC hook, or other places where the selection may occur. This
> > could be a bit counter-intuitive.
> >
> > One thought I had to work around this was to introduce a flag,
> > something like BPF_F_FIND_REUSEPORT_SK_BY_HASH. This flag would
> > effectively communicate in the API that the bpf_sk_lookup_xxx()
> > functions will only select a REUSEPORT socket based on the hash and
> > not by, for example BPF_PROG_TYPE_SK_REUSEPORT programs. The absence
> > of the flag would support finding REUSEPORT sockets by other
> > mechanisms (which would be allowed for now from TC hooks but would be
> > disallowed from XDP, since there's no specific plan to support this).
Thanks Joe for the quick response.This certainly looks feasible. With the
flag, both tc and XDP hookpoints will be consistent in their approach.
>
> Hmm, given skb is NULL here the only way to lookup the socket in such
> scenario is based on hash, that is, inet_ehashfn() / inet6_ehashfn(),
> perhaps alternative is to pass this hash in from XDP itself to the
> helper so it could be custom selector.
Interesting, and this will be an additional helper or done within this
sk_lookup() helper ?
Do you have a specific use case
> on this for XDP (just curious)?
Yes, this is for a dual-stack solution. The XDP program functions as a
demux, if there is a receiver the packet will be ingressed on Linux
networking stack, else it enters the other stack path.
Thanks
Nitin
>
> Thanks,
> Daniel
^ permalink raw reply
* Re: [PATCH v4 bpf-next 0/2] bpf: add cg_skb_is_valid_access
From: Alexei Starovoitov @ 2018-10-18 23:34 UTC (permalink / raw)
To: Song Liu; +Cc: netdev, ast, daniel, kernel-team
In-Reply-To: <20181018160649.1611530-1-songliubraving@fb.com>
On Thu, Oct 18, 2018 at 09:06:47AM -0700, Song Liu wrote:
> Changes v3 -> v4:
> 1. Fixed crash issue reported by Alexei.
>
> Changes v2 -> v3:
> 1. Added helper function bpf_compute_and_save_data_pointers() and
> bpf_restore_data_pointers().
>
> Changes v1 -> v2:
> 1. Updated the list of read-only fields, and read-write fields.
> 2. Added dummy sk to bpf_prog_test_run_skb().
>
> This set enables BPF program of type BPF_PROG_TYPE_CGROUP_SKB to access
> some __skb_buff data directly.
Applied, Thanks
^ permalink raw reply
* linux-next: Signed-off-by missing for commits in the net-next tree
From: Stephen Rothwell @ 2018-10-19 7:30 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Saeed Mahameed
[-- Attachment #1: Type: text/plain, Size: 261 bytes --]
Hi all,
Commits
2a4c42980250 ("net/mlx5: Remove counter from idr after removing it from list")
fd3307130344 ("net/mlx5: Take fs_counters dellist before addlist")
are missing a Signed-off-by from their committer.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: fix the error path of cxgb4_uld_register()
From: David Miller @ 2018-10-18 23:26 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, dt, harsh, linux-crypto
In-Reply-To: <1539871459-6921-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Thu, 18 Oct 2018 19:34:19 +0530
> On multi adapter setup if the uld registration fails even on
> one adapter, the allocated resources for the uld on all the
> adapters are freed, rendering the functioning adapters unusable.
>
> This commit fixes the issue by freeing the allocated resources
> only for the failed adapter.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] net: ethernet: lpc_eth: add device and device node local variables
From: Vladimir Zapolskiy @ 2018-10-18 23:25 UTC (permalink / raw)
To: David S. Miller; +Cc: Sylvain Lemieux, netdev
Trivial non-functional change added to simplify getting multiple
references to device pointer in lpc_eth_drv_probe().
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
NB, to avoid a merge conflict the change should be applied
after https://marc.info/?l=linux-netdev&m=153990402012273
drivers/net/ethernet/nxp/lpc_eth.c | 40 ++++++++++++++++--------------
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index e275d64007af..ecc7f464c238 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1242,17 +1242,19 @@ static const struct net_device_ops lpc_netdev_ops = {
static int lpc_eth_drv_probe(struct platform_device *pdev)
{
- struct resource *res;
- struct net_device *ndev;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
struct netdata_local *pldat;
+ struct net_device *ndev;
dma_addr_t dma_handle;
+ struct resource *res;
int irq, ret;
u32 tmp;
/* Setup network interface for RMII or MII mode */
tmp = __raw_readl(LPC32XX_CLKPWR_MACCLK_CTRL);
tmp &= ~LPC32XX_CLKPWR_MACCTRL_PINS_MSK;
- if (lpc_phy_interface_mode(&pdev->dev) == PHY_INTERFACE_MODE_MII)
+ if (lpc_phy_interface_mode(dev) == PHY_INTERFACE_MODE_MII)
tmp |= LPC32XX_CLKPWR_MACCTRL_USE_MII_PINS;
else
tmp |= LPC32XX_CLKPWR_MACCTRL_USE_RMII_PINS;
@@ -1262,7 +1264,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq = platform_get_irq(pdev, 0);
if (!res || irq < 0) {
- dev_err(&pdev->dev, "error getting resources.\n");
+ dev_err(dev, "error getting resources.\n");
ret = -ENXIO;
goto err_exit;
}
@@ -1270,12 +1272,12 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
/* Allocate net driver data structure */
ndev = alloc_etherdev(sizeof(struct netdata_local));
if (!ndev) {
- dev_err(&pdev->dev, "could not allocate device.\n");
+ dev_err(dev, "could not allocate device.\n");
ret = -ENOMEM;
goto err_exit;
}
- SET_NETDEV_DEV(ndev, &pdev->dev);
+ SET_NETDEV_DEV(ndev, dev);
pldat = netdev_priv(ndev);
pldat->pdev = pdev;
@@ -1287,9 +1289,9 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
ndev->irq = irq;
/* Get clock for the device */
- pldat->clk = clk_get(&pdev->dev, NULL);
+ pldat->clk = clk_get(dev, NULL);
if (IS_ERR(pldat->clk)) {
- dev_err(&pdev->dev, "error getting clock.\n");
+ dev_err(dev, "error getting clock.\n");
ret = PTR_ERR(pldat->clk);
goto err_out_free_dev;
}
@@ -1302,14 +1304,14 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
/* Map IO space */
pldat->net_base = ioremap(res->start, resource_size(res));
if (!pldat->net_base) {
- dev_err(&pdev->dev, "failed to map registers\n");
+ dev_err(dev, "failed to map registers\n");
ret = -ENOMEM;
goto err_out_disable_clocks;
}
ret = request_irq(ndev->irq, __lpc_eth_interrupt, 0,
ndev->name, ndev);
if (ret) {
- dev_err(&pdev->dev, "error requesting interrupt.\n");
+ dev_err(dev, "error requesting interrupt.\n");
goto err_out_iounmap;
}
@@ -1323,7 +1325,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
sizeof(struct txrx_desc_t) + sizeof(struct rx_status_t));
pldat->dma_buff_base_v = 0;
- if (use_iram_for_net(&pldat->pdev->dev)) {
+ if (use_iram_for_net(dev)) {
dma_handle = LPC32XX_IRAM_BASE;
if (pldat->dma_buff_size <= lpc32xx_return_iram_size())
pldat->dma_buff_base_v =
@@ -1334,7 +1336,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
}
if (pldat->dma_buff_base_v == 0) {
- ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret)
goto err_out_free_irq;
@@ -1343,7 +1345,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
/* Allocate a chunk of memory for the DMA ethernet buffers
and descriptors */
pldat->dma_buff_base_v =
- dma_alloc_coherent(&pldat->pdev->dev,
+ dma_alloc_coherent(dev,
pldat->dma_buff_size, &dma_handle,
GFP_KERNEL);
if (pldat->dma_buff_base_v == NULL) {
@@ -1368,7 +1370,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
__lpc_get_mac(pldat, ndev->dev_addr);
if (!is_valid_ether_addr(ndev->dev_addr)) {
- const char *macaddr = of_get_mac_address(pdev->dev.of_node);
+ const char *macaddr = of_get_mac_address(np);
if (macaddr)
memcpy(ndev->dev_addr, macaddr, ETH_ALEN);
}
@@ -1398,7 +1400,7 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
ret = register_netdev(ndev);
if (ret) {
- dev_err(&pdev->dev, "Cannot register net device, aborting.\n");
+ dev_err(dev, "Cannot register net device, aborting.\n");
goto err_out_dma_unmap;
}
platform_set_drvdata(pdev, ndev);
@@ -1410,17 +1412,17 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
netdev_info(ndev, "LPC mac at 0x%08x irq %d\n",
res->start, ndev->irq);
- device_init_wakeup(&pdev->dev, 1);
- device_set_wakeup_enable(&pdev->dev, 0);
+ device_init_wakeup(dev, 1);
+ device_set_wakeup_enable(dev, 0);
return 0;
err_out_unregister_netdev:
unregister_netdev(ndev);
err_out_dma_unmap:
- if (!use_iram_for_net(&pldat->pdev->dev) ||
+ if (!use_iram_for_net(dev) ||
pldat->dma_buff_size > lpc32xx_return_iram_size())
- dma_free_coherent(&pldat->pdev->dev, pldat->dma_buff_size,
+ dma_free_coherent(dev, pldat->dma_buff_size,
pldat->dma_buff_base_v,
pldat->dma_buff_base_p);
err_out_free_irq:
--
2.17.1
^ permalink raw reply related
* [PATCH] net: ethernet: lpc_eth: remove unused local variable
From: Vladimir Zapolskiy @ 2018-10-18 23:06 UTC (permalink / raw)
To: David S. Miller; +Cc: Sylvain Lemieux, netdev
A trivial change which removes an unused local variable, the issue
is reported as a compile time warning:
drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe':
drivers/net/ethernet/nxp/lpc_eth.c:1250:21: warning: variable 'phydev' set but not used [-Wunused-but-set-variable]
struct phy_device *phydev;
^~~~~~
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/net/ethernet/nxp/lpc_eth.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 922b5b5b5c01..e275d64007af 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1245,7 +1245,6 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
struct resource *res;
struct net_device *ndev;
struct netdata_local *pldat;
- struct phy_device *phydev;
dma_addr_t dma_handle;
int irq, ret;
u32 tmp;
@@ -1411,8 +1410,6 @@ static int lpc_eth_drv_probe(struct platform_device *pdev)
netdev_info(ndev, "LPC mac at 0x%08x irq %d\n",
res->start, ndev->irq);
- phydev = ndev->phydev;
-
device_init_wakeup(&pdev->dev, 1);
device_set_wakeup_enable(&pdev->dev, 0);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 0/6] net/ncsi: Allow enabling multiple packages & channels
From: Samuel Mendoza-Jonas @ 2018-10-18 23:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Justin.Lee1, linux-kernel, openbmc
In-Reply-To: <20181018.155647.1045018243241594303.davem@davemloft.net>
On Thu, 2018-10-18 at 15:56 -0700, David Miller wrote:
> From: Samuel Mendoza-Jonas <sam@mendozajonas.com>
> Date: Thu, 18 Oct 2018 14:59:11 +1100
>
> > This series extends the NCSI driver to configure multiple packages
> > and/or channels simultaneously. Since the RFC series this includes a few
> > extra changes to fix areas in the driver that either made this harder or
> > were roadblocks due to deviations from the NCSI specification.
> >
> > Patches 1 & 2 fix two issues where the driver made assumptions about the
> > capabilities of the NCSI topology.
> > Patches 3 & 4 change some internal semantics slightly to make multi-mode
> > easier.
> > Patch 5 introduces a cleaner way of reconfiguring the NCSI configuration
> > and keeping track of channel states.
> > Patch 6 implements the main multi-package/multi-channel configuration,
> > configured via the Netlink interface.
> >
> > Readers who have an interesting NCSI setup - especially multi-package
> > with HWA - please test! I think I've covered all permutations but I
> > don't have infinite hardware to test on.
>
> This doesn't apply cleanly to net-next. Does it depend upon changes
> applied elsewhere? You must always make that explicit.
Ah, my mistake; I hadn't updated my net-next branch recently enough and
missed Vijay's OEM command patch. Will rebase.
>
> Also, please explain this locking in ncsi_reset_dev():
>
> + NCSI_FOR_EACH_PACKAGE(ndp, np) {
> + NCSI_FOR_EACH_CHANNEL(np, nc) {
> + spin_lock_irqsave(&nc->lock, flags);
> + enabled = nc->monitor.enabled;
> + state = nc->state;
> + spin_unlock_irqrestore(&nc->lock, flags);
> +
> + if (enabled)
> + ncsi_stop_channel_monitor(nc);
> + if (state == NCSI_CHANNEL_ACTIVE) {
> + active = nc;
> + break;
> + }
>
> Is that really protecting anything?
>
> Right after you drop np->lock those two values can change, the state
> of the 'nc' can change such that it isn't NCSI_CHANNEL_ACTIVE anymore
> etc.
>
> At best this locking makes sure thatn enabled and state are consistent
> with respect to eachother, only. It doesn't guarantee anything about
> the stability of the state of the object at all, and it can change
> right from under you.
And you've caught this correctly, I'll fix this up in the rebase to
protect actually checking the channel/monitor state.
Thanks,
Sam
^ permalink raw reply
* RE: [PATCH] net: ethernet: fec: Add missing SPEED_
From: Andy Duan @ 2018-10-19 7:07 UTC (permalink / raw)
To: Heiner Kallweit, Florian Fainelli, LABBE Corentin
Cc: andrew@lunn.ch, davem@davemloft.net, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <f1933c0a-d124-a7ac-afab-2fa8f88907ab@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com> Sent: 2018年10月19日 4:41
> On 18.10.2018 22:10, Florian Fainelli wrote:
> > On 10/18/2018 12:59 PM, LABBE Corentin wrote:
> >> On Thu, Oct 18, 2018 at 12:38:32PM -0700, Florian Fainelli wrote:
> >>> On 10/18/2018 12:16 PM, LABBE Corentin wrote:
> >>>> On Thu, Oct 18, 2018 at 11:55:49AM -0700, Florian Fainelli wrote:
> >>>>> On 10/18/2018 11:47 AM, LABBE Corentin wrote:
> >>>>>> On Thu, Oct 18, 2018 at 11:39:24AM -0700, Florian Fainelli
> wrote:
> >>>>>>> On 10/18/2018 08:05 AM, Corentin Labbe wrote:
> >>>>>>>> Since commit 58056c1e1b0e ("net: ethernet: Use
> phy_set_max_speed() to limit advertised speed"), the fec driver is unable
> to get any link.
> >>>>>>>> This is due to missing SPEED_.
> >>>>>>>
> >>>>>>> But SPEED_1000 is defined in include/uapi/linux/ethtool.h as
> >>>>>>> 1000, so surely this would amount to the same code paths being
> >>>>>>> taken or am I missing something here?
> >>>>>>
> >>>>>> The bisect session pointed your patch, reverting it fix the issue.
> >>>>>> BUT since the fix seemed trivial I sent the patch without more test
> then compile it.
> >>>>>> Sorry, I have just found some minutes ago that it didnt fix the
> issue.
> >>>>>>
> >>>>>> But your patch is still the cause for sure.
> >>>>>>
> >>>>>
> >>>>> What you are writing is really lowering the confidence level,
> >>>>> first Andrew is the author of that patch, and second "just
> >>>>> compiling" and pretending this fixes a problem when it does not is
> >>>>> not quite what I would expect.
> >>>>>
> >>>>> I don't have a problem helping you find the solution or the right
> >>>>> fix though, even if it is not my patch, but please get the author
> >>>>> and actual problem right so we can move forward in confidence,
> thanks!
> >>>>
> >>>> Sorry again, I wanted to acknoledge my error but I did it too fast and
> late.
> >>>> And sorry to have confound you with Andrew.
> >>>
> >>> No worries, here to help, let us know what your bisection points to.
> >>> THanks
> >>
> >> I have added printing of phydev->supported My working kernel (on top
> >> of 58056c1e1b0e + revert patch) got:
> >> [ 5.550838] fec_enet_mii_probe 2ff (gbit features)
> >> [ 5.555848] fec_enet_mii_probe 2ef (without 1000baseT_Half)
> >> [ 5.561620] fec_enet_mii_probe 22ef final (after pause)
> >> [ 5.566914] Micrel KSZ9021 Gigabit PHY 2188000.ethernet-1:06:
> attached PHY driver [Micrel KSZ9021 Gigabit PHY]
> (mii_bus:phy_addr=2188000.ethernet-1:06, irq=POLL)
> >> [ 8.730751] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full -
> flow control rx/tx
> >> [ 8.788311] Sending DHCP requests ., OK
> >> [ 8.832357] IP-Config: Got DHCP answer from 192.168.66.1, my
> address is 192.168.66.58
> >>
> >> the non-working kernel (next-20181015)
> >> [ 7.308917] fec_enet_mii_probe 62ff after phy_set_max_speed
> >> [ 7.314545] fec_enet_mii_probe 62ef after
> phy_remove_link_mode
> >> [ 7.320418] fec_enet_mii_probe 62ef after pause
> >> and then no link
> >>
> >> So it seems that phy_set_max_speed adds bit 14
> >> (ETHTOOL_LINK_MODE_Asym_Pause_BIT)
> >
> > It's not masking it so it must be coming from phy_probe().
> >
> See df8ed346d4a8 ("net: phy: fix flag masking in __set_phy_supported").
> phy_set_max_speed() used to (unintentionally) mask the pause bits and it
> seems that the fec driver used this bug as a feature.
>
> >>
> >> I have patched by adding:
> >> phy_remove_link_mode(phy_dev,
> ETHTOOL_LINK_MODE_Asym_Pause_BIT);
>
> Instead of programmatically removing the feature bit it should be possible
> to do this in the PHY driver configuration. See also this part of
> phy_probe().
>
> if (phydrv->features & (SUPPORTED_Pause |
> SUPPORTED_Asym_Pause)) {
> phydev->supported &= ~(SUPPORTED_Pause |
> SUPPORTED_Asym_Pause);
> phydev->supported |= phydrv->features &
> (SUPPORTED_Pause | SUPPORTED_Asym_Pause);
> } else {
> phydev->supported |= SUPPORTED_Pause |
> SUPPORTED_Asym_Pause;
> }
The ksz9021 phy driver don't set Pause feature, then the phylib enable "SUPPORTED_Pause" and " SUPPORTED_Asym_Pause" in both.
Micrel.c:
.phy_id = PHY_ID_KSZ9021,
.phy_id_mask = 0x000ffffe,
.name = "Micrel KSZ9021 Gigabit PHY",
.features = PHY_GBIT_FEATURES,
From @LABBE Corentin debug, it seem ksz9021 cannot advertise Pause and Asym pause in both, otherwise it cannot link up.
From ksz9021 datasheet description as below, Symmetric & Asymmetric PAUSE is for local device, I don't understand its mean.
4.11:10 Pause
[0,0] = No PAUSE
[1,0] = Asymmetric PAUSE (link partner)
[0,1] = Symmetric PAUSE
[1,1] = Symmetric & Asymmetric PAUSE (local device)
@ LABBE Corentin, you can try this:
Micrel.c:
.phy_id = PHY_ID_KSZ9021,
.phy_id_mask = 0x000ffffe,
.name = "Micrel KSZ9021 Gigabit PHY",
.features = PHY_GBIT_FEATURES | SUPPORTED_Pause,
In fact, I test net tree without any change with AR8031 and there has no link problem.
Andy
^ permalink raw reply
* Re: [net PATCH] net: sched: Fix for duplicate class dump
From: David Miller @ 2018-10-18 23:00 UTC (permalink / raw)
To: phil; +Cc: netdev, edumazet
In-Reply-To: <20181018083426.6623-1-phil@nwl.cc>
From: Phil Sutter <phil@nwl.cc>
Date: Thu, 18 Oct 2018 10:34:26 +0200
> When dumping classes by parent, kernel would return classes twice:
>
> | # tc qdisc add dev lo root prio
> | # tc class show dev lo
> | class prio 8001:1 parent 8001:
> | class prio 8001:2 parent 8001:
> | class prio 8001:3 parent 8001:
> | # tc class show dev lo parent 8001:
> | class prio 8001:1 parent 8001:
> | class prio 8001:2 parent 8001:
> | class prio 8001:3 parent 8001:
> | class prio 8001:1 parent 8001:
> | class prio 8001:2 parent 8001:
> | class prio 8001:3 parent 8001:
>
> This comes from qdisc_match_from_root() potentially returning the root
> qdisc itself if its handle matched. Though in that case, root's classes
> were already dumped a few lines above.
>
> Fixes: cb395b2010879 ("net: sched: optimize class dumps")
> Signed-off-by: Phil Sutter <phil@nwl.cc>
Applied and queued up for -stable, thanks Phil.
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Copy and paste bug in extended tx_stats
From: David Miller @ 2018-10-18 22:59 UTC (permalink / raw)
To: dan.carpenter; +Cc: michael.chan, netdev, kernel-janitors
In-Reply-To: <20181018080239.z2egoh4bw4beb3r3@kili.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 18 Oct 2018 11:02:39 +0300
> The struct type was copied from the line before but it should be "tx"
> instead of "rx". I have reviewed the code and I can't immediately see
> that this bug causes a runtime issue.
>
> Fixes: 36e53349b60b ("bnxt_en: Add additional extended port statistics.")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> This is from static analysis and I don't have a way to test it.
Applied.
^ permalink raw reply
* Re: [PATCH v2 net] r8169: fix NAPI handling under high load
From: Francois Romieu @ 2018-10-18 22:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: Heiner Kallweit, David Miller, Realtek linux nic maintainers,
netdev@vger.kernel.org
In-Reply-To: <05eb4233-bf98-4aeb-73f6-94fec46ca3de@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> :
[...]
> One has to wonder why rtl8169_poll(), which might be called in a loop under DOS,
> has to call rtl_ack_events() ?
So as to cover a wider temporal range before any event can trigger an
extra irq. I was more worried about irq cost than about IO cost (and
I still am).
--
Ueimor
^ permalink raw reply
* [PATCH] net: ethernet: lpc_eth: remove CONFIG_OF guard from the driver
From: Vladimir Zapolskiy @ 2018-10-18 22:58 UTC (permalink / raw)
To: David S. Miller; +Cc: Sylvain Lemieux, netdev
The MAC controller device is available on NXP LPC32xx platform only,
and the LPC32xx platform supports OF builds only, so additional
checks in the device driver are not needed.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/net/ethernet/nxp/lpc_eth.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index ed02e8e18f25..922b5b5b5c01 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -1518,13 +1518,11 @@ static int lpc_eth_drv_resume(struct platform_device *pdev)
}
#endif
-#ifdef CONFIG_OF
static const struct of_device_id lpc_eth_match[] = {
{ .compatible = "nxp,lpc-eth" },
{ }
};
MODULE_DEVICE_TABLE(of, lpc_eth_match);
-#endif
static struct platform_driver lpc_eth_driver = {
.probe = lpc_eth_drv_probe,
@@ -1535,7 +1533,7 @@ static struct platform_driver lpc_eth_driver = {
#endif
.driver = {
.name = MODNAME,
- .of_match_table = of_match_ptr(lpc_eth_match),
+ .of_match_table = lpc_eth_match,
},
};
--
2.17.1
^ permalink raw reply related
* [PATCH] net: ethernet: lpc_eth: clean up the list of included headers
From: Vladimir Zapolskiy @ 2018-10-18 22:53 UTC (permalink / raw)
To: David S. Miller; +Cc: Sylvain Lemieux, netdev
The change removes all unnecessary included headers from the driver
source code, the remaining list is sorted in alphabetical order.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/net/ethernet/nxp/lpc_eth.c | 28 ++++++----------------------
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 08381ef8bdb4..ed02e8e18f25 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -19,34 +19,18 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/sched.h>
-#include <linux/slab.h>
-#include <linux/delay.h>
-#include <linux/interrupt.h>
-#include <linux/errno.h>
-#include <linux/ioport.h>
-#include <linux/crc32.h>
-#include <linux/platform_device.h>
-#include <linux/spinlock.h>
-#include <linux/ethtool.h>
-#include <linux/mii.h>
#include <linux/clk.h>
-#include <linux/workqueue.h>
-#include <linux/netdevice.h>
+#include <linux/crc32.h>
#include <linux/etherdevice.h>
-#include <linux/skbuff.h>
-#include <linux/phy.h>
-#include <linux/dma-mapping.h>
-#include <linux/of.h>
+#include <linux/module.h>
#include <linux/of_net.h>
-#include <linux/types.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
-#include <linux/io.h>
#include <mach/board.h>
-#include <mach/platform.h>
#include <mach/hardware.h>
+#include <mach/platform.h>
#define MODNAME "lpc-eth"
#define DRV_VERSION "1.00"
--
2.17.1
^ permalink raw reply related
* Re: [net-next 00/13][pull request] Intel Wired LAN Doc Updates 2018-10-18
From: David Miller @ 2018-10-18 22:46 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20181018203259.4175-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 18 Oct 2018 13:32:46 -0700
> This series contains documentation fixes and updates for Intel wired LAN
> drivers.
>
> The following was done:
> - Updated incorrect URLs
> - removed document references which did not apply to the current
> in-kernel drivers
> - added documentation for fm10k driver
> - added missing documentation on existing or new features
> - added SPDX headers to all the documentation files
>
> Lastly, the documentation was converted over to the RST (reStructured
> Text) format, so that 'make htmldocs' produces pretty html driver
> documentation for our drivers.
>
> The following are changes since commit 3a3295bfa6f484bba91de0a804c1d0bf7d31dbd3:
> Merge branch 'sctp-fix-sk_wmem_queued-and-use-it-to-check-for-writable-space'
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE
Pulled, thanks Jeff.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox