* Re: [PATCH v2] rhashtable: make walk safe from softirq context
From: Johannes Berg @ 2019-02-12 19:03 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, j, tgraf, herbert, Bob Copeland
In-Reply-To: <20190212.104339.1794719792249723582.davem@davemloft.net>
On Tue, 2019-02-12 at 10:43 -0800, David Miller wrote:
> Herbert and Johannes, I need some guidance.
>
> It seems Herbert wants the softirq usage of rhashtables removed,
Well, specifically of rhashtable walkers. I can only concede that he's
right in that a hashtable walk during softirq (or even with softirqs
disabled) was maybe a bad idea.
At the same time, it's likely going to be pretty deep surgery in this
code, and I'm not sure I can do that right now. Maybe Bob has some
thoughts if it can be achieved more easily, but I think it'd require
adding a new list to each station that tracks which mesh paths it is the
next_hop for, and making sure that's maintained correctly, which feels
tricky but maybe it's not (I could be more familiar with mesh ...)
Evidently this goes back to
commit 60854fd94573f0d3b80b55b40cf0140a0430f3ab
Author: Bob Copeland <me@bobcopeland.com>
Date: Wed Mar 2 10:09:20 2016 -0500
mac80211: mesh: convert path table to rhashtable
which is kinda old. Not sure why this didn't surface before, because the
spinlock was introduced *before*, otherwise certainly the mutex would've
caused us to not be able to do this code to start with (commit
c6ff5268293 - rhashtable: Fix walker list corruption).
That commit also just converted an existing hashtable walk to
rhashtable, so not sure that counts as having introduced the problem :-)
I guess that's not really guidance. If it were my call I'd apply the
patch and issue a stern warning to myself to remove this ASAP ;-) But
sadly, mesh isn't exactly a priority to most, so not sure when that "P"
would be.
But I guess we should also ask Bob first:
1) do you think it'd be easy to maintain a separate list or avoid the
iteration in some otherway, and make that a small enough patch to be
applicable for stable?
2) or do you think maybe the mesh_plink_broken() call could just be
lifted into a workqueue instead?
johannes
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: phy: Add 2.5G/5GBASET PHYs support
From: David Miller @ 2019-02-12 19:03 UTC (permalink / raw)
To: maxime.chevallier
Cc: netdev, linux-kernel, andrew, f.fainelli, hkallweit1, linux,
linux-arm-kernel, antoine.tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190211142529.22885-1-maxime.chevallier@bootlin.com>
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: Mon, 11 Feb 2019 15:25:25 +0100
> The 802.3bz standard defines 2 modes based on the NBASET alliance work
> that allow to use 2.5Gbps and 5Gbps speeds on Cat 5e, 6 and 7 cables.
>
> This series adds the necessary infrastructure to handle these modes with
> C45 PHYs. This series was originally part of a bigger one, that has
> seen 2 iterations [1] [2] that added support for these modes on Marvell
> Alaska PHYs.
...
I'll give Andrew, Florian, and Heiner a chance to review this series.
^ permalink raw reply
* [PATCH net] net: phy: fix interrupt handling in non-started states
From: Heiner Kallweit @ 2019-02-12 18:56 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller
Cc: netdev@vger.kernel.org, Russell King - ARM Linux
phylib enables interrupts before phy_start() has been called, and if
we receive an interrupt in a non-started state, the interrupt handler
returns IRQ_NONE. This causes problems with at least one Marvell chip
as reported by Andrew.
Fix this by handling interrupts the same as in phy_mac_interrupt(),
basically always running the phylib state machine. It knows when it
has to do something and when not.
This change allows to handle interrupts gracefully even if they
occur in a non-started state.
Fixes: 2b3e88ea6528 ("net: phy: improve phy state checking")
Reported-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 189cd2048c3a..ca5e0c0f018c 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -762,9 +762,6 @@ static irqreturn_t phy_interrupt(int irq, void *phy_dat)
{
struct phy_device *phydev = phy_dat;
- if (!phy_is_started(phydev))
- return IRQ_NONE; /* It can't be ours. */
-
if (phydev->drv->did_interrupt && !phydev->drv->did_interrupt(phydev))
return IRQ_NONE;
--
2.20.1
^ permalink raw reply related
* KASAN: use-after-free Read in rt_cache_valid
From: syzbot @ 2019-02-12 18:53 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: aa0c38cf39de Merge branch 'fixes' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1460eca7400000
kernel config: https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
dashboard link: https://syzkaller.appspot.com/bug?extid=c4c4b2bb358bb936ad7e
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1197cb88c00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c4c4b2bb358bb936ad7e@syzkaller.appspotmail.com
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
==================================================================
BUG: KASAN: use-after-free in rt_cache_valid+0x158/0x190
net/ipv4/route.c:1510
Read of size 2 at addr ffff88809bfce836 by task udevd/7435
CPU: 1 PID: 7435 Comm: udevd Not tainted 5.0.0-rc6+ #69
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load2_noabort+0x14/0x20 mm/kasan/generic_report.c:133
rt_cache_valid+0x158/0x190 net/ipv4/route.c:1510
__mkroute_output net/ipv4/route.c:2260 [inline]
ip_route_output_key_hash_rcu+0x89d/0x30e0 net/ipv4/route.c:2492
Enabling of bearer <udp:syz1> rejected, already enabled
ip_route_output_key_hash+0x212/0x380 net/ipv4/route.c:2321
Enabling of bearer <udp:syz1> rejected, already enabled
__ip_route_output_key include/net/route.h:124 [inline]
ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2576
ip_route_output_key include/net/route.h:134 [inline]
tipc_udp_xmit.isra.0+0x55d/0xcc0 net/tipc/udp_media.c:173
Enabling of bearer <udp:syz1> rejected, already enabled
tipc_udp_send_msg+0x295/0x4a0 net/tipc/udp_media.c:247
tipc_bearer_xmit_skb+0x172/0x360 net/tipc/bearer.c:503
Enabling of bearer <udp:syz1> rejected, already enabled
tipc_disc_timeout+0x933/0xd60 net/tipc/discover.c:332
call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
Enabling of bearer <udp:syz1> rejected, already enabled
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers kernel/time/timer.c:1681 [inline]
__run_timers kernel/time/timer.c:1649 [inline]
run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
Enabling of bearer <udp:syz1> rejected, already enabled
__do_softirq+0x266/0x95a kernel/softirq.c:292
Enabling of bearer <udp:syz1> rejected, already enabled
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x180/0x1d0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
</IRQ>
Enabling of bearer <udp:syz1> rejected, already enabled
RIP: 0010:generic_fillattr+0x54c/0x6e0 fs/stat.c:51
Code: 7c 24 0c 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03
38 d0 7c 08 84 d2 0f 85 ee 00 00 00 45 8b 64 24 0c 31 ff <41> 81 e4 00 08
00 00 44 89 e6 e8 15 21 bf ff 45 85 e4 74 2c e8 8b
RSP: 0018:ffff88809894fc58 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000007 RBX: ffff88809894fde8 RCX: ffffffff81b0c113
RDX: 0000000000000000 RSI: ffffffff81b0c146 RDI: 0000000000000000
RBP: ffff88809894fc78 R08: ffff8880925de340 R09: ffff88809894fde8
R10: ffffed1013129fcd R11: ffff88809894fe6f R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000800 R15: ffff888098d4d100
vfs_getattr_nosec+0x140/0x180 fs/stat.c:82
vfs_getattr+0x4b/0x70 fs/stat.c:116
Enabling of bearer <udp:syz1> rejected, already enabled
vfs_statx+0x157/0x200 fs/stat.c:189
Enabling of bearer <udp:syz1> rejected, already enabled
vfs_stat include/linux/fs.h:3171 [inline]
__do_sys_newstat+0xa4/0x130 fs/stat.c:339
Enabling of bearer <udp:syz1> rejected, already enabled
Enabling of bearer <udp:syz1> rejected, already enabled
kobject: 'loop0' (000000003275aa21): kobject_uevent_env
__se_sys_newstat fs/stat.c:335 [inline]
__x64_sys_newstat+0x54/0x80 fs/stat.c:335
kobject: 'loop0' (000000003275aa21): fill_kobj_path: path
= '/devices/virtual/block/loop0'
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7fda7f482c65
Code: 00 00 00 e8 5d 01 00 00 48 83 c4 18 c3 90 90 90 90 90 90 90 90 83 ff
01 48 89 f0 77 18 48 89 c7 48 89 d6 b8 04 00 00 00 0f 05 <48> 3d 00 f0 ff
ff 77 17 f3 c3 90 48 8b 05 a1 51 2b 00 64 c7 00 16
RSP: 002b:00007ffefd39a338 EFLAGS: 00000246 ORIG_RAX: 0000000000000004
Enabling of bearer <udp:syz1> rejected, already enabled
RAX: ffffffffffffffda RBX: 00007ffefd39a3d0 RCX: 00007fda7f482c65
RDX: 00007ffefd39a340 RSI: 00007ffefd39a340 RDI: 00007ffefd39a3d0
RBP: 0000000001125980 R08: 00007ffefd39a3e0 R09: 00007fda7f4d9790
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000001114250
R13: 0000000000000000 R14: 00007ffefd39a840 R15: 0000000000000001
Enabling of bearer <udp:syz1> rejected, already enabled
Allocated by task 7724:
save_stack+0x45/0xd0 mm/kasan/common.c:73
kobject: 'loop0' (000000003275aa21): kobject_uevent_env
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc mm/kasan/common.c:496 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
kobject: 'loop0' (000000003275aa21): fill_kobj_path: path
= '/devices/virtual/block/loop0'
kasan_kmalloc mm/kasan/common.c:504 [inline]
kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:411
Enabling of bearer <udp:syz1> rejected, already enabled
kmem_cache_alloc+0x12d/0x710 mm/slab.c:3543
dst_alloc+0x10e/0x1d0 net/core/dst.c:105
rt_dst_alloc+0x83/0x3f0 net/ipv4/route.c:1566
__mkroute_output net/ipv4/route.c:2265 [inline]
ip_route_output_key_hash_rcu+0x97d/0x30e0 net/ipv4/route.c:2492
Enabling of bearer <udp:syz1> rejected, already enabled
ip_route_output_key_hash+0x212/0x380 net/ipv4/route.c:2321
__ip_route_output_key include/net/route.h:124 [inline]
ip_route_connect include/net/route.h:302 [inline]
__ip4_datagram_connect+0x6fb/0x1330 net/ipv4/datagram.c:51
__ip6_datagram_connect+0xa6a/0x1390 net/ipv6/datagram.c:152
kobject: 'loop0' (000000003275aa21): kobject_uevent_env
ip6_datagram_connect+0x30/0x50 net/ipv6/datagram.c:273
inet_dgram_connect+0x150/0x2e0 net/ipv4/af_inet.c:571
__sys_connect+0x266/0x330 net/socket.c:1662
__do_sys_connect net/socket.c:1673 [inline]
__se_sys_connect net/socket.c:1670 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1670
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
kobject: 'loop0' (000000003275aa21): fill_kobj_path: path
= '/devices/virtual/block/loop0'
Freed by task 0:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
__cache_free mm/slab.c:3487 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3749
dst_destroy+0x2a0/0x3c0 net/core/dst.c:141
dst_destroy_rcu+0x16/0x19 net/core/dst.c:154
__rcu_reclaim kernel/rcu/rcu.h:240 [inline]
rcu_do_batch kernel/rcu/tree.c:2452 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2773 [inline]
rcu_process_callbacks+0x928/0x1390 kernel/rcu/tree.c:2754
cgroup: fork rejected by pids controller in /syz0
__do_softirq+0x266/0x95a kernel/softirq.c:292
The buggy address belongs to the object at ffff88809bfce800
which belongs to the cache ip_dst_cache of size 160
The buggy address is located 54 bytes inside of
160-byte region [ffff88809bfce800, ffff88809bfce8a0)
The buggy address belongs to the page:
page:ffffea00026ff380 count:1 mapcount:0 mapping:ffff88821af8d1c0 index:0x0
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea000297e848 ffff8880a68abd48 ffff88821af8d1c0
raw: 0000000000000000 ffff88809bfce000 0000000100000010 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88809bfce700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88809bfce780: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88809bfce800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88809bfce880: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
ffff88809bfce900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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 net-next 3/4] mlxsw: spectrum_flower: Fix VLAN modify action support
From: Pablo Neira Ayuso @ 2019-02-12 18:49 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev@vger.kernel.org, davem@davemloft.net, Jiri Pirko,
Nir Dotan, mlxsw
In-Reply-To: <20190212162924.29777-4-idosch@mellanox.com>
On Tue, Feb 12, 2019 at 04:29:53PM +0000, Ido Schimmel wrote:
> The driver does not support VLAN push and pop, but only VLAN modify.
>
> Fixes: 738678817573 ("drivers: net: use flow action infrastructure")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
> Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
^ permalink raw reply
* Re: [PATCH v2] rhashtable: make walk safe from softirq context
From: David Miller @ 2019-02-12 18:43 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, j, tgraf, herbert, johannes.berg
In-Reply-To: <20190206090721.8001-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 6 Feb 2019 10:07:21 +0100
> From: Johannes Berg <johannes.berg@intel.com>
>
> When an rhashtable walk is done from softirq context, we rightfully
> get a lockdep complaint saying that we could get a softirq in the
> middle of a rehash, and thus deadlock on &ht->lock. This happened
> e.g. in mac80211 as it does a walk in softirq context.
>
> Fix this by using spin_lock_bh() wherever we use the &ht->lock.
>
> Initially, I thought it would be sufficient to do this only in the
> rehash (rhashtable_rehash_table), but I changed my mind:
> * the caller doesn't really need to disable softirqs across all
> of the rhashtable_walk_* functions, only those parts that they
> actually do within the lock need it
> * maybe more importantly, it would still lead to massive lockdep
> complaints - false positives, but hard to fix - because lockdep
> wouldn't know about different ht->lock instances, and thus one
> user of the code doing a walk w/o any locking (when it only ever
> uses process context this is fine) vs. another user like in wifi
> where we noticed this problem would still cause it to complain.
>
> Cc: stable@vger.kernel.org
> Reported-by: Jouni Malinen <j@w1.fi>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Herbert and Johannes, I need some guidance.
It seems Herbert wants the softirq usage of rhashtables removed, but
since things have been like this for so long that's not the most
reasonable requirement if we can fix it more simply with Johannes's
patch especially for -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net] dsa: mv88e6xxx: Ensure all pending interrupts are handled prior to exit
From: Heiner Kallweit @ 2019-02-12 18:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: John David Anglin, Russell King, Vivien Didelot, Florian Fainelli,
netdev
In-Reply-To: <20190212125644.GA7527@lunn.ch>
On 12.02.2019 13:56, Andrew Lunn wrote:
> On Tue, Feb 12, 2019 at 07:51:05AM +0100, Heiner Kallweit wrote:
>> On 12.02.2019 04:58, Andrew Lunn wrote:
>>>>> Hi David
>>>>>
>>>>> I just tested this on one of my boards. It loops endlessly:
>>>>>
>>>>> [ 47.173396] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>> [ 47.182108] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>> [ 47.190820] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>> [ 47.199535] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>> [ 47.208254] mv88e6xxx_g1_irq_thread_work: c881 a8 80
>>>>>
>>>>> These are reg, ctl1, reg & ctl1.
>>>>>
>>>>> So there is an unhandled device interrupt.
>>>
>>> Hi Heiner
>>>
>>> Your patch Fixes: 2b3e88ea6528 ("net: phy: improve phy state
>>> checking") is causing me problems with interrupts for the Marvell
>>> switches.
>>>
>> Hi Andrew,
>>
>> what kernel version is it?
>
> It is a little bit old, 5.0-rc1 net-next. I should rebase and
> retest. I'm testing on a ZII board which is not fully in mainline So i
> need some patches.
>
Thanks, Andrew. Indeed 5.0 needs a fix, as also pointed out by Russell.
I think I will simply remove the following:
if (!phy_is_started(phydev))
return IRQ_NONE;
Then we basically do the same like phy_mac_interrupt(), we always run
the state machine. If it has nothing to do, then it does nothing.
Therefore also state HALTED doesn't need a special handling.
This way we handle interrupts (incl. spurious ones) gracefully.
>> And the PHY driver in use is "Marvell 88E6390" ?
>
> Yes, the marvell 1G driver.
>
> Andrew
> .
>
Heiner
^ permalink raw reply
* Re: [PATCH net-next v4 00/17] Refactor classifier API to work with chain/classifiers without rtnl lock
From: David Miller @ 2019-02-12 18:42 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, ast, daniel
In-Reply-To: <20190211085548.7190-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 11 Feb 2019 10:55:31 +0200
> Currently, all netlink protocol handlers for updating rules, actions and
> qdiscs are protected with single global rtnl lock which removes any
> possibility for parallelism. This patch set is a third step to remove
> rtnl lock dependency from TC rules update path.
...
I have to say, this stuff is very ambitious. Thanks for working on this.
Series applied, thanks Vlad.
^ permalink raw reply
* Re: [PATCH v2] net/packet: fix 4gb buffer limit due to overflow check
From: David Miller @ 2019-02-12 18:38 UTC (permalink / raw)
To: kal.conley
Cc: willemb, edumazet, alexander.h.duyck, jeffrey.t.kirsher, ktkhai,
vincent.whitchurch, lirongqing, magnus.karlsson, netdev,
linux-kernel
In-Reply-To: <20190210085712.31622-1-kal.conley@dectris.com>
From: Kal Conley <kal.conley@dectris.com>
Date: Sun, 10 Feb 2019 09:57:11 +0100
> When calculating rb->frames_per_block * req->tp_block_nr the result
> can overflow. Check it for overflow without limiting the total buffer
> size to UINT_MAX.
>
> This change fixes support for packet ring buffers >= UINT_MAX.
>
> Fixes: 8f8d28e4d6d8 ("net/packet: fix overflow in check for tp_frame_nr")
> Signed-off-by: Kal Conley <kal.conley@dectris.com>
> ---
> Changes in v2:
> - Add Signed-off-by and Fixes tag
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] inet_diag: fix reporting cgroup classid and fallback to priority
From: David Miller @ 2019-02-12 18:37 UTC (permalink / raw)
To: khlebnikov; +Cc: netdev, linux-kernel, sashal, linux-sctp
In-Reply-To: <154970855279.305165.13649851988934332761.stgit@buzz>
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Date: Sat, 09 Feb 2019 13:35:52 +0300
> Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
> extensions has only 8 bits. Thus extensions starting from DCTCPINFO
> cannot be requested directly. Some of them included into response
> unconditionally or hook into some of lower 8 bits.
>
> Extension INET_DIAG_CLASS_ID has not way to request from the beginning.
>
> This patch bundle it with INET_DIAG_TCLASS (ipv6 tos), fixes space
> reservation, and documents behavior for other extensions.
>
> Also this patch adds fallback to reporting socket priority. This filed
> is more widely used for traffic classification because ipv4 sockets
> automatically maps TOS to priority and default qdisc pfifo_fast knows
> about that. But priority could be changed via setsockopt SO_PRIORITY so
> INET_DIAG_TOS isn't enough for predicting class.
>
> Also cgroup2 obsoletes net_cls classid (it always zero), but we cannot
> reuse this field for reporting cgroup2 id because it is 64-bit (ino+gen).
>
> So, after this patch INET_DIAG_CLASS_ID will report socket priority
> for most common setup when net_cls isn't set and/or cgroup2 in use.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Fixes: 0888e372c37f ("net: inet: diag: expose sockets cgroup classid")
Applied, and queued up for -stable.
Please always put the Fixes: tag first in the list of tags. I fixed
it up for you this time.
Thanks.
^ permalink raw reply
* Re: [PATCH net] batman-adv: fix uninit-value in batadv_interface_tx()
From: David Miller @ 2019-02-12 18:31 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, syzkaller
In-Reply-To: <20190211224122.122242-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 11 Feb 2019 14:41:22 -0800
> KMSAN reported batadv_interface_tx() was possibly using a
> garbage value [1]
>
> batadv_get_vid() does have a pskb_may_pull() call
> but batadv_interface_tx() does not actually make sure
> this did not fail.
...
> Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] isdn: i4l: isdn_tty: Mark expected switch fall-through
From: David Miller @ 2019-02-12 18:29 UTC (permalink / raw)
To: gustavo; +Cc: isdn, netdev, linux-kernel, keescook
In-Reply-To: <20190211223821.GA13158@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 11 Feb 2019 16:38:21 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/isdn/i4l/isdn_tty.c: In function ‘isdn_tty_edit_at’:
> drivers/isdn/i4l/isdn_tty.c:3644:18: warning: this statement may fall through [-Wimplicit-fallthrough=]
> m->mdmcmdl = 0;
> ~~~~~~~~~~~^~~
> drivers/isdn/i4l/isdn_tty.c:3646:5: note: here
> case 0:
> ^~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH] isdn_v110: mark expected switch fall-through
From: David Miller @ 2019-02-12 18:29 UTC (permalink / raw)
To: gustavo; +Cc: isdn, netdev, linux-kernel, keescook
In-Reply-To: <20190211224237.GA29262@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 11 Feb 2019 16:42:37 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/isdn/i4l/isdn_v110.c: In function ‘EncodeMatrix’:
> drivers/isdn/i4l/isdn_v110.c:353:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
> if (line >= mlen) {
> ^
> drivers/isdn/i4l/isdn_v110.c:358:3: note: here
> case 128:
> ^~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ser_gigaset: mark expected switch fall-through
From: David Miller @ 2019-02-12 18:29 UTC (permalink / raw)
To: gustavo; +Cc: pebolle, isdn, gigaset307x-common, netdev, linux-kernel, keescook
In-Reply-To: <20190211223444.GA29517@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 11 Feb 2019 16:34:44 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/isdn/gigaset/ser-gigaset.c: In function ‘gigaset_tty_ioctl’:
> drivers/isdn/gigaset/ser-gigaset.c:627:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
> switch (arg) {
> ^~~~~~
> drivers/isdn/gigaset/ser-gigaset.c:638:2: note: here
> default:
> ^~~~~~~
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* [PATCH] rpc: properly check debugfs dentry before using it
From: Greg Kroah-Hartman @ 2019-02-12 18:27 UTC (permalink / raw)
To: J. Bruce Fields, Jeff Layton, Trond Myklebust, Anna Schumaker
Cc: linux-nfs, netdev, David Howells
debugfs can now report an error code if something went wrong instead of
just NULL. So if the return value is to be used as a "real" dentry, it
needs to be checked if it is an error before dereferencing it.
This is now happening because of ff9fb72bc077 ("debugfs: return error
values, not NULL"), but why debugfs files are not being created properly
is an older issue, probably one that has always been there and should
probably be looked at...
Cc: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@kernel.org>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna.schumaker@netapp.com>
Cc: linux-nfs@vger.kernel.org
Cc: netdev@vger.kernel.org
Reported-by: David Howells <dhowells@redhat.com>
Tested-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sunrpc/debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I can take this through my tree if people don't object, or it can go
through the NFS tree. It does need to get merged before 5.0-final
though.
I also have a "larger" debugfs cleanup patch for this file, but that's
not really 5.0-final material and I will send it out later.
thanks,
greg k-h
diff --git a/net/sunrpc/debugfs.c b/net/sunrpc/debugfs.c
index 45a033329cd4..19bb356230ed 100644
--- a/net/sunrpc/debugfs.c
+++ b/net/sunrpc/debugfs.c
@@ -146,7 +146,7 @@ rpc_clnt_debugfs_register(struct rpc_clnt *clnt)
rcu_read_lock();
xprt = rcu_dereference(clnt->cl_xprt);
/* no "debugfs" dentry? Don't bother with the symlink. */
- if (!xprt->debugfs) {
+ if (IS_ERR_OR_NULL(xprt->debugfs)) {
rcu_read_unlock();
return;
}
^ permalink raw reply related
* Re: [net-next PATCH V2 1/3] mm: add dma_addr_t to struct page
From: Florian Fainelli @ 2019-02-12 18:23 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, linux-mm, Toke Høiland-Jørgensen,
Ilias Apalodimas, willy, Saeed Mahameed, Alexander Duyck,
Andrew Morton, mgorman, David S. Miller, Tariq Toukan
In-Reply-To: <20190212191917.2ef91a88@carbon>
On 2/12/19 10:19 AM, Jesper Dangaard Brouer wrote:
> On Tue, 12 Feb 2019 10:05:39 -0800
> Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> On 2/12/19 6:49 AM, Jesper Dangaard Brouer wrote:
>>> The page_pool API is using page->private to store DMA addresses.
>>> As pointed out by David Miller we can't use that on 32-bit architectures
>>> with 64-bit DMA
>>>
>>> This patch adds a new dma_addr_t struct to allow storing DMA addresses
>>>
>>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
>>> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>>> Acked-by: Andrew Morton <akpm@linux-foundation.org>
>>> ---
>>> include/linux/mm_types.h | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>>> index 2c471a2c43fa..581737bd0878 100644
>>> --- a/include/linux/mm_types.h
>>> +++ b/include/linux/mm_types.h
>>> @@ -95,6 +95,13 @@ struct page {
>>> */
>>> unsigned long private;
>>> };
>>> + struct { /* page_pool used by netstack */
>>> + /**
>>> + * @dma_addr: page_pool requires a 64-bit value even on
>>> + * 32-bit architectures.
>>> + */
>>
>> Nit: might require? dma_addr_t, as you mention in the commit may have a
>> different size based on CONFIG_ARCH_DMA_ADDR_T_64BIT.
>
> So you want me to change the comment to be:
>
> /**
> * @dma_addr: might require a 64-bit value even on
> * 32-bit architectures.
> */
>
> Correctly understood?
Correct, that is what I would change. The commit message is correct, but
the comment makes it sound like dma_addr_t is guaranteed to be 64-bit,
while it is actually platform dependent. Does that make it clearer?
--
Florian
^ permalink raw reply
* Re: [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t
From: Ilias Apalodimas @ 2019-02-12 18:20 UTC (permalink / raw)
To: Alexander Duyck
Cc: Eric Dumazet, Tariq Toukan, Matthew Wilcox, brouer@redhat.com,
David Miller, toke@redhat.com, netdev@vger.kernel.org,
mgorman@techsingularity.net, linux-mm@kvack.org
In-Reply-To: <CAKgT0UfG08aYoN=zO_aVyx+OgNPmN9pVkBNeZMPTF2KL7XqoBQ@mail.gmail.com>
Hi Alexander,
On Tue, Feb 12, 2019 at 10:13:30AM -0800, Alexander Duyck wrote:
> On Tue, Feb 12, 2019 at 7:16 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >
> >
> > On 02/12/2019 04:39 AM, Tariq Toukan wrote:
> > >
> > >
> > > On 2/11/2019 7:14 PM, Eric Dumazet wrote:
> > >>
> > >>
> > >> On 02/11/2019 12:53 AM, Tariq Toukan wrote:
> > >>>
> > >>
> > >>> Hi,
> > >>>
> > >>> It's great to use the struct page to store its dma mapping, but I am
> > >>> worried about extensibility.
> > >>> page_pool is evolving, and it would need several more per-page fields.
> > >>> One of them would be pageref_bias, a planned optimization to reduce the
> > >>> number of the costly atomic pageref operations (and replace existing
> > >>> code in several drivers).
> > >>>
> > >>
> > >> But the point about pageref_bias is to place it in a different cache line than "struct page"
> > >>
> > >> The major cost is having a cache line bouncing between producer and consumer.
> > >>
> > >
> > > pageref_bias is meant to be dirtied only by the page requester, i.e. the
> > > NIC driver / page_pool.
> > > All other components (basically, SKB release flow / put_page) should
> > > continue working with the atomic page_refcnt, and not dirty the
> > > pageref_bias.
> >
> > This is exactly my point.
> >
> > You suggested to put pageref_bias in struct page, which breaks this completely.
> >
> > pageref_bias is better kept in a driver structure, with appropriate prefetching
> > since most NIC use a ring buffer for their queues.
> >
> > The dma address _can_ be put in the struct page, since the driver does not dirty it
> > and does not even read it when page can be recycled.
>
> Instead of maintaining the pageref_bias in the page itself it could be
> maintained in some sort of separate structure. You could just maintain
> a pointer to a slot in an array somewhere. Then you can still access
> it if needed, the pointer would be static for as long as it is in the
> page pool, and you could invalidate the pointer prior to removing the
> bias from the page.
I think that's what Tariq was suggesting in the first place.
/Ilias
^ permalink raw reply
* Re: [net-next PATCH V2 1/3] mm: add dma_addr_t to struct page
From: Jesper Dangaard Brouer @ 2019-02-12 18:19 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, linux-mm, Toke Høiland-Jørgensen,
Ilias Apalodimas, willy, Saeed Mahameed, Alexander Duyck,
Andrew Morton, mgorman, David S. Miller, Tariq Toukan, brouer
In-Reply-To: <dc34bb0b-1efd-4200-2ee7-bf8adef8a0b5@gmail.com>
On Tue, 12 Feb 2019 10:05:39 -0800
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 2/12/19 6:49 AM, Jesper Dangaard Brouer wrote:
> > The page_pool API is using page->private to store DMA addresses.
> > As pointed out by David Miller we can't use that on 32-bit architectures
> > with 64-bit DMA
> >
> > This patch adds a new dma_addr_t struct to allow storing DMA addresses
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > Acked-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> > include/linux/mm_types.h | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 2c471a2c43fa..581737bd0878 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -95,6 +95,13 @@ struct page {
> > */
> > unsigned long private;
> > };
> > + struct { /* page_pool used by netstack */
> > + /**
> > + * @dma_addr: page_pool requires a 64-bit value even on
> > + * 32-bit architectures.
> > + */
>
> Nit: might require? dma_addr_t, as you mention in the commit may have a
> different size based on CONFIG_ARCH_DMA_ADDR_T_64BIT.
So you want me to change the comment to be:
/**
* @dma_addr: might require a 64-bit value even on
* 32-bit architectures.
*/
Correctly understood?
--
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-next 00/10] s390/qeth: updates 2019-02-12
From: David Miller @ 2019-02-12 18:14 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20190212173325.36555-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Tue, 12 Feb 2019 18:33:15 +0100
> please apply one more round of qeth patches to net-next. This
> series targets the driver's control paths. It primarily brings
> improvements to the error handling for sent cmds and received
> responses, along with the usual cleanup and consolidation efforts.
Series applied, thanks.
^ permalink raw reply
* Re: [RFC, PATCH] net: page_pool: Don't use page->private to store dma_addr_t
From: Alexander Duyck @ 2019-02-12 18:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tariq Toukan, Ilias Apalodimas, Matthew Wilcox, brouer@redhat.com,
David Miller, toke@redhat.com, netdev@vger.kernel.org,
mgorman@techsingularity.net, linux-mm@kvack.org
In-Reply-To: <d8fa6786-c252-6bb0-409f-42ce18127cb3@gmail.com>
On Tue, Feb 12, 2019 at 7:16 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 02/12/2019 04:39 AM, Tariq Toukan wrote:
> >
> >
> > On 2/11/2019 7:14 PM, Eric Dumazet wrote:
> >>
> >>
> >> On 02/11/2019 12:53 AM, Tariq Toukan wrote:
> >>>
> >>
> >>> Hi,
> >>>
> >>> It's great to use the struct page to store its dma mapping, but I am
> >>> worried about extensibility.
> >>> page_pool is evolving, and it would need several more per-page fields.
> >>> One of them would be pageref_bias, a planned optimization to reduce the
> >>> number of the costly atomic pageref operations (and replace existing
> >>> code in several drivers).
> >>>
> >>
> >> But the point about pageref_bias is to place it in a different cache line than "struct page"
> >>
> >> The major cost is having a cache line bouncing between producer and consumer.
> >>
> >
> > pageref_bias is meant to be dirtied only by the page requester, i.e. the
> > NIC driver / page_pool.
> > All other components (basically, SKB release flow / put_page) should
> > continue working with the atomic page_refcnt, and not dirty the
> > pageref_bias.
>
> This is exactly my point.
>
> You suggested to put pageref_bias in struct page, which breaks this completely.
>
> pageref_bias is better kept in a driver structure, with appropriate prefetching
> since most NIC use a ring buffer for their queues.
>
> The dma address _can_ be put in the struct page, since the driver does not dirty it
> and does not even read it when page can be recycled.
Instead of maintaining the pageref_bias in the page itself it could be
maintained in some sort of separate structure. You could just maintain
a pointer to a slot in an array somewhere. Then you can still access
it if needed, the pointer would be static for as long as it is in the
page pool, and you could invalidate the pointer prior to removing the
bias from the page.
^ permalink raw reply
* Re: [net-next PATCH V2 1/3] mm: add dma_addr_t to struct page
From: Florian Fainelli @ 2019-02-12 18:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev, linux-mm
Cc: Toke Høiland-Jørgensen, Ilias Apalodimas, willy,
Saeed Mahameed, Alexander Duyck, Andrew Morton, mgorman,
David S. Miller, Tariq Toukan
In-Reply-To: <154998294324.8783.9045146111677125556.stgit@firesoul>
On 2/12/19 6:49 AM, Jesper Dangaard Brouer wrote:
> The page_pool API is using page->private to store DMA addresses.
> As pointed out by David Miller we can't use that on 32-bit architectures
> with 64-bit DMA
>
> This patch adds a new dma_addr_t struct to allow storing DMA addresses
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Acked-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> include/linux/mm_types.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2c471a2c43fa..581737bd0878 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -95,6 +95,13 @@ struct page {
> */
> unsigned long private;
> };
> + struct { /* page_pool used by netstack */
> + /**
> + * @dma_addr: page_pool requires a 64-bit value even on
> + * 32-bit architectures.
> + */
Nit: might require? dma_addr_t, as you mention in the commit may have a
different size based on CONFIG_ARCH_DMA_ADDR_T_64BIT.
--
Florian
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
From: Li Yang @ 2019-02-12 18:01 UTC (permalink / raw)
To: Pankaj Bansal, Rob Herring
Cc: Shawn Guo, Andrew Lunn, Florian Fainelli, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM5PR0401MB24818DB35D5DEF95DA710038F1650@AM5PR0401MB2481.eurprd04.prod.outlook.com>
On Mon, Feb 11, 2019 at 9:28 PM Pankaj Bansal <pankaj.bansal@nxp.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Leo Li
> > Sent: Tuesday, 12 February, 2019 02:14 AM
> > To: Shawn Guo <shawnguo@kernel.org>; Pankaj Bansal
> > <pankaj.bansal@nxp.com>
> > Cc: Andrew Lunn <andrew@lunn.ch>; Florian Fainelli <f.fainelli@gmail.com>;
> > netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org
> > Subject: RE: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
> >
> >
> >
> > > -----Original Message-----
> > > From: Shawn Guo <shawnguo@kernel.org>
> > > Sent: Sunday, February 10, 2019 9:00 PM
> > > To: Pankaj Bansal <pankaj.bansal@nxp.com>
> > > Cc: Leo Li <leoyang.li@nxp.com>; Andrew Lunn <andrew@lunn.ch>; Florian
> > > Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org; linux-arm-
> > > kernel@lists.infradead.org
> > > Subject: Re: [PATCH v3] arm64: dts: lx2160aqds: Add mdio mux nodes
> > >
> > > On Wed, Feb 06, 2019 at 09:40:33AM +0000, Pankaj Bansal wrote:
> > > > The two external MDIO buses used to communicate with phy devices
> > > > that are external to SOC are muxed in LX2160AQDS board.
> > > >
> > > > These buses can be routed to any one of the eight IO slots on
> > > > LX2160AQDS board depending on value in fpga register 0x54.
> > > >
> > > > Additionally the external MDIO1 is used to communicate to the
> > > > onboard RGMII phy devices.
> > > >
> > > > The mdio1 is controlled by bits 4-7 of fpga register and mdio2 is
> > > > controlled by bits 0-3 of fpga register.
> > > >
> > > > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > > > ---
> > > >
> > > > Notes:
> > > > V3:
> > > > - Add status = disabled in soc file and status = okay in board file
> > > > for external MDIO nodes
> > > > - Add interrupts property in external mdio nodes in soc file
> > > > V2:
> > > > - removed unnecassary TODO statements
> > > > - removed device_type from mdio nodes
> > > > - change the case of hex number to lowercase
> > > > - removed board specific comments from soc file
> > > >
> > > > .../boot/dts/freescale/fsl-lx2160a-qds.dts | 123 +++++++++++++++++
> > > > .../boot/dts/freescale/fsl-lx2160a.dtsi | 22 +++
> > > > 2 files changed, 145 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > index 99a22abbe725..079264b391a2 100644
> > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
> > > > @@ -35,6 +35,14 @@
> > > > status = "okay";
> > > > };
> > > >
> > > > +&emdio1 {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > +&emdio2 {
> > > > + status = "okay";
> > > > +};
> > > > +
> > > > &esdhc0 {
> > > > status = "okay";
> > > > };
> > > > @@ -46,6 +54,121 @@
> > > > &i2c0 {
> > > > status = "okay";
> > > >
> > > > + fpga@66 {
> > > > + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
> > > > + reg = <0x66>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + mdio-mux-1@54 {
> > > > + mdio-parent-bus = <&emdio1>;
> > > > + reg = <0x54>; /* BRDCFG4 */
> > > > + mux-mask = <0xf8>; /* EMI1_MDIO */
> > > > + #address-cells=<1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + mdio@0 {
> > > > + reg = <0x00>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > >
> > > Please have a newline between nodes. It doesn't deserve a respin
> > > though. I can fix them up when applying if Leo is fine with this version.
> >
> > I think there should be a compatible string defined for the binding of parent
> > node mdio-mux, probably "mdio-mux-regmap", and be used here in the device
> > tree.
>
> I have two concerns :
> 1. The regmap is linux s/w construct, while device tree is h/w representation and is s/w agnostic. can we use regmap in device tree?
Well, if we want to avoid using the regmap name, we probably can try
"mdio-mux-reg" or "mdio-mux-syscon"? With further search I also found
a more generic mux binding at Documentation/devicetree/bindings/mux/,
would be even better if we can use that to describe the mux.
> 2. By convention the device tree compatible binding is defined as "<manufacturer>,<model>" e.g. "fsl,mpc8349-uart". The mdio-mux node and it's sub nodes are a generic representation of mdio mux and it is not dependent on a particular manufacturer device. How to define the compatible in this case?
The manufacturer prefix is for vendor specific bindings. If the
binding a suppose to be generic, we don't need the vendor prefix.
>
> >
> > >
> > > Shawn
> > >
> > > > + mdio@40 {
> > > > + reg = <0x40>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@c0 {
> > > > + reg = <0xc0>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@c8 {
> > > > + reg = <0xc8>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@d0 {
> > > > + reg = <0xd0>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@d8 {
> > > > + reg = <0xd8>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@e0 {
> > > > + reg = <0xe0>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@e8 {
> > > > + reg = <0xe8>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@f0 {
> > > > + reg = <0xf0>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@f8 {
> > > > + reg = <0xf8>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + };
> > > > +
> > > > + mdio-mux-2@54 {
> > > > + mdio-parent-bus = <&emdio2>;
> > > > + reg = <0x54>; /* BRDCFG4 */
> > > > + mux-mask = <0x07>; /* EMI2_MDIO */
> > > > + #address-cells=<1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + mdio@0 {
> > > > + reg = <0x00>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@1 {
> > > > + reg = <0x01>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@2 {
> > > > + reg = <0x02>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@3 {
> > > > + reg = <0x03>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@4 {
> > > > + reg = <0x04>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@5 {
> > > > + reg = <0x05>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@6 {
> > > > + reg = <0x06>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + mdio@7 {
> > > > + reg = <0x07>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + };
> > > > + };
> > > > + };
> > > > +
> > > > i2c-mux@77 {
> > > > compatible = "nxp,pca9547";
> > > > reg = <0x77>;
> > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > index a79f5c1ea56d..7def5252ac1a 100644
> > > > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > > > @@ -762,5 +762,27 @@
> > > > <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
> > > > dma-coherent;
> > > > };
> > > > +
> > > > + /* WRIOP0: 0x8b8_0000, E-MDIO1: 0x1_6000 */
> > > > + emdio1: mdio@8b96000 {
> > > > + compatible = "fsl,fman-memac-mdio";
> > > > + reg = <0x0 0x8b96000 0x0 0x1000>;
> > > > + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + little-endian; /* force the driver in LE mode */
> > > > + status = "disabled";
> > > > + };
> > > > +
> > > > + /* WRIOP0: 0x8b8_0000, E-MDIO2: 0x1_7000 */
> > > > + emdio2: mdio@8b97000 {
> > > > + compatible = "fsl,fman-memac-mdio";
> > > > + reg = <0x0 0x8b97000 0x0 0x1000>;
> > > > + interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > + little-endian; /* force the driver in LE mode */
> > > > + status = "disabled";
> > > > + };
> > > > };
> > > > };
> > > > --
> > > > 2.17.1
> > > >
^ permalink raw reply
* Re: [v3, 0/9] Add ENETC PTP clock driver
From: David Miller @ 2019-02-12 17:59 UTC (permalink / raw)
To: yangbo.lu; +Cc: netdev, devicetree, richardcochran, robh+dt, claudiu.manoil
In-Reply-To: <20190212042404.15575-1-yangbo.lu@nxp.com>
From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Tue, 12 Feb 2019 12:23:55 +0800
> There is same QorIQ 1588 timer IP block on the new ENETC Ethernet
> controller with eTSEC/DPAA Ethernet controllers. However it's
> different endianness (little-endian) and using PCI driver.
>
> To support ENETC PTP driver, ptp_qoriq driver needed to be
> reworked to make functions global for reusing, to add little-
> endian support, to add ENETC memory map support, and to add
> ENETC dependency for ptp_qoriq driver.
>
> In addition, although ENETC PTP driver is a PCI driver, the dts
> node still could be used. Currently the ls1028a dtsi which is
> the only platform by now using ENETC is not complete, so there
> is still dependency for ENETC PTP node upstreaming. This will
> be done in the near future. The hardware timestamping support
> for ENETC is done but needs to be reworked with new method in
> internal git tree, and will be sent out soon.
Series applied.
I'll push this out after my build tests pass.
^ permalink raw reply
* Re: [net-next PATCH V2 3/3] page_pool: use DMA_ATTR_SKIP_CPU_SYNC for DMA mappings
From: Jesper Dangaard Brouer @ 2019-02-12 17:58 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, netdev, linux-mm, Toke Høiland-Jørgensen,
Ilias Apalodimas, willy, Saeed Mahameed, Alexander Duyck,
Andrew Morton, mgorman, David S. Miller, Tariq Toukan, brouer
In-Reply-To: <201902130132.DXE6rH81%fengguang.wu@intel.com>
On Wed, 13 Feb 2019 01:12:59 +0800
kbuild test robot <lkp@intel.com> wrote:
> net/core/page_pool.c: In function '__page_pool_clean_page':
> >> net/core/page_pool.c:187:2: error: implicit declaration of function 'dma_unmap_page_attr'; did you mean 'dma_unmap_page_attrs'? [-Werror=implicit-function-declaration]
> dma_unmap_page_attr(pool->p.dev, dma,
> ^~~~~~~~~~~~~~~~~~~
> dma_unmap_page_attrs
> cc1: some warnings being treated as errors
Ups, in my compile test I didn't have CONFIG_PAGE_POOL defined.
Will respin a V3.
--
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-next] net/skbuff: fix up kernel-doc placement
From: David Miller @ 2019-02-12 17:55 UTC (permalink / raw)
To: briannorris; +Cc: netdev, linux-kernel
In-Reply-To: <20190211210225.132282-1-briannorris@chromium.org>
From: Brian Norris <briannorris@chromium.org>
Date: Mon, 11 Feb 2019 13:02:25 -0800
> There are several skb_* functions where the locked and unlocked
> functions are confusingly documented. For several of them, the
> kernel-doc for the unlocked version is placed above the locked version,
> which to the casual reader makes it seems like the locked version "takes
> no locks and you must therefore hold required locks before calling it."
>
> One can see, for example, that this link claims to document
> skb_queue_head(), while instead describing __skb_queue_head().
>
> https://www.kernel.org/doc/html/latest/networking/kapi.html#c.skb_queue_head
>
> The correct documentation for skb_queue_head() is also included further
> down the page.
>
> This diff tested via:
>
> $ scripts/kernel-doc -rst include/linux/skbuff.h net/core/skbuff.c
>
> No new warnings were seen, and the output makes a little more sense.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Applied, thanks Brian.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox