2019-01-22 02:10:19 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
/*
|
|
|
|
|
* phylink models the MAC to optional PHY connection, supporting
|
|
|
|
|
* technologies such as SFP cages where the PHY is hot-pluggable.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2015 Russell King
|
|
|
|
|
*/
|
2021-06-11 18:53:59 +08:00
|
|
|
#include <linux/acpi.h>
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
#include <linux/ethtool.h>
|
|
|
|
|
#include <linux/export.h>
|
|
|
|
|
#include <linux/gpio/consumer.h>
|
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
|
#include <linux/of.h>
|
|
|
|
|
#include <linux/of_mdio.h>
|
|
|
|
|
#include <linux/phy.h>
|
|
|
|
|
#include <linux/phy_fixed.h>
|
|
|
|
|
#include <linux/phylink.h>
|
|
|
|
|
#include <linux/rtnetlink.h>
|
|
|
|
|
#include <linux/spinlock.h>
|
2018-05-11 04:17:31 +08:00
|
|
|
#include <linux/timer.h>
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
#include <linux/workqueue.h>
|
|
|
|
|
|
2017-07-25 22:03:18 +08:00
|
|
|
#include "sfp.h"
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
#include "swphy.h"
|
|
|
|
|
|
|
|
|
|
#define SUPPORTED_INTERFACES \
|
|
|
|
|
(SUPPORTED_TP | SUPPORTED_MII | SUPPORTED_FIBRE | \
|
|
|
|
|
SUPPORTED_BNC | SUPPORTED_AUI | SUPPORTED_Backplane)
|
|
|
|
|
#define ADVERTISED_INTERFACES \
|
|
|
|
|
(ADVERTISED_TP | ADVERTISED_MII | ADVERTISED_FIBRE | \
|
|
|
|
|
ADVERTISED_BNC | ADVERTISED_AUI | ADVERTISED_Backplane)
|
|
|
|
|
|
|
|
|
|
enum {
|
|
|
|
|
PHYLINK_DISABLE_STOPPED,
|
2017-07-25 22:03:18 +08:00
|
|
|
PHYLINK_DISABLE_LINK,
|
2021-09-07 18:56:46 +08:00
|
|
|
PHYLINK_DISABLE_MAC_WOL,
|
2023-07-13 16:42:07 +08:00
|
|
|
|
|
|
|
|
PCS_STATE_DOWN = 0,
|
|
|
|
|
PCS_STATE_STARTING,
|
|
|
|
|
PCS_STATE_STARTED,
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
};
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* struct phylink - internal data type for phylink
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
struct phylink {
|
2017-12-01 18:24:47 +08:00
|
|
|
/* private: */
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
struct net_device *netdev;
|
2020-03-31 01:44:50 +08:00
|
|
|
const struct phylink_mac_ops *mac_ops;
|
2019-05-29 01:38:12 +08:00
|
|
|
struct phylink_config *config;
|
2020-07-21 19:04:46 +08:00
|
|
|
struct phylink_pcs *pcs;
|
2019-05-29 01:38:13 +08:00
|
|
|
struct device *dev;
|
|
|
|
|
unsigned int old_link_state:1;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
unsigned long phylink_disable_state; /* bitmask of disables */
|
|
|
|
|
struct phy_device *phydev;
|
|
|
|
|
phy_interface_t link_interface; /* PHY_INTERFACE_xxx */
|
2019-12-11 18:56:35 +08:00
|
|
|
u8 cfg_link_an_mode; /* MLO_AN_xxx */
|
|
|
|
|
u8 cur_link_an_mode;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
u8 link_port; /* The current non-phy ethtool port */
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(supported);
|
|
|
|
|
|
|
|
|
|
/* The link configuration settings */
|
|
|
|
|
struct phylink_link_state link_config;
|
2019-05-28 17:27:21 +08:00
|
|
|
|
|
|
|
|
/* The current settings */
|
|
|
|
|
phy_interface_t cur_interface;
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
struct gpio_desc *link_gpio;
|
2019-05-28 17:57:23 +08:00
|
|
|
unsigned int link_irq;
|
2018-05-11 04:17:31 +08:00
|
|
|
struct timer_list link_poll;
|
2017-12-13 08:00:28 +08:00
|
|
|
void (*get_fixed_state)(struct net_device *dev,
|
|
|
|
|
struct phylink_link_state *s);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
struct mutex state_mutex;
|
|
|
|
|
struct phylink_link_state phy_state;
|
|
|
|
|
struct work_struct resolve;
|
2023-06-16 20:06:22 +08:00
|
|
|
unsigned int pcs_neg_mode;
|
2023-07-13 16:42:07 +08:00
|
|
|
unsigned int pcs_state;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
bool mac_link_dropped;
|
2022-02-22 01:10:52 +08:00
|
|
|
bool using_mac_select_pcs;
|
2017-07-25 22:03:18 +08:00
|
|
|
|
|
|
|
|
struct sfp_bus *sfp_bus;
|
2019-12-11 18:56:45 +08:00
|
|
|
bool sfp_may_have_phy;
|
2022-09-30 22:21:00 +08:00
|
|
|
DECLARE_PHY_INTERFACE_MASK(sfp_interfaces);
|
2019-12-11 18:56:45 +08:00
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(sfp_support);
|
|
|
|
|
u8 sfp_port;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
};
|
|
|
|
|
|
2019-05-29 01:38:14 +08:00
|
|
|
#define phylink_printk(level, pl, fmt, ...) \
|
|
|
|
|
do { \
|
|
|
|
|
if ((pl)->config->type == PHYLINK_NETDEV) \
|
|
|
|
|
netdev_printk(level, (pl)->netdev, fmt, ##__VA_ARGS__); \
|
|
|
|
|
else if ((pl)->config->type == PHYLINK_DEV) \
|
|
|
|
|
dev_printk(level, (pl)->dev, fmt, ##__VA_ARGS__); \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
#define phylink_err(pl, fmt, ...) \
|
|
|
|
|
phylink_printk(KERN_ERR, pl, fmt, ##__VA_ARGS__)
|
|
|
|
|
#define phylink_warn(pl, fmt, ...) \
|
|
|
|
|
phylink_printk(KERN_WARNING, pl, fmt, ##__VA_ARGS__)
|
|
|
|
|
#define phylink_info(pl, fmt, ...) \
|
|
|
|
|
phylink_printk(KERN_INFO, pl, fmt, ##__VA_ARGS__)
|
2019-11-01 06:42:26 +08:00
|
|
|
#if defined(CONFIG_DYNAMIC_DEBUG)
|
2019-05-29 01:38:14 +08:00
|
|
|
#define phylink_dbg(pl, fmt, ...) \
|
2019-11-01 06:42:26 +08:00
|
|
|
do { \
|
|
|
|
|
if ((pl)->config->type == PHYLINK_NETDEV) \
|
|
|
|
|
netdev_dbg((pl)->netdev, fmt, ##__VA_ARGS__); \
|
|
|
|
|
else if ((pl)->config->type == PHYLINK_DEV) \
|
|
|
|
|
dev_dbg((pl)->dev, fmt, ##__VA_ARGS__); \
|
|
|
|
|
} while (0)
|
|
|
|
|
#elif defined(DEBUG)
|
|
|
|
|
#define phylink_dbg(pl, fmt, ...) \
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_printk(KERN_DEBUG, pl, fmt, ##__VA_ARGS__)
|
2019-11-01 06:42:26 +08:00
|
|
|
#else
|
|
|
|
|
#define phylink_dbg(pl, fmt, ...) \
|
|
|
|
|
({ \
|
|
|
|
|
if (0) \
|
|
|
|
|
phylink_printk(KERN_DEBUG, pl, fmt, ##__VA_ARGS__); \
|
|
|
|
|
})
|
|
|
|
|
#endif
|
2019-05-29 01:38:14 +08:00
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_set_port_modes() - set the port type modes in the ethtool mask
|
|
|
|
|
* @mask: ethtool link mode mask
|
|
|
|
|
*
|
|
|
|
|
* Sets all the port type modes in the ethtool mask. MAC drivers should
|
|
|
|
|
* use this in their 'validate' callback.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
void phylink_set_port_modes(unsigned long *mask)
|
|
|
|
|
{
|
|
|
|
|
phylink_set(mask, TP);
|
|
|
|
|
phylink_set(mask, AUI);
|
|
|
|
|
phylink_set(mask, MII);
|
|
|
|
|
phylink_set(mask, FIBRE);
|
|
|
|
|
phylink_set(mask, BNC);
|
|
|
|
|
phylink_set(mask, Backplane);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_set_port_modes);
|
|
|
|
|
|
|
|
|
|
static int phylink_is_empty_linkmode(const unsigned long *linkmode)
|
|
|
|
|
{
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(tmp) = { 0, };
|
|
|
|
|
|
|
|
|
|
phylink_set_port_modes(tmp);
|
|
|
|
|
phylink_set(tmp, Autoneg);
|
|
|
|
|
phylink_set(tmp, Pause);
|
|
|
|
|
phylink_set(tmp, Asym_Pause);
|
|
|
|
|
|
2019-10-15 18:28:46 +08:00
|
|
|
return linkmode_subset(linkmode, tmp);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *phylink_an_mode_str(unsigned int mode)
|
|
|
|
|
{
|
|
|
|
|
static const char *modestr[] = {
|
|
|
|
|
[MLO_AN_PHY] = "phy",
|
|
|
|
|
[MLO_AN_FIXED] = "fixed",
|
2017-12-01 18:24:26 +08:00
|
|
|
[MLO_AN_INBAND] = "inband",
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
return mode < ARRAY_SIZE(modestr) ? modestr[mode] : "unknown";
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-17 18:38:12 +08:00
|
|
|
static unsigned int phylink_interface_signal_rate(phy_interface_t interface)
|
|
|
|
|
{
|
|
|
|
|
switch (interface) {
|
|
|
|
|
case PHY_INTERFACE_MODE_SGMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_1000BASEX: /* 1.25Mbd */
|
|
|
|
|
return 1250;
|
|
|
|
|
case PHY_INTERFACE_MODE_2500BASEX: /* 3.125Mbd */
|
|
|
|
|
return 3125;
|
|
|
|
|
case PHY_INTERFACE_MODE_5GBASER: /* 5.15625Mbd */
|
|
|
|
|
return 5156;
|
|
|
|
|
case PHY_INTERFACE_MODE_10GBASER: /* 10.3125Mbd */
|
|
|
|
|
return 10313;
|
|
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-21 06:12:32 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_interface_max_speed() - get the maximum speed of a phy interface
|
|
|
|
|
* @interface: phy interface mode defined by &typedef phy_interface_t
|
|
|
|
|
*
|
|
|
|
|
* Determine the maximum speed of a phy interface. This is intended to help
|
|
|
|
|
* determine the correct speed to pass to the MAC when the phy is performing
|
|
|
|
|
* rate matching.
|
|
|
|
|
*
|
|
|
|
|
* Return: The maximum speed of @interface
|
|
|
|
|
*/
|
|
|
|
|
static int phylink_interface_max_speed(phy_interface_t interface)
|
|
|
|
|
{
|
|
|
|
|
switch (interface) {
|
|
|
|
|
case PHY_INTERFACE_MODE_100BASEX:
|
|
|
|
|
case PHY_INTERFACE_MODE_REVRMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_RMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_SMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_REVMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_MII:
|
|
|
|
|
return SPEED_100;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_TBI:
|
|
|
|
|
case PHY_INTERFACE_MODE_MOCA:
|
|
|
|
|
case PHY_INTERFACE_MODE_RTBI:
|
|
|
|
|
case PHY_INTERFACE_MODE_1000BASEX:
|
|
|
|
|
case PHY_INTERFACE_MODE_1000BASEKX:
|
|
|
|
|
case PHY_INTERFACE_MODE_TRGMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_TXID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_RXID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_ID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII:
|
2023-08-11 19:10:07 +08:00
|
|
|
case PHY_INTERFACE_MODE_PSGMII:
|
2022-09-21 06:12:32 +08:00
|
|
|
case PHY_INTERFACE_MODE_QSGMII:
|
2023-06-09 16:03:04 +08:00
|
|
|
case PHY_INTERFACE_MODE_QUSGMII:
|
2022-09-21 06:12:32 +08:00
|
|
|
case PHY_INTERFACE_MODE_SGMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_GMII:
|
|
|
|
|
return SPEED_1000;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_2500BASEX:
|
|
|
|
|
return SPEED_2500;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_5GBASER:
|
|
|
|
|
return SPEED_5000;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_XGMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_RXAUI:
|
|
|
|
|
case PHY_INTERFACE_MODE_XAUI:
|
|
|
|
|
case PHY_INTERFACE_MODE_10GBASER:
|
|
|
|
|
case PHY_INTERFACE_MODE_10GKR:
|
|
|
|
|
case PHY_INTERFACE_MODE_USXGMII:
|
|
|
|
|
return SPEED_10000;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_25GBASER:
|
|
|
|
|
return SPEED_25000;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_XLGMII:
|
|
|
|
|
return SPEED_40000;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_INTERNAL:
|
|
|
|
|
case PHY_INTERFACE_MODE_NA:
|
|
|
|
|
case PHY_INTERFACE_MODE_MAX:
|
|
|
|
|
/* No idea! Garbage in, unknown out */
|
|
|
|
|
return SPEED_UNKNOWN;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If we get here, someone forgot to add an interface mode above */
|
|
|
|
|
WARN_ON_ONCE(1);
|
|
|
|
|
return SPEED_UNKNOWN;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-21 06:12:29 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_caps_to_linkmodes() - Convert capabilities to ethtool link modes
|
|
|
|
|
* @linkmodes: ethtool linkmode mask (must be already initialised)
|
|
|
|
|
* @caps: bitmask of MAC capabilities
|
|
|
|
|
*
|
|
|
|
|
* Set all possible pause, speed and duplex linkmodes in @linkmodes that are
|
|
|
|
|
* supported by the @caps. @linkmodes must have been initialised previously.
|
|
|
|
|
*/
|
2023-10-16 23:43:08 +08:00
|
|
|
static void phylink_caps_to_linkmodes(unsigned long *linkmodes,
|
|
|
|
|
unsigned long caps)
|
2021-11-15 18:00:27 +08:00
|
|
|
{
|
|
|
|
|
if (caps & MAC_SYM_PAUSE)
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_Pause_BIT, linkmodes);
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_ASYM_PAUSE)
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, linkmodes);
|
|
|
|
|
|
2023-01-10 00:59:58 +08:00
|
|
|
if (caps & MAC_10HD) {
|
2021-11-15 18:00:27 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10baseT_Half_BIT, linkmodes);
|
2023-01-10 00:59:58 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10baseT1S_Half_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10baseT1S_P2MP_Half_BIT, linkmodes);
|
|
|
|
|
}
|
2021-11-15 18:00:27 +08:00
|
|
|
|
2022-04-29 23:34:31 +08:00
|
|
|
if (caps & MAC_10FD) {
|
2021-11-15 18:00:27 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT, linkmodes);
|
2022-04-29 23:34:31 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10baseT1L_Full_BIT, linkmodes);
|
2023-01-10 00:59:58 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10baseT1S_Full_BIT, linkmodes);
|
2022-04-29 23:34:31 +08:00
|
|
|
}
|
2021-11-15 18:00:27 +08:00
|
|
|
|
|
|
|
|
if (caps & MAC_100HD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100baseFX_Half_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_100FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100baseT1_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100baseFX_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_1000HD)
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT, linkmodes);
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_1000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT, linkmodes);
|
2021-11-19 02:07:06 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_1000baseKX_Full_BIT, linkmodes);
|
2021-11-15 18:00:27 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_1000baseT1_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_2500FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_2500baseX_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_5000FD)
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, linkmodes);
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_10000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseKR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseR_FEC_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseCR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseSR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseLR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseLRM_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_10000baseER_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_25000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_25000baseCR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_25000baseKR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_25000baseSR_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_40000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_40000baseKR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_40000baseCR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_40000baseSR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_40000baseLR4_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_50000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_50000baseKR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_50000baseSR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_50000baseKR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_50000baseSR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_50000baseCR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_50000baseLR_ER_FR_Full_BIT,
|
|
|
|
|
linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_50000baseDR_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_56000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_56000baseKR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_56000baseCR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_56000baseSR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_56000baseLR4_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_100000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseSR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT,
|
|
|
|
|
linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseKR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseSR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseCR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseLR2_ER2_FR2_Full_BIT,
|
|
|
|
|
linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseDR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseKR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseSR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseLR_ER_FR_Full_BIT,
|
|
|
|
|
linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseCR_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_100000baseDR_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_200000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT,
|
|
|
|
|
linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseKR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseSR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseLR2_ER2_FR2_Full_BIT,
|
|
|
|
|
linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseDR2_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_200000baseCR2_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (caps & MAC_400000FD) {
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseKR8_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseSR8_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseLR8_ER8_FR8_Full_BIT,
|
|
|
|
|
linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseDR8_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseCR8_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseKR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseSR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseLR4_ER4_FR4_Full_BIT,
|
|
|
|
|
linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseDR4_Full_BIT, linkmodes);
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_400000baseCR4_Full_BIT, linkmodes);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-21 06:12:33 +08:00
|
|
|
static struct {
|
|
|
|
|
unsigned long mask;
|
|
|
|
|
int speed;
|
|
|
|
|
unsigned int duplex;
|
|
|
|
|
} phylink_caps_params[] = {
|
|
|
|
|
{ MAC_400000FD, SPEED_400000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_200000FD, SPEED_200000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_100000FD, SPEED_100000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_56000FD, SPEED_56000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_50000FD, SPEED_50000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_40000FD, SPEED_40000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_25000FD, SPEED_25000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_20000FD, SPEED_20000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_10000FD, SPEED_10000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_5000FD, SPEED_5000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_2500FD, SPEED_2500, DUPLEX_FULL },
|
|
|
|
|
{ MAC_1000FD, SPEED_1000, DUPLEX_FULL },
|
|
|
|
|
{ MAC_1000HD, SPEED_1000, DUPLEX_HALF },
|
|
|
|
|
{ MAC_100FD, SPEED_100, DUPLEX_FULL },
|
|
|
|
|
{ MAC_100HD, SPEED_100, DUPLEX_HALF },
|
|
|
|
|
{ MAC_10FD, SPEED_10, DUPLEX_FULL },
|
|
|
|
|
{ MAC_10HD, SPEED_10, DUPLEX_HALF },
|
|
|
|
|
};
|
|
|
|
|
|
2023-08-24 21:37:53 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_limit_mac_speed - limit the phylink_config to a maximum speed
|
|
|
|
|
* @config: pointer to a &struct phylink_config
|
|
|
|
|
* @max_speed: maximum speed
|
|
|
|
|
*
|
|
|
|
|
* Mask off MAC capabilities for speeds higher than the @max_speed parameter.
|
|
|
|
|
* Any further motifications of config.mac_capabilities will override this.
|
|
|
|
|
*/
|
|
|
|
|
void phylink_limit_mac_speed(struct phylink_config *config, u32 max_speed)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(phylink_caps_params) &&
|
|
|
|
|
phylink_caps_params[i].speed > max_speed; i++)
|
|
|
|
|
config->mac_capabilities &= ~phylink_caps_params[i].mask;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_limit_mac_speed);
|
|
|
|
|
|
2022-09-21 06:12:33 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_cap_from_speed_duplex - Get mac capability from speed/duplex
|
|
|
|
|
* @speed: the speed to search for
|
|
|
|
|
* @duplex: the duplex to search for
|
|
|
|
|
*
|
|
|
|
|
* Find the mac capability for a given speed and duplex.
|
|
|
|
|
*
|
|
|
|
|
* Return: A mask with the mac capability patching @speed and @duplex, or 0 if
|
|
|
|
|
* there were no matches.
|
|
|
|
|
*/
|
|
|
|
|
static unsigned long phylink_cap_from_speed_duplex(int speed,
|
|
|
|
|
unsigned int duplex)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(phylink_caps_params); i++) {
|
|
|
|
|
if (speed == phylink_caps_params[i].speed &&
|
|
|
|
|
duplex == phylink_caps_params[i].duplex)
|
|
|
|
|
return phylink_caps_params[i].mask;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-15 18:00:27 +08:00
|
|
|
/**
|
2022-09-21 06:12:30 +08:00
|
|
|
* phylink_get_capabilities() - get capabilities for a given MAC
|
2021-11-15 18:00:27 +08:00
|
|
|
* @interface: phy interface mode defined by &typedef phy_interface_t
|
|
|
|
|
* @mac_capabilities: bitmask of MAC capabilities
|
2022-09-21 06:12:33 +08:00
|
|
|
* @rate_matching: type of rate matching being performed
|
2021-11-15 18:00:27 +08:00
|
|
|
*
|
2022-09-21 06:12:30 +08:00
|
|
|
* Get the MAC capabilities that are supported by the @interface mode and
|
|
|
|
|
* @mac_capabilities.
|
2021-11-15 18:00:27 +08:00
|
|
|
*/
|
2023-10-16 23:43:08 +08:00
|
|
|
static unsigned long phylink_get_capabilities(phy_interface_t interface,
|
|
|
|
|
unsigned long mac_capabilities,
|
|
|
|
|
int rate_matching)
|
2021-11-15 18:00:27 +08:00
|
|
|
{
|
2022-09-21 06:12:33 +08:00
|
|
|
int max_speed = phylink_interface_max_speed(interface);
|
2021-11-15 18:00:27 +08:00
|
|
|
unsigned long caps = MAC_SYM_PAUSE | MAC_ASYM_PAUSE;
|
2022-09-21 06:12:33 +08:00
|
|
|
unsigned long matched_caps = 0;
|
2021-11-15 18:00:27 +08:00
|
|
|
|
|
|
|
|
switch (interface) {
|
|
|
|
|
case PHY_INTERFACE_MODE_USXGMII:
|
|
|
|
|
caps |= MAC_10000FD | MAC_5000FD | MAC_2500FD;
|
|
|
|
|
fallthrough;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_TXID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_RXID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_ID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII:
|
2023-08-11 19:10:07 +08:00
|
|
|
case PHY_INTERFACE_MODE_PSGMII:
|
2021-11-15 18:00:27 +08:00
|
|
|
case PHY_INTERFACE_MODE_QSGMII:
|
2022-08-17 20:32:52 +08:00
|
|
|
case PHY_INTERFACE_MODE_QUSGMII:
|
2021-11-15 18:00:27 +08:00
|
|
|
case PHY_INTERFACE_MODE_SGMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_GMII:
|
|
|
|
|
caps |= MAC_1000HD | MAC_1000FD;
|
|
|
|
|
fallthrough;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_REVRMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_RMII:
|
2021-11-16 01:11:17 +08:00
|
|
|
case PHY_INTERFACE_MODE_SMII:
|
2021-11-15 18:00:27 +08:00
|
|
|
case PHY_INTERFACE_MODE_REVMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_MII:
|
|
|
|
|
caps |= MAC_10HD | MAC_10FD;
|
|
|
|
|
fallthrough;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_100BASEX:
|
|
|
|
|
caps |= MAC_100HD | MAC_100FD;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_TBI:
|
|
|
|
|
case PHY_INTERFACE_MODE_MOCA:
|
|
|
|
|
case PHY_INTERFACE_MODE_RTBI:
|
|
|
|
|
case PHY_INTERFACE_MODE_1000BASEX:
|
|
|
|
|
caps |= MAC_1000HD;
|
|
|
|
|
fallthrough;
|
2022-09-03 06:02:39 +08:00
|
|
|
case PHY_INTERFACE_MODE_1000BASEKX:
|
2021-11-15 18:00:27 +08:00
|
|
|
case PHY_INTERFACE_MODE_TRGMII:
|
|
|
|
|
caps |= MAC_1000FD;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_2500BASEX:
|
|
|
|
|
caps |= MAC_2500FD;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_5GBASER:
|
|
|
|
|
caps |= MAC_5000FD;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_XGMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_RXAUI:
|
|
|
|
|
case PHY_INTERFACE_MODE_XAUI:
|
|
|
|
|
case PHY_INTERFACE_MODE_10GBASER:
|
|
|
|
|
case PHY_INTERFACE_MODE_10GKR:
|
|
|
|
|
caps |= MAC_10000FD;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_25GBASER:
|
|
|
|
|
caps |= MAC_25000FD;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_XLGMII:
|
|
|
|
|
caps |= MAC_40000FD;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_INTERNAL:
|
|
|
|
|
caps |= ~0;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_NA:
|
|
|
|
|
case PHY_INTERFACE_MODE_MAX:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-21 06:12:33 +08:00
|
|
|
switch (rate_matching) {
|
|
|
|
|
case RATE_MATCH_OPEN_LOOP:
|
|
|
|
|
/* TODO */
|
|
|
|
|
fallthrough;
|
|
|
|
|
case RATE_MATCH_NONE:
|
|
|
|
|
matched_caps = 0;
|
|
|
|
|
break;
|
|
|
|
|
case RATE_MATCH_PAUSE: {
|
|
|
|
|
/* The MAC must support asymmetric pause towards the local
|
|
|
|
|
* device for this. We could allow just symmetric pause, but
|
|
|
|
|
* then we might have to renegotiate if the link partner
|
|
|
|
|
* doesn't support pause. This is because there's no way to
|
|
|
|
|
* accept pause frames without transmitting them if we only
|
|
|
|
|
* support symmetric pause.
|
|
|
|
|
*/
|
|
|
|
|
if (!(mac_capabilities & MAC_SYM_PAUSE) ||
|
|
|
|
|
!(mac_capabilities & MAC_ASYM_PAUSE))
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
/* We can't adapt if the MAC doesn't support the interface's
|
|
|
|
|
* max speed at full duplex.
|
|
|
|
|
*/
|
|
|
|
|
if (mac_capabilities &
|
|
|
|
|
phylink_cap_from_speed_duplex(max_speed, DUPLEX_FULL)) {
|
|
|
|
|
/* Although a duplex-matching phy might exist, we
|
|
|
|
|
* conservatively remove these modes because the MAC
|
|
|
|
|
* will not be aware of the half-duplex nature of the
|
|
|
|
|
* link.
|
|
|
|
|
*/
|
|
|
|
|
matched_caps = GENMASK(__fls(caps), __fls(MAC_10HD));
|
|
|
|
|
matched_caps &= ~(MAC_1000HD | MAC_100HD | MAC_10HD);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case RATE_MATCH_CRS:
|
|
|
|
|
/* The MAC must support half duplex at the interface's max
|
|
|
|
|
* speed.
|
|
|
|
|
*/
|
|
|
|
|
if (mac_capabilities &
|
|
|
|
|
phylink_cap_from_speed_duplex(max_speed, DUPLEX_HALF)) {
|
|
|
|
|
matched_caps = GENMASK(__fls(caps), __fls(MAC_10HD));
|
|
|
|
|
matched_caps &= mac_capabilities;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return (caps & mac_capabilities) | matched_caps;
|
2021-11-15 18:00:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2022-10-18 04:22:35 +08:00
|
|
|
* phylink_validate_mask_caps() - Restrict link modes based on caps
|
2021-11-15 18:00:27 +08:00
|
|
|
* @supported: ethtool bitmask for supported link modes.
|
2022-10-26 02:51:26 +08:00
|
|
|
* @state: pointer to a &struct phylink_link_state.
|
2022-10-18 04:22:35 +08:00
|
|
|
* @mac_capabilities: bitmask of MAC capabilities
|
2021-11-15 18:00:27 +08:00
|
|
|
*
|
2022-10-18 04:22:35 +08:00
|
|
|
* Calculate the supported link modes based on @mac_capabilities, and restrict
|
|
|
|
|
* @supported and @state based on that. Use this function if your capabiliies
|
|
|
|
|
* aren't constant, such as if they vary depending on the interface.
|
2021-11-15 18:00:27 +08:00
|
|
|
*/
|
2023-10-16 23:43:08 +08:00
|
|
|
static void phylink_validate_mask_caps(unsigned long *supported,
|
|
|
|
|
struct phylink_link_state *state,
|
|
|
|
|
unsigned long mac_capabilities)
|
2021-11-15 18:00:27 +08:00
|
|
|
{
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
|
2022-09-21 06:12:30 +08:00
|
|
|
unsigned long caps;
|
2021-11-15 18:00:27 +08:00
|
|
|
|
|
|
|
|
phylink_set_port_modes(mask);
|
|
|
|
|
phylink_set(mask, Autoneg);
|
2022-10-18 04:22:35 +08:00
|
|
|
caps = phylink_get_capabilities(state->interface, mac_capabilities,
|
2022-09-21 06:12:33 +08:00
|
|
|
state->rate_matching);
|
2022-09-21 06:12:30 +08:00
|
|
|
phylink_caps_to_linkmodes(mask, caps);
|
2021-11-15 18:00:27 +08:00
|
|
|
|
|
|
|
|
linkmode_and(supported, supported, mask);
|
2022-10-26 02:51:26 +08:00
|
|
|
linkmode_and(state->advertising, state->advertising, mask);
|
2022-10-18 04:22:35 +08:00
|
|
|
}
|
2021-11-15 18:00:27 +08:00
|
|
|
|
2021-12-15 23:34:15 +08:00
|
|
|
static int phylink_validate_mac_and_pcs(struct phylink *pl,
|
|
|
|
|
unsigned long *supported,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
2023-10-16 23:42:53 +08:00
|
|
|
unsigned long capabilities;
|
2021-12-15 23:34:15 +08:00
|
|
|
struct phylink_pcs *pcs;
|
2021-12-15 23:34:20 +08:00
|
|
|
int ret;
|
2021-12-15 23:34:15 +08:00
|
|
|
|
2021-12-15 23:34:20 +08:00
|
|
|
/* Get the PCS for this interface mode */
|
2022-02-22 01:10:52 +08:00
|
|
|
if (pl->using_mac_select_pcs) {
|
2021-12-15 23:34:15 +08:00
|
|
|
pcs = pl->mac_ops->mac_select_pcs(pl->config, state->interface);
|
|
|
|
|
if (IS_ERR(pcs))
|
|
|
|
|
return PTR_ERR(pcs);
|
2021-12-15 23:34:20 +08:00
|
|
|
} else {
|
|
|
|
|
pcs = pl->pcs;
|
2021-12-15 23:34:15 +08:00
|
|
|
}
|
|
|
|
|
|
2021-12-15 23:34:20 +08:00
|
|
|
if (pcs) {
|
|
|
|
|
/* The PCS, if present, must be setup before phylink_create()
|
|
|
|
|
* has been called. If the ops is not initialised, print an
|
|
|
|
|
* error and backtrace rather than oopsing the kernel.
|
|
|
|
|
*/
|
|
|
|
|
if (!pcs->ops) {
|
|
|
|
|
phylink_err(pl, "interface %s: uninitialised PCS\n",
|
|
|
|
|
phy_modes(state->interface));
|
|
|
|
|
dump_stack();
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Validate the link parameters with the PCS */
|
|
|
|
|
if (pcs->ops->pcs_validate) {
|
|
|
|
|
ret = pcs->ops->pcs_validate(pcs, supported, state);
|
|
|
|
|
if (ret < 0 || phylink_is_empty_linkmode(supported))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
/* Ensure the advertising mask is a subset of the
|
|
|
|
|
* supported mask.
|
|
|
|
|
*/
|
|
|
|
|
linkmode_and(state->advertising, state->advertising,
|
|
|
|
|
supported);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Then validate the link parameters with the MAC */
|
2023-10-16 23:43:03 +08:00
|
|
|
if (pl->mac_ops->mac_get_caps)
|
|
|
|
|
capabilities = pl->mac_ops->mac_get_caps(pl->config,
|
|
|
|
|
state->interface);
|
|
|
|
|
else
|
|
|
|
|
capabilities = pl->config->mac_capabilities;
|
2023-10-16 23:42:53 +08:00
|
|
|
|
2023-10-16 23:43:03 +08:00
|
|
|
phylink_validate_mask_caps(supported, state, capabilities);
|
2021-12-15 23:34:15 +08:00
|
|
|
|
|
|
|
|
return phylink_is_empty_linkmode(supported) ? -EINVAL : 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-30 22:20:59 +08:00
|
|
|
static int phylink_validate_mask(struct phylink *pl, unsigned long *supported,
|
|
|
|
|
struct phylink_link_state *state,
|
|
|
|
|
const unsigned long *interfaces)
|
2021-10-26 18:06:11 +08:00
|
|
|
{
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(all_adv) = { 0, };
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(all_s) = { 0, };
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(s);
|
|
|
|
|
struct phylink_link_state t;
|
|
|
|
|
int intf;
|
|
|
|
|
|
|
|
|
|
for (intf = 0; intf < PHY_INTERFACE_MODE_MAX; intf++) {
|
2022-09-30 22:20:59 +08:00
|
|
|
if (test_bit(intf, interfaces)) {
|
2021-10-26 18:06:11 +08:00
|
|
|
linkmode_copy(s, supported);
|
|
|
|
|
|
|
|
|
|
t = *state;
|
|
|
|
|
t.interface = intf;
|
2021-12-15 23:34:15 +08:00
|
|
|
if (!phylink_validate_mac_and_pcs(pl, s, &t)) {
|
|
|
|
|
linkmode_or(all_s, all_s, s);
|
|
|
|
|
linkmode_or(all_adv, all_adv, t.advertising);
|
|
|
|
|
}
|
2021-10-26 18:06:11 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
linkmode_copy(supported, all_s);
|
|
|
|
|
linkmode_copy(state->advertising, all_adv);
|
|
|
|
|
|
|
|
|
|
return phylink_is_empty_linkmode(supported) ? -EINVAL : 0;
|
|
|
|
|
}
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
static int phylink_validate(struct phylink *pl, unsigned long *supported,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
2022-09-30 22:20:59 +08:00
|
|
|
const unsigned long *interfaces = pl->config->supported_interfaces;
|
|
|
|
|
|
2023-05-20 18:41:42 +08:00
|
|
|
if (state->interface == PHY_INTERFACE_MODE_NA)
|
|
|
|
|
return phylink_validate_mask(pl, supported, state, interfaces);
|
2021-10-26 18:06:11 +08:00
|
|
|
|
2023-05-20 18:41:42 +08:00
|
|
|
if (!test_bit(state->interface, interfaces))
|
|
|
|
|
return -EINVAL;
|
2021-10-26 18:06:11 +08:00
|
|
|
|
2021-12-15 23:34:15 +08:00
|
|
|
return phylink_validate_mac_and_pcs(pl, supported, state);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
static int phylink_parse_fixedlink(struct phylink *pl,
|
2023-05-13 00:58:37 +08:00
|
|
|
const struct fwnode_handle *fwnode)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
2017-12-01 18:25:09 +08:00
|
|
|
struct fwnode_handle *fixed_node;
|
2023-02-10 23:46:27 +08:00
|
|
|
bool pause, asym_pause, autoneg;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
const struct phy_setting *s;
|
|
|
|
|
struct gpio_desc *desc;
|
|
|
|
|
u32 speed;
|
2017-12-01 18:25:09 +08:00
|
|
|
int ret;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
fixed_node = fwnode_get_named_child_node(fwnode, "fixed-link");
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (fixed_node) {
|
2017-12-01 18:25:09 +08:00
|
|
|
ret = fwnode_property_read_u32(fixed_node, "speed", &speed);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
pl->link_config.speed = speed;
|
|
|
|
|
pl->link_config.duplex = DUPLEX_HALF;
|
|
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
if (fwnode_property_read_bool(fixed_node, "full-duplex"))
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
pl->link_config.duplex = DUPLEX_FULL;
|
|
|
|
|
|
|
|
|
|
/* We treat the "pause" and "asym-pause" terminology as
|
2021-06-16 18:01:20 +08:00
|
|
|
* defining the link partner's ability.
|
|
|
|
|
*/
|
2017-12-01 18:25:09 +08:00
|
|
|
if (fwnode_property_read_bool(fixed_node, "pause"))
|
2020-02-15 23:49:53 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
|
|
|
|
|
pl->link_config.lp_advertising);
|
2017-12-01 18:25:09 +08:00
|
|
|
if (fwnode_property_read_bool(fixed_node, "asym-pause"))
|
2020-02-15 23:49:53 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
|
|
|
|
|
pl->link_config.lp_advertising);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
if (ret == 0) {
|
2020-01-03 09:03:18 +08:00
|
|
|
desc = fwnode_gpiod_get_index(fixed_node, "link", 0,
|
|
|
|
|
GPIOD_IN, "?");
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
if (!IS_ERR(desc))
|
|
|
|
|
pl->link_gpio = desc;
|
|
|
|
|
else if (desc == ERR_PTR(-EPROBE_DEFER))
|
|
|
|
|
ret = -EPROBE_DEFER;
|
|
|
|
|
}
|
2017-12-01 18:25:09 +08:00
|
|
|
fwnode_handle_put(fixed_node);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
} else {
|
2017-12-01 18:25:09 +08:00
|
|
|
u32 prop[5];
|
|
|
|
|
|
|
|
|
|
ret = fwnode_property_read_u32_array(fwnode, "fixed-link",
|
|
|
|
|
NULL, 0);
|
|
|
|
|
if (ret != ARRAY_SIZE(prop)) {
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_err(pl, "broken fixed-link?\n");
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2017-12-01 18:25:09 +08:00
|
|
|
|
|
|
|
|
ret = fwnode_property_read_u32_array(fwnode, "fixed-link",
|
|
|
|
|
prop, ARRAY_SIZE(prop));
|
|
|
|
|
if (!ret) {
|
|
|
|
|
pl->link_config.duplex = prop[1] ?
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
DUPLEX_FULL : DUPLEX_HALF;
|
2017-12-01 18:25:09 +08:00
|
|
|
pl->link_config.speed = prop[2];
|
|
|
|
|
if (prop[3])
|
2020-02-15 23:49:53 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_Pause_BIT,
|
|
|
|
|
pl->link_config.lp_advertising);
|
2017-12-01 18:25:09 +08:00
|
|
|
if (prop[4])
|
2020-02-15 23:49:53 +08:00
|
|
|
__set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
|
|
|
|
|
pl->link_config.lp_advertising);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (pl->link_config.speed > SPEED_1000 &&
|
|
|
|
|
pl->link_config.duplex != DUPLEX_FULL)
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_warn(pl, "fixed link specifies half duplex for %dMbps link?\n",
|
|
|
|
|
pl->link_config.speed);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
bitmap_fill(pl->supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
|
|
|
|
|
linkmode_copy(pl->link_config.advertising, pl->supported);
|
|
|
|
|
phylink_validate(pl, pl->supported, &pl->link_config);
|
|
|
|
|
|
2023-02-10 23:46:27 +08:00
|
|
|
pause = phylink_test(pl->supported, Pause);
|
|
|
|
|
asym_pause = phylink_test(pl->supported, Asym_Pause);
|
|
|
|
|
autoneg = phylink_test(pl->supported, Autoneg);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
s = phy_lookup_setting(pl->link_config.speed, pl->link_config.duplex,
|
2018-11-11 06:43:33 +08:00
|
|
|
pl->supported, true);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
linkmode_zero(pl->supported);
|
|
|
|
|
phylink_set(pl->supported, MII);
|
2023-02-10 23:46:27 +08:00
|
|
|
|
|
|
|
|
if (pause)
|
|
|
|
|
phylink_set(pl->supported, Pause);
|
|
|
|
|
|
|
|
|
|
if (asym_pause)
|
|
|
|
|
phylink_set(pl->supported, Asym_Pause);
|
|
|
|
|
|
|
|
|
|
if (autoneg)
|
|
|
|
|
phylink_set(pl->supported, Autoneg);
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (s) {
|
|
|
|
|
__set_bit(s->bit, pl->supported);
|
2020-07-21 19:03:45 +08:00
|
|
|
__set_bit(s->bit, pl->link_config.lp_advertising);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
} else {
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_warn(pl, "fixed link %s duplex %dMbps not recognised\n",
|
|
|
|
|
pl->link_config.duplex == DUPLEX_FULL ? "full" : "half",
|
|
|
|
|
pl->link_config.speed);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
linkmode_and(pl->link_config.advertising, pl->link_config.advertising,
|
|
|
|
|
pl->supported);
|
|
|
|
|
|
|
|
|
|
pl->link_config.link = 1;
|
|
|
|
|
pl->link_config.an_complete = 1;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-13 00:58:37 +08:00
|
|
|
static int phylink_parse_mode(struct phylink *pl,
|
|
|
|
|
const struct fwnode_handle *fwnode)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
2017-12-01 18:25:09 +08:00
|
|
|
struct fwnode_handle *dn;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
const char *managed;
|
|
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
dn = fwnode_get_named_child_node(fwnode, "fixed-link");
|
|
|
|
|
if (dn || fwnode_property_present(fwnode, "fixed-link"))
|
2019-12-11 18:56:35 +08:00
|
|
|
pl->cfg_link_an_mode = MLO_AN_FIXED;
|
2017-12-01 18:25:09 +08:00
|
|
|
fwnode_handle_put(dn);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2021-03-15 13:27:08 +08:00
|
|
|
if ((fwnode_property_read_string(fwnode, "managed", &managed) == 0 &&
|
|
|
|
|
strcmp(managed, "in-band-status") == 0) ||
|
|
|
|
|
pl->config->ovr_an_inband) {
|
2019-12-11 18:56:35 +08:00
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_FIXED) {
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_err(pl,
|
|
|
|
|
"can't use both fixed-link and in-band-status\n");
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
linkmode_zero(pl->supported);
|
|
|
|
|
phylink_set(pl->supported, MII);
|
|
|
|
|
phylink_set(pl->supported, Autoneg);
|
|
|
|
|
phylink_set(pl->supported, Asym_Pause);
|
|
|
|
|
phylink_set(pl->supported, Pause);
|
2019-12-11 18:56:35 +08:00
|
|
|
pl->cfg_link_an_mode = MLO_AN_INBAND;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
switch (pl->link_config.interface) {
|
|
|
|
|
case PHY_INTERFACE_MODE_SGMII:
|
2023-08-11 19:10:07 +08:00
|
|
|
case PHY_INTERFACE_MODE_PSGMII:
|
2020-01-06 09:34:10 +08:00
|
|
|
case PHY_INTERFACE_MODE_QSGMII:
|
2022-08-17 20:32:52 +08:00
|
|
|
case PHY_INTERFACE_MODE_QUSGMII:
|
2022-08-24 14:10:34 +08:00
|
|
|
case PHY_INTERFACE_MODE_RGMII:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_ID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_RXID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RGMII_TXID:
|
|
|
|
|
case PHY_INTERFACE_MODE_RTBI:
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
phylink_set(pl->supported, 10baseT_Half);
|
|
|
|
|
phylink_set(pl->supported, 10baseT_Full);
|
|
|
|
|
phylink_set(pl->supported, 100baseT_Half);
|
|
|
|
|
phylink_set(pl->supported, 100baseT_Full);
|
|
|
|
|
phylink_set(pl->supported, 1000baseT_Half);
|
|
|
|
|
phylink_set(pl->supported, 1000baseT_Full);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_1000BASEX:
|
|
|
|
|
phylink_set(pl->supported, 1000baseX_Full);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_2500BASEX:
|
|
|
|
|
phylink_set(pl->supported, 2500baseX_Full);
|
|
|
|
|
break;
|
|
|
|
|
|
2021-02-17 03:20:54 +08:00
|
|
|
case PHY_INTERFACE_MODE_5GBASER:
|
|
|
|
|
phylink_set(pl->supported, 5000baseT_Full);
|
|
|
|
|
break;
|
|
|
|
|
|
2021-06-11 20:54:53 +08:00
|
|
|
case PHY_INTERFACE_MODE_25GBASER:
|
|
|
|
|
phylink_set(pl->supported, 25000baseCR_Full);
|
|
|
|
|
phylink_set(pl->supported, 25000baseKR_Full);
|
|
|
|
|
phylink_set(pl->supported, 25000baseSR_Full);
|
|
|
|
|
fallthrough;
|
2020-01-18 20:19:15 +08:00
|
|
|
case PHY_INTERFACE_MODE_USXGMII:
|
2017-07-25 22:03:34 +08:00
|
|
|
case PHY_INTERFACE_MODE_10GKR:
|
2020-01-04 04:43:23 +08:00
|
|
|
case PHY_INTERFACE_MODE_10GBASER:
|
2017-07-25 22:03:34 +08:00
|
|
|
phylink_set(pl->supported, 10baseT_Half);
|
|
|
|
|
phylink_set(pl->supported, 10baseT_Full);
|
|
|
|
|
phylink_set(pl->supported, 100baseT_Half);
|
|
|
|
|
phylink_set(pl->supported, 100baseT_Full);
|
|
|
|
|
phylink_set(pl->supported, 1000baseT_Half);
|
|
|
|
|
phylink_set(pl->supported, 1000baseT_Full);
|
|
|
|
|
phylink_set(pl->supported, 1000baseX_Full);
|
2020-03-09 16:36:24 +08:00
|
|
|
phylink_set(pl->supported, 1000baseKX_Full);
|
2020-01-17 01:36:56 +08:00
|
|
|
phylink_set(pl->supported, 2500baseT_Full);
|
|
|
|
|
phylink_set(pl->supported, 2500baseX_Full);
|
|
|
|
|
phylink_set(pl->supported, 5000baseT_Full);
|
|
|
|
|
phylink_set(pl->supported, 10000baseT_Full);
|
2017-07-25 22:03:34 +08:00
|
|
|
phylink_set(pl->supported, 10000baseKR_Full);
|
2020-03-09 16:36:24 +08:00
|
|
|
phylink_set(pl->supported, 10000baseKX4_Full);
|
2017-07-25 22:03:34 +08:00
|
|
|
phylink_set(pl->supported, 10000baseCR_Full);
|
|
|
|
|
phylink_set(pl->supported, 10000baseSR_Full);
|
|
|
|
|
phylink_set(pl->supported, 10000baseLR_Full);
|
|
|
|
|
phylink_set(pl->supported, 10000baseLRM_Full);
|
|
|
|
|
phylink_set(pl->supported, 10000baseER_Full);
|
|
|
|
|
break;
|
|
|
|
|
|
2020-03-13 01:10:10 +08:00
|
|
|
case PHY_INTERFACE_MODE_XLGMII:
|
|
|
|
|
phylink_set(pl->supported, 25000baseCR_Full);
|
|
|
|
|
phylink_set(pl->supported, 25000baseKR_Full);
|
|
|
|
|
phylink_set(pl->supported, 25000baseSR_Full);
|
|
|
|
|
phylink_set(pl->supported, 40000baseKR4_Full);
|
|
|
|
|
phylink_set(pl->supported, 40000baseCR4_Full);
|
|
|
|
|
phylink_set(pl->supported, 40000baseSR4_Full);
|
|
|
|
|
phylink_set(pl->supported, 40000baseLR4_Full);
|
|
|
|
|
phylink_set(pl->supported, 50000baseCR2_Full);
|
|
|
|
|
phylink_set(pl->supported, 50000baseKR2_Full);
|
|
|
|
|
phylink_set(pl->supported, 50000baseSR2_Full);
|
|
|
|
|
phylink_set(pl->supported, 50000baseKR_Full);
|
|
|
|
|
phylink_set(pl->supported, 50000baseSR_Full);
|
|
|
|
|
phylink_set(pl->supported, 50000baseCR_Full);
|
|
|
|
|
phylink_set(pl->supported, 50000baseLR_ER_FR_Full);
|
|
|
|
|
phylink_set(pl->supported, 50000baseDR_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseKR4_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseSR4_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseCR4_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseLR4_ER4_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseKR2_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseSR2_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseCR2_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseLR2_ER2_FR2_Full);
|
|
|
|
|
phylink_set(pl->supported, 100000baseDR2_Full);
|
|
|
|
|
break;
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
default:
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_err(pl,
|
|
|
|
|
"incorrect link mode %s for in-band status\n",
|
|
|
|
|
phy_modes(pl->link_config.interface));
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
linkmode_copy(pl->link_config.advertising, pl->supported);
|
|
|
|
|
|
|
|
|
|
if (phylink_validate(pl, pl->supported, &pl->link_config)) {
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_err(pl,
|
|
|
|
|
"failed to validate link configuration for in-band status\n");
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-15 23:49:43 +08:00
|
|
|
static void phylink_apply_manual_flow(struct phylink *pl,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
/* If autoneg is disabled, pause AN is also disabled */
|
2023-03-21 23:58:54 +08:00
|
|
|
if (!linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
|
|
|
|
|
state->advertising))
|
2020-02-15 23:49:43 +08:00
|
|
|
state->pause &= ~MLO_PAUSE_AN;
|
|
|
|
|
|
|
|
|
|
/* Manual configuration of pause modes */
|
|
|
|
|
if (!(pl->link_config.pause & MLO_PAUSE_AN))
|
|
|
|
|
state->pause = pl->link_config.pause;
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-23 18:15:53 +08:00
|
|
|
static void phylink_resolve_an_pause(struct phylink_link_state *state)
|
2020-02-15 23:49:53 +08:00
|
|
|
{
|
|
|
|
|
bool tx_pause, rx_pause;
|
|
|
|
|
|
|
|
|
|
if (state->duplex == DUPLEX_FULL) {
|
|
|
|
|
linkmode_resolve_pause(state->advertising,
|
|
|
|
|
state->lp_advertising,
|
|
|
|
|
&tx_pause, &rx_pause);
|
|
|
|
|
if (tx_pause)
|
|
|
|
|
state->pause |= MLO_PAUSE_TX;
|
|
|
|
|
if (rx_pause)
|
|
|
|
|
state->pause |= MLO_PAUSE_RX;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-13 16:42:12 +08:00
|
|
|
static void phylink_pcs_pre_config(struct phylink_pcs *pcs,
|
|
|
|
|
phy_interface_t interface)
|
|
|
|
|
{
|
|
|
|
|
if (pcs && pcs->ops->pcs_pre_config)
|
|
|
|
|
pcs->ops->pcs_pre_config(pcs, interface);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int phylink_pcs_post_config(struct phylink_pcs *pcs,
|
|
|
|
|
phy_interface_t interface)
|
|
|
|
|
{
|
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
|
|
if (pcs && pcs->ops->pcs_post_config)
|
|
|
|
|
err = pcs->ops->pcs_post_config(pcs, interface);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-13 16:42:07 +08:00
|
|
|
static void phylink_pcs_disable(struct phylink_pcs *pcs)
|
|
|
|
|
{
|
|
|
|
|
if (pcs && pcs->ops->pcs_disable)
|
|
|
|
|
pcs->ops->pcs_disable(pcs);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int phylink_pcs_enable(struct phylink_pcs *pcs)
|
|
|
|
|
{
|
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
|
|
if (pcs && pcs->ops->pcs_enable)
|
|
|
|
|
err = pcs->ops->pcs_enable(pcs);
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-16 20:06:22 +08:00
|
|
|
static int phylink_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
|
2023-05-23 23:31:50 +08:00
|
|
|
const struct phylink_link_state *state,
|
|
|
|
|
bool permit_pause_to_mac)
|
|
|
|
|
{
|
|
|
|
|
if (!pcs)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2023-06-16 20:06:22 +08:00
|
|
|
return pcs->ops->pcs_config(pcs, neg_mode, state->interface,
|
2023-05-23 23:31:50 +08:00
|
|
|
state->advertising, permit_pause_to_mac);
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-16 20:06:22 +08:00
|
|
|
static void phylink_pcs_link_up(struct phylink_pcs *pcs, unsigned int neg_mode,
|
2023-05-23 23:31:50 +08:00
|
|
|
phy_interface_t interface, int speed,
|
|
|
|
|
int duplex)
|
|
|
|
|
{
|
|
|
|
|
if (pcs && pcs->ops->pcs_link_up)
|
2023-06-16 20:06:22 +08:00
|
|
|
pcs->ops->pcs_link_up(pcs, neg_mode, interface, speed, duplex);
|
2023-05-23 23:31:50 +08:00
|
|
|
}
|
|
|
|
|
|
2022-06-27 19:44:43 +08:00
|
|
|
static void phylink_pcs_poll_stop(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_INBAND)
|
|
|
|
|
del_timer(&pl->link_poll);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_pcs_poll_start(struct phylink *pl)
|
|
|
|
|
{
|
2022-06-30 03:33:58 +08:00
|
|
|
if (pl->pcs && pl->pcs->poll && pl->cfg_link_an_mode == MLO_AN_INBAND)
|
2022-06-27 19:44:43 +08:00
|
|
|
mod_timer(&pl->link_poll, jiffies + HZ);
|
|
|
|
|
}
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
static void phylink_mac_config(struct phylink *pl,
|
|
|
|
|
const struct phylink_link_state *state)
|
|
|
|
|
{
|
2023-07-23 04:33:05 +08:00
|
|
|
struct phylink_link_state st = *state;
|
|
|
|
|
|
|
|
|
|
/* Stop drivers incorrectly using these */
|
|
|
|
|
linkmode_zero(st.lp_advertising);
|
|
|
|
|
st.speed = SPEED_UNKNOWN;
|
|
|
|
|
st.duplex = DUPLEX_UNKNOWN;
|
|
|
|
|
st.an_complete = false;
|
|
|
|
|
st.link = false;
|
|
|
|
|
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_dbg(pl,
|
2023-07-23 04:33:05 +08:00
|
|
|
"%s: mode=%s/%s/%s adv=%*pb pause=%02x\n",
|
2019-12-11 18:56:35 +08:00
|
|
|
__func__, phylink_an_mode_str(pl->cur_link_an_mode),
|
2023-07-23 04:33:05 +08:00
|
|
|
phy_modes(st.interface),
|
|
|
|
|
phy_rate_matching_to_str(st.rate_matching),
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, st.advertising,
|
|
|
|
|
st.pause);
|
|
|
|
|
|
|
|
|
|
pl->mac_ops->mac_config(pl->config, pl->cur_link_an_mode, &st);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
2023-07-14 17:12:17 +08:00
|
|
|
static void phylink_pcs_an_restart(struct phylink *pl)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
2023-07-14 17:12:17 +08:00
|
|
|
if (pl->pcs && linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
|
|
|
|
|
pl->link_config.advertising) &&
|
2020-06-24 19:30:04 +08:00
|
|
|
phy_interface_mode_is_8023z(pl->link_config.interface) &&
|
2023-07-14 17:12:17 +08:00
|
|
|
phylink_autoneg_inband(pl->cur_link_an_mode))
|
|
|
|
|
pl->pcs->ops->pcs_an_restart(pl->pcs);
|
2020-03-31 01:44:55 +08:00
|
|
|
}
|
|
|
|
|
|
2020-07-21 19:04:41 +08:00
|
|
|
static void phylink_major_config(struct phylink *pl, bool restart,
|
|
|
|
|
const struct phylink_link_state *state)
|
2020-03-31 01:44:55 +08:00
|
|
|
{
|
2021-12-15 23:34:15 +08:00
|
|
|
struct phylink_pcs *pcs = NULL;
|
2022-06-27 19:44:43 +08:00
|
|
|
bool pcs_changed = false;
|
2023-05-17 18:38:12 +08:00
|
|
|
unsigned int rate_kbd;
|
2023-06-16 20:06:22 +08:00
|
|
|
unsigned int neg_mode;
|
2020-07-21 19:04:41 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
phylink_dbg(pl, "major config %s\n", phy_modes(state->interface));
|
2020-03-31 01:44:55 +08:00
|
|
|
|
2023-06-16 20:06:22 +08:00
|
|
|
pl->pcs_neg_mode = phylink_pcs_neg_mode(pl->cur_link_an_mode,
|
|
|
|
|
state->interface,
|
|
|
|
|
state->advertising);
|
|
|
|
|
|
2022-02-22 01:10:52 +08:00
|
|
|
if (pl->using_mac_select_pcs) {
|
2021-12-15 23:34:15 +08:00
|
|
|
pcs = pl->mac_ops->mac_select_pcs(pl->config, state->interface);
|
|
|
|
|
if (IS_ERR(pcs)) {
|
|
|
|
|
phylink_err(pl,
|
|
|
|
|
"mac_select_pcs unexpectedly failed: %pe\n",
|
|
|
|
|
pcs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2022-06-27 19:44:43 +08:00
|
|
|
|
|
|
|
|
pcs_changed = pcs && pl->pcs != pcs;
|
2021-12-15 23:34:15 +08:00
|
|
|
}
|
|
|
|
|
|
2022-06-27 19:44:43 +08:00
|
|
|
phylink_pcs_poll_stop(pl);
|
|
|
|
|
|
2020-07-21 19:04:41 +08:00
|
|
|
if (pl->mac_ops->mac_prepare) {
|
|
|
|
|
err = pl->mac_ops->mac_prepare(pl->config, pl->cur_link_an_mode,
|
|
|
|
|
state->interface);
|
|
|
|
|
if (err < 0) {
|
|
|
|
|
phylink_err(pl, "mac_prepare failed: %pe\n",
|
|
|
|
|
ERR_PTR(err));
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-03-31 01:44:55 +08:00
|
|
|
|
2021-12-15 23:34:15 +08:00
|
|
|
/* If we have a new PCS, switch to the new PCS after preparing the MAC
|
|
|
|
|
* for the change.
|
|
|
|
|
*/
|
2023-07-13 16:42:07 +08:00
|
|
|
if (pcs_changed) {
|
|
|
|
|
phylink_pcs_disable(pl->pcs);
|
|
|
|
|
|
2023-07-13 16:42:17 +08:00
|
|
|
if (pl->pcs)
|
|
|
|
|
pl->pcs->phylink = NULL;
|
|
|
|
|
|
|
|
|
|
pcs->phylink = pl;
|
|
|
|
|
|
2022-02-26 22:56:22 +08:00
|
|
|
pl->pcs = pcs;
|
2023-07-13 16:42:07 +08:00
|
|
|
}
|
2022-02-26 22:56:22 +08:00
|
|
|
|
2023-07-13 16:42:12 +08:00
|
|
|
if (pl->pcs)
|
|
|
|
|
phylink_pcs_pre_config(pl->pcs, state->interface);
|
|
|
|
|
|
2020-03-31 01:44:55 +08:00
|
|
|
phylink_mac_config(pl, state);
|
|
|
|
|
|
2023-07-13 16:42:12 +08:00
|
|
|
if (pl->pcs)
|
|
|
|
|
phylink_pcs_post_config(pl->pcs, state->interface);
|
|
|
|
|
|
2023-07-13 16:42:07 +08:00
|
|
|
if (pl->pcs_state == PCS_STATE_STARTING || pcs_changed)
|
|
|
|
|
phylink_pcs_enable(pl->pcs);
|
|
|
|
|
|
2023-06-16 20:06:22 +08:00
|
|
|
neg_mode = pl->cur_link_an_mode;
|
|
|
|
|
if (pl->pcs && pl->pcs->neg_mode)
|
|
|
|
|
neg_mode = pl->pcs_neg_mode;
|
|
|
|
|
|
|
|
|
|
err = phylink_pcs_config(pl->pcs, neg_mode, state,
|
|
|
|
|
!!(pl->link_config.pause & MLO_PAUSE_AN));
|
2023-05-23 23:31:50 +08:00
|
|
|
if (err < 0)
|
|
|
|
|
phylink_err(pl, "pcs_config failed: %pe\n",
|
|
|
|
|
ERR_PTR(err));
|
|
|
|
|
else if (err > 0)
|
|
|
|
|
restart = true;
|
|
|
|
|
|
2020-03-31 01:44:55 +08:00
|
|
|
if (restart)
|
2023-07-14 17:12:17 +08:00
|
|
|
phylink_pcs_an_restart(pl);
|
2020-07-21 19:04:41 +08:00
|
|
|
|
|
|
|
|
if (pl->mac_ops->mac_finish) {
|
|
|
|
|
err = pl->mac_ops->mac_finish(pl->config, pl->cur_link_an_mode,
|
|
|
|
|
state->interface);
|
|
|
|
|
if (err < 0)
|
2021-03-15 12:33:42 +08:00
|
|
|
phylink_err(pl, "mac_finish failed: %pe\n",
|
2020-07-21 19:04:41 +08:00
|
|
|
ERR_PTR(err));
|
|
|
|
|
}
|
2022-06-27 19:44:43 +08:00
|
|
|
|
2023-05-17 18:38:12 +08:00
|
|
|
if (pl->sfp_bus) {
|
|
|
|
|
rate_kbd = phylink_interface_signal_rate(state->interface);
|
|
|
|
|
if (rate_kbd)
|
|
|
|
|
sfp_upstream_set_signal_rate(pl->sfp_bus, rate_kbd);
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-27 19:44:43 +08:00
|
|
|
phylink_pcs_poll_start(pl);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
2020-07-21 19:04:36 +08:00
|
|
|
/*
|
|
|
|
|
* Reconfigure for a change of inband advertisement.
|
|
|
|
|
* If we have a separate PCS, we only need to call its pcs_config() method,
|
|
|
|
|
* and then restart AN if it indicates something changed. Otherwise, we do
|
|
|
|
|
* the full MAC reconfiguration.
|
|
|
|
|
*/
|
|
|
|
|
static int phylink_change_inband_advert(struct phylink *pl)
|
|
|
|
|
{
|
2023-06-16 20:06:22 +08:00
|
|
|
unsigned int neg_mode;
|
2020-07-21 19:04:36 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
if (test_bit(PHYLINK_DISABLE_STOPPED, &pl->phylink_disable_state))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
phylink_dbg(pl, "%s: mode=%s/%s adv=%*pb pause=%02x\n", __func__,
|
|
|
|
|
phylink_an_mode_str(pl->cur_link_an_mode),
|
|
|
|
|
phy_modes(pl->link_config.interface),
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, pl->link_config.advertising,
|
|
|
|
|
pl->link_config.pause);
|
|
|
|
|
|
2023-06-16 20:06:22 +08:00
|
|
|
/* Recompute the PCS neg mode */
|
|
|
|
|
pl->pcs_neg_mode = phylink_pcs_neg_mode(pl->cur_link_an_mode,
|
|
|
|
|
pl->link_config.interface,
|
|
|
|
|
pl->link_config.advertising);
|
|
|
|
|
|
|
|
|
|
neg_mode = pl->cur_link_an_mode;
|
|
|
|
|
if (pl->pcs->neg_mode)
|
|
|
|
|
neg_mode = pl->pcs_neg_mode;
|
|
|
|
|
|
2020-07-21 19:04:36 +08:00
|
|
|
/* Modern PCS-based method; update the advert at the PCS, and
|
|
|
|
|
* restart negotiation if the pcs_config() helper indicates that
|
|
|
|
|
* the programmed advertisement has changed.
|
|
|
|
|
*/
|
2023-06-16 20:06:22 +08:00
|
|
|
ret = phylink_pcs_config(pl->pcs, neg_mode, &pl->link_config,
|
2023-05-23 23:31:50 +08:00
|
|
|
!!(pl->link_config.pause & MLO_PAUSE_AN));
|
2020-07-21 19:04:36 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
if (ret > 0)
|
2023-07-14 17:12:17 +08:00
|
|
|
phylink_pcs_an_restart(pl);
|
2020-07-21 19:04:36 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-21 08:36:22 +08:00
|
|
|
static void phylink_mac_pcs_get_state(struct phylink *pl,
|
|
|
|
|
struct phylink_link_state *state)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
|
|
|
|
linkmode_copy(state->advertising, pl->link_config.advertising);
|
|
|
|
|
linkmode_zero(state->lp_advertising);
|
|
|
|
|
state->interface = pl->link_config.interface;
|
2022-09-21 06:12:32 +08:00
|
|
|
state->rate_matching = pl->link_config.rate_matching;
|
2023-03-21 23:58:54 +08:00
|
|
|
if (linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
|
|
|
|
|
state->advertising)) {
|
2021-10-19 18:24:50 +08:00
|
|
|
state->speed = SPEED_UNKNOWN;
|
|
|
|
|
state->duplex = DUPLEX_UNKNOWN;
|
|
|
|
|
state->pause = MLO_PAUSE_NONE;
|
|
|
|
|
} else {
|
|
|
|
|
state->speed = pl->link_config.speed;
|
|
|
|
|
state->duplex = pl->link_config.duplex;
|
|
|
|
|
state->pause = pl->link_config.pause;
|
|
|
|
|
}
|
2019-02-27 02:29:22 +08:00
|
|
|
state->an_complete = 0;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
state->link = 1;
|
|
|
|
|
|
2022-06-27 19:44:38 +08:00
|
|
|
if (pl->pcs)
|
|
|
|
|
pl->pcs->ops->pcs_get_state(pl->pcs, state);
|
2020-08-28 18:53:53 +08:00
|
|
|
else
|
|
|
|
|
state->link = 0;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The fixed state is... fixed except for the link state,
|
2017-12-13 08:00:28 +08:00
|
|
|
* which may be determined by a GPIO or a callback.
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
*/
|
2020-02-15 23:49:53 +08:00
|
|
|
static void phylink_get_fixed_state(struct phylink *pl,
|
|
|
|
|
struct phylink_link_state *state)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
|
|
|
|
*state = pl->link_config;
|
2020-04-24 00:02:56 +08:00
|
|
|
if (pl->config->get_fixed_state)
|
|
|
|
|
pl->config->get_fixed_state(pl->config, state);
|
2017-12-13 08:00:28 +08:00
|
|
|
else if (pl->link_gpio)
|
2018-05-11 04:17:29 +08:00
|
|
|
state->link = !!gpiod_get_value_cansleep(pl->link_gpio);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2023-05-23 18:15:53 +08:00
|
|
|
state->pause = MLO_PAUSE_NONE;
|
|
|
|
|
phylink_resolve_an_pause(state);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
2020-03-31 01:44:55 +08:00
|
|
|
static void phylink_mac_initial_config(struct phylink *pl, bool force_restart)
|
2020-02-15 23:50:03 +08:00
|
|
|
{
|
|
|
|
|
struct phylink_link_state link_state;
|
|
|
|
|
|
|
|
|
|
switch (pl->cur_link_an_mode) {
|
|
|
|
|
case MLO_AN_PHY:
|
|
|
|
|
link_state = pl->phy_state;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case MLO_AN_FIXED:
|
|
|
|
|
phylink_get_fixed_state(pl, &link_state);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case MLO_AN_INBAND:
|
|
|
|
|
link_state = pl->link_config;
|
|
|
|
|
if (link_state.interface == PHY_INTERFACE_MODE_SGMII)
|
|
|
|
|
link_state.pause = MLO_PAUSE_NONE;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default: /* can't happen */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
link_state.link = false;
|
|
|
|
|
|
|
|
|
|
phylink_apply_manual_flow(pl, &link_state);
|
2020-07-21 19:04:41 +08:00
|
|
|
phylink_major_config(pl, force_restart, &link_state);
|
2020-02-15 23:50:03 +08:00
|
|
|
}
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
static const char *phylink_pause_to_str(int pause)
|
|
|
|
|
{
|
|
|
|
|
switch (pause & MLO_PAUSE_TXRX_MASK) {
|
|
|
|
|
case MLO_PAUSE_TX | MLO_PAUSE_RX:
|
|
|
|
|
return "rx/tx";
|
|
|
|
|
case MLO_PAUSE_TX:
|
|
|
|
|
return "tx";
|
|
|
|
|
case MLO_PAUSE_RX:
|
|
|
|
|
return "rx";
|
|
|
|
|
default:
|
|
|
|
|
return "off";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-31 01:44:55 +08:00
|
|
|
static void phylink_link_up(struct phylink *pl,
|
|
|
|
|
struct phylink_link_state link_state)
|
2019-05-29 01:38:11 +08:00
|
|
|
{
|
|
|
|
|
struct net_device *ndev = pl->netdev;
|
2023-06-16 20:06:22 +08:00
|
|
|
unsigned int neg_mode;
|
2022-09-21 06:12:32 +08:00
|
|
|
int speed, duplex;
|
|
|
|
|
bool rx_pause;
|
|
|
|
|
|
|
|
|
|
speed = link_state.speed;
|
|
|
|
|
duplex = link_state.duplex;
|
|
|
|
|
rx_pause = !!(link_state.pause & MLO_PAUSE_RX);
|
|
|
|
|
|
|
|
|
|
switch (link_state.rate_matching) {
|
|
|
|
|
case RATE_MATCH_PAUSE:
|
|
|
|
|
/* The PHY is doing rate matchion from the media rate (in
|
|
|
|
|
* the link_state) to the interface speed, and will send
|
|
|
|
|
* pause frames to the MAC to limit its transmission speed.
|
|
|
|
|
*/
|
|
|
|
|
speed = phylink_interface_max_speed(link_state.interface);
|
|
|
|
|
duplex = DUPLEX_FULL;
|
|
|
|
|
rx_pause = true;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case RATE_MATCH_CRS:
|
|
|
|
|
/* The PHY is doing rate matchion from the media rate (in
|
|
|
|
|
* the link_state) to the interface speed, and will cause
|
|
|
|
|
* collisions to the MAC to limit its transmission speed.
|
|
|
|
|
*/
|
|
|
|
|
speed = phylink_interface_max_speed(link_state.interface);
|
|
|
|
|
duplex = DUPLEX_HALF;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-05-29 01:38:11 +08:00
|
|
|
|
2019-06-01 01:49:43 +08:00
|
|
|
pl->cur_interface = link_state.interface;
|
2020-03-31 01:44:55 +08:00
|
|
|
|
2023-06-16 20:06:22 +08:00
|
|
|
neg_mode = pl->cur_link_an_mode;
|
|
|
|
|
if (pl->pcs && pl->pcs->neg_mode)
|
|
|
|
|
neg_mode = pl->pcs_neg_mode;
|
|
|
|
|
|
|
|
|
|
phylink_pcs_link_up(pl->pcs, neg_mode, pl->cur_interface, speed,
|
|
|
|
|
duplex);
|
2020-03-31 01:44:55 +08:00
|
|
|
|
2022-09-21 06:12:32 +08:00
|
|
|
pl->mac_ops->mac_link_up(pl->config, pl->phydev, pl->cur_link_an_mode,
|
|
|
|
|
pl->cur_interface, speed, duplex,
|
|
|
|
|
!!(link_state.pause & MLO_PAUSE_TX), rx_pause);
|
2019-05-29 01:38:11 +08:00
|
|
|
|
2019-05-29 01:38:13 +08:00
|
|
|
if (ndev)
|
|
|
|
|
netif_carrier_on(ndev);
|
2019-05-29 01:38:11 +08:00
|
|
|
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_info(pl,
|
|
|
|
|
"Link is Up - %s/%s - flow control %s\n",
|
|
|
|
|
phy_speed_to_str(link_state.speed),
|
|
|
|
|
phy_duplex_to_str(link_state.duplex),
|
|
|
|
|
phylink_pause_to_str(link_state.pause));
|
2019-05-29 01:38:11 +08:00
|
|
|
}
|
|
|
|
|
|
2020-03-31 01:44:55 +08:00
|
|
|
static void phylink_link_down(struct phylink *pl)
|
2019-05-29 01:38:11 +08:00
|
|
|
{
|
|
|
|
|
struct net_device *ndev = pl->netdev;
|
|
|
|
|
|
2019-05-29 01:38:13 +08:00
|
|
|
if (ndev)
|
|
|
|
|
netif_carrier_off(ndev);
|
2020-03-31 01:44:50 +08:00
|
|
|
pl->mac_ops->mac_link_down(pl->config, pl->cur_link_an_mode,
|
|
|
|
|
pl->cur_interface);
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_info(pl, "Link is Down\n");
|
2019-05-29 01:38:11 +08:00
|
|
|
}
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
static void phylink_resolve(struct work_struct *w)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = container_of(w, struct phylink, resolve);
|
|
|
|
|
struct phylink_link_state link_state;
|
|
|
|
|
struct net_device *ndev = pl->netdev;
|
2020-07-21 19:03:55 +08:00
|
|
|
bool mac_config = false;
|
2021-11-23 23:44:02 +08:00
|
|
|
bool retrigger = false;
|
2020-07-21 19:03:50 +08:00
|
|
|
bool cur_link_state;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
mutex_lock(&pl->state_mutex);
|
2020-07-21 19:03:50 +08:00
|
|
|
if (pl->netdev)
|
|
|
|
|
cur_link_state = netif_carrier_ok(ndev);
|
|
|
|
|
else
|
|
|
|
|
cur_link_state = pl->old_link_state;
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (pl->phylink_disable_state) {
|
|
|
|
|
pl->mac_link_dropped = false;
|
|
|
|
|
link_state.link = false;
|
|
|
|
|
} else if (pl->mac_link_dropped) {
|
|
|
|
|
link_state.link = false;
|
2021-11-23 23:44:02 +08:00
|
|
|
retrigger = true;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
} else {
|
2019-12-11 18:56:35 +08:00
|
|
|
switch (pl->cur_link_an_mode) {
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
case MLO_AN_PHY:
|
|
|
|
|
link_state = pl->phy_state;
|
2020-02-15 23:49:43 +08:00
|
|
|
phylink_apply_manual_flow(pl, &link_state);
|
2020-07-21 19:03:55 +08:00
|
|
|
mac_config = link_state.link;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case MLO_AN_FIXED:
|
|
|
|
|
phylink_get_fixed_state(pl, &link_state);
|
2020-07-21 19:03:55 +08:00
|
|
|
mac_config = link_state.link;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
break;
|
|
|
|
|
|
2017-12-01 18:24:26 +08:00
|
|
|
case MLO_AN_INBAND:
|
2019-11-21 08:36:22 +08:00
|
|
|
phylink_mac_pcs_get_state(pl, &link_state);
|
2019-05-20 23:07:20 +08:00
|
|
|
|
2021-11-23 23:44:03 +08:00
|
|
|
/* The PCS may have a latching link-fail indicator.
|
|
|
|
|
* If the link was up, bring the link down and
|
|
|
|
|
* re-trigger the resolve. Otherwise, re-read the
|
|
|
|
|
* PCS state to get the current status of the link.
|
|
|
|
|
*/
|
|
|
|
|
if (!link_state.link) {
|
|
|
|
|
if (cur_link_state)
|
|
|
|
|
retrigger = true;
|
|
|
|
|
else
|
|
|
|
|
phylink_mac_pcs_get_state(pl,
|
|
|
|
|
&link_state);
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-20 23:07:20 +08:00
|
|
|
/* If we have a phy, the "up" state is the union of
|
2021-06-16 18:01:20 +08:00
|
|
|
* both the PHY and the MAC
|
|
|
|
|
*/
|
2019-05-20 23:07:20 +08:00
|
|
|
if (pl->phydev)
|
|
|
|
|
link_state.link &= pl->phy_state.link;
|
|
|
|
|
|
|
|
|
|
/* Only update if the PHY link is up */
|
|
|
|
|
if (pl->phydev && pl->phy_state.link) {
|
2021-11-23 23:44:02 +08:00
|
|
|
/* If the interface has changed, force a
|
|
|
|
|
* link down event if the link isn't already
|
|
|
|
|
* down, and re-resolve.
|
|
|
|
|
*/
|
|
|
|
|
if (link_state.interface !=
|
|
|
|
|
pl->phy_state.interface) {
|
|
|
|
|
retrigger = true;
|
|
|
|
|
link_state.link = false;
|
|
|
|
|
}
|
2019-05-20 23:07:20 +08:00
|
|
|
link_state.interface = pl->phy_state.interface;
|
|
|
|
|
|
2022-09-21 06:12:32 +08:00
|
|
|
/* If we are doing rate matching, then the
|
|
|
|
|
* link speed/duplex comes from the PHY
|
|
|
|
|
*/
|
|
|
|
|
if (pl->phy_state.rate_matching) {
|
|
|
|
|
link_state.rate_matching =
|
|
|
|
|
pl->phy_state.rate_matching;
|
|
|
|
|
link_state.speed = pl->phy_state.speed;
|
|
|
|
|
link_state.duplex =
|
|
|
|
|
pl->phy_state.duplex;
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-20 23:07:20 +08:00
|
|
|
/* If we have a PHY, we need to update with
|
2021-06-16 18:01:20 +08:00
|
|
|
* the PHY flow control bits.
|
|
|
|
|
*/
|
2020-02-15 23:49:48 +08:00
|
|
|
link_state.pause = pl->phy_state.pause;
|
2020-07-21 19:03:55 +08:00
|
|
|
mac_config = true;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
2020-07-21 19:03:55 +08:00
|
|
|
phylink_apply_manual_flow(pl, &link_state);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-21 19:04:00 +08:00
|
|
|
if (mac_config) {
|
|
|
|
|
if (link_state.interface != pl->link_config.interface) {
|
|
|
|
|
/* The interface has changed, force the link down and
|
|
|
|
|
* then reconfigure.
|
|
|
|
|
*/
|
|
|
|
|
if (cur_link_state) {
|
|
|
|
|
phylink_link_down(pl);
|
|
|
|
|
cur_link_state = false;
|
|
|
|
|
}
|
2020-07-21 19:04:41 +08:00
|
|
|
phylink_major_config(pl, false, &link_state);
|
2020-07-21 19:04:05 +08:00
|
|
|
pl->link_config.interface = link_state.interface;
|
2020-07-21 19:04:00 +08:00
|
|
|
}
|
|
|
|
|
}
|
2020-07-21 19:03:55 +08:00
|
|
|
|
2020-07-21 19:03:50 +08:00
|
|
|
if (link_state.link != cur_link_state) {
|
2019-05-29 01:38:13 +08:00
|
|
|
pl->old_link_state = link_state.link;
|
2019-05-29 01:38:11 +08:00
|
|
|
if (!link_state.link)
|
2020-03-31 01:44:55 +08:00
|
|
|
phylink_link_down(pl);
|
2019-05-29 01:38:11 +08:00
|
|
|
else
|
2020-03-31 01:44:55 +08:00
|
|
|
phylink_link_up(pl, link_state);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
2021-11-23 23:44:02 +08:00
|
|
|
if (!link_state.link && retrigger) {
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
pl->mac_link_dropped = false;
|
|
|
|
|
queue_work(system_power_efficient_wq, &pl->resolve);
|
|
|
|
|
}
|
|
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_run_resolve(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
if (!pl->phylink_disable_state)
|
|
|
|
|
queue_work(system_power_efficient_wq, &pl->resolve);
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-11 23:04:24 +08:00
|
|
|
static void phylink_run_resolve_and_disable(struct phylink *pl, int bit)
|
|
|
|
|
{
|
|
|
|
|
unsigned long state = pl->phylink_disable_state;
|
|
|
|
|
|
|
|
|
|
set_bit(bit, &pl->phylink_disable_state);
|
|
|
|
|
if (state == 0) {
|
|
|
|
|
queue_work(system_power_efficient_wq, &pl->resolve);
|
|
|
|
|
flush_work(&pl->resolve);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-30 22:49:41 +08:00
|
|
|
static void phylink_enable_and_run_resolve(struct phylink *pl, int bit)
|
|
|
|
|
{
|
|
|
|
|
clear_bit(bit, &pl->phylink_disable_state);
|
|
|
|
|
phylink_run_resolve(pl);
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-11 04:17:31 +08:00
|
|
|
static void phylink_fixed_poll(struct timer_list *t)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = container_of(t, struct phylink, link_poll);
|
|
|
|
|
|
|
|
|
|
mod_timer(t, jiffies + HZ);
|
|
|
|
|
|
|
|
|
|
phylink_run_resolve(pl);
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-25 22:03:18 +08:00
|
|
|
static const struct sfp_upstream_ops sfp_phylink_ops;
|
|
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
static int phylink_register_sfp(struct phylink *pl,
|
2023-05-13 00:58:37 +08:00
|
|
|
const struct fwnode_handle *fwnode)
|
2017-07-25 22:03:18 +08:00
|
|
|
{
|
2019-10-15 18:38:39 +08:00
|
|
|
struct sfp_bus *bus;
|
2017-12-01 18:25:09 +08:00
|
|
|
int ret;
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2020-01-03 23:13:56 +08:00
|
|
|
if (!fwnode)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2019-11-09 01:39:29 +08:00
|
|
|
bus = sfp_bus_find_fwnode(fwnode);
|
2019-10-15 18:38:39 +08:00
|
|
|
if (IS_ERR(bus)) {
|
2022-03-01 16:51:34 +08:00
|
|
|
phylink_err(pl, "unable to attach SFP bus: %pe\n", bus);
|
|
|
|
|
return PTR_ERR(bus);
|
2017-12-01 18:25:09 +08:00
|
|
|
}
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2019-10-15 18:38:39 +08:00
|
|
|
pl->sfp_bus = bus;
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2019-11-09 01:39:29 +08:00
|
|
|
ret = sfp_bus_add_upstream(bus, pl, &sfp_phylink_ops);
|
|
|
|
|
sfp_bus_put(bus);
|
|
|
|
|
|
|
|
|
|
return ret;
|
2017-07-25 22:03:18 +08:00
|
|
|
}
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_create() - create a phylink instance
|
2019-10-08 23:39:04 +08:00
|
|
|
* @config: a pointer to the target &struct phylink_config
|
2017-12-01 18:25:09 +08:00
|
|
|
* @fwnode: a pointer to a &struct fwnode_handle describing the network
|
|
|
|
|
* interface
|
2017-12-01 18:24:47 +08:00
|
|
|
* @iface: the desired link mode defined by &typedef phy_interface_t
|
2020-03-31 01:44:50 +08:00
|
|
|
* @mac_ops: a pointer to a &struct phylink_mac_ops for the MAC.
|
2017-12-01 18:24:47 +08:00
|
|
|
*
|
|
|
|
|
* Create a new phylink instance, and parse the link parameters found in @np.
|
|
|
|
|
* This will parse in-band modes, fixed-link or SFP configuration.
|
|
|
|
|
*
|
2019-11-20 01:18:52 +08:00
|
|
|
* Note: the rtnl lock must not be held when calling this function.
|
|
|
|
|
*
|
2017-12-01 18:24:47 +08:00
|
|
|
* Returns a pointer to a &struct phylink, or an error-pointer value. Users
|
|
|
|
|
* must use IS_ERR() to check for errors from this function.
|
|
|
|
|
*/
|
2019-05-29 01:38:12 +08:00
|
|
|
struct phylink *phylink_create(struct phylink_config *config,
|
2023-05-13 00:58:37 +08:00
|
|
|
const struct fwnode_handle *fwnode,
|
2017-10-31 12:42:57 +08:00
|
|
|
phy_interface_t iface,
|
2020-03-31 01:44:50 +08:00
|
|
|
const struct phylink_mac_ops *mac_ops)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
2022-02-22 01:10:52 +08:00
|
|
|
bool using_mac_select_pcs = false;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
struct phylink *pl;
|
|
|
|
|
int ret;
|
|
|
|
|
|
2022-02-22 01:10:52 +08:00
|
|
|
/* Validate the supplied configuration */
|
2023-05-20 18:41:42 +08:00
|
|
|
if (phy_interface_empty(config->supported_interfaces)) {
|
2021-12-15 23:34:15 +08:00
|
|
|
dev_err(config->dev,
|
2023-05-20 18:41:42 +08:00
|
|
|
"phylink: error: empty supported_interfaces\n");
|
2021-12-15 23:34:15 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-20 18:41:42 +08:00
|
|
|
if (mac_ops->mac_select_pcs &&
|
|
|
|
|
mac_ops->mac_select_pcs(config, PHY_INTERFACE_MODE_NA) !=
|
|
|
|
|
ERR_PTR(-EOPNOTSUPP))
|
|
|
|
|
using_mac_select_pcs = true;
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
pl = kzalloc(sizeof(*pl), GFP_KERNEL);
|
|
|
|
|
if (!pl)
|
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
|
|
mutex_init(&pl->state_mutex);
|
|
|
|
|
INIT_WORK(&pl->resolve, phylink_resolve);
|
2019-05-29 01:38:12 +08:00
|
|
|
|
|
|
|
|
pl->config = config;
|
|
|
|
|
if (config->type == PHYLINK_NETDEV) {
|
|
|
|
|
pl->netdev = to_net_dev(config->dev);
|
net: phylink: initialize carrier state at creation
Background: Turris Omnia (Armada 385); eth2 (mvneta) connected to SFP bus;
SFP module is present, but no fiber connected, so definitely no carrier.
After booting, eth2 is down, but netdev LED trigger surprisingly reports
link active. Then, after "ip link set eth2 up", the link indicator goes
away - as I would have expected it from the beginning.
It turns out, that the default carrier state after netdev creation is
"carrier ok". Some ethernet drivers explicitly call netif_carrier_off
during probing, others (like mvneta) don't - which explains the current
behaviour: only when the device is brought up, phylink_start calls
netif_carrier_off.
Fix this for all drivers using phylink, by calling netif_carrier_off in
phylink_create.
Fixes: 089381b27abe ("leds: initial support for Turris Omnia LEDs")
Cc: stable@vger.kernel.org
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2023-11-08 01:44:02 +08:00
|
|
|
netif_carrier_off(pl->netdev);
|
2019-05-29 01:38:13 +08:00
|
|
|
} else if (config->type == PHYLINK_DEV) {
|
|
|
|
|
pl->dev = config->dev;
|
2019-05-29 01:38:12 +08:00
|
|
|
} else {
|
|
|
|
|
kfree(pl);
|
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-22 01:10:52 +08:00
|
|
|
pl->using_mac_select_pcs = using_mac_select_pcs;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
pl->phy_state.interface = iface;
|
|
|
|
|
pl->link_interface = iface;
|
2017-12-13 08:00:29 +08:00
|
|
|
if (iface == PHY_INTERFACE_MODE_MOCA)
|
|
|
|
|
pl->link_port = PORT_BNC;
|
|
|
|
|
else
|
|
|
|
|
pl->link_port = PORT_MII;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
pl->link_config.interface = iface;
|
|
|
|
|
pl->link_config.pause = MLO_PAUSE_AN;
|
|
|
|
|
pl->link_config.speed = SPEED_UNKNOWN;
|
|
|
|
|
pl->link_config.duplex = DUPLEX_UNKNOWN;
|
2023-07-13 16:42:07 +08:00
|
|
|
pl->pcs_state = PCS_STATE_DOWN;
|
2020-03-31 01:44:50 +08:00
|
|
|
pl->mac_ops = mac_ops;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
__set_bit(PHYLINK_DISABLE_STOPPED, &pl->phylink_disable_state);
|
2018-05-11 04:17:31 +08:00
|
|
|
timer_setup(&pl->link_poll, phylink_fixed_poll, 0);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
bitmap_fill(pl->supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
|
|
|
|
|
linkmode_copy(pl->link_config.advertising, pl->supported);
|
|
|
|
|
phylink_validate(pl, pl->supported, &pl->link_config);
|
|
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
ret = phylink_parse_mode(pl, fwnode);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
|
kfree(pl);
|
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:35 +08:00
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_FIXED) {
|
2017-12-01 18:25:09 +08:00
|
|
|
ret = phylink_parse_fixedlink(pl, fwnode);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
|
kfree(pl);
|
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:35 +08:00
|
|
|
pl->cur_link_an_mode = pl->cfg_link_an_mode;
|
|
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
ret = phylink_register_sfp(pl, fwnode);
|
2017-07-25 22:03:18 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
|
kfree(pl);
|
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
}
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
return pl;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_create);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_destroy() - cleanup and destroy the phylink instance
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
*
|
|
|
|
|
* Destroy a phylink instance. Any PHY that has been attached must have been
|
|
|
|
|
* cleaned up via phylink_disconnect_phy() prior to calling this function.
|
2019-11-20 01:18:52 +08:00
|
|
|
*
|
|
|
|
|
* Note: the rtnl lock must not be held when calling this function.
|
2017-12-01 18:24:47 +08:00
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
void phylink_destroy(struct phylink *pl)
|
|
|
|
|
{
|
2019-11-09 01:39:29 +08:00
|
|
|
sfp_bus_del_upstream(pl->sfp_bus);
|
2019-05-28 17:57:23 +08:00
|
|
|
if (pl->link_gpio)
|
2018-05-11 04:17:30 +08:00
|
|
|
gpiod_put(pl->link_gpio);
|
2017-07-25 22:03:18 +08:00
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
cancel_work_sync(&pl->resolve);
|
|
|
|
|
kfree(pl);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_destroy);
|
|
|
|
|
|
2023-03-30 17:14:02 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_expects_phy() - Determine if phylink expects a phy to be attached
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
*
|
|
|
|
|
* When using fixed-link mode, or in-band mode with 1000base-X or 2500base-X,
|
|
|
|
|
* no PHY is needed.
|
|
|
|
|
*
|
|
|
|
|
* Returns true if phylink will be expecting a PHY.
|
|
|
|
|
*/
|
|
|
|
|
bool phylink_expects_phy(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_FIXED ||
|
|
|
|
|
(pl->cfg_link_an_mode == MLO_AN_INBAND &&
|
|
|
|
|
phy_interface_mode_is_8023z(pl->link_config.interface)))
|
|
|
|
|
return false;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_expects_phy);
|
|
|
|
|
|
2020-05-19 06:23:59 +08:00
|
|
|
static void phylink_phy_change(struct phy_device *phydev, bool up)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
|
|
|
|
struct phylink *pl = phydev->phylink;
|
2020-02-15 23:49:48 +08:00
|
|
|
bool tx_pause, rx_pause;
|
|
|
|
|
|
|
|
|
|
phy_get_pause(phydev, &tx_pause, &rx_pause);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
|
pl->phy_state.speed = phydev->speed;
|
|
|
|
|
pl->phy_state.duplex = phydev->duplex;
|
2022-09-21 06:12:32 +08:00
|
|
|
pl->phy_state.rate_matching = phydev->rate_matching;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
pl->phy_state.pause = MLO_PAUSE_NONE;
|
2020-02-15 23:49:48 +08:00
|
|
|
if (tx_pause)
|
|
|
|
|
pl->phy_state.pause |= MLO_PAUSE_TX;
|
|
|
|
|
if (rx_pause)
|
|
|
|
|
pl->phy_state.pause |= MLO_PAUSE_RX;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
pl->phy_state.interface = phydev->interface;
|
|
|
|
|
pl->phy_state.link = up;
|
|
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
|
|
|
|
|
|
phylink_run_resolve(pl);
|
|
|
|
|
|
2022-09-21 06:12:32 +08:00
|
|
|
phylink_dbg(pl, "phy link %s %s/%s/%s/%s/%s\n", up ? "up" : "down",
|
2019-05-29 01:38:14 +08:00
|
|
|
phy_modes(phydev->interface),
|
|
|
|
|
phy_speed_to_str(phydev->speed),
|
2021-07-20 19:15:20 +08:00
|
|
|
phy_duplex_to_str(phydev->duplex),
|
2022-09-21 06:12:32 +08:00
|
|
|
phy_rate_matching_to_str(phydev->rate_matching),
|
2021-07-20 19:15:20 +08:00
|
|
|
phylink_pause_to_str(pl->phy_state.pause));
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:30 +08:00
|
|
|
static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy,
|
|
|
|
|
phy_interface_t interface)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
|
|
|
|
struct phylink_link_state config;
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(supported);
|
2020-01-13 01:35:38 +08:00
|
|
|
char *irq_str;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This is the new way of dealing with flow control for PHYs,
|
|
|
|
|
* as described by Timur Tabi in commit 529ed1275263 ("net: phy:
|
|
|
|
|
* phy drivers should not set SUPPORTED_[Asym_]Pause") except
|
|
|
|
|
* using our validate call to the MAC, we rely upon the MAC
|
|
|
|
|
* clearing the bits from both supported and advertising fields.
|
|
|
|
|
*/
|
2019-11-16 04:05:45 +08:00
|
|
|
phy_support_asym_pause(phy);
|
|
|
|
|
|
|
|
|
|
memset(&config, 0, sizeof(config));
|
|
|
|
|
linkmode_copy(supported, phy->supported);
|
|
|
|
|
linkmode_copy(config.advertising, phy->advertising);
|
net: phylink: extend clause 45 PHY validation workaround
Commit e45d1f5288b8 ("net: phylink: support Clause 45 PHYs on SFP+
modules") added a workaround to support clause 45 PHYs which
dynamically switch their interface mode on SFP+ modules. This was
implemented by validating the PHYs supported/advertising using
PHY_INTERFACE_MODE_NA, rather than the specific interface mode that
we attached the PHY with.
However, we already have a situation where phylink is used to connect
a Marvell 88X3310 PHY which also behaves in exactly the same way, but
which seemingly doesn't need this. The reason seems to be that the
mvpp2 driver sets a whole bunch of link modes for
PHY_INTERFACE_MODE_10GKR down to 10Mb/s, despite 10GBASE-R not actually
supporting anything but 10Gb/s speeds.
When testing with drivers that (correctly) take the mvneta approach,
where the validate() method only returns what can be supported /
advertised for the specified link mode, we find that Clause 45 PHYs do
not behave as we expect: their advertisement is restricted to what
the current link will support, rather than what the PHY supports
through its dynamic switching.
Extend this workaround to all such cases; if we have a Clause 45 PHY
attaching via any means, except in USXGMII, XAUI and RXAUI which are
all unable to support this dynamic switching or have other solutions
to it, then we need to validate using PHY_INTERFACE_MODE_NA.
This should allow mvpp2 to switch to a more conformant validate()
implementation.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-14 02:22:07 +08:00
|
|
|
|
2022-11-24 17:06:48 +08:00
|
|
|
/* Check whether we would use rate matching for the proposed interface
|
|
|
|
|
* mode.
|
net: phylink: extend clause 45 PHY validation workaround
Commit e45d1f5288b8 ("net: phylink: support Clause 45 PHYs on SFP+
modules") added a workaround to support clause 45 PHYs which
dynamically switch their interface mode on SFP+ modules. This was
implemented by validating the PHYs supported/advertising using
PHY_INTERFACE_MODE_NA, rather than the specific interface mode that
we attached the PHY with.
However, we already have a situation where phylink is used to connect
a Marvell 88X3310 PHY which also behaves in exactly the same way, but
which seemingly doesn't need this. The reason seems to be that the
mvpp2 driver sets a whole bunch of link modes for
PHY_INTERFACE_MODE_10GKR down to 10Mb/s, despite 10GBASE-R not actually
supporting anything but 10Gb/s speeds.
When testing with drivers that (correctly) take the mvneta approach,
where the validate() method only returns what can be supported /
advertised for the specified link mode, we find that Clause 45 PHYs do
not behave as we expect: their advertisement is restricted to what
the current link will support, rather than what the PHY supports
through its dynamic switching.
Extend this workaround to all such cases; if we have a Clause 45 PHY
attaching via any means, except in USXGMII, XAUI and RXAUI which are
all unable to support this dynamic switching or have other solutions
to it, then we need to validate using PHY_INTERFACE_MODE_NA.
This should allow mvpp2 to switch to a more conformant validate()
implementation.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-14 02:22:07 +08:00
|
|
|
*/
|
2022-11-24 17:06:48 +08:00
|
|
|
config.rate_matching = phy_get_rate_matching(phy, interface);
|
|
|
|
|
|
|
|
|
|
/* Clause 45 PHYs may switch their Serdes lane between, e.g. 10GBASE-R,
|
|
|
|
|
* 5GBASE-R, 2500BASE-X and SGMII if they are not using rate matching.
|
|
|
|
|
* For some interface modes (e.g. RXAUI, XAUI and USXGMII) switching
|
|
|
|
|
* their Serdes is either unnecessary or not reasonable.
|
|
|
|
|
*
|
|
|
|
|
* For these which switch interface modes, we really need to know which
|
|
|
|
|
* interface modes the PHY supports to properly work out which ethtool
|
|
|
|
|
* linkmodes can be supported. For now, as a work-around, we validate
|
|
|
|
|
* against all interface modes, which may lead to more ethtool link
|
|
|
|
|
* modes being advertised than are actually supported.
|
|
|
|
|
*/
|
|
|
|
|
if (phy->is_c45 && config.rate_matching == RATE_MATCH_NONE &&
|
net: phylink: extend clause 45 PHY validation workaround
Commit e45d1f5288b8 ("net: phylink: support Clause 45 PHYs on SFP+
modules") added a workaround to support clause 45 PHYs which
dynamically switch their interface mode on SFP+ modules. This was
implemented by validating the PHYs supported/advertising using
PHY_INTERFACE_MODE_NA, rather than the specific interface mode that
we attached the PHY with.
However, we already have a situation where phylink is used to connect
a Marvell 88X3310 PHY which also behaves in exactly the same way, but
which seemingly doesn't need this. The reason seems to be that the
mvpp2 driver sets a whole bunch of link modes for
PHY_INTERFACE_MODE_10GKR down to 10Mb/s, despite 10GBASE-R not actually
supporting anything but 10Gb/s speeds.
When testing with drivers that (correctly) take the mvneta approach,
where the validate() method only returns what can be supported /
advertised for the specified link mode, we find that Clause 45 PHYs do
not behave as we expect: their advertisement is restricted to what
the current link will support, rather than what the PHY supports
through its dynamic switching.
Extend this workaround to all such cases; if we have a Clause 45 PHY
attaching via any means, except in USXGMII, XAUI and RXAUI which are
all unable to support this dynamic switching or have other solutions
to it, then we need to validate using PHY_INTERFACE_MODE_NA.
This should allow mvpp2 to switch to a more conformant validate()
implementation.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-14 02:22:07 +08:00
|
|
|
interface != PHY_INTERFACE_MODE_RXAUI &&
|
|
|
|
|
interface != PHY_INTERFACE_MODE_XAUI &&
|
|
|
|
|
interface != PHY_INTERFACE_MODE_USXGMII)
|
|
|
|
|
config.interface = PHY_INTERFACE_MODE_NA;
|
|
|
|
|
else
|
|
|
|
|
config.interface = interface;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
ret = phylink_validate(pl, supported, &config);
|
2020-03-02 07:55:02 +08:00
|
|
|
if (ret) {
|
2022-03-01 16:51:34 +08:00
|
|
|
phylink_warn(pl, "validation of %s with support %*pb and advertisement %*pb failed: %pe\n",
|
2020-03-02 07:55:02 +08:00
|
|
|
phy_modes(config.interface),
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, phy->supported,
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, config.advertising,
|
2022-03-01 16:51:34 +08:00
|
|
|
ERR_PTR(ret));
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
return ret;
|
2020-03-02 07:55:02 +08:00
|
|
|
}
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
phy->phylink = pl;
|
|
|
|
|
phy->phy_link_change = phylink_phy_change;
|
|
|
|
|
|
2020-01-13 01:35:38 +08:00
|
|
|
irq_str = phy_attached_info_irq(phy);
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_info(pl,
|
2020-01-13 01:35:38 +08:00
|
|
|
"PHY [%s] driver [%s] (irq=%s)\n",
|
|
|
|
|
dev_name(&phy->mdio.dev), phy->drv->name, irq_str);
|
|
|
|
|
kfree(irq_str);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
mutex_lock(&phy->lock);
|
|
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
|
pl->phydev = phy;
|
2019-12-11 18:56:30 +08:00
|
|
|
pl->phy_state.interface = interface;
|
2020-02-15 23:50:03 +08:00
|
|
|
pl->phy_state.pause = MLO_PAUSE_NONE;
|
|
|
|
|
pl->phy_state.speed = SPEED_UNKNOWN;
|
|
|
|
|
pl->phy_state.duplex = DUPLEX_UNKNOWN;
|
2022-09-21 06:12:32 +08:00
|
|
|
pl->phy_state.rate_matching = RATE_MATCH_NONE;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
linkmode_copy(pl->supported, supported);
|
|
|
|
|
linkmode_copy(pl->link_config.advertising, config.advertising);
|
|
|
|
|
|
2018-03-01 18:23:03 +08:00
|
|
|
/* Restrict the phy advertisement according to the MAC support. */
|
2018-11-11 06:43:33 +08:00
|
|
|
linkmode_copy(phy->advertising, config.advertising);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
|
mutex_unlock(&phy->lock);
|
|
|
|
|
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_dbg(pl,
|
2021-11-20 00:28:06 +08:00
|
|
|
"phy: %s setting supported %*pb advertising %*pb\n",
|
|
|
|
|
phy_modes(interface),
|
2019-05-29 01:38:14 +08:00
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, pl->supported,
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, phy->advertising);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2019-01-23 14:31:58 +08:00
|
|
|
if (phy_interrupt_is_valid(phy))
|
|
|
|
|
phy_request_interrupt(phy);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2022-10-14 22:47:28 +08:00
|
|
|
if (pl->config->mac_managed_pm)
|
|
|
|
|
phy->mac_managed_pm = true;
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:25 +08:00
|
|
|
static int phylink_attach_phy(struct phylink *pl, struct phy_device *phy,
|
|
|
|
|
phy_interface_t interface)
|
2018-10-04 00:04:49 +08:00
|
|
|
{
|
2019-12-11 18:56:35 +08:00
|
|
|
if (WARN_ON(pl->cfg_link_an_mode == MLO_AN_FIXED ||
|
|
|
|
|
(pl->cfg_link_an_mode == MLO_AN_INBAND &&
|
2022-09-30 22:21:06 +08:00
|
|
|
phy_interface_mode_is_8023z(interface) && !pl->sfp_bus)))
|
2018-10-04 00:04:49 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
2019-12-11 18:56:25 +08:00
|
|
|
return phy_attach_direct(pl->netdev, phy, 0, interface);
|
2018-10-04 00:04:49 +08:00
|
|
|
}
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_connect_phy() - connect a PHY to the phylink instance
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @phy: a pointer to a &struct phy_device.
|
|
|
|
|
*
|
|
|
|
|
* Connect @phy to the phylink instance specified by @pl by calling
|
|
|
|
|
* phy_attach_direct(). Configure the @phy according to the MAC driver's
|
|
|
|
|
* capabilities, start the PHYLIB state machine and enable any interrupts
|
|
|
|
|
* that the PHY supports.
|
|
|
|
|
*
|
|
|
|
|
* This updates the phylink's ethtool supported and advertising link mode
|
|
|
|
|
* masks.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 on success or a negative errno.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_connect_phy(struct phylink *pl, struct phy_device *phy)
|
|
|
|
|
{
|
2019-12-11 18:56:25 +08:00
|
|
|
int ret;
|
|
|
|
|
|
2017-12-13 08:00:26 +08:00
|
|
|
/* Use PHY device/driver interface */
|
|
|
|
|
if (pl->link_interface == PHY_INTERFACE_MODE_NA) {
|
|
|
|
|
pl->link_interface = phy->interface;
|
|
|
|
|
pl->link_config.interface = pl->link_interface;
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:25 +08:00
|
|
|
ret = phylink_attach_phy(pl, phy, pl->link_interface);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
2019-12-11 18:56:30 +08:00
|
|
|
ret = phylink_bringup_phy(pl, phy, pl->link_config.interface);
|
2019-12-11 18:56:25 +08:00
|
|
|
if (ret)
|
|
|
|
|
phy_detach(phy);
|
|
|
|
|
|
|
|
|
|
return ret;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_connect_phy);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_of_phy_connect() - connect the PHY specified in the DT mode.
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @dn: a pointer to a &struct device_node.
|
2017-12-13 08:00:25 +08:00
|
|
|
* @flags: PHY-specific flags to communicate to the PHY device driver
|
2017-12-01 18:24:47 +08:00
|
|
|
*
|
|
|
|
|
* Connect the phy specified in the device node @dn to the phylink instance
|
|
|
|
|
* specified by @pl. Actions specified in phylink_connect_phy() will be
|
|
|
|
|
* performed.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 on success or a negative errno.
|
|
|
|
|
*/
|
2017-12-13 08:00:25 +08:00
|
|
|
int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn,
|
|
|
|
|
u32 flags)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
2021-06-11 18:54:00 +08:00
|
|
|
return phylink_fwnode_phy_connect(pl, of_fwnode_handle(dn), flags);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_of_phy_connect);
|
|
|
|
|
|
2021-06-11 18:53:59 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_fwnode_phy_connect() - connect the PHY specified in the fwnode.
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @fwnode: a pointer to a &struct fwnode_handle.
|
|
|
|
|
* @flags: PHY-specific flags to communicate to the PHY device driver
|
|
|
|
|
*
|
|
|
|
|
* Connect the phy specified @fwnode to the phylink instance specified
|
|
|
|
|
* by @pl.
|
|
|
|
|
*
|
|
|
|
|
* Returns 0 on success or a negative errno.
|
|
|
|
|
*/
|
|
|
|
|
int phylink_fwnode_phy_connect(struct phylink *pl,
|
2023-05-13 00:58:37 +08:00
|
|
|
const struct fwnode_handle *fwnode,
|
2021-06-11 18:53:59 +08:00
|
|
|
u32 flags)
|
|
|
|
|
{
|
|
|
|
|
struct fwnode_handle *phy_fwnode;
|
|
|
|
|
struct phy_device *phy_dev;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
/* Fixed links and 802.3z are handled without needing a PHY */
|
|
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_FIXED ||
|
|
|
|
|
(pl->cfg_link_an_mode == MLO_AN_INBAND &&
|
|
|
|
|
phy_interface_mode_is_8023z(pl->link_interface)))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
phy_fwnode = fwnode_get_phy_node(fwnode);
|
|
|
|
|
if (IS_ERR(phy_fwnode)) {
|
|
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_PHY)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
phy_dev = fwnode_phy_find_device(phy_fwnode);
|
|
|
|
|
/* We're done with the phy_node handle */
|
|
|
|
|
fwnode_handle_put(phy_fwnode);
|
|
|
|
|
if (!phy_dev)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
2021-11-20 00:28:06 +08:00
|
|
|
/* Use PHY device/driver interface */
|
|
|
|
|
if (pl->link_interface == PHY_INTERFACE_MODE_NA) {
|
|
|
|
|
pl->link_interface = phy_dev->interface;
|
|
|
|
|
pl->link_config.interface = pl->link_interface;
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-11 18:53:59 +08:00
|
|
|
ret = phy_attach_direct(pl->netdev, phy_dev, flags,
|
|
|
|
|
pl->link_interface);
|
2023-01-31 18:02:42 +08:00
|
|
|
phy_device_free(phy_dev);
|
|
|
|
|
if (ret)
|
2021-06-11 18:53:59 +08:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
ret = phylink_bringup_phy(pl, phy_dev, pl->link_config.interface);
|
|
|
|
|
if (ret)
|
|
|
|
|
phy_detach(phy_dev);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_fwnode_phy_connect);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_disconnect_phy() - disconnect any PHY attached to the phylink
|
|
|
|
|
* instance.
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
*
|
|
|
|
|
* Disconnect any current PHY from the phylink instance described by @pl.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
void phylink_disconnect_phy(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
struct phy_device *phy;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
phy = pl->phydev;
|
|
|
|
|
if (phy) {
|
|
|
|
|
mutex_lock(&phy->lock);
|
|
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
|
pl->phydev = NULL;
|
|
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
|
mutex_unlock(&phy->lock);
|
|
|
|
|
flush_work(&pl->resolve);
|
|
|
|
|
|
|
|
|
|
phy_disconnect(phy);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_disconnect_phy);
|
|
|
|
|
|
2023-07-13 16:42:17 +08:00
|
|
|
static void phylink_link_changed(struct phylink *pl, bool up, const char *what)
|
|
|
|
|
{
|
|
|
|
|
if (!up)
|
|
|
|
|
pl->mac_link_dropped = true;
|
|
|
|
|
phylink_run_resolve(pl);
|
|
|
|
|
phylink_dbg(pl, "%s link %s\n", what, up ? "up" : "down");
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_mac_change() - notify phylink of a change in MAC state
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @up: indicates whether the link is currently up.
|
|
|
|
|
*
|
|
|
|
|
* The MAC driver should call this driver when the state of its link
|
|
|
|
|
* changes (eg, link failure, new negotiation results, etc.)
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
void phylink_mac_change(struct phylink *pl, bool up)
|
|
|
|
|
{
|
2023-07-13 16:42:17 +08:00
|
|
|
phylink_link_changed(pl, up, "mac");
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_mac_change);
|
|
|
|
|
|
2023-07-13 16:42:17 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_pcs_change() - notify phylink of a change to PCS link state
|
|
|
|
|
* @pcs: pointer to &struct phylink_pcs
|
|
|
|
|
* @up: indicates whether the link is currently up.
|
|
|
|
|
*
|
|
|
|
|
* The PCS driver should call this when the state of its link changes
|
|
|
|
|
* (e.g. link failure, new negotiation results, etc.) Note: it should
|
|
|
|
|
* not determine "up" by reading the BMSR. If in doubt about the link
|
|
|
|
|
* state at interrupt time, then pass true if pcs_get_state() returns
|
|
|
|
|
* the latched link-down state, otherwise pass false.
|
|
|
|
|
*/
|
|
|
|
|
void phylink_pcs_change(struct phylink_pcs *pcs, bool up)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = pcs->phylink;
|
|
|
|
|
|
|
|
|
|
if (pl)
|
|
|
|
|
phylink_link_changed(pl, up, "pcs");
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_pcs_change);
|
|
|
|
|
|
2019-05-28 17:57:23 +08:00
|
|
|
static irqreturn_t phylink_link_handler(int irq, void *data)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = data;
|
|
|
|
|
|
|
|
|
|
phylink_run_resolve(pl);
|
|
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_start() - start a phylink instance
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
*
|
|
|
|
|
* Start the phylink instance specified by @pl, configuring the MAC for the
|
|
|
|
|
* desired link mode(s) and negotiation style. This should be called from the
|
|
|
|
|
* network device driver's &struct net_device_ops ndo_open() method.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
void phylink_start(struct phylink *pl)
|
|
|
|
|
{
|
2020-04-24 00:02:56 +08:00
|
|
|
bool poll = false;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_info(pl, "configuring for %s/%s link mode\n",
|
2019-12-11 18:56:35 +08:00
|
|
|
phylink_an_mode_str(pl->cur_link_an_mode),
|
2019-05-29 01:38:14 +08:00
|
|
|
phy_modes(pl->link_config.interface));
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2018-09-19 17:39:31 +08:00
|
|
|
/* Always set the carrier off */
|
2019-05-29 01:38:13 +08:00
|
|
|
if (pl->netdev)
|
|
|
|
|
netif_carrier_off(pl->netdev);
|
2018-09-19 17:39:31 +08:00
|
|
|
|
2023-07-13 16:42:07 +08:00
|
|
|
pl->pcs_state = PCS_STATE_STARTING;
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
/* Apply the link configuration to the MAC when starting. This allows
|
|
|
|
|
* a fixed-link to start with the correct parameters, and also
|
2018-03-01 18:23:03 +08:00
|
|
|
* ensures that we set the appropriate advertisement for Serdes links.
|
2020-03-31 01:44:55 +08:00
|
|
|
*
|
|
|
|
|
* Restart autonegotiation if using 802.3z to ensure that the link
|
2017-12-01 18:24:42 +08:00
|
|
|
* parameters are properly negotiated. This is necessary for DSA
|
|
|
|
|
* switches using 802.3z negotiation to ensure they see our modes.
|
|
|
|
|
*/
|
2020-03-31 01:44:55 +08:00
|
|
|
phylink_mac_initial_config(pl, true);
|
2017-12-01 18:24:42 +08:00
|
|
|
|
2023-07-13 16:42:07 +08:00
|
|
|
pl->pcs_state = PCS_STATE_STARTED;
|
|
|
|
|
|
2021-11-30 22:49:41 +08:00
|
|
|
phylink_enable_and_run_resolve(pl, PHYLINK_DISABLE_STOPPED);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2019-12-11 18:56:35 +08:00
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_FIXED && pl->link_gpio) {
|
2019-05-28 17:57:23 +08:00
|
|
|
int irq = gpiod_to_irq(pl->link_gpio);
|
|
|
|
|
|
|
|
|
|
if (irq > 0) {
|
|
|
|
|
if (!request_irq(irq, phylink_link_handler,
|
|
|
|
|
IRQF_TRIGGER_RISING |
|
|
|
|
|
IRQF_TRIGGER_FALLING,
|
|
|
|
|
"netdev link", pl))
|
|
|
|
|
pl->link_irq = irq;
|
|
|
|
|
else
|
|
|
|
|
irq = 0;
|
|
|
|
|
}
|
|
|
|
|
if (irq <= 0)
|
2020-04-24 00:02:56 +08:00
|
|
|
poll = true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-13 16:42:07 +08:00
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_FIXED)
|
2020-04-24 00:02:56 +08:00
|
|
|
poll |= pl->config->poll_fixed_state;
|
2023-07-13 16:42:07 +08:00
|
|
|
|
2020-04-24 00:02:56 +08:00
|
|
|
if (poll)
|
2018-05-11 04:17:31 +08:00
|
|
|
mod_timer(&pl->link_poll, jiffies + HZ);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (pl->phydev)
|
|
|
|
|
phy_start(pl->phydev);
|
net: phylink: don't start and stop SGMII PHYs in SFP modules twice
SFP modules connected using the SGMII interface have their own PHYs which
are handled by the struct phylink's phydev field. On the other hand, for
the modules connected using 1000Base-X interface that field is not set.
Since commit ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network
devices and sfp cages") phylink_start() ends up setting the phydev field
using the sfp-bus infrastructure, which eventually calls phy_start() on it,
and then calling phy_start() again on the same phydev from phylink_start()
itself. Similar call sequence holds for phylink_stop(), only in the reverse
order. This results in WARNs during network interface bringup and shutdown
when a copper SFP module is connected, as phy_start() and phy_stop() are
called twice in a row for the same phy_device:
% ip link set up dev eth0
------------[ cut here ]------------
called from state UP
WARNING: CPU: 1 PID: 155 at drivers/net/phy/phy.c:895 phy_start+0x74/0xc0
Modules linked in:
CPU: 1 PID: 155 Comm: backend Not tainted 5.2.0+ #1
NIP: c0227bf0 LR: c0227bf0 CTR: c004d224
REGS: df547720 TRAP: 0700 Not tainted (5.2.0+)
MSR: 00029000 <CE,EE,ME> CR: 24002822 XER: 00000000
GPR00: c0227bf0 df5477d8 df5d7080 00000014 df9d2370 df9d5ac4 1f4eb000 00000001
GPR08: c061fe58 00000000 00000000 df5477d8 0000003c 100c8768 00000000 00000000
GPR16: df486a00 c046f1c8 c046eea0 00000000 c046e904 c0239604 db68449c 00000000
GPR24: e9083204 00000000 00000001 db684460 e9083404 00000000 db6dce00 db6dcc00
NIP [c0227bf0] phy_start+0x74/0xc0
LR [c0227bf0] phy_start+0x74/0xc0
Call Trace:
[df5477d8] [c0227bf0] phy_start+0x74/0xc0 (unreliable)
[df5477e8] [c023cad0] startup_gfar+0x398/0x3f4
[df547828] [c023cf08] gfar_enet_open+0x364/0x374
[df547898] [c029d870] __dev_open+0xe4/0x140
[df5478c8] [c029db70] __dev_change_flags+0xf0/0x188
[df5478f8] [c029dc28] dev_change_flags+0x20/0x54
[df547918] [c02ae304] do_setlink+0x310/0x818
[df547a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0
[df547c28] [c02b222c] rtnl_newlink+0x48/0x68
[df547c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c
[df547c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0
[df547cd8] [c02cba3c] netlink_unicast+0x114/0x19c
[df547d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0
[df547d58] [c027b668] sock_sendmsg_nosec+0x20/0x40
[df547d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc
[df547e98] [c027df7c] __sys_sendmsg+0x68/0x84
[df547ef8] [c027e430] sys_socketcall+0x1a0/0x204
[df547f38] [c000d1d8] ret_from_syscall+0x0/0x38
--- interrupt: c01 at 0xfd4e030
LR = 0xfd4e010
Instruction dump:
813f0188 38800000 2b890005 419d0014 3d40c046 5529103a 394aa208 7c8a482e
3c60c046 3863a1b8 4cc63182 4be009a1 <0fe00000> 48000030 3c60c046 3863a1d0
---[ end trace d4c095aeaf6ea998 ]---
and
% ip link set down dev eth0
------------[ cut here ]------------
called from state HALTED
WARNING: CPU: 1 PID: 184 at drivers/net/phy/phy.c:858 phy_stop+0x3c/0x88
<...>
Call Trace:
[df581788] [c0228450] phy_stop+0x3c/0x88 (unreliable)
[df581798] [c022d548] sfp_sm_phy_detach+0x1c/0x44
[df5817a8] [c022e8cc] sfp_sm_event+0x4b0/0x87c
[df581848] [c022f04c] sfp_upstream_stop+0x34/0x44
[df581858] [c0225608] phylink_stop+0x7c/0xe4
[df581868] [c023c57c] stop_gfar+0x7c/0x94
[df581888] [c023c5b8] gfar_close+0x24/0x94
[df5818a8] [c0298688] __dev_close_many+0xdc/0xf8
[df5818c8] [c029db58] __dev_change_flags+0xd8/0x188
[df5818f8] [c029dc28] dev_change_flags+0x20/0x54
[df581918] [c02ae304] do_setlink+0x310/0x818
[df581a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0
[df581c28] [c02b222c] rtnl_newlink+0x48/0x68
[df581c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c
[df581c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0
[df581cd8] [c02cba3c] netlink_unicast+0x114/0x19c
[df581d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0
[df581d58] [c027b668] sock_sendmsg_nosec+0x20/0x40
[df581d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc
[df581e98] [c027df7c] __sys_sendmsg+0x68/0x84
[df581ef8] [c027e430] sys_socketcall+0x1a0/0x204
[df581f38] [c000d1d8] ret_from_syscall+0x0/0x38
<...>
---[ end trace d4c095aeaf6ea999 ]---
SFP modules with the 1000Base-X interface are not affected.
Place explicit calls to phy_start() and phy_stop() before enabling or after
disabling an attached SFP module, where phydev is not yet set (or is
already unset), so they will be made only from the inside of sfp-bus, if
needed.
Fixes: 217962615662 ("net: phy: warn if phy_start is called from invalid state")
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-24 21:31:39 +08:00
|
|
|
if (pl->sfp_bus)
|
|
|
|
|
sfp_upstream_start(pl->sfp_bus);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_start);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_stop() - stop a phylink instance
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
*
|
|
|
|
|
* Stop the phylink instance specified by @pl. This should be called from the
|
|
|
|
|
* network device driver's &struct net_device_ops ndo_stop() method. The
|
|
|
|
|
* network device's carrier state should not be changed prior to calling this
|
|
|
|
|
* function.
|
2021-09-07 18:56:46 +08:00
|
|
|
*
|
|
|
|
|
* This will synchronously bring down the link if the link is not already
|
|
|
|
|
* down (in other words, it will trigger a mac_link_down() method call.)
|
2017-12-01 18:24:47 +08:00
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
void phylink_stop(struct phylink *pl)
|
|
|
|
|
{
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-07-25 22:03:18 +08:00
|
|
|
if (pl->sfp_bus)
|
|
|
|
|
sfp_upstream_stop(pl->sfp_bus);
|
net: phylink: don't start and stop SGMII PHYs in SFP modules twice
SFP modules connected using the SGMII interface have their own PHYs which
are handled by the struct phylink's phydev field. On the other hand, for
the modules connected using 1000Base-X interface that field is not set.
Since commit ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network
devices and sfp cages") phylink_start() ends up setting the phydev field
using the sfp-bus infrastructure, which eventually calls phy_start() on it,
and then calling phy_start() again on the same phydev from phylink_start()
itself. Similar call sequence holds for phylink_stop(), only in the reverse
order. This results in WARNs during network interface bringup and shutdown
when a copper SFP module is connected, as phy_start() and phy_stop() are
called twice in a row for the same phy_device:
% ip link set up dev eth0
------------[ cut here ]------------
called from state UP
WARNING: CPU: 1 PID: 155 at drivers/net/phy/phy.c:895 phy_start+0x74/0xc0
Modules linked in:
CPU: 1 PID: 155 Comm: backend Not tainted 5.2.0+ #1
NIP: c0227bf0 LR: c0227bf0 CTR: c004d224
REGS: df547720 TRAP: 0700 Not tainted (5.2.0+)
MSR: 00029000 <CE,EE,ME> CR: 24002822 XER: 00000000
GPR00: c0227bf0 df5477d8 df5d7080 00000014 df9d2370 df9d5ac4 1f4eb000 00000001
GPR08: c061fe58 00000000 00000000 df5477d8 0000003c 100c8768 00000000 00000000
GPR16: df486a00 c046f1c8 c046eea0 00000000 c046e904 c0239604 db68449c 00000000
GPR24: e9083204 00000000 00000001 db684460 e9083404 00000000 db6dce00 db6dcc00
NIP [c0227bf0] phy_start+0x74/0xc0
LR [c0227bf0] phy_start+0x74/0xc0
Call Trace:
[df5477d8] [c0227bf0] phy_start+0x74/0xc0 (unreliable)
[df5477e8] [c023cad0] startup_gfar+0x398/0x3f4
[df547828] [c023cf08] gfar_enet_open+0x364/0x374
[df547898] [c029d870] __dev_open+0xe4/0x140
[df5478c8] [c029db70] __dev_change_flags+0xf0/0x188
[df5478f8] [c029dc28] dev_change_flags+0x20/0x54
[df547918] [c02ae304] do_setlink+0x310/0x818
[df547a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0
[df547c28] [c02b222c] rtnl_newlink+0x48/0x68
[df547c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c
[df547c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0
[df547cd8] [c02cba3c] netlink_unicast+0x114/0x19c
[df547d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0
[df547d58] [c027b668] sock_sendmsg_nosec+0x20/0x40
[df547d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc
[df547e98] [c027df7c] __sys_sendmsg+0x68/0x84
[df547ef8] [c027e430] sys_socketcall+0x1a0/0x204
[df547f38] [c000d1d8] ret_from_syscall+0x0/0x38
--- interrupt: c01 at 0xfd4e030
LR = 0xfd4e010
Instruction dump:
813f0188 38800000 2b890005 419d0014 3d40c046 5529103a 394aa208 7c8a482e
3c60c046 3863a1b8 4cc63182 4be009a1 <0fe00000> 48000030 3c60c046 3863a1d0
---[ end trace d4c095aeaf6ea998 ]---
and
% ip link set down dev eth0
------------[ cut here ]------------
called from state HALTED
WARNING: CPU: 1 PID: 184 at drivers/net/phy/phy.c:858 phy_stop+0x3c/0x88
<...>
Call Trace:
[df581788] [c0228450] phy_stop+0x3c/0x88 (unreliable)
[df581798] [c022d548] sfp_sm_phy_detach+0x1c/0x44
[df5817a8] [c022e8cc] sfp_sm_event+0x4b0/0x87c
[df581848] [c022f04c] sfp_upstream_stop+0x34/0x44
[df581858] [c0225608] phylink_stop+0x7c/0xe4
[df581868] [c023c57c] stop_gfar+0x7c/0x94
[df581888] [c023c5b8] gfar_close+0x24/0x94
[df5818a8] [c0298688] __dev_close_many+0xdc/0xf8
[df5818c8] [c029db58] __dev_change_flags+0xd8/0x188
[df5818f8] [c029dc28] dev_change_flags+0x20/0x54
[df581918] [c02ae304] do_setlink+0x310/0x818
[df581a08] [c02b1eb8] __rtnl_newlink+0x384/0x6b0
[df581c28] [c02b222c] rtnl_newlink+0x48/0x68
[df581c48] [c02ad7c8] rtnetlink_rcv_msg+0x240/0x27c
[df581c98] [c02cc068] netlink_rcv_skb+0x8c/0xf0
[df581cd8] [c02cba3c] netlink_unicast+0x114/0x19c
[df581d08] [c02cbd74] netlink_sendmsg+0x2b0/0x2c0
[df581d58] [c027b668] sock_sendmsg_nosec+0x20/0x40
[df581d68] [c027d080] ___sys_sendmsg+0x17c/0x1dc
[df581e98] [c027df7c] __sys_sendmsg+0x68/0x84
[df581ef8] [c027e430] sys_socketcall+0x1a0/0x204
[df581f38] [c000d1d8] ret_from_syscall+0x0/0x38
<...>
---[ end trace d4c095aeaf6ea999 ]---
SFP modules with the 1000Base-X interface are not affected.
Place explicit calls to phy_start() and phy_stop() before enabling or after
disabling an attached SFP module, where phydev is not yet set (or is
already unset), so they will be made only from the inside of sfp-bus, if
needed.
Fixes: 217962615662 ("net: phy: warn if phy_start is called from invalid state")
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-24 21:31:39 +08:00
|
|
|
if (pl->phydev)
|
|
|
|
|
phy_stop(pl->phydev);
|
2019-05-28 17:57:23 +08:00
|
|
|
del_timer_sync(&pl->link_poll);
|
|
|
|
|
if (pl->link_irq) {
|
|
|
|
|
free_irq(pl->link_irq, pl);
|
|
|
|
|
pl->link_irq = 0;
|
|
|
|
|
}
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2019-02-11 23:04:24 +08:00
|
|
|
phylink_run_resolve_and_disable(pl, PHYLINK_DISABLE_STOPPED);
|
2023-07-13 16:42:07 +08:00
|
|
|
|
|
|
|
|
pl->pcs_state = PCS_STATE_DOWN;
|
|
|
|
|
|
|
|
|
|
phylink_pcs_disable(pl->pcs);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_stop);
|
|
|
|
|
|
2021-09-07 18:56:46 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_suspend() - handle a network device suspend event
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @mac_wol: true if the MAC needs to receive packets for Wake-on-Lan
|
|
|
|
|
*
|
|
|
|
|
* Handle a network device suspend event. There are several cases:
|
2021-12-06 16:12:28 +08:00
|
|
|
*
|
2021-09-07 18:56:46 +08:00
|
|
|
* - If Wake-on-Lan is not active, we can bring down the link between
|
|
|
|
|
* the MAC and PHY by calling phylink_stop().
|
|
|
|
|
* - If Wake-on-Lan is active, and being handled only by the PHY, we
|
|
|
|
|
* can also bring down the link between the MAC and PHY.
|
|
|
|
|
* - If Wake-on-Lan is active, but being handled by the MAC, the MAC
|
|
|
|
|
* still needs to receive packets, so we can not bring the link down.
|
|
|
|
|
*/
|
|
|
|
|
void phylink_suspend(struct phylink *pl, bool mac_wol)
|
|
|
|
|
{
|
|
|
|
|
ASSERT_RTNL();
|
|
|
|
|
|
|
|
|
|
if (mac_wol && (!pl->netdev || pl->netdev->wol_enabled)) {
|
|
|
|
|
/* Wake-on-Lan enabled, MAC handling */
|
|
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
|
|
|
|
|
|
/* Stop the resolver bringing the link up */
|
|
|
|
|
__set_bit(PHYLINK_DISABLE_MAC_WOL, &pl->phylink_disable_state);
|
|
|
|
|
|
|
|
|
|
/* Disable the carrier, to prevent transmit timeouts,
|
|
|
|
|
* but one would hope all packets have been sent. This
|
|
|
|
|
* also means phylink_resolve() will do nothing.
|
|
|
|
|
*/
|
2021-09-17 21:36:31 +08:00
|
|
|
if (pl->netdev)
|
|
|
|
|
netif_carrier_off(pl->netdev);
|
|
|
|
|
else
|
|
|
|
|
pl->old_link_state = false;
|
2021-09-07 18:56:46 +08:00
|
|
|
|
|
|
|
|
/* We do not call mac_link_down() here as we want the
|
|
|
|
|
* link to remain up to receive the WoL packets.
|
|
|
|
|
*/
|
|
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
|
} else {
|
|
|
|
|
phylink_stop(pl);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_suspend);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* phylink_resume() - handle a network device resume event
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
*
|
|
|
|
|
* Undo the effects of phylink_suspend(), returning the link to an
|
|
|
|
|
* operational state.
|
|
|
|
|
*/
|
|
|
|
|
void phylink_resume(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
ASSERT_RTNL();
|
|
|
|
|
|
|
|
|
|
if (test_bit(PHYLINK_DISABLE_MAC_WOL, &pl->phylink_disable_state)) {
|
|
|
|
|
/* Wake-on-Lan enabled, MAC handling */
|
|
|
|
|
|
|
|
|
|
/* Call mac_link_down() so we keep the overall state balanced.
|
|
|
|
|
* Do this under the state_mutex lock for consistency. This
|
|
|
|
|
* will cause a "Link Down" message to be printed during
|
|
|
|
|
* resume, which is harmless - the true link state will be
|
|
|
|
|
* printed when we run a resolve.
|
|
|
|
|
*/
|
|
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
|
phylink_link_down(pl);
|
|
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
|
|
|
|
|
|
/* Re-apply the link parameters so that all the settings get
|
|
|
|
|
* restored to the MAC.
|
|
|
|
|
*/
|
|
|
|
|
phylink_mac_initial_config(pl, true);
|
|
|
|
|
|
|
|
|
|
/* Re-enable and re-resolve the link parameters */
|
2021-11-30 22:49:41 +08:00
|
|
|
phylink_enable_and_run_resolve(pl, PHYLINK_DISABLE_MAC_WOL);
|
2021-09-07 18:56:46 +08:00
|
|
|
} else {
|
|
|
|
|
phylink_start(pl);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_resume);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_get_wol() - get the wake on lan parameters for the PHY
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @wol: a pointer to &struct ethtool_wolinfo to hold the read parameters
|
|
|
|
|
*
|
|
|
|
|
* Read the wake on lan parameters from the PHY attached to the phylink
|
|
|
|
|
* instance specified by @pl. If no PHY is currently attached, report no
|
|
|
|
|
* support for wake on lan.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
void phylink_ethtool_get_wol(struct phylink *pl, struct ethtool_wolinfo *wol)
|
|
|
|
|
{
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
wol->supported = 0;
|
|
|
|
|
wol->wolopts = 0;
|
|
|
|
|
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
phy_ethtool_get_wol(pl->phydev, wol);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_get_wol);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_set_wol() - set wake on lan parameters
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @wol: a pointer to &struct ethtool_wolinfo for the desired parameters
|
|
|
|
|
*
|
|
|
|
|
* Set the wake on lan parameters for the PHY attached to the phylink
|
|
|
|
|
* instance specified by @pl. If no PHY is attached, returns %EOPNOTSUPP
|
|
|
|
|
* error.
|
|
|
|
|
*
|
|
|
|
|
* Returns zero on success or negative errno code.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_ethtool_set_wol(struct phylink *pl, struct ethtool_wolinfo *wol)
|
|
|
|
|
{
|
|
|
|
|
int ret = -EOPNOTSUPP;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
ret = phy_ethtool_set_wol(pl->phydev, wol);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_set_wol);
|
|
|
|
|
|
|
|
|
|
static void phylink_merge_link_mode(unsigned long *dst, const unsigned long *b)
|
|
|
|
|
{
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(mask);
|
|
|
|
|
|
|
|
|
|
linkmode_zero(mask);
|
|
|
|
|
phylink_set_port_modes(mask);
|
|
|
|
|
|
|
|
|
|
linkmode_and(dst, dst, mask);
|
|
|
|
|
linkmode_or(dst, dst, b);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_get_ksettings(const struct phylink_link_state *state,
|
|
|
|
|
struct ethtool_link_ksettings *kset)
|
|
|
|
|
{
|
|
|
|
|
phylink_merge_link_mode(kset->link_modes.advertising, state->advertising);
|
|
|
|
|
linkmode_copy(kset->link_modes.lp_advertising, state->lp_advertising);
|
2022-09-21 06:12:32 +08:00
|
|
|
if (kset->base.rate_matching == RATE_MATCH_NONE) {
|
|
|
|
|
kset->base.speed = state->speed;
|
|
|
|
|
kset->base.duplex = state->duplex;
|
|
|
|
|
}
|
2023-03-21 23:58:54 +08:00
|
|
|
kset->base.autoneg = linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
|
|
|
|
|
state->advertising) ?
|
|
|
|
|
AUTONEG_ENABLE : AUTONEG_DISABLE;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_ksettings_get() - get the current link settings
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @kset: a pointer to a &struct ethtool_link_ksettings to hold link settings
|
|
|
|
|
*
|
|
|
|
|
* Read the current link settings for the phylink instance specified by @pl.
|
|
|
|
|
* This will be the link settings read from the MAC, PHY or fixed link
|
|
|
|
|
* settings depending on the current negotiation mode.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_ethtool_ksettings_get(struct phylink *pl,
|
2017-10-31 12:42:57 +08:00
|
|
|
struct ethtool_link_ksettings *kset)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
|
|
|
|
struct phylink_link_state link_state;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2021-06-16 18:01:23 +08:00
|
|
|
if (pl->phydev)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
phy_ethtool_ksettings_get(pl->phydev, kset);
|
2021-06-16 18:01:23 +08:00
|
|
|
else
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
kset->base.port = pl->link_port;
|
|
|
|
|
|
|
|
|
|
linkmode_copy(kset->link_modes.supported, pl->supported);
|
|
|
|
|
|
2019-12-11 18:56:35 +08:00
|
|
|
switch (pl->cur_link_an_mode) {
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
case MLO_AN_FIXED:
|
|
|
|
|
/* We are using fixed settings. Report these as the
|
|
|
|
|
* current link settings - and note that these also
|
|
|
|
|
* represent the supported speeds/duplex/pause modes.
|
|
|
|
|
*/
|
|
|
|
|
phylink_get_fixed_state(pl, &link_state);
|
|
|
|
|
phylink_get_ksettings(&link_state, kset);
|
|
|
|
|
break;
|
|
|
|
|
|
2017-12-01 18:24:26 +08:00
|
|
|
case MLO_AN_INBAND:
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
/* If there is a phy attached, then use the reported
|
|
|
|
|
* settings from the phy with no modification.
|
|
|
|
|
*/
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
break;
|
|
|
|
|
|
2019-11-21 08:36:22 +08:00
|
|
|
phylink_mac_pcs_get_state(pl, &link_state);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
/* The MAC is reporting the link results from its own PCS
|
|
|
|
|
* layer via in-band status. Report these as the current
|
|
|
|
|
* link settings.
|
|
|
|
|
*/
|
|
|
|
|
phylink_get_ksettings(&link_state, kset);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_ksettings_get);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_ksettings_set() - set the link settings
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @kset: a pointer to a &struct ethtool_link_ksettings for the desired modes
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_ethtool_ksettings_set(struct phylink *pl,
|
2017-10-31 12:42:57 +08:00
|
|
|
const struct ethtool_link_ksettings *kset)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
2019-06-02 22:12:54 +08:00
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(support);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
struct phylink_link_state config;
|
2020-07-21 19:04:16 +08:00
|
|
|
const struct phy_setting *s;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2020-07-21 19:04:21 +08:00
|
|
|
if (pl->phydev) {
|
2023-06-01 17:12:06 +08:00
|
|
|
struct ethtool_link_ksettings phy_kset = *kset;
|
|
|
|
|
|
|
|
|
|
linkmode_and(phy_kset.link_modes.advertising,
|
|
|
|
|
phy_kset.link_modes.advertising,
|
|
|
|
|
pl->supported);
|
|
|
|
|
|
2020-07-21 19:04:21 +08:00
|
|
|
/* We can rely on phylib for this update; we also do not need
|
|
|
|
|
* to update the pl->link_config settings:
|
|
|
|
|
* - the configuration returned via ksettings_get() will come
|
|
|
|
|
* from phylib whenever a PHY is present.
|
|
|
|
|
* - link_config.interface will be updated by the PHY calling
|
|
|
|
|
* back via phylink_phy_change() and a subsequent resolve.
|
|
|
|
|
* - initial link configuration for PHY mode comes from the
|
|
|
|
|
* last phy state updated via phylink_phy_change().
|
|
|
|
|
* - other configuration changes (e.g. pause modes) are
|
|
|
|
|
* performed directly via phylib.
|
|
|
|
|
* - if in in-band mode with a PHY, the link configuration
|
|
|
|
|
* is passed on the link from the PHY, and all of
|
|
|
|
|
* link_config.{speed,duplex,an_enabled,pause} are not used.
|
|
|
|
|
* - the only possible use would be link_config.advertising
|
|
|
|
|
* pause modes when in 1000base-X mode with a PHY, but in
|
|
|
|
|
* the presence of a PHY, this should not be changed as that
|
|
|
|
|
* should be determined from the media side advertisement.
|
|
|
|
|
*/
|
2023-06-01 17:12:06 +08:00
|
|
|
return phy_ethtool_ksettings_set(pl->phydev, &phy_kset);
|
2020-07-21 19:04:21 +08:00
|
|
|
}
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
config = pl->link_config;
|
2023-06-01 17:12:06 +08:00
|
|
|
/* Mask out unsupported advertisements */
|
|
|
|
|
linkmode_and(config.advertising, kset->link_modes.advertising,
|
|
|
|
|
pl->supported);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
/* FIXME: should we reject autoneg if phy/mac does not support it? */
|
2020-07-21 19:04:16 +08:00
|
|
|
switch (kset->base.autoneg) {
|
|
|
|
|
case AUTONEG_DISABLE:
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
/* Autonegotiation disabled, select a suitable speed and
|
|
|
|
|
* duplex.
|
|
|
|
|
*/
|
|
|
|
|
s = phy_lookup_setting(kset->base.speed, kset->base.duplex,
|
2021-07-20 19:15:26 +08:00
|
|
|
pl->supported, false);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (!s)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2020-07-21 19:04:31 +08:00
|
|
|
/* If we have a fixed link, refuse to change link parameters.
|
|
|
|
|
* If the link parameters match, accept them but do nothing.
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
*/
|
2020-07-21 19:04:31 +08:00
|
|
|
if (pl->cur_link_an_mode == MLO_AN_FIXED) {
|
|
|
|
|
if (s->speed != pl->link_config.speed ||
|
|
|
|
|
s->duplex != pl->link_config.duplex)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
config.speed = s->speed;
|
|
|
|
|
config.duplex = s->duplex;
|
2020-07-21 19:04:16 +08:00
|
|
|
break;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2020-07-21 19:04:16 +08:00
|
|
|
case AUTONEG_ENABLE:
|
2020-07-21 19:04:31 +08:00
|
|
|
/* If we have a fixed link, allow autonegotiation (since that
|
|
|
|
|
* is our default case) but do not allow the advertisement to
|
|
|
|
|
* be changed. If the advertisement matches, simply return.
|
|
|
|
|
*/
|
|
|
|
|
if (pl->cur_link_an_mode == MLO_AN_FIXED) {
|
|
|
|
|
if (!linkmode_equal(config.advertising,
|
|
|
|
|
pl->link_config.advertising))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
config.speed = SPEED_UNKNOWN;
|
|
|
|
|
config.duplex = DUPLEX_UNKNOWN;
|
2020-07-21 19:04:16 +08:00
|
|
|
break;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2020-07-21 19:04:16 +08:00
|
|
|
default:
|
|
|
|
|
return -EINVAL;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
2020-07-21 19:04:31 +08:00
|
|
|
/* We have ruled out the case with a PHY attached, and the
|
|
|
|
|
* fixed-link cases. All that is left are in-band links.
|
2020-07-21 19:04:21 +08:00
|
|
|
*/
|
2021-07-20 19:15:26 +08:00
|
|
|
linkmode_mod_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, config.advertising,
|
2023-03-21 23:58:54 +08:00
|
|
|
kset->base.autoneg == AUTONEG_ENABLE);
|
2021-07-20 19:15:26 +08:00
|
|
|
|
2021-09-02 13:14:49 +08:00
|
|
|
/* If this link is with an SFP, ensure that changes to advertised modes
|
|
|
|
|
* also cause the associated interface to be selected such that the
|
|
|
|
|
* link can be configured correctly.
|
|
|
|
|
*/
|
2021-10-19 18:00:04 +08:00
|
|
|
if (pl->sfp_bus) {
|
2021-09-02 13:14:49 +08:00
|
|
|
config.interface = sfp_select_interface(pl->sfp_bus,
|
|
|
|
|
config.advertising);
|
|
|
|
|
if (config.interface == PHY_INTERFACE_MODE_NA) {
|
|
|
|
|
phylink_err(pl,
|
|
|
|
|
"selection of interface failed, advertisement %*pb\n",
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS,
|
|
|
|
|
config.advertising);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Revalidate with the selected interface */
|
|
|
|
|
linkmode_copy(support, pl->supported);
|
|
|
|
|
if (phylink_validate(pl, support, &config)) {
|
|
|
|
|
phylink_err(pl, "validation of %s/%s with support %*pb failed\n",
|
|
|
|
|
phylink_an_mode_str(pl->cur_link_an_mode),
|
|
|
|
|
phy_modes(config.interface),
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, support);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2021-10-19 18:00:04 +08:00
|
|
|
} else {
|
|
|
|
|
/* Validate without changing the current supported mask. */
|
|
|
|
|
linkmode_copy(support, pl->supported);
|
|
|
|
|
if (phylink_validate(pl, support, &config))
|
|
|
|
|
return -EINVAL;
|
2021-09-02 13:14:49 +08:00
|
|
|
}
|
|
|
|
|
|
2021-10-19 18:00:04 +08:00
|
|
|
/* If autonegotiation is enabled, we must have an advertisement */
|
2023-03-21 23:58:54 +08:00
|
|
|
if (linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
|
|
|
|
|
config.advertising) &&
|
|
|
|
|
phylink_is_empty_linkmode(config.advertising))
|
2021-10-19 18:00:04 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
2020-07-21 19:04:21 +08:00
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
|
pl->link_config.speed = config.speed;
|
|
|
|
|
pl->link_config.duplex = config.duplex;
|
|
|
|
|
|
2020-07-21 19:04:41 +08:00
|
|
|
if (pl->link_config.interface != config.interface) {
|
|
|
|
|
/* The interface changed, e.g. 1000base-X <-> 2500base-X */
|
|
|
|
|
/* We need to force the link down, then change the interface */
|
|
|
|
|
if (pl->old_link_state) {
|
|
|
|
|
phylink_link_down(pl);
|
|
|
|
|
pl->old_link_state = false;
|
|
|
|
|
}
|
|
|
|
|
if (!test_bit(PHYLINK_DISABLE_STOPPED,
|
|
|
|
|
&pl->phylink_disable_state))
|
|
|
|
|
phylink_major_config(pl, false, &config);
|
|
|
|
|
pl->link_config.interface = config.interface;
|
|
|
|
|
linkmode_copy(pl->link_config.advertising, config.advertising);
|
|
|
|
|
} else if (!linkmode_equal(pl->link_config.advertising,
|
|
|
|
|
config.advertising)) {
|
|
|
|
|
linkmode_copy(pl->link_config.advertising, config.advertising);
|
|
|
|
|
phylink_change_inband_advert(pl);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
2020-07-21 19:04:21 +08:00
|
|
|
mutex_unlock(&pl->state_mutex);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-08-10 05:35:50 +08:00
|
|
|
return 0;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_ksettings_set);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_nway_reset() - restart negotiation
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
*
|
|
|
|
|
* Restart negotiation for the phylink instance specified by @pl. This will
|
|
|
|
|
* cause any attached phy to restart negotiation with the link partner, and
|
|
|
|
|
* if the MAC is in a BaseX mode, the MAC will also be requested to restart
|
|
|
|
|
* negotiation.
|
|
|
|
|
*
|
|
|
|
|
* Returns zero on success, or negative error code.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_ethtool_nway_reset(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
ret = phy_restart_aneg(pl->phydev);
|
2023-07-14 17:12:17 +08:00
|
|
|
phylink_pcs_an_restart(pl);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_nway_reset);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_get_pauseparam() - get the current pause parameters
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @pause: a pointer to a &struct ethtool_pauseparam
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
void phylink_ethtool_get_pauseparam(struct phylink *pl,
|
|
|
|
|
struct ethtool_pauseparam *pause)
|
|
|
|
|
{
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
pause->autoneg = !!(pl->link_config.pause & MLO_PAUSE_AN);
|
|
|
|
|
pause->rx_pause = !!(pl->link_config.pause & MLO_PAUSE_RX);
|
|
|
|
|
pause->tx_pause = !!(pl->link_config.pause & MLO_PAUSE_TX);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_get_pauseparam);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_set_pauseparam() - set the current pause parameters
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @pause: a pointer to a &struct ethtool_pauseparam
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_ethtool_set_pauseparam(struct phylink *pl,
|
|
|
|
|
struct ethtool_pauseparam *pause)
|
|
|
|
|
{
|
|
|
|
|
struct phylink_link_state *config = &pl->link_config;
|
2020-06-24 00:47:29 +08:00
|
|
|
bool manual_changed;
|
|
|
|
|
int pause_state;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2020-02-15 23:49:37 +08:00
|
|
|
if (pl->cur_link_an_mode == MLO_AN_FIXED)
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (!phylink_test(pl->supported, Pause) &&
|
|
|
|
|
!phylink_test(pl->supported, Asym_Pause))
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
if (!phylink_test(pl->supported, Asym_Pause) &&
|
2021-10-28 22:55:34 +08:00
|
|
|
pause->rx_pause != pause->tx_pause)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
2020-06-24 00:47:29 +08:00
|
|
|
pause_state = 0;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (pause->autoneg)
|
2020-06-24 00:47:29 +08:00
|
|
|
pause_state |= MLO_PAUSE_AN;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (pause->rx_pause)
|
2020-06-24 00:47:29 +08:00
|
|
|
pause_state |= MLO_PAUSE_RX;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (pause->tx_pause)
|
2020-06-24 00:47:29 +08:00
|
|
|
pause_state |= MLO_PAUSE_TX;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2020-06-24 00:47:29 +08:00
|
|
|
mutex_lock(&pl->state_mutex);
|
2020-02-15 23:49:58 +08:00
|
|
|
/*
|
|
|
|
|
* See the comments for linkmode_set_pause(), wrt the deficiencies
|
|
|
|
|
* with the current implementation. A solution to this issue would
|
|
|
|
|
* be:
|
|
|
|
|
* ethtool Local device
|
|
|
|
|
* rx tx Pause AsymDir
|
|
|
|
|
* 0 0 0 0
|
|
|
|
|
* 1 0 1 1
|
|
|
|
|
* 0 1 0 1
|
|
|
|
|
* 1 1 1 1
|
|
|
|
|
* and then use the ethtool rx/tx enablement status to mask the
|
|
|
|
|
* rx/tx pause resolution.
|
|
|
|
|
*/
|
|
|
|
|
linkmode_set_pause(config->advertising, pause->tx_pause,
|
|
|
|
|
pause->rx_pause);
|
|
|
|
|
|
2020-06-24 00:47:29 +08:00
|
|
|
manual_changed = (config->pause ^ pause_state) & MLO_PAUSE_AN ||
|
|
|
|
|
(!(pause_state & MLO_PAUSE_AN) &&
|
|
|
|
|
(config->pause ^ pause_state) & MLO_PAUSE_TXRX_MASK);
|
|
|
|
|
|
|
|
|
|
config->pause = pause_state;
|
|
|
|
|
|
2020-07-21 19:04:36 +08:00
|
|
|
/* Update our in-band advertisement, triggering a renegotiation if
|
|
|
|
|
* the advertisement changed.
|
|
|
|
|
*/
|
|
|
|
|
if (!pl->phydev)
|
|
|
|
|
phylink_change_inband_advert(pl);
|
2020-06-24 00:47:23 +08:00
|
|
|
|
|
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
|
|
|
|
|
|
/* If we have a PHY, a change of the pause frame advertisement will
|
|
|
|
|
* cause phylib to renegotiate (if AN is enabled) which will in turn
|
|
|
|
|
* call our phylink_phy_change() and trigger a resolve. Note that
|
|
|
|
|
* we can't hold our state mutex while calling phy_set_asym_pause().
|
2019-11-20 01:28:14 +08:00
|
|
|
*/
|
2020-06-24 00:47:23 +08:00
|
|
|
if (pl->phydev)
|
2019-11-20 01:28:14 +08:00
|
|
|
phy_set_asym_pause(pl->phydev, pause->rx_pause,
|
|
|
|
|
pause->tx_pause);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2020-06-24 00:47:29 +08:00
|
|
|
/* If the manual pause settings changed, make sure we trigger a
|
|
|
|
|
* resolve to update their state; we can not guarantee that the
|
|
|
|
|
* link will cycle.
|
|
|
|
|
*/
|
|
|
|
|
if (manual_changed) {
|
|
|
|
|
pl->mac_link_dropped = true;
|
|
|
|
|
phylink_run_resolve(pl);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_set_pauseparam);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
2020-11-16 18:17:57 +08:00
|
|
|
* phylink_get_eee_err() - read the energy efficient ethernet error
|
2017-12-01 18:24:47 +08:00
|
|
|
* counter
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create().
|
|
|
|
|
*
|
|
|
|
|
* Read the Energy Efficient Ethernet error counter from the PHY associated
|
|
|
|
|
* with the phylink instance specified by @pl.
|
|
|
|
|
*
|
|
|
|
|
* Returns positive error counter value, or negative error code.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_get_eee_err(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
ret = phy_get_eee_err(pl->phydev);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_get_eee_err);
|
|
|
|
|
|
2019-02-11 19:46:06 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_init_eee() - init and check the EEE features
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @clk_stop_enable: allow PHY to stop receive clock
|
|
|
|
|
*
|
|
|
|
|
* Must be called either with RTNL held or within mac_link_up()
|
|
|
|
|
*/
|
|
|
|
|
int phylink_init_eee(struct phylink *pl, bool clk_stop_enable)
|
|
|
|
|
{
|
|
|
|
|
int ret = -EOPNOTSUPP;
|
|
|
|
|
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
ret = phy_init_eee(pl->phydev, clk_stop_enable);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_init_eee);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_get_eee() - read the energy efficient ethernet parameters
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @eee: a pointer to a &struct ethtool_eee for the read parameters
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_ethtool_get_eee(struct phylink *pl, struct ethtool_eee *eee)
|
|
|
|
|
{
|
|
|
|
|
int ret = -EOPNOTSUPP;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
ret = phy_ethtool_get_eee(pl->phydev, eee);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_get_eee);
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_ethtool_set_eee() - set the energy efficient ethernet parameters
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @eee: a pointer to a &struct ethtool_eee for the desired parameters
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_ethtool_set_eee(struct phylink *pl, struct ethtool_eee *eee)
|
|
|
|
|
{
|
|
|
|
|
int ret = -EOPNOTSUPP;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
ret = phy_ethtool_set_eee(pl->phydev, eee);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_set_eee);
|
|
|
|
|
|
|
|
|
|
/* This emulates MII registers for a fixed-mode phy operating as per the
|
|
|
|
|
* passed in state. "aneg" defines if we report negotiation is possible.
|
|
|
|
|
*
|
|
|
|
|
* FIXME: should deal with negotiation state too.
|
|
|
|
|
*/
|
2019-05-28 17:57:18 +08:00
|
|
|
static int phylink_mii_emul_read(unsigned int reg,
|
|
|
|
|
struct phylink_link_state *state)
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
{
|
|
|
|
|
struct fixed_phy_status fs;
|
2020-02-15 23:49:53 +08:00
|
|
|
unsigned long *lpa = state->lp_advertising;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int val;
|
|
|
|
|
|
|
|
|
|
fs.link = state->link;
|
|
|
|
|
fs.speed = state->speed;
|
|
|
|
|
fs.duplex = state->duplex;
|
2020-02-15 23:49:53 +08:00
|
|
|
fs.pause = test_bit(ETHTOOL_LINK_MODE_Pause_BIT, lpa);
|
|
|
|
|
fs.asym_pause = test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, lpa);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
|
|
|
|
val = swphy_read_reg(reg, &fs);
|
|
|
|
|
if (reg == MII_BMSR) {
|
|
|
|
|
if (!state->an_complete)
|
|
|
|
|
val &= ~BMSR_ANEGCOMPLETE;
|
|
|
|
|
}
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-25 22:03:28 +08:00
|
|
|
static int phylink_phy_read(struct phylink *pl, unsigned int phy_id,
|
|
|
|
|
unsigned int reg)
|
|
|
|
|
{
|
|
|
|
|
struct phy_device *phydev = pl->phydev;
|
|
|
|
|
int prtad, devad;
|
|
|
|
|
|
|
|
|
|
if (mdio_phy_id_is_c45(phy_id)) {
|
|
|
|
|
prtad = mdio_phy_id_prtad(phy_id);
|
|
|
|
|
devad = mdio_phy_id_devad(phy_id);
|
2022-05-01 01:30:33 +08:00
|
|
|
return mdiobus_c45_read(pl->phydev->mdio.bus, prtad, devad,
|
|
|
|
|
reg);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (phydev->is_c45) {
|
2017-07-25 22:03:28 +08:00
|
|
|
switch (reg) {
|
|
|
|
|
case MII_BMCR:
|
|
|
|
|
case MII_BMSR:
|
|
|
|
|
case MII_PHYSID1:
|
|
|
|
|
case MII_PHYSID2:
|
2020-06-18 21:46:08 +08:00
|
|
|
devad = __ffs(phydev->c45_ids.mmds_present);
|
2017-07-25 22:03:28 +08:00
|
|
|
break;
|
|
|
|
|
case MII_ADVERTISE:
|
|
|
|
|
case MII_LPA:
|
2020-06-18 21:46:08 +08:00
|
|
|
if (!(phydev->c45_ids.mmds_present & MDIO_DEVS_AN))
|
2017-07-25 22:03:28 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
devad = MDIO_MMD_AN;
|
|
|
|
|
if (reg == MII_ADVERTISE)
|
|
|
|
|
reg = MDIO_AN_ADVERTISE;
|
|
|
|
|
else
|
|
|
|
|
reg = MDIO_AN_LPA;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
prtad = phy_id;
|
2022-05-01 01:30:33 +08:00
|
|
|
return mdiobus_c45_read(pl->phydev->mdio.bus, prtad, devad,
|
|
|
|
|
reg);
|
2017-07-25 22:03:28 +08:00
|
|
|
}
|
2022-05-01 01:30:33 +08:00
|
|
|
|
|
|
|
|
return mdiobus_read(pl->phydev->mdio.bus, phy_id, reg);
|
2017-07-25 22:03:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int phylink_phy_write(struct phylink *pl, unsigned int phy_id,
|
|
|
|
|
unsigned int reg, unsigned int val)
|
|
|
|
|
{
|
|
|
|
|
struct phy_device *phydev = pl->phydev;
|
|
|
|
|
int prtad, devad;
|
|
|
|
|
|
|
|
|
|
if (mdio_phy_id_is_c45(phy_id)) {
|
|
|
|
|
prtad = mdio_phy_id_prtad(phy_id);
|
|
|
|
|
devad = mdio_phy_id_devad(phy_id);
|
2022-05-01 01:30:33 +08:00
|
|
|
return mdiobus_c45_write(pl->phydev->mdio.bus, prtad, devad,
|
|
|
|
|
reg, val);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (phydev->is_c45) {
|
2017-07-25 22:03:28 +08:00
|
|
|
switch (reg) {
|
|
|
|
|
case MII_BMCR:
|
|
|
|
|
case MII_BMSR:
|
|
|
|
|
case MII_PHYSID1:
|
|
|
|
|
case MII_PHYSID2:
|
2020-06-18 21:46:08 +08:00
|
|
|
devad = __ffs(phydev->c45_ids.mmds_present);
|
2017-07-25 22:03:28 +08:00
|
|
|
break;
|
|
|
|
|
case MII_ADVERTISE:
|
|
|
|
|
case MII_LPA:
|
2020-06-18 21:46:08 +08:00
|
|
|
if (!(phydev->c45_ids.mmds_present & MDIO_DEVS_AN))
|
2017-07-25 22:03:28 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
devad = MDIO_MMD_AN;
|
|
|
|
|
if (reg == MII_ADVERTISE)
|
|
|
|
|
reg = MDIO_AN_ADVERTISE;
|
|
|
|
|
else
|
|
|
|
|
reg = MDIO_AN_LPA;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2022-05-01 01:30:33 +08:00
|
|
|
return mdiobus_c45_write(pl->phydev->mdio.bus, phy_id, devad,
|
|
|
|
|
reg, val);
|
2017-07-25 22:03:28 +08:00
|
|
|
}
|
|
|
|
|
|
2022-05-01 01:30:33 +08:00
|
|
|
return mdiobus_write(phydev->mdio.bus, phy_id, reg, val);
|
2017-07-25 22:03:28 +08:00
|
|
|
}
|
|
|
|
|
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
static int phylink_mii_read(struct phylink *pl, unsigned int phy_id,
|
|
|
|
|
unsigned int reg)
|
|
|
|
|
{
|
|
|
|
|
struct phylink_link_state state;
|
|
|
|
|
int val = 0xffff;
|
|
|
|
|
|
2019-12-11 18:56:35 +08:00
|
|
|
switch (pl->cur_link_an_mode) {
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
case MLO_AN_FIXED:
|
|
|
|
|
if (phy_id == 0) {
|
|
|
|
|
phylink_get_fixed_state(pl, &state);
|
2019-05-28 17:57:18 +08:00
|
|
|
val = phylink_mii_emul_read(reg, &state);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case MLO_AN_PHY:
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2017-12-01 18:24:26 +08:00
|
|
|
case MLO_AN_INBAND:
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
if (phy_id == 0) {
|
2019-11-21 08:36:22 +08:00
|
|
|
phylink_mac_pcs_get_state(pl, &state);
|
2019-05-28 17:57:18 +08:00
|
|
|
val = phylink_mii_emul_read(reg, &state);
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return val & 0xffff;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int phylink_mii_write(struct phylink *pl, unsigned int phy_id,
|
|
|
|
|
unsigned int reg, unsigned int val)
|
|
|
|
|
{
|
2019-12-11 18:56:35 +08:00
|
|
|
switch (pl->cur_link_an_mode) {
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
case MLO_AN_FIXED:
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case MLO_AN_PHY:
|
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
2017-12-01 18:24:26 +08:00
|
|
|
case MLO_AN_INBAND:
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_mii_ioctl() - generic mii ioctl interface
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @ifr: a pointer to a &struct ifreq for socket ioctls
|
|
|
|
|
* @cmd: ioctl cmd to execute
|
|
|
|
|
*
|
|
|
|
|
* Perform the specified MII ioctl on the PHY attached to the phylink instance
|
|
|
|
|
* specified by @pl. If no PHY is attached, emulate the presence of the PHY.
|
|
|
|
|
*
|
|
|
|
|
* Returns: zero on success or negative error code.
|
|
|
|
|
*
|
|
|
|
|
* %SIOCGMIIPHY:
|
|
|
|
|
* read register from the current PHY.
|
|
|
|
|
* %SIOCGMIIREG:
|
|
|
|
|
* read register from the specified PHY.
|
|
|
|
|
* %SIOCSMIIREG:
|
|
|
|
|
* set a register on the specified PHY.
|
|
|
|
|
*/
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
int phylink_mii_ioctl(struct phylink *pl, struct ifreq *ifr, int cmd)
|
|
|
|
|
{
|
2017-07-25 22:03:28 +08:00
|
|
|
struct mii_ioctl_data *mii = if_mii(ifr);
|
|
|
|
|
int ret;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-07-25 22:03:28 +08:00
|
|
|
if (pl->phydev) {
|
2017-12-01 18:24:26 +08:00
|
|
|
/* PHYs only exist for MLO_AN_PHY and SGMII */
|
2017-07-25 22:03:28 +08:00
|
|
|
switch (cmd) {
|
|
|
|
|
case SIOCGMIIPHY:
|
|
|
|
|
mii->phy_id = pl->phydev->mdio.addr;
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
2017-07-25 22:03:28 +08:00
|
|
|
|
|
|
|
|
case SIOCGMIIREG:
|
|
|
|
|
ret = phylink_phy_read(pl, mii->phy_id, mii->reg_num);
|
|
|
|
|
if (ret >= 0) {
|
|
|
|
|
mii->val_out = ret;
|
|
|
|
|
ret = 0;
|
|
|
|
|
}
|
|
|
|
|
break;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-07-25 22:03:28 +08:00
|
|
|
case SIOCSMIIREG:
|
|
|
|
|
ret = phylink_phy_write(pl, mii->phy_id, mii->reg_num,
|
|
|
|
|
mii->val_in);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
ret = phy_mii_ioctl(pl->phydev, ifr, cmd);
|
|
|
|
|
break;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
2017-07-25 22:03:28 +08:00
|
|
|
} else {
|
|
|
|
|
switch (cmd) {
|
|
|
|
|
case SIOCGMIIPHY:
|
|
|
|
|
mii->phy_id = 0;
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
2017-07-25 22:03:28 +08:00
|
|
|
|
|
|
|
|
case SIOCGMIIREG:
|
|
|
|
|
ret = phylink_mii_read(pl, mii->phy_id, mii->reg_num);
|
|
|
|
|
if (ret >= 0) {
|
|
|
|
|
mii->val_out = ret;
|
|
|
|
|
ret = 0;
|
|
|
|
|
}
|
|
|
|
|
break;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-07-25 22:03:28 +08:00
|
|
|
case SIOCSMIIREG:
|
|
|
|
|
ret = phylink_mii_write(pl, mii->phy_id, mii->reg_num,
|
|
|
|
|
mii->val_in);
|
|
|
|
|
break;
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
|
2017-07-25 22:03:28 +08:00
|
|
|
default:
|
|
|
|
|
ret = -EOPNOTSUPP;
|
|
|
|
|
break;
|
|
|
|
|
}
|
phylink: add phylink infrastructure
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 22:03:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_mii_ioctl);
|
|
|
|
|
|
2020-06-24 18:06:54 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_speed_down() - set the non-SFP PHY to lowest speed supported by both
|
|
|
|
|
* link partners
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
* @sync: perform action synchronously
|
|
|
|
|
*
|
|
|
|
|
* If we have a PHY that is not part of a SFP module, then set the speed
|
|
|
|
|
* as described in the phy_speed_down() function. Please see this function
|
|
|
|
|
* for a description of the @sync parameter.
|
|
|
|
|
*
|
|
|
|
|
* Returns zero if there is no PHY, otherwise as per phy_speed_down().
|
|
|
|
|
*/
|
|
|
|
|
int phylink_speed_down(struct phylink *pl, bool sync)
|
|
|
|
|
{
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
ASSERT_RTNL();
|
|
|
|
|
|
|
|
|
|
if (!pl->sfp_bus && pl->phydev)
|
|
|
|
|
ret = phy_speed_down(pl->phydev, sync);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_speed_down);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* phylink_speed_up() - restore the advertised speeds prior to the call to
|
|
|
|
|
* phylink_speed_down()
|
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
|
*
|
|
|
|
|
* If we have a PHY that is not part of a SFP module, then restore the
|
|
|
|
|
* PHY speeds as per phy_speed_up().
|
|
|
|
|
*
|
|
|
|
|
* Returns zero if there is no PHY, otherwise as per phy_speed_up().
|
|
|
|
|
*/
|
|
|
|
|
int phylink_speed_up(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
ASSERT_RTNL();
|
|
|
|
|
|
|
|
|
|
if (!pl->sfp_bus && pl->phydev)
|
|
|
|
|
ret = phy_speed_up(pl->phydev);
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_speed_up);
|
|
|
|
|
|
2019-05-28 17:57:34 +08:00
|
|
|
static void phylink_sfp_attach(void *upstream, struct sfp_bus *bus)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = upstream;
|
|
|
|
|
|
|
|
|
|
pl->netdev->sfp_bus = bus;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_sfp_detach(void *upstream, struct sfp_bus *bus)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = upstream;
|
|
|
|
|
|
|
|
|
|
pl->netdev->sfp_bus = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
static const phy_interface_t phylink_sfp_interface_preference[] = {
|
|
|
|
|
PHY_INTERFACE_MODE_25GBASER,
|
|
|
|
|
PHY_INTERFACE_MODE_USXGMII,
|
|
|
|
|
PHY_INTERFACE_MODE_10GBASER,
|
|
|
|
|
PHY_INTERFACE_MODE_5GBASER,
|
|
|
|
|
PHY_INTERFACE_MODE_2500BASEX,
|
|
|
|
|
PHY_INTERFACE_MODE_SGMII,
|
|
|
|
|
PHY_INTERFACE_MODE_1000BASEX,
|
|
|
|
|
PHY_INTERFACE_MODE_100BASEX,
|
|
|
|
|
};
|
|
|
|
|
|
2022-09-30 22:21:03 +08:00
|
|
|
static DECLARE_PHY_INTERFACE_MASK(phylink_sfp_interfaces);
|
|
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
static phy_interface_t phylink_choose_sfp_interface(struct phylink *pl,
|
|
|
|
|
const unsigned long *intf)
|
|
|
|
|
{
|
|
|
|
|
phy_interface_t interface;
|
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
|
|
interface = PHY_INTERFACE_MODE_NA;
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(phylink_sfp_interface_preference); i++)
|
|
|
|
|
if (test_bit(phylink_sfp_interface_preference[i], intf)) {
|
|
|
|
|
interface = phylink_sfp_interface_preference[i];
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return interface;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_sfp_set_config(struct phylink *pl, u8 mode,
|
|
|
|
|
unsigned long *supported,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
bool changed = false;
|
|
|
|
|
|
|
|
|
|
phylink_dbg(pl, "requesting link mode %s/%s with support %*pb\n",
|
|
|
|
|
phylink_an_mode_str(mode), phy_modes(state->interface),
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, supported);
|
|
|
|
|
|
|
|
|
|
if (!linkmode_equal(pl->supported, supported)) {
|
|
|
|
|
linkmode_copy(pl->supported, supported);
|
|
|
|
|
changed = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!linkmode_equal(pl->link_config.advertising, state->advertising)) {
|
|
|
|
|
linkmode_copy(pl->link_config.advertising, state->advertising);
|
|
|
|
|
changed = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (pl->cur_link_an_mode != mode ||
|
|
|
|
|
pl->link_config.interface != state->interface) {
|
|
|
|
|
pl->cur_link_an_mode = mode;
|
|
|
|
|
pl->link_config.interface = state->interface;
|
|
|
|
|
|
|
|
|
|
changed = true;
|
|
|
|
|
|
|
|
|
|
phylink_info(pl, "switched to %s/%s link mode\n",
|
|
|
|
|
phylink_an_mode_str(mode),
|
|
|
|
|
phy_modes(state->interface));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (changed && !test_bit(PHYLINK_DISABLE_STOPPED,
|
|
|
|
|
&pl->phylink_disable_state))
|
|
|
|
|
phylink_mac_initial_config(pl, false);
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-30 22:21:02 +08:00
|
|
|
static int phylink_sfp_config_phy(struct phylink *pl, u8 mode,
|
|
|
|
|
struct phy_device *phy)
|
2017-07-25 22:03:18 +08:00
|
|
|
{
|
2019-06-02 22:12:54 +08:00
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(support1);
|
2019-12-11 18:56:40 +08:00
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(support);
|
2017-07-25 22:03:18 +08:00
|
|
|
struct phylink_link_state config;
|
|
|
|
|
phy_interface_t iface;
|
2019-12-11 18:56:40 +08:00
|
|
|
int ret;
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2022-09-30 22:21:02 +08:00
|
|
|
linkmode_copy(support, phy->supported);
|
2017-07-25 22:03:18 +08:00
|
|
|
|
|
|
|
|
memset(&config, 0, sizeof(config));
|
2022-09-30 22:21:02 +08:00
|
|
|
linkmode_copy(config.advertising, phy->advertising);
|
2018-02-27 23:53:02 +08:00
|
|
|
config.interface = PHY_INTERFACE_MODE_NA;
|
2017-07-25 22:03:18 +08:00
|
|
|
config.speed = SPEED_UNKNOWN;
|
|
|
|
|
config.duplex = DUPLEX_UNKNOWN;
|
|
|
|
|
config.pause = MLO_PAUSE_AN;
|
|
|
|
|
|
|
|
|
|
/* Ignore errors if we're expecting a PHY to attach later */
|
|
|
|
|
ret = phylink_validate(pl, support, &config);
|
2018-02-27 23:53:02 +08:00
|
|
|
if (ret) {
|
2022-03-01 16:51:34 +08:00
|
|
|
phylink_err(pl, "validation with support %*pb failed: %pe\n",
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, support,
|
|
|
|
|
ERR_PTR(ret));
|
2018-02-27 23:53:02 +08:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:55:59 +08:00
|
|
|
iface = sfp_select_interface(pl->sfp_bus, config.advertising);
|
2018-02-27 23:53:02 +08:00
|
|
|
if (iface == PHY_INTERFACE_MODE_NA) {
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_err(pl,
|
|
|
|
|
"selection of interface failed, advertisement %*pb\n",
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, config.advertising);
|
2018-02-27 23:53:02 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
config.interface = iface;
|
2019-12-11 18:56:40 +08:00
|
|
|
linkmode_copy(support1, support);
|
2019-06-02 22:12:54 +08:00
|
|
|
ret = phylink_validate(pl, support1, &config);
|
2017-07-25 22:03:18 +08:00
|
|
|
if (ret) {
|
2022-03-01 16:51:34 +08:00
|
|
|
phylink_err(pl,
|
|
|
|
|
"validation of %s/%s with support %*pb failed: %pe\n",
|
2019-12-11 18:56:40 +08:00
|
|
|
phylink_an_mode_str(mode),
|
2019-05-29 01:38:14 +08:00
|
|
|
phy_modes(config.interface),
|
2022-03-01 16:51:34 +08:00
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, support,
|
|
|
|
|
ERR_PTR(ret));
|
2017-07-25 22:03:18 +08:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
pl->link_port = pl->sfp_port;
|
|
|
|
|
|
|
|
|
|
phylink_sfp_set_config(pl, mode, support, &config);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int phylink_sfp_config_optical(struct phylink *pl)
|
|
|
|
|
{
|
|
|
|
|
__ETHTOOL_DECLARE_LINK_MODE_MASK(support);
|
|
|
|
|
DECLARE_PHY_INTERFACE_MASK(interfaces);
|
|
|
|
|
struct phylink_link_state config;
|
|
|
|
|
phy_interface_t interface;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
phylink_dbg(pl, "optical SFP: interfaces=[mac=%*pbl, sfp=%*pbl]\n",
|
|
|
|
|
(int)PHY_INTERFACE_MODE_MAX,
|
|
|
|
|
pl->config->supported_interfaces,
|
|
|
|
|
(int)PHY_INTERFACE_MODE_MAX,
|
|
|
|
|
pl->sfp_interfaces);
|
|
|
|
|
|
|
|
|
|
/* Find the union of the supported interfaces by the PCS/MAC and
|
|
|
|
|
* the SFP module.
|
|
|
|
|
*/
|
|
|
|
|
phy_interface_and(interfaces, pl->config->supported_interfaces,
|
|
|
|
|
pl->sfp_interfaces);
|
|
|
|
|
if (phy_interface_empty(interfaces)) {
|
|
|
|
|
phylink_err(pl, "unsupported SFP module: no common interface modes\n");
|
|
|
|
|
return -EINVAL;
|
2017-07-25 22:03:18 +08:00
|
|
|
}
|
|
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
memset(&config, 0, sizeof(config));
|
|
|
|
|
linkmode_copy(support, pl->sfp_support);
|
|
|
|
|
linkmode_copy(config.advertising, pl->sfp_support);
|
|
|
|
|
config.speed = SPEED_UNKNOWN;
|
|
|
|
|
config.duplex = DUPLEX_UNKNOWN;
|
|
|
|
|
config.pause = MLO_PAUSE_AN;
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
/* For all the interfaces that are supported, reduce the sfp_support
|
|
|
|
|
* mask to only those link modes that can be supported.
|
|
|
|
|
*/
|
|
|
|
|
ret = phylink_validate_mask(pl, pl->sfp_support, &config, interfaces);
|
|
|
|
|
if (ret) {
|
|
|
|
|
phylink_err(pl, "unsupported SFP module: validation with support %*pb failed\n",
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, support);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
interface = phylink_choose_sfp_interface(pl, interfaces);
|
|
|
|
|
if (interface == PHY_INTERFACE_MODE_NA) {
|
|
|
|
|
phylink_err(pl, "failed to select SFP interface\n");
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
phylink_dbg(pl, "optical SFP: chosen %s interface\n",
|
|
|
|
|
phy_modes(interface));
|
|
|
|
|
|
|
|
|
|
config.interface = interface;
|
|
|
|
|
|
|
|
|
|
/* Ignore errors if we're expecting a PHY to attach later */
|
|
|
|
|
ret = phylink_validate(pl, support, &config);
|
|
|
|
|
if (ret) {
|
|
|
|
|
phylink_err(pl, "validation with support %*pb failed: %pe\n",
|
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, support,
|
|
|
|
|
ERR_PTR(ret));
|
|
|
|
|
return ret;
|
2017-07-25 22:03:18 +08:00
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:45 +08:00
|
|
|
pl->link_port = pl->sfp_port;
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
phylink_sfp_set_config(pl, MLO_AN_INBAND, pl->sfp_support, &config);
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
return 0;
|
2017-07-25 22:03:18 +08:00
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:40 +08:00
|
|
|
static int phylink_sfp_module_insert(void *upstream,
|
|
|
|
|
const struct sfp_eeprom_id *id)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = upstream;
|
|
|
|
|
|
|
|
|
|
ASSERT_RTNL();
|
|
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
linkmode_zero(pl->sfp_support);
|
2022-09-30 22:21:00 +08:00
|
|
|
phy_interface_zero(pl->sfp_interfaces);
|
2022-09-30 22:21:01 +08:00
|
|
|
sfp_parse_support(pl->sfp_bus, id, pl->sfp_support, pl->sfp_interfaces);
|
|
|
|
|
pl->sfp_port = sfp_parse_port(pl->sfp_bus, id, pl->sfp_support);
|
2019-12-11 18:56:40 +08:00
|
|
|
|
2019-12-11 18:56:45 +08:00
|
|
|
/* If this module may have a PHY connecting later, defer until later */
|
|
|
|
|
pl->sfp_may_have_phy = sfp_may_have_phy(pl->sfp_bus, id);
|
|
|
|
|
if (pl->sfp_may_have_phy)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
return phylink_sfp_config_optical(pl);
|
2019-12-11 18:56:40 +08:00
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:14 +08:00
|
|
|
static int phylink_sfp_module_start(void *upstream)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = upstream;
|
|
|
|
|
|
|
|
|
|
/* If this SFP module has a PHY, start the PHY now. */
|
2019-12-11 18:56:45 +08:00
|
|
|
if (pl->phydev) {
|
2019-12-11 18:56:14 +08:00
|
|
|
phy_start(pl->phydev);
|
2019-12-11 18:56:45 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
2019-12-11 18:56:14 +08:00
|
|
|
|
2019-12-11 18:56:45 +08:00
|
|
|
/* If the module may have a PHY but we didn't detect one we
|
|
|
|
|
* need to configure the MAC here.
|
|
|
|
|
*/
|
|
|
|
|
if (!pl->sfp_may_have_phy)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2022-09-30 22:21:01 +08:00
|
|
|
return phylink_sfp_config_optical(pl);
|
2019-12-11 18:56:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_sfp_module_stop(void *upstream)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = upstream;
|
|
|
|
|
|
|
|
|
|
/* If this SFP module has a PHY, stop it. */
|
|
|
|
|
if (pl->phydev)
|
|
|
|
|
phy_stop(pl->phydev);
|
|
|
|
|
}
|
|
|
|
|
|
2017-07-25 22:03:18 +08:00
|
|
|
static void phylink_sfp_link_down(void *upstream)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = upstream;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2019-02-11 23:04:24 +08:00
|
|
|
phylink_run_resolve_and_disable(pl, PHYLINK_DISABLE_LINK);
|
2017-07-25 22:03:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_sfp_link_up(void *upstream)
|
|
|
|
|
{
|
|
|
|
|
struct phylink *pl = upstream;
|
|
|
|
|
|
2017-12-16 00:09:47 +08:00
|
|
|
ASSERT_RTNL();
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2021-11-30 22:49:41 +08:00
|
|
|
phylink_enable_and_run_resolve(pl, PHYLINK_DISABLE_LINK);
|
2017-07-25 22:03:18 +08:00
|
|
|
}
|
|
|
|
|
|
2019-12-11 18:56:50 +08:00
|
|
|
/* The Broadcom BCM84881 in the Methode DM7052 is unable to provide a SGMII
|
|
|
|
|
* or 802.3z control word, so inband will not work.
|
|
|
|
|
*/
|
|
|
|
|
static bool phylink_phy_no_inband(struct phy_device *phy)
|
|
|
|
|
{
|
2023-05-19 21:03:59 +08:00
|
|
|
return phy->is_c45 && phy_id_compare(phy->c45_ids.device_ids[1],
|
|
|
|
|
0xae025150, 0xfffffff0);
|
2019-12-11 18:56:50 +08:00
|
|
|
}
|
|
|
|
|
|
2017-07-25 22:03:18 +08:00
|
|
|
static int phylink_sfp_connect_phy(void *upstream, struct phy_device *phy)
|
|
|
|
|
{
|
2018-10-04 00:04:49 +08:00
|
|
|
struct phylink *pl = upstream;
|
2019-12-11 18:56:45 +08:00
|
|
|
phy_interface_t interface;
|
2019-12-11 18:56:50 +08:00
|
|
|
u8 mode;
|
2019-12-11 18:56:25 +08:00
|
|
|
int ret;
|
2018-10-04 00:04:49 +08:00
|
|
|
|
2019-12-11 18:56:45 +08:00
|
|
|
/*
|
|
|
|
|
* This is the new way of dealing with flow control for PHYs,
|
|
|
|
|
* as described by Timur Tabi in commit 529ed1275263 ("net: phy:
|
|
|
|
|
* phy drivers should not set SUPPORTED_[Asym_]Pause") except
|
|
|
|
|
* using our validate call to the MAC, we rely upon the MAC
|
|
|
|
|
* clearing the bits from both supported and advertising fields.
|
|
|
|
|
*/
|
|
|
|
|
phy_support_asym_pause(phy);
|
|
|
|
|
|
2019-12-11 18:56:50 +08:00
|
|
|
if (phylink_phy_no_inband(phy))
|
|
|
|
|
mode = MLO_AN_PHY;
|
|
|
|
|
else
|
|
|
|
|
mode = MLO_AN_INBAND;
|
|
|
|
|
|
2022-09-30 22:21:03 +08:00
|
|
|
/* Set the PHY's host supported interfaces */
|
|
|
|
|
phy_interface_and(phy->host_interfaces, phylink_sfp_interfaces,
|
|
|
|
|
pl->config->supported_interfaces);
|
|
|
|
|
|
2019-12-11 18:56:45 +08:00
|
|
|
/* Do the initial configuration */
|
2022-09-30 22:21:02 +08:00
|
|
|
ret = phylink_sfp_config_phy(pl, mode, phy);
|
2019-12-11 18:56:45 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
interface = pl->link_config.interface;
|
|
|
|
|
ret = phylink_attach_phy(pl, phy, interface);
|
2019-12-11 18:56:25 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
2019-12-11 18:56:30 +08:00
|
|
|
ret = phylink_bringup_phy(pl, phy, interface);
|
2019-12-11 18:56:25 +08:00
|
|
|
if (ret)
|
|
|
|
|
phy_detach(phy);
|
|
|
|
|
|
|
|
|
|
return ret;
|
2017-07-25 22:03:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_sfp_disconnect_phy(void *upstream)
|
|
|
|
|
{
|
|
|
|
|
phylink_disconnect_phy(upstream);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct sfp_upstream_ops sfp_phylink_ops = {
|
2019-05-28 17:57:34 +08:00
|
|
|
.attach = phylink_sfp_attach,
|
|
|
|
|
.detach = phylink_sfp_detach,
|
2017-07-25 22:03:18 +08:00
|
|
|
.module_insert = phylink_sfp_module_insert,
|
2019-12-11 18:56:14 +08:00
|
|
|
.module_start = phylink_sfp_module_start,
|
|
|
|
|
.module_stop = phylink_sfp_module_stop,
|
2017-07-25 22:03:18 +08:00
|
|
|
.link_up = phylink_sfp_link_up,
|
|
|
|
|
.link_down = phylink_sfp_link_down,
|
|
|
|
|
.connect_phy = phylink_sfp_connect_phy,
|
|
|
|
|
.disconnect_phy = phylink_sfp_disconnect_phy,
|
|
|
|
|
};
|
|
|
|
|
|
2018-08-09 21:38:38 +08:00
|
|
|
/* Helpers for MAC drivers */
|
|
|
|
|
|
2023-05-23 18:15:58 +08:00
|
|
|
static struct {
|
|
|
|
|
int bit;
|
|
|
|
|
int speed;
|
|
|
|
|
} phylink_c73_priority_resolution[] = {
|
|
|
|
|
{ ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT, SPEED_100000 },
|
|
|
|
|
{ ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT, SPEED_100000 },
|
|
|
|
|
/* 100GBASE-KP4 and 100GBASE-CR10 not supported */
|
|
|
|
|
{ ETHTOOL_LINK_MODE_40000baseCR4_Full_BIT, SPEED_40000 },
|
|
|
|
|
{ ETHTOOL_LINK_MODE_40000baseKR4_Full_BIT, SPEED_40000 },
|
|
|
|
|
{ ETHTOOL_LINK_MODE_10000baseKR_Full_BIT, SPEED_10000 },
|
|
|
|
|
{ ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT, SPEED_10000 },
|
|
|
|
|
/* 5GBASE-KR not supported */
|
|
|
|
|
{ ETHTOOL_LINK_MODE_2500baseX_Full_BIT, SPEED_2500 },
|
|
|
|
|
{ ETHTOOL_LINK_MODE_1000baseKX_Full_BIT, SPEED_1000 },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void phylink_resolve_c73(struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(phylink_c73_priority_resolution); i++) {
|
|
|
|
|
int bit = phylink_c73_priority_resolution[i].bit;
|
|
|
|
|
if (linkmode_test_bit(bit, state->advertising) &&
|
|
|
|
|
linkmode_test_bit(bit, state->lp_advertising))
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (i < ARRAY_SIZE(phylink_c73_priority_resolution)) {
|
|
|
|
|
state->speed = phylink_c73_priority_resolution[i].speed;
|
|
|
|
|
state->duplex = DUPLEX_FULL;
|
|
|
|
|
} else {
|
|
|
|
|
/* negotiation failure */
|
|
|
|
|
state->link = false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
phylink_resolve_an_pause(state);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_resolve_c73);
|
|
|
|
|
|
2020-03-17 22:52:36 +08:00
|
|
|
static void phylink_decode_c37_word(struct phylink_link_state *state,
|
|
|
|
|
uint16_t config_reg, int speed)
|
|
|
|
|
{
|
|
|
|
|
int fd_bit;
|
|
|
|
|
|
|
|
|
|
if (speed == SPEED_2500)
|
|
|
|
|
fd_bit = ETHTOOL_LINK_MODE_2500baseX_Full_BIT;
|
|
|
|
|
else
|
|
|
|
|
fd_bit = ETHTOOL_LINK_MODE_1000baseX_Full_BIT;
|
|
|
|
|
|
|
|
|
|
mii_lpa_mod_linkmode_x(state->lp_advertising, config_reg, fd_bit);
|
|
|
|
|
|
|
|
|
|
if (linkmode_test_bit(fd_bit, state->advertising) &&
|
|
|
|
|
linkmode_test_bit(fd_bit, state->lp_advertising)) {
|
|
|
|
|
state->speed = speed;
|
|
|
|
|
state->duplex = DUPLEX_FULL;
|
|
|
|
|
} else {
|
|
|
|
|
/* negotiation failure */
|
|
|
|
|
state->link = false;
|
|
|
|
|
}
|
|
|
|
|
|
2023-05-23 18:15:53 +08:00
|
|
|
phylink_resolve_an_pause(state);
|
2020-03-17 22:52:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void phylink_decode_sgmii_word(struct phylink_link_state *state,
|
|
|
|
|
uint16_t config_reg)
|
|
|
|
|
{
|
|
|
|
|
if (!(config_reg & LPA_SGMII_LINK)) {
|
|
|
|
|
state->link = false;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (config_reg & LPA_SGMII_SPD_MASK) {
|
|
|
|
|
case LPA_SGMII_10:
|
|
|
|
|
state->speed = SPEED_10;
|
|
|
|
|
break;
|
|
|
|
|
case LPA_SGMII_100:
|
|
|
|
|
state->speed = SPEED_100;
|
|
|
|
|
break;
|
|
|
|
|
case LPA_SGMII_1000:
|
|
|
|
|
state->speed = SPEED_1000;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
state->link = false;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (config_reg & LPA_SGMII_FULL_DUPLEX)
|
|
|
|
|
state->duplex = DUPLEX_FULL;
|
|
|
|
|
else
|
|
|
|
|
state->duplex = DUPLEX_HALF;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-30 16:33:58 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_decode_usxgmii_word() - decode the USXGMII word from a MAC PCS
|
|
|
|
|
* @state: a pointer to a struct phylink_link_state.
|
|
|
|
|
* @lpa: a 16 bit value which stores the USXGMII auto-negotiation word
|
|
|
|
|
*
|
|
|
|
|
* Helper for MAC PCS supporting the USXGMII protocol and the auto-negotiation
|
|
|
|
|
* code word. Decode the USXGMII code word and populate the corresponding fields
|
|
|
|
|
* (speed, duplex) into the phylink_link_state structure.
|
|
|
|
|
*/
|
|
|
|
|
void phylink_decode_usxgmii_word(struct phylink_link_state *state,
|
|
|
|
|
uint16_t lpa)
|
|
|
|
|
{
|
|
|
|
|
switch (lpa & MDIO_USXGMII_SPD_MASK) {
|
|
|
|
|
case MDIO_USXGMII_10:
|
|
|
|
|
state->speed = SPEED_10;
|
|
|
|
|
break;
|
|
|
|
|
case MDIO_USXGMII_100:
|
|
|
|
|
state->speed = SPEED_100;
|
|
|
|
|
break;
|
|
|
|
|
case MDIO_USXGMII_1000:
|
|
|
|
|
state->speed = SPEED_1000;
|
|
|
|
|
break;
|
|
|
|
|
case MDIO_USXGMII_2500:
|
|
|
|
|
state->speed = SPEED_2500;
|
|
|
|
|
break;
|
|
|
|
|
case MDIO_USXGMII_5000:
|
|
|
|
|
state->speed = SPEED_5000;
|
|
|
|
|
break;
|
|
|
|
|
case MDIO_USXGMII_10G:
|
|
|
|
|
state->speed = SPEED_10000;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
state->link = false;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (lpa & MDIO_USXGMII_FULL_DUPLEX)
|
|
|
|
|
state->duplex = DUPLEX_FULL;
|
|
|
|
|
else
|
|
|
|
|
state->duplex = DUPLEX_HALF;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_decode_usxgmii_word);
|
|
|
|
|
|
2023-06-09 16:03:05 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_decode_usgmii_word() - decode the USGMII word from a MAC PCS
|
|
|
|
|
* @state: a pointer to a struct phylink_link_state.
|
|
|
|
|
* @lpa: a 16 bit value which stores the USGMII auto-negotiation word
|
|
|
|
|
*
|
|
|
|
|
* Helper for MAC PCS supporting the USGMII protocol and the auto-negotiation
|
|
|
|
|
* code word. Decode the USGMII code word and populate the corresponding fields
|
|
|
|
|
* (speed, duplex) into the phylink_link_state structure. The structure for this
|
|
|
|
|
* word is the same as the USXGMII word, except it only supports speeds up to
|
|
|
|
|
* 1Gbps.
|
|
|
|
|
*/
|
|
|
|
|
static void phylink_decode_usgmii_word(struct phylink_link_state *state,
|
|
|
|
|
uint16_t lpa)
|
|
|
|
|
{
|
|
|
|
|
switch (lpa & MDIO_USXGMII_SPD_MASK) {
|
|
|
|
|
case MDIO_USXGMII_10:
|
|
|
|
|
state->speed = SPEED_10;
|
|
|
|
|
break;
|
|
|
|
|
case MDIO_USXGMII_100:
|
|
|
|
|
state->speed = SPEED_100;
|
|
|
|
|
break;
|
|
|
|
|
case MDIO_USXGMII_1000:
|
|
|
|
|
state->speed = SPEED_1000;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
state->link = false;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (lpa & MDIO_USXGMII_FULL_DUPLEX)
|
|
|
|
|
state->duplex = DUPLEX_FULL;
|
|
|
|
|
else
|
|
|
|
|
state->duplex = DUPLEX_HALF;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-17 22:52:36 +08:00
|
|
|
/**
|
2021-11-19 23:58:09 +08:00
|
|
|
* phylink_mii_c22_pcs_decode_state() - Decode MAC PCS state from MII registers
|
2020-03-17 22:52:36 +08:00
|
|
|
* @state: a pointer to a &struct phylink_link_state.
|
2021-11-19 23:58:09 +08:00
|
|
|
* @bmsr: The value of the %MII_BMSR register
|
|
|
|
|
* @lpa: The value of the %MII_LPA register
|
2020-03-17 22:52:36 +08:00
|
|
|
*
|
|
|
|
|
* Helper for MAC PCS supporting the 802.3 clause 22 register set for
|
|
|
|
|
* clause 37 negotiation and/or SGMII control.
|
|
|
|
|
*
|
2021-11-19 23:58:09 +08:00
|
|
|
* Parse the Clause 37 or Cisco SGMII link partner negotiation word into
|
|
|
|
|
* the phylink @state structure. This is suitable to be used for implementing
|
2023-07-23 04:32:59 +08:00
|
|
|
* the pcs_get_state() member of the struct phylink_pcs_ops structure if
|
2021-11-19 23:58:09 +08:00
|
|
|
* accessing @bmsr and @lpa cannot be done with MDIO directly.
|
2020-03-17 22:52:36 +08:00
|
|
|
*/
|
2021-11-19 23:58:09 +08:00
|
|
|
void phylink_mii_c22_pcs_decode_state(struct phylink_link_state *state,
|
|
|
|
|
u16 bmsr, u16 lpa)
|
2020-03-17 22:52:36 +08:00
|
|
|
{
|
|
|
|
|
state->link = !!(bmsr & BMSR_LSTATUS);
|
|
|
|
|
state->an_complete = !!(bmsr & BMSR_ANEGCOMPLETE);
|
2021-10-19 18:24:50 +08:00
|
|
|
/* If there is no link or autonegotiation is disabled, the LP advertisement
|
|
|
|
|
* data is not meaningful, so don't go any further.
|
|
|
|
|
*/
|
2023-03-21 23:58:54 +08:00
|
|
|
if (!state->link || !linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
|
|
|
|
|
state->advertising))
|
2020-03-17 22:52:36 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
switch (state->interface) {
|
|
|
|
|
case PHY_INTERFACE_MODE_1000BASEX:
|
|
|
|
|
phylink_decode_c37_word(state, lpa, SPEED_1000);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_2500BASEX:
|
|
|
|
|
phylink_decode_c37_word(state, lpa, SPEED_2500);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case PHY_INTERFACE_MODE_SGMII:
|
2020-08-30 16:33:59 +08:00
|
|
|
case PHY_INTERFACE_MODE_QSGMII:
|
2020-03-17 22:52:36 +08:00
|
|
|
phylink_decode_sgmii_word(state, lpa);
|
|
|
|
|
break;
|
2023-06-09 16:03:05 +08:00
|
|
|
case PHY_INTERFACE_MODE_QUSGMII:
|
|
|
|
|
phylink_decode_usgmii_word(state, lpa);
|
|
|
|
|
break;
|
2020-03-17 22:52:36 +08:00
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
state->link = false;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-11-19 23:58:09 +08:00
|
|
|
EXPORT_SYMBOL_GPL(phylink_mii_c22_pcs_decode_state);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* phylink_mii_c22_pcs_get_state() - read the MAC PCS state
|
|
|
|
|
* @pcs: a pointer to a &struct mdio_device.
|
|
|
|
|
* @state: a pointer to a &struct phylink_link_state.
|
|
|
|
|
*
|
|
|
|
|
* Helper for MAC PCS supporting the 802.3 clause 22 register set for
|
|
|
|
|
* clause 37 negotiation and/or SGMII control.
|
|
|
|
|
*
|
|
|
|
|
* Read the MAC PCS state from the MII device configured in @config and
|
|
|
|
|
* parse the Clause 37 or Cisco SGMII link partner negotiation word into
|
|
|
|
|
* the phylink @state structure. This is suitable to be directly plugged
|
2023-07-23 04:32:59 +08:00
|
|
|
* into the pcs_get_state() member of the struct phylink_pcs_ops
|
2021-11-19 23:58:09 +08:00
|
|
|
* structure.
|
|
|
|
|
*/
|
|
|
|
|
void phylink_mii_c22_pcs_get_state(struct mdio_device *pcs,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
int bmsr, lpa;
|
|
|
|
|
|
|
|
|
|
bmsr = mdiodev_read(pcs, MII_BMSR);
|
|
|
|
|
lpa = mdiodev_read(pcs, MII_LPA);
|
|
|
|
|
if (bmsr < 0 || lpa < 0) {
|
|
|
|
|
state->link = false;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
phylink_mii_c22_pcs_decode_state(state, bmsr, lpa);
|
|
|
|
|
}
|
2020-03-17 22:52:36 +08:00
|
|
|
EXPORT_SYMBOL_GPL(phylink_mii_c22_pcs_get_state);
|
|
|
|
|
|
|
|
|
|
/**
|
2021-11-19 23:58:09 +08:00
|
|
|
* phylink_mii_c22_pcs_encode_advertisement() - configure the clause 37 PCS
|
2020-03-17 22:52:36 +08:00
|
|
|
* advertisement
|
2020-03-31 01:44:44 +08:00
|
|
|
* @interface: the PHY interface mode being configured
|
|
|
|
|
* @advertising: the ethtool advertisement mask
|
2020-03-17 22:52:36 +08:00
|
|
|
*
|
|
|
|
|
* Helper for MAC PCS supporting the 802.3 clause 22 register set for
|
|
|
|
|
* clause 37 negotiation and/or SGMII control.
|
|
|
|
|
*
|
2021-11-19 23:58:09 +08:00
|
|
|
* Encode the clause 37 PCS advertisement as specified by @interface and
|
|
|
|
|
* @advertising.
|
2020-03-17 22:52:36 +08:00
|
|
|
*
|
2021-11-19 23:58:09 +08:00
|
|
|
* Return: The new value for @adv, or ``-EINVAL`` if it should not be changed.
|
2020-03-17 22:52:36 +08:00
|
|
|
*/
|
2021-11-19 23:58:09 +08:00
|
|
|
int phylink_mii_c22_pcs_encode_advertisement(phy_interface_t interface,
|
|
|
|
|
const unsigned long *advertising)
|
2020-03-17 22:52:36 +08:00
|
|
|
{
|
|
|
|
|
u16 adv;
|
|
|
|
|
|
2020-03-31 01:44:44 +08:00
|
|
|
switch (interface) {
|
2020-03-17 22:52:36 +08:00
|
|
|
case PHY_INTERFACE_MODE_1000BASEX:
|
|
|
|
|
case PHY_INTERFACE_MODE_2500BASEX:
|
|
|
|
|
adv = ADVERTISE_1000XFULL;
|
|
|
|
|
if (linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT,
|
2020-03-31 01:44:44 +08:00
|
|
|
advertising))
|
2020-03-17 22:52:36 +08:00
|
|
|
adv |= ADVERTISE_1000XPAUSE;
|
|
|
|
|
if (linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
|
2020-03-31 01:44:44 +08:00
|
|
|
advertising))
|
2020-03-17 22:52:36 +08:00
|
|
|
adv |= ADVERTISE_1000XPSE_ASYM;
|
2021-11-19 23:58:09 +08:00
|
|
|
return adv;
|
2020-03-17 22:52:36 +08:00
|
|
|
case PHY_INTERFACE_MODE_SGMII:
|
2022-06-23 20:25:25 +08:00
|
|
|
case PHY_INTERFACE_MODE_QSGMII:
|
2021-11-19 23:58:09 +08:00
|
|
|
return 0x0001;
|
2020-03-17 22:52:36 +08:00
|
|
|
default:
|
|
|
|
|
/* Nothing to do for other modes */
|
2021-11-19 23:58:09 +08:00
|
|
|
return -EINVAL;
|
2020-03-17 22:52:36 +08:00
|
|
|
}
|
|
|
|
|
}
|
2021-11-19 23:58:09 +08:00
|
|
|
EXPORT_SYMBOL_GPL(phylink_mii_c22_pcs_encode_advertisement);
|
2020-03-17 22:52:36 +08:00
|
|
|
|
2020-07-21 19:04:51 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_mii_c22_pcs_config() - configure clause 22 PCS
|
|
|
|
|
* @pcs: a pointer to a &struct mdio_device.
|
|
|
|
|
* @interface: the PHY interface mode being configured
|
|
|
|
|
* @advertising: the ethtool advertisement mask
|
2023-06-16 20:06:32 +08:00
|
|
|
* @neg_mode: PCS negotiation mode
|
2020-07-21 19:04:51 +08:00
|
|
|
*
|
|
|
|
|
* Configure a Clause 22 PCS PHY with the appropriate negotiation
|
|
|
|
|
* parameters for the @mode, @interface and @advertising parameters.
|
|
|
|
|
* Returns negative error number on failure, zero if the advertisement
|
|
|
|
|
* has not changed, or positive if there is a change.
|
|
|
|
|
*/
|
2023-06-16 20:06:32 +08:00
|
|
|
int phylink_mii_c22_pcs_config(struct mdio_device *pcs,
|
2020-07-21 19:04:51 +08:00
|
|
|
phy_interface_t interface,
|
2023-06-16 20:06:32 +08:00
|
|
|
const unsigned long *advertising,
|
|
|
|
|
unsigned int neg_mode)
|
2020-07-21 19:04:51 +08:00
|
|
|
{
|
2021-11-19 23:58:09 +08:00
|
|
|
bool changed = 0;
|
2020-07-21 19:04:51 +08:00
|
|
|
u16 bmcr;
|
2021-11-19 23:58:09 +08:00
|
|
|
int ret, adv;
|
2020-07-21 19:04:51 +08:00
|
|
|
|
2021-11-19 23:58:09 +08:00
|
|
|
adv = phylink_mii_c22_pcs_encode_advertisement(interface, advertising);
|
|
|
|
|
if (adv >= 0) {
|
|
|
|
|
ret = mdiobus_modify_changed(pcs->bus, pcs->addr,
|
|
|
|
|
MII_ADVERTISE, 0xffff, adv);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
changed = ret;
|
|
|
|
|
}
|
2020-07-21 19:04:51 +08:00
|
|
|
|
2023-06-16 20:06:27 +08:00
|
|
|
if (neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED)
|
2021-10-19 18:24:50 +08:00
|
|
|
bmcr = BMCR_ANENABLE;
|
|
|
|
|
else
|
|
|
|
|
bmcr = 0;
|
|
|
|
|
|
2023-06-16 20:06:27 +08:00
|
|
|
/* Configure the inband state. Ensure ISOLATE bit is disabled */
|
2021-10-22 23:59:13 +08:00
|
|
|
ret = mdiodev_modify(pcs, MII_BMCR, BMCR_ANENABLE | BMCR_ISOLATE, bmcr);
|
2020-07-21 19:04:51 +08:00
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
2021-11-19 23:58:09 +08:00
|
|
|
return changed;
|
2020-07-21 19:04:51 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_mii_c22_pcs_config);
|
|
|
|
|
|
2020-03-17 22:52:36 +08:00
|
|
|
/**
|
|
|
|
|
* phylink_mii_c22_pcs_an_restart() - restart 802.3z autonegotiation
|
|
|
|
|
* @pcs: a pointer to a &struct mdio_device.
|
|
|
|
|
*
|
|
|
|
|
* Helper for MAC PCS supporting the 802.3 clause 22 register set for
|
|
|
|
|
* clause 37 negotiation.
|
|
|
|
|
*
|
|
|
|
|
* Restart the clause 37 negotiation with the link partner. This is
|
2023-07-23 04:32:59 +08:00
|
|
|
* suitable to be directly plugged into the pcs_get_state() member
|
|
|
|
|
* of the struct phylink_pcs_ops structure.
|
2020-03-17 22:52:36 +08:00
|
|
|
*/
|
|
|
|
|
void phylink_mii_c22_pcs_an_restart(struct mdio_device *pcs)
|
|
|
|
|
{
|
2021-10-22 23:59:13 +08:00
|
|
|
int val = mdiodev_read(pcs, MII_BMCR);
|
2020-03-17 22:52:36 +08:00
|
|
|
|
|
|
|
|
if (val >= 0) {
|
|
|
|
|
val |= BMCR_ANRESTART;
|
|
|
|
|
|
2021-10-22 23:59:13 +08:00
|
|
|
mdiodev_write(pcs, MII_BMCR, val);
|
2020-03-17 22:52:36 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_mii_c22_pcs_an_restart);
|
|
|
|
|
|
2020-03-17 22:52:41 +08:00
|
|
|
void phylink_mii_c45_pcs_get_state(struct mdio_device *pcs,
|
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
|
{
|
|
|
|
|
struct mii_bus *bus = pcs->bus;
|
|
|
|
|
int addr = pcs->addr;
|
|
|
|
|
int stat;
|
|
|
|
|
|
2020-05-26 23:29:36 +08:00
|
|
|
stat = mdiobus_c45_read(bus, addr, MDIO_MMD_PCS, MDIO_STAT1);
|
2020-03-17 22:52:41 +08:00
|
|
|
if (stat < 0) {
|
|
|
|
|
state->link = false;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
state->link = !!(stat & MDIO_STAT1_LSTATUS);
|
|
|
|
|
if (!state->link)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
switch (state->interface) {
|
|
|
|
|
case PHY_INTERFACE_MODE_10GBASER:
|
|
|
|
|
state->speed = SPEED_10000;
|
|
|
|
|
state->duplex = DUPLEX_FULL;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_mii_c45_pcs_get_state);
|
|
|
|
|
|
2022-09-30 22:21:03 +08:00
|
|
|
static int __init phylink_init(void)
|
|
|
|
|
{
|
|
|
|
|
for (int i = 0; i < ARRAY_SIZE(phylink_sfp_interface_preference); ++i)
|
|
|
|
|
__set_bit(phylink_sfp_interface_preference[i],
|
|
|
|
|
phylink_sfp_interfaces);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
module_init(phylink_init);
|
|
|
|
|
|
2019-01-22 02:10:19 +08:00
|
|
|
MODULE_LICENSE("GPL v2");
|
2023-10-29 02:44:57 +08:00
|
|
|
MODULE_DESCRIPTION("phylink models the MAC to optional PHY connection");
|
