- 30 Nov, 2023 32 commits
-
-
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Support CFF flood mode The registers to configure to initialize a flood table differ between the controlled and CFF flood modes. In therefore needs to be an op. Add it, hook up the current init to the existing families, and invoke the op. PGT is an in-HW table that maps addresses to sets of ports. Then when some HW process needs a set of ports as an argument, instead of embedding the actual set in the dynamic configuration, what gets configured is the address referencing the set. The HW then works with the appropriate PGT entry. Among other allocations, the PGT currently contains two large blocks for bridge flooding: one for 802.1q and one for 802.1d. Within each of these blocks are three tables, for unknown-unicast, multicast and broadcast flooding: . . . | 802.1q | 802.1d | . . . | UC | MC | BC | UC | MC | BC | \______ _____/ \_____ ______/ v v FID flood vectors Thus each FID (which corresponds to an 802.1d bridge or one VLAN in an 802.1q bridge) uses three flood vectors spread across a fairly large region of PGT. This way of organizing the flood table (called "controlled") is not very flexible. E.g. to decrease a bridge scale and store more IP MC vectors, one would need to completely rewrite the bridge PGT blocks, or resort to hacks such as storing individual MC flood vectors into unused part of the bridge table. In order to address these shortcomings, Spectrum-2 and above support what is called CFF flood mode, for Compressed FID Flooding. In CFF flood mode, each FID has a little table of its own, with three entries adjacent to each other, one for unknown-UC, one for MC, one for BC. This allows for a much more fine-grained approach to PGT management, where bits of it are allocated on demand. . . . | FID | FID | FID | FID | FID | . . . |U|M|B|U|M|B|U|M|B|U|M|B|U|M|B| \_____________ _____________/ v FID flood vectors Besides the FID table organization, the CFF flood mode also impacts Router Subport (RSP) table. This table contains flood vectors for rFIDs, which are FIDs that reference front panel ports or LAGs. The RSP table contains two entries per front panel port and LAG, one for unknown-UC traffic, and one for everything else. Currently, the FW allocates and manages the table in its own part of PGT. rFIDs are marked with flood_rsp bit and managed specially. In CFF mode, rFIDs are managed as all other FIDs. The driver therefore has to allocate and maintain the flood vectors. Like with bridge FIDs, this is more work, but increases flexibility of the system. The FW currently supports both the controlled and CFF flood modes. To shed complexity, in the future it should only support CFF flood mode. Hence this patchset, which adds CFF flood mode support to mlxsw. Since mlxsw needs to maintain both the controlled mode as well as CFF mode support, we will keep the layout as compatible as possible. The bridge tables will stay in the same overall shape, just their inner organization will change from flood mode -> FID to FID -> flood mode. Likewise will RSP be kept as a contiguous block of PGT memory, as was the case when the FW maintained it. - The way FIDs get configured under the CFF flood mode differs from the currently used controlled mode. The simple approach of having several globally visible arrays for spectrum.c to statically choose from no longer works. Patch #1 thus privatizes all FID initialization and finalization logic, and exposes it as ops instead. - Patch #2 renames the ops that are specific to the controlled mode, to make room in the namespace for the CFF variants. Patch #3 extracts a helper to compute flood table base out of mlxsw_sp_fid_flood_table_mid(). - The op fid_setup configured fid_offset, i.e. the number of this FID within its family. For rFIDs in CFF mode, to determine this number, the driver will need to do fallible queries. Thus in patch #4, make the FID setup operation fallible as well. - Flood mode initialization routine differs between the controlled and CFF flood modes. The controlled mode needs to configure flood table layout, which the CFF mode does not need to do. In patch #5, move mlxsw_sp_fid_flood_table_init() up so that the following patch can make use of it. In patch #6, add an op to be invoked per table (if defined). - The current way of determining PGT allocation size depends on the number of FIDs and number of flood tables. RFIDs however have PGT footprint depending not on number of FIDs, but on number of ports and LAGs, because which ports an rFID should flood to does not depend on the FID itself, but on the port or LAG that it references. Therefore in patch #7, add FID family ops for determining PGT allocation size. - As elaborated above, layout of PGT will differ between controlled and CFF flood modes. In CFF mode, it will further differ between rFIDs and other FIDs (as described at previous patch). The way to pack the SFMR register to configure a FID will likewise differ from controlled to CFF. Thus in patches #8 and #9 add FID family ops to determine PGT base address for a FID and to pack SFMR. - Patches #10 and #11 add more bits for RSP support. In patch #10, add a new traffic type enumerator, for non-UC traffic. This is a combination of BC and MC traffic, but the way that mlxsw maps these mnemonic names to actual traffic type configurations requires that we have a new name to describe this class of traffic. Patch #11 then adds hooks necessary for RSP table maintenance. As ports come and go, and join and leave LAGs, it is necessary to update flood vectors that the rFIDs use. These new hooks will make that possible. - Patches #12, #13 and #14 introduce flood profiles. These have been implicit so far, but the way that CFF flood mode works with profile IDs requires that we make them explicit. Thus in patch #12, introduce flood profile objects as a set of flood tables that FID families then refer to. The FID code currently only uses a single flood profile. In patch #13, add a flood profile ID to flood profile objects. In patch #14, when in CFF mode, configure SFFP according to the existing flood profiles (or the one that exists as of that point). - Patches #15 and #16 add code to implement, respectively, bridge FIDs and RSP FIDs in CFF mode. - In patch #17, toggle flood_mode_prefer_cff on Spectrum-2 and above, which makes the newly-added code live. ==================== Link: https://lore.kernel.org/r/cover.1701183891.git.petrm@nvidia.comSigned-off-by:Jakub Kicinski <kuba@kernel.org>
-
Petr Machata authored
Mark all Spectrum>2 systems as preferring CFF flood mode if supported by the firmware. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/8a3d2ad96b943f7e3f53f998bd333a14e19cd641.1701183892.git.petrm@nvidia.comSigned-off-by:
-
Petr Machata authored
In this patch, add the artifacts for the rFID family that works in CFF flood mode. The same that was said about PGT organization and lookup in bridge FID families applies for the rFID family as well. The main difference lies in the fact that in the controlled flood mode, the FW was taking care of maintaining the PGT tables for rFIDs. In CFF mode, the responsibility shifts to the driver. All rFIDs are based off either a front panel port, or a LAG port. For those based off ports, we need to maintain at worst one PGT block for each port, for those based off LAGs, one PGT block per LAG. This reflects in the pgt_size callback, which determines the PGT footprint based on number of ports and the LAG capacity. A number of FIDs may end up using the same PGT base. Unlike with bridges, where membership of a port in a given FID is highly dynamic, an rFID based of a port will just always need to flood to that port. Both the port and the LAG subtables need to be actively maintained. To that end, the CFF rFID family implements fid_port_init and fid_port_fini callbacks, which toggle the necessary bits. Both FID-MID translation and SFMR packing then point into either the port or the LAG subtable, to the block that corresponds to a given port or a given LAG, depending on what port the RIF bound to the rFID uses. As in the previous patch, the way CFF flood mode organizes PGT accesses allows for much more smarts and dynamism. As in the previous patch, we rather aim to keep things simple and static. Signed-off-by:
-
Petr Machata authored
In this patch, add the artifacts for 802.1d and 802.1q FID families that work in CFF flood mode. 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. The term "flood table" as used by the spectrum_fid module, borrows from controlled flood mode way of organizing the PGT table. There flood tables were actual tables, contiguous in the PGT. In the CFF flood mode, they are more abstract: a flood table becomes a collection of e.g. all first rows of the per-FID PGT blocks. Nonetheless we retain the nomenclature. FIDs are still configured through the SFMR register, but there are different fields to set under CFF mode: PGT base and profile. Thus register packing gets a dedicated op overload as well. The new organization of PGT makes it possible to treat the PGT as a block of an ordinary memory, allocate and deallocate on demand, and achieve better flexibility. Here instead, we aim to keep the code as close as possible to the previous controlled flood mode, support for which we need to retain for Spectrum-1 and older FW versions anyway. Thus the PGT footprint of the individual families is the same as before, just the internal organization of the per-family PGT region differs. Hence the pgt_size callback is reused between the controlled and CFF flood modes. Since the dummy family has no flood tables in either the CTL mode or in CFF mode, the existing one can be reused for the CFF family array. Users should not notice any changes between the controlled and CFF flood modes. Signed-off-by:
-
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 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:
-
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 8 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:
-
