* Re: Page allocator bottleneck
From: Tariq Toukan @ 2018-04-23 8:54 UTC (permalink / raw)
To: Aaron Lu
Cc: Linux Kernel Network Developers, linux-mm, Mel Gorman,
David Miller, Jesper Dangaard Brouer, Eric Dumazet,
Alexei Starovoitov, Saeed Mahameed, Eran Ben Elisha,
Andrew Morton, Michal Hocko
In-Reply-To: <127df719-b978-60b7-5d77-3c8efbf2ecff@mellanox.com>
On 22/04/2018 7:43 PM, Tariq Toukan wrote:
>
>
> On 21/04/2018 11:15 AM, Aaron Lu wrote:
>> Sorry to bring up an old thread...
>>
>
> I want to thank you very much for bringing this up!
>
>> On Thu, Nov 02, 2017 at 07:21:09PM +0200, Tariq Toukan wrote:
>>>
>>>
>>> On 18/09/2017 12:16 PM, Tariq Toukan wrote:
>>>>
>>>>
>>>> On 15/09/2017 1:23 PM, Mel Gorman wrote:
>>>>> On Thu, Sep 14, 2017 at 07:49:31PM +0300, Tariq Toukan wrote:
>>>>>> Insights: Major degradation between #1 and #2, not getting any
>>>>>> close to linerate! Degradation is fixed between #2 and #3. This is
>>>>>> because page allocator cannot stand the higher allocation rate. In
>>>>>> #2, we also see that the addition of rings (cores) reduces BW (!!),
>>>>>> as result of increasing congestion over shared resources.
>>>>>>
>>>>>
>>>>> Unfortunately, no surprises there.
>>>>>
>>>>>> Congestion in this case is very clear. When monitored in perf
>>>>>> top: 85.58% [kernel] [k] queued_spin_lock_slowpath
>>>>>>
>>>>>
>>>>> While it's not proven, the most likely candidate is the zone lock
>>>>> and that should be confirmed using a call-graph profile. If so, then
>>>>> the suggestion to tune to the size of the per-cpu allocator would
>>>>> mitigate the problem.
>>>>>
>>>> Indeed, I tuned the per-cpu allocator and bottleneck is released.
>>>>
>>>
>>> Hi all,
>>>
>>> After leaving this task for a while doing other tasks, I got back to
>>> it now
>>> and see that the good behavior I observed earlier was not stable.
>>
>> I posted a patchset to improve zone->lock contention for order-0 pages
>> recently, it can almost eliminate 80% zone->lock contention for
>> will-it-scale/page_fault1 testcase when tested on a 2 sockets Intel
>> Skylake server and it doesn't require PCP size tune, so should have
>> some effects on your workload where one CPU does allocation while
>> another does free.
>>
>
> That is great news. In our driver's memory scheme (and many others as
> well) we allocate only order-0 pages (the only flow that does not do
> that yet in upstream will do so very soon, we already have the patches
> in our internal branch).
> Allocation of order-0 pages is not only the common case, but is the only
> type of allocation in our data-path. Let's optimize it!
>
>
>> It did this by some disruptive changes:
>> 1 on free path, it skipped doing merge(so could be bad for mixed
>> workloads where both 4K and high order pages are needed);
>
> I think there are so many advantages to not using high order
> allocations, especially in production servers that are not rebooted for
> long periods and become fragmented.
> AFAIK, the community direction (at least in networking) is using order-0
> pages in datapath, so optimizing their allocaiton is a very good idea.
> Need of course to perf evaluate possible degradations, and see how
> important these use cases are.
>
>> 2 on allocation path, it avoided touching multiple cachelines.
>>
>
> Great!
>
>> RFC v2 patchset:
>> https://lkml.org/lkml/2018/3/20/171
>>
>> repo:
>> https://github.com/aaronlu/linux zone_lock_rfc_v2
>>
>
> I will check them out first thing tomorrow!
>
> p.s., I will be on vacation for a week starting Tuesday.
> I hope I can make some progress before that :)
>
> Thanks,
> Tariq
>
Hi,
I ran my tests with your patches.
Initial BW numbers are significantly higher than I documented back then
in this mail-thread.
For example, in driver #2 (see original mail thread), with 6 rings, I
now get 92Gbps (slightly less than linerate) in comparison to 64Gbps
back then.
However, there were many kernel changes since then, I need to isolate
your changes. I am not sure I can finish this today, but I will surely
get to it next week after I'm back from vacation.
Still, when I increase the scale (more rings, i.e. more cpus), I see
that queued_spin_lock_slowpath gets to 60%+ cpu. Still high, but lower
than it used to be.
This should be root solved by the (orthogonal) changes planned in
network subsystem, which will change the SKB allocation/free scheme so
that SKBs are released on the originating cpu.
Thanks,
Tariq
>>> Recall: I work with a modified driver that allocates a page (4K) per
>>> packet
>>> (MTU=1500), in order to simulate the stress on page-allocator in 200Gbps
>>> NICs.
>>>
>>> Performance is good as long as pages are available in the allocating
>>> cores's
>>> PCP.
>>> Issue is that pages are allocated in one core, then free'd in another,
>>> making it's hard for the PCP to work efficiently, and both the allocator
>>> core and the freeing core need to access the buddy allocator very often.
>>>
>>> I'd like to share with you some testing numbers:
>>>
>>> Test: ./super_netperf 128 -H 24.134.0.51 -l 1000
>>>
>>> 100% cpu on all cores, top func in perf:
>>> 84.98% [kernel] [k] queued_spin_lock_slowpath
>>>
>>> system wide (all cores)
>>> 1135941 kmem:mm_page_alloc
>>>
>>> 2606629 kmem:mm_page_free
>>>
>>> 0 kmem:mm_page_alloc_extfrag
>>> 4784616 kmem:mm_page_alloc_zone_locked
>>>
>>> 1337 kmem:mm_page_free_batched
>>>
>>> 6488213 kmem:mm_page_pcpu_drain
>>>
>>> 8925503 net:napi_gro_receive_entry
>>>
>>>
>>> Two types of cores:
>>> A core mostly running napi (8 such cores):
>>> 221875 kmem:mm_page_alloc
>>>
>>> 17100 kmem:mm_page_free
>>>
>>> 0 kmem:mm_page_alloc_extfrag
>>> 766584 kmem:mm_page_alloc_zone_locked
>>>
>>> 16 kmem:mm_page_free_batched
>>>
>>> 35 kmem:mm_page_pcpu_drain
>>>
>>> 1340139 net:napi_gro_receive_entry
>>>
>>>
>>> Other core, mostly running user application (40 such):
>>> 2 kmem:mm_page_alloc
>>>
>>> 38922 kmem:mm_page_free
>>>
>>> 0 kmem:mm_page_alloc_extfrag
>>> 1 kmem:mm_page_alloc_zone_locked
>>>
>>> 8 kmem:mm_page_free_batched
>>>
>>> 107289 kmem:mm_page_pcpu_drain
>>>
>>> 34 net:napi_gro_receive_entry
>>>
>>>
>>> As you can see, sync overhead is enormous.
>>>
>>> PCP-wise, a key improvement in such scenarios would be reached if we
>>> could
>>> (1) keep and handle the allocated page on same cpu, or (2) somehow
>>> get the
>>> page back to the allocating core's PCP in a fast-path, without going
>>> through
>>> the regular buddy allocator paths.
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: implement and use per cpu rx skbs cache
From: Jesper Dangaard Brouer @ 2018-04-23 8:52 UTC (permalink / raw)
To: Paolo Abeni
Cc: Eric Dumazet, Willem de Bruijn, netdev, David S. Miller,
Tariq Toukan, brouer
In-Reply-To: <1524396178.10317.18.camel@redhat.com>
On Sun, 22 Apr 2018 13:22:58 +0200
Paolo Abeni <pabeni@redhat.com> wrote:
> On Fri, 2018-04-20 at 15:48 +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 19 Apr 2018 06:47:10 -0700 Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > On 04/19/2018 12:40 AM, Paolo Abeni wrote:
> > > > On Wed, 2018-04-18 at 12:21 -0700, Eric Dumazet wrote:
> > > > > On 04/18/2018 10:15 AM, Paolo Abeni wrote:
> >
> > [...]
> > > >
> > > > Any suggestions for better results are more than welcome!
> > >
> > > Yes, remote skb freeing. I mentioned this idea to Jesper and Tariq in
> > > Seoul (netdev conference). Not tied to UDP, but a generic solution.
> >
> > Yes, I remember. I think... was it the idea, where you basically
> > wanted to queue back SKBs to the CPU that allocated them, right?
> >
> > Freeing an SKB on the same CPU that allocated it, have multiple
> > advantages. (1) the SLUB allocator can use a non-atomic
> > "cpu-local" (double)cmpxchg. (2) the 4 cache-lines memset cleared of
> > the SKB stay local. (3) the atomic SKB refcnt/users stay local.
>
> By the time the skb is returned to the ingress cpu, isn't that skb most
> probably out of the cache?
This is a too simplistic view. You have to look at the cache
coherence state[1] of the individual cache lines (SKB consist of 4
cache-lines). And newer Intel CPUs [2] can "Forward(F)" cache-lines
between caches. The SKB cache-line that have atomic refcnt/users
important to analyze (Read For Ownership (RFO) case). Analyzing the
other cache-lines is actually more complicated due to techniques like
"Store Buffer" and "Invalidate Queues".
[1] https://en.wikipedia.org/wiki/MESI_protocol
[2] https://en.wikipedia.org/wiki/MESIF_protocol
There is also a lot of detail in point (1) about how the SLUB
alloactor works internally, and how it avoids bouncing the struct-page
cache-line. Some of the performance benefit from you current patch
also comes from this...
> > We just have to avoid that queue back SKB's mechanism, doesn't cost
> > more than the operations we expect to save. Bulk transfer is an
> > obvious approach. For storing SKBs until they are returned, we already
> > have a fast mechanism see napi_consume_skb calling _kfree_skb_defer,
> > which SLUB/SLAB-bulk free to amortize cost (1).
> >
> > I guess, the missing information is that we don't know what CPU the SKB
> > were created on...
> >
> > Where to store this CPU info?
> >
> > (a) In struct sk_buff, in a cache-line that is already read on remote
> > CPU in UDP code?
> >
> > (b) In struct page, as SLUB alloc hand-out objects/SKBs on a per page
> > basis, we could have SLUB store a hint about the CPU it was allocated
> > on, and bet on returning to that CPU ? (might be bad to read the
> > struct-page cache-line)
>
> Bulking would be doable only for connected sockets, elsewhere would be
> difficult to assemble a burst long enough to amortize the handshake
> with the remote CPU (spinlock + ipi needed ?!?)
We obviously need some level of bulking.
I would likely try to avoid any explicit IPI calls, but instead use a
queue like the ptr_ring queue, because it have good separation between
cache-lines used by consumer and producer (but it might be overkill
for this use-case).
> Would be good enough for unconnected sockets sending a whole skb burst
> back to one of the (several) ingress CPU? e.g. peeking the CPU
> associated with the first skb inside the burst, we would somewhat
> balance the load between the ingress CPUs.
See, Willem de Bruijn suggestions...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] team: check team dev npinfo when adding a port only
From: Xin Long @ 2018-04-23 8:46 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, network dev, davem, Jiri Pirko, stephen hemminger
In-Reply-To: <CADvbK_esxb+WG-ute1nNwDVkMrKargxCt1_HeQZv8D4CLskVsA@mail.gmail.com>
On Mon, Apr 23, 2018 at 1:40 PM, Xin Long <lucien.xin@gmail.com> wrote:
> On Mon, Apr 23, 2018 at 12:20 PM, kbuild test robot <lkp@intel.com> wrote:
>> Hi Xin,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on net/master]
>>
>> url: https://github.com/0day-ci/linux/commits/Xin-Long/team-check-team-dev-npinfo-when-adding-a-port-only/20180423-114310
>> config: i386-randconfig-x071-201816 (attached as .config)
>> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=i386
>>
>> All errors (new ones prefixed by >>):
>>
>> drivers/net/team/team.c: In function 'team_port_add':
>>>> drivers/net/team/team.c:1221:15: error: 'struct net_device' has no member named 'npinfo'
>> if (team->dev->npinfo) {
>> ^~
> Oops, this is different from bonding, we probably should
> just revert 0fb52a27a04a ("team: cleanup netpoll clode")
> for this fix.
or do the same as bridge netpoll does.
+static int team_port_enable_netpoll(struct team *team, struct team_port *port)
+{
+ if (!team->dev->npinfo)
+ return 0;
+
+ return __team_port_enable_netpoll(port);
+}
which looks better.
^ permalink raw reply
* Re: [PATCH 09/15] net: irda: pxaficp_ir: remove the dmaengine compat need
From: Greg Kroah-Hartman @ 2018-04-23 8:37 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Ulf Hansson, alsa-devel, Takashi Iwai, linux-ide, Pravin Shedge,
linux-mtd, devel, Boris Brezillon, Mauro Carvalho Chehab,
Vinod Koul, Richard Weinberger, Marek Vasut, Ezequiel Garcia,
linux-media, Samuel Ortiz, Arnd Bergmann,
Bartlomiej Zolnierkiewicz, Haojian Zhuang, dmaengine, Mark Brown,
Jaroslav Kysela, linux-arm-kernel, Nicolas Pitre, netdev,
linux-mmc
In-Reply-To: <20180402142656.26815-10-robert.jarzmik@free.fr>
On Mon, Apr 02, 2018 at 04:26:50PM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
>
> This patch simplifies the dma resource acquisition, using the more
> generic function dma_request_slave_channel().
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> drivers/staging/irda/drivers/pxaficp_ir.c | 14 ++------------
> 1 file changed, 2 insertions(+), 12 deletions(-)
This file is no longer in Linus's tree :)
thanks,
greg k-h
^ permalink raw reply
* KMSAN: uninit-value in pppoe_connect
From: syzbot @ 2018-04-23 8:24 UTC (permalink / raw)
To: linux-kernel, mostrows, netdev, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +0000)
kmsan: disable assembly checksums
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=4f03bdf92fdf9ef5ddab
So far this crash happened 2 times on
https://github.com/google/kmsan.git/master.
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5233317381144576
Kernel config: https://syzkaller.appspot.com/x/.config?id=328654897048964367
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4f03bdf92fdf9ef5ddab@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in pppoe_connect+0xe9a/0x2360
drivers/net/ppp/pppoe.c:662
CPU: 1 PID: 8338 Comm: syz-executor2 Not tainted 4.16.0+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
pppoe_connect+0xe9a/0x2360 drivers/net/ppp/pppoe.c:662
SYSC_connect+0x41a/0x510 net/socket.c:1639
SyS_connect+0x54/0x80 net/socket.c:1620
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x455389
RSP: 002b:00007f5c253ecc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007f5c253ed6d4 RCX: 0000000000455389
RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000013
RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000063 R14: 00000000006f39e8 R15: 0000000000000000
Local variable description: ----address@SYSC_connect
Variable was created at:
SYSC_connect+0x6f/0x510 net/socket.c:1622
SyS_connect+0x54/0x80 net/socket.c:1620
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* WARNING: suspicious RCU usage in rt6_check_expired
From: syzbot @ 2018-04-23 8:24 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot hit the following crash on net-next commit
0638eb573cde5888c0886c7f35da604e5db209a6 (Sat Apr 21 20:06:14 2018 +0000)
Merge branch 'ipv6-Another-followup-to-the-fib6_info-change'
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=2422c9e35796659d2273
So far this crash happened 3 times on net-next.
Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6081013801287680
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-8412024688694752032
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2422c9e35796659d2273@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
netlink: 'syz-executor4': attribute type 6 has an invalid length.
netlink: 'syz-executor4': attribute type 1 has an invalid length.
netlink: 'syz-executor4': attribute type 6 has an invalid length.
=============================
WARNING: suspicious RCU usage
4.16.0+ #11 Not tainted
-----------------------------
net/ipv6/route.c:410 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz-executor7/25958:
#0: 00000000d1963139 (sk_lock-AF_INET6){+.+.}, at: lock_sock
include/net/sock.h:1469 [inline]
#0: 00000000d1963139 (sk_lock-AF_INET6){+.+.}, at:
sock_setsockopt+0x19c/0x1fe0 net/core/sock.c:717
stack backtrace:
CPU: 1 PID: 25958 Comm: syz-executor7 Not tainted 4.16.0+ #11
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+0x1b9/0x294 lib/dump_stack.c:113
lockdep_rcu_suspicious+0x14a/0x153 kernel/locking/lockdep.c:4592
rt6_check_expired+0x38b/0x3e0 net/ipv6/route.c:410
ip6_negative_advice+0x67/0xc0 net/ipv6/route.c:2204
dst_negative_advice include/net/sock.h:1786 [inline]
sock_setsockopt+0x138f/0x1fe0 net/core/sock.c:1051
__sys_setsockopt+0x2df/0x390 net/socket.c:1899
SYSC_setsockopt net/socket.c:1914 [inline]
SyS_setsockopt+0x34/0x50 net/socket.c:1911
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x455389
RSP: 002b:00007f7556e30c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007f7556e316d4 RCX: 0000000000455389
RDX: 0000000000000035 RSI: 0000000000000001 RDI: 0000000000000013
RBP: 000000000072bf58 R08: 0000000000000004 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000000005ff R14: 00000000006fc088 R15: 0000000000000001
netlink: 'syz-executor4': attribute type 4 has an invalid length.
netlink: 'syz-executor4': attribute type 4 has an invalid length.
IPVS: set_ctl: invalid protocol: 59 127.0.0.1:20000 lc
IPVS: set_ctl: invalid protocol: 127 224.0.0.1:20000 rr
IPVS: sync thread started: state = BACKUP, mcast_ifn = ip6tnl0, syncid = 4,
id = 0
IPVS: set_ctl: invalid protocol: 127 224.0.0.1:20000 rr
netlink: 72 bytes leftover after parsing attributes in process
`syz-executor2'.
netlink: 72 bytes leftover after parsing attributes in process
`syz-executor2'.
dccp_xmit_packet: Payload too large (65423) for featneg.
IPVS: set_ctl: invalid protocol: 29 1.0.0.0:2 wlc
IPVS: set_ctl: invalid protocol: 29 1.0.0.0:2 wlc
netlink: 32 bytes leftover after parsing attributes in process
`syz-executor7'.
netlink: 12 bytes leftover after parsing attributes in process
`syz-executor1'.
netlink: 12 bytes leftover after parsing attributes in process
`syz-executor1'.
netlink: 'syz-executor1': attribute type 29 has an invalid length.
netlink: 8 bytes leftover after parsing attributes in process
`syz-executor1'.
IPVS: set_ctl: invalid protocol: 108 224.0.0.1:20004 lblc
netlink: 'syz-executor1': attribute type 29 has an invalid length.
netlink: 8 bytes leftover after parsing attributes in process
`syz-executor1'.
IPVS: set_ctl: invalid protocol: 108 224.0.0.1:20004 lblc
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* KMSAN: uninit-value in pppol2tp_connect
From: syzbot @ 2018-04-23 8:24 UTC (permalink / raw)
To: davem, jchapman, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +0000)
kmsan: disable assembly checksums
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=a70ac890b23b1bf29f5c
So far this crash happened 3 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4946656566968320
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5395971013869568
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5936570024591360
Kernel config: https://syzkaller.appspot.com/x/.config?id=328654897048964367
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a70ac890b23b1bf29f5c@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in pppol2tp_connect+0x258/0x1c50
net/l2tp/l2tp_ppp.c:622
CPU: 1 PID: 4524 Comm: syzkaller735385 Not tainted 4.16.0+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
pppol2tp_connect+0x258/0x1c50 net/l2tp/l2tp_ppp.c:622
SYSC_connect+0x41a/0x510 net/socket.c:1639
SyS_connect+0x54/0x80 net/socket.c:1620
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x445559
RSP: 002b:00007f0b96f0ddb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445559
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffec2b0929f R14: 00007f0b96f0e9c0 R15: 0000000000000001
Local variable description: ----address@SYSC_connect
Variable was created at:
SYSC_connect+0x6f/0x510 net/socket.c:1622
SyS_connect+0x54/0x80 net/socket.c:1620
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* KMSAN: uninit-value in strnlen
From: syzbot @ 2018-04-23 8:23 UTC (permalink / raw)
To: linux-kernel, mostrows, netdev, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +0000)
kmsan: disable assembly checksums
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=cd06c321e7147d03a65e
So far this crash happened 5 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5785171018121216
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5117671628603392
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6310764688179200
Kernel config: https://syzkaller.appspot.com/x/.config?id=328654897048964367
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cd06c321e7147d03a65e@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in strnlen+0xc4/0x110 lib/string.c:499
CPU: 1 PID: 4507 Comm: syzkaller579712 Not tainted 4.16.0+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
strnlen+0xc4/0x110 lib/string.c:499
dev_name_hash net/core/dev.c:209 [inline]
dev_get_by_name_rcu net/core/dev.c:764 [inline]
dev_get_by_name+0x6e/0x350 net/core/dev.c:791
pppoe_connect+0xcb7/0x2360 drivers/net/ppp/pppoe.c:665
SYSC_connect+0x41a/0x510 net/socket.c:1639
SyS_connect+0x54/0x80 net/socket.c:1620
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43fcf9
RSP: 002b:00007ffca4bd4978 EFLAGS: 00000213 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fcf9
RDX: 0000000000000007 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401620
R13: 00000000004016b0 R14: 0000000000000000 R15: 0000000000000000
Local variable description: ----address@SYSC_connect
Variable was created at:
SYSC_connect+0x6f/0x510 net/socket.c:1622
SyS_connect+0x54/0x80 net/socket.c:1620
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* KMSAN: uninit-value in ebt_stp_mt_check
From: syzbot @ 2018-04-23 8:23 UTC (permalink / raw)
To: bridge, coreteam, davem, fw, kadlec, linux-kernel, netdev,
netfilter-devel, pablo, stephen, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
a7f95e9c8a95e9fbb388c3999b61a17667cd3bbe (Sat Apr 21 13:50:22 2018 +0000)
kmsan: disable assembly checksums
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=5c06e318fc558cc27823
So far this crash happened 3 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5411555638247424
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=6309829995921408
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=4546610964987904
Kernel config: https://syzkaller.appspot.com/x/.config?id=328654897048964367
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5c06e318fc558cc27823@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in ebt_stp_mt_check+0x248/0x410
net/bridge/netfilter/ebt_stp.c:164
CPU: 0 PID: 4520 Comm: syzkaller565841 Not tainted 4.16.0+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
ebt_stp_mt_check+0x248/0x410 net/bridge/netfilter/ebt_stp.c:164
xt_check_match+0x1449/0x1660 net/netfilter/x_tables.c:499
ebt_check_match net/bridge/netfilter/ebtables.c:374 [inline]
ebt_check_entry net/bridge/netfilter/ebtables.c:704 [inline]
translate_table+0x3ffd/0x5e10 net/bridge/netfilter/ebtables.c:945
do_replace_finish+0x1258/0x2ea0 net/bridge/netfilter/ebtables.c:1002
do_replace+0x707/0x770 net/bridge/netfilter/ebtables.c:1141
do_ebt_set_ctl+0x2ab/0x3c0 net/bridge/netfilter/ebtables.c:1518
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x476/0x4d0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0x24b/0x2b0 net/ipv4/ip_sockglue.c:1261
dccp_setsockopt+0x1c3/0x1f0 net/dccp/proto.c:576
sock_common_setsockopt+0x136/0x170 net/core/sock.c:2975
SYSC_setsockopt+0x4b8/0x570 net/socket.c:1849
SyS_setsockopt+0x76/0xa0 net/socket.c:1828
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x445d39
RSP: 002b:00007efff4e14da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445d39
RDX: 0000000000000080 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000358 R09: 0000000000000000
R10: 00000000200008c0 R11: 0000000000000246 R12: 00000000006dac20
R13: 006567646972625f R14: 6f745f3168746576 R15: 0000000000000002
Local variable description: ----mtpar.i@translate_table
Variable was created at:
translate_table+0xb9/0x5e10 net/bridge/netfilter/ebtables.c:833
do_replace_finish+0x1258/0x2ea0 net/bridge/netfilter/ebtables.c:1002
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: implement and use per cpu rx skbs cache
From: Tariq Toukan @ 2018-04-23 8:13 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Eric Dumazet
Cc: Paolo Abeni, netdev, David S. Miller, Tariq Toukan
In-Reply-To: <20180420154836.3690a39e@redhat.com>
On 20/04/2018 4:48 PM, Jesper Dangaard Brouer wrote:
>
> On Thu, 19 Apr 2018 06:47:10 -0700 Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On 04/19/2018 12:40 AM, Paolo Abeni wrote:
>>> On Wed, 2018-04-18 at 12:21 -0700, Eric Dumazet wrote:
>>>> On 04/18/2018 10:15 AM, Paolo Abeni wrote:
> [...]
>>>
>>> Any suggestions for better results are more than welcome!
>>
>> Yes, remote skb freeing. I mentioned this idea to Jesper and Tariq in
>> Seoul (netdev conference). Not tied to UDP, but a generic solution.
>
> Yes, I remember. I think... was it the idea, where you basically
> wanted to queue back SKBs to the CPU that allocated them, right?
>
> Freeing an SKB on the same CPU that allocated it, have multiple
> advantages. (1) the SLUB allocator can use a non-atomic
> "cpu-local" (double)cmpxchg. (2) the 4 cache-lines memset cleared of
> the SKB stay local. (3) the atomic SKB refcnt/users stay local.
>
> We just have to avoid that queue back SKB's mechanism, doesn't cost
> more than the operations we expect to save. Bulk transfer is an
> obvious approach. For storing SKBs until they are returned, we already
> have a fast mechanism see napi_consume_skb calling _kfree_skb_defer,
> which SLUB/SLAB-bulk free to amortize cost (1).
>
> I guess, the missing information is that we don't know what CPU the SKB
> were created on...
>
> Where to store this CPU info?
>
> (a) In struct sk_buff, in a cache-line that is already read on remote
> CPU in UDP code?
>
> (b) In struct page, as SLUB alloc hand-out objects/SKBs on a per page
> basis, we could have SLUB store a hint about the CPU it was allocated
> on, and bet on returning to that CPU ? (might be bad to read the
> struct-page cache-line)
>
I'm in favor of (a).
Pages of an SKB originates on the same cpu (guaranteed by NAPI).
So a single field in SKB is good for all of its fragments, no need to
read this info from every single page. This also keeps the change local
to the networking subsystem.
Best if we find a hole in struct SKB (for u16?), or union it with a
mutually exclusive field.
Regards,
Tariq
^ permalink raw reply
* Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
From: Geert Uytterhoeven @ 2018-04-23 8:08 UTC (permalink / raw)
To: Laurent Pinchart
Cc: ALSA Development Mailing List, Kuninori Morimoto, Catalin Marinas,
Will Deacon, Liam Girdwood, driverdevel, Mauro Carvalho Chehab,
Geert Uytterhoeven, Vinod Koul, Magnus Damm, Russell King,
Linux Media Mailing List, Arnd Bergmann, Mark Brown, Dan Williams,
Linux ARM, Sergei Shtylyov, Greg Kroah-Hartman, Takashi Iwai,
Linux Kernel Mailing List, Linux-
In-Reply-To: <1700954.Qkp7xggMnX@avalon>
Hi Laurent,
On Sun, Apr 22, 2018 at 10:46 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Saturday, 21 April 2018 11:07:11 EEST Laurent Pinchart wrote:
>> On Friday, 20 April 2018 16:28:29 EEST Geert Uytterhoeven wrote:
>> > The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
>> > only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
>> > ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
>> > than the legacy ARCH_SHMOBILE, hence use the former.
>> >
>> > This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
>> > future.
>> >
>> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>
>> How would you like to get this merged ?
>
> Unless you would like to merge the whole series in one go, I'll take this in
> my tree as I have a conflicting patch I would like to submit for v4.18.
Please take it in your tree, thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 6/6] rhashtable: add rhashtable_walk_prev()
From: Herbert Xu @ 2018-04-23 8:07 UTC (permalink / raw)
To: NeilBrown; +Cc: Thomas Graf, netdev, linux-kernel
In-Reply-To: <87bmegqfjc.fsf@notabene.neil.brown.name>
On Thu, Apr 19, 2018 at 09:08:07AM +1000, NeilBrown wrote:
>
> The need is essentially the same as the need for
> rhashtable_walk_peek(). The difference is that the actual behaviour can
> be documented briefly (and so understood easily) without enumerating
> multiple special cases.
> rhashtable_walk_peek() is much the same as
> rhashtable_walk_prev() ?: rhashtable_walk_next()
>
> The need arises when you need to "stop" a walk and then restart at the
> same object, not the next one. i.e. the last object returned before the
> "stop" wasn't acted on.
> This happens with seq_file if the buffer space for ->show() is not
> sufficient to format an object. In the case, seq_file will stop() the
> iteration, make more space available (either by flushing or by
> reallocing) and will start again at the same location.
> If the seq_file client stored the rhashtable_iter in the seq_file
> private data, it can use rhasthable_walk_prev() to recover its position
> if that object is still in the hash table. If it isn't still present,
> rhashtable_walk_next() can be used to get the next one. In some cases
> it can be useful for the client to know whether it got the previous one
> or not.
I see. I'm OK with this provided that you will also remove/convert
users of rhashtable_walk_peek.
I don't think we need two functions that do almost the same thing.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/6] rhashtable: remove incorrect comment on r{hl, hash}table_walk_enter()
From: Herbert Xu @ 2018-04-23 8:06 UTC (permalink / raw)
To: NeilBrown; +Cc: Thomas Graf, netdev, linux-kernel
In-Reply-To: <87d0yqog56.fsf@notabene.neil.brown.name>
On Mon, Apr 23, 2018 at 11:39:17AM +1000, NeilBrown wrote:
>
> Sound fair. Could you Ack the following? Then I'll resend all the
> patches that have an ack.
> I've realised that the "further improve stability of rhashtable_walk"
> patch isn't actually complete, so I'll withdraw that for now.
Looks good to me.
> From e16c037398b6c057787437f3a0aaa7fd44c3bee3 Mon Sep 17 00:00:00 2001
> From: NeilBrown <neilb@suse.com>
> Date: Mon, 16 Apr 2018 11:05:39 +1000
> Subject: [PATCH] rhashtable: Revise incorrect comment on
> r{hl,hash}table_walk_enter()
>
> Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, though
> they do take a spinlock without irq protection.
> So revise the comments to accurately state the contexts in which
> these functions can be called.
>
> Signed-off-by: NeilBrown <neilb@suse.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 net-next] net: stmmac: Implement logic to automatically select HW Interface
From: Jose Abreu @ 2018-04-23 8:05 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, David S. Miller, Joao Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
Move all the core version detection to a common place ("hwif.c") and
implement a table which can be used to lookup the correct callbacks for
each IP version.
This simplifies the initialization flow of each IP version and eases
future implementation of new IP versions.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Vitor Soares <soares@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
Changes from v1:
- Remove C++ style comments from header (David)
- Add a dev_err when HW Interface is not found
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 3 +-
drivers/net/ethernet/stmicro/stmmac/common.h | 30 +---
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 1 -
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 29 +--
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 23 +--
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 -
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 41 +---
drivers/net/ethernet/stmicro/stmmac/hwif.c | 220 ++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/hwif.h | 17 ++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 77 +-------
11 files changed, 279 insertions(+), 164 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/hwif.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 972e4ef..e3b578b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -4,7 +4,8 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o \
- dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o $(stmmac-y)
+ dwmac4_dma.o dwmac4_lib.o dwmac4_core.o dwmac5.o hwif.o \
+ $(stmmac-y)
# Ordering matters. Generic driver must be last.
obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index 59673c6..627e905 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -39,6 +39,7 @@
#define DWMAC_CORE_3_40 0x34
#define DWMAC_CORE_3_50 0x35
#define DWMAC_CORE_4_00 0x40
+#define DWMAC_CORE_4_10 0x41
#define DWMAC_CORE_5_00 0x50
#define DWMAC_CORE_5_10 0x51
#define STMMAC_CHAN0 0 /* Always supported and default for all chips */
@@ -428,12 +429,9 @@ struct stmmac_rx_routing {
u32 reg_shift;
};
-struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries,
- int *synopsys_id);
-struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id);
-struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries, int *synopsys_id);
+int dwmac100_setup(struct stmmac_priv *priv);
+int dwmac1000_setup(struct stmmac_priv *priv);
+int dwmac4_setup(struct stmmac_priv *priv);
void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
unsigned int high, unsigned int low);
@@ -453,24 +451,4 @@ void stmmac_dwmac4_get_mac_addr(void __iomem *ioaddr, unsigned char *addr,
extern const struct stmmac_mode_ops chain_mode_ops;
extern const struct stmmac_desc_ops dwmac4_desc_ops;
-/**
- * stmmac_get_synopsys_id - return the SYINID.
- * @priv: driver private structure
- * Description: this simple function is to decode and return the SYINID
- * starting from the HW core register.
- */
-static inline u32 stmmac_get_synopsys_id(u32 hwid)
-{
- /* Check Synopsys Id (not available on old chips) */
- if (likely(hwid)) {
- u32 uid = ((hwid & 0x0000ff00) >> 8);
- u32 synid = (hwid & 0x000000ff);
-
- pr_info("stmmac - user ID: 0x%x, Synopsys ID: 0x%x\n",
- uid, synid);
-
- return synid;
- }
- return 0;
-}
#endif /* __COMMON_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index c02d366..184ca13 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -29,7 +29,6 @@
#define GMAC_MII_DATA 0x00000014 /* MII Data */
#define GMAC_FLOW_CTRL 0x00000018 /* Flow Control */
#define GMAC_VLAN_TAG 0x0000001c /* VLAN Tag */
-#define GMAC_VERSION 0x00000020 /* GMAC CORE Version */
#define GMAC_DEBUG 0x00000024 /* GMAC debug register */
#define GMAC_WAKEUP_FILTER 0x00000028 /* Wake-up Frame Filter */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index ef10baf..0877bde 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -27,6 +27,7 @@
#include <linux/ethtool.h>
#include <net/dsa.h>
#include <asm/io.h>
+#include "stmmac.h"
#include "stmmac_pcs.h"
#include "dwmac1000.h"
@@ -498,7 +499,7 @@ static void dwmac1000_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
x->mac_gmii_rx_proto_engine++;
}
-static const struct stmmac_ops dwmac1000_ops = {
+const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
.set_mac = stmmac_set_mac,
.rx_ipc = dwmac1000_rx_ipc_enable,
@@ -519,28 +520,21 @@ static void dwmac1000_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
.pcs_get_adv_lp = dwmac1000_get_adv_lp,
};
-struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries,
- int *synopsys_id)
+int dwmac1000_setup(struct stmmac_priv *priv)
{
- struct mac_device_info *mac;
- u32 hwid = readl(ioaddr + GMAC_VERSION);
+ struct mac_device_info *mac = priv->hw;
- mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
- if (!mac)
- return NULL;
+ dev_info(priv->device, "\tDWMAC1000\n");
- mac->pcsr = ioaddr;
- mac->multicast_filter_bins = mcbins;
- mac->unicast_filter_entries = perfect_uc_entries;
+ priv->dev->priv_flags |= IFF_UNICAST_FLT;
+ mac->pcsr = priv->ioaddr;
+ mac->multicast_filter_bins = priv->plat->multicast_filter_bins;
+ mac->unicast_filter_entries = priv->plat->unicast_filter_entries;
mac->mcast_bits_log2 = 0;
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
- mac->mac = &dwmac1000_ops;
- mac->dma = &dwmac1000_dma_ops;
-
mac->link.duplex = GMAC_CONTROL_DM;
mac->link.speed10 = GMAC_CONTROL_PS;
mac->link.speed100 = GMAC_CONTROL_PS | GMAC_CONTROL_FES;
@@ -555,8 +549,5 @@ struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
mac->mii.clk_csr_shift = 2;
mac->mii.clk_csr_mask = GENMASK(5, 2);
- /* Get and dump the chip ID */
- *synopsys_id = stmmac_get_synopsys_id(hwid);
-
- return mac;
+ return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 91b23f9..b735143 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -27,6 +27,7 @@
#include <linux/crc32.h>
#include <net/dsa.h>
#include <asm/io.h>
+#include "stmmac.h"
#include "dwmac100.h"
static void dwmac100_core_init(struct mac_device_info *hw,
@@ -159,7 +160,7 @@ static void dwmac100_pmt(struct mac_device_info *hw, unsigned long mode)
return;
}
-static const struct stmmac_ops dwmac100_ops = {
+const struct stmmac_ops dwmac100_ops = {
.core_init = dwmac100_core_init,
.set_mac = stmmac_set_mac,
.rx_ipc = dwmac100_rx_ipc_enable,
@@ -172,20 +173,13 @@ static void dwmac100_pmt(struct mac_device_info *hw, unsigned long mode)
.get_umac_addr = dwmac100_get_umac_addr,
};
-struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id)
+int dwmac100_setup(struct stmmac_priv *priv)
{
- struct mac_device_info *mac;
+ struct mac_device_info *mac = priv->hw;
- mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
- if (!mac)
- return NULL;
-
- pr_info("\tDWMAC100\n");
-
- mac->pcsr = ioaddr;
- mac->mac = &dwmac100_ops;
- mac->dma = &dwmac100_dma_ops;
+ dev_info(priv->device, "\tDWMAC100\n");
+ mac->pcsr = priv->ioaddr;
mac->link.duplex = MAC_CONTROL_F;
mac->link.speed10 = 0;
mac->link.speed100 = 0;
@@ -200,8 +194,5 @@ struct mac_device_info *dwmac100_setup(void __iomem *ioaddr, int *synopsys_id)
mac->mii.clk_csr_shift = 2;
mac->mii.clk_csr_mask = GENMASK(5, 2);
- /* Synopsys Id is not available on old chips */
- *synopsys_id = 0;
-
- return mac;
+ return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index c7bff59..ec32fd7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -34,7 +34,6 @@
#define GMAC_PCS_BASE 0x000000e0
#define GMAC_PHYIF_CONTROL_STATUS 0x000000f8
#define GMAC_PMT 0x000000c0
-#define GMAC_VERSION 0x00000110
#define GMAC_DEBUG 0x00000114
#define GMAC_HW_FEATURE0 0x0000011c
#define GMAC_HW_FEATURE1 0x00000120
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index a3af92e..cdda0bf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -18,6 +18,7 @@
#include <linux/ethtool.h>
#include <linux/io.h>
#include <net/dsa.h>
+#include "stmmac.h"
#include "stmmac_pcs.h"
#include "dwmac4.h"
#include "dwmac5.h"
@@ -707,7 +708,7 @@ static void dwmac4_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
x->mac_gmii_rx_proto_engine++;
}
-static const struct stmmac_ops dwmac4_ops = {
+const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_set_mac,
.rx_ipc = dwmac4_rx_ipc_enable,
@@ -738,7 +739,7 @@ static void dwmac4_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
.set_filter = dwmac4_set_filter,
};
-static const struct stmmac_ops dwmac410_ops = {
+const struct stmmac_ops dwmac410_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_dwmac4_set_mac,
.rx_ipc = dwmac4_rx_ipc_enable,
@@ -769,7 +770,7 @@ static void dwmac4_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
.set_filter = dwmac4_set_filter,
};
-static const struct stmmac_ops dwmac510_ops = {
+const struct stmmac_ops dwmac510_ops = {
.core_init = dwmac4_core_init,
.set_mac = stmmac_dwmac4_set_mac,
.rx_ipc = dwmac4_rx_ipc_enable,
@@ -803,19 +804,16 @@ static void dwmac4_debug(void __iomem *ioaddr, struct stmmac_extra_stats *x,
.safety_feat_dump = dwmac5_safety_feat_dump,
};
-struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, int mcbins,
- int perfect_uc_entries, int *synopsys_id)
+int dwmac4_setup(struct stmmac_priv *priv)
{
- struct mac_device_info *mac;
- u32 hwid = readl(ioaddr + GMAC_VERSION);
+ struct mac_device_info *mac = priv->hw;
- mac = kzalloc(sizeof(const struct mac_device_info), GFP_KERNEL);
- if (!mac)
- return NULL;
+ dev_info(priv->device, "\tDWMAC4/5\n");
- mac->pcsr = ioaddr;
- mac->multicast_filter_bins = mcbins;
- mac->unicast_filter_entries = perfect_uc_entries;
+ priv->dev->priv_flags |= IFF_UNICAST_FLT;
+ mac->pcsr = priv->ioaddr;
+ mac->multicast_filter_bins = priv->plat->multicast_filter_bins;
+ mac->unicast_filter_entries = priv->plat->unicast_filter_entries;
mac->mcast_bits_log2 = 0;
if (mac->multicast_filter_bins)
@@ -835,20 +833,5 @@ struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, int mcbins,
mac->mii.clk_csr_shift = 8;
mac->mii.clk_csr_mask = GENMASK(11, 8);
- /* Get and dump the chip ID */
- *synopsys_id = stmmac_get_synopsys_id(hwid);
-
- if (*synopsys_id > DWMAC_CORE_4_00)
- mac->dma = &dwmac410_dma_ops;
- else
- mac->dma = &dwmac4_dma_ops;
-
- if (*synopsys_id >= DWMAC_CORE_5_10)
- mac->mac = &dwmac510_ops;
- else if (*synopsys_id >= DWMAC_CORE_4_00)
- mac->mac = &dwmac410_ops;
- else
- mac->mac = &dwmac4_ops;
-
- return mac;
+ return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
new file mode 100644
index 0000000..2b0a7e7
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 Synopsys, Inc. and/or its affiliates.
+ * stmmac HW Interface Handling
+ */
+
+#include "common.h"
+#include "stmmac.h"
+
+static u32 stmmac_get_id(struct stmmac_priv *priv, u32 id_reg)
+{
+ u32 reg = readl(priv->ioaddr + id_reg);
+
+ if (!reg) {
+ dev_info(priv->device, "Version ID not available\n");
+ return 0x0;
+ }
+
+ dev_info(priv->device, "User ID: 0x%x, Synopsys ID: 0x%x\n",
+ (unsigned int)(reg & GENMASK(15, 8)) >> 8,
+ (unsigned int)(reg & GENMASK(7, 0)));
+ return reg & GENMASK(7, 0);
+}
+
+static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
+{
+ struct mac_device_info *mac = priv->hw;
+
+ if (priv->chain_mode) {
+ dev_info(priv->device, "Chain mode enabled\n");
+ priv->mode = STMMAC_CHAIN_MODE;
+ mac->mode = &chain_mode_ops;
+ } else {
+ dev_info(priv->device, "Ring mode enabled\n");
+ priv->mode = STMMAC_RING_MODE;
+ mac->mode = &ring_mode_ops;
+ }
+}
+
+static int stmmac_dwmac1_quirks(struct stmmac_priv *priv)
+{
+ struct mac_device_info *mac = priv->hw;
+
+ if (priv->plat->enh_desc) {
+ dev_info(priv->device, "Enhanced/Alternate descriptors\n");
+
+ /* GMAC older than 3.50 has no extended descriptors */
+ if (priv->synopsys_id >= DWMAC_CORE_3_50) {
+ dev_info(priv->device, "Enabled extended descriptors\n");
+ priv->extend_desc = 1;
+ } else {
+ dev_warn(priv->device, "Extended descriptors not supported\n");
+ }
+
+ mac->desc = &enh_desc_ops;
+ } else {
+ dev_info(priv->device, "Normal descriptors\n");
+ mac->desc = &ndesc_ops;
+ }
+
+ stmmac_dwmac_mode_quirk(priv);
+ return 0;
+}
+
+static int stmmac_dwmac4_quirks(struct stmmac_priv *priv)
+{
+ stmmac_dwmac_mode_quirk(priv);
+ return 0;
+}
+
+static const struct stmmac_hwif_entry {
+ bool gmac;
+ bool gmac4;
+ u32 min_id;
+ const void *desc;
+ const void *dma;
+ const void *mac;
+ const void *hwtimestamp;
+ const void *mode;
+ int (*setup)(struct stmmac_priv *priv);
+ int (*quirks)(struct stmmac_priv *priv);
+} stmmac_hw[] = {
+ /* NOTE: New HW versions shall go to the end of this table */
+ {
+ .gmac = false,
+ .gmac4 = false,
+ .min_id = 0,
+ .desc = NULL,
+ .dma = &dwmac100_dma_ops,
+ .mac = &dwmac100_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = NULL,
+ .setup = dwmac100_setup,
+ .quirks = stmmac_dwmac1_quirks,
+ }, {
+ .gmac = true,
+ .gmac4 = false,
+ .min_id = 0,
+ .desc = NULL,
+ .dma = &dwmac1000_dma_ops,
+ .mac = &dwmac1000_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = NULL,
+ .setup = dwmac1000_setup,
+ .quirks = stmmac_dwmac1_quirks,
+ }, {
+ .gmac = false,
+ .gmac4 = true,
+ .min_id = 0,
+ .desc = &dwmac4_desc_ops,
+ .dma = &dwmac4_dma_ops,
+ .mac = &dwmac4_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = NULL,
+ .setup = dwmac4_setup,
+ .quirks = stmmac_dwmac4_quirks,
+ }, {
+ .gmac = false,
+ .gmac4 = true,
+ .min_id = DWMAC_CORE_4_00,
+ .desc = &dwmac4_desc_ops,
+ .dma = &dwmac4_dma_ops,
+ .mac = &dwmac410_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = &dwmac4_ring_mode_ops,
+ .setup = dwmac4_setup,
+ .quirks = NULL,
+ }, {
+ .gmac = false,
+ .gmac4 = true,
+ .min_id = DWMAC_CORE_4_10,
+ .desc = &dwmac4_desc_ops,
+ .dma = &dwmac410_dma_ops,
+ .mac = &dwmac410_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = &dwmac4_ring_mode_ops,
+ .setup = dwmac4_setup,
+ .quirks = NULL,
+ }, {
+ .gmac = false,
+ .gmac4 = true,
+ .min_id = DWMAC_CORE_5_10,
+ .desc = &dwmac4_desc_ops,
+ .dma = &dwmac410_dma_ops,
+ .mac = &dwmac510_ops,
+ .hwtimestamp = &stmmac_ptp,
+ .mode = &dwmac4_ring_mode_ops,
+ .setup = dwmac4_setup,
+ .quirks = NULL,
+ }
+};
+
+int stmmac_hwif_init(struct stmmac_priv *priv)
+{
+ bool needs_gmac4 = priv->plat->has_gmac4;
+ bool needs_gmac = priv->plat->has_gmac;
+ const struct stmmac_hwif_entry *entry;
+ struct mac_device_info *mac;
+ int i, ret;
+ u32 id;
+
+ if (needs_gmac) {
+ id = stmmac_get_id(priv, GMAC_VERSION);
+ } else {
+ id = stmmac_get_id(priv, GMAC4_VERSION);
+ }
+
+ /* Save ID for later use */
+ priv->synopsys_id = id;
+
+ /* Check for HW specific setup first */
+ if (priv->plat->setup) {
+ priv->hw = priv->plat->setup(priv);
+ if (!priv->hw)
+ return -ENOMEM;
+ return 0;
+ }
+
+ mac = devm_kzalloc(priv->device, sizeof(*mac), GFP_KERNEL);
+ if (!mac)
+ return -ENOMEM;
+
+ /* Fallback to generic HW */
+ for (i = ARRAY_SIZE(stmmac_hw) - 1; i >= 0; i--) {
+ entry = &stmmac_hw[i];
+
+ if (needs_gmac ^ entry->gmac)
+ continue;
+ if (needs_gmac4 ^ entry->gmac4)
+ continue;
+ if (id < entry->min_id)
+ continue;
+
+ mac->desc = entry->desc;
+ mac->dma = entry->dma;
+ mac->mac = entry->mac;
+ mac->ptp = entry->hwtimestamp;
+ mac->mode = entry->mode;
+
+ priv->hw = mac;
+
+ /* Entry found */
+ ret = entry->setup(priv);
+ if (ret)
+ return ret;
+
+ /* Run quirks, if needed */
+ if (entry->quirks) {
+ ret = entry->quirks(priv);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+ }
+
+ dev_err(priv->device, "Failed to find HW IF (id=0x%x, gmac=%d/%d)\n",
+ id, needs_gmac, needs_gmac4);
+ return -EINVAL;
+}
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index f81ded4..bfad616 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -418,4 +418,21 @@ struct stmmac_mode_ops {
#define stmmac_clean_desc3(__priv, __args...) \
stmmac_do_void_callback(__priv, mode, clean_desc3, __args)
+struct stmmac_priv;
+
+extern const struct stmmac_ops dwmac100_ops;
+extern const struct stmmac_dma_ops dwmac100_dma_ops;
+extern const struct stmmac_ops dwmac1000_ops;
+extern const struct stmmac_dma_ops dwmac1000_dma_ops;
+extern const struct stmmac_ops dwmac4_ops;
+extern const struct stmmac_dma_ops dwmac4_dma_ops;
+extern const struct stmmac_ops dwmac410_ops;
+extern const struct stmmac_dma_ops dwmac410_dma_ops;
+extern const struct stmmac_ops dwmac510_ops;
+
+#define GMAC_VERSION 0x00000020 /* GMAC CORE Version */
+#define GMAC4_VERSION 0x00000110 /* GMAC4+ CORE Version */
+
+int stmmac_hwif_init(struct stmmac_priv *priv);
+
#endif /* __STMMAC_HWIF_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index da50451..2443f20 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -130,6 +130,7 @@ struct stmmac_priv {
int eee_active;
int tx_lpi_timer;
unsigned int mode;
+ unsigned int chain_mode;
int extend_desc;
struct ptp_clock *ptp_clock;
struct ptp_clock_info ptp_clock_ops;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 90363a8..574924a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -769,7 +769,6 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
netdev_info(priv->dev,
"IEEE 1588-2008 Advanced Timestamp supported\n");
- priv->hw->ptp = &stmmac_ptp;
priv->hwts_tx_en = 0;
priv->hwts_rx_en = 0;
@@ -2122,32 +2121,6 @@ static void stmmac_mmc_setup(struct stmmac_priv *priv)
}
/**
- * stmmac_selec_desc_mode - to select among: normal/alternate/extend descriptors
- * @priv: driver private structure
- * Description: select the Enhanced/Alternate or Normal descriptors.
- * In case of Enhanced/Alternate, it checks if the extended descriptors are
- * supported by the HW capability register.
- */
-static void stmmac_selec_desc_mode(struct stmmac_priv *priv)
-{
- if (priv->plat->enh_desc) {
- dev_info(priv->device, "Enhanced/Alternate descriptors\n");
-
- /* GMAC older than 3.50 has no extended descriptors */
- if (priv->synopsys_id >= DWMAC_CORE_3_50) {
- dev_info(priv->device, "Enabled extended descriptors\n");
- priv->extend_desc = 1;
- } else
- dev_warn(priv->device, "Extended descriptors not supported\n");
-
- priv->hw->desc = &enh_desc_ops;
- } else {
- dev_info(priv->device, "Normal descriptors\n");
- priv->hw->desc = &ndesc_ops;
- }
-}
-
-/**
* stmmac_get_hw_features - get MAC capabilities from the HW cap. register.
* @priv: driver private structure
* Description:
@@ -4093,49 +4066,17 @@ static void stmmac_service_task(struct work_struct *work)
*/
static int stmmac_hw_init(struct stmmac_priv *priv)
{
- struct mac_device_info *mac;
-
- /* Identify the MAC HW device */
- if (priv->plat->setup) {
- mac = priv->plat->setup(priv);
- } else if (priv->plat->has_gmac) {
- priv->dev->priv_flags |= IFF_UNICAST_FLT;
- mac = dwmac1000_setup(priv->ioaddr,
- priv->plat->multicast_filter_bins,
- priv->plat->unicast_filter_entries,
- &priv->synopsys_id);
- } else if (priv->plat->has_gmac4) {
- priv->dev->priv_flags |= IFF_UNICAST_FLT;
- mac = dwmac4_setup(priv->ioaddr,
- priv->plat->multicast_filter_bins,
- priv->plat->unicast_filter_entries,
- &priv->synopsys_id);
- } else {
- mac = dwmac100_setup(priv->ioaddr, &priv->synopsys_id);
- }
- if (!mac)
- return -ENOMEM;
-
- priv->hw = mac;
+ int ret;
/* dwmac-sun8i only work in chain mode */
if (priv->plat->has_sun8i)
chain_mode = 1;
+ priv->chain_mode = chain_mode;
- /* To use the chained or ring mode */
- if (priv->synopsys_id >= DWMAC_CORE_4_00) {
- priv->hw->mode = &dwmac4_ring_mode_ops;
- } else {
- if (chain_mode) {
- priv->hw->mode = &chain_mode_ops;
- dev_info(priv->device, "Chain mode enabled\n");
- priv->mode = STMMAC_CHAIN_MODE;
- } else {
- priv->hw->mode = &ring_mode_ops;
- dev_info(priv->device, "Ring mode enabled\n");
- priv->mode = STMMAC_RING_MODE;
- }
- }
+ /* Initialize HW Interface */
+ ret = stmmac_hwif_init(priv);
+ if (ret)
+ return ret;
/* Get the HW capability (new GMAC newer than 3.50a) */
priv->hw_cap_support = stmmac_get_hw_features(priv);
@@ -4169,12 +4110,6 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
dev_info(priv->device, "No HW DMA feature register supported\n");
}
- /* To use alternate (extended), normal or GMAC4 descriptor structures */
- if (priv->synopsys_id >= DWMAC_CORE_4_00)
- priv->hw->desc = &dwmac4_desc_ops;
- else
- stmmac_selec_desc_mode(priv);
-
if (priv->plat->rx_coe) {
priv->hw->rx_csum = priv->plat->rx_coe;
dev_info(priv->device, "RX Checksum Offload Engine supported\n");
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 6/8] ASoC: sh: Update menu title and platform dependency
From: Simon Horman @ 2018-04-23 7:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel, Kuninori Morimoto, Catalin Marinas, Will Deacon,
Liam Girdwood, Laurent Pinchart, devel, Mauro Carvalho Chehab,
Vinod Koul, Magnus Damm, Russell King, linux-media, Arnd Bergmann,
Mark Brown, Dan Williams, Jaroslav Kysela, linux-arm-kernel,
Sergei Shtylyov, Greg Kroah-Hartman, Takashi Iwai, linux-kernel,
linux-renesas-soc, netdev, dmaengine
In-Reply-To: <1524230914-10175-7-git-send-email-geert+renesas@glider.be>
On Fri, Apr 20, 2018 at 03:28:32PM +0200, Geert Uytterhoeven wrote:
> Change the menu title to refer to "Renesas SoCs" instead of "SuperH", as
> both SuperH and ARM SoCs are supported.
>
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is ARCH_RENESAS a more appropriate platform dependency for Renesas ARM
> SoCs than the legacy ARCH_SHMOBILE, hence use the former.
> Renesas SuperH SH-Mobile SoCs are still covered by the SUPERH
> dependency.
>
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 5/8] staging: emxx_udc: Change platform dependency to ARCH_RENESAS
From: Simon Horman @ 2018-04-23 7:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel, Kuninori Morimoto, Catalin Marinas, Will Deacon,
Liam Girdwood, Laurent Pinchart, devel, Mauro Carvalho Chehab,
Vinod Koul, Magnus Damm, Russell King, linux-media, Arnd Bergmann,
Mark Brown, Dan Williams, linux-arm-kernel, Sergei Shtylyov,
Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-renesas-soc,
netdev, dmaengine, "David S . Miller" <davem@
In-Reply-To: <1524230914-10175-6-git-send-email-geert+renesas@glider.be>
On Fri, Apr 20, 2018 at 03:28:31PM +0200, Geert Uytterhoeven wrote:
> Emma Mobile is a Renesas ARM SoC. Since commit 9b5ba0df4ea4f940 ("ARM:
> shmobile: Introduce ARCH_RENESAS") is ARCH_RENESAS a more appropriate
> platform dependency than the legacy ARCH_SHMOBILE, hence use the
> former.
>
> This will allow to drop ARCH_SHMOBILE on ARM in the near future.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 4/8] sh_eth: Change platform check to CONFIG_ARCH_RENESAS
From: Simon Horman @ 2018-04-23 7:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel, Kuninori Morimoto, Catalin Marinas, Will Deacon,
Liam Girdwood, Laurent Pinchart, devel, Mauro Carvalho Chehab,
Vinod Koul, Magnus Damm, Russell King, linux-media, Arnd Bergmann,
Mark Brown, Dan Williams, linux-arm-kernel, Sergei Shtylyov,
Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-renesas-soc,
netdev, dmaengine, "David S . Miller" <davem@
In-Reply-To: <1524230914-10175-5-git-send-email-geert+renesas@glider.be>
On Fri, Apr 20, 2018 at 03:28:30PM +0200, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check.
>
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 3/8] [media] v4l: rcar_fdp1: Change platform dependency to ARCH_RENESAS
From: Simon Horman @ 2018-04-23 7:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel, Kuninori Morimoto, Catalin Marinas, Will Deacon,
Liam Girdwood, Laurent Pinchart, devel, Mauro Carvalho Chehab,
Vinod Koul, Magnus Damm, Russell King, linux-media, Arnd Bergmann,
Mark Brown, Dan Williams, linux-arm-kernel, Sergei Shtylyov,
Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-renesas-soc,
netdev, dmaengine, "David S . Miller" <davem@
In-Reply-To: <1524230914-10175-4-git-send-email-geert+renesas@glider.be>
On Fri, Apr 20, 2018 at 03:28:29PM +0200, Geert Uytterhoeven wrote:
> The Renesas Fine Display Processor driver is used on Renesas R-Car SoCs
> only. Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce
> ARCH_RENESAS") is ARCH_RENESAS a more appropriate platform dependency
> than the legacy ARCH_SHMOBILE, hence use the former.
>
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS
From: Simon Horman @ 2018-04-23 7:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: alsa-devel, Kuninori Morimoto, Catalin Marinas, Will Deacon,
Liam Girdwood, Laurent Pinchart, devel, Mauro Carvalho Chehab,
Vinod Koul, Magnus Damm, Russell King, linux-media, Arnd Bergmann,
Mark Brown, Dan Williams, linux-arm-kernel, Sergei Shtylyov,
Greg Kroah-Hartman, Takashi Iwai, linux-kernel, linux-renesas-soc,
netdev, dmaengine, "David S . Miller" <davem@
In-Reply-To: <1524230914-10175-3-git-send-email-geert+renesas@glider.be>
On Fri, Apr 20, 2018 at 03:28:28PM +0200, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check, just like before support for Renesas ARM SoCs was added.
>
> Instead of blindly changing all the #ifdefs, switch the main code block
> in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
> remaining #ifdefs.
>
> This will allow to drop ARCH_SHMOBILE on ARM in the near future.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 1/8] arm: shmobile: Change platform dependency to ARCH_RENESAS
From: Simon Horman @ 2018-04-23 7:50 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Geert Uytterhoeven, Magnus Damm, Russell King, Catalin Marinas,
Will Deacon, Dan Williams, Vinod Koul, Mauro Carvalho Chehab,
David S . Miller, Greg Kroah-Hartman, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Arnd Bergmann, Kuninori Morimoto,
Laurent Pinchart, linux-renesas-soc, linux-arm-kernel, dma
In-Reply-To: <44b6b9a3-5273-54f4-ee72-0d5fcc36348a@cogentembedded.com>
On Fri, Apr 20, 2018 at 05:53:18PM +0300, Sergei Shtylyov wrote:
> On 04/20/2018 04:28 PM, Geert Uytterhoeven wrote:
>
> > Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> > is ARCH_RENESAS a more appropriate platform dependency than the legacy
>
> "ARCH_RENESAS is", no?
Thanks, applied with that corrected.
>
> > ARCH_SHMOBILE, hence use the former.
> >
> > This will allow to drop ARCH_SHMOBILE on ARM in the near future.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> [...]
>
> MBR, Sergei
>
^ permalink raw reply
* Re: [PATCH 0/8] arm: renesas: Change platform dependency to ARCH_RENESAS
From: Geert Uytterhoeven @ 2018-04-23 7:45 UTC (permalink / raw)
To: Mark Brown
Cc: ALSA Development Mailing List, Kuninori Morimoto, Catalin Marinas,
Will Deacon, Liam Girdwood, Laurent Pinchart, driverdevel,
Mauro Carvalho Chehab, Geert Uytterhoeven, Vinod Koul,
Magnus Damm, Russell King, Linux Media Mailing List,
Arnd Bergmann, Simon Horman, Dan Williams, Jaroslav Kysela,
Linux ARM, Sergei Shtylyov, Greg Kroah-Hartman, Takas
In-Reply-To: <20180420164811.GC22369@sirena.org.uk>
Hi Mark,
On Fri, Apr 20, 2018 at 6:48 PM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Apr 20, 2018 at 03:28:26PM +0200, Geert Uytterhoeven wrote:
>> The first 6 patches can be applied independently by subsystem
>> maintainers.
>> The last two patches depend on the first 6 patches, and are thus marked
>> RFC.
>
> Would it not make sense to try to apply everything en masse rather than
> delaying? I'm happy to apply the subsystem stuff but if it gets things
> done quicker or more efficiently I'm also happy to have the lot merged
> as one series.
In theory, yes.
However, this touches multiple subsystems, and it's non-critical, so I don't
want to spent the energy to get this done in a synchronized way.
It's way easier to postpone the last (RFC) patches when everything else
has been applied by subsystem maintainers.
So please apply your part, thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: Move PHY statistics code into PHY library helpers
From: kbuild test robot @ 2018-04-23 7:40 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, Florian Fainelli, Andrew Lunn, Vivien Didelot,
David S. Miller, cphealy
In-Reply-To: <1524336953-26108-2-git-send-email-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Hi Florian,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Extend-availability-of-PHY-statistics/20180423-113141
config: alpha-defconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=alpha
All errors (new ones prefixed by >>):
net/core/ethtool.o: In function `__ethtool_get_sset_count':
>> (.text+0x189c): undefined reference to `phy_ethtool_get_sset_count'
(.text+0x18a0): undefined reference to `phy_ethtool_get_sset_count'
net/core/ethtool.o: In function `dev_ethtool':
(.text+0x3e2c): undefined reference to `phy_ethtool_get_sset_count'
(.text+0x3e30): undefined reference to `phy_ethtool_get_sset_count'
>> (.text+0x3ea8): undefined reference to `phy_ethtool_get_stats'
(.text+0x3eb4): undefined reference to `phy_ethtool_get_stats'
>> (.text+0x5794): undefined reference to `phy_ethtool_get_strings'
(.text+0x579c): undefined reference to `phy_ethtool_get_strings'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 11952 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: Move PHY statistics code into PHY library helpers
From: kbuild test robot @ 2018-04-23 7:40 UTC (permalink / raw)
To: Florian Fainelli
Cc: kbuild-all, netdev, Florian Fainelli, Andrew Lunn, Vivien Didelot,
David S. Miller, cphealy
In-Reply-To: <1524336953-26108-2-git-send-email-f.fainelli@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]
Hi Florian,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-Extend-availability-of-PHY-statistics/20180423-113141
config: parisc-c3000_defconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc
All errors (new ones prefixed by >>):
net/core/ethtool.o: In function `__ethtool_get_sset_count':
>> (.text.__ethtool_get_sset_count+0x74): undefined reference to `phy_ethtool_get_sset_count'
net/core/ethtool.o: In function `.L901':
>> (.text.dev_ethtool+0x10bc): undefined reference to `phy_ethtool_get_sset_count'
>> (.text.dev_ethtool+0x1114): undefined reference to `phy_ethtool_get_stats'
net/core/ethtool.o: In function `.L806':
>> (.text.dev_ethtool+0x2200): undefined reference to `phy_ethtool_get_strings'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 14302 bytes --]
^ permalink raw reply
* [PATCH v2] net: phy: marvell: clear wol event before setting it
From: Jisheng Zhang @ 2018-04-23 7:22 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David S. Miller, Bhadram Varka
Cc: netdev, linux-kernel, Jingju Hou
From: Jingju Hou <Jingju.Hou@synaptics.com>
If WOL event happened once, the LED[2] interrupt pin will not be
cleared unless we read the CSISR register. If interrupts are in use,
the normal interrupt handling will clear the WOL event. Let's clear the
WOL event before enabling it if !phy_interrupt_is_valid().
Signed-off-by: Jingju Hou <Jingju.Hou@synaptics.com>
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
Since v1:
- reuse MII_M1011_IEVENT, suggested by Bhadram Varka
- make read conditional on !phy_interrupt_is_valid(), suggested by
Andrew
drivers/net/phy/marvell.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index c22e8e383247..25e2a099b71c 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1393,6 +1393,15 @@ static int m88e1318_set_wol(struct phy_device *phydev,
if (err < 0)
goto error;
+ /* If WOL event happened once, the LED[2] interrupt pin
+ * will not be cleared unless we reading the interrupt status
+ * register. If interrupts are in use, the normal interrupt
+ * handling will clear the WOL event. Clear the WOL event
+ * before enabling it if !phy_interrupt_is_valid()
+ */
+ if (!phy_interrupt_is_valid(phydev))
+ phy_read(phydev, MII_M1011_IEVENT);
+
/* Enable the WOL interrupt */
err = __phy_modify(phydev, MII_88E1318S_PHY_CSIER, 0,
MII_88E1318S_PHY_CSIER_WOL_EIE);
--
2.17.0
^ permalink raw reply related
* [PATCH 2/3] tools bpf: Sync bpf.h uapi header
From: Jiri Olsa @ 2018-04-23 6:59 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann; +Cc: lkml, netdev, Quentin Monnet
In-Reply-To: <20180423065927.23127-1-jolsa@kernel.org>
Syncing the bpf.h uapi header with tools.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/include/uapi/linux/bpf.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 7f7fbb9d0253..b7298ee177e7 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -239,6 +239,8 @@ enum bpf_attach_type {
#define BPF_OBJ_NAME_LEN 16U
+#define BPF_OBJ_LICENSE_LEN 128U
+
/* Flags for accessing BPF object */
#define BPF_F_RDONLY (1U << 3)
#define BPF_F_WRONLY (1U << 4)
@@ -884,6 +886,7 @@ enum bpf_func_id {
/* BPF_FUNC_skb_set_tunnel_key flags. */
#define BPF_F_ZERO_CSUM_TX (1ULL << 1)
#define BPF_F_DONT_FRAGMENT (1ULL << 2)
+#define BPF_F_SEQ_NUMBER (1ULL << 3)
/* BPF_FUNC_perf_event_output, BPF_FUNC_perf_event_read and
* BPF_FUNC_perf_event_read_value flags.
@@ -1038,6 +1041,7 @@ struct bpf_prog_info {
__u32 ifindex;
__u64 netns_dev;
__u64 netns_ino;
+ char license[BPF_OBJ_LICENSE_LEN];
} __attribute__((aligned(8)));
struct bpf_map_info {
--
2.13.6
^ 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