- 30 Jan, 2019 40 commits
-
-
liyongxin authored
Union l3_hdr_info and l4_hdr_info have already been defined in the hns3_enet.h, so it is unnecessary to define them elsewhere. This patch removes the redundant definition, and reuses the one defined in the hns3_enet.h. Signed-off-by:
liyongxin <liyongxin1@huawei.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Greg Ungerer says: ==================== net: dsa: mt7530: support MT7530 in the MT7621 SoC This is the fourth version of a patch series supporting the MT7530 switch as used in the MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around a dual core MIPS CPU architecture. But inside it uses basically the same 7530 switch. This series resolves all issues I had with previous versions, and I can now reliably use the driver on a 7621 SoC platform. These patches were generated against linux-5.0-rc4. The first patch enables support for the existing kernel mediatek ethernet driver on the MT7621 SoC. This support is from Bjørn Mork, with an update and fix by me. Using this driver fixed a number of problems I had (TX checksums, large RX packet drop) over the staging driver (drivers/staging/mt7621-eth). Patch 2 modifies the mt7530 DSA driver to support the 7530 switch as implemented in the Mediatek MT7621 SoC. The last patch updates the devicetree bindings to reflect the new support in the mt7530 driver. There is no real dependencies between the patches, so they can be taken independantly. Creating a new binding for the MT7621 seems like the only viable approach to distinguish between a stand alone 7530 switch, the silicon module in the MT7623 SoC and the silicon in the MT7621. Certainly the 7530 ID register in the MT7623 and MT7621 returns the same value, "0x7530001". Looking at the mt7530.c DSA driver it might make some sense to convert the existing "mediatek,mcm" binding to something like "mediatek,mt7623" to be consistent with this new MT7621 support. As far as I can tell this is the intention of this binding. ==================== Signed-off-by: -
Greg Ungerer authored
Add devicetree binding to support the compatible mt7530 switch as used in the MediaTek MT7621 SoC. Signed-off-by:
Greg Ungerer <gerg@kernel.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Sean Wang <sean.wang@kernel.org> Signed-off-by:
-
Greg Ungerer authored
The MediaTek MT7621 SoC device contains a 7530 switch, and the existing linux kernel 7530 DSA switch driver can be used with it. The bulk of the changes required stem from the 7621 having different regulator and pad setup. The existing setup of these in the 7530 driver appears to be very specific to its implemtation in the Mediatek 7623 SoC. (Not entirely surprising given the 7623 is a quad core ARM based SoC, and the 7621 is a dual core, dual thread MIPS based SoC). Create a new devicetree type, "mediatek,mt7621", to support the 7530 switch in the 7621 SoC. There appears to be no usable ID register to distinguish it from a 7530 in other hardware at runtime. This is used to carry out the appropriate configuration and setup. Signed-off-by:
-
Bjørn Mork authored
The Mediatek MT7621 SoC contains the same ethernet hardware module as used on a number of other MediaTek SoC parts. There are some minor differences to deal with but we can use the same driver to support them all. This patch is based on work by Bjørn Mork <bjorn@mork.no>, and his original patch is at: https://github.com/bmork/LEDE/commit/3293bc63f5461ca1eb0bbc4ed90145335e7e3404 There is an additional compatible devicetree type added, and the primary change to the code required is to support a single interrupt (for both RX and TX interrupts). Signed-off-by:
Bjørn Mork <bjorn@mork.no> [gerg@kernel.org: rebase to mainline and irq handler fix] Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: spectrum_acl: Include delta bits into hashtable key The Spectrum-2 ASIC allows multiple rules to use the same mask provided that the difference between their masks is small enough (up to 8 consecutive delta bits). A more detailed explanation is provided in merge commit 756cd366 ("Merge branch 'mlxsw-Introduce-algorithmic-TCAM-support'"). These delta bits are part of the rule's key and therefore rules that only differ in their delta bits can be inserted with the same A-TCAM mask. In case two rules share the same key and only differ in their priority, then the second will spill to the C-TCAM. Current code does not take the delta bits into account when checking for duplicate rules, which leads to unnecessary spillage to the C-TCAM. This may result in reduced scale and performance. Patch #1 includes the delta bits in the rule's key to avoid the above mentioned problem. Patch #2 adds a tracepoint when a rule is inserted into the C-TCAM. Patches #3-#5 add test cases to make sure unnecessary spillage into the C-TCAM does not occur. ==================== Signed-off-by:
-
Jiri Pirko authored
Ensure that the bug is fixed and we no longer have C-TCAM spill for two keys that differ only in delta. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Jiri Pirko authored
With recent fix in C-TCAM spillage for delta masks, the test stops to be falsely positive. So fix it not to use delta by adding src_ip bits to the masks. Alongside with that, use C-TCAM spill trace to see when the spillage actually happens. Signed-off-by:
-
Jiri Pirko authored
Allow to specify number of trace hits and move helpers to the beginning of the file. Signed-off-by:
-
Jiri Pirko authored
Add some visibility to the rule addition process and trace whenever rule spilled into C-TCAM. Signed-off-by:
-
Jiri Pirko authored
Currently only ERP mask masked bits in key are considered for the hashtable key. That leads to false negative collisions and fallbacks to C-TCAM in case two keys differ only in delta bits. Fix this by taking full encoded key as a hashtable key, including delta bits. Reported-by:
Nir Dotan <nird@mellanox.com> Signed-off-by:
-
David S. Miller authored
Xin Long says: ==================== sctp: support SCTP_FUTURE/CURRENT/ALL_ASSOC This patchset adds the support for 3 assoc_id constants: SCTP_FUTURE_ASSOC SCTP_CURRENT_ASSOC, SCTP_ALL_ASSOC, described in rfc6458#section-7.2: All socket options set on a one-to-one style listening socket also apply to all future accepted sockets. For one-to-many style sockets, often a socket option will pass a structure that includes an assoc_id field. This field can be filled with the association identifier of a particular association and unless otherwise specified can be filled with one of the following constants: SCTP_FUTURE_ASSOC: Specifies that only future associations created after this socket option will be affected by this call. SCTP_CURRENT_ASSOC: Specifies that only currently existing associations will be affected by this call, and future associations will still receive the previous default value. SCTP_ALL_ASSOC: Specifies that all current and future associations will be affected by this call. The functions for many other sockopts that use assoc_id also need to be updated accordingly. ==================== Acked-by:Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_scheduler and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_scheduler, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_STREAM_SCHEDULER in this patch. It also adds default_ss in sctp_sock to support SCTP_FUTURE_ASSOC. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_event and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_event, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_EVENT in this patch. It also adds sctp_assoc_ulpevent_type_set() to make code more readable. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_enable_strreset and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_enable_strreset, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_ENABLE_STREAM_RESET in this patch. It also adjusts some code to keep a same check form as other functions. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_default_prinfo and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_default_prinfo, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_DEFAULT_PRINFO in this patch. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_deactivate_key. SCTP_CURRENT_ASSOC is supported for SCTP_AUTH_DEACTIVATE_KEY in this patch. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_del_key. SCTP_CURRENT_ASSOC is supported for SCTP_AUTH_DELETE_KEY in this patch. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_auth_key. SCTP_CURRENT_ASSOC is supported for SCTP_AUTH_ACTIVE_KEY in this patch. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_auth_key. SCTP_CURRENT_ASSOC is supported for SCTP_AUTH_KEY in this patch. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_maxburst and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_maxburst, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_CONTEXT in this patch. It also adjusts some code to keep a same check form as other functions. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_context and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_context, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_CONTEXT in this patch. It also adjusts some code to keep a same check form as other functions. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_default_sndinfo and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_default_sndinfo, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_DEFAULT_SNDINFO in this patch. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_default_send_param and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_default_send_param, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_DEFAULT_SEND_PARAM in this patch. Signed-off-by:
-
Xin Long authored
Check with SCTP_ALL_ASSOC instead in sctp_setsockopt_delayed_ack and check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_delayed_ack, it's compatible with 0. SCTP_CURRENT_ASSOC is supported for SCTP_DELAYED_SACK in this patch. It also adds sctp_apply_asoc_delayed_ack() to make code more readable. Signed-off-by:
-
Xin Long authored
SCTP_STREAM_SCHEDULER_VALUE is a special one, as its value is not save in sctp_sock, but only in asoc. So only SCTP_CURRENT_ASSOC reserved assoc_id can be used in sctp_setsockopt_scheduler_value. This patch adds SCTP_CURRENT_ASOC support for SCTP_STREAM_SCHEDULER_VALUE. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_set/getsockopt_reconfig_supported, it's compatible with 0. It also adjusts some code to keep a same check form as other functions. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_set/getsockopt_reconfig_supported, it's compatible with 0. It also adjusts some code to keep a same check form as other functions. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_set/getsockopt_pr_supported, it's compatible with 0. It also adjusts some code to keep a same check form as other functions. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_set/getsockopt_paddr_thresholds, it's compatible with 0. It also adds pf_retrans in sctp_sock to support SCTP_FUTURE_ASSOC. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_getsockopt_local_auth_chunks, it's compatible with 0. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_set/getsockopt_maxseg, it's compatible with 0. Also check asoc_id early as other sctp setsockopts does. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_set/getsockopt_associnfo, it's compatible with 0. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_set/getsockopt_rtoinfo, it's compatible with 0. Signed-off-by:
-
Xin Long authored
Check with SCTP_FUTURE_ASSOC instead in sctp_/setgetsockopt_peer_addr_params, it's compatible with 0. Signed-off-by:
-
Xin Long authored
This patch is to add 3 constants SCTP_FUTURE_ASSOC, SCTP_CURRENT_ASSOC and SCTP_ALL_ASSOC for reserved assoc_ids, as defined in rfc6458#section-7.2. And add the process for them when doing lookup and inserting in sctp_id2assoc and sctp_assoc_set_id. Signed-off-by:
-
David S. Miller authored
Vasundhara Volam says: ==================== devlink: Add configuration parameters support for devlink_port This patchset adds support for configuration parameters setting through devlink_port. Each device registers supported configuration parameters table. The user can retrieve data on these parameters by "devlink port param show" command and can set new value to a parameter by "devlink port param set" command. All configuration modes supported by devlink_dev are supported by devlink_port also. Command examples and output: pci/0000:3b:00.0/0: name wake-on-lan type generic values: cmode permanent value false pci/0000:3b:00.1/1: name wake-on-lan type generic values: cmode permanent value false pci/0000:af:00.0/0: name wake-on-lan type generic values: cmode permanent value true pci/0000:3b:00.0/0: name wake-on-lan type generic values: cmode permanent value false There is difference of opinion on adding WOL parameter to devlink, between Jakub Kicinski and Michael Chan. Quote from Jakud Kicinski: ******** As explained previously I think it's a very bad idea to add existing configuration options to devlink, just because devlink has the ability to persist the setting in NVM. Especially that for WoL you have to get the link up so you potentially have all link config stuff as well. And that n-tuple filters are one of the WoL options, meaning we'd need the ability to persist n-tuple filters via devlink. The effort would be far better spent helping with migrating ethtool to netlink, and allowing persisting there. I have not heard any reason why devlink is a better fit. I can imagine you're just doing it here because it's less effort for you since ethtool is not yet migrated. ******** Quote from Michael Chan: ******** The devlink's WoL parameter is a persistent WoL parameter stored in the NIC's NVRAM. It is different from ethtool's WoL parameter in a number of ways. ethtool WoL is not persistent over AC power cycle and is considered OS-present WoL. As such, ethtool WoL can use a more sophisticated pattern including n-tuple with IP address in addition to the more basic types (e.g. magic packet). Whereas OS-absent power up WoL should only include magic packet and other simple types. The devlink WoL setting does not have to match the ethtool WoL setting. The card will autoneg up to the speed supported by Vaux so no special devlink link setting is needed. ******** Future expansion of WOL parameter to devlink: ******** Add an additional flag to support additional setting to address link settings. This will allow attributes to support both runtime and persistent configuration. ******** v7->v8: * Re-ordered function definitions. * Append with "Acked-by: Jiri Pirko <jiri@mellanox.com>" to first 3 patches. * Add missing devlink_port_param_driverinit_value_get() declaration. v6->v7: * Remove RFC tag from the patch-set. v5->v6: * Replace '-' with '*' in cover letter to avoid cutoff by git. v4->v5: * Added quotes from Jakub Kicinski and Michael chan on devlink's WOL parameter in the cover letter. v3->v4: * Update changes done from v2 to v3 version in individual patch descriptions. v2->v3: Make following changes as per suggestions from Jiri Pirko and Michal Kubecek. * Add a helper __devlink_params_register() with common code used by both devlink_params_register() and devlink_port_params_register(). * Define only WOL types used now and define them as bitfield, so that mutliple WOL types can be enabled upon power on. * Modify "wake-on-lan" name to "wake_on_lan" to be symmetric with previous definitions. * Rename DEVLINK_PARAM_WOL_XXX to DEVLINK_PARAM_WAKE_XXX to be symmetrical with ethtool WOL definitions. * Modify bnxt_dl_wol_validate(), to throw error message when user gives value other than DEVLINK_PARAM_WAKE_MAGIC or to disable WOL. * Use netdev_err() instead of netdev_warn(), when devlink_port_register() and devlink_port_params_register() returns error. Also, don't log rc in this message. v1->v2: Make following changes as per suggestions from Jiri Pirko. * Remove separate enum devlink_port_param_generic_id for port params. Instead club it with existing device params. Accordingly refactor remaining patchset. * Move INIT_LIST_HEAD of port param_list to devlink_port_register() * Add a helper devlink_param_verify() to be used for both devlink_params_register() and devlink_port_params_register(). * Add a helper __devlink_params_unregister() for common code in devlink_params_unregister() and devlink_port_params_unregister(). * Move DEVLINK_CMD_PORT_PARAM_XXX definitions to the end of the enum. * Split the patches for devlink_port_param_driverinit_value_get() and devlink_port_param_driverinit_value_set() into separate patches. * define DEVLINK_PARAM_GENERIC_ID_WOL type as u8 and define enum for different types of WOL. Accordingly modify bnxt_en patch to validate wol type. ==================== Signed-off-by: -
Vasundhara Volam authored
Register devlink_port with devlink and create initial port params table for bnxt_en. The table consists of a generic parameter: wake_on_lan: Enables Wake on Lan for this port when magic packet is received with this port's MAC address using ACPI pattern. If enabled, the controller asserts a wake pin upon reception of WoL packet. ACPI (Advanced Configuration and Power Interface) is an industry specification for the efficient handling of power consumption in desktop and mobile computers. v2->v3: - Modify bnxt_dl_wol_validate(), to throw error message when user gives value other than DEVLINK_PARAM_WAKE_MAGIC ot to disable WOL. - Use netdev_err() instead of netdev_warn(), when devlink_port_register() and devlink_port_params_register() returns error. Also, don't log rc in this message. Cc: Michael Chan <michael.chan@broadcom.com> Signed-off-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by:
-
Vasundhara Volam authored
wake_on_lan - Enables Wake on Lan for this port. If enabled, the controller asserts a wake pin based on the WOL type. v2->v3: - Define only WOL types used now and define them as bitfield, so that mutliple WOL types can be enabled upon power on. - Modify "wake-on-lan" name to "wake_on_lan" to be symmetric with previous definitions. - Rename DEVLINK_PARAM_WOL_XXX to DEVLINK_PARAM_WAKE_XXX to be symmetrical with ethtool WOL definitions. Cc: Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Vasundhara Volam authored
Add notification call for devlink port param set, register and unregister functions. Add devlink_port_param_value_changed() function to enable the driver notify devlink on value change. Driver should use this function after value was changed on any configuration mode part to driverinit. v7->v8: Order devlink_port_param_value_changed() definitions followed by devlink_param_value_changed() Cc: Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
