The iwlmvm driver supports channel width change in AP mode.  Add the
proper flag.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

fw-dbg code return ret but that variable was either 0
or not initialised. Return 0 always.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 6a951267 ("iwlwifi: mvm: send dbg config hcmds to fw if set in tlv")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

wdev_to_ieee80211_vif() might return NULL.
Check that vif != NULL before dereferencing it.
Signed-off-by: NSharon Dvir <sharon.dvir@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

When the user really wanted a dump on P2P Client, he
coudln't get it because we checked vif->type but didn't
take vif->p2p into account. Fix that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Change vif_event_lock to spinlock from mutex, since this lock is
used in wait_event_timeout() via vif_event_equals(). This caused
a warning report as below.

As far as I can see, this lock protects regions where updating
structure members, not function calls. Also, since those
regions are not called from interrupt handlers (of course, it
was a mutex), spin_lock is used instead of spin_lock_irqsave.

[  186.678550] ------------[ cut here ]------------
[  186.678556] WARNING: CPU: 2 PID: 7140 at /home/mhiramat/ksrc/linux/kernel/sched/core.c:7545 __might_sleep+0x7c/0x80
[  186.678560] do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff980d9090>] prepare_to_wait_event+0x60/0x100
[  186.678560] Modules linked in: brcmfmac xt_CHECKSUM rfcomm ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_addrtype br_netfilter xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_raw ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_filter ip6_tables iptable_raw iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables bnep nls_iso8859_1 i2c_designware_platform i2c_designware_core snd_hda_codec_hdmi snd_hda_codec_realtek dcdbas snd_hda_codec_generic snd_hda_intel snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal intel_powerclamp coretemp
[  186.678594]  snd_pcm crct10dif_pclmul crc32_pclmul aesni_intel aes_x86_64 joydev glue_helper snd_hwdep lrw gf128mul uvcvideo ablk_helper snd_seq_midi cryptd snd_seq_midi_event snd_rawmidi videobuf2_vmalloc videobuf2_memops snd_seq input_leds videobuf2_v4l2 cfg80211 videobuf2_core snd_timer videodev serio_raw btusb snd_seq_device media btrtl rtsx_pci_ms snd mei_me memstick hid_multitouch mei soundcore brcmutil idma64 virt_dma intel_lpss_pci processor_thermal_device intel_soc_dts_iosf hci_uart btbcm btqca btintel bluetooth int3403_thermal dell_smo8800 intel_lpss_acpi intel_lpss int3402_thermal int340x_thermal_zone intel_hid mac_hid int3400_thermal shpchp sparse_keymap acpi_pad acpi_thermal_rel acpi_als kfifo_buf industrialio kvm_intel kvm irqbypass parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq
[  186.678631]  usbhid nouveau ttm i915 rtsx_pci_sdmmc mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops psmouse drm ahci rtsx_pci nvme nvme_core libahci i2c_hid hid pinctrl_sunrisepoint video wmi pinctrl_intel fjes [last unloaded: brcmfmac]
[  186.678646] CPU: 2 PID: 7140 Comm: wpa_supplicant Not tainted 4.8.0-rc1+ #8
[  186.678647] Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 01.02.00 04/07/2016
[  186.678648]  0000000000000000 ffff9d8c64b5b900 ffffffff98442f23 ffff9d8c64b5b950
[  186.678651]  0000000000000000 ffff9d8c64b5b940 ffffffff9808b22b 00001d790000000d
[  186.678653]  ffffffff98c75e78 000000000000026c 0000000000000000 ffff9d8c2706d058
[  186.678655] Call Trace:
[  186.678659]  [<ffffffff98442f23>] dump_stack+0x85/0xc2
[  186.678666]  [<ffffffff9808b22b>] __warn+0xcb/0xf0
[  186.678668]  [<ffffffff9808b29f>] warn_slowpath_fmt+0x4f/0x60
[  186.678671]  [<ffffffff980d9090>] ? prepare_to_wait_event+0x60/0x100
[  186.678672]  [<ffffffff980d9090>] ? prepare_to_wait_event+0x60/0x100
[  186.678674]  [<ffffffff980b922c>] __might_sleep+0x7c/0x80
[  186.678680]  [<ffffffff988b0853>] mutex_lock_nested+0x33/0x3b0
[  186.678682]  [<ffffffff980e5d8d>] ? trace_hardirqs_on+0xd/0x10
[  186.678689]  [<ffffffffc0c57d2d>] brcmf_cfg80211_wait_vif_event+0xcd/0x130 [brcmfmac]
[  186.678691]  [<ffffffff980d9190>] ? wake_atomic_t_function+0x60/0x60
[  186.678697]  [<ffffffffc0c628e9>] brcmf_p2p_del_vif+0xf9/0x220 [brcmfmac]
[  186.678702]  [<ffffffffc0c57fab>] brcmf_cfg80211_del_iface+0x21b/0x270 [brcmfmac]
[  186.678716]  [<ffffffffc0b0539e>] nl80211_del_interface+0xfe/0x3a0 [cfg80211]
[  186.678718]  [<ffffffff987ca335>] genl_family_rcv_msg+0x1b5/0x370
[  186.678720]  [<ffffffff980e5d8d>] ? trace_hardirqs_on+0xd/0x10
[  186.678721]  [<ffffffff987ca56d>] genl_rcv_msg+0x7d/0xb0
[  186.678722]  [<ffffffff987ca4f0>] ? genl_family_rcv_msg+0x370/0x370
[  186.678724]  [<ffffffff987c9a47>] netlink_rcv_skb+0x97/0xb0
[  186.678726]  [<ffffffff987ca168>] genl_rcv+0x28/0x40
[  186.678727]  [<ffffffff987c93c3>] netlink_unicast+0x1d3/0x2f0
[  186.678729]  [<ffffffff987c933b>] ? netlink_unicast+0x14b/0x2f0
[  186.678731]  [<ffffffff987c97cb>] netlink_sendmsg+0x2eb/0x3a0
[  186.678733]  [<ffffffff9876dad8>] sock_sendmsg+0x38/0x50
[  186.678734]  [<ffffffff9876e4df>] ___sys_sendmsg+0x27f/0x290
[  186.678737]  [<ffffffff9828b935>] ? mntput_no_expire+0x5/0x3f0
[  186.678739]  [<ffffffff9828b9be>] ? mntput_no_expire+0x8e/0x3f0
[  186.678741]  [<ffffffff9828b935>] ? mntput_no_expire+0x5/0x3f0
[  186.678743]  [<ffffffff9828bd44>] ? mntput+0x24/0x40
[  186.678744]  [<ffffffff98267830>] ? __fput+0x190/0x200
[  186.678746]  [<ffffffff9876f125>] __sys_sendmsg+0x45/0x80
[  186.678748]  [<ffffffff9876f172>] SyS_sendmsg+0x12/0x20
[  186.678749]  [<ffffffff988b5680>] entry_SYSCALL_64_fastpath+0x23/0xc1
[  186.678751]  [<ffffffff980e2b8f>] ? trace_hardirqs_off_caller+0x1f/0xc0
[  186.678752] ---[ end trace e224d66c5d8408b5 ]---
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Check rtnl_lock is locked in brcmf_p2p_ifp_removed() by passing
rtnl_locked flag. Actually the caller brcmf_del_if() checks whether
the rtnl_lock is locked, but doesn't pass it to brcmf_p2p_ifp_removed().

