- 30 Nov, 2023 28 commits
-
-
Petr Machata authored
In CFF flood mode, the way flood vectors are looked up changes: there's a per-FID PGT base, to which a small offset is added depending on type of traffic. Thus each FID occupies a small contiguous block of PGT memory, whereas in the controlled flood mode, flood vectors for a given FID were spread across the PGT. Each FID is associated with one of a handful of profiles. The profile and the traffic type are then used as keys to look up the PGT offset. This offset is then added to the per-FID PGT base. The profile / type / offset mapping needs to be configured by the driver, and is only relevant in CFF flood mode. In this patch, add the SFFP initialization code. Only initialize the one profile currently explicitly used. As follow-up patch add more profiles, this code will pick them up and initialize as well. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/2c4733ed72d439444218969c032acad22cd4ed88.1701183892.git.petrm@nvidia.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Petr Machata authored
In the CFF mode, flood profiles are identified by a unique numerical identifier. This is used for configuration of FIDs and for configuration of traffic-type to PGT offset rules. In both cases, the numerical identifier serves as a handle for the flood profile. Add the identifier to the flood profile structure. There is currently only one flood profile in use explicitly, the one used for all bridging. Eventually three will be necessary in total: one for bridges, one for rFIDs, one for NVE underlay. A total of four profiles are supported by the HW. Start allocating at 1, because 0 is currently used for underlay NVE flood. Signed-off-by:
-
Petr Machata authored
A flood profile is a mapping from traffic type to an offset at which a flood vector should be looked up. In mlxsw so far, a flood profile was somewhat implicitly represented by flood table array. When the CFF flood mode will be introduced, the flood profile will become more explicit: each will get a number and the profile ID / traffic-type / offset mapping will actually need to be initialized in the hardware. Therefore it is going to be handy to have a structure that keeps all the components that compose a flood profile. Add this structure, currently with just the flood table array bits. In the FID families that flood at all, reference the flood profile instead of just the table array. Signed-off-by:
-
Petr Machata authored
In the CFF flood mode, the driver has to allocate a table within PGT, which holds flood vectors for router subport FIDs. For LAGs, these flood vectors have to obviously be maintained dynamically as port membership in a LAG changes. But even for physical ports, the flood vectors have to be kept valid, and may not contain enabled bits corresponding to non-existent ports. It is therefore not possible to precompute the port part of the RSP table, it has to be maintained as ports come and go due to splits. To support the RSP table maintenance, add to FID ops two new ops: fid_port_init and fid_port_fini, for when a port comes to existence, or joins a lag, and vice versa. Invoke these ops from mlxsw_sp_port_fids_init() and mlxsw_sp_port_fids_fini(), which are called when port is added and removed, respectively. Also add two new hooks for LAG maintenance, mlxsw_sp_fid_port_join_lag() / _leave_lag() which transitively call into the same ops. Later patches will actually add the op implementations themselves, this just adds the scaffolding. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
-
Petr Machata authored
In CFF flood mode, the rFID family will allocate two tables. One for unknown UC traffic, one for everything else. Add a traffic type for the everything else traffic. Signed-off-by:
-
Petr Machata authored
The way SFMR is packed differs between the controlled and CFF flood modes. Add an op to dispatch it dynamically. Signed-off-by:
-
Petr Machata authored
In the CFF flood mode, the way to determine a PGT address where a given FID / flood table resides is different from the controlled flood mode, which mlxsw currently uses. Furthermore, this will differ between rFID family and bridge families. The operation therefore needs to be dynamically dispatched. To that end, add an op to FID-family ops. Signed-off-by:
-
Petr Machata authored
In the CFF flood mode, the PGT allocation size of RFID family will not depend on number of FIDs, but rather number of ports and LAGs. Therefore introduce a FID family operation to calculate the PGT allocation size. The way that size is calculated in the CFF mode depends on calling fallible functions. Thus express the op as returning an int, with the size returned via a pointer argument. Signed-off-by:
-
Petr Machata authored
In controlled flood mode, for each bridge FID family (i.e., 802.1Q and 802.1D) and packet type (i.e., UUC/MC/BC), the hardware needs to be told which PGT address to use as the base address for the flood table and how to determine the offset from the base for each FID. The above is not needed in CFF mode where each FID has its own flood table instead of the FID family itself. Therefore, create a new FID family operation for the above configuration and only implement it for the 802.1Q and 802.1D families in controlled flood mode. No functional changes intended. Signed-off-by:
-
Petr Machata authored
Move the function to the point where it will need to be to be visible for the 802.1d ops. Signed-off-by:
-
Petr Machata authored
This operation will be fallible for rFIDs in CFF mode, which will be introduced in follow-up patches. Have it return an int, and handle the failures in the caller. Signed-off-by:
-
Petr Machata authored
In future patches, for CFF flood mode support, we will need a way to determine a PGT base dynamically, as an op. Therefore, for symmetry, split out a helper, mlxsw_sp_fid_pgt_base_ctl(), that determines a PGT base in the controlled mode as well. Now that the helper is available, use it in mlxsw_sp_fid_flood_table_init() which currently invokes the FID->MID helper to that end. Signed-off-by:
-
Petr Machata authored
Currently, mlxsw always uses a "controlled" flood mode on all Nvidia Spectrum generations. The following patches will however introduce a possibility to run a "CFF" (for Compressed FID Flooding) mode on newer machines, if the FW supports it. To reflect that, label all FID ops, FID families and FID family arrays with a _ctl suffix. This will make it clearer what is what when the CFF families are introduced in later patches. Keep the dummy family intact. Since the dummy family has no flood tables in either CTL or CFF mode, there are no flood-mode-specific callbacks. Additionally, add a remark at two fields that they are only relevant when flood mode is not CFF. Signed-off-by:
-
Petr Machata authored
Currently, mlxsw always uses a "controlled" flood mode on all Nvidia Spectrum generations. The following patches will however introduce a possibility to run a "CFF" (for Compressed FID Flooding) mode on newer machines, if the FW supports it. Several operations will differ between how they need to be done in controlled mode vs. CFF mode. Thus the per-FID-family ops will differ between controlled and CFF, thus the FID family array as such will differ depending on whether the mode negotiated with FW is controlled or CFF. The simple approach of having several globally visible arrays for spectrum.c to statically choose from no longer works. Instead privatize all FID initialization and finalization logic, and expose it as ops instead. Signed-off-by:
-
Christian Marangi authored
On further testing on BE target with kernel test robot, it was notice that the endianness conversion for addr and CRC in fw_load_memory was wrong. Drop the cpu_to_le32 conversion for addr load as it's not needed. Use get_unaligned_le32 instead of get_unaligned for FW data word load to correctly convert data in the correct order to follow system endian. Also drop the cpu_to_be32 for CRC calculation as it's wrong and would cause different CRC on BE system. The loaded word is swapped internally and MAILBOX calculates the CRC on the swapped word. To correctly calculate the CRC to be later matched with the one from MAILBOX, use an u8 struct and swap the word there to keep the same order on both LE and BE for crc_ccitt_false function. Also add additional comments on how the CRC verification for the loaded section works. CRC is calculated as we load the section and verified with the MAILBOX only after the entire section is loaded to skip additional slowdown by loop the section data again. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311210414.sEJZjlcD-lkp@intel.com/ Fixes: e93984eb ("net: phy: aquantia: add firmware load support") Tested-by: Robert Marko <robimarko@gmail.com> # ipq8072 LE device Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20231128135928.9841-1-ansuelsmth@gmail.comSigned-off-by:
-
Vincent Whitchurch authored
Add support to allow Fast Link Down (aka "Enhanced link detection") to be controlled via the ETHTOOL_PHY_FAST_LINK_DOWN tunable. These PHYs have this feature enabled by default. Signed-off-by:
Vincent Whitchurch <vincent.whitchurch@axis.com> Acked-by:
Nuno Sa <nuno.sa@analog.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231127-adin-fld-v1-1-797f6423fd48@axis.comSigned-off-by:
-
Heiner Kallweit authored
If we know that the task is going to be a no-op, don't even schedule it. And remove the check for netif_running() in the worker function, the check for flag RTL_FLAG_TASK_ENABLED is sufficient. Note that we can't remove the check for flag RTL_FLAG_TASK_ENABLED in the worker function because we have no guarantee when it will be executed. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/c65873a3-7394-4107-99a7-83f20030779c@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Linus Walleij says: ==================== Create a binding for the Marvell MV88E6xxx DSA switches The Marvell switches are lacking DT bindings. I need proper schema checking to add LED support to the Marvell switch. Just how it is, it can't go on like this. Some Device Tree fixes are included in the series, these remove the major and most annoying warnings fallout noise: some warnings remain, and these are of more serious nature, such as missing phy-mode. They can be applied individually, or to the networking tree with the rest of the patches. Thanks to Andrew Lunn, Vladimir Oltean and Russell King for excellent review and feedback! This latest version employs special compatibles in the odd ABI device trees. v8: https://lore.kernel.org/r/20231114-marvell-88e6152-wan-led-v8-0-50688741691b@linaro.org v7: https://lore.kernel.org/r/20231024-marvell-88e6152-wan-led-v7-0-2869347697d1@linaro.org v6: https://lore.kernel.org/r/20231024-marvell-88e6152-wan-led-v6-0-993ab0949344@linaro.org v5: https://lore.kernel.org/r/20231023-marvell-88e6152-wan-led-v5-0-0e82952015a7@linaro.org v4: https://lore.kernel.org/r/20231018-marvell-88e6152-wan-led-v4-0-3ee0c67383be@linaro.org v3: https://lore.kernel.org/r/20231016-marvell-88e6152-wan-led-v3-0-38cd449dfb15@linaro.org v2: https://lore.kernel.org/r/20231014-marvell-88e6152-wan-led-v2-0-7fca08b68849@linaro.org v1: https://lore.kernel.org/r/20231013-marvell-88e6152-wan-led-v1-0-0712ba99857c@linaro.org ==================== Link: https://lore.kernel.org/r/20231127-marvell-88e6152-wan-led-v9-0-272934e04681@linaro.orgSigned-off-by:
-
Linus Walleij authored
The Marvell MV88E6060 is one of the oldest DSA switches from Marvell, and it has DT bindings used in the wild. Let's define them properly. It is different enough from the rest of the MV88E6xxx switches that it deserves its own binding. Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231127-marvell-88e6152-wan-led-v9-5-272934e04681@linaro.orgSigned-off-by:
-
Linus Walleij authored
This is an attempt to rewrite the Marvell MV88E6xxx switch bindings in YAML schema. The current text binding says: WARNING: This binding is currently unstable. Do not program it into a FLASH never to be changed again. Once this binding is stable, this warning will be removed. Well that never happened before we switched to YAML markup, we can't have it like this, what about fixing the mess? Reviewed-by:
-
Linus Walleij authored
Accept special node naming variants for Marvell switches with special node names as ABI. This is maybe not the prettiest but it avoids special-casing the Marvell MV88E6xxx bindings by copying a lot of generic binding code down into that one binding just to special-case these unfixable nodes. Reviewed-by:
-
Linus Walleij authored
When adding a proper schema for the Marvell mx88e6xxx switch, the scripts start complaining about this embedded example: dtschema/dtc warnings/errors: net/marvell,mvusb.example.dtb: switch@0: ports: '#address-cells' is a required property from schema $id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml# net/marvell,mvusb.example.dtb: switch@0: ports: '#size-cells' is a required property from schema $id: http://devicetree.org/schemas/net/dsa/marvell,mv88e6xxx.yaml# Fix this up by extending the example with those properties in the ports node. While we are at it, rename "ports" to "ethernet-ports" and rename "switch" to "ethernet-switch" as this is recommended practice. Reviewed-by:
-
Linus Walleij authored
Bindings using dsa.yaml#/$defs/ethernet-ports specify that a DSA switch node need to have a ports or ethernet-ports subnode, and that is actually required, so add requirements using oneOf. Suggested-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== tools: ynl: fixes for the page-pool sample and the generation process Minor fixes to the new sample and the Makefiles. ==================== Link: https://lore.kernel.org/r/20231129193622.2912353-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Commit 2b7ac0c8 ("tools: ynl-gen: don't touch the output file if content is the same") is working too well. It was added so that ynl-regen -f doesn't make us rebuild half of the kernel, if there are no actual changes in any generated code. When ynl-gen-c is called by make, however, we're better off trusting make's tracking and overwrite the file. Otherwise if output is identical we won't update file timestamps and make will retry code gen on every invocation. Link: https://lore.kernel.org/r/20231129193622.2912353-5-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Parallel builds of ynl: make -C tools/net/ynl/ -j 4 don't work correctly right now. samples get handled before generated, so build of samples does not notice that protos.a has changed. Order samples to be last. Link: https://lore.kernel.org/r/20231129193622.2912353-4-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Building samples generates the following warning: In file included from page-pool.c:11: generated/netdev-user.h:21:45: warning: ‘enum netdev_xdp_rx_metadata’ declared inside parameter list will not be visible outside of this definition or declaration 21 | const char *netdev_xdp_rx_metadata_str(enum netdev_xdp_rx_metadata value); | ^~~~~~~~~~~~~~~~~~~~~~ Our magic way of including uAPI headers assumes the sample name matches the family name. We need to copy the flags over. Fixes: 637567e4 ("tools: ynl: add sample for getting page-pool information") Link: https://lore.kernel.org/r/20231129193622.2912353-3-kuba@kernel.orgSigned-off-by: -
Jakub Kicinski authored
The name of the "destroyed" field in the reply was not changed in the sample after we started calling it "detach_time". page-pool.c: In function ‘main’: page-pool.c:84:33: error: ‘struct <anonymous>’ has no member named ‘destroyed’ 84 | if (pp->_present.destroyed) | ^ Fixes: 637567e4 ("tools: ynl: add sample for getting page-pool information") Link: https://lore.kernel.org/r/20231129193622.2912353-2-kuba@kernel.orgSigned-off-by:
-
- 29 Nov, 2023 12 commits
-
-
Jakub Kicinski authored
Oleksij Rempel says: ==================== Fine-Tune Flow Control and Speed Configurations in Microchip KSZ8xxx DSA Driver This patch set focuses on enhancing the configurability of flow control, speed, and duplex settings in the Microchip KSZ8xxx DSA driver. The first patch allows more granular control over the CPU port's flow control, speed, and duplex settings. The second patch introduces a method for port configurations for port with integrated PHYs, primarily concerning flow control based on duplex mode. ==================== Link: https://lore.kernel.org/r/20231127145101.3039399-1-o.rempel@pengutronix.deSigned-off-by:
-
Oleksij Rempel authored
Last part of the driver do now support phylink_mac_link_up(). So, make it not optional. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20231127145101.3039399-4-o.rempel@pengutronix.deSigned-off-by:
-
Oleksij Rempel authored
This patch introduces the function 'ksz8_phy_port_link_up' to the Microchip KSZ8xxx driver. This function is responsible for setting up flow control and duplex settings for the ports that are integrated with PHYs. The KSZ8795 switch supports asymmetric pause control, which can't be fully utilized since a single bit controls both RX and TX pause. Despite this, the flow control can be adjusted based on the auto-negotiation process, taking into account the capabilities of both link partners. On the other hand, the KSZ8873's PORT_FORCE_FLOW_CTRL bit can be set by the hardware bootstrap, which ignores the auto-negotiation result. Therefore, even in auto-negotiation mode, we need to ensure that this bit is correctly set. When auto-negotiation isn't in use, we enforce symmetric pause control for the KSZ8795 switch. Please note, forcing flow control disable on a port while still advertising pause support isn't possible. While this scenario might not be practical or desired, it's important to be aware of this limitation when working with the KSZ8873 and similar devices. Signed-off-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
-
Oleksij Rempel authored
Allow flow control, speed, and duplex settings on the CPU port to be configurable. Previously, the speed and duplex relied on default switch values, which limited flexibility. Additionally, flow control was hardcoded and only functional in duplex mode. This update enhances the configurability of these parameters. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
-
Jakub Kicinski authored
John Fraker says: ==================== gve: Add support for non-4k page sizes. This patch series adds support for non-4k page sizes to the driver. Prior to this patch series, the driver assumes a 4k page size in many small ways, and will crash in a kernel compiled for a different page size. This changeset aims to be a minimal changeset that unblocks certain arm platforms with large page sizes. ==================== Link: https://lore.kernel.org/r/20231128002648.320892-1-jfraker@google.comSigned-off-by:
-
John Fraker authored
Prior to this change, gve crashes when attempting to run in kernels with page sizes other than 4k. This change removes unnecessary references to PAGE_SIZE and replaces them with more meaningful constants. Signed-off-by:
Jordan Kimbrough <jrkim@google.com> Signed-off-by:
John Fraker <jfraker@google.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20231128002648.320892-6-jfraker@google.comSigned-off-by:
-
John Fraker authored
This register is required on platforms with page sizes greater than 4k. This is because the tx side of the driver vmaps the entire queue page list of pages into a single flat address space, then uses the entire space. Without communicating the guest page size to the backend, the backend will only access the first 4k of each page in the queue page list. Signed-off-by:
-
John Fraker authored
These checks are safe to remove as they are no longer enforced by the backend. Retaining them would require updating them to work differently with page sizes larger than 4k. Signed-off-by:
-
John Fraker authored
adminq_pfn assumes a page size of 4k, causing this mechanism to break in kernels compiled with different page sizes. A new PCI device revision was needed for the device to be able to communicate with the driver how to set up the admin queue prior to having access to the admin queue. Signed-off-by:
-
John Fraker authored
This allows the adminq to be smaller than a page, paving the way for non 4k page support. This is to support platforms where PAGE_SIZE is not 4k, such as some ARM platforms. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-11-27 (i40e, iavf) This series contains updates to i40e and iavf drivers. Ivan Vecera performs more cleanups on i40e and iavf drivers; removing unused fields, defines, and unneeded fields. Petr Oros utilizes iavf_schedule_aq_request() helper to replace open coded equivalents. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: iavf: use iavf_schedule_aq_request() helper iavf: Remove queue tracking fields from iavf_adminq_ring i40e: Remove queue tracking fields from i40e_adminq_ring i40e: Remove AQ register definitions for VF types i40e: Delete unused and useless i40e_pf fields ==================== Link: https://lore.kernel.org/r/20231127211037.1135403-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Heiner Kallweit authored
Once upon a time, when r8169 was new, the multicast filter limit code was copied from RTL8139 driver. There the filter limit is even user-configurable. The filtering is hash-based and we don't have perfect filtering. Actually the mc filtering on RTL8125 still seems to be the same as used on 8390/NE2000. So it's not clear to me which benefit it should bring when switching to all-multi mode once a certain number of filter bits is set. More the opposite: Filtering out at least some unwanted mc traffic is better than no filtering. Also the available chip documentation doesn't mention any restriction. Therefore remove the filter limit. Signed-off-by:
-
