- 07 Sep, 2019 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2019-09-05 This series contains updates to ice driver. Brett fixes the setting of num_q_vectors by using the maximum number between the allocated transmit and receive queues. Anirudh simplifies the code to use a helper function to return the main VSI, which is the first element in the pf->vsi array. Adds a pointer check to prevent a NULL pointer dereference. Adds a check to ensure we do not initialize DCB on devices that are not DCB capable. Does some housekeeping on the code to remove unnecessary indirection and reduce the PF structure by removing elements that are not needed since the values they were storing can be readily gotten from ice_get_avail_*_count()'s. Updates the printed strings to make it easier to search the logs for driver capabilities. Jesse cleans up unnecessary function arguments. Updated the code to use prefetch() to add some efficiency to the driver to avoid a cache miss. Did some housekeeping on the code to remove the configurable transmit work limit via ethtool which ended up creating performance overhead. Made additional performance enhancements by updating the driver to start out with a reasonable number of descriptors by changing the default to 2048. Mitch fixes the reset logic for VFs by clearing VF_MBX_ARQLEN register when the source of the reset is not PFR. Lukasz updates the driver to include a similar fix for the i40e driver by reporting link down for VF's when the PF queues are not enabled. Akeem updates the driver to report the VF link status once we get VF resources so that we can reflect the link status similarly to how the PF reports link speed. Ashish updates the transmit context structure based on recent changes to the hardware specification. Dave updates the DCB logic to allow a delayed registration for MIB change events so that the driver is not accepting events before it is ready for them. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2019-09-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 5.4 Second set of patches for 5.4. Lots of changes for iwlwifi and mt76, but also smaller changes to other drivers. Major changes: iwlwifi * remove broken and unused runtime power management mode for PCIe devices, removes IWLWIFI_PCIE_RTPM Kconfig option as well * support new ACPI value for per-platform antenna gain * support for single antenna diversity * support for new WoWLAN FW API brcmfmac * add reset debugfs file for testing firmware restart mt76 * DFS pattern detector for mt7615 (DFS channels not enabled yet) * Channel Switch Announcement (CSA) support for mt7615 * new device support for mt76x0 * support for more ciphers in mt7615 * smart carrier sense on mt7615 * survey support on mt7615 * multiple interfaces on mt76x02u rtw88 * enable MSI interrupt ==================== Signed-off-by:
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2019-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Patches intended for v5.4 * Remove (broken) d0i3 support; * Debug infrastructure work continues; * Bump support FW API version to 50; * Fix for the SN value in certain suspend/resume situations; * Some work on new FW scan APIs; * Work on LTR FW APIs; * New FW channel-switch support; * Support new ACPI value for per-platform antenna gain; * Support for single antenna diversity; * Support for new WoWLAN FW API; * Initial refactoring of the device selection code; * A bunch of clean-ups; * Other small fixes and improvements;
-
- 06 Sep, 2019 37 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Daniel Borkmann says: ==================== The following pull-request contains BPF updates for your *net-next* tree. The main changes are: 1) Add the ability to use unaligned chunks in the AF_XDP umem. By relaxing where the chunks can be placed, it allows to use an arbitrary buffer size and place whenever there is a free address in the umem. Helps more seamless DPDK AF_XDP driver integration. Support for i40e, ixgbe and mlx5e, from Kevin and Maxim. 2) Addition of a wakeup flag for AF_XDP tx and fill rings so the application can wake up the kernel for rx/tx processing which avoids busy-spinning of the latter, useful when app and driver is located on the same core. Support for i40e, ixgbe and mlx5e, from Magnus and Maxim. 3) bpftool fixes for printf()-like functions so compiler can actually enforce checks, bpftool build system improvements for custom output directories, and addition of 'bpftool map freeze' command, from Quentin. 4) Support attaching/detaching XDP programs from 'bpftool net' command, from Daniel. 5) Automatic xskmap cleanup when AF_XDP socket is released, and several barrier/{read,write}_once fixes in AF_XDP code, from Björn. 6) Relicense of bpf_helpers.h/bpf_endian.h for future libbpf inclusion as well as libbpf versioning improvements, from Andrii. 7) Several new BPF kselftests for verifier precision tracking, from Alexei. 8) Several BPF kselftest fixes wrt endianess to run on s390x, from Ilya. 9) And more BPF kselftest improvements all over the place, from Stanislav. 10) Add simple BPF map op cache for nfp driver to batch dumps, from Jakub. 11) AF_XDP socket umem mapping improvements for 32bit archs, from Ivan. 12) Add BPF-to-BPF call and BTF line info support for s390x JIT, from Yauheni. 13) Small optimization in arm64 JIT to spare 1 insns for BPF_MOD, from Jerin. 14) Fix an error check in bpf_tcp_gen_syncookie() helper, from Petar. 15) Various minor fixes and cleanups, from Nathan, Masahiro, Masanari, Peter, Wei, Yue. ==================== Signed-off-by: -
Colin Ian King authored
The variable rx_process_result is being initialized with a value that is never read and is being re-assigned immediately afterwards. The assignment is redundant, so replace it with the return from function lan743x_rx_process_packet. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
David S. Miller authored
Simon Horman says: ==================== ravb: remove use of undocumented registers this short series cleans up the RAVB driver a little. The first patch corrects the spelling of the FBP field of SFO register. This register field is unused and should have no run-time effect. The remaining patches remove the use of undocumented registers after some consultation with the internal Renesas BSP team. Changes in v2: * Corrected mangled state of first patch * Patches 2/4 and 3/4 split out of a large patch * Accumulated acks * Tweaked changelog * Claimed authorship of all patches v1 of this series was tested on the following platforms. No behaviour change is expected in v2. * E3 Ebisu * H3 Salvator-XS (ES2.0) * M3-W Salvator-XS * M3-N Salvator-XS * RZ/G1C iW-RainboW-G23S ==================== Signed-off-by: -
Simon Horman authored
Only use the TROCR register on R-Car Gen3 as it is not present on other SoCs. Offsets used for the undocumented registers are considered reserved and should not be written to. After some internal investigation with Renesas it remains unclear why this driver accesses these fields on R-Car Gen2 but regardless of what the historical reasons are the current code is considered incorrect. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Simon Horman authored
This patch removes the use of the undocumented BOC bit of the CCC register. Current documentation for EtherAVB (ravb) describes the offset of what the driver uses as the BOC bit as reserved and that only a value of 0 should be written. After some internal investigation with Renesas it remains unclear why this driver accesses these fields but regardless of what the historical reasons are the current code is considered incorrect. Based on work by Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by:
-
Simon Horman authored
This patch removes the use of the undocumented counter registers CDCR, LCCR, CERCR, CEECR. Offsets used for undocumented registers are considered reserved and should not be written to. After some internal investigation with Renesas it remains unclear why this driver accesses these fields but regardless of what the historical reasons are the current code is considered incorrect. Based on work by Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by:
-
Simon Horman authored
The field name is FBP rather than FPB. This field is unused and could equally be removed from the driver entirely. But there seems no harm in leaving as documentation of the presence of the field. Based on work by Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by:
-
Andy Shevchenko authored
Use %*ph format to print small buffer as hex string. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Andy Shevchenko authored
Use %*ph format to print small buffer as hex string. Signed-off-by:
-
Andy Shevchenko authored
Use %*ph format to print small buffer as hex string. Signed-off-by:
-
Wei Yongjun authored
When using single_open() for opening, single_release() should be used instead of seq_release(), otherwise there is a memory leak. This is detected by Coccinelle semantic patch. Fixes: 610247f4 ("rtlwifi: Improve debugging by using debugfs") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Wei Yongjun authored
When using single_open(), single_release() should be used instead of seq_release(), otherwise there is a memory leak. This is detected by Coccinelle semantic patch. Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver") Signed-off-by:
-
zhong jiang authored
Obviously, variable 'copied' is initialized to zero. But it is not used. hence just remove it. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Signed-off-by:
-
Rafał Miłecki authored
This is a trivial debugfs entry for triggering reset just like in case of firmware crash. It works by writing 1 to it: echo 1 > reset Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
-
Rafał Miłecki authored
In case of compiling driver without DEBUG expose a stub function to make writing debug code much simpler (no extra conditions). This will allow e.g. using debugfs_create_file() without any magic if or #ifdef. Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: add some bugfixes and cleanups This patch-set includes bugfixes and cleanups for the HNS3 ethernet controller driver. [patch 01/07] fixes an error when setting VLAN offload. [patch 02/07] fixes an double free issue when setting ringparam. [patch 03/07] fixes a mis-assignment of hdev->reset_level. [patch 04/07] adds a checking for client's validity. [patch 05/07] simplifies bool variable's assignment. [patch 06/07] disables loopback when initializing. [patch 07/07] makes internal function to static. Change log: V1->V2: fixes comment from Sergei Shtylyov. ==================== Signed-off-by: -
Guojia Liao authored
hclge_dbg_get_m7_info is used only in the hclge_debugfs.c, so it should be declared with static. Signed-off-by:
Guojia Liao <liaoguojia@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Yufeng Mo authored
If the selftest and reset are performed at the same time, the loopback setting may be still in the enable state after the reset. As a result, packets cannot be sent out. This patch fixes this issue by disabling loopback in hclge_mac_init. Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
-
Guojia Liao authored
Relational and logical operators evaluate to bool, explicit conversion is overly verbose and unnecessary. Signed-off-by:
-
Peng Li authored
HNS3 driver can only unregister client which included in hnae3_client_list. This patch adds the client node validity judgment. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Huazhong Tan authored
Since hclge_get_reset_level may return HNAE3_NONE_RESET, so hdev->reset_level can not be assigned with the return value in the hclge_reset(), otherwise, it will cause the use of hdev->reset_level in hclge_reset_event get into error. Fixes: 012fcb52 ("net: hns3: activate reset timer when calling reset_event") Signed-off-by:
-
Huazhong Tan authored
The system will panic when change the ringparam in HNS3 drivers: [ 1459.627727] hns3 0000:bd:00.0 eth6: Changing Tx/Rx ring ds from 1024/1024 to 24/24 [ 1459.635766] hns3 0000:bd:00.0 eth6: link down [ 1459.640788] BUG: Bad page state in process ethtool pfn:203f75c18 [ 1459.646940] page:ffff7ee4ffd70600 refcount:0 mapcount:0 mapping:ffff993fff40f400 index:0x0 compound_mapcount: 0 [ 1459.656987] flags: 0x9fffe00000010200(slab|head) [ 1459.661591] raw: 9fffe00000010200 dead000000000100 dead000000000122 ffff993fff40f400 [ 1459.669302] raw: 0000000000000000 0000000080100010 00000000ffffffff 0000000000000000 [ 1459.677016] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set [ 1459.683432] bad because of flags: 0x200(slab) [ 1459.687775] Modules linked in: ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi hns_roce_hw_v2 crct10dif_ce hns3 ses hclge hnae3 hisi_hpre hisi_zip qm uacce ip_tables x_tables hisi_sas_v3_hw hisi_sas_main libsas scsi_transport_sas [ 1459.709329] CPU: 14 PID: 17244 Comm: ethtool Tainted: G O 5.3.0-rc4-00415-gc86f057 #1 [ 1459.718419] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B040.01 07/26/2019 [ 1459.727248] Call trace: [ 1459.729688] dump_backtrace+0x0/0x150 [ 1459.733335] show_stack+0x24/0x30 [ 1459.736639] dump_stack+0xa0/0xc4 [ 1459.739943] bad_page+0xf0/0x158 [ 1459.743157] free_pages_check_bad+0x84/0xa0 [ 1459.747322] __free_pages_ok+0x348/0x378 [ 1459.751228] page_frag_free+0x80/0x88 [ 1459.754877] skb_free_head+0x38/0x48 [ 1459.758436] skb_release_data+0x134/0x160 [ 1459.762427] skb_release_all+0x30/0x40 [ 1459.766158] consume_skb+0x38/0x108 [ 1459.769633] __dev_kfree_skb_any+0x58/0x68 [ 1459.773718] hns3_fini_ring+0x48/0x58 [hns3] [ 1459.777970] hns3_set_ringparam+0x2a8/0x418 [hns3] [ 1459.782741] dev_ethtool+0x5f4/0x2080 [ 1459.786390] dev_ioctl+0x190/0x3d8 [ 1459.789777] sock_do_ioctl+0xf8/0x220 [ 1459.793423] sock_ioctl+0x3bc/0x490 [ 1459.796896] do_vfs_ioctl+0xc4/0x868 [ 1459.800454] ksys_ioctl+0x8c/0xa0 [ 1459.803752] __arm64_sys_ioctl+0x28/0x38 [ 1459.807658] el0_svc_common.constprop.0+0xe0/0x1e0 [ 1459.812426] el0_svc_handler+0x34/0x90 [ 1459.816158] el0_svc+0x10/0x14 [ 1459.819220] Disabling lock debugging due to kernel taint [ 1459.825182] ------------[ cut here ]------------ Since ndo_stop will reclaim the RX's skb allocated by the driver, so the backed up ring parameter should not keep this info. Fixes: a723fb8e ("net: hns3: refine for set ring parameters") Signed-off-by:
-
Jian Shen authored
In original codes, the VF index used incorrectly in function hclge_set_vlan_rx_offload_cfg() and hclge_set_vlan_rx_offload_cfg(). When VF id is greater than 8, for example 9, it will set the same bit with VF id 1. This patch fixes it by using vport->vport_id % HCLGE_VF_NUM_PER_CMD / HCLGE_VF_NUM_PER_BYTE as the array index, instead of vport->vport_id / HCLGE_VF_NUM_PER_CMD. Fixes: 052ece6d ("net: hns3: add ethtool related offload command") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Andy Shevchenko authored
This patch amends the error and warning messages across the platform driver. It includes the following changes: - append \n to the end of messages - change pr_* macros to dev_* Signed-off-by:
-
Jose Abreu authored
While running stmmac selftests I found that in my 1G setup some tests were failling when running with PHY loopback enabled. It looks like when loopback is enabled the PHY will report that Link is down even though there is a valid connection. As in loopback mode the data will not be sent anywhere we can bypass the logic of checking if Link is valid thus saving unecessary reads. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
-
David Dai authored
For high speed adapter like Mellanox CX-5 card, it can reach upto 100 Gbits per second bandwidth. Currently htb already supports 64bit rate in tc utility. However police action rate and peakrate are still limited to 32bit value (upto 32 Gbits per second). Add 2 new attributes TCA_POLICE_RATE64 and TCA_POLICE_RATE64 in kernel for 64bit support so that tc utility can use them for 64bit rate and peakrate value to break the 32bit limit, and still keep the backward binary compatibility. Tested-by:
David Dai <zdai@linux.vnet.ibm.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Paul Blakey authored
Offloaded OvS datapath rules are translated one to one to tc rules, for example the following simplified OvS rule: recirc_id(0),in_port(dev1),eth_type(0x0800),ct_state(-trk) actions:ct(),recirc(2) Will be translated to the following tc rule: $ tc filter add dev dev1 ingress \ prio 1 chain 0 proto ip \ flower tcp ct_state -trk \ action ct pipe \ action goto chain 2 Received packets will first travel though tc, and if they aren't stolen by it, like in the above rule, they will continue to OvS datapath. Since we already did some actions (action ct in this case) which might modify the packets, and updated action stats, we would like to continue the proccessing with the correct recirc_id in OvS (here recirc_id(2)) where we left off. To support this, introduce a new skb extension for tc, which will be used for translating tc chain to ovs recirc_id to handle these miss cases. Last tc chain index will be set by tc goto chain action and read by OvS datapath. Signed-off-by:
Paul Blakey <paulb@mellanox.com> Signed-off-by:
Vlad Buslov <vladbu@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
-
zhong jiang authored
Continue is not needed at the bottom of a loop. Signed-off-by:
-
Shahar S Matityahu authored
Use cancel_delayed_work_sync on the dump workers only in case of unloading the op mode. In any other case use iwl_fw_flush_dumps or iwl_fw_dbg_stop_sync (depends if the op mode mutex is held or not). This way, the driver will wait until debug data is collected in all cases but op mode unloading. Signed-off-by:
Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Shahar S Matityahu authored
Remove periodic trigger functionality. After moving to the new API we will add periodic trigger functionality that matches the new API. Signed-off-by:
-
Shahar S Matityahu authored
Fix the documentation of struct iwl_fw_ini_monitor_dump and iwl_fw_ini_error_dump_range. Signed-off-by:
-
Shahar S Matityahu authored
Add support code to be able to use the DRAM buffer allocation command, which allows us to send information about a buffer to the firmware to use it with the DBGC hardware. Signed-off-by:
-
Shahar S Matityahu authored
Remove the "apply points" mechanism as preparation for the changed debug API where this is now a "time point" instead. Use a new API across the code at the trigger points ("time points"), but don't yet implement it since that requires some more preparation. Signed-off-by: -
Shahar S Matityahu authored
Allows to easily calculate array length at the end of a TLV. Signed-off-by:
-
Emmanuel Grumbach authored
Sometimes the firmware won't be able to decrypt frames because the keys were not installed yet or other scenarios. The firmware will soon stop dropping multicast frames when MAC_FILTER_ACCEPT_GRP is not set. The firmware will simply always pass multicast frame in. In order to avoid logging any such frame coming in when we don't have the keys, drop the print. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Haim Dreyfuss authored
There are products which have a single chain with 2 antennas. In these products, we need to inform the FW that the device has the single antenna diversity(SAD) feature. In the future, we will read the active antenna from a BIOS configuration. Currently, we use a default configuration which means that the FW decides which antenna to use. Signed-off-by:
Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by:
-
Johannes Berg authored
In prior hardware generations (e.g. 9000 series), we received the BAR frame with fake NSSN information to handle releasing frames from the reorder buffer for the default queue, the other queues were getting the FRAME_RELEASE notification in this case. With multi-TID block-ack, the firmware no longer sends us the BAR frame because the fake RX is quite big (just the metadata is around 48 bytes or so). Instead, it now sends us one (or multiple) special release notifications (0xc2). The hardware consumes these as well, but only generates the FRAME_RELEASE (0xc3) for queues other than the default queue. We thus need to handle them in the same way we handle the normal FRAME_RELEASE. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