Without this fix, wpa_supplicant goes softlockup with rtnl_lock
holding (this means all other process using netlink are locked up too)

e.g.
[ 4495.876627] INFO: task wpa_supplicant:7307 blocked for more than 10 seconds.
[ 4495.876632]       Tainted: G        W       4.8.0-rc1+ #8
[ 4495.876635] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4495.876638] wpa_supplicant  D ffff974c647b39a0     0  7307      1 0x00000000
[ 4495.876644]  ffff974c647b39a0 0000000000000000 ffff974c00000000 ffff974c7dc59c58
[ 4495.876651]  ffff974c6b7417c0 ffff974c645017c0 ffff974c647b4000 ffffffff86f16c08
[ 4495.876657]  ffff974c645017c0 0000000000000246 00000000ffffffff ffff974c647b39b8
[ 4495.876664] Call Trace:
[ 4495.876671]  [<ffffffff868aeccc>] schedule+0x3c/0x90
[ 4495.876676]  [<ffffffff868af065>] schedule_preempt_disabled+0x15/0x20
[ 4495.876682]  [<ffffffff868b0996>] mutex_lock_nested+0x176/0x3b0
[ 4495.876686]  [<ffffffff867a2067>] ? rtnl_lock+0x17/0x20
[ 4495.876690]  [<ffffffff867a2067>] rtnl_lock+0x17/0x20
[ 4495.876720]  [<ffffffffc0ae9a5d>] brcmf_p2p_ifp_removed+0x4d/0x70 [brcmfmac]
[ 4495.876741]  [<ffffffffc0aebde6>] brcmf_remove_interface+0x196/0x1b0 [brcmfmac]
[ 4495.876760]  [<ffffffffc0ae9901>] brcmf_p2p_del_vif+0x111/0x220 [brcmfmac]
[ 4495.876777]  [<ffffffffc0adefab>] brcmf_cfg80211_del_iface+0x21b/0x270 [brcmfmac]
[ 4495.876820]  [<ffffffffc097b39e>] nl80211_del_interface+0xfe/0x3a0 [cfg80211]
[ 4495.876825]  [<ffffffff867ca335>] genl_family_rcv_msg+0x1b5/0x370
[ 4495.876832]  [<ffffffff860e5d8d>] ? trace_hardirqs_on+0xd/0x10
[ 4495.876836]  [<ffffffff867ca56d>] genl_rcv_msg+0x7d/0xb0
[ 4495.876839]  [<ffffffff867ca4f0>] ? genl_family_rcv_msg+0x370/0x370
[ 4495.876846]  [<ffffffff867c9a47>] netlink_rcv_skb+0x97/0xb0
[ 4495.876849]  [<ffffffff867ca168>] genl_rcv+0x28/0x40
[ 4495.876854]  [<ffffffff867c93c3>] netlink_unicast+0x1d3/0x2f0
[ 4495.876860]  [<ffffffff867c933b>] ? netlink_unicast+0x14b/0x2f0
[ 4495.876866]  [<ffffffff867c97cb>] netlink_sendmsg+0x2eb/0x3a0
[ 4495.876870]  [<ffffffff8676dad8>] sock_sendmsg+0x38/0x50
[ 4495.876874]  [<ffffffff8676e4df>] ___sys_sendmsg+0x27f/0x290
[ 4495.876882]  [<ffffffff8628b935>] ? mntput_no_expire+0x5/0x3f0
[ 4495.876888]  [<ffffffff8628b9be>] ? mntput_no_expire+0x8e/0x3f0
[ 4495.876894]  [<ffffffff8628b935>] ? mntput_no_expire+0x5/0x3f0
[ 4495.876899]  [<ffffffff8628bd44>] ? mntput+0x24/0x40
[ 4495.876904]  [<ffffffff86267830>] ? __fput+0x190/0x200
[ 4495.876909]  [<ffffffff8676f125>] __sys_sendmsg+0x45/0x80
[ 4495.876914]  [<ffffffff8676f172>] SyS_sendmsg+0x12/0x20
[ 4495.876918]  [<ffffffff868b5680>] entry_SYSCALL_64_fastpath+0x23/0xc1
[ 4495.876924]  [<ffffffff860e2b8f>] ? trace_hardirqs_off_caller+0x1f/0xc0
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Acked-by: NRafał Miłecki <rafal@milecki.pl>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

