- 21 Jun, 2022 16 commits
-
-
Mateusz Palczewski authored
Add ability to change speed through ethtool -s <interface> speed <speed in Mb> Driver advertises all link modes that support requested speed. Autoneg must be set off e.g.: ethtool -s <interface> autoneg off speed <speed in Mb>. Add helper function that translate speed in Mb to enum i40e_aq_link_speed and compare it to supported speeds from given ethtool_link_ksettings. Add in i40e_set_link_ksettings hold for requested speed and set copy_ks.base.speed to safe_ks.base.speed to be sure that user is not changing unsupported setting. In i40e_speed_to_link_speed compare requested speed with supported speeds. Set speed to requested speed. Signed-off-by:
Norbert Zulinski <norbertx.zulinski@intel.com> Signed-off-by:
Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by:
Dave Switzer <david.switzer@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Paolo Abeni authored
Arun Ramadoss says: ==================== net: dsa: microchip: common spi probe for the ksz series switches - part 1 This patch series aims to refactor the ksz_switch_register routine to have the common flow for the ksz series switch. At present ksz8795.c & ksz9477.c have its own dsa_switch_ops and switch detect functionality. In ksz_switch_register, ksz_dev_ops is assigned based on the function parameter passed by the individual ksz8/ksz9477 switch register function. And then switch detect is performed based on the ksz_dev_ops.detect hook. This patch modifies the ksz_switch_register such a way that switch detect is performed first, based on the chip ksz_dev_ops is assigned to ksz_device structure. It ensures the common flow for the existing as well as LAN937x switches. In the next series of patch, it will move ksz_dsa_ops and dsa_switch_ops from ksz8795.c and ksz9477.c to ksz_common.c and have the common spi probe all the ksz based switches. Changes in v1 - Splitted the patch series into two. - Replaced all occurrence of REG_PORT_STATUS_0 and PORT_FIBER_MODE to KSZ8_PORT_STATUS_0 and KSZ8_PORT_FIBER_MODE. - Separated the tag protocol and phy read/write patch into two. - Assigned the DSA_TAG_PROTO_NONE as the default value for get_tag_protocol hook. - Reduced the indentation level by using the if(!dev->dev_ops->mirror_add). - Added the stp_ctrl_reg as a member in ksz_chip_data and removed the member in ksz_dev_ops. - Removed the r_dyn_mac_table, r_sta_mac_table and w_sta_mac_table from the ksz_dev_ops since it is used only in the ksz8795.c. Changes in RFC v2 - Fixed the compilation issue. - Reduced the patch set to 15. ==================== Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20220617084255.19376-1-arun.ramadoss@microchip.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Arun Ramadoss authored
This patch assigns the get_phy_flags & mtu hook of ksz8795 and ksz9477 in dsa_switch_ops to ksz_common. For get_phy_flags hooks,checks whether the chip is ksz8863/kss8793 then it returns error for port1. Signed-off-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by:
-
Arun Ramadoss authored
This patch makes the dsa_switch_hook for fdbs to use ksz_common.c file. And from ksz_common, individual switches fdb functions are called using the dev->dev_ops. And removed the r_dyn_mac_table, r_sta_mac_table and w_sta_mac_table from ksz_dev_ops as it is used only in ksz8795.c Signed-off-by:
-
Arun Ramadoss authored
ksz_mdb_add/del in ksz_common.c is specific for the ksz8795.c file. The ksz9477 has its separate ksz9477_port_mdb_add/del functions. This patch moves the ksz8795 specific mdb functionality from ksz_common to ksz8795. And this dsa_switch_ops hooks for ksz8795/ksz9477 are invoked through the ksz_port_mdb_add/del. Signed-off-by:
-
Arun Ramadoss authored
This patch assigns the phylink_get_caps in ksz8795 and ksz9477 to ksz_phylink_get_caps. And update their mac_capabilities in the respective ksz_dev_ops. Signed-off-by:
-
Arun Ramadoss authored
At present, P_STP_CTRL register value is passed as parameter to ksz_port_stp_state from the individual dsa_switch_ops hooks. This patch update the function to retrieve the register value through the ksz_chip_data member. And add the static to ksz_update_port_member since it is not called outside the ksz_common. Signed-off-by:
-
Arun Ramadoss authored
This patch updates the common port mirror add/del dsa_switch_ops in ksz_common.c. The individual switches implementation is executed based on the ksz_dev_ops function pointers. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Arun Ramadoss authored
This patch moves the vlan dsa_switch_ops such as vlan_add, vlan_del and vlan_filtering from the individual files ksz8795.c, ksz9477.c to ksz_common.c file. Signed-off-by:
-
Arun Ramadoss authored
ksz8795 and ksz9477 implementation on phy read/write hooks are different. This patch modifies the ksz9477 implementation same as ksz8795 by updating the ksz9477_dev_ops structure. Signed-off-by:
-
Arun Ramadoss authored
This patch move the dsa hook get_tag_protocol to ksz_common file. And the tag_protocol is returned based on the dev->chip_id. Signed-off-by:
-
Arun Ramadoss authored
KSZ87xx and KSZ88xx have chip_id representation at reg location 0. And KSZ9477 compatible switch and LAN937x switch have same chip_id detection at location 0x01 and 0x02. To have the common switch detect functionality for ksz switches, ksz_switch_detect function is introduced. Signed-off-by:
-
Arun Ramadoss authored
The ksz9477_switch_detect performs the detecting the chip id from the location 0x00 and also check gigabit compatibility check & number of ports based on the register global_options0. To prepare the common ksz switch detect function, routine other than chip id read is moved to ksz9477_switch_init. Signed-off-by:
-
Yu Xiao authored
During initialization of the NFP driver, a file name for loading application firmware is composed using the NIC's AMDA information and port type (count and speed). E.g.: "nic_AMDA0145-1012_2x10.nffw". In practice there may be many variants for each NIC type, and many of the variants relate to assembly components which do not concern the driver and application firmware implementation. Yet the current scheme leads to a different application firmware file name for each variant, because they have different AMDA information. To reduce proliferation of content-duplicated application firmware images or symlinks, the NIC's management firmware will only expose differences between variants that need different application firmware via a newly introduced hwinfo, "nffw.partno". Use of the existing hwinfo, "assembly.partno", is maintained in order to support for NICs with management firmware that does not expose "nffw.partno". Signed-off-by:
Yu Xiao <yu.xiao@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20220620103912.46164-1-simon.horman@corigine.comSigned-off-by:
-
Eric Dumazet authored
raw_diag_dump() can use rcu_read_lock() instead of read_lock() Now the hashinfo lock is only used from process context, in write mode only, we can convert it to a spinlock, and we do not need to block BH anymore. Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20220620100509.3493504-1-eric.dumazet@gmail.comSigned-off-by:
-
Eric Dumazet authored
Make sure skb_mac_header(), skb_mac_offset() and skb_mac_header_len() uses are not fooled if the mac header has not been set. These checks are enabled if CONFIG_DEBUG_NET=y This commit will likely expose existing bugs in linux networking stacks. Signed-off-by:
-
- 20 Jun, 2022 18 commits
-
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Unified bridge conversion - part 1/6 This set starts converting mlxsw to the unified bridge model and mainly adds new device registers and extends existing ones that will be used in follow-up patchsets. High-level summary ================== The unified bridge model is a new way of managing low-level device objects such as filtering identifiers (FIDs). The conversion moves a lot of logic out of the device's firmware towards the driver, but its main selling point is that it allows to overcome various scalability issues related to the amount of entries that need to be programmed to the device. The only (intended) user visible changes of the conversion are improvement in resource utilization and ability to support more router interfaces (RIFs) in Spectrum-{2,3}. Details ======= Commit 50853808 ("Merge branch 'mlxsw-Prepare-for-VLAN-aware-bridge-w-VxLAN'") converted mlxsw to emulate 802.1Q FIDs (represent VLANs in a VLAN-aware bridge) using 802.1D FIDs (represent VLAN-unaware bridges). This was necessary because at that time VNI could not be assigned to 802.1Q FIDs, which effectively meant that mlxsw could not support VXLAN with VLAN-aware bridges. The downside of this approach is that multiple {Port,VID}->FID entries are required in order to classify incoming traffic to a FID, as opposed to a single VID->FID entry that can be used with actual 802.1Q FIDs. For example, if 10 ports are members in the same VLAN-aware bridge and the same 100 VLANs are configured on each port, then only 100 VID->FID entries are required with 802.1Q FIDs, whereas 1000 {Port,VID}->FID entries are required with emulated 802.1Q FIDs. The above limitation is the result of various assumptions that were made in the design of the API that was exposed to software. In the unified bridge model the API is much more "raw" and therefore avoids these assumptions, allowing software to configure the device in a more efficient manner. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
Router interfaces (RIFs) constructed on top of VLAN-aware bridges are of "VLAN" type, whereas RIFs constructed on top of VLAN-unaware bridges of "FID" type. In other words, the RIF type is derived from the underlying FID type. VLAN RIFs are used on top of 802.1Q FIDs, whereas FID RIFs are used on top of 802.1D FIDs. Currently 802.1Q FIDs are emulated using 802.1D FIDs, and therefore VLAN RIFs are emulated using FID RIFs. As part of converting the driver to use unified bridge, 802.1Q FIDs and VLAN RIFs will be used. Add the relevant fields to RITR register, add pack() function for VLAN RIF and rename one field to fit the internal name. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Amit Cohen authored
As preparation for unified bridge model, add support for VNI->FID mapping via SVFA register. When performing VXLAN encapsulation, the VXLAN header needs to contain a VNI. This VNI is derived from the FID classification performed on ingress, through which the ingress RIF is also determined. Similarly, when performing VXLAN decapsulation, the FID of the packet needs to be determined. This FID is derived from VNI classification performed during decapsulation. In the old model, both entries (i.e., FID->VNI and VNI->FID) were configured via SFMR.vni. In the new model, where ingress is separated from egress, ingress configuration (VNI->FID) is performed via SVFA, while SFMR only configures egress (FID->VNI). Add 'vni' field to SVFA, add new mapping table - VNI to FID, add new pack() function for VNI mapping and edit the comment in SFMR. Signed-off-by:
Danielle Ratson <danieller@nvidia.com> Reviewed-by:
-
Amit Cohen authored
RITR configures the router interface table. As preparation for unified bridge model, add egress FID field to RITR. After routing, a packet has to perform a layer-2 lookup using the destination MAC it got from the routing and a FID. In the new model, the egress FID is configured by RITR for both sub-port and FID RIFs. Add 'efid' field to sub-port router interface and update FID router interface related comment. Signed-off-by:
-
Amit Cohen authored
The REIV maps {egress router interface (eRIF), egress_port} -> {vlan ID}. As preparation for unified bridge model, add REIV register for future use. In the past, firmware would take care of the above mentioned mapping, but in the new model this should be done by software using REIV register. REIV register supports a simultaneous update of 256 ports using 'port_page' field. When 'port_page'=0 the records represent ports 0-255, when 'port_page'=1 the records represent ports 256-511 and so on. The register is reserved while using the legacy model. Signed-off-by: -
Amit Cohen authored
SFGC register maps {packet type, bridge type} -> {MID base, table type}. As preparation for unified bridge model, remove 'mid' field and add 'mid_base' field. The MID index (index to PGT table which maps MID to local port list and SMPE index) is a result of 'mid_base' + 'fid_offset'. Using the legacy bridge model, firmware configures 'mid_base'. However, using the new model, software is responsible to configure it via SFGC register. The 'mid_base' is configured per {packet type, bridge type}, for example, for {Unicast, .1Q}, {Broadcast, .1D}. Add the field 'mid_base' to SFGC register and increase the length of the register accordingly. Remove the field 'mid' as currently it is ignored by the device, its use is an old leftover. Signed-off-by: -
Amit Cohen authored
SFMR register creates and configures FIDs. As preparation for unified bridge model, add a required field for future use. The PGT (Port Group) table maps multicast ID (MID) to {local port list, SMPE index} on Spectrum-1 and to {local port list} on the other ASICs. In the legacy model, software did not interact with this table directly. Instead, it was accessed by firmware in response to registers such as SFTR and SMID. In the new model, the SFTR register is deprecated and software has full control over the PGT table using the SMID register. The configuration of MDB entries (using SFD) is unchanged, but flooding configuration is completely different. SFGC register maps {packet type, bridge type} -> {MID base, table type}, then with FID and FID-offset which are configured via SFMR, the MID index is obtained. Add the field 'flood_bridge_type' to SFMR, software can separate between 802.1q FIDs and vFIDs using two types which are supported. Signed-off-by: -
Amit Cohen authored
SFD register configures FDB table. As preparation for unified bridge model, add some required fields for future use. In the new model, firmware no longer configures the egress VID, this responsibility is moved to software. For layer 2 this means that software needs to determine the egress VID for both unicast and multicast. For unicast FDB records and unicast LAG FDB records, the VID needs to be set via new fields in SFD - 'set_vid' and 'vid'. Add the two mentioned fields for future use. Signed-off-by:
-
Amit Cohen authored
SFMR register creates and configures FIDs. As preparation unified bridge model, add some required fields for future use. The device includes two main tables to support layer 2 multicast (i.e., MDB and flooding). These are the PGT (Port Group Table) and the MPE (Multicast Port Egress) table. - PGT is {MID -> (bitmap of local_port, SPME index)} - MPE is {(Local port, SMPE index) -> eVID} In Spectrum-2 and later ASICs, the SMPE index is an attribute of the FID and programmed via new fields in SFMR register - 'smpe_valid' and 'smpe'. Add the two mentioned fields for future use and increase the length of the register accordingly. Signed-off-by: -
Amit Cohen authored
SMID register maps multicast ID (MID) into a list of local ports. As preparation for unified bridge model, add some required fields for future use. The device includes two main tables to support layer 2 multicast (i.e., MDB and flooding). These are the PGT (Port Group Table) and the MPE (Multicast Port Egress) table. - PGT is {MID -> (bitmap of local_port, SPME index)} - MPE is {(Local port, SMPE index) -> eVID} In Spectrum-1, both indexes into the MPE table (local port and SMPE) are derived from the PGT table. Therefore, the SMPE index needs to be programmed as part of the PGT entry via new fields in SMID - 'smpe_valid' and 'smpe'. Add the two mentioned fields for future use and align the callers of mlxsw_reg_smid2_pack() to pass zeros for SMPE fields. Signed-off-by: -
Amit Cohen authored
The SMPE register maps {egress_port, SMPE index} -> VID. The device includes two main tables to support layer 2 multicast (i.e., MDB and flooding). These are the PGT (Port Group Table) and the MPE (Multicast Port Egress) table. - PGT is {MID -> (bitmap of local_port, SPME index)} - MPE is {(Local port, SMPE index) -> eVID} In Spectrum-1, the index into the MPE table - called switch multicast to port egress VID (SMPE) - is derived from the PGT entry, whereas in Spectrum-2 and later ASICs it is derived from the FID. In the legacy model, software did not interact with this table as it was completely hidden in firmware. In the new model, software needs to populate the table itself in order to map from {Local port, SMPE index} to an egress VID. This is done using the SMPE register. Add the register for future use. Signed-off-by: -
Amit Cohen authored
SVFA register controls the VID to FID mapping and {Port, VID} to FID mapping for virtualized ports. As preparation for unified bridge model, add some required fields for future use. On ingress, after ingress ACL, a packet needs to be classified to a FID. The key for this lookup can be one of: 1. VID. When port is not in virtual mode. 2. {RQ, VID}. When port is in virtual mode. 3. FID. When FID was set by ingress ACL. Since RITR no longer performs ingress configuration, the ingress RIF for the first two entry types needs to be set via new fields in SVFA - 'irif_v' and 'irif'. Add the two mentioned fields for future use and increase the length of the register accordingly. Signed-off-by: -
Amit Cohen authored
SFMR register creates and configures FIDs. As preparation for unified bridge model, add some required fields for future use. On ingress, after ingress ACL, a packet needs to be classified to a FID. The key for this lookup can be one of: 1. VID. When port is not in virtual mode. 2. {RQ, VID}. When port is in virtual mode. 3. FID. When FID was set by ingress ACL. For example, via VR_AND_FID_ACTION. Since RITR no longer performs ingress configuration, the ingress RIF for the last entry type needs to be set via new fields in SFMR - 'irif_v' and 'irif'. Add the two mentioned fields for future use. Signed-off-by: -
Amit Cohen authored
SFMR register creates and configures FIDs. As preparation for unified bridge model, add a field for future use. In the new model, RITR no longer configures the rFID used for sub-port RIFs and it has to be created by software via SFMR. Such FIDs need to be created with special flood indication using 'flood_rsp' field. When set, this bit instructs the device to manage the flooding entries for this FID in a reserved part of the port group table (PGT). Signed-off-by:
-
Ronak Doshi authored
'Commit 6f91f4ba ("vmxnet3: add support for capability registers")' added support for capability registers. These registers are used to advertize capabilities of the device. The patch updated the dev_caps to disable outer checksum offload if PTCR register does not support it. However, it missed to update other overlay offloads. This patch fixes this issue. Fixes: 6f91f4ba ("vmxnet3: add support for capability registers") Signed-off-by:
Ronak Doshi <doshir@vmware.com> Signed-off-by:
-
David S. Miller authored
Kuniyuki Iwashima says: ==================== raw: Fix nits of RCU conversion series. The first patch fixes a build error by commit ba44f818 ("raw: use more conventional iterators"), but it does not land in the net tree, so this series is targeted to net-next. The second patch replaces some hlist functions with sk's helper macros. ==================== Signed-off-by:
-
Kuniyuki Iwashima authored
hlist_nulls_add_head_rcu() and hlist_nulls_for_each_entry() have dedicated macros for sk. Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
-
Kuniyuki Iwashima authored
The trailing semicolon causes a compiler error, so let's remove it. net/ipv4/raw.c: In function ‘raw_icmp_error’: net/ipv4/raw.c:266:2: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] 266 | struct hlist_nulls_head *hlist; | ^~~~~~ Fixes: ba44f818 ("raw: use more conventional iterators") Signed-off-by:
-
- 19 Jun, 2022 6 commits
-
-
Xiang wangx authored
Delete the redundant word 'and'. Signed-off-by:
Xiang wangx <wangxiang@cdjrlc.com> Signed-off-by:
-
Xiang wangx authored
Delete the redundant word 'and'. Signed-off-by:
-
Xiang wangx authored
Delete the redundant word 'and'. Signed-off-by:
-
Simon Horman authored
This reverts commit 9386ebcc ("nfp: update nfp_X logging definitions") The reverted patch was intended to improve logging for the NFP driver by including information such as the source code file and number in log messages. Unfortunately our experience is that this has not improved things as we had hoped. The resulting logs are inconsistent with (most) other kernel log messages. And rely on knowledge of the source code version in order for the extra information to be useful. Thus, revert the change. We acknowledge that Jakub Kicinski <kuba@kernel.org> foresaw this problem. Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== net: introduce mii_bmcr_encode_fixed() While converting the mv88e6xxx driver to phylink pcs, it has been noticed that we've started to have repeated cases where we convert a speed and duplex to a BMCR value. Rather than open coding this in multiple locations, let's provide a helper for this - in linux/mii.h. This helper not only takes care of the standard 10, 100 and 1000Mbps encodings, but also includes 2500Mbps (which is the same as 1000Mbps) for those users who require that encoding as well. Unknown speeds will be encoded to 10Mbps, and non-full duplexes will be encoded as half duplex. This series converts the existing users to the new helper, and the mv88e6xxx conversion will add further users in the 6352 and 639x PCS code. ==================== Signed-off-by: -
Russell King (Oracle) authored
Use the newly introduced mii_bmcr_encode_fixed() for the xpcs driver. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
