summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/meta/fbnic/fbnic_phylink.c
AgeCommit message (Collapse)Author
2025-06-24fbnic: Add support for setting/getting pause configurationAlexander Duyck
Phylink already handles most of the pieces necessary for configuring autonegotation. With that being the case we can add support for getting/setting pause now by just passing through the ethtool call to the phylink code. Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/175028448974.625704.14427543910503058114.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-24fbnic: Add support for reporting link configAlexander Duyck
This change adds some basic support for reporting the current link config to the user via ethtool. Currently the main components reported are the carrier status, link speed, and FEC. For now we are handling the FEC directly as phylink doesn't have support for it. The plan is to work on incorporating FEC support into phylink and eventually adding the ability for us to set the FEC configuration through phylink itself. In addition as we don't yet have SFP or PHY support the listed modes supported are including ones not supported by the media we are attached to. That will hopefully be addressed once we can get the QSFP modules supported. Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Link: https://patch.msgid.link/175028448275.625704.60592644122010798.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-24fbnic: Set correct supported modes and speeds based on FW settingAlexander Duyck
The fbnic driver was using the XLGMII link mode to enable phylink, however that mode wasn't the correct one to use as the NIC doesn't actually use XLGMII, it is using a combinations of 25G, 50G, and 100G interface modes and configuring those via pins exposed on the PCS, MAC, and PHY interfaces. To more accurately reflect that we should drop the uxe of XGMII and XLGMII and instead use the correct interface types. Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Link: https://patch.msgid.link/175028447568.625704.17971496887030109107.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-24fbnic: Replace link_mode with AUIAlexander Duyck
The way we were using "link_mode" was really more to describe the interface between the attachment unit interface(s) we were using on the device. Specifically the AUI is describing the modulation and the number of lanes we are using. So we can simplify this by replacing link_mode with aui. Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Link: https://patch.msgid.link/175028446219.625704.8050098629750896117.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-24fbnic: Retire "AUTO" flags and cleanup handling of FW link settingsAlexander Duyck
There were several issues in the way we were handling the link info coming from firmware. First is the fact that we were carrying around "AUTO" flags to indicate that we needed to populate the values. We can just drop this and assume that we will always be populating the settings from firmware. With this we can also clean up the masking as the "AUTO" flags were just there to be stripped anyway. Second since we are getting rid of the "AUTO" setting we still need a way to report that the link is not configured. We convert the link_mode "AUTO" to "UNKNOWN" to do this. With this we can avoid reporting link up in the phylink_pcs_get_state call as we will just set link to 0 and return without updating the link speed. This is preferred versus the driver just forcing 50G which makes it harder to recover when the FW does start providing valid settings. With this the plan is to eventually replace the link_mode we use with the interface_mode from phylink for all intents and purposes and have the two be interchangeable. At that point we can convert the FW provided settings over to something closer to link partner settings and give phylink greater control of the interface allowing for user override of the settings and an asynchronous setup of the link versus having to pull early settings from firmware. Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Link: https://patch.msgid.link/175028445548.625704.1367708155813490215.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-02-14net: remove phylink_pcs .neg_mode booleanRussell King (Oracle)
As all PCS are using the neg_mode parameter rather than the legacy an_mode, remove the ability to use the legacy an_mode. We remove the tests in the phylink code, unconditionally passing the PCS neg_mode parameter to PCS methods, and remove setting the flag from drivers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tidPn-0040hd-2R@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: phylink: pass neg_mode into .pcs_get_state() methodRussell King (Oracle)
Pass the current neg_mode into the .pcs_get_state() method. Update all users of phylink PCS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeT-000Et3-4L@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-07-15eth: fbnic: Add link detectionAlexander Duyck
Add basic support for detecting the link and reporting it at the netdev layer. For now we will just use the values reporeted by the firmware as the link configuration and assume that is the current configuration of the MAC and PCS. With this we start the stubbing out of the phylink interface that will be used to provide the configuration interface for ethtool in a future patch set. The phylink interface isn't an exact fit. As such we are currently working around several issues in this patch set that we plan to address in the future such as: 1. Support for FEC 2. Support for multiple lanes to handle 50GbaseR2 vs 50GbaseR1 3. Support for BMC CC: Russell King <linux@armlinux.org.uk> CC: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Link: https://patch.msgid.link/172079939835.1778861.5964790909718481811.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski <kuba@kernel.org>