A station pointer can be passed to the driver on tx, before it has been
marked as associated. Since ath9k_sta_state was initializing the entry
too late, it resulted in some spurious crashes.

Fixes: df3c6eb3 ("ath9k: Use sta_state() callback")
Cc: stable@vger.kernel.org
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

For pure station mode, iter_data.primary_beacon_vif was used and passed
to ath_beacon_config, but not set to the station vif.
This was causing the following warning:

[  100.310919] ------------[ cut here ]------------
[  100.315683] WARNING: CPU: 0 PID: 7 at compat-wireless-2016-06-20/drivers/net/wireless/ath/ath9k/beacon.c:642 ath9k_calculate_summary_state+0x250/0x60c [ath9k]()
[  100.402028] CPU: 0 PID: 7 Comm: kworker/u2:1 Tainted: G        W       4.4.15 #5
[  100.409676] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
[  100.415351] Stack : 8736e98c 870b4b20 87a25b54 800a6800 8782a080 80400d63 8039b96c 00000007
[  100.415351]    803c5edc 87875914 80400000 800a47cc 87a25b54 800a6800 803a0fd8 80400000
[  100.415351]    00000003 87875914 80400000 80094ae0 87a25b54 8787594c 00000000 801ef308
[  100.415351]    803ffe70 801ef300 87193d58 87b3a400 87b3ad00 70687930 00000000 00000000
[  100.415351]    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  100.415351]    ...
[  100.451703] Call Trace:
[  100.454235] [<800a6800>] vprintk_default+0x24/0x30
[  100.459110] [<800a47cc>] printk+0x2c/0x38
[  100.463190] [<800a6800>] vprintk_default+0x24/0x30
[  100.468072] [<80094ae0>] print_worker_info+0x148/0x174
[  100.473378] [<801ef308>] serial8250_console_putchar+0x0/0x44
[  100.479122] [<801ef300>] wait_for_xmitr+0xc4/0xcc
[  100.484014] [<87193d58>] ieee80211_ibss_leave+0xb90/0x1900 [mac80211]
[  100.490590] [<80081604>] warn_slowpath_common+0xa0/0xd0
[  100.495922] [<801a359c>] dump_stack+0x14/0x28
[  100.500350] [<80071a00>] show_stack+0x50/0x84
[  100.504784] [<80081604>] warn_slowpath_common+0xa0/0xd0
[  100.510106] [<87024c60>] ath9k_calculate_summary_state+0x250/0x60c [ath9k]
[  100.517105] [<800816b8>] warn_slowpath_null+0x18/0x24
[  100.522256] [<87024c60>] ath9k_calculate_summary_state+0x250/0x60c [ath9k]
[  100.529273] [<87025418>] ath9k_set_txpower+0x148/0x498 [ath9k]
[  100.535302] [<871d2c64>] cleanup_module+0xa74/0xd4c [mac80211]
[  100.541237] [<801ef308>] serial8250_console_putchar+0x0/0x44
[  100.547042] [<800a5d18>] wake_up_klogd+0x54/0x68
[  100.551730] [<800a6650>] vprintk_emit+0x404/0x43c
[  100.556623] [<871b9db8>] ieee80211_sta_rx_notify+0x258/0x32c [mac80211]
[  100.563475] [<871ba6a4>] ieee80211_sta_rx_queued_mgmt+0x63c/0x734 [mac80211]
[  100.570693] [<871aa49c>] ieee80211_tx_prepare_skb+0x210/0x230 [mac80211]
[  100.577609] [<800af5d4>] mod_timer+0x15c/0x190
[  100.582220] [<871ba8b8>] ieee80211_sta_work+0xfc/0xe1c [mac80211]
[  100.588539] [<871940b4>] ieee80211_ibss_leave+0xeec/0x1900 [mac80211]
[  100.595122] [<8009ec84>] dequeue_task_fair+0x44/0x130
[  100.600281] [<80092a34>] process_one_work+0x1f8/0x334
[  100.605454] [<80093830>] worker_thread+0x2b4/0x408
[  100.610317] [<8009357c>] worker_thread+0x0/0x408
[  100.615019] [<8009357c>] worker_thread+0x0/0x408
[  100.619705] [<80097b68>] kthread+0xdc/0xe8
[  100.623886] [<80097a8c>] kthread+0x0/0xe8
[  100.627961] [<80060878>] ret_from_kernel_thread+0x14/0x1c
[  100.633448]
[  100.634956] ---[ end trace aafbe57e9ae6862f ]---

