- 11 Sep, 2019 37 commits
-
-
Alexandru Ardelean authored
In-between the MAC & PHY there can be a mode converter, which converts one mode to another (e.g. GMII-to-RGMII). The converter, can be passive (i.e. no driver or OS/SW information required), so the MAC & PHY need to be configured differently. For the `stmmac` driver, this is implemented via a `mac-mode` property in the device-tree, which configures the MAC into a certain mode, and for the PHY a `phy_interface` field will hold the mode of the PHY. The mode of the PHY will be passed to the PHY and from there-on it work in a different mode. If unspecified, the default `phy-mode` will be used for both. Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Sudarsana Reddy Kalluru says: ==================== qed* Fix series. The patch series addresses couple of issues in the recent commits. Patch (1) populates the actual dump-size of config attribute instead of providing a fixed size value. Patch(2) updates frame format of flash config buffer as required by management FW (MFW). Please consider applying it to net-next. ==================== Signed-off-by: -
Sudarsana Reddy Kalluru authored
MFW associates the entity id to a config attribute instead of assigning one entity id for all the config attributes. This patch incorporates driver changes to link entity id to a config id attribute. Fixes: 0dabbe1b ("qed: Add driver API for flashing the config attributes.") Signed-off-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
Driver currently returns max-buf-size as size of the config attribute. This patch incorporates changes to read this value from MFW (if available) and provide it to the user. Also did a trivial clean up in this path. Fixes: d44a3ced ("qede: Add support for reading the config id attributes.") Signed-off-by:
-
David S. Miller authored
Simon Horman says: ==================== devlink: add unknown 'fw_load_policy' value Dirk says: Recently we added an unknown value for the 'reset_dev_on_drv_probe' devlink parameter. Extend the 'fw_load_policy' parameter in the same way. The only driver that uses this right now is the nfp driver. ==================== Signed-off-by: -
Dirk van der Merwe authored
If the 'app_fw_from_flash' HWinfo key is invalid, set the 'fw_load_policy' devlink parameter value to unknown. Suggested-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Dirk van der Merwe authored
Similar to the 'reset_dev_on_drv_probe' devlink parameter, it is useful to have an unknown value which can be used by drivers to report that the hardware value isn't recognized or is otherwise invalid instead of failing the operation. This is especially useful for u8/enum parameters. Suggested-by:
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2019-09-11' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== We have a number of changes, but things are settling down: * a fix in the new 6 GHz channel support * a fix for recent minstrel (rate control) updates for an infinite loop * handle interface type changes better wrt. management frame registrations (for management frames sent to userspace) * add in-BSS RX time to survey information * handle HW rfkill properly if !CONFIG_RFKILL * send deauth on IBSS station expiry, to avoid state mismatches * handle deferred crypto tailroom updates in mac80211 better when device restart happens * fix a spectre-v1 - really a continuation of a previous patch * advertise NL80211_CMD_UPDATE_FT_IES as supported if so * add some missing parsing in VHT extended NSS support * support HE in mac80211_hwsim * let mac80211 drivers determine the max MTU themselves along with the usual cleanups etc. ==================== Signed-off-by:
-
Denis Kenzior authored
Currently frame registrations are not purged, even when changing the interface type. This can lead to potentially weird situations where frames possibly not allowed on a given interface type remain registered due to the type switching happening after registration. The kernel currently relies on userspace apps to actually purge the registrations themselves, this is not something that the kernel should rely on. Add a call to cfg80211_mlme_purge_registrations() to forcefully remove any registrations left over prior to switching the iftype. Cc: stable@vger.kernel.org Signed-off-by:
Denis Kenzior <denkenz@gmail.com> Link: https://lore.kernel.org/r/20190828211110.15005-1-denkenz@gmail.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2019-09-10 Misc build warnings cleanup for mlx5: 1) Reduce stack usage in FW trace 2) Fix addr's type in mlx5dr_icm_dm 3) Fix rt's type in dr_action_create_reformat_action ==================== Signed-off-by: -
David S. Miller authored
Jose Abreu says: ==================== net: stmmac: Improvements for -next Misc patches for -next. It includes: - Two fixes for features in -next only - New features support for GMAC cores (which includes GMAC4 and GMAC5) ==================== Signed-off-by: -
Jose Abreu authored
Implement the ARP Offload feature in GMAC4 and GMAC5 cores. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
-
Jose Abreu authored
Adds support for TX VLAN Offload using descriptors based features available in GMAC4/5. Signed-off-by:
-
Jose Abreu authored
Add the support for Source Address Insertion and Replacement in GMAC4 and GMAC5 cores. Two methods are supported: Descriptor based and register based. Signed-off-by:
-
Jose Abreu authored
'value' was being or'ed with a value from another register. This is a typo and could cause new written value to be wrong. Fix it. Signed-off-by:
-
Jose Abreu authored
Adds the support for VLAN HASH Filtering in GMAC4/5 cores. Signed-off-by:
-
Jose Abreu authored
When RX Coalesce settings are set to all zero (which is a valid setting) we will currently get a divide-by-zero error. Fix it. Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: add a feature & bugfixes & cleanups This patch-set includes a VF feature, bugfixes and cleanups for the HNS3 ethernet controller driver. [patch 01/07] adds ethtool_ops.set_channels support for HNS3 VF driver [patch 02/07] adds a recovery for setting channel fail. [patch 03/07] fixes an error related to shaper parameter algorithm. [patch 04/07] fixes an error related to ksetting. [patch 05/07] adds cleanups for some log pinting. [patch 06/07] adds a NULL pointer check before function calling. [patch 07/07] adds some debugging information for reset issue. ==================== Signed-off-by: -
Huazhong Tan authored
This patch adds more information for reset DFX. Also, adds some cleanups to reset info, move reset_fail_cnt into struct hclge_rst_stats, and modifies some print formats. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Guangbin Huang authored
This patch checks ops->set_default_reset_request whether is NULL before using it in function hns3_slot_reset. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Guangbin Huang authored
The pfc_en and pfc_map need to be displayed in hexadecimal notation, printing dma address should use %pad, and the end of printed string needs to be add "\n". This patch modifies them. Signed-off-by:
-
Guangbin Huang authored
For hardware doesn't support use specified speed and duplex to negotiate, it's unnecessary to check and modify the port speed and duplex for fibre port when autoneg is on. Fixes: 22f48e24 ("net: hns3: add autoneg and change speed support for fibre port") Signed-off-by:
-
Yonglong Liu authored
Currently when hns3 driver configures the tm shaper to limit bandwidth below 20Mbit using the parameters calculated by hclge_shaper_para_calc(), the actual bandwidth limited by tm hardware module is not accurate enough, for example, 1.28 Mbit when the user is configuring 1 Mbit. This patch adjusts the ir_calc to be closer to ir, and always calculate the ir_b parameter when user is configuring a small bandwidth. Also, removes an unnecessary parenthesis when calculating denominator. Fixes: 84844054 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver") Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
-
Peng Li authored
After setting new channel num, it needs free old ring memory and allocate new ring memory. If there is no enough memory and allocate new ring memory fail, the ring may initialize fail. To make sure the network interface can work normally, driver should revert the channel to the old configuration. Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
-
Guangbin Huang authored
This patch adds ethtool_ops.set_channels support for HNS3 VF driver, and updates related TQP information and RSS information, to support modification of VF TQP number, and uses current rss_size instead of max_rss_size to initialize RSS. Also, fixes a format error in hclgevf_get_rss(). Signed-off-by:
-
Sven Eckelmann authored
Some features of 802.11ax without central organizing (AP) STA can also be used in mesh mode. hwsim can be used to assist initial development of these features without having access to HW. Signed-off-by:
Sven Eckelmann <seckelmann@datto.com> Link: https://lore.kernel.org/r/20190813063657.7544-1-sven@narfation.orgSigned-off-by:
-
Masashi Honma authored
commit 1222a160 ("nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds") was incomplete and requires one more fix to prevent accessing to rssi_thresholds[n] because user can control rssi_thresholds[i] values to make i reach to n. For example, rssi_thresholds = {-400, -300, -200, -100} when last is -34. Cc: stable@vger.kernel.org Fixes: 1222a160 ("nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Masashi Honma <masashi.honma@gmail.com> Link: https://lore.kernel.org/r/20190908005653.17433-1-masashi.honma@gmail.comSigned-off-by:
-
Wen Gong authored
Make it possibly for drivers to adjust the default max_mtu by storing it in the hardware struct and using that value for all interfaces. Signed-off-by:
Wen Gong <wgong@codeaurora.org> Link: https://lore.kernel.org/r/1567738137-31748-1-git-send-email-wgong@codeaurora.orgSigned-off-by:
-
zhong jiang authored
With the help of boolinit.cocci, we use !nl80211_reg_change_event_fill instead of (nl80211_reg_change_event_fill == false). Meanwhile, Clean up the code. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Link: https://lore.kernel.org/r/1567657537-65472-1-git-send-email-zhongjiang@huawei.comSigned-off-by:
-
Johannes Berg authored
When we expire an inactive station, try to send it a deauth. This helps if it's actually still around, and just has issues with beacon distribution (or we do), and it will not also remove us. Then, if we have shared state, this may not be reset properly, causing problems; for example, we saw a case where aggregation sessions weren't removed properly (due to the TX start being offloaded to firmware and it relying on deauth for stop), causing a lot of traffic to get lost due to the SN reset after remove/add of the peer. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/20190830112451.21655-9-luca@coelho.fiSigned-off-by:
-
Luca Coelho authored
We already assume that key is not NULL and dereference it in a few other places before we check whether it is NULL, so the check is unnecessary. Remove it. Fixes: 96fc6efb ("mac80211: IEEE 802.11 Extended Key ID support") Signed-off-by:
-
Lior Cohen authored
In case we got a fw restart while roaming from encrypted AP to non-encrypted one, we might end up with hitting a warning on the pending counter crypto_tx_tailroom_pending_dec having a non-zero value. The following comment taken from net/mac80211/key.c explains the rational for the delayed tailroom needed: /* * The reason for the delayed tailroom needed decrementing is to * make roaming faster: during roaming, all keys are first deleted * and then new keys are installed. The first new key causes the * crypto_tx_tailroom_needed_cnt to go from 0 to 1, which invokes * the cost of synchronize_net() (which can be slow). Avoid this * by deferring the crypto_tx_tailroom_needed_cnt decrementing on * key removal for a while, so if we roam the value is larger than * zero and no 0->1 transition happens. * * The cost is that if the AP switching was from an AP with keys * to one without, we still allocate tailroom while it would no * longer be needed. However, in the typical (fast) roaming case * within an ESS this usually won't happen. */ The next flow lead to the warning eventually reported as a bug: 1. Disconnect from encrypted AP 2. Set crypto_tx_tailroom_pending_dec = 1 for the key 3. Schedule work 4. Reconnect to non-encrypted AP 5. Add a new key, setting the tailroom counter = 1 6. Got FW restart while pending counter is set ---> hit the warning While on it, the ieee80211_reset_crypto_tx_tailroom() func was merged into its single caller ieee80211_reenable_keys (previously called ieee80211_enable_keys). Also, we reset the crypto_tx_tailroom_pending_dec and remove the counters warning as we just reset both. Signed-off-by:
Lior Cohen <lior2.cohen@intel.com> Signed-off-by:
-
Johannes Berg authored
When we reach this point, the key cannot be NULL. Remove the condition that suggests otherwise. Signed-off-by:
-
Johannes Berg authored
"HE/HT/VHT" is a bit confusing since really the order of development (and possible support) is different - change this to "HT/VHT/HE". Signed-off-by:
-
Johannes Berg authored
When the RFKILL subsystem isn't available, then rfkill_blocked() always returns false. In the case of hardware rfkill this will be wrong though, as if the hardware reported being killed then it cannot operate any longer. Since we only ever call the rfkill_sync work in this case, just rename it to rfkill_block and always pass "true" for the blocked parameter, rather than passing rfkill_blocked(). We rely on the underlying driver to still reject any new attempt to bring up the device by itself. Signed-off-by:
-
Mordechay Goodstein authored
This fixes was missed in parsing the vht capabilities max bw support. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Fixes: e80d6425 ("mac80211: copy VHT EXT NSS BW Support/Capable data to station") Signed-off-by:
-
Arend van Spriel authored
The boundary value used for the 6G band was incorrect as it would result in invalid 6G channel number for certain frequencies. Reported-by:
Amar Singhal <asinghal@codeaurora.org> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://lore.kernel.org/r/1567510772-24263-1-git-send-email-arend.vanspriel@broadcom.comSigned-off-by:
-
- 10 Sep, 2019 3 commits
-
-
Saeed Mahameed authored
Mark mlx5_tracer_print_trace as noinline as the function only uses 512 bytes on the stack to avoid the following build warning: drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c:660:13: error: stack frame size of 1032 bytes in function 'mlx5_fw_tracer_handle_traces' [-Werror,-Wframe-larger-than=] Fixes: 70dd6fdb ("net/mlx5: FW tracer, parse traces and kernel tracing support") Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Nathan Chancellor authored
clang errors when CONFIG_PHYS_ADDR_T_64BIT is not set: drivers/net/ethernet/mellanox/mlx5/core/steering/dr_icm_pool.c:121:8: error: incompatible pointer types passing 'u64 *' (aka 'unsigned long long *') to parameter of type 'phys_addr_t *' (aka 'unsigned int *') [-Werror,-Wincompatible-pointer-types] &icm_mr->dm.addr, &icm_mr->dm.obj_id); ^~~~~~~~~~~~~~~~ include/linux/mlx5/driver.h:1092:39: note: passing argument to parameter 'addr' here u64 length, u16 uid, phys_addr_t *addr, u32 *obj_id); ^ 1 error generated. Use phys_addr_t for addr's type in mlx5dr_icm_dm, which won't change anything with 64-bit builds because phys_addr_t is u64 when CONFIG_PHYS_ADDR_T_64BIT is set, which is always when CONFIG_64BIT is set. Fixes: 29cf8feb ("net/mlx5: DR, ICM pool memory allocator") Link: https://github.com/ClangBuiltLinux/linux/issues/653Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Reported-by:
-
Nathan Chancellor authored
clang warns: drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1080:9: warning: implicit conversion from enumeration type 'enum mlx5_reformat_ctx_type' to different enumeration type 'enum mlx5dr_action_type' [-Wenum-conversion] rt = MLX5_REFORMAT_TYPE_L2_TO_L2_TUNNEL; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1082:9: warning: implicit conversion from enumeration type 'enum mlx5_reformat_ctx_type' to different enumeration type 'enum mlx5dr_action_type' [-Wenum-conversion] rt = MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL; ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1084:51: warning: implicit conversion from enumeration type 'enum mlx5dr_action_type' to different enumeration type 'enum mlx5_reformat_ctx_type' [-Wenum-conversion] ret = mlx5dr_cmd_create_reformat_ctx(dmn->mdev, rt, data_sz, data, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~ 3 warnings generated. Use the right type for rt, which is mlx5_reformat_ctx_type so there are no warnings about mismatched types. Fixes: 9db810ed ("net/mlx5: DR, Expose steering action functionality") Link: https://github.com/ClangBuiltLinux/linux/issues/652Signed-off-by:Austin Kim <austindh.kim@gmail.com> Reported-by:
-
