* Re: general protection fault in prepare_to_wait
From: syzbot @ 2019-02-08 12:06 UTC (permalink / raw)
To: davem, linux-hams, linux-kernel, netdev, ralf, syzkaller-bugs
In-Reply-To: <000000000000fa6a2c057e8b7064@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: ec7fd009e87c Merge branch 'ipv6-fixes'
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=17fc3d97400000
kernel config: https://syzkaller.appspot.com/x/.config?x=2e0064f906afee10
dashboard link: https://syzkaller.appspot.com/bug?extid=55f9d3e51d49e20b2ce5
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16970150c00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+55f9d3e51d49e20b2ce5@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device batadv0
8021q: adding VLAN 0 to HW filter on device batadv0
8021q: adding VLAN 0 to HW filter on device batadv0
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 7733 Comm: syz-executor3 Not tainted 5.0.0-rc4+ #67
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__lock_acquire+0x8df/0x4700 kernel/locking/lockdep.c:3215
Code: 28 00 00 00 0f 85 35 27 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
85 dc 27 00 00 49 81 3c 24 20 25 9a 89 0f 84 03 f8
RSP: 0018:ffff888088fa7970 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000018
RBP: ffff888088fa7b40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000018
R13: 0000000000000001 R14: 0000000000000000 R15: ffff888098fc60c0
FS: 00007f2176cc4700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f763933ddb8 CR3: 0000000088560000 CR4: 00000000001406f0
Call Trace:
lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152
prepare_to_wait+0x7c/0x300 kernel/sched/wait.c:230
nr_accept+0x239/0x790 net/netrom/af_netrom.c:796
__sys_accept4+0x350/0x6a0 net/socket.c:1588
__do_sys_accept net/socket.c:1629 [inline]
__se_sys_accept net/socket.c:1626 [inline]
__x64_sys_accept+0x75/0xb0 net/socket.c:1626
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e39
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2176cc3c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 000000000073c0e0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2176cc46d4
R13: 00000000004bdc10 R14: 00000000004cdea0 R15: 00000000ffffffff
Modules linked in:
---[ end trace 82c8ff081ad12861 ]---
RIP: 0010:__lock_acquire+0x8df/0x4700 kernel/locking/lockdep.c:3215
Code: 28 00 00 00 0f 85 35 27 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f
5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f
85 dc 27 00 00 49 81 3c 24 20 25 9a 89 0f 84 03 f8
RSP: 0018:ffff888088fa7970 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000018
RBP: ffff888088fa7b40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000018
R13: 0000000000000001 R14: 0000000000000000 R15: ffff888098fc60c0
FS: 00007f2176cc4700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f763933ddb8 CR3: 0000000088560000 CR4: 00000000001406f0
^ permalink raw reply
* Re: Kernel 5.0-rc5 regression with NAT, bisected to: netfilter: nat: remove l4proto->manip_pkt
From: Florian Westphal @ 2019-02-08 11:54 UTC (permalink / raw)
To: Florian Westphal
Cc: Sander Eikelenboom, Pablo Neira Ayuso, David S. Miller, netdev,
linux-kernel
In-Reply-To: <20190208070710.rcbj6exqwz6m2o7o@breakpoint.cc>
Florian Westphal <fw@strlen.de> wrote:
> Sander Eikelenboom <linux@eikelenboom.it> wrote:
> > L.S.,
> >
> > While trying out a 5.0-RC5 kernel I seem to have stumbled over a regression with NAT.
> > (using an nftables firewall with NAT and connection tracking).
> >
> > Unfortunately it isn't too obvious since no errors are logged, but on clients it
> > causes symptoms like firefox intermittently not being able to load pages with:
> > Network Protocol Error
> > An error occurred during a connection to www.example.com
> > The page you are trying to view cannot be shown because an error in the network protocol was detected.
> > Please contact the website owners to inform them of this problem.
> >
> > But it's only intermittently, so i can still visit some webpages with clients,
> > could be that packet size and or fragments are at play ?
> >
> > So I tried testing with git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git with
> > e8c32c32b48c2e889704d8ca0872f92eb027838e as last commit, to be sure to have the latest netdev has to offer,
> > but to no avail.
> >
> > After that I tried to git bisect and ended up with:
> >
> > faec18dbb0405c7d4dda025054511dc3a6696918 is the first bad commit
> > commit faec18dbb0405c7d4dda025054511dc3a6696918
> > Author: Florian Westphal <fw@strlen.de>
> > Date: Thu Dec 13 16:01:33 2018 +0100
> >
> > netfilter: nat: remove l4proto->manip_pkt
>
> Thanks, this is immensely helpful.
>
> I think I see the bug, we can't use target->dst.protonum in
> nf_nat_l4proto_manip_pkt(), it will be TCP in case we're dealing
> with a related icmp packet.
>
> I will send a patch in a few hours when I get back.
Sander, does this patch fix things for you?
Thanks!
diff --git a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
--- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
@@ -215,6 +215,7 @@ int nf_nat_icmp_reply_translation(struct sk_buff *skb,
/* Change outer to look like the reply to an incoming packet */
nf_ct_invert_tuplepr(&target, &ct->tuplehash[!dir].tuple);
+ target.dst.protonum = IPPROTO_ICMP;
if (!nf_nat_ipv4_manip_pkt(skb, 0, &target, manip))
return 0;
diff --git a/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c b/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
--- a/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
+++ b/net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
@@ -226,6 +226,7 @@ int nf_nat_icmpv6_reply_translation(struct sk_buff *skb,
}
nf_ct_invert_tuplepr(&target, &ct->tuplehash[!dir].tuple);
+ target.dst.protonum = IPPROTO_ICMPV6;
if (!nf_nat_ipv6_manip_pkt(skb, 0, &target, manip))
return 0;
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 0/2] qed*: SmartAN query support
From: Sudarsana Reddy Kalluru @ 2019-02-08 11:32 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ariel Elior,
Michal Kalderon
In-Reply-To: <20190207115405.02563e74@cakuba.netronome.com>
>-----Original Message-----
>From: Jakub Kicinski [mailto:jakub.kicinski@netronome.com]
>Sent: 08 February 2019 01:24
>To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
>Cc: davem@davemloft.net; netdev@vger.kernel.org; Ariel Elior
><aelior@marvell.com>; Michal Kalderon <mkalderon@marvell.com>
>Subject: [EXT] Re: [PATCH net-next 0/2] qed*: SmartAN query support
>
>External Email
>
>----------------------------------------------------------------------
>On Thu, 7 Feb 2019 06:20:10 -0800, Sudarsana Reddy Kalluru wrote:
>> SmartAN feature detects the peer/cable capabilities and establishes
>> the link in the best possible configuration.
>
>It sounds familiar, I need to check with FW team, but I think we may be doing
>a similar thing, and adding a common API rather than ethtool flag would be
>preferable.
>
>Could you please share a little bit more detail? What are the configurations
>this would choose between?
Jakub,
Following doc provides detailed information on this feature. We simply need a flag to display whether the feature is enabled in the hardware or not, hence adding it to "ethtool --show-priv-flags".
https://www.cavium.com/Dell/Documents/Converged/TB_Establishing_Adaptive_Links_with_SmartAN_Dell.pdf
****
When an administrator first plugs a device (discrete optical module or Active Optical Cable assembly or DAC) into the Cavium FastLinQ adapter SFP/QSFP interface, the Cavium SmartAN technology reads the device type (discrete optics or AOC or DAC), what its speed rating is, special optics data (such as what FEC mode is required or if it is multi-speed capable), DAC CA-x type, and DAC length.
Armed with this information, the FastLinQ adapter attempts each possible mode (supported by that device) until it secures a link with the connected link partner (switch), without input from the end user.
****
Thanks,
Sudarsana
^ permalink raw reply
* Re: [PATCH net-next 1/2] Revert "devlink: Add a generic wake_on_lan port parameter"
From: kbuild test robot @ 2019-02-08 11:00 UTC (permalink / raw)
To: Vasundhara Volam; +Cc: kbuild-all, davem, michael.chan, jiri, netdev
In-Reply-To: <1549617190-387130-2-git-send-email-vasundhara-v.volam@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 24900 bytes --]
Hi Vasundhara,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Vasundhara-Volam/Revert-wake_on_lan-devlink-parameter/20190208-181949
config: i386-randconfig-x000-201905 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: the linux-review/Vasundhara-Volam/Revert-wake_on_lan-devlink-parameter/20190208-181949 HEAD caa636fa491621c75cb625cb981adfe514368a45 builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
>> drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:41:3: error: 'DEVLINK_PARAM_GENERIC_ID_WOL' undeclared here (not in a function); did you mean 'DEVLINK_PARAM_GENERIC_ID_MAX'?
{DEVLINK_PARAM_GENERIC_ID_WOL, NVM_OFF_WOL, BNXT_NVM_PORT_CFG, 1},
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
DEVLINK_PARAM_GENERIC_ID_MAX
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c: In function 'bnxt_hwrm_nvm_req':
>> drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:76:20: warning: comparison between pointer and integer
nvm_param.id != DEVLINK_PARAM_GENERIC_ID_WOL)
^~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c: In function 'bnxt_dl_wol_validate':
>> drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:174:28: error: 'DEVLINK_PARAM_WAKE_MAGIC' undeclared (first use in this function); did you mean 'DEVLINK_PARAM_CMODE_MAX'?
if (val.vu8 && val.vu8 != DEVLINK_PARAM_WAKE_MAGIC) {
^~~~~~~~~~~~~~~~~~~~~~~~
DEVLINK_PARAM_CMODE_MAX
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:174:28: note: each undeclared identifier is reported only once for each function it appears in
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:174:25: warning: comparison between pointer and integer
if (val.vu8 && val.vu8 != DEVLINK_PARAM_WAKE_MAGIC) {
^~
In file included from drivers/net//ethernet/broadcom/bnxt/bnxt.h:23,
from drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:13:
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c: At top level:
>> include/net/devlink.h:404:8: warning: initialization of 'unsigned int' from 'const struct bnxt_dl_nvm_param *' makes integer from pointer without a cast [-Wint-conversion]
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:404:8: note: (near initialization for 'bnxt_dl_port_params[0].id')
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:404:8: error: initializer element is not constant
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:404:8: note: (near initialization for 'bnxt_dl_port_params[0].id')
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:405:10: error: 'DEVLINK_PARAM_GENERIC_WOL_NAME' undeclared here (not in a function); did you mean 'DEVLINK_PARAM_GENERIC_ID_MAX'?
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:405:10: error: initialization of 'const char *' from incompatible pointer type 'const struct bnxt_dl_nvm_param *' [-Werror=incompatible-pointer-types]
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:405:10: note: (near initialization for 'bnxt_dl_port_params[0].name')
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:405:10: error: initializer element is not constant
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:405:10: note: (near initialization for 'bnxt_dl_port_params[0].name')
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:406:10: error: 'DEVLINK_PARAM_GENERIC_WOL_TYPE' undeclared here (not in a function); did you mean 'DEVLINK_PARAM_GENERIC_ID_MAX'?
.type = DEVLINK_PARAM_GENERIC_##_id##_TYPE, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:406:10: error: incompatible types when initializing type 'enum devlink_param_type' using type 'const struct bnxt_dl_nvm_param *'
.type = DEVLINK_PARAM_GENERIC_##_id##_TYPE, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:41:3: error: 'DEVLINK_PARAM_GENERIC_ID_WOL' undeclared here (not in a function); did you mean 'DEVLINK_PARAM_GENERIC_ID_MAX'?
{DEVLINK_PARAM_GENERIC_ID_WOL, NVM_OFF_WOL, BNXT_NVM_PORT_CFG, 1},
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
DEVLINK_PARAM_GENERIC_ID_MAX
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c: In function 'bnxt_hwrm_nvm_req':
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:76:20: warning: comparison between pointer and integer
nvm_param.id != DEVLINK_PARAM_GENERIC_ID_WOL)
^~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c: In function 'bnxt_dl_wol_validate':
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:174:28: error: 'DEVLINK_PARAM_WAKE_MAGIC' undeclared (first use in this function); did you mean 'DEVLINK_PARAM_CMODE_MAX'?
if (val.vu8 && val.vu8 != DEVLINK_PARAM_WAKE_MAGIC) {
^~~~~~~~~~~~~~~~~~~~~~~~
DEVLINK_PARAM_CMODE_MAX
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:174:28: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:174:25: warning: comparison between pointer and integer
if (val.vu8 && val.vu8 != DEVLINK_PARAM_WAKE_MAGIC) {
^~
In file included from drivers/net/ethernet/broadcom/bnxt/bnxt.h:23,
from drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:13:
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c: At top level:
>> include/net/devlink.h:404:8: warning: initialization of 'unsigned int' from 'const struct bnxt_dl_nvm_param *' makes integer from pointer without a cast [-Wint-conversion]
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:404:8: note: (near initialization for 'bnxt_dl_port_params[0].id')
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:404:8: error: initializer element is not constant
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:404:8: note: (near initialization for 'bnxt_dl_port_params[0].id')
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:405:10: error: 'DEVLINK_PARAM_GENERIC_WOL_NAME' undeclared here (not in a function); did you mean 'DEVLINK_PARAM_GENERIC_ID_MAX'?
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:405:10: error: initialization of 'const char *' from incompatible pointer type 'const struct bnxt_dl_nvm_param *' [-Werror=incompatible-pointer-types]
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:405:10: note: (near initialization for 'bnxt_dl_port_params[0].name')
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:405:10: error: initializer element is not constant
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
include/net/devlink.h:405:10: note: (near initialization for 'bnxt_dl_port_params[0].name')
.name = DEVLINK_PARAM_GENERIC_##_id##_NAME, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:406:10: error: 'DEVLINK_PARAM_GENERIC_WOL_TYPE' undeclared here (not in a function); did you mean 'DEVLINK_PARAM_GENERIC_ID_MAX'?
.type = DEVLINK_PARAM_GENERIC_##_id##_TYPE, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
>> include/net/devlink.h:406:10: error: incompatible types when initializing type 'enum devlink_param_type' using type 'const struct bnxt_dl_nvm_param *'
.type = DEVLINK_PARAM_GENERIC_##_id##_TYPE, \
^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c:206:2: note: in expansion of macro 'DEVLINK_PARAM_GENERIC'
DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +41 drivers/net//ethernet/broadcom/bnxt/bnxt_devlink.c
2dc0865e Vasundhara Volam 2018-10-04 28
6354b95e Vasundhara Volam 2018-07-04 29 static const struct bnxt_dl_nvm_param nvm_params[] = {
6354b95e Vasundhara Volam 2018-07-04 30 {DEVLINK_PARAM_GENERIC_ID_ENABLE_SRIOV, NVM_OFF_ENABLE_SRIOV,
6354b95e Vasundhara Volam 2018-07-04 31 BNXT_NVM_SHARED_CFG, 1},
7d859234 Vasundhara Volam 2018-10-04 32 {DEVLINK_PARAM_GENERIC_ID_IGNORE_ARI, NVM_OFF_IGNORE_ARI,
7d859234 Vasundhara Volam 2018-10-04 33 BNXT_NVM_SHARED_CFG, 1},
f399e849 Vasundhara Volam 2018-10-04 34 {DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
f399e849 Vasundhara Volam 2018-10-04 35 NVM_OFF_MSIX_VEC_PER_PF_MAX, BNXT_NVM_SHARED_CFG, 10},
f399e849 Vasundhara Volam 2018-10-04 36 {DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
f399e849 Vasundhara Volam 2018-10-04 37 NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
2dc0865e Vasundhara Volam 2018-10-04 38 {BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK, NVM_OFF_DIS_GRE_VER_CHECK,
2dc0865e Vasundhara Volam 2018-10-04 39 BNXT_NVM_SHARED_CFG, 1},
782a624d Vasundhara Volam 2019-01-28 40
782a624d Vasundhara Volam 2019-01-28 @41 {DEVLINK_PARAM_GENERIC_ID_WOL, NVM_OFF_WOL, BNXT_NVM_PORT_CFG, 1},
6354b95e Vasundhara Volam 2018-07-04 42 };
6354b95e Vasundhara Volam 2018-07-04 43
6354b95e Vasundhara Volam 2018-07-04 44 static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
6354b95e Vasundhara Volam 2018-07-04 45 int msg_len, union devlink_param_value *val)
6354b95e Vasundhara Volam 2018-07-04 46 {
6fc92c33 Michael Chan 2018-08-05 47 struct hwrm_nvm_get_variable_input *req = msg;
6354b95e Vasundhara Volam 2018-07-04 48 void *data_addr = NULL, *buf = NULL;
6354b95e Vasundhara Volam 2018-07-04 49 struct bnxt_dl_nvm_param nvm_param;
6354b95e Vasundhara Volam 2018-07-04 50 int bytesize, idx = 0, rc, i;
6354b95e Vasundhara Volam 2018-07-04 51 dma_addr_t data_dma_addr;
6354b95e Vasundhara Volam 2018-07-04 52
6354b95e Vasundhara Volam 2018-07-04 53 /* Get/Set NVM CFG parameter is supported only on PFs */
6354b95e Vasundhara Volam 2018-07-04 54 if (BNXT_VF(bp))
6354b95e Vasundhara Volam 2018-07-04 55 return -EPERM;
6354b95e Vasundhara Volam 2018-07-04 56
6354b95e Vasundhara Volam 2018-07-04 57 for (i = 0; i < ARRAY_SIZE(nvm_params); i++) {
6354b95e Vasundhara Volam 2018-07-04 58 if (nvm_params[i].id == param_id) {
6354b95e Vasundhara Volam 2018-07-04 59 nvm_param = nvm_params[i];
6354b95e Vasundhara Volam 2018-07-04 60 break;
6354b95e Vasundhara Volam 2018-07-04 61 }
6354b95e Vasundhara Volam 2018-07-04 62 }
6354b95e Vasundhara Volam 2018-07-04 63
65fac4fe zhong jiang 2018-09-18 64 if (i == ARRAY_SIZE(nvm_params))
65fac4fe zhong jiang 2018-09-18 65 return -EOPNOTSUPP;
65fac4fe zhong jiang 2018-09-18 66
6354b95e Vasundhara Volam 2018-07-04 67 if (nvm_param.dir_type == BNXT_NVM_PORT_CFG)
6354b95e Vasundhara Volam 2018-07-04 68 idx = bp->pf.port_id;
6354b95e Vasundhara Volam 2018-07-04 69 else if (nvm_param.dir_type == BNXT_NVM_FUNC_CFG)
6354b95e Vasundhara Volam 2018-07-04 70 idx = bp->pf.fw_fid - BNXT_FIRST_PF_FID;
6354b95e Vasundhara Volam 2018-07-04 71
6354b95e Vasundhara Volam 2018-07-04 72 bytesize = roundup(nvm_param.num_bits, BITS_PER_BYTE) / BITS_PER_BYTE;
f399e849 Vasundhara Volam 2018-10-04 73 switch (bytesize) {
f399e849 Vasundhara Volam 2018-10-04 74 case 1:
782a624d Vasundhara Volam 2019-01-28 75 if (nvm_param.num_bits == 1 &&
782a624d Vasundhara Volam 2019-01-28 @76 nvm_param.id != DEVLINK_PARAM_GENERIC_ID_WOL)
6354b95e Vasundhara Volam 2018-07-04 77 buf = &val->vbool;
f399e849 Vasundhara Volam 2018-10-04 78 else
f399e849 Vasundhara Volam 2018-10-04 79 buf = &val->vu8;
f399e849 Vasundhara Volam 2018-10-04 80 break;
f399e849 Vasundhara Volam 2018-10-04 81 case 2:
f399e849 Vasundhara Volam 2018-10-04 82 buf = &val->vu16;
f399e849 Vasundhara Volam 2018-10-04 83 break;
f399e849 Vasundhara Volam 2018-10-04 84 case 4:
f399e849 Vasundhara Volam 2018-10-04 85 buf = &val->vu32;
f399e849 Vasundhara Volam 2018-10-04 86 break;
f399e849 Vasundhara Volam 2018-10-04 87 default:
f399e849 Vasundhara Volam 2018-10-04 88 return -EFAULT;
f399e849 Vasundhara Volam 2018-10-04 89 }
6354b95e Vasundhara Volam 2018-07-04 90
750afb08 Luis Chamberlain 2019-01-04 91 data_addr = dma_alloc_coherent(&bp->pdev->dev, bytesize,
6354b95e Vasundhara Volam 2018-07-04 92 &data_dma_addr, GFP_KERNEL);
6354b95e Vasundhara Volam 2018-07-04 93 if (!data_addr)
6354b95e Vasundhara Volam 2018-07-04 94 return -ENOMEM;
6354b95e Vasundhara Volam 2018-07-04 95
6fc92c33 Michael Chan 2018-08-05 96 req->dest_data_addr = cpu_to_le64(data_dma_addr);
6354b95e Vasundhara Volam 2018-07-04 97 req->data_len = cpu_to_le16(nvm_param.num_bits);
6354b95e Vasundhara Volam 2018-07-04 98 req->option_num = cpu_to_le16(nvm_param.offset);
6354b95e Vasundhara Volam 2018-07-04 99 req->index_0 = cpu_to_le16(idx);
6354b95e Vasundhara Volam 2018-07-04 100 if (idx)
6354b95e Vasundhara Volam 2018-07-04 101 req->dimensions = cpu_to_le16(1);
6354b95e Vasundhara Volam 2018-07-04 102
6fc92c33 Michael Chan 2018-08-05 103 if (req->req_type == cpu_to_le16(HWRM_NVM_SET_VARIABLE))
6354b95e Vasundhara Volam 2018-07-04 104 memcpy(data_addr, buf, bytesize);
6354b95e Vasundhara Volam 2018-07-04 105
6354b95e Vasundhara Volam 2018-07-04 106 rc = hwrm_send_message(bp, msg, msg_len, HWRM_CMD_TIMEOUT);
6fc92c33 Michael Chan 2018-08-05 107 if (!rc && req->req_type == cpu_to_le16(HWRM_NVM_GET_VARIABLE))
6354b95e Vasundhara Volam 2018-07-04 108 memcpy(buf, data_addr, bytesize);
6354b95e Vasundhara Volam 2018-07-04 109
6354b95e Vasundhara Volam 2018-07-04 110 dma_free_coherent(&bp->pdev->dev, bytesize, data_addr, data_dma_addr);
3a1d52a5 Vasundhara Volam 2018-10-04 111 if (rc == HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED) {
3a1d52a5 Vasundhara Volam 2018-10-04 112 netdev_err(bp->dev, "PF does not have admin privileges to modify NVM config\n");
3a1d52a5 Vasundhara Volam 2018-10-04 113 return -EACCES;
3a1d52a5 Vasundhara Volam 2018-10-04 114 } else if (rc) {
6354b95e Vasundhara Volam 2018-07-04 115 return -EIO;
3a1d52a5 Vasundhara Volam 2018-10-04 116 }
6354b95e Vasundhara Volam 2018-07-04 117 return 0;
6354b95e Vasundhara Volam 2018-07-04 118 }
6354b95e Vasundhara Volam 2018-07-04 119
6354b95e Vasundhara Volam 2018-07-04 120 static int bnxt_dl_nvm_param_get(struct devlink *dl, u32 id,
6354b95e Vasundhara Volam 2018-07-04 121 struct devlink_param_gset_ctx *ctx)
6354b95e Vasundhara Volam 2018-07-04 122 {
6354b95e Vasundhara Volam 2018-07-04 123 struct hwrm_nvm_get_variable_input req = {0};
6354b95e Vasundhara Volam 2018-07-04 124 struct bnxt *bp = bnxt_get_bp_from_dl(dl);
2dc0865e Vasundhara Volam 2018-10-04 125 int rc;
6354b95e Vasundhara Volam 2018-07-04 126
6354b95e Vasundhara Volam 2018-07-04 127 bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_NVM_GET_VARIABLE, -1, -1);
2dc0865e Vasundhara Volam 2018-10-04 128 rc = bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
2dc0865e Vasundhara Volam 2018-10-04 129 if (!rc)
2dc0865e Vasundhara Volam 2018-10-04 130 if (id == BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK)
2dc0865e Vasundhara Volam 2018-10-04 131 ctx->val.vbool = !ctx->val.vbool;
2dc0865e Vasundhara Volam 2018-10-04 132
2dc0865e Vasundhara Volam 2018-10-04 133 return rc;
6354b95e Vasundhara Volam 2018-07-04 134 }
6354b95e Vasundhara Volam 2018-07-04 135
6354b95e Vasundhara Volam 2018-07-04 136 static int bnxt_dl_nvm_param_set(struct devlink *dl, u32 id,
6354b95e Vasundhara Volam 2018-07-04 137 struct devlink_param_gset_ctx *ctx)
6354b95e Vasundhara Volam 2018-07-04 138 {
6354b95e Vasundhara Volam 2018-07-04 139 struct hwrm_nvm_set_variable_input req = {0};
6354b95e Vasundhara Volam 2018-07-04 140 struct bnxt *bp = bnxt_get_bp_from_dl(dl);
6354b95e Vasundhara Volam 2018-07-04 141
6354b95e Vasundhara Volam 2018-07-04 142 bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_NVM_SET_VARIABLE, -1, -1);
2dc0865e Vasundhara Volam 2018-10-04 143
2dc0865e Vasundhara Volam 2018-10-04 144 if (id == BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK)
2dc0865e Vasundhara Volam 2018-10-04 145 ctx->val.vbool = !ctx->val.vbool;
2dc0865e Vasundhara Volam 2018-10-04 146
6354b95e Vasundhara Volam 2018-07-04 147 return bnxt_hwrm_nvm_req(bp, id, &req, sizeof(req), &ctx->val);
6354b95e Vasundhara Volam 2018-07-04 148 }
6354b95e Vasundhara Volam 2018-07-04 149
f399e849 Vasundhara Volam 2018-10-04 150 static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
f399e849 Vasundhara Volam 2018-10-04 151 union devlink_param_value val,
f399e849 Vasundhara Volam 2018-10-04 152 struct netlink_ext_ack *extack)
f399e849 Vasundhara Volam 2018-10-04 153 {
5fc7c12f Gustavo A. R. Silva 2018-10-05 154 int max_val = -1;
f399e849 Vasundhara Volam 2018-10-04 155
f399e849 Vasundhara Volam 2018-10-04 156 if (id == DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX)
f399e849 Vasundhara Volam 2018-10-04 157 max_val = BNXT_MSIX_VEC_MAX;
f399e849 Vasundhara Volam 2018-10-04 158
f399e849 Vasundhara Volam 2018-10-04 159 if (id == DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN)
f399e849 Vasundhara Volam 2018-10-04 160 max_val = BNXT_MSIX_VEC_MIN_MAX;
f399e849 Vasundhara Volam 2018-10-04 161
5fc7c12f Gustavo A. R. Silva 2018-10-05 162 if (val.vu32 > max_val) {
f399e849 Vasundhara Volam 2018-10-04 163 NL_SET_ERR_MSG_MOD(extack, "MSIX value is exceeding the range");
f399e849 Vasundhara Volam 2018-10-04 164 return -EINVAL;
f399e849 Vasundhara Volam 2018-10-04 165 }
f399e849 Vasundhara Volam 2018-10-04 166
f399e849 Vasundhara Volam 2018-10-04 167 return 0;
f399e849 Vasundhara Volam 2018-10-04 168 }
f399e849 Vasundhara Volam 2018-10-04 169
782a624d Vasundhara Volam 2019-01-28 170 static int bnxt_dl_wol_validate(struct devlink *dl, u32 id,
782a624d Vasundhara Volam 2019-01-28 171 union devlink_param_value val,
782a624d Vasundhara Volam 2019-01-28 172 struct netlink_ext_ack *extack)
782a624d Vasundhara Volam 2019-01-28 173 {
782a624d Vasundhara Volam 2019-01-28 @174 if (val.vu8 && val.vu8 != DEVLINK_PARAM_WAKE_MAGIC) {
782a624d Vasundhara Volam 2019-01-28 175 NL_SET_ERR_MSG_MOD(extack, "WOL type is not supported");
782a624d Vasundhara Volam 2019-01-28 176 return -EINVAL;
782a624d Vasundhara Volam 2019-01-28 177 }
782a624d Vasundhara Volam 2019-01-28 178 return 0;
782a624d Vasundhara Volam 2019-01-28 179 }
782a624d Vasundhara Volam 2019-01-28 180
:::::: The code at line 41 was first introduced by commit
:::::: 782a624d00fa22e7499f5abc29747501ec671313 bnxt_en: Add bnxt_en initial port params table and register it
:::::: TO: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
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: 34458 bytes --]
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-02-08 10:42 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
[ To the actual mailing lists this time... ]
This pull request is dedicated to the upcoming snowpocalypse parts 2
and 3 in the Pacific Northwest:
1) Drop profiles are broken because some drivers use dev_kfree_skb*
instead of dev_consume_skb*, from Yang Wei.
2) Fix IWLWIFI kconfig deps, from Luca Coelho.
3) Fix percpu maps updating in bpftool, from Paolo Abeni.
4) Missing station release in batman-adv, from Felix Fietkau.
5) Fix some networking compat ioctl bugs, from Johannes Berg.
6) ucc_geth must reset the BQL queue state when stopping the device,
from Mathias Thore.
7) Several XDP bug fixes in virtio_net from Toshiaki Makita.
8) TSO packets must be sent always on queue 0 in stmmac, from
Jose Abreu.
9) Fix socket refcounting bug in RDS, from Eric Dumazet.
10) Handle sparse cpu allocations in bpf selftests, from Martynas
Pumputis.
11) Make sure mgmt frames have enough tailroom in mac80211, from Felix
Feitkau.
12) Use safe list walking in sctp_sendmsg() asoc list traversal, from
Greg Kroah-Hartman.
13) Make DCCP's ccid_hc_[rt]x_parse_options always check for NULL ccid,
from Eric Dumazet.
14) Need to reload WoL password into bcmsysport device after deep sleeps,
from Florian Fainelli.
15) Remove filter from mask before freeing in cls_flower, from Petr
Machata.
16) Missing release and use after free in error paths of s390 qeth
code, from Julian Wiedmann.
17) Fix lockdep false positive in dsa code, from Marc Zyngier.
18) Fix counting of ATU violations in mv88e6xxx, from Andrew Lunn.
19) Fix EQ firmware assert in qed driver, from Manish Chopra.
20) Don't default Caivum PTP to Y in kconfig, from Bjorn Helgaas.
Please pull, thanks a lot!
The following changes since commit 62967898789dc1f09a06e59fa85ae2c5ca4dc2da:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2019-01-29 17:11:47 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to 39841cc1cbb69344539c98a1fa9d858ed124c7ba:
net: dsa: b53: Fix for failure when irq is not defined in dt (2019-02-07 18:18:37 -0800)
----------------------------------------------------------------
Alexei Starovoitov (4):
Merge branch 'typedef-func_proto'
bpf: run bpf programs with preemption disabled
bpf: fix lockdep false positive in percpu_freelist
bpf: fix potential deadlock in bpf_prog_register
Andrew Lunn (1):
net: dsa: mv88e6xxx: Fix counting of ATU violations
Arun Parameswaran (1):
net: dsa: b53: Fix for failure when irq is not defined in dt
Bart Van Assche (1):
lib/test_rhashtable: Make test_insert_dup() allocate its hash table dynamically
Bjorn Helgaas (1):
net: Don't default Cavium PTP driver to 'y'
Brian Norris (1):
ath10k: correct bus type for WCN3990
Colin Ian King (1):
ieee802154: mcr20a: fix indentation, remove tabs
Dan Carpenter (2):
skge: potential memory corruption in skge_get_regs()
net: dsa: Fix NULL checking in dsa_slave_set_eee()
Daniel Borkmann (3):
bpf, doc: add reviewers to maintainers entry
ipvlan, l3mdev: fix broken l3s mode wrt local routes
Merge branch 'bpf-lockdep-fixes'
David S. Miller (17):
Merge branch 'net-various-compat-ioctl-fixes'
Merge branch 'erspan-always-reports-output-key-to-userspace'
Merge branch 'virtio_net-Fix-problems-around-XDP-tx-and-napi_tx'
Merge branch 'stmmac-fixes'
Merge branch 'ieee802154-for-davem-2019-01-31' of git://git.kernel.org/.../sschmidt/wpan
Merge tag 'mac80211-for-davem-2019-02-01' of git://git.kernel.org/.../jberg/mac80211
Merge tag 'batadv-net-for-davem-20190201' of git://git.open-mesh.org/linux-merge
Merge branch 'smc-fixes'
Merge git://git.kernel.org/.../bpf/bpf
Merge branch 'vsock-virtio-hot-unplug'
Merge branch 'smc-fixes'
Merge tag 'wireless-drivers-for-davem-2019-02-04' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge branch 's390-qeth-fixes'
Merge git://git.kernel.org/.../pablo/nf
Merge tag 'mlx5-fixes-2019-02-05' of git://git.kernel.org/.../saeed/linux
Merge branch 'qed-Bug-fixes'
Merge branch 'ipv6-fixes'
Eli Cooper (1):
netfilter: ipv6: Don't preserve original oif for loopback address
Eric Dumazet (4):
rds: fix refcount bug in rds_sock_addref
dccp: fool proof ccid_hc_[rt]x_parse_options()
mISDN: fix a race in dev_expire_timer()
rxrpc: bad unlock balance in rxrpc_recvmsg
Felix Fietkau (2):
batman-adv: release station info tidstats
mac80211: ensure that mgmt tx skbs have tailroom for encryption
Florian Fainelli (1):
net: systemport: Fix WoL with password after deep sleep
Florian Westphal (2):
selftests: netfilter: add simple masq/redirect test cases
netfilter: nft_compat: don't use refcount_inc on newly allocated entry
George Amanakis (1):
tun: move the call to tun_set_real_num_queues
Govindarajulu Varadarajan (1):
enic: fix checksum validation for IPv6
Greg Kroah-Hartman (1):
sctp: walk the list of asoc safely
Guy Shattah (1):
net/mlx5e: Use the inner headers to determine tc/pedit offload limitation on decap flows
Hangbin Liu (2):
geneve: should not call rt6_lookup() when ipv6 was disabled
sit: check if IPv6 enabled before calling ip6_err_gen_icmpv6_unreach()
Hans Wippel (1):
net/smc: allow 16 byte pnetids in netlink policy
Jacob Wen (2):
l2tp: fix reading optional fields of L2TPv3
l2tp: copy 4 more bytes to linear part if necessary
Jakub Kicinski (1):
tools: bpftool: fix crash with un-owned prog arrays
Jakub Sitnicki (1):
sk_msg: Always cancel strp work before freeing the psock
Jiri Olsa (1):
bpftool: Fix prog dump by tag
Johannes Berg (5):
Revert "socket: fix struct ifreq size in compat ioctl"
Revert "kill dev_ifsioc()"
net: socket: fix SIOCGIFNAME in compat
net: socket: make bond ioctls go through compat_ifreq_ioctl()
cfg80211: call disconnect_wk when AP stops
Jose Abreu (3):
net: stmmac: Fallback to Platform Data clock in Watchdog conversion
net: stmmac: Send TSO packets always from Queue 0
net: stmmac: Disable EEE mode earlier in XMIT callback
Julian Wiedmann (4):
s390/qeth: release cmd buffer in error paths
s390/qeth: fix use-after-free in error path
s390/qeth: cancel close_dev work before removing a card
s390/qeth: conclude all event processing before offlining a card
Karsten Graul (7):
net/smc: prevent races between smc_lgr_terminate() and smc_conn_free()
net/smc: don't wait for send buffer space when data was already sent
net/smc: recvmsg and splice_read should return 0 after shutdown
net/smc: do not wait under send_lock
net/smc: call smc_cdc_msg_send() under send_lock
net/smc: use device link provided in qp_context
net/smc: fix use of variable in cleared area
Lorenzo Bianconi (3):
net: ip_gre: always reports o_key to userspace
net: ip6_gre: always reports o_key to userspace
mt76x0: eeprom: fix chan_vs_power map in mt76x0_get_power_info
Luca Coelho (1):
iwlwifi: make IWLWIFI depend on CFG80211
Manish Chopra (2):
qed: Fix EQ full firmware assert.
qed*: Advance drivers version to 8.37.0.20
Marc Zyngier (1):
net: dsa: Fix lockdep false positive splat
Martin KaFai Lau (1):
bpf: Fix syscall's stackmap lookup potential deadlock
Martynas Pumputis (2):
bpf, selftests: fix handling of sparse CPU allocations
netfilter: nf_nat: skip nat clash resolution for same-origin entries
Mathias Thore (1):
ucc_geth: Reset BQL queue when stopping device
Michael Chan (1):
bnxt_en: Disable interrupts when allocating CP rings or NQs.
Naresh Kamboju (1):
selftests: netfilter: fix config fragment CONFIG_NF_TABLES_INET
Or Gerlitz (1):
net/mlx5e: Properly set steering match levels for offloaded TC decap rules
Pablo Neira Ayuso (1):
netfilter: nf_tables: unbind set in rule from commit path
Paolo Abeni (1):
bpftool: fix percpu maps updating
Petr Machata (1):
net: cls_flower: Remove filter from mask before freeing it
Raed Salem (1):
net/mlx5e: FPGA, fix Innova IPsec TX offload data path performance
Rahul Verma (1):
qed: Change verbosity for coalescing message.
Rundong Ge (1):
net: dsa: slave: Don't propagate flag changes on down slave interfaces
Russell King (2):
Revert "net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x"
MAINTAINERS: add maintainer for SFF/SFP/SFP+ support
Sebastian Andrzej Siewior (1):
net: dp83640: expire old TX-skb
Siva Rebbagondla (1):
MAINTAINERS: add entry for redpine wireless driver
Stefano Garzarella (2):
vsock/virtio: fix kernel panic after device hot-unplug
vsock/virtio: reset connected sockets on device removal
Sudarsana Reddy Kalluru (3):
qed: Assign UFP TC value to vlan priority in UFP mode.
qed: Consider TX tcs while deriving the max num_queues for PF.
qede: Fix system crash on configuring channels.
Sven Eckelmann (2):
batman-adv: Avoid WARN on net_device without parent in netns
batman-adv: Force mac header to start of data on xmit
Tonghao Zhang (2):
net/mlx5e: Update hw flows when encap source mac changed
net/mlx5e: Don't overwrite pedit action when multiple pedit used
Toshiaki Makita (8):
virtio_net: Don't enable NAPI when interface is down
virtio_net: Don't call free_old_xmit_skbs for xdp_frames
virtio_net: Fix not restoring real_num_rx_queues
virtio_net: Fix out of bounds access of sq
virtio_net: Don't process redirected XDP frames when XDP is disabled
virtio_net: Use xdp_return_frame to free xdp_frames on destroying vqs
virtio_net: Differentiate sk_buff and xdp_frame on freeing
virtio_net: Account for tx bytes and packets on sending xdp_frames
Ulf Hansson (1):
wlcore: sdio: Fixup power on/off sequence
Ursula Braun (5):
net/smc: fix another sizeof to int comparison
net/smc: preallocated memory for rdma work requests
net/smc: fix sender_free computation
net/smc: delete rkey first before switching to unused
net/smc: correct state change for peer closing
Xin Long (1):
sctp: check and update stream->out_curr when allocating stream_out
Yafang Shao (1):
bpf: sock recvbuff must be limited by rmem_max in bpf_setsockopt()
Yang Wei (10):
net: defxx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: tulip: de2104x: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: dscc4: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: smsc: epic100: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: fec_mpc52xx: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: fsl_ucc_hdlc: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: sun: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: tehuti: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: via-velocity: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
net: broadcom: replace dev_kfree_skb_irq by dev_consume_skb_irq for drop profiles
Yohei Kanemaru (1):
ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation
Yonghong Song (2):
bpf: btf: allow typedef func_proto
tools/bpf: fix test_btf for typedef func_proto case
MAINTAINERS | 21 +++
drivers/isdn/mISDN/timerdev.c | 2 +-
drivers/net/dsa/b53/b53_srab.c | 3 -
drivers/net/dsa/mv88e6xxx/global1_atu.c | 21 +--
drivers/net/ethernet/broadcom/bcmsysport.c | 25 ++-
drivers/net/ethernet/broadcom/bcmsysport.h | 2 +
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8 +-
drivers/net/ethernet/broadcom/sb1250-mac.c | 2 +-
drivers/net/ethernet/cavium/Kconfig | 1 -
drivers/net/ethernet/cisco/enic/enic_main.c | 3 +-
drivers/net/ethernet/dec/tulip/de2104x.c | 2 +-
drivers/net/ethernet/freescale/fec_mpc52xx.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 2 +
drivers/net/ethernet/marvell/skge.c | 6 +-
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 6 +-
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.h | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 4 +
drivers/net/ethernet/mellanox/mlx5/core/en_rep.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 52 ++++---
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 6 +
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 17 ++-
drivers/net/ethernet/qlogic/qed/qed.h | 2 +-
drivers/net/ethernet/qlogic/qed/qed_l2.c | 8 +-
drivers/net/ethernet/qlogic/qed/qed_sp.h | 1 +
drivers/net/ethernet/qlogic/qed/qed_sp_commands.c | 3 +
drivers/net/ethernet/qlogic/qed/qed_spq.c | 15 +-
drivers/net/ethernet/qlogic/qede/qede.h | 5 +-
drivers/net/ethernet/qlogic/qede/qede_fp.c | 13 ++
drivers/net/ethernet/qlogic/qede/qede_main.c | 3 +
drivers/net/ethernet/smsc/epic100.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 14 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 17 ++-
drivers/net/ethernet/sun/cassini.c | 2 +-
drivers/net/ethernet/sun/sunbmac.c | 2 +-
drivers/net/ethernet/sun/sunhme.c | 2 +-
drivers/net/ethernet/tehuti/tehuti.c | 2 +-
drivers/net/ethernet/via/via-velocity.c | 2 +-
drivers/net/fddi/defxx.c | 2 +-
drivers/net/geneve.c | 10 +-
drivers/net/ieee802154/mcr20a.c | 6 +-
drivers/net/ipvlan/ipvlan_main.c | 6 +-
drivers/net/phy/dp83640.c | 13 +-
drivers/net/phy/marvell.c | 16 --
drivers/net/tun.c | 3 +-
drivers/net/virtio_net.c | 171 +++++++++++++++------
drivers/net/wan/dscc4.c | 2 +-
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/intel/iwlwifi/Kconfig | 3 +-
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.c | 40 +++--
drivers/net/wireless/mediatek/mt76/mt76x0/eeprom.h | 2 +-
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 10 +-
drivers/net/wireless/ti/wlcore/sdio.c | 15 +-
drivers/s390/net/qeth_core.h | 3 +-
drivers/s390/net/qeth_core_main.c | 31 ++--
drivers/s390/net/qeth_l2_main.c | 8 +-
drivers/s390/net/qeth_l3_main.c | 3 +
include/linux/filter.h | 21 ++-
include/linux/netdevice.h | 8 +
include/linux/stmmac.h | 1 +
include/net/l3mdev.h | 3 +-
include/net/netfilter/nf_tables.h | 17 ++-
kernel/bpf/btf.c | 3 +-
kernel/bpf/cgroup.c | 2 +-
kernel/bpf/hashtab.c | 4 +-
kernel/bpf/percpu_freelist.c | 41 +++--
kernel/bpf/percpu_freelist.h | 4 +
kernel/bpf/syscall.c | 12 +-
kernel/trace/bpf_trace.c | 14 +-
lib/test_rhashtable.c | 23 ++-
net/batman-adv/bat_v_elp.c | 3 +
net/batman-adv/hard-interface.c | 5 +-
net/batman-adv/soft-interface.c | 2 +
net/core/filter.c | 2 +
net/core/skmsg.c | 3 +-
net/dccp/ccid.h | 4 +-
net/dsa/master.c | 4 +
net/dsa/slave.c | 17 ++-
net/ipv4/ip_gre.c | 7 +-
net/ipv6/ip6_gre.c | 7 +-
net/ipv6/netfilter.c | 4 +-
net/ipv6/seg6_iptunnel.c | 2 +
net/ipv6/sit.c | 3 +-
net/l2tp/l2tp_core.c | 9 +-
net/l2tp/l2tp_core.h | 20 +++
net/l2tp/l2tp_ip.c | 3 +
net/l2tp/l2tp_ip6.c | 3 +
net/mac80211/tx.c | 12 +-
net/netfilter/nf_conntrack_core.c | 16 ++
net/netfilter/nf_tables_api.c | 85 +++++------
net/netfilter/nft_compat.c | 62 +++-----
net/netfilter/nft_dynset.c | 18 +--
net/netfilter/nft_immediate.c | 6 +-
net/netfilter/nft_lookup.c | 18 +--
net/netfilter/nft_objref.c | 18 +--
net/rds/bind.c | 6 +-
net/rxrpc/recvmsg.c | 3 +-
net/sched/cls_flower.c | 6 +-
net/sctp/socket.c | 4 +-
net/sctp/stream.c | 20 +++
net/smc/af_smc.c | 11 +-
net/smc/smc_cdc.c | 21 ++-
net/smc/smc_cdc.h | 34 ++++-
net/smc/smc_clc.c | 2 +-
net/smc/smc_close.c | 9 +-
net/smc/smc_core.c | 6 +-
net/smc/smc_core.h | 20 +++
net/smc/smc_ib.c | 6 +-
net/smc/smc_llc.c | 3 +-
net/smc/smc_pnet.c | 2 +-
net/smc/smc_tx.c | 64 ++++----
net/smc/smc_wr.c | 46 +++++-
net/smc/smc_wr.h | 1 +
net/socket.c | 82 +++++++---
net/vmw_vsock/virtio_transport.c | 29 +++-
net/wireless/ap.c | 2 +
net/wireless/core.h | 2 +
net/wireless/sme.c | 2 +-
tools/bpf/bpftool/common.c | 6 +-
tools/bpf/bpftool/map.c | 33 ++--
tools/bpf/bpftool/prog.c | 5 +-
tools/testing/selftests/bpf/bpf_util.h | 30 ++--
tools/testing/selftests/bpf/test_btf.c | 9 +-
tools/testing/selftests/netfilter/Makefile | 2 +-
tools/testing/selftests/netfilter/config | 2 +-
tools/testing/selftests/netfilter/nft_nat.sh | 762 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
127 files changed, 1802 insertions(+), 544 deletions(-)
create mode 100755 tools/testing/selftests/netfilter/nft_nat.sh
^ permalink raw reply
* Re: [iproute PATCH] ip-link: Fix listing of alias interfaces
From: Phil Sutter @ 2019-02-08 10:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Roopa Prabhu
In-Reply-To: <20190207162436.4452f7ad@hermes.lan>
On Thu, Feb 07, 2019 at 04:24:36PM -0800, Stephen Hemminger wrote:
> On Thu, 7 Feb 2019 14:05:27 +0100
> Phil Sutter <phil@nwl.cc> wrote:
>
> > Commit 50b9950dd9011 ("link dump filter") accidentally broke listing of
> > links in the old alias interface notation:
> >
> > | % ip link show eth0:1
> > | RTNETLINK answers: No such device
> > | Cannot send link get request: No such device
> >
> > Prior to the above commit, link lookup was performed via ifindex
> > returned by if_nametoindex(). The latter uses SIOCGIFINDEX ioctl call
> > which on kernel side causes the colon-suffix to be dropped before doing
> > the interface lookup. Netlink API though doesn't care about that at all.
> > To keep things backward compatible, mimick ioctl API behaviour and drop
> > the colon-suffix prior to sending the RTM_GETLINK request.
> >
> > Fixes: 50b9950dd9011 ("link dump filter")
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
>
> What about mistaken usage where the text after the colon is not a number,
> or has additional colon?
That's completely ignored in ioctl-case as well. See dev_ioctl() in
kernel sources:
| colon = strchr(ifr->ifr_name, ':');
| if (colon)
| *colon = 0;
If you pass 'group 0' to link show command, ioctl code path is taken. It
allows (and drops) arbitrary input after the colon (as long as the total
name doesn't exceed 15 characters).
Cheers, Phil
^ permalink raw reply
* Re: Is advertising of 2500Mbps support must from phy device to set phy at 2500Mbps link speed
From: abhijit @ 2019-02-08 10:37 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190206133858.GF20405@lunn.ch>
Thanks Andrew for your reply. I will have look at IEEE document and c45.
On Wednesday 06 February 2019 07:08 PM, Andrew Lunn wrote:
>> Currently, we don't have any phy drivers. Generic driver doesn't seems to
>> support 2500Mbps.
> Correct. genphy only supports upto 1G. The c45 based genphy_c45 is
> slowly gaining more features and might soon support 2.5G.
>
>> If I have to write the driver, whether it is necessary for
>> phy device to advertise speed of 2500Mbps?
> The user could force it, using the ethool command you suggested. But
> it is the PHY driver which configures this. If you add the driver code
> to force it, you might as well add the driver code to allow it to be
> negotiated.
>
>> Phy is custom phy and is currently under test. If you know any phy device
>> that supports 2500Mbps and whose data sheet is available freely please let
>> me know.
> There are none that i know of with open data sheets. However the IEEE
> standards should be freely available and they describe the registers
> the PHY is expected to have. There are also patches floating around
> which add 2.5G and 5G support to the marvell10g driver. I expect these
> patches to get merged soon, but maybe in a different form to make
> genphy_c45 more generic.
>
> Andrew
^ permalink raw reply
* Re: TC stats / hw offload question
From: Edward Cree @ 2019-02-08 10:26 UTC (permalink / raw)
To: Jamal Hadi Salim, netdev; +Cc: Jiri Pirko, Cong Wang
In-Reply-To: <4cb765dd-453f-3139-bce6-6e0b31167aec@mojatatu.com>
On 06/02/19 02:20, Jamal Hadi Salim wrote:
> The classifiers dont mod the packets. The actions do. And they
> maintain stats on the size on "entry" i.e pre-edit.
Thank you for clearing that up.
> Each action keeps its own counters. If you did something like:
>
> tc match using flower blah \
> action vlan push tag ... \
> action redirect to egress of eth0
>
> And you submited a packet of size x bytes,
> then the "match" would record x bytes.
Sorry, where would it record that? I can't find any stats counters on
the "match" either in the software path or the offload API.
> the "vlan action" would record x bytes.
> the "redirect" would record size x+vlaninfo bytes
> the egress of eth0 would recorr x+vlaninfo bytes
Am I right in thinking that offloaded counters don't do that? As far
as I can tell, the drivers with flower offload all use
tcf_exts_stats_update() which takes a single 'bytes' count and adds
it to all the actions. (Presumably this is pre-edit length.)
-Ed
^ permalink raw reply
* Re: [PATCH net-next v2 2/6] phy: armada38x: add common phy support
From: Kishon Vijay Abraham I @ 2019-02-08 10:24 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Gregory Clement, Jason Cooper,
Sebastian Hesselbarth, Thomas Petazzoni
Cc: devicetree, linux-arm-kernel, netdev
In-Reply-To: <E1grmOM-0000MF-PS@rmk-PC.armlinux.org.uk>
On 07/02/19 9:49 PM, Russell King wrote:
> Add support for the Armada 38x common phy to allow us to change the
> speed of the Ethernet serdes lane. This driver only supports
> manipulation of the speed, it does not support configuration of the
> common phy.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
This patch will conflict with PHY pull request (in the marvell Kconfig and
Makefile). But the resolution should be trivial and should be okay to go via
-net tree.
FWIW
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/phy/marvell/Kconfig | 10 ++
> drivers/phy/marvell/Makefile | 1 +
> drivers/phy/marvell/phy-armada38x-comphy.c | 237 +++++++++++++++++++++++++++++
> 3 files changed, 248 insertions(+)
> create mode 100644 drivers/phy/marvell/phy-armada38x-comphy.c
>
> diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig
> index 6fb4b56e4c14..224ea4e6a46d 100644
> --- a/drivers/phy/marvell/Kconfig
> +++ b/drivers/phy/marvell/Kconfig
> @@ -21,6 +21,16 @@ config PHY_BERLIN_USB
> help
> Enable this to support the USB PHY on Marvell Berlin SoCs.
>
> +config PHY_MVEBU_A38X_COMPHY
> + tristate "Marvell Armada 38x comphy driver"
> + depends on ARCH_MVEBU || COMPILE_TEST
> + depends on OF
> + select GENERIC_PHY
> + help
> + This driver allows to control the comphy, an hardware block providing
> + shared serdes PHYs on Marvell Armada 38x. Its serdes lanes can be
> + used by various controllers (Ethernet, sata, usb, PCIe...).
> +
> config PHY_MVEBU_CP110_COMPHY
> tristate "Marvell CP110 comphy driver"
> depends on ARCH_MVEBU || COMPILE_TEST
> diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile
> index 3975b144f8ec..59b6c03ef756 100644
> --- a/drivers/phy/marvell/Makefile
> +++ b/drivers/phy/marvell/Makefile
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
> obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
> obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
> +obj-$(CONFIG_PHY_MVEBU_A38X_COMPHY) += phy-armada38x-comphy.o
> obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o
> obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
> obj-$(CONFIG_PHY_PXA_28NM_HSIC) += phy-pxa-28nm-hsic.o
> diff --git a/drivers/phy/marvell/phy-armada38x-comphy.c b/drivers/phy/marvell/phy-armada38x-comphy.c
> new file mode 100644
> index 000000000000..3e00bc679d4e
> --- /dev/null
> +++ b/drivers/phy/marvell/phy-armada38x-comphy.c
> @@ -0,0 +1,237 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Russell King, Deep Blue Solutions Ltd.
> + *
> + * Partly derived from CP110 comphy driver by Antoine Tenart
> + * <antoine.tenart@bootlin.com>
> + */
> +#include <linux/delay.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/phy.h>
> +#include <linux/platform_device.h>
> +
> +#define MAX_A38X_COMPHY 6
> +#define MAX_A38X_PORTS 3
> +
> +#define COMPHY_CFG1 0x00
> +#define COMPHY_CFG1_GEN_TX(x) ((x) << 26)
> +#define COMPHY_CFG1_GEN_TX_MSK COMPHY_CFG1_GEN_TX(15)
> +#define COMPHY_CFG1_GEN_RX(x) ((x) << 22)
> +#define COMPHY_CFG1_GEN_RX_MSK COMPHY_CFG1_GEN_RX(15)
> +#define GEN_SGMII_1_25GBPS 6
> +#define GEN_SGMII_3_125GBPS 8
> +
> +#define COMPHY_STAT1 0x18
> +#define COMPHY_STAT1_PLL_RDY_TX BIT(3)
> +#define COMPHY_STAT1_PLL_RDY_RX BIT(2)
> +
> +#define COMPHY_SELECTOR 0xfc
> +
> +struct a38x_comphy;
> +
> +struct a38x_comphy_lane {
> + void __iomem *base;
> + struct a38x_comphy *priv;
> + unsigned int n;
> +
> + int port;
> +};
> +
> +struct a38x_comphy {
> + void __iomem *base;
> + struct device *dev;
> + struct a38x_comphy_lane lane[MAX_A38X_COMPHY];
> +};
> +
> +static const u8 gbe_mux[MAX_A38X_COMPHY][MAX_A38X_PORTS] = {
> + { 0, 0, 0 },
> + { 4, 5, 0 },
> + { 0, 4, 0 },
> + { 0, 0, 4 },
> + { 0, 3, 0 },
> + { 0, 0, 3 },
> +};
> +
> +static void a38x_comphy_set_reg(struct a38x_comphy_lane *lane,
> + unsigned int offset, u32 mask, u32 value)
> +{
> + u32 val;
> +
> + val = readl_relaxed(lane->base + offset) & ~mask;
> + writel(val | value, lane->base + offset);
> +}
> +
> +static void a38x_comphy_set_speed(struct a38x_comphy_lane *lane,
> + unsigned int gen_tx, unsigned int gen_rx)
> +{
> + a38x_comphy_set_reg(lane, COMPHY_CFG1,
> + COMPHY_CFG1_GEN_TX_MSK | COMPHY_CFG1_GEN_RX_MSK,
> + COMPHY_CFG1_GEN_TX(gen_tx) |
> + COMPHY_CFG1_GEN_RX(gen_rx));
> +}
> +
> +static int a38x_comphy_poll(struct a38x_comphy_lane *lane,
> + unsigned int offset, u32 mask, u32 value)
> +{
> + u32 val;
> + int ret;
> +
> + ret = readl_relaxed_poll_timeout_atomic(lane->base + offset, val,
> + (val & mask) == value,
> + 1000, 150000);
> +
> + if (ret)
> + dev_err(lane->priv->dev,
> + "comphy%u: timed out waiting for status\n", lane->n);
> +
> + return ret;
> +}
> +
> +/*
> + * We only support changing the speed for comphys configured for GBE.
> + * Since that is all we do, we only poll for PLL ready status.
> + */
> +static int a38x_comphy_set_mode(struct phy *phy, enum phy_mode mode, int sub)
> +{
> + struct a38x_comphy_lane *lane = phy_get_drvdata(phy);
> + unsigned int gen;
> +
> + if (mode != PHY_MODE_ETHERNET)
> + return -EINVAL;
> +
> + switch (sub) {
> + case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_1000BASEX:
> + gen = GEN_SGMII_1_25GBPS;
> + break;
> +
> + case PHY_INTERFACE_MODE_2500BASEX:
> + gen = GEN_SGMII_3_125GBPS;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + a38x_comphy_set_speed(lane, gen, gen);
> +
> + return a38x_comphy_poll(lane, COMPHY_STAT1,
> + COMPHY_STAT1_PLL_RDY_TX |
> + COMPHY_STAT1_PLL_RDY_RX,
> + COMPHY_STAT1_PLL_RDY_TX |
> + COMPHY_STAT1_PLL_RDY_RX);
> +}
> +
> +static const struct phy_ops a38x_comphy_ops = {
> + .set_mode = a38x_comphy_set_mode,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct phy *a38x_comphy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct a38x_comphy_lane *lane;
> + struct phy *phy;
> + u32 val;
> +
> + if (WARN_ON(args->args[0] >= MAX_A38X_PORTS))
> + return ERR_PTR(-EINVAL);
> +
> + phy = of_phy_simple_xlate(dev, args);
> + if (IS_ERR(phy))
> + return phy;
> +
> + lane = phy_get_drvdata(phy);
> + if (lane->port >= 0)
> + return ERR_PTR(-EBUSY);
> +
> + lane->port = args->args[0];
> +
> + val = readl_relaxed(lane->priv->base + COMPHY_SELECTOR);
> + val = (val >> (4 * lane->n)) & 0xf;
> +
> + if (!gbe_mux[lane->n][lane->port] ||
> + val != gbe_mux[lane->n][lane->port]) {
> + dev_warn(lane->priv->dev,
> + "comphy%u: not configured for GBE\n", lane->n);
> + phy = ERR_PTR(-EINVAL);
> + }
> +
> + return phy;
> +}
> +
> +static int a38x_comphy_probe(struct platform_device *pdev)
> +{
> + struct phy_provider *provider;
> + struct device_node *child;
> + struct a38x_comphy *priv;
> + struct resource *res;
> + void __iomem *base;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + priv->dev = &pdev->dev;
> + priv->base = base;
> +
> + for_each_available_child_of_node(pdev->dev.of_node, child) {
> + struct phy *phy;
> + int ret;
> + u32 val;
> +
> + ret = of_property_read_u32(child, "reg", &val);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "missing 'reg' property (%d)\n",
> + ret);
> + continue;
> + }
> +
> + if (val >= MAX_A38X_COMPHY || priv->lane[val].base) {
> + dev_err(&pdev->dev, "invalid 'reg' property\n");
> + continue;
> + }
> +
> + phy = devm_phy_create(&pdev->dev, child, &a38x_comphy_ops);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + priv->lane[val].base = base + 0x28 * val;
> + priv->lane[val].priv = priv;
> + priv->lane[val].n = val;
> + priv->lane[val].port = -1;
> + phy_set_drvdata(phy, &priv->lane[val]);
> + }
> +
> + dev_set_drvdata(&pdev->dev, priv);
> +
> + provider = devm_of_phy_provider_register(&pdev->dev, a38x_comphy_xlate);
> +
> + return PTR_ERR_OR_ZERO(provider);
> +}
> +
> +static const struct of_device_id a38x_comphy_of_match_table[] = {
> + { .compatible = "marvell,armada-380-comphy" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, a38x_comphy_of_match_table);
> +
> +static struct platform_driver a38x_comphy_driver = {
> + .probe = a38x_comphy_probe,
> + .driver = {
> + .name = "armada-38x-comphy",
> + .of_match_table = a38x_comphy_of_match_table,
> + },
> +};
> +module_platform_driver(a38x_comphy_driver);
> +
> +MODULE_AUTHOR("Russell King <rmk+kernel@armlinux.org.uk>");
> +MODULE_DESCRIPTION("Common PHY driver for Armada 38x SoCs");
> +MODULE_LICENSE("GPL v2");
>
^ permalink raw reply
* RE: [PATCH bpf-next] tools/bpf: add missing strings.h include
From: David Laight @ 2019-02-08 10:23 UTC (permalink / raw)
To: 'Andrii Nakryiko', yhs@fb.com, songliubraving@fb.com,
ast@fb.com, kafai@fb.com, netdev@vger.kernel.org,
kernel-team@fb.com
In-Reply-To: <20190207175027.1950358-1-andriin@fb.com>
From: Andrii Nakryiko
> Sent: 07 February 2019 17:50
>
> Few files in libbpf are using bzero() function (defined in strings.h header), but
> don't include corresponding header. When libbpf is added as a dependency to pahole,
> this undeterministically causes warnings on some machines:
>
> bpf.c:225:2: warning: implicit declaration of function ‘bzero’ [-Wimplicit-function-declaration]
> bzero(&attr, sizeof(attr));
> ^~~~~
Wouldn't it be better to change these to the more portable memset()?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] Add comphy support for Armada 38x
From: Russell King - ARM Linux admin @ 2019-02-08 10:06 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: David Miller, andrew, gregory.clement, jason, kishon,
sebastian.hesselbarth, devicetree, linux-arm-kernel, mark.rutland,
netdev, robh+dt
In-Reply-To: <20190208085821.7556a18d@windsurf>
On Fri, Feb 08, 2019 at 08:58:21AM +0100, Thomas Petazzoni wrote:
> Hello David,
>
> On Thu, 07 Feb 2019 18:10:49 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
> > From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > Date: Thu, 7 Feb 2019 16:18:25 +0000
> >
> > > This series adds support for the comphy for Armada 38x, which allows
> > > these SoCs to use 2500BASE-X mode with appropriate SFP modules.
> > >
> > > Tested on SolidRun Clearfog after updating for the 5.0 merge window
> > > changes.
> >
> > Series applied, thanks Russell.
>
> This series contained:
>
> - Device Tree bindings that had not been ACKed by the DT bindings
> maintainers, one of which should have been merged through the
> drivers/phy maintainer tree.
Actually, it was reviewed by Rob on 3rd December, but I omitted to
add the attributation he sent. So that point is false.
>
> - A brand new drivers/phy driver that had not been ACKed by the
> drivers/phy maintainer.
>
> - Changes to platform Device Tree that should have been merged through
> the platform tree.
>
> Only patches 4/6 and 5/6 should go through the net-next tree, all the
> other patches should have gone through other trees.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] Add comphy support for Armada 38x
From: Russell King - ARM Linux admin @ 2019-02-08 10:04 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Thomas Petazzoni, David Miller, andrew, gregory.clement, jason,
sebastian.hesselbarth, devicetree, linux-arm-kernel, mark.rutland,
netdev, robh+dt
In-Reply-To: <295924f0-1007-4b39-189b-1b21e4bf1b86@ti.com>
On Fri, Feb 08, 2019 at 02:52:26PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On 08/02/19 1:28 PM, Thomas Petazzoni wrote:
> > Hello David,
> >
> > On Thu, 07 Feb 2019 18:10:49 -0800 (PST)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> >> Date: Thu, 7 Feb 2019 16:18:25 +0000
> >>
> >>> This series adds support for the comphy for Armada 38x, which allows
> >>> these SoCs to use 2500BASE-X mode with appropriate SFP modules.
> >>>
> >>> Tested on SolidRun Clearfog after updating for the 5.0 merge window
> >>> changes.
> >>
> >> Series applied, thanks Russell.
> >
> > This series contained:
> >
> > - Device Tree bindings that had not been ACKed by the DT bindings
> > maintainers, one of which should have been merged through the
> > drivers/phy maintainer tree.
> >
> > - A brand new drivers/phy driver that had not been ACKed by the
> > drivers/phy maintainer.
>
> The PHY driver looks good to me. But I think it might still be better to take
> it via PHY tree since there are other Marvell drivers that are getting merged
> and will result in conflicts in Kconfig and Makefile.
... which would have the effect that if the DTS and mvneta changes
are merged ahead of the PHY changes into Linus' tree, mvneta breaks.
Breaking stuff in the merge window is something that needs to be
avoided - that's the exact time that bisects need to work.
Splitting a dependent patch series up for different subsystems to
avoid conflicts is not always a good idea.
Linus has said many times that he's okay dealing with simple
conflicts during the merge window (normally wanting the requester to
at least be aware of the conflict.) Yet, some seem to have fostered
an idea that "conflicts are bad and must be avoided at all costs".
I've sent Linus several pull requests with conflicts during the age
of git, and the conflict resolution diff in the pull request email.
It's *never* been a problem, even if Linus has decided a slightly
different resolution is better.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next] ipvs: Use struct_size() helper
From: Simon Horman @ 2019-02-08 9:56 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Wensong Zhang, Julian Anastasov, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, David S. Miller, netdev,
lvs-devel, netfilter-devel, coreteam, linux-kernel
In-Reply-To: <20190208004456.GA15845@embeddedor>
On Thu, Feb 07, 2019 at 06:44:56PM -0600, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = alloc(size, GFP_KERNEL)
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> size = struct_size(instance, entry, count);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Pablo, could you consider applying this?
> ---
> net/netfilter/ipvs/ip_vs_ctl.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 7d6318664eb2..bcd9112f47d9 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2734,8 +2734,7 @@ do_ip_vs_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
> int size;
>
> get = (struct ip_vs_get_services *)arg;
> - size = sizeof(*get) +
> - sizeof(struct ip_vs_service_entry) * get->num_services;
> + size = struct_size(get, entrytable, get->num_services);
> if (*len != size) {
> pr_err("length: %u != %u\n", *len, size);
> ret = -EINVAL;
> @@ -2776,8 +2775,7 @@ do_ip_vs_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
> int size;
>
> get = (struct ip_vs_get_dests *)arg;
> - size = sizeof(*get) +
> - sizeof(struct ip_vs_dest_entry) * get->num_dests;
> + size = struct_size(get, entrytable, get->num_dests);
> if (*len != size) {
> pr_err("length: %u != %u\n", *len, size);
> ret = -EINVAL;
> --
> 2.20.1
>
^ permalink raw reply
* RE: [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length
From: David Laight @ 2019-02-08 9:53 UTC (permalink / raw)
To: 'Marcelo Ricardo Leitner'
Cc: Julien Gomes, netdev@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-kernel@vger.kernel.org, davem@davemloft.net,
nhorman@tuxdriver.com, vyasevich@gmail.com, lucien.xin@gmail.com
In-Reply-To: <20190207174715.GF13621@localhost.localdomain>
From: 'Marcelo Ricardo Leitner'
> Sent: 07 February 2019 17:47
...
> > > Maybe what we want(ed) here then is explicit versioning, to have the 3
> > > definitions available. Then the application is able to use, say struct
> > > sctp_event_subscribe, and be happy with it, while there is struct
> > > sctp_event_subscribe_v2 and struct sctp_event_subscribe_v3 there too.
> > >
> > > But it's too late for that now because that would break applications
> > > already using the new fields in sctp_event_subscribe.
> >
> > It is probably better to break the recompilation of the few programs
> > that use the new fields (and have them not work on old kernels)
> > than to stop recompilations of old programs stop working on old
> > kernels or have requested new options silently ignored.
>
> I got confused here, not sure what you mean. Seems there is one "stop"
> word too many.
More confusing than I intended...
With the current kernel and headers a 'new program' (one that
needs the new options) will fail to run on an old kernel - which is good.
However a recompilation of an 'old program' (that doesn't use
the new options) will also fail to run on an old kernel - which is bad.
Changing the kernel to ignore extra events flags breaks the 'new'
program.
Versioning the structure now (even though it should have been done
earlier) won't change the behaviour of existing binaries.
However a recompilation of an 'old' program would use the 'old'
structure and work on old kernels.
Attempts to recompile a 'new' program will fail - until the structure
name (or some #define to enable the extra fields) is changed.
Breaking compilations is much better than unexpected run-time
behaviour.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros
From: Eli Britstein @ 2019-02-08 9:33 UTC (permalink / raw)
To: Simon Horman, David Miller
Cc: gvrose8192@gmail.com, pshelar@ovn.org, dev@openvswitch.org,
netdev@vger.kernel.org
In-Reply-To: <20190208075903.so63odmtuvxawija@netronome.com>
On 2/8/2019 9:59 AM, Simon Horman wrote:
> On Mon, Feb 04, 2019 at 12:09:00PM -0800, David Miller wrote:
>> From: Gregory Rose <gvrose8192@gmail.com>
>> Date: Mon, 4 Feb 2019 11:41:29 -0800
>>
>>> On 2/3/2019 1:12 AM, Eli Britstein wrote:
>>>> Declare ovs key structures using macros as a pre-step towards to
>>>> enable retrieving fields information, as a work done in proposed
>>>> commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/
>>>> ("odp-util: Do not rewrite fields with the same values as matched"),
>>>> with no functional change.
>>>>
>>>> Signed-off-by: Eli Britstein <elibr@mellanox.com>
>>>> Reviewed-by: Roi Dayan <roid@mellanox.com>
>>> Obscuring the structures with these macros is awful. I'm opposed but
>>> I see it has already been
>>> accepted upstream so I guess that's that.
>> I am personally in no way obligated to apply this patch to my tree
>> just because "upstream" did, and I absolutely have no plans to do so
>> at this point.
>>
>> This patch is absolutely awful.
> I hate to jump on a bandwagon, but this patch makes the code much
> less readable.
Please review the alternative I have posted:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-February/356000.html
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] Add comphy support for Armada 38x
From: Kishon Vijay Abraham I @ 2019-02-08 9:22 UTC (permalink / raw)
To: Thomas Petazzoni, David Miller
Cc: linux, andrew, gregory.clement, jason, sebastian.hesselbarth,
devicetree, linux-arm-kernel, mark.rutland, netdev, robh+dt
In-Reply-To: <20190208085821.7556a18d@windsurf>
Hi,
On 08/02/19 1:28 PM, Thomas Petazzoni wrote:
> Hello David,
>
> On Thu, 07 Feb 2019 18:10:49 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
>> Date: Thu, 7 Feb 2019 16:18:25 +0000
>>
>>> This series adds support for the comphy for Armada 38x, which allows
>>> these SoCs to use 2500BASE-X mode with appropriate SFP modules.
>>>
>>> Tested on SolidRun Clearfog after updating for the 5.0 merge window
>>> changes.
>>
>> Series applied, thanks Russell.
>
> This series contained:
>
> - Device Tree bindings that had not been ACKed by the DT bindings
> maintainers, one of which should have been merged through the
> drivers/phy maintainer tree.
>
> - A brand new drivers/phy driver that had not been ACKed by the
> drivers/phy maintainer.
The PHY driver looks good to me. But I think it might still be better to take
it via PHY tree since there are other Marvell drivers that are getting merged
and will result in conflicts in Kconfig and Makefile.
Thanks
Kishon
^ permalink raw reply
* [PATCH net-next 2/2] bnxt_en: Remove wake_on_lan parameter support for devlink
From: Vasundhara Volam @ 2019-02-08 9:13 UTC (permalink / raw)
To: davem; +Cc: michael.chan, jiri, netdev
In-Reply-To: <1549617190-387130-1-git-send-email-vasundhara-v.volam@broadcom.com>
Retain the code to register devlink port parameters.
There will be followup patchset to add some port parameters.
Cc: Michael Chan <michael.chan@broadcom.com>
Cc: Michal Kubecek <mkubecek@suse.cz>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 19 +------------------
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 -
2 files changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index a6abfa4..9d2b699 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -37,8 +37,6 @@ enum bnxt_dl_param_id {
NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
{BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK, NVM_OFF_DIS_GRE_VER_CHECK,
BNXT_NVM_SHARED_CFG, 1},
-
- {DEVLINK_PARAM_GENERIC_ID_WOL, NVM_OFF_WOL, BNXT_NVM_PORT_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -72,8 +70,7 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
bytesize = roundup(nvm_param.num_bits, BITS_PER_BYTE) / BITS_PER_BYTE;
switch (bytesize) {
case 1:
- if (nvm_param.num_bits == 1 &&
- nvm_param.id != DEVLINK_PARAM_GENERIC_ID_WOL)
+ if (nvm_param.num_bits == 1)
buf = &val->vbool;
else
buf = &val->vu8;
@@ -167,17 +164,6 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
return 0;
}
-static int bnxt_dl_wol_validate(struct devlink *dl, u32 id,
- union devlink_param_value val,
- struct netlink_ext_ack *extack)
-{
- if (val.vu8 && val.vu8 != DEVLINK_PARAM_WAKE_MAGIC) {
- NL_SET_ERR_MSG_MOD(extack, "WOL type is not supported");
- return -EINVAL;
- }
- return 0;
-}
-
static const struct devlink_param bnxt_dl_params[] = {
DEVLINK_PARAM_GENERIC(ENABLE_SRIOV,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
@@ -203,9 +189,6 @@ static int bnxt_dl_wol_validate(struct devlink *dl, u32 id,
};
static const struct devlink_param bnxt_dl_port_params[] = {
- DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
- bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
- bnxt_dl_wol_validate),
};
int bnxt_dl_register(struct bnxt *bp)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index da065ca..5b6b2c7 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -35,7 +35,6 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
#define NVM_OFF_MSIX_VEC_PER_PF_MAX 108
#define NVM_OFF_MSIX_VEC_PER_PF_MIN 114
-#define NVM_OFF_WOL 152
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_DIS_GRE_VER_CHECK 171
#define NVM_OFF_ENABLE_SRIOV 401
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/2] Revert "devlink: Add a generic wake_on_lan port parameter"
From: Vasundhara Volam @ 2019-02-08 9:13 UTC (permalink / raw)
To: davem; +Cc: michael.chan, jiri, netdev
In-Reply-To: <1549617190-387130-1-git-send-email-vasundhara-v.volam@broadcom.com>
This reverts commit b639583f9e36d044ac1b13090ae812266992cbac.
As per discussion with Jakub Kicinski and Michal Kubecek,
this will be better addressed by soon-too-come ethtool netlink
API with additional indication that given configuration request
is supposed to be persisted.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michal Kubecek <mkubecek@suse.cz>
Suggested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 8 --------
net/core/devlink.c | 5 -----
2 files changed, 13 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index c12ad6e..1dfdd81 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -369,17 +369,12 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MAX,
DEVLINK_PARAM_GENERIC_ID_MSIX_VEC_PER_PF_MIN,
DEVLINK_PARAM_GENERIC_ID_FW_LOAD_POLICY,
- DEVLINK_PARAM_GENERIC_ID_WOL,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
DEVLINK_PARAM_GENERIC_ID_MAX = __DEVLINK_PARAM_GENERIC_ID_MAX - 1,
};
-enum devlink_param_wol_types {
- DEVLINK_PARAM_WAKE_MAGIC = (1 << 0),
-};
-
#define DEVLINK_PARAM_GENERIC_INT_ERR_RESET_NAME "internal_error_reset"
#define DEVLINK_PARAM_GENERIC_INT_ERR_RESET_TYPE DEVLINK_PARAM_TYPE_BOOL
@@ -404,9 +399,6 @@ enum devlink_param_wol_types {
#define DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_NAME "fw_load_policy"
#define DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_TYPE DEVLINK_PARAM_TYPE_U8
-#define DEVLINK_PARAM_GENERIC_WOL_NAME "wake_on_lan"
-#define DEVLINK_PARAM_GENERIC_WOL_TYPE DEVLINK_PARAM_TYPE_U8
-
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 7fbdba5..f064ad3 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -2701,11 +2701,6 @@ static int devlink_nl_cmd_reload(struct sk_buff *skb, struct genl_info *info)
.name = DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_NAME,
.type = DEVLINK_PARAM_GENERIC_FW_LOAD_POLICY_TYPE,
},
- {
- .id = DEVLINK_PARAM_GENERIC_ID_WOL,
- .name = DEVLINK_PARAM_GENERIC_WOL_NAME,
- .type = DEVLINK_PARAM_GENERIC_WOL_TYPE,
- },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 0/2] Revert wake_on_lan devlink parameter
From: Vasundhara Volam @ 2019-02-08 9:13 UTC (permalink / raw)
To: davem; +Cc: michael.chan, jiri, netdev
As per discussion with Jakub Kicinski and Michal Kubecek,
this will be better addressed by soon-too-come ethtool netlink
API with additional indication that given WoL configuration request
is supposed to be persisted.
Retain bnxt_en code for devlink port param table registration.
There will be follow up patches to add some devlink port params
for bnxt_en driver.
Vasundhara Volam (2):
Revert "devlink: Add a generic wake_on_lan port parameter"
bnxt_en: Remove wake_on_lan parameter support for devlink
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 19 +------------------
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 -
include/net/devlink.h | 8 --------
net/core/devlink.c | 5 -----
4 files changed, 1 insertion(+), 32 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH bpf-next 1/6] bpf: Add a bpf_sock pointer to __sk_buff and a bpf_sk_fullsock helper
From: Daniel Borkmann @ 2019-02-08 8:56 UTC (permalink / raw)
To: Martin Lau
Cc: netdev@vger.kernel.org, Alexei Starovoitov, Kernel Team,
Lawrence Brakmo
In-Reply-To: <20190208055601.wwqqi2bpwtfft4nz@kafai-mbp.dhcp.thefacebook.com>
On 02/08/2019 06:56 AM, Martin Lau wrote:
> On Thu, Feb 07, 2019 at 11:21:41PM +0100, Daniel Borkmann wrote:
>> On 02/07/2019 08:27 AM, Martin Lau wrote:
>> [...]
>>> Following up the discussion in the iovisor conf call.
>>>
>>> One of discussion was about:
>>> other than tw, can __sk_buff->sk always return a
>>> fullsock (PTR_TO_SOCKET_OR_NULL). In request_sock case,
>>> it is doable because it can trace back to the listener sock.
>>>
>>> However, that will go back to the sock_common accessing question.
>>> In particular, how to access the sock_common's fields of the
>>> request_sock itself? Those fields in the request_sock are different
>>> from its listener sock. e.g. the skc_daddr and skc_dport.
>>>
>>> Also, if the sock_common fields of tw is needed, it will become weird
>>> because likely a new "struct bpf_tw_sock" is needed which is OK
>>> but all sock_common fields need to be copied from bpf_sock
>>> to bpf_tw_sock.
>>>
>>> I think reading a sk from a ctx should return the
>>> most basic type PTR_TO_SOCK_COMMON_OR_NULL (unless the running
>>> ctx can guarantee that it always has a fullsock).
>>> Currently, it is __sk_buff->sk. Later, sock_ops->sk...etc.
>>> One single 'struct bpf_sock' and limit fullsock field access
>>> at verification time. The bpf_prog then moves down the chain
>>> based on what it needs. It could be fullsock, tcp_sock...etc.
>>>
>>> I think that will be the most flexible way to write bpf_prog
>>> while also avoid having duplicate fields in different
>>> bpf struct in uapi.
>>
>> Ok, thanks for following up and sorry for late reply, lets go with
>> sock_common then. What's the plan to moving forward with accessing
>> full sk in case of req sk? Separate helper or backed into the newly
>> added bpf_sk_fullsock() one? Presumably latter?
> I will add sk_to_full_sk() to bpf_sk_fullsock() and bpf_tcp_sock().
Ok, sounds good, thanks!
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: Change TCA_ACT_* to TCA_ID_* to match that of TCA_ID_POLICE
From: Jiri Pirko @ 2019-02-08 8:39 UTC (permalink / raw)
To: Simon Horman
Cc: Eli Cohen, jhs, xiyou.wangcong, davem, netdev, linux-kernel,
jakub.kicinski, dirk.vandermerwe, francois.theron, quentin.monnet,
john.hurley, edwin.peer
In-Reply-To: <20190208080141.dlksz5dfkufj2sbm@netronome.com>
Fri, Feb 08, 2019 at 09:01:42AM CET, simon.horman@netronome.com wrote:
>On Thu, Feb 07, 2019 at 09:45:49AM +0200, Eli Cohen wrote:
>> Modify the kernel users of the TCA_ACT_* macros to use TCA_ID_*. For
>> example, use TCA_ID_GACT instead of TCA_ACT_GACT. This will align with
>> TCA_ID_POLICE and also differentiates these identifier, used in struct
>> tc_action_ops type field, from other macros starting with TCA_ACT_.
>>
>> To make things clearer, we name the enum defining the TCA_ID_*
>> identifiers and also change the "type" field of struct tc_action to
>> id.
>>
>> Signed-off-by: Eli Cohen <eli@mellanox.com>
>> Acked-by: Jiri Pirko <jiri@mellanox.com>
>
>...
>
>> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
>> index 7ab55f97e7c4..51a0496f78ea 100644
>> --- a/include/uapi/linux/pkt_cls.h
>> +++ b/include/uapi/linux/pkt_cls.h
>> @@ -85,7 +85,7 @@ enum {
>> #define TCA_ACT_SAMPLE 26
>>
>> /* Action type identifiers*/
>> -enum {
>> +enum tca_id {
>> TCA_ID_UNSPEC = 0,
>> TCA_ID_POLICE = 1,
>> TCA_ID_GACT = TCA_ACT_GACT,
>
>This change updates the UAPI. It seems to me that it would not
>break existing users. But I would like to ask if this has been
>given due consideration.
Sure it has. I believe this is UAPI-safe change.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] Add comphy support for Armada 38x
From: Thomas Petazzoni @ 2019-02-08 7:58 UTC (permalink / raw)
To: David Miller
Cc: linux, andrew, gregory.clement, jason, kishon,
sebastian.hesselbarth, devicetree, linux-arm-kernel, mark.rutland,
netdev, robh+dt
In-Reply-To: <20190207.181049.1229639710283404215.davem@davemloft.net>
Hello David,
On Thu, 07 Feb 2019 18:10:49 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Date: Thu, 7 Feb 2019 16:18:25 +0000
>
> > This series adds support for the comphy for Armada 38x, which allows
> > these SoCs to use 2500BASE-X mode with appropriate SFP modules.
> >
> > Tested on SolidRun Clearfog after updating for the 5.0 merge window
> > changes.
>
> Series applied, thanks Russell.
This series contained:
- Device Tree bindings that had not been ACKed by the DT bindings
maintainers, one of which should have been merged through the
drivers/phy maintainer tree.
- A brand new drivers/phy driver that had not been ACKed by the
drivers/phy maintainer.
- Changes to platform Device Tree that should have been merged through
the platform tree.
Only patches 4/6 and 5/6 should go through the net-next tree, all the
other patches should have gone through other trees.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: Change TCA_ACT_* to TCA_ID_* to match that of TCA_ID_POLICE
From: Simon Horman @ 2019-02-08 8:01 UTC (permalink / raw)
To: Eli Cohen
Cc: jhs, xiyou.wangcong, jiri, davem, netdev, linux-kernel,
jakub.kicinski, dirk.vandermerwe, francois.theron, quentin.monnet,
john.hurley, edwin.peer
In-Reply-To: <20190207074549.29861-3-eli@mellanox.com>
On Thu, Feb 07, 2019 at 09:45:49AM +0200, Eli Cohen wrote:
> Modify the kernel users of the TCA_ACT_* macros to use TCA_ID_*. For
> example, use TCA_ID_GACT instead of TCA_ACT_GACT. This will align with
> TCA_ID_POLICE and also differentiates these identifier, used in struct
> tc_action_ops type field, from other macros starting with TCA_ACT_.
>
> To make things clearer, we name the enum defining the TCA_ID_*
> identifiers and also change the "type" field of struct tc_action to
> id.
>
> Signed-off-by: Eli Cohen <eli@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
...
> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> index 7ab55f97e7c4..51a0496f78ea 100644
> --- a/include/uapi/linux/pkt_cls.h
> +++ b/include/uapi/linux/pkt_cls.h
> @@ -85,7 +85,7 @@ enum {
> #define TCA_ACT_SAMPLE 26
>
> /* Action type identifiers*/
> -enum {
> +enum tca_id {
> TCA_ID_UNSPEC = 0,
> TCA_ID_POLICE = 1,
> TCA_ID_GACT = TCA_ACT_GACT,
This change updates the UAPI. It seems to me that it would not
break existing users. But I would like to ask if this has been
given due consideration.
...
^ permalink raw reply
* Re: [ovs-dev] [PATCH net-next V2 1/1] openvswitch: Declare ovs key structures using macros
From: Simon Horman @ 2019-02-08 7:59 UTC (permalink / raw)
To: David Miller; +Cc: gvrose8192, elibr, pshelar, dev, netdev
In-Reply-To: <20190204.120900.211287782199950541.davem@davemloft.net>
On Mon, Feb 04, 2019 at 12:09:00PM -0800, David Miller wrote:
> From: Gregory Rose <gvrose8192@gmail.com>
> Date: Mon, 4 Feb 2019 11:41:29 -0800
>
> >
> > On 2/3/2019 1:12 AM, Eli Britstein wrote:
> >> Declare ovs key structures using macros as a pre-step towards to
> >> enable retrieving fields information, as a work done in proposed
> >> commit in the OVS tree https://patchwork.ozlabs.org/patch/1023406/
> >> ("odp-util: Do not rewrite fields with the same values as matched"),
> >> with no functional change.
> >>
> >> Signed-off-by: Eli Britstein <elibr@mellanox.com>
> >> Reviewed-by: Roi Dayan <roid@mellanox.com>
> >
> > Obscuring the structures with these macros is awful. I'm opposed but
> > I see it has already been
> > accepted upstream so I guess that's that.
>
> I am personally in no way obligated to apply this patch to my tree
> just because "upstream" did, and I absolutely have no plans to do so
> at this point.
>
> This patch is absolutely awful.
I hate to jump on a bandwagon, but this patch makes the code much
less readable.
^ permalink raw reply
* Re: [PATCH] net: stmmac: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized
From: Maxime Ripard @ 2019-02-08 7:44 UTC (permalink / raw)
To: Yizhuo
Cc: csong, zhiyunq, Giuseppe Cavallaro, Alexandre Torgue,
Chen-Yu Tsai, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20190207174623.16712-1-yzhai003@ucr.edu>
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
On Thu, Feb 07, 2019 at 09:46:23AM -0800, Yizhuo wrote:
> In function sun8i_dwmac_set_syscon(), local variable "val" could
> be uninitialized if function regmap_read() returns -EINVAL.
> However, it will be used directly in the if statement, which
> is potentially unsafe.
>
> Signed-off-by: Yizhuo <yzhai003@ucr.edu>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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