Fixes: cfda2d8e ("ath9k: Fix beacon configuration for addition/removal of interfaces")
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>

Sometimes host prepares and downloads a large amsdu packet to firmware
which leads to a memory corruption in firmware.
The reason is __dev_alloc_skb() may allocate larger buffer than required
size. This patch solves the problem by checking "adapter->tx_buf_size"
instead of relying on skb_tailroom().
Signed-off-by: NCathy Luo <cluo@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

As pointed out by Jamal, an action could be shared by
multiple filters, so we can't use list to chain them
any more after we get rid of the original tc_action.
Instead, we could just save pointers to these actions
in tcf_exts, since they are refcount'ed, so convert
the list to an array of pointers.

The "ugly" part is the action API still accepts list
as a parameter, I just introduce a helper function to
convert the array of pointers to a list, instead of
relying on the C99 feature to iterate the array.

Fixes: a85a970a ("net_sched: move tc_action into tcf_common")
Reported-by: NJamal Hadi Salim <jhs@mojatatu.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
Acked-by: NJamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When packets enter the device they are classified to a priority group
(PG) buffer based on their PCP value. After their egress port and
traffic class are determined they are moved to the switch's shared
buffer and await transmission, if:

(Ingress{Port}.Usage < Thres && Ingress{Port,PG}.Usage < Thres &&
 Egress{Port}.Usage < Thres && Egress{Port,TC}.Usage < Thres)
