* Re: [PATCH] allow DSCP values in ip rulesB
From: David Miller @ 2018-11-17 4:29 UTC (permalink / raw)
To: mail; +Cc: netdev
In-Reply-To: <20181114143037.GA4650@rnd.infotecs.ru>
From: Pavel Balaev <mail@void.so>
Date: Wed, 14 Nov 2018 17:30:37 +0300
> Hello, for now IP rules supports only old TOS values and we cannot use
> DSCP.
>
> This patch adds support for DSCP values in IP rules:
>
> $ ip r add default via 192.168.0.6 table test
> $ ip ru add tos 0x80 table test
> $ ip ru
> 0: from all lookup local
> 32764: from all tos CS4 lookup test
> 32766: from all lookup main
> 32767: from all lookup default
> $ ip r get fibmatch 8.8.8.9 tos 0x80
> default tos CS4 via 192.168.0.6 dev lan table test
>
> Signed-off-by: Pavel Balaev <mail@void.so>
Please repost this with all of your follow-up comments added to
the commit message.
And provide a proper subsystem prefix in your Subject line, such
as "ipv4: ".
^ permalink raw reply
* Re: [PATCH 0/2] pull request for net: batman-adv 2018-11-14
From: David Miller @ 2018-11-17 4:27 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20181114134618.17557-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Wed, 14 Nov 2018 14:46:16 +0100
> here are some bugfixes which we would like to see integrated into net.
>
> Please pull or let me know of any problem!
Pulled, thanks Simon.
^ permalink raw reply
* Re: SMSC95xx driver updates (round 1)
From: David Miller @ 2018-11-17 4:16 UTC (permalink / raw)
To: ben.dooks
Cc: netdev, oneukum, linux-usb, linux-kernel, steve.glendinning,
linux-kernel
In-Reply-To: <20181114115022.9584-1-ben.dooks@codethink.co.uk>
From: Ben Dooks <ben.dooks@codethink.co.uk>
Date: Wed, 14 Nov 2018 11:50:18 +0000
> This is a series of a few driver cleanups and some fixups of the code
> for the SMSC95XX driver. There have been a few reviews, and the issues
> have been fixed so this should be ready for merging.
>
> I will work on the tx-alignment and the other bits of usbnet changes
> and produce at least two more patch series for this later.
Series applied with the missing space in the comment of patch #4 fixed.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/3] dpaa2-eth: add bql support
From: David Miller @ 2018-11-17 4:13 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei
In-Reply-To: <1542196109-1127-1-git-send-email-ruxandra.radulescu@nxp.com>
From: Ioana Ciocoi Radulescu <ruxandra.radulescu@nxp.com>
Date: Wed, 14 Nov 2018 11:48:34 +0000
> The first two patches make minor tweaks to the driver to
> simplify bql implementation. The third patch adds the actual
> bql support.
Series applied, thanks!
^ permalink raw reply
* Re: [PATCH net] net/sched: act_pedit: fix memory leak when IDR allocation fails
From: David Miller @ 2018-11-17 3:54 UTC (permalink / raw)
To: dcaratti; +Cc: jiri, vladbu, netdev
In-Reply-To: <8ae2ff111546be071b461a0678939078353dff27.1542193853.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 14 Nov 2018 12:17:25 +0100
> tcf_idr_check_alloc() can return a negative value, on allocation failures
> (-ENOMEM) or IDR exhaustion (-ENOSPC): don't leak keys_ex in these cases.
>
> Fixes: 0190c1d452a9 ("net: sched: atomically check-allocate action")
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/6] Remove VLAN.CFI overload
From: Alexei Starovoitov @ 2018-11-17 3:51 UTC (permalink / raw)
To: David S. Miller
Cc: Michał Mirosław, Network Development,
Alexei Starovoitov, Benjamin Herrenschmidt, Daniel Borkmann,
jhogan, linux-mips, linuxppc-dev, Michael Ellerman, paul.burton,
Paul Mackerras, Ralf Baechle, sparclinux
In-Reply-To: <20181110.134758.693752342395888727.davem@davemloft.net>
On Sat, Nov 10, 2018 at 1:48 PM David Miller <davem@davemloft.net> wrote:
>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Date: Sat, 10 Nov 2018 19:58:29 +0100
>
> > Fix BPF code/JITs to allow for separate VLAN_PRESENT flag
> > storage and finally move the flag to separate storage in skbuff.
> >
> > This is final step to make CLAN.CFI transparent to core Linux
> > networking stack.
> >
> > An #ifdef is introduced temporarily to mark fragments masking
> > VLAN_TAG_PRESENT. This is removed altogether in the final patch.
>
> Daniel and Alexei, please review.
It was on my todo list.
All reviews got delayed due to LPC.
I guess too late to comment now.
Anyhow I don't see the value in this patch set.
Seems like code churn.
Michal, could you please explain the reasoning?
^ permalink raw reply
* Re: [patch net-next] net: 8021q: move vlan offload registrations into vlan_core
From: David Miller @ 2018-11-17 3:51 UTC (permalink / raw)
To: jiri
Cc: netdev, michaelsh86, ktkhai, sbrivio, sd, xiyou.wangcong,
dcaratti, dsahern, weiyongjun1, ivan.khoronzhuk,
grygorii.strashko, tariqt, makita.toshiaki, mirq-linux, mlxsw
In-Reply-To: <20181113222248.2773-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 13 Nov 2018 23:22:48 +0100
> From: Jiri Pirko <jiri@mellanox.com>
>
> Currently, the vlan packet offloads are registered only upon 8021q module
> load. However, even without this module loaded, the offloads could be
> utilized, for example by openvswitch datapath. As reported by Michael,
> that causes 2x to 5x performance improvement, depending on a testcase.
>
> So move the vlan offload registrations into vlan_core and make this
> available even without 8021q module loaded.
>
> Reported-by: Michael Shteinbok <michaelsh86@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> Tested-by: Michael Shteinbok <michaelsh86@gmail.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH v3] net: Add trace events for all receive exit points
From: David Miller @ 2018-11-17 3:50 UTC (permalink / raw)
To: gbastien; +Cc: netdev, mathieu.desnoyers, rostedt, mingo
In-Reply-To: <20181113201326.5627-1-gbastien@versatic.net>
From: Geneviève Bastien <gbastien@versatic.net>
Date: Tue, 13 Nov 2018 15:13:26 -0500
> @@ -5222,9 +5228,14 @@ static void netif_receive_skb_list_internal(struct list_head *head)
> */
> int netif_receive_skb(struct sk_buff *skb)
> {
> + int ret;
> +
> trace_netif_receive_skb_entry(skb);
>
> - return netif_receive_skb_internal(skb);
> + ret = netif_receive_skb_internal(skb);
> + trace_netif_receive_skb_exit(skb, ret);
Every time I read this code from now on I'm going to say to myself
"oh crap, we reference 'skb' after it's potentially freed up"
I really don't like this.
I know only the pointer is used, but that pointer can be reallocated
to another SLAB object, even another SKB, by the time these exit
tracepoints execute.
Sorry, I can't really convince myself to apply this now.
^ permalink raw reply
* Re: [PATCH net] ipv6: fix a dst leak when removing its exception
From: David Miller @ 2018-11-17 3:45 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, dsa
In-Reply-To: <b031b44110fcb06d780ed60ecadfa4e8bc39acfb.1542127708.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 14 Nov 2018 00:48:28 +0800
> These is no need to hold dst before calling rt6_remove_exception_rt().
> The call to dst_hold_safe() in ip6_link_failure() was for ip6_del_rt(),
> which has been removed in Commit 93531c674315 ("net/ipv6: separate
> handling of FIB entries from dst based routes"). Otherwise, it will
> cause a dst leak.
>
> This patch is to simply remove the dst_hold_safe() call before calling
> rt6_remove_exception_rt() and also do the same in ip6_del_cached_rt().
> It's safe, because the removal of the exception that holds its dst's
> refcnt is protected by rt6_exception_lock.
>
> Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
> Fixes: 23fb93a4d3f1 ("net/ipv6: Cleanup exception and cache route handling")
> Reported-by: Li Shuang <shuali@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [Patch net-next] net: remove unused skb_send_sock()
From: David Miller @ 2018-11-17 3:32 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev
In-Reply-To: <20181113020524.1569-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 12 Nov 2018 18:05:24 -0800
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/6] Remove VLAN.CFI overload
From: David Miller @ 2018-11-17 3:26 UTC (permalink / raw)
To: mirq-linux
Cc: netdev, ast, benh, daniel, jhogan, linux-mips, linuxppc-dev, mpe,
paul.burton, paulus, ralf, sparclinux
In-Reply-To: <cover.1541876179.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sat, 10 Nov 2018 19:58:29 +0100
> Fix BPF code/JITs to allow for separate VLAN_PRESENT flag
> storage and finally move the flag to separate storage in skbuff.
>
> This is final step to make CLAN.CFI transparent to core Linux
> networking stack.
>
> An #ifdef is introduced temporarily to mark fragments masking
> VLAN_TAG_PRESENT. This is removed altogether in the final patch.
Series applied, thank you.
^ permalink raw reply
* [PATCH net-next 1/2] net: bcmgenet: code movement
From: Doug Berger @ 2018-11-17 2:00 UTC (permalink / raw)
To: David S. Miller
Cc: Florian Fainelli, netdev, linux-kernel, YueHaibing, Doug Berger
In-Reply-To: <1542420022-30251-1-git-send-email-opendmb@gmail.com>
This commit switches the order of bcmgenet_suspend and bcmgenet_resume
in the file to prevent the need for a forward declaration in the next
commit and to make the review of that commit easier.
Signed-off-by: Doug Berger <opendmb@gmail.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 60 +++++++++++++-------------
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index bf88749505a9..01c8499fd87f 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -3612,36 +3612,6 @@ static int bcmgenet_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_SLEEP
-static int bcmgenet_suspend(struct device *d)
-{
- struct net_device *dev = dev_get_drvdata(d);
- struct bcmgenet_priv *priv = netdev_priv(dev);
- int ret = 0;
-
- if (!netif_running(dev))
- return 0;
-
- netif_device_detach(dev);
-
- bcmgenet_netif_stop(dev);
-
- if (!device_may_wakeup(d))
- phy_suspend(dev->phydev);
-
- /* Prepare the device for Wake-on-LAN and switch to the slow clock */
- if (device_may_wakeup(d) && priv->wolopts) {
- ret = bcmgenet_power_down(priv, GENET_POWER_WOL_MAGIC);
- clk_prepare_enable(priv->clk_wol);
- } else if (priv->internal_phy) {
- ret = bcmgenet_power_down(priv, GENET_POWER_PASSIVE);
- }
-
- /* Turn off the clocks */
- clk_disable_unprepare(priv->clk);
-
- return ret;
-}
-
static int bcmgenet_resume(struct device *d)
{
struct net_device *dev = dev_get_drvdata(d);
@@ -3719,6 +3689,36 @@ static int bcmgenet_resume(struct device *d)
clk_disable_unprepare(priv->clk);
return ret;
}
+
+static int bcmgenet_suspend(struct device *d)
+{
+ struct net_device *dev = dev_get_drvdata(d);
+ struct bcmgenet_priv *priv = netdev_priv(dev);
+ int ret = 0;
+
+ if (!netif_running(dev))
+ return 0;
+
+ netif_device_detach(dev);
+
+ bcmgenet_netif_stop(dev);
+
+ if (!device_may_wakeup(d))
+ phy_suspend(dev->phydev);
+
+ /* Prepare the device for Wake-on-LAN and switch to the slow clock */
+ if (device_may_wakeup(d) && priv->wolopts) {
+ ret = bcmgenet_power_down(priv, GENET_POWER_WOL_MAGIC);
+ clk_prepare_enable(priv->clk_wol);
+ } else if (priv->internal_phy) {
+ ret = bcmgenet_power_down(priv, GENET_POWER_PASSIVE);
+ }
+
+ /* Turn off the clocks */
+ clk_disable_unprepare(priv->clk);
+
+ return ret;
+}
#endif /* CONFIG_PM_SLEEP */
static SIMPLE_DEV_PM_OPS(bcmgenet_pm_ops, bcmgenet_suspend, bcmgenet_resume);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/2] net: bcmgenet: fix aborted suspend
From: Doug Berger @ 2018-11-17 2:00 UTC (permalink / raw)
To: David S. Miller
Cc: Florian Fainelli, netdev, linux-kernel, YueHaibing, Doug Berger
It is not enough to return an error code from the driver suspend
routine. The driver must also restore the device functionality.
This commit corrects the issue introduced by commit 0db55093b566
("net: bcmgenet: return correct value 'ret' from bcmgenet_power_down")
by calling the driver resume function if the suspend function returns
an error.
Doug Berger (2):
net: bcmgenet: code movement
net: bcmgenet: abort suspend on error
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 63 +++++++++++-----------
drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c | 6 +++
2 files changed, 39 insertions(+), 30 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/3] bpf: Support socket lookup in CGROUP_SOCK_ADDR progs
From: Alexei Starovoitov @ 2018-11-17 1:59 UTC (permalink / raw)
To: Andrey Ignatov
Cc: Network Development, Alexei Starovoitov, Daniel Borkmann,
Joe Stringer, Martin KaFai Lau, Kernel Team
In-Reply-To: <cover.1541789512.git.rdna@fb.com>
On Fri, Nov 9, 2018 at 6:54 PM Andrey Ignatov <rdna@fb.com> wrote:
>
> This patch set makes bpf_sk_lookup_tcp, bpf_sk_lookup_udp and
> bpf_sk_release helpers available in programs of type
> BPF_PROG_TYPE_CGROUP_SOCK_ADDR.
>
> Patch 1 is a fix for bpf_sk_lookup_udp that was already merged to bpf
> (stable) tree. Here it's prerequisite for patch 3.
>
> Patch 2 is the main patch in the set, it makes the helpers available for
> BPF_PROG_TYPE_CGROUP_SOCK_ADDR and provides more details about use-case.
>
> Patch 3 adds selftest for new functionality.
>
> v1->v2:
> - remove "Split bpf_sk_lookup" patch since it was already split by:
> commit c8123ead13a5 ("bpf: Extend the sk_lookup() helper to XDP
> hookpoint.");
> - avoid unnecessary bpf_sock_addr_sk_lookup function.
applied, thanks
^ permalink raw reply
* KASAN: use-after-free Read in sctp_epaddr_lookup_transport
From: syzbot @ 2018-11-17 1:59 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev, nhorman,
syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: a97b95653383 drivers/net/ethernet/qlogic/qed/qed_rdma.h: f..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1217d26d400000
kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
dashboard link: https://syzkaller.appspot.com/bug?extid=aad231d51b1923158444
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b5bb0b400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+aad231d51b1923158444@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in sctp_epaddr_lookup_transport+0xacb/0xb20
net/sctp/input.c:971
Read of size 8 at addr ffff8881cde426b0 by task syz-executor3/18110
CPU: 1 PID: 18110 Comm: syz-executor3 Not tainted 4.20.0-rc2+ #187
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x39d lib/dump_stack.c:113
print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
sctp_epaddr_lookup_transport+0xacb/0xb20 net/sctp/input.c:971
sctp_endpoint_lookup_assoc+0xe0/0x290 net/sctp/endpointola.c:338
sctp_addr_id2transport+0x1f8/0x370 net/sctp/socket.c:279
sctp_getsockopt_peer_addr_params+0x17c/0x1260 net/sctp/socket.c:5613
sctp_getsockopt+0x44f9/0x7d32 net/sctp/socket.c:7462
sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:2937
__sys_getsockopt+0x1ad/0x390 net/socket.c:1939
__do_sys_getsockopt net/socket.c:1950 [inline]
__se_sys_getsockopt net/socket.c:1947 [inline]
__x64_sys_getsockopt+0xbe/0x150 net/socket.c:1947
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f177b561c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457569
RDX: 0000000000000009 RSI: 0000000000000084 RDI: 0000000000000006
RBP: 000000000072c180 R08: 000000002044fffc R09: 0000000000000000
R10: 0000000020a68000 R11: 0000000000000246 R12: 00007f177b5626d4
R13: 00000000004c8318 R14: 00000000004ce200 R15: 00000000ffffffff
Allocated by task 18068:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
kmalloc include/linux/slab.h:546 [inline]
kzalloc include/linux/slab.h:741 [inline]
sctp_association_new+0x14e/0x2290 net/sctp/associola.c:311
sctp_sendmsg_new_asoc+0x39c/0x11f0 net/sctp/socket.c:1723
sctp_sendmsg+0x18a5/0x1da0 net/sctp/socket.c:2086
inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
__sys_sendto+0x3d7/0x670 net/socket.c:1788
__do_sys_sendto net/socket.c:1800 [inline]
__se_sys_sendto net/socket.c:1796 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 18110:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3817
sctp_association_destroy net/sctp/associola.c:437 [inline]
sctp_association_put+0x264/0x350 net/sctp/associola.c:889
sctp_transport_destroy net/sctp/transport.c:180 [inline]
sctp_transport_put+0x186/0x1f0 net/sctp/transport.c:340
sctp_hash_cmp+0x1ef/0x260 net/sctp/input.c:825
__rhashtable_lookup include/linux/rhashtable.h:483 [inline]
rhltable_lookup include/linux/rhashtable.h:566 [inline]
sctp_epaddr_lookup_transport+0x4fe/0xb20 net/sctp/input.c:967
sctp_endpoint_lookup_assoc+0xe0/0x290 net/sctp/endpointola.c:338
sctp_addr_id2transport+0x1f8/0x370 net/sctp/socket.c:279
sctp_getsockopt_peer_addr_params+0x17c/0x1260 net/sctp/socket.c:5613
sctp_getsockopt+0x44f9/0x7d32 net/sctp/socket.c:7462
sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:2937
__sys_getsockopt+0x1ad/0x390 net/socket.c:1939
__do_sys_getsockopt net/socket.c:1950 [inline]
__se_sys_getsockopt net/socket.c:1947 [inline]
__x64_sys_getsockopt+0xbe/0x150 net/socket.c:1947
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881cde42600
which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 176 bytes inside of
4096-byte region [ffff8881cde42600, ffff8881cde43600)
The buggy address belongs to the page:
page:ffffea0007379080 count:1 mapcount:0 mapping:ffff8881da800dc0 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000010200(slab|head)
raw: 02fffc0000010200 ffffea0007379008 ffffea0007377f08 ffff8881da800dc0
raw: 0000000000000000 ffff8881cde42600 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881cde42580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881cde42600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8881cde42680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881cde42700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881cde42780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
kobject: 'loop5' (00000000f0e4ffac): fill_kobj_path: path
= '/devices/virtual/block/loop5'
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: libbpf: Fix bpf_program__next() API
From: Alexei Starovoitov @ 2018-11-17 1:50 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Alexei Starovoitov, Daniel Borkmann, kernel-team,
Stanislav Fomichev, Stanislav Fomichev
In-Reply-To: <20181112234453.2126896-1-kafai@fb.com>
On Mon, Nov 12, 2018 at 03:44:53PM -0800, Martin KaFai Lau wrote:
> This patch restores the behavior in
> commit eac7d84519a3 ("tools: libbpf: don't return '.text' as a program for multi-function programs")
> such that bpf_program__next() does not return pseudo programs in ".text".
>
> Fixes: 0c19a9fbc9cd ("libbpf: cleanup after partial failure in bpf_object__pin")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Applied, Thanks
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: Fix uninitialized duration warning
From: Alexei Starovoitov @ 2018-11-17 1:44 UTC (permalink / raw)
To: Joe Stringer; +Cc: Daniel Borkmann, Network Development
In-Reply-To: <20181109181816.22622-1-joe@wand.net.nz>
On Fri, Nov 9, 2018 at 6:20 PM Joe Stringer <joe@wand.net.nz> wrote:
>
> Daniel Borkmann reports:
>
> test_progs.c: In function ‘main’:
> test_progs.c:81:3: warning: ‘duration’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> printf("%s:PASS:%s %d nsec\n", __func__, tag, duration);\
> ^~~~~~
> test_progs.c:1706:8: note: ‘duration’ was declared here
> __u32 duration;
> ^~~~~~~~
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] geneve: Use empty braces for addr6 initializer
From: Stefano Brivio @ 2018-11-17 11:31 UTC (permalink / raw)
To: Joe Perches, Nathan Chancellor, David S. Miller
Cc: Sabrina Dubroca, netdev, linux-kernel
In-Reply-To: <138f1c15387c47fe65f4a0448f35afdd9db81933.camel@perches.com>
On Fri, 16 Nov 2018 18:33:40 -0800
Joe Perches <joe@perches.com> wrote:
> If this is really an issue, I don't know why the other uses
> haven't been reported.
It causes warnings with some older gcc versions and clang, I don't see
it as an issue, but others might.
> Perhaps change the rest of them too?
But then look, we already have a delicious strict C89 initialiser in
include/linux/in6.h, and we can do this:
drivers/net/geneve.c | 4 ++--
include/net/ip6_fib.h | 9 +++------
include/trace/events/fib6.h | 4 +---
net/6lowpan/iphc.c | 12 ++++++------
4 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 7c53e06b31c3..96588adc294c 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -191,7 +191,7 @@ static struct geneve_dev *geneve_lookup_skb(struct geneve_sock *gs,
return geneve_lookup(gs, addr, vni);
#if IS_ENABLED(CONFIG_IPV6)
} else if (geneve_get_sk_family(gs) == AF_INET6) {
- static struct in6_addr zero_addr6;
+ struct in6_addr zero_addr6 = IN6ADDR_ANY_INIT;
struct ipv6hdr *ip6h;
struct in6_addr addr6;
@@ -424,8 +424,8 @@ static int geneve_udp_encap_err_lookup(struct sock *sk, struct sk_buff *skb)
#if IS_ENABLED(CONFIG_IPV6)
if (geneve_get_sk_family(gs) == AF_INET6) {
+ struct in6_addr addr6 = IN6ADDR_ANY_INIT;
struct ipv6hdr *ip6h = ipv6_hdr(skb);
- struct in6_addr addr6 = { 0 };
if (!gs->collect_md) {
vni = geneve_hdr(skb)->vni;
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 84097010237c..24543caf5a9f 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -427,13 +427,10 @@ void rt6_get_prefsrc(const struct rt6_info *rt, struct in6_addr *addr)
rcu_read_lock();
from = rcu_dereference(rt->from);
- if (from) {
+ if (from)
*addr = from->fib6_prefsrc.addr;
- } else {
- struct in6_addr in6_zero = {};
-
- *addr = in6_zero;
- }
+ else
+ *addr = in6addr_any;
rcu_read_unlock();
}
diff --git a/include/trace/events/fib6.h b/include/trace/events/fib6.h
index b088b54d699c..6496ca1594ac 100644
--- a/include/trace/events/fib6.h
+++ b/include/trace/events/fib6.h
@@ -68,10 +68,8 @@ TRACE_EVENT(fib6_table_lookup,
__assign_str(name, "-");
}
if (f6i == net->ipv6.fib6_null_entry) {
- struct in6_addr in6_zero = {};
-
in6 = (struct in6_addr *)__entry->gw;
- *in6 = in6_zero;
+ *in6 = in6addr_any;
} else if (f6i) {
in6 = (struct in6_addr *)__entry->gw;
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index 52fad5dad9f7..f0e0bac91e71 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -246,8 +246,8 @@ lowpan_iphc_ctx_get_by_mcast_addr(const struct net_device *dev,
const struct in6_addr *addr)
{
struct lowpan_iphc_ctx *table = lowpan_dev(dev)->ctx.table;
+ struct in6_addr addr_mcast, network_pfx = IN6ADDR_ANY_INIT;
struct lowpan_iphc_ctx *ret = NULL;
- struct in6_addr addr_mcast, network_pfx = {};
int i;
/* init mcast address with */
@@ -481,7 +481,7 @@ static int lowpan_uncompress_multicast_ctx_daddr(struct sk_buff *skb,
struct in6_addr *ipaddr,
u8 address_mode)
{
- struct in6_addr network_pfx = {};
+ struct in6_addr network_pfx = IN6ADDR_ANY_INIT;
bool fail;
ipaddr->s6_addr[0] = 0xFF;
@@ -794,8 +794,8 @@ lowpan_iphc_compress_ctx_802154_lladdr(const struct in6_addr *ipaddr,
{
const struct ieee802154_addr *addr = lladdr;
unsigned char extended_addr[EUI64_ADDR_LEN];
+ struct in6_addr tmp = IN6ADDR_ANY_INIT;
bool lladdr_compress = false;
- struct in6_addr tmp = {};
switch (addr->mode) {
case IEEE802154_ADDR_LONG:
@@ -833,7 +833,7 @@ static bool lowpan_iphc_addr_equal(const struct net_device *dev,
const struct in6_addr *ipaddr,
const void *lladdr)
{
- struct in6_addr tmp = {};
+ struct in6_addr tmp = IN6ADDR_ANY_INIT;
lowpan_iphc_uncompress_lladdr(dev, &tmp, lladdr);
@@ -848,7 +848,7 @@ static u8 lowpan_compress_ctx_addr(u8 **hc_ptr, const struct net_device *dev,
const struct lowpan_iphc_ctx *ctx,
const unsigned char *lladdr, bool sam)
{
- struct in6_addr tmp = {};
+ struct in6_addr tmp = IN6ADDR_ANY_INIT;
u8 dam;
switch (lowpan_dev(dev)->lltype) {
@@ -907,8 +907,8 @@ lowpan_iphc_compress_802154_lladdr(const struct in6_addr *ipaddr,
{
const struct ieee802154_addr *addr = lladdr;
unsigned char extended_addr[EUI64_ADDR_LEN];
+ struct in6_addr tmp = IN6ADDR_ANY_INIT;
bool lladdr_compress = false;
- struct in6_addr tmp = {};
switch (addr->mode) {
case IEEE802154_ADDR_LONG:
--
Stefano
^ permalink raw reply related
* [PATCH 5/5] Bluetooth: btusb: Use the hw_reset method to allow resetting the BT chip
From: Rajat Jain @ 2018-11-17 1:07 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, Greg Kroah-Hartman,
David S. Miller, Dmitry Torokhov, Rajat Jain, Alex Hung,
linux-bluetooth, linux-kernel, linux-usb, netdev
Cc: rajatxjain, dtor, raghuram.hegde, chethan.tumkur.narayan,
sukumar.ghorai
In-Reply-To: <20181117010748.24347-1-rajatja@google.com>
If the platform provides it, use the reset gpio to reset the BT
chip (requested by the HCI core if needed). This has been found helpful
on some of Intel bluetooth controllers where the firmware gets stuck and
the only way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain <rajatja@google.com>
---
drivers/bluetooth/btusb.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index e8e148480c91..8aad02d9e211 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -29,6 +29,7 @@
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/suspend.h>
+#include <linux/gpio/consumer.h>
#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
@@ -475,6 +476,8 @@ struct btusb_data {
struct usb_endpoint_descriptor *diag_tx_ep;
struct usb_endpoint_descriptor *diag_rx_ep;
+ struct gpio_desc *reset_gpio;
+
__u8 cmdreq_type;
__u8 cmdreq;
@@ -490,6 +493,28 @@ struct btusb_data {
int oob_wake_irq; /* irq for out-of-band wake-on-bt */
};
+
+static void btusb_hw_reset(struct hci_dev *hdev)
+{
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct gpio_desc *reset_gpio = data->reset_gpio;
+
+ /*
+ * Toggle the hard reset line if the platform provides one. The reset
+ * is going to yank the device off the USB and then replug. So doing
+ * once is enough. The cleanup is handled correctly on the way out
+ * (standard USB disconnect), and the new device is detected cleanly
+ * and bound to the driver again like it should be.
+ */
+ if (reset_gpio) {
+ bt_dev_dbg(hdev, "%s: Initiating HW reset via gpio", __func__);
+ clear_bit(HCI_QUIRK_HW_RESET_ON_TIMEOUT, &hdev->quirks);
+ gpiod_set_value(reset_gpio, 1);
+ mdelay(100);
+ gpiod_set_value(reset_gpio, 0);
+ }
+}
+
static inline void btusb_free_frags(struct btusb_data *data)
{
unsigned long flags;
@@ -3030,6 +3055,11 @@ static int btusb_probe(struct usb_interface *intf,
SET_HCIDEV_DEV(hdev, &intf->dev);
+ data->reset_gpio = gpiod_get_optional(&data->udev->dev, "reset",
+ GPIOD_OUT_LOW);
+ if (data->reset_gpio)
+ hdev->hw_reset = btusb_hw_reset;
+
hdev->open = btusb_open;
hdev->close = btusb_close;
hdev->flush = btusb_flush;
@@ -3085,6 +3115,7 @@ static int btusb_probe(struct usb_interface *intf,
set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks);
set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
set_bit(HCI_QUIRK_NON_PERSISTENT_DIAG, &hdev->quirks);
+ set_bit(HCI_QUIRK_HW_RESET_ON_TIMEOUT, &hdev->quirks);
if (id->driver_info & BTUSB_INTEL) {
hdev->setup = btusb_setup_intel;
@@ -3225,6 +3256,8 @@ static int btusb_probe(struct usb_interface *intf,
return 0;
out_free_dev:
+ if (data->reset_gpio)
+ gpiod_put(data->reset_gpio);
hci_free_dev(hdev);
return err;
}
@@ -3268,6 +3301,9 @@ static void btusb_disconnect(struct usb_interface *intf)
if (data->oob_wake_irq)
device_init_wakeup(&data->udev->dev, false);
+ if (data->reset_gpio)
+ gpiod_put(data->reset_gpio);
+
hci_free_dev(hdev);
}
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* Re: [v3, PATCH 1/2] net:stmmac: dwmac-mediatek: add support for mt2712
From: Sean Wang @ 2018-11-17 1:03 UTC (permalink / raw)
To: biao.huang
Cc: davem, robh+dt, mark.rutland, devicetree, nelson.chang, andrew,
netdev, liguo.zhang, linux-kernel, Matthias Brugger, joabreu,
linux-mediatek, honghui.zhang, linux-arm-kernel
In-Reply-To: <1542359926-28800-1-git-send-email-biao.huang@mediatek.com>
wi
On Fri, Nov 16, 2018 at 1:19 AM Biao Huang <biao.huang@mediatek.com> wrote:
>
> Add Ethernet support for MediaTek SoCs from the mt2712 family
>
> Change-Id: Id3c535627088227793bd36405994edf2dc765e6a
Drop change-Id
> Signed-off-by: Biao Huang <biao.huang@mediatek.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 8 +
> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
> .../net/ethernet/stmicro/stmmac/dwmac-mediatek.c | 383 ++++++++++++++++++++
> 3 files changed, 392 insertions(+)
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index edf2036..28a7a28 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -75,6 +75,14 @@ config DWMAC_LPC18XX
> ---help---
> Support for NXP LPC18xx/43xx DWMAC Ethernet.
>
> +config DWMAC_MEDIATEK
> + tristate "MediaTek MT27xx GMAC support"
> + depends on OF && (ARCH_MEDIATEK || COMPILE_TEST)
> + help
> + Support for MediaTek GMAC Ethernet controller.
> +
> + This selects the MT2712 SoC support for the stmmac driver.
> +
> config DWMAC_MESON
> tristate "Amlogic Meson dwmac support"
> default ARCH_MESON
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index 99967a8..bf09701 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
> obj-$(CONFIG_DWMAC_ANARION) += dwmac-anarion.o
> obj-$(CONFIG_DWMAC_IPQ806X) += dwmac-ipq806x.o
> obj-$(CONFIG_DWMAC_LPC18XX) += dwmac-lpc18xx.o
> +obj-$(CONFIG_DWMAC_MEDIATEK) += dwmac-mediatek.o
> obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
> obj-$(CONFIG_DWMAC_OXNAS) += dwmac-oxnas.o
> obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> new file mode 100644
> index 0000000..a80b3e0
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + */
> +#include <linux/io.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_net.h>
> +#include <linux/regmap.h>
> +#include <linux/stmmac.h>
> +
> +#include "stmmac.h"
> +#include "stmmac_platform.h"
> +
> +/* Peri Configuration register */
> +#define PERI_ETH_PHY_INTF_SEL 0x418
> +#define PHY_INTF_MII_GMII 0
> +#define PHY_INTF_RGMII 1
> +#define PHY_INTF_RMII 4
> +#define RMII_CLK_SRC_RXC BIT(4)
> +#define RMII_CLK_SRC_INTERNAL BIT(5)
> +
> +#define PERI_ETH_PHY_DLY 0x428
> +#define PHY_DLY_GTXC_INV BIT(6)
> +#define PHY_DLY_GTXC_ENABLE BIT(5)
> +#define PHY_DLY_GTXC_STAGES GENMASK(4, 0)
> +#define PHY_DLY_TXC_INV BIT(20)
> +#define PHY_DLY_TXC_ENABLE BIT(19)
> +#define PHY_DLY_TXC_STAGES GENMASK(18, 14)
> +#define PHY_DLY_TXC_SHIFT 14
> +#define PHY_DLY_RXC_INV BIT(13)
> +#define PHY_DLY_RXC_ENABLE BIT(12)
> +#define PHY_DLY_RXC_STAGES GENMASK(11, 7)
> +#define PHY_DLY_RXC_SHIFT 7
> +
> +#define PERI_ETH_DLY_FINE 0x800
> +#define ETH_RMII_DLY_TX_INV BIT(2)
> +#define ETH_FINE_DLY_GTXC BIT(1)
> +#define ETH_FINE_DLY_RXC BIT(0)
> +
> +enum dwmac_clks_map {
> + DWMAC_CLK_AXI_DRAM,
> + DWMAC_CLK_APB_REG,
> + DWMAC_CLK_MAC_EXT,
> + DWMAC_CLK_MAC_PARENT,
> + DWMAC_CLK_PTP_REF,
> + DWMAC_CLK_PTP_PARENT,
> + DWMAC_CLK_PTP_TOP,
> + DWMAC_CLK_MAX
> +};
> +
> +struct mac_delay_struct {
> + u32 tx_delay;
> + u32 rx_delay;
> + u32 tx_inv;
> + u32 rx_inv;
> +};
> +
> +struct mediatek_dwmac_plat_data {
> + struct device *dev;
> + struct regmap *peri_regmap;
> + struct clk *clks[DWMAC_CLK_MAX];
> + struct device_node *np;
> + int phy_mode;
> + struct mac_delay_struct mac_delay;
> + const struct mediatek_dwmac_variant *variant;
> + int fine_tune;
> + int rmii_rxc;
> +};
> +
> +struct mediatek_dwmac_variant {
> + int (*dwmac_config_dt)(struct mediatek_dwmac_plat_data *plat);
> + int (*dwmac_enable_clks)(struct mediatek_dwmac_plat_data *plat);
> + void (*dwmac_disable_clks)(struct mediatek_dwmac_plat_data *plat);
Each variant usually can reuse the same config_dt, enable/disable_clks function.
> + u32 rx_delay_max;
> + u32 tx_delay_max;
> +};
> +
> +static const char * const mediatek_dwmac_clks_name[] = {
> + "axi", "apb", "mac_ext", "mac_parent", "ptp_ref", "ptp_parent", "ptp_top"
> +};
> +
> +static int mt2712_set_interface(struct mediatek_dwmac_plat_data *plat)
Kconfig indicates it's a mt27xx driver. so it's good if there is a
more generic prefix.
> +{
> + int rmii_rxc = plat->rmii_rxc ? RMII_CLK_SRC_RXC : 0;
> + u32 intf_val = 0;
> +
> + /* select phy interface in top control domain */
> + switch (plat->phy_mode) {
> + case PHY_INTERFACE_MODE_MII:
> + intf_val |= PHY_INTF_MII_GMII;
> + break;
> + case PHY_INTERFACE_MODE_RMII:
> + intf_val |= PHY_INTF_RMII;
> + intf_val |= rmii_rxc;
> + break;
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + intf_val |= PHY_INTF_RGMII;
> + break;
> + default:
> + dev_err(plat->dev, "phy interface not supported\n");
> + return -EINVAL;
> + }
> +
> + regmap_write(plat->peri_regmap, PERI_ETH_PHY_INTF_SEL, intf_val);
> +
> + return 0;
> +}
> +
> +static int mt2712_set_delay(struct mediatek_dwmac_plat_data *plat)
> +{
> + struct mac_delay_struct *mac_delay = &plat->mac_delay;
> + u32 delay_val = 0;
> + u32 fine_val = 0;
> +
> + switch (plat->phy_mode) {
> + case PHY_INTERFACE_MODE_MII:
> + delay_val |= mac_delay->tx_delay ? PHY_DLY_TXC_ENABLE : 0;
> + delay_val |= (mac_delay->tx_delay << PHY_DLY_TXC_SHIFT) &
> + PHY_DLY_TXC_STAGES;
> + delay_val |= mac_delay->tx_inv ? PHY_DLY_TXC_INV : 0;
> + delay_val |= mac_delay->rx_delay ? PHY_DLY_RXC_ENABLE : 0;
> + delay_val |= (mac_delay->rx_delay << PHY_DLY_RXC_SHIFT) &
> + PHY_DLY_RXC_STAGES;
> + delay_val |= mac_delay->rx_inv ? PHY_DLY_RXC_INV : 0;
> + break;
> + case PHY_INTERFACE_MODE_RMII:
> + if (plat->rmii_rxc) {
> + delay_val |= mac_delay->rx_delay ?
> + PHY_DLY_RXC_ENABLE : 0;
> + delay_val |= (mac_delay->rx_delay <<
> + PHY_DLY_RXC_SHIFT) & PHY_DLY_RXC_STAGES;
> + delay_val |= mac_delay->rx_inv ? PHY_DLY_RXC_INV : 0;
> + fine_val |= mac_delay->tx_inv ?
> + ETH_RMII_DLY_TX_INV : 0;
> + } else {
> + delay_val |= mac_delay->rx_delay ?
> + PHY_DLY_TXC_ENABLE : 0;
> + delay_val |= (mac_delay->rx_delay <<
> + PHY_DLY_TXC_SHIFT) & PHY_DLY_TXC_STAGES;
> + delay_val |= mac_delay->rx_inv ? PHY_DLY_TXC_INV : 0;
> + fine_val |= mac_delay->tx_inv ?
> + ETH_RMII_DLY_TX_INV : 0;
> + }
> + break;
> + case PHY_INTERFACE_MODE_RGMII:
> + fine_val = plat->fine_tune ?
> + (ETH_FINE_DLY_GTXC | ETH_FINE_DLY_RXC) : 0;
> + delay_val |= mac_delay->tx_delay ? PHY_DLY_GTXC_ENABLE : 0;
> + delay_val |= mac_delay->tx_delay & PHY_DLY_GTXC_STAGES;
> + delay_val |= mac_delay->tx_inv ? PHY_DLY_GTXC_INV : 0;
> + delay_val |= mac_delay->rx_delay ? PHY_DLY_RXC_ENABLE : 0;
> + delay_val |= (mac_delay->rx_delay << PHY_DLY_RXC_SHIFT) &
> + PHY_DLY_RXC_STAGES;
> + delay_val |= mac_delay->rx_inv ? PHY_DLY_RXC_INV : 0;
> + break;
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + fine_val = plat->fine_tune ? ETH_FINE_DLY_RXC : 0;
> + delay_val |= mac_delay->rx_delay ? PHY_DLY_RXC_ENABLE : 0;
> + delay_val |= (mac_delay->rx_delay << PHY_DLY_RXC_SHIFT) &
> + PHY_DLY_RXC_STAGES;
> + delay_val |= mac_delay->rx_inv ? PHY_DLY_RXC_INV : 0;
> + break;
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + fine_val = plat->fine_tune ? ETH_FINE_DLY_GTXC : 0;
> + delay_val |= mac_delay->tx_delay ? PHY_DLY_GTXC_ENABLE : 0;
> + delay_val |= mac_delay->tx_delay & PHY_DLY_GTXC_STAGES;
> + delay_val |= mac_delay->tx_inv ? PHY_DLY_GTXC_INV : 0;
> + break;
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + break;
> + default:
> + dev_err(plat->dev, "phy interface not supported\n");
> + return -EINVAL;
> + }
> + regmap_write(plat->peri_regmap, PERI_ETH_PHY_DLY, delay_val);
> + regmap_write(plat->peri_regmap, PERI_ETH_DLY_FINE, fine_val);
> +
> + return 0;
> +}
> +
> +static int mt2712_get_clks(struct mediatek_dwmac_plat_data *plat)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(plat->clks); i++) {
> + plat->clks[i] = devm_clk_get(plat->dev,
> + mediatek_dwmac_clks_name[i]);
> + if (IS_ERR(plat->clks[i]))
> + return PTR_ERR(plat->clks[i]);
> + }
can we use devm_clk_bulk_get?
> +
> + return 0;
> +}
> +
> +static int mt2712_enable_clks(struct mediatek_dwmac_plat_data *plat)
> +{
> + int clk, ret;
> +
> + for (clk = 0; clk < DWMAC_CLK_MAX ; clk++) {
> + ret = clk_prepare_enable(plat->clks[clk]);
> + if (ret)
> + goto err_disable_clks;
> + }
can we use clk_bulk_enable?
> +
> + ret = clk_set_parent(plat->clks[DWMAC_CLK_MAC_EXT], plat->clks[DWMAC_CLK_MAC_PARENT]);
> + if (ret)
> + goto err_disable_clks;
> +
> + ret = clk_set_parent(plat->clks[DWMAC_CLK_PTP_REF], plat->clks[DWMAC_CLK_PTP_PARENT]);
> + if (ret)
> + goto err_disable_clks;
> +
I guess clk_set_parent can be trimmed if we involve assigned-clocks,
assigned-clock-parents, assigned-clock-rates in the dts
> + return 0;
> +
> +err_disable_clks:
> + while (--clk >= 0)
> + clk_disable_unprepare(plat->clks[clk]);
> +
clk_bulk_enable would take care about the failed case
> + return ret;
> +}
> +
> +static void mt2712_disable_clks(struct mediatek_dwmac_plat_data *plat)
> +{
> + int clk;
> +
> + for (clk = DWMAC_CLK_MAX - 1; clk >= 0; clk--)
> + clk_disable_unprepare(plat->clks[clk]);
> +}
can we use clk_bulk_disable ?
> +
> +static int mt2712_config_dt(struct mediatek_dwmac_plat_data *plat)
> +{
> + u32 tx_delay, rx_delay;
> +
> + plat->peri_regmap = syscon_regmap_lookup_by_compatible("mediatek,mt2712-pericfg");
the driver would be not generic enough if we assigned a specific
string into here.
how about apply syscon_regmap_lookup_by_phandle in here?
> + if (IS_ERR(plat->peri_regmap)) {
> + dev_err(plat->dev, "Failed to get pericfg syscon\n");
> + return PTR_ERR(plat->peri_regmap);
> + }
> +
> + if (!of_property_read_u32(plat->np, "tx-delay", &tx_delay)) {
> + if (tx_delay < plat->variant->tx_delay_max) {
> + plat->mac_delay.tx_delay = tx_delay;
> + } else {
> + dev_err(plat->dev, "Invalid TX clock delay: %d\n", tx_delay);
> + return -EINVAL;
> + }
> + }
> +
> + if (!of_property_read_u32(plat->np, "rx-delay", &rx_delay)) {
> + if (rx_delay < plat->variant->rx_delay_max) {
> + plat->mac_delay.rx_delay = rx_delay;
> + } else {
> + dev_err(plat->dev, "Invalid RX clock delay: %d\n", rx_delay);
> + return -EINVAL;
> + }
> + }
> +
> + plat->mac_delay.tx_inv = of_property_read_bool(plat->np, "txc-inverse");
> +
can we drop the empty line?
> + plat->mac_delay.rx_inv = of_property_read_bool(plat->np, "rxc-inverse");
> +
can we drop the empty line?
> + plat->fine_tune = of_property_read_bool(plat->np, "fine-tune");
> +
can we drop the empty line?
> + plat->rmii_rxc = of_property_read_bool(plat->np, "rmii-rxc");
> +
> + mt2712_set_interface(plat);
> +
> + mt2712_set_delay(plat);
> +
> + return mt2712_get_clks(plat);
> +}
> +
> +static const struct mediatek_dwmac_variant mt2712_gmac_variant = {
> + .dwmac_config_dt = mt2712_config_dt,
> + .dwmac_enable_clks = mt2712_enable_clks,
> + .dwmac_disable_clks = mt2712_disable_clks,
> + .rx_delay_max = 32,
> + .tx_delay_max = 32,
> +};
I thought we add the variant structure when the SoC variant is really in.
> +
> +static int mediatek_dwmac_config_dt(struct mediatek_dwmac_plat_data *plat)
> +{
> + const struct mediatek_dwmac_variant *variant = plat->variant;
> +
> + /* Set the DMA mask, 4GB mode enabled */
> + dma_set_mask_and_coherent(plat->dev, DMA_BIT_MASK(33));
> +
> + return variant->dwmac_config_dt(plat);
> +}
> +
> +static int mediatek_dwmac_init(struct platform_device *pdev, void *priv)
> +{
> + struct mediatek_dwmac_plat_data *plat = priv;
> + const struct mediatek_dwmac_variant *variant = plat->variant;
> +
> + return variant->dwmac_enable_clks(plat);
> +}
> +
> +static void mediatek_dwmac_exit(struct platform_device *pdev, void *priv)
> +{
> + struct mediatek_dwmac_plat_data *plat = priv;
> + const struct mediatek_dwmac_variant *variant = plat->variant;
> +
> + variant->dwmac_disable_clks(plat);
> +}
> +
> +static int mediatek_dwmac_probe(struct platform_device *pdev)
> +{
> + int ret = 0;
> + struct plat_stmmacenet_data *plat_dat;
> + struct stmmac_resources stmmac_res;
> + struct mediatek_dwmac_plat_data *priv_plat;
sorting these declarations into reverse Xmas tree seems to be good
> +
> + priv_plat = devm_kzalloc(&pdev->dev, sizeof(*priv_plat), GFP_KERNEL);
> + if (!priv_plat)
> + return -ENOMEM;
> +
> + priv_plat->variant = of_device_get_match_data(&pdev->dev);
> + if (!priv_plat->variant) {
> + dev_err(&pdev->dev, "Missing dwmac-mediatek variant\n");
> + return -EINVAL;
> + }
> +
> + priv_plat->dev = &pdev->dev;
> + priv_plat->np = pdev->dev.of_node;
> + priv_plat->phy_mode = of_get_phy_mode(priv_plat->np);
> +
> + ret = mediatek_dwmac_config_dt(priv_plat);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> + if (ret)
> + return ret;
> +
> + plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> + if (IS_ERR(plat_dat))
> + return PTR_ERR(plat_dat);
> +
> + plat_dat->interface = priv_plat->phy_mode;
> + /* clk_csr_i = 250-300MHz & MDC = clk_csr_i/124 */
> + plat_dat->clk_csr = 5;
> + plat_dat->has_gmac4 = 1;
> + plat_dat->has_gmac = 0;
> + plat_dat->pmt = 0;
> + plat_dat->maxmtu = ETH_DATA_LEN;
> + plat_dat->bsp_priv = priv_plat;
> + plat_dat->init = mediatek_dwmac_init;
> + plat_dat->exit = mediatek_dwmac_exit;
> + mediatek_dwmac_init(pdev, priv_plat);
> +
> + ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
> + if (ret) {
> + stmmac_remove_config_dt(pdev, plat_dat);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mediatek_dwmac_match[] = {
> + { .compatible = "mediatek,mt2712-gmac",
> + .data = &mt2712_gmac_variant },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(of, mediatek_dwmac_match);
> +
> +static struct platform_driver mediatek_dwmac_driver = {
> + .probe = mediatek_dwmac_probe,
> + .remove = stmmac_pltfr_remove,
> + .driver = {
> + .name = "dwmac-mediatek",
> + .pm = &stmmac_pltfr_pm_ops,
> + .of_match_table = mediatek_dwmac_match,
> + },
> +};
> +module_platform_driver(mediatek_dwmac_driver);
> --
> 1.7.9.5
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [next-queue PATCH v1 2/2] Documentation: igb: Add a section about CBS
From: Vinicius Costa Gomes @ 2018-11-17 0:19 UTC (permalink / raw)
To: intel-wired-lan
Cc: Vinicius Costa Gomes, jeffrey.t.kirsher, netdev, jesus.s.palencia
In-Reply-To: <20181117001924.1525-1-vinicius.gomes@intel.com>
Add some pointers to the definition of the CBS algorithm, and some
notes about the limits of its implementation in the i210 family of
controllers.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
---
Documentation/networking/igb.rst | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/networking/igb.rst b/Documentation/networking/igb.rst
index ba16b86d5593..e87a4a72ea2d 100644
--- a/Documentation/networking/igb.rst
+++ b/Documentation/networking/igb.rst
@@ -177,6 +177,25 @@ rate limit using the IProute2 tool. Download the latest version of the
IProute2 tool from Sourceforge if your version does not have all the features
you require.
+Credit Based Shaper (Qav Mode)
+------------------------------
+When enabling the CBS qdisc in the hardware offload mode, traffic shaping using
+the CBS (described in the IEEE 802.1Q-2018 Section 8.6.8.2 and discussed in the
+Annex L) algorithm will run in the i210 controller, so it's more accurate and
+uses less CPU.
+
+When using offloaded CBS, and the traffic rate obeys the configured rate
+(doesn't go above it), CBS should have little to no effect in the latency.
+
+The offloaded version of the algorithm has some limits, caused by how the idle
+slope is expressed in the adapter's registers. It can only represent idle slopes
+in 16.38431 kbps units, which means that if a idle slope of 2576kbps is
+requested, the controller will be configured to use a idle slope of ~2589 kbps,
+because the driver rounds the value up. For more details, see the comments on
+:c:func:`igb_config_tx_modes()`.
+
+NOTE: This feature is exclusive to i210 models.
+
Support
=======
--
2.19.1
^ permalink raw reply related
* [next-queue PATCH v1 1/2] igb: Change RXPBSIZE size when setting Qav mode
From: Vinicius Costa Gomes @ 2018-11-17 0:19 UTC (permalink / raw)
To: intel-wired-lan
Cc: Jesus Sanchez-Palencia, jeffrey.t.kirsher, netdev,
jesus.s.palencia
From: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
Section 4.5.9 of the datasheet says that the total size of all packet
buffers combined (TxPB 0 + 1 + 2 + 3 + RxPB + BMC2OS + OS2BMC) must not
exceed 60KB. Today we are configuring a total of 62KB, so reduce the
RxPB from 32KB to 30KB in order to respect that.
The choice of changing RxPBSIZE here is mainly because it seems more
correct to give more priority to the transmit packet buffers over the
receiver ones when running in Qav mode. Also, the BMC2OS and OS2BMC
sizes are already too short.
Signed-off-by: Jesus Sanchez-Palencia <jesus.s.palencia@gmail.com>
---
drivers/net/ethernet/intel/igb/e1000_defines.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h b/drivers/net/ethernet/intel/igb/e1000_defines.h
index 8a28f3388f69..01fcfc6f3415 100644
--- a/drivers/net/ethernet/intel/igb/e1000_defines.h
+++ b/drivers/net/ethernet/intel/igb/e1000_defines.h
@@ -334,6 +334,7 @@
#define I210_RXPBSIZE_DEFAULT 0x000000A2 /* RXPBSIZE default */
#define I210_RXPBSIZE_MASK 0x0000003F
+#define I210_RXPBSIZE_PB_30KB 0x0000001E
#define I210_RXPBSIZE_PB_32KB 0x00000020
#define I210_TXPBSIZE_DEFAULT 0x04000014 /* TXPBSIZE default */
#define I210_TXPBSIZE_MASK 0xC0FFFFFF
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index bb4f3f64fbf0..e135adf46980 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -1934,7 +1934,7 @@ static void igb_setup_tx_mode(struct igb_adapter *adapter)
val = rd32(E1000_RXPBS);
val &= ~I210_RXPBSIZE_MASK;
- val |= I210_RXPBSIZE_PB_32KB;
+ val |= I210_RXPBSIZE_PB_30KB;
wr32(E1000_RXPBS, val);
/* Section 8.12.9 states that MAX_TPKT_SIZE from DTXMXPKTSZ
--
2.19.1
^ permalink raw reply related
* Re: Linux kernel hangs if using RV1108 with MSZ8863 switch with two ports connected
From: Andrew Lunn @ 2018-11-16 23:40 UTC (permalink / raw)
To: Otavio Salvador; +Cc: netdev, Heiko Stuebner, david.choi, Andy Yan
In-Reply-To: <CAP9ODKpHzQKC-C8KNbNUB3OGt7_xJyNtWyeYj7C9pwbh=ow0Yg@mail.gmail.com>
On Fri, Nov 16, 2018 at 04:28:29PM -0200, Otavio Salvador wrote:
> Hi,
>
> I have a custom design based on Rockchip RV1108 that uses an MSZ8863
> switch running kernel 4.19.
>
> The dts part is as follows:
>
> &gmac {
> pinctrl-names = "default";
> pinctrl-0 = <&rmii_pins>;
> snps,reset-gpio = <&gpio1 RK_PC1 GPIO_ACTIVE_LOW>;
> snps,reset-active-low;
> clock_in_out = "output";
> status = "okay";
> };
>
> RV1108 GMAC is connected to KSZ8863 port 3 and after kernel boots, I
> can put an Ethernet cable from my router to the uplink port of
> KSZ8863, which makes the RV1108 board and a Linux PC connected to the
> other KSZ8863 port to both get IP addresses.
>
> So in this usecase the setup is working fine.
>
> However, if the RV1108 board boots with both Ethernet cables to the
> KSZ8863 switch connected, then the kernel silently hangs.
Hi Otavio
By silently, you mean it prints nothing at all?
I would try building the kernel with all the lock debugging turned
on. That might find something even with your working case, if there is
a potential deadlock.
If the kernel dies very early, you might need to enable "kernel
low-level debugping print and EARLY_PRINTK, in order to see anything.
Andrew
^ permalink raw reply
* Re: WARNING: refcount bug in p9_req_put
From: Dominique Martinet @ 2018-11-17 8:55 UTC (permalink / raw)
To: syzbot
Cc: davem, ericvh, linux-kernel, lucho, netdev, syzkaller-bugs,
v9fs-developer
In-Reply-To: <000000000000eb6a8e057ab79f82@google.com>
syzbot wrote on Thu, Nov 15, 2018:
> RIP: 0010:refcount_sub_and_test_checked+0x2c9/0x310 lib/refcount.c:187
> Code: 89 de e8 ea 1a ed fd 84 db 74 07 31 db e9 4d ff ff ff e8 0a 1a
> ed fd 48 c7 c7 20 ae 60 88 c6 05 7b fd 7e 06 01 e8 67 7d b6 fd <0f>
> 0b 31 db e9 2c ff ff ff 48 89 cf e8 a6 67 30 fe e9 41 fe ff ff
> RSP: 0018:ffff88817e87f330 EFLAGS: 00010282
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90005e51000
> RDX: 00000000000222c2 RSI: ffffffff8165e7e5 RDI: 0000000000000005
> RBP: ffff88817e87f418 R08: ffff8881866ba640 R09: ffffed103b5c5020
> R10: ffffed103b5c5020 R11: ffff8881dae28107 R12: ffff88817c7a7008
> R13: 00000000ffffffff R14: ffff88817e87f3f0 R15: ffff8881c1dc9d68
> refcount_dec_and_test_checked+0x1a/0x20 lib/refcount.c:212
> kref_put include/linux/kref.h:69 [inline]
> p9_req_put+0x20/0x60 net/9p/client.c:395
> p9_conn_destroy net/9p/trans_fd.c:880 [inline]
> p9_fd_close+0x39f/0x6b0 net/9p/trans_fd.c:913
> p9_client_create+0xbd0/0x1674 net/9p/client.c:1062
> v9fs_session_init+0x217/0x1bb0 fs/9p/v9fs.c:421
So the latest ref put I added on destroy for m->rreq looks like it's not
always a good idea... The worker thread is supposed to be stoped at this
point so I'm not sure what went wrong, but while looking at this I found
a race with the read work function and the cancelled callback --
although that would cause a list corruption so it's not what happened
here.
Will think on it a bit more, and try to reproduce by adding some random
delays to make some races more likely.
I'll fix the race in trans_fd's cancelled after/together with the
async flush patches, I've got something working except for cancelled on
this end so will probably submit something around next week after I've
had time to test a bit more extensively
--
Dominique
^ permalink raw reply
* [PATCH net 2/2] tc-testing: tdc.py: Guard against lack of returncode in executed command
From: Lucas Bates @ 2018-11-16 22:37 UTC (permalink / raw)
To: davem; +Cc: netdev, xiyou.wangcong, jiri, kernel, Brenda J. Butler,
Lucas Bates
In-Reply-To: <1542407876-31310-1-git-send-email-lucasb@mojatatu.com>
From: "Brenda J. Butler" <bjb@mojatatu.com>
Add some defensive coding in case one of the subprocesses created by tdc
returns nothing. If no object is returned from exec_cmd, then tdc will
halt with an unhandled exception.
Signed-off-by: Brenda J. Butler <bjb@mojatatu.com>
Signed-off-by: Lucas Bates <lucasb@mojatatu.com>
---
tools/testing/selftests/tc-testing/tdc.py | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/tc-testing/tdc.py b/tools/testing/selftests/tc-testing/tdc.py
index 9b3f414..7607ba3 100755
--- a/tools/testing/selftests/tc-testing/tdc.py
+++ b/tools/testing/selftests/tc-testing/tdc.py
@@ -169,6 +169,8 @@ def prepare_env(args, pm, stage, prefix, cmdlist, output = None):
file=sys.stderr)
print("\n{} *** Error message: \"{}\"".format(prefix, foutput),
file=sys.stderr)
+ print("returncode {}; expected {}".format(proc.returncode,
+ exit_codes))
print("\n{} *** Aborting test run.".format(prefix), file=sys.stderr)
print("\n\n{} *** stdout ***".format(proc.stdout), file=sys.stderr)
print("\n\n{} *** stderr ***".format(proc.stderr), file=sys.stderr)
@@ -195,12 +197,18 @@ def run_one_test(pm, args, index, tidx):
print('-----> execute stage')
pm.call_pre_execute()
(p, procout) = exec_cmd(args, pm, 'execute', tidx["cmdUnderTest"])
- exit_code = p.returncode
+ if p:
+ exit_code = p.returncode
+ else:
+ exit_code = None
+
pm.call_post_execute()
- if (exit_code != int(tidx["expExitCode"])):
+ if (exit_code is None or exit_code != int(tidx["expExitCode"])):
result = False
- print("exit:", exit_code, int(tidx["expExitCode"]))
+ print("exit: {!r}".format(exit_code))
+ print("exit: {}".format(int(tidx["expExitCode"])))
+ #print("exit: {!r} {}".format(exit_code, int(tidx["expExitCode"])))
print(procout)
else:
if args.verbose > 0:
--
2.7.4
^ 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