||
(Ingress{Port}.Usage < Min || Ingress{Port,PG} < Min ||
 Egress{Port}.Usage < Min || Egress{Port,TC}.Usage < Min)

Packets scheduled to transmission through CPU port (trapped to CPU) use
traffic class 7, which has a zero maximum and minimum quotas. However,
when such packets arrive from PG 0 they are admitted to the shared
buffer as PG 0 has a non-zero minimum quota.

Allow all packets to be trapped to the CPU - regardless of the PG they
were classified to - by assigning a 10KB minimum quota for CPU port and
TC7.

Fixes: 8e8dfe9f ("mlxsw: spectrum: Add IEEE 802.1Qaz ETS support")
Reported-by: NTamir Winetroub <tamirw@mellanox.com>
Tested-by: NTamir Winetroub <tamirw@mellanox.com>
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Before destroying the 802.1Q FID we should first remove the VID-to-FID
mapping. This makes mlxsw_sp_fid_destroy() symmetric with regards to
mlxsw_sp_fid_create().

Fixes: 14d39461 ("mlxsw: spectrum: Use per-FID struct for the VLAN-aware bridge")
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While going over the code I noticed we are missing two rollbacks in the
port's creation error path. Add them and adjust the place of one of them
in the port's removal sequence so that both are symmetric.

Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Ralue pack function needs to set op, otherwise it is 0 for add always.

Fixes: d5a1c749 ("mlxsw: reg: Add Router Algorithmic LPM Unicast Entry Register definition")
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

One of the conditions to generate an ICMP Redirect Message is that "the
packet is being forwarded out the same physical interface that it was
received from" (RFC 1812).

Therefore, we need to be able to trap such packets and let the kernel
decide what to do with them.

For each RIF, enable the loop-back filter, which will raise the LBERROR
trap whenever the ingress RIF equals the egress RIF.

Fixes: 99724c18 ("mlxsw: spectrum: Introduce support for router interfaces")
Reported-by: NIlan Tayari <ilant@mellanox.com>
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add the following traps:

1) MTU Error: Trap packets whose size is bigger than the egress RIF's
MTU. If DF bit isn't set, traffic will continue to be routed in slow
path.

2) TTL Error: Trap packets whose TTL expired. This allows traceroute to
work properly.

3) OSPF packets.

Fixes: 7b27ce7b ("mlxsw: spectrum: Add traps needed for router implementation")
Signed-off-by: NElad Raz <eladr@mellanox.com>
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit bbf2a475 ("mlxsw: spectrum: Initialize ports at the end of
init sequence") moved ports initialization to the end of the init
sequence, which means ports are the first to be removed during fini.

Since the FDB delayed work is still active when ports are removed it's
possible for it to process FDB notifications of inactive ports,
resulting in a warning message.

Fix that by marking ports as inactive only after unregistering them. The
NETDEV_UNREGISTER event will invoke bridge's driver port removal
sequence that will cause the FDB (and FDB notifications) to be flushed.

Fixes: bbf2a475 ("mlxsw: spectrum: Initialize ports at the end of init sequence")
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After registering a netdevice it's possible for user space applications
to configure an IP address on it. From the driver's perspective, this
means a router interface (RIF) should be created for the PVID vPort.

Therefore, we must create the PVID vPort before registering the
netdevice.

Fixes: 99724c18 ("mlxsw: spectrum: Introduce support for router interfaces")
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, when device configuration fails we emit errors to the kernel
log despite the fact we already get these from the EMAD transaction
layer, so remove them.

In addition to being unnecessary, removing these error messages will
allow us to reuse mlxsw_sp_port_add_vid() to create the PVID vPort
before registering the netdevice.

Fixes: 99724c18 ("mlxsw: spectrum: Introduce support for router interfaces")
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When removing a VLAN filter from the device we shouldn't return upon the
first error we encounter, as otherwise we'll have resources that will
never be freed nor used.

Instead, we should keep trying to free as much resources as possible in
a best effort mode.

Remove the error message as well, since we already get these from the
EMAD transaction code.

Fixes: 99724c18 ("mlxsw: spectrum: Introduce support for router interfaces")
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The i40e driver was causing a kernel panic when
non-contiguous Traffic Classes, or Traffic Classes not
starting with TC0, were configured on a link partner switch.
i40e does not support non-contiguous TCs.

To fix this, the patch changes the logic when determining
the total number of TCs enabled.  Before, this would use the
highest TC number enabled and assume that all TCs below it were
also enabled.  Now, we create a bitmask of enabled TCs and scan
it to determine not only the number of TCs, but also if the set
of enabled TCs starts at zero and is contiguous.  If not, then
DCB is disabled by only returning one TC.
Signed-off-by: NDave Ertman <david.m.ertman@intel.com>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Back when I submitted the GSO code I messed up and dropped the support for
disabling the VLAN tag filtering via the feature bit.  This patch
re-enables the use of the NETIF_F_HW_VLAN_CTAG_FILTER to enable/disable the
VLAN filtering independent of toggling promiscuous mode.

Fixes: b83e3010 ("ixgbe/ixgbevf: Add support for GSO partial")
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When I was adding the code for enabling VLAN promiscuous mode with SR-IOV
enabled I had inadvertently left the VLNCTRL.VFE bit unchanged as I has
assumed there was code in another path that was setting it when we enabled
SR-IOV.  This wasn't the case and as a result we were just disabling VLAN
filtering for all the VFs apparently.

Also the previous patches were always clearing CFIEN which was always set
to 0 by the hardware anyway so I am dropping the redundant bit clearing.

Fixes: 16369564 ("ixgbe: Add support for VLAN promiscuous with SR-IOV")
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used
as a PTP slave experiences random ~10 hour clock jumps, which are resolved
if the same workaround for the 82574 and 82583 is employed, so set the
appropriate flag2 in e1000_pch_lpt_info too.
Reported-by: NRupesh Patel <rupatel@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This is prepatory work for an expanding list of adapter families that have
occasional ~10 hour clock jumps when being used for PTP. Factor out the
sanitization function and convert to using a feature (bug) flag, per
suggestion from Jesse Brandeburg.

Littering functional code with device-specific checks is much messier than
simply checking a flag, and having device-specific init set flags as needed.
There are probably a number of other cases in the e1000e code that
could/should be converted similarly.
Suggested-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Fix PHY delay compensation math in igb_ptp_tx_hwtstamp() and
igb_ptp_rx_rgtstamp. Add PHY delay compensation in
igb_ptp_rx_pktstamp().

In the IGB driver, there are two functions that retrieve timestamps
received by the PHY - igb_ptp_rx_rgtstamp() and igb_ptp_rx_pktstamp().
The previous commit only changed igb_ptp_rx_rgtstamp(), and the change
was incorrect.

There are two instances in which PHY delay compensations should be
made:

- Before the packet transmission over the PHY, the latency between
  when the packet is timestamped and transmission of the packets,
  should be an add operation, but it is currently a subtract.

- After the packets are received from the PHY, the latency between
  the receiving and timestamping of the packets should be a subtract
  operation, but it is currently an add.
Signed-off-by: NKshitiz Gupta <kshitiz.gupta@ni.com>
Fixes: 3f544d2a (igb: adjust ptp timestamps for tx/rx latency)
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

net: ethernet: mediatek: fix runtime warning raised by inconsistent struct device pointers passed to DMA API

Runtime warning occurs if DMA-API debug feature is enabled that would be
raised by pointers passed to DMA API as arguments to inconsistent struct
device objects, so that the patch makes them usage aligned between DMA
operations such as dma_map_*() and dma_unmap_*() to eliminate the warning.
Signed-off-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 08ef55c6
("net-next: mediatek: fix gigabit and flow control advertisement")
had supported proper flow control settings for GMAC1. But for GMAC0,

1.GMAC0 shares the common logic with GMAC1 inside mtk_phy_link_adjust()
to adapt various settings for the target phy.

2.GMAC0 uses fixed-phy to connect to a builtin gigabit switch with
fixed link speed as commit 0c72c50f
("net-next: mediatek: add fixed-phy support") describes.

3.However, fixed-phy doesn't enable SUPPORTED_Pause & SUPPORTED_Asym_Pause
supported flag on default that would cause mtk_phy_link_adjust() not to
enable flow control setting on GMAC0 properly and cause packet dropped
when high traffic.

Due to these reasons, the patch adds SUPPORTED_Pause & SUPPORTED_Asym_Pause
supported flags on fixed-phy used by the driver to have proper handling on
the both GMAC with the shared common logic.
Signed-off-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The patch fixes up the incorrect setup of reduced MII (RMII) on GMAC
and adds the supplement for the setup of reverse MII (REVMII) on GMAC
, and rearranges the error handling for invalid PHY argument.
Signed-off-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Bonding driver sets IFF_BONDING on both master (the bonding device) and
slave (the real NIC) devices and in netvsc_netdev_event() we want to skip
master devices only. Currently, there is an uncertainty when a slave
interface is removed: if bonding module comes first in netdev_chain it
clears IFF_BONDING flag on the netdev and netvsc_netdev_event() correctly
handles NETDEV_UNREGISTER event, but in case netvsc comes first on the
chain it sees the device with IFF_BONDING still attached and skips it. As
we still hold vf_netdev pointer to the device we crash on the next inject.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We're not guaranteed to see NETDEV_REGISTER/NETDEV_UNREGISTER notifications
only once per VF but we increase/decrease module refcount unconditionally.
Check vf_netdev to make sure we don't take/release it twice. We presume
that only one VF per netvsc device may exist.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We reset vf_inject on VF going down (netvsc_vf_down()) but we don't on
VF removal (netvsc_unregister_vf()) so vf_inject stays 'true' while
vf_netdev is already NULL and we're trying to inject packets into NULL
net device in netvsc_recv_callback() causing kernel to crash.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Here is a deadlock scenario:
- netvsc_vf_up() schedules netvsc_notify_peers() work and quits.
- netvsc_vf_down() runs before netvsc_notify_peers() gets executed. As it
  is being executed from netdev notifier chain we hold rtnl lock when we
  get here.
- we enter while (atomic_read(&net_device_ctx->vf_use_cnt) != 0) loop and
  wait till netvsc_notify_peers() drops vf_use_cnt.
- netvsc_notify_peers() starts on some other CPU but netdev_notify_peers()
  will hang on rtnl_lock().
- deadlock!

Instead of introducing additional synchronization I suggest we drop
gwrk.dwrk completely and call NETDEV_NOTIFY_PEERS directly. As we're
acting under rtnl lock this is legitimate.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

struct netvsc_device is not suitable for storing VF information as this
structure is being destroyed on MTU change / set channel operation (see
rndis_filter_device_remove()). Move all VF related stuff to struct
net_device_context which is persistent.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In mlxsw_sp_router_fib4_add_info_destroy(), the fib_entry pointer is used
after it has been freed by mlxsw_sp_fib_entry_destroy(). Use a temporary
variable to fix this.

Fixes: 61c503f9 ("mlxsw: spectrum_router: Implement fib4 add/del switchdev obj ops")
Signed-off-by: NVincent Stehlé <vincent.stehle@laposte.net>
Cc: Jiri Pirko <jiri@mellanox.com>
Acked-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The idea for type_check in dev_get_nest_level() was to count the number
of nested devices of the same type (currently, only macvlan or vlan
devices).
This prevented the false positive lockdep warning on configurations such
as:

eth0 <--- macvlan0 <--- vlan0 <--- macvlan1

However, this doesn't prevent a warning on a configuration such as:

eth0 <--- macvlan0 <--- vlan0
eth1 <--- vlan1 <--- macvlan1

In this case, all the locks end up with a nesting subclass of 1, so
lockdep thinks that there is still a deadlock:

- in the first case we have (macvlan_netdev_addr_lock_key, 1) and then
  take (vlan_netdev_xmit_lock_key, 1)
- in the second case, we have (vlan_netdev_xmit_lock_key, 1) and then
  take (macvlan_netdev_addr_lock_key, 1)

By removing the linktype check in dev_get_nest_level() and always
incrementing the nesting depth, lockdep considers this configuration
valid.
Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, trying to setup a vlan over a macsec device, or other
combinations of devices, triggers a lockdep warning.

Use netdev_lockdep_set_classes and ndo_get_lock_subclass, similar to
what macvlan does.
Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds the missing of_node_put() after finishing the usage
of of_parse_phandle() or of_node_get() used by fixed_phy.
Signed-off-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

To fix runtime warning with lockdep is enabled due that u64_stats_sync
is not initialized well, so add it.
Signed-off-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When CONFIG_NET_DSA_HWMON is disabled, we get warnings about two unused
functions whose only callers are all inside of an #ifdef:

drivers/net/dsa/mv88e6xxx.c:3257:12: 'mv88e6xxx_mdio_page_write' defined but not used [-Werror=unused-function]
drivers/net/dsa/mv88e6xxx.c:3244:12: 'mv88e6xxx_mdio_page_read' defined but not used [-Werror=unused-function]

This adds another ifdef around the function definitions. The warnings
appeared after the functions were marked 'static', but the problem
was already there before that.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 57d32310 ("net: dsa: mv88e6xxx: fix style issues")
Reviewed-by: NVivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>