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
|
|
|
|
*/
|
|
|
|
#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,
|
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;
|
|
|
|
const struct phylink_mac_ops *ops;
|
2019-05-29 01:38:12 +08:00
|
|
|
struct phylink_config *config;
|
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;
|
|
|
|
|
|
|
|
bool mac_link_dropped;
|
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;
|
|
|
|
__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";
|
|
|
|
}
|
|
|
|
|
|
|
|
static int phylink_validate(struct phylink *pl, unsigned long *supported,
|
|
|
|
struct phylink_link_state *state)
|
|
|
|
{
|
2019-05-29 01:38:12 +08:00
|
|
|
pl->ops->validate(pl->config, 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
|
|
|
|
|
|
|
return phylink_is_empty_linkmode(supported) ? -EINVAL : 0;
|
|
|
|
}
|
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
static int phylink_parse_fixedlink(struct phylink *pl,
|
|
|
|
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;
|
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
|
|
|
|
* 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);
|
|
|
|
|
|
|
|
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);
|
2019-07-27 17:40:11 +08:00
|
|
|
phylink_set(pl->supported, Pause);
|
|
|
|
phylink_set(pl->supported, Asym_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
|
|
|
if (s) {
|
|
|
|
__set_bit(s->bit, pl->supported);
|
|
|
|
} 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;
|
|
|
|
}
|
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
static int phylink_parse_mode(struct phylink *pl, 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
|
|
|
|
2017-12-01 18:25:09 +08:00
|
|
|
if (fwnode_property_read_string(fwnode, "managed", &managed) == 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
|
|
|
strcmp(managed, "in-band-status") == 0) {
|
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);
|
|
|
|
pl->link_config.an_enabled = true;
|
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:
|
2020-01-06 09:34:10 +08:00
|
|
|
case PHY_INTERFACE_MODE_QSGMII:
|
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;
|
|
|
|
|
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-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);
|
|
|
|
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;
|
|
|
|
|
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 */
|
|
|
|
if (!state->an_enabled)
|
|
|
|
state->pause &= ~MLO_PAUSE_AN;
|
|
|
|
|
|
|
|
/* Manual configuration of pause modes */
|
|
|
|
if (!(pl->link_config.pause & MLO_PAUSE_AN))
|
|
|
|
state->pause = pl->link_config.pause;
|
|
|
|
}
|
|
|
|
|
2020-02-15 23:49:53 +08:00
|
|
|
static void phylink_resolve_flow(struct phylink_link_state *state)
|
|
|
|
{
|
|
|
|
bool tx_pause, rx_pause;
|
|
|
|
|
|
|
|
state->pause = MLO_PAUSE_NONE;
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_dbg(pl,
|
|
|
|
"%s: mode=%s/%s/%s/%s adv=%*pb pause=%02x link=%u an=%u\n",
|
2019-12-11 18:56:35 +08:00
|
|
|
__func__, phylink_an_mode_str(pl->cur_link_an_mode),
|
2019-05-29 01:38:14 +08:00
|
|
|
phy_modes(state->interface),
|
|
|
|
phy_speed_to_str(state->speed),
|
|
|
|
phy_duplex_to_str(state->duplex),
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, state->advertising,
|
|
|
|
state->pause, state->link, state->an_enabled);
|
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
|
|
|
pl->ops->mac_config(pl->config, pl->cur_link_an_mode, 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
|
|
|
}
|
|
|
|
|
2019-02-11 19:46:01 +08:00
|
|
|
static void phylink_mac_config_up(struct phylink *pl,
|
|
|
|
const struct phylink_link_state *state)
|
|
|
|
{
|
|
|
|
if (state->link)
|
|
|
|
phylink_mac_config(pl, 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
|
|
|
static void phylink_mac_an_restart(struct phylink *pl)
|
|
|
|
{
|
|
|
|
if (pl->link_config.an_enabled &&
|
2017-12-01 18:24:16 +08:00
|
|
|
phy_interface_mode_is_8023z(pl->link_config.interface))
|
2019-05-29 01:38:12 +08:00
|
|
|
pl->ops->mac_an_restart(pl->config);
|
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-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;
|
|
|
|
state->an_enabled = pl->link_config.an_enabled;
|
2019-02-27 02:29:22 +08:00
|
|
|
state->speed = SPEED_UNKNOWN;
|
|
|
|
state->duplex = DUPLEX_UNKNOWN;
|
|
|
|
state->pause = MLO_PAUSE_NONE;
|
|
|
|
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;
|
|
|
|
|
2019-11-21 08:36:22 +08:00
|
|
|
pl->ops->mac_pcs_get_state(pl->config, 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 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;
|
2017-12-13 08:00:28 +08:00
|
|
|
if (pl->get_fixed_state)
|
|
|
|
pl->get_fixed_state(pl->netdev, state);
|
|
|
|
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
|
|
|
|
2020-02-15 23:49:53 +08:00
|
|
|
phylink_resolve_flow(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-02-15 23:50:03 +08:00
|
|
|
static void phylink_mac_initial_config(struct phylink *pl)
|
|
|
|
{
|
|
|
|
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);
|
|
|
|
phylink_mac_config(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
|
|
|
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";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-29 01:38:11 +08:00
|
|
|
static void phylink_mac_link_up(struct phylink *pl,
|
|
|
|
struct phylink_link_state link_state)
|
|
|
|
{
|
|
|
|
struct net_device *ndev = pl->netdev;
|
|
|
|
|
2019-06-01 01:49:43 +08:00
|
|
|
pl->cur_interface = link_state.interface;
|
2019-12-11 18:56:35 +08:00
|
|
|
pl->ops->mac_link_up(pl->config, pl->cur_link_an_mode,
|
2019-12-13 18:06:30 +08:00
|
|
|
pl->cur_interface, pl->phydev);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
static void phylink_mac_link_down(struct phylink *pl)
|
|
|
|
{
|
|
|
|
struct net_device *ndev = pl->netdev;
|
|
|
|
|
2019-05-29 01:38:13 +08:00
|
|
|
if (ndev)
|
|
|
|
netif_carrier_off(ndev);
|
2019-12-11 18:56:35 +08:00
|
|
|
pl->ops->mac_link_down(pl->config, pl->cur_link_an_mode,
|
2019-06-01 01:49:43 +08:00
|
|
|
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;
|
2019-05-29 01:38:13 +08:00
|
|
|
int link_changed;
|
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);
|
|
|
|
if (pl->phylink_disable_state) {
|
|
|
|
pl->mac_link_dropped = false;
|
|
|
|
link_state.link = false;
|
|
|
|
} else if (pl->mac_link_dropped) {
|
|
|
|
link_state.link = false;
|
|
|
|
} 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);
|
2019-02-11 19:46:01 +08:00
|
|
|
phylink_mac_config_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
|
|
|
break;
|
|
|
|
|
|
|
|
case MLO_AN_FIXED:
|
|
|
|
phylink_get_fixed_state(pl, &link_state);
|
2019-02-11 19:46:01 +08:00
|
|
|
phylink_mac_config_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
|
|
|
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
|
|
|
|
|
|
|
/* If we have a phy, the "up" state is the union of
|
|
|
|
* both the PHY and the MAC */
|
|
|
|
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) {
|
|
|
|
link_state.interface = pl->phy_state.interface;
|
|
|
|
|
|
|
|
/* If we have a PHY, we need to update with
|
2020-02-15 23:49:48 +08:00
|
|
|
* the PHY flow control bits. */
|
|
|
|
link_state.pause = pl->phy_state.pause;
|
2020-02-15 23:49:43 +08:00
|
|
|
phylink_apply_manual_flow(pl, &link_state);
|
2019-05-20 23:07:20 +08:00
|
|
|
phylink_mac_config(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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-29 01:38:13 +08:00
|
|
|
if (pl->netdev)
|
|
|
|
link_changed = (link_state.link != netif_carrier_ok(ndev));
|
|
|
|
else
|
|
|
|
link_changed = (link_state.link != pl->old_link_state);
|
|
|
|
|
|
|
|
if (link_changed) {
|
|
|
|
pl->old_link_state = link_state.link;
|
2019-05-29 01:38:11 +08:00
|
|
|
if (!link_state.link)
|
|
|
|
phylink_mac_link_down(pl);
|
|
|
|
else
|
|
|
|
phylink_mac_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
|
|
|
}
|
|
|
|
if (!link_state.link && pl->mac_link_dropped) {
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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,
|
|
|
|
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)) {
|
|
|
|
ret = PTR_ERR(bus);
|
|
|
|
phylink_err(pl, "unable to attach SFP bus: %d\n", ret);
|
2017-12-01 18:25:09 +08:00
|
|
|
return ret;
|
|
|
|
}
|
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
|
|
|
|
* @ops: a pointer to a &struct phylink_mac_ops for the MAC.
|
|
|
|
*
|
|
|
|
* 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,
|
2017-12-01 18:25:09 +08:00
|
|
|
struct fwnode_handle *fwnode,
|
2017-10-31 12:42:57 +08:00
|
|
|
phy_interface_t iface,
|
|
|
|
const struct phylink_mac_ops *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
|
|
|
{
|
|
|
|
struct phylink *pl;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
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);
|
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);
|
|
|
|
}
|
|
|
|
|
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;
|
2017-12-21 07:21:34 +08:00
|
|
|
pl->link_config.an_enabled = 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->ops = ops;
|
|
|
|
__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);
|
|
|
|
|
2017-11-02 19:14:48 +08:00
|
|
|
static void phylink_phy_change(struct phy_device *phydev, bool up,
|
|
|
|
bool do_carrier)
|
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;
|
|
|
|
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);
|
|
|
|
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_dbg(pl, "phy link %s %s/%s/%s\n", up ? "up" : "down",
|
|
|
|
phy_modes(phydev->interface),
|
|
|
|
phy_speed_to_str(phydev->speed),
|
|
|
|
phy_duplex_to_str(phydev->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
|
|
|
}
|
|
|
|
|
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
|
|
|
|
|
|
|
/* Clause 45 PHYs switch their Serdes lane between several different
|
|
|
|
* modes, normally 10GBASE-R, SGMII. Some use 2500BASE-X for 2.5G
|
|
|
|
* speeds. We really need to know which interface modes the PHY and
|
|
|
|
* MAC supports to properly work out which linkmodes can be supported.
|
|
|
|
*/
|
|
|
|
if (phy->is_c45 &&
|
|
|
|
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);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
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;
|
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,
|
|
|
|
"phy: setting supported %*pb advertising %*pb\n",
|
|
|
|
__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
|
|
|
|
|
|
|
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 &&
|
2018-10-04 00:04:49 +08:00
|
|
|
phy_interface_mode_is_8023z(interface))))
|
|
|
|
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
|
|
|
{
|
|
|
|
struct device_node *phy_node;
|
|
|
|
struct phy_device *phy_dev;
|
|
|
|
int ret;
|
|
|
|
|
2017-12-01 18:24:21 +08:00
|
|
|
/* Fixed links and 802.3z are handled without needing a PHY */
|
2019-12-11 18:56:35 +08:00
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_FIXED ||
|
|
|
|
(pl->cfg_link_an_mode == MLO_AN_INBAND &&
|
2017-12-01 18:24:26 +08:00
|
|
|
phy_interface_mode_is_8023z(pl->link_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 0;
|
|
|
|
|
|
|
|
phy_node = of_parse_phandle(dn, "phy-handle", 0);
|
|
|
|
if (!phy_node)
|
|
|
|
phy_node = of_parse_phandle(dn, "phy", 0);
|
|
|
|
if (!phy_node)
|
|
|
|
phy_node = of_parse_phandle(dn, "phy-device", 0);
|
|
|
|
|
|
|
|
if (!phy_node) {
|
2019-12-11 18:56:35 +08:00
|
|
|
if (pl->cfg_link_an_mode == MLO_AN_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
|
|
|
return -ENODEV;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-13 01:16:12 +08:00
|
|
|
phy_dev = of_phy_find_device(phy_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
|
|
|
/* We're done with the phy_node handle */
|
|
|
|
of_node_put(phy_node);
|
|
|
|
if (!phy_dev)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2019-12-13 01:16:12 +08:00
|
|
|
ret = phy_attach_direct(pl->netdev, phy_dev, flags,
|
|
|
|
pl->link_interface);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2019-12-11 18:56:30 +08:00
|
|
|
ret = phylink_bringup_phy(pl, phy_dev, 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
|
|
|
if (ret)
|
|
|
|
phy_detach(phy_dev);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_of_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);
|
|
|
|
|
2017-12-13 08:00:28 +08:00
|
|
|
/**
|
|
|
|
* phylink_fixed_state_cb() - allow setting a fixed link callback
|
|
|
|
* @pl: a pointer to a &struct phylink returned from phylink_create()
|
|
|
|
* @cb: callback to execute to determine the fixed link state.
|
|
|
|
*
|
|
|
|
* The MAC driver should call this driver when the state of its link
|
|
|
|
* can be determined through e.g: an out of band MMIO register.
|
|
|
|
*/
|
|
|
|
int phylink_fixed_state_cb(struct phylink *pl,
|
|
|
|
void (*cb)(struct net_device *dev,
|
|
|
|
struct phylink_link_state *state))
|
|
|
|
{
|
|
|
|
/* It does not make sense to let the link be overriden unless we use
|
|
|
|
* MLO_AN_FIXED
|
|
|
|
*/
|
2019-12-11 18:56:35 +08:00
|
|
|
if (pl->cfg_link_an_mode != MLO_AN_FIXED)
|
2017-12-13 08:00:28 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
pl->get_fixed_state = cb;
|
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_fixed_state_cb);
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
if (!up)
|
|
|
|
pl->mac_link_dropped = true;
|
|
|
|
phylink_run_resolve(pl);
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_dbg(pl, "mac link %s\n", up ? "up" : "down");
|
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);
|
|
|
|
|
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)
|
|
|
|
{
|
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
|
|
|
|
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.
|
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:50:03 +08:00
|
|
|
phylink_mac_initial_config(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
|
|
|
|
2017-12-01 18:24:42 +08:00
|
|
|
/* Restart autonegotiation if using 802.3z to ensure that the link
|
|
|
|
* parameters are properly negotiated. This is necessary for DSA
|
|
|
|
* switches using 802.3z negotiation to ensure they see our modes.
|
|
|
|
*/
|
|
|
|
phylink_mac_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
|
|
|
clear_bit(PHYLINK_DISABLE_STOPPED, &pl->phylink_disable_state);
|
|
|
|
phylink_run_resolve(pl);
|
|
|
|
|
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)
|
|
|
|
mod_timer(&pl->link_poll, jiffies + HZ);
|
|
|
|
}
|
2020-01-06 09:34:11 +08:00
|
|
|
if ((pl->cfg_link_an_mode == MLO_AN_FIXED && pl->get_fixed_state) ||
|
|
|
|
pl->config->pcs_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.
|
|
|
|
*/
|
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);
|
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);
|
|
|
|
|
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);
|
|
|
|
kset->base.speed = state->speed;
|
|
|
|
kset->base.duplex = state->duplex;
|
|
|
|
kset->base.autoneg = state->an_enabled ? AUTONEG_ENABLE :
|
|
|
|
AUTONEG_DISABLE;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
|
|
|
if (pl->phydev) {
|
|
|
|
phy_ethtool_ksettings_get(pl->phydev, kset);
|
|
|
|
} else {
|
|
|
|
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 ethtool_link_ksettings our_kset;
|
|
|
|
struct phylink_link_state config;
|
|
|
|
int ret;
|
|
|
|
|
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 (kset->base.autoneg != AUTONEG_DISABLE &&
|
|
|
|
kset->base.autoneg != AUTONEG_ENABLE)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-06-02 22:12:54 +08:00
|
|
|
linkmode_copy(support, 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
|
|
|
config = pl->link_config;
|
|
|
|
|
2018-03-01 18:23:03 +08:00
|
|
|
/* Mask out unsupported advertisements */
|
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(config.advertising, kset->link_modes.advertising,
|
2019-06-02 22:12:54 +08:00
|
|
|
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
|
|
|
|
|
|
|
/* FIXME: should we reject autoneg if phy/mac does not support it? */
|
|
|
|
if (kset->base.autoneg == AUTONEG_DISABLE) {
|
|
|
|
const struct phy_setting *s;
|
|
|
|
|
|
|
|
/* Autonegotiation disabled, select a suitable speed and
|
|
|
|
* duplex.
|
|
|
|
*/
|
|
|
|
s = phy_lookup_setting(kset->base.speed, kset->base.duplex,
|
2019-06-02 22:12:54 +08:00
|
|
|
support, 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;
|
|
|
|
|
|
|
|
/* If we have a fixed link (as specified by firmware), refuse
|
|
|
|
* to change link parameters.
|
|
|
|
*/
|
2019-12-11 18:56:35 +08:00
|
|
|
if (pl->cur_link_an_mode == MLO_AN_FIXED &&
|
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->speed != pl->link_config.speed ||
|
|
|
|
s->duplex != pl->link_config.duplex))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
config.speed = s->speed;
|
|
|
|
config.duplex = s->duplex;
|
|
|
|
config.an_enabled = false;
|
|
|
|
|
|
|
|
__clear_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, config.advertising);
|
|
|
|
} else {
|
|
|
|
/* If we have a fixed link, refuse to enable autonegotiation */
|
2019-12-11 18:56:35 +08:00
|
|
|
if (pl->cur_link_an_mode == MLO_AN_FIXED)
|
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;
|
|
|
|
|
|
|
|
config.speed = SPEED_UNKNOWN;
|
|
|
|
config.duplex = DUPLEX_UNKNOWN;
|
|
|
|
config.an_enabled = true;
|
|
|
|
|
|
|
|
__set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, config.advertising);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pl->phydev) {
|
2019-12-14 02:22:02 +08:00
|
|
|
/* If we have a PHY, we process the kset change via phylib.
|
|
|
|
* phylib will call our link state function if the PHY
|
|
|
|
* parameters have changed, which will trigger a resolve
|
|
|
|
* and update the MAC configuration.
|
|
|
|
*/
|
|
|
|
our_kset = *kset;
|
|
|
|
linkmode_copy(our_kset.link_modes.advertising,
|
|
|
|
config.advertising);
|
|
|
|
our_kset.base.speed = config.speed;
|
|
|
|
our_kset.base.duplex = config.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
|
|
|
ret = phy_ethtool_ksettings_set(pl->phydev, &our_kset);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2019-12-14 02:22:02 +08:00
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
/* Save the new configuration */
|
|
|
|
linkmode_copy(pl->link_config.advertising,
|
|
|
|
our_kset.link_modes.advertising);
|
|
|
|
pl->link_config.interface = config.interface;
|
|
|
|
pl->link_config.speed = our_kset.base.speed;
|
|
|
|
pl->link_config.duplex = our_kset.base.duplex;
|
|
|
|
pl->link_config.an_enabled = our_kset.base.autoneg !=
|
|
|
|
AUTONEG_DISABLE;
|
|
|
|
mutex_unlock(&pl->state_mutex);
|
|
|
|
} else {
|
|
|
|
/* For a fixed link, this isn't able to change any parameters,
|
|
|
|
* which just leaves inband mode.
|
|
|
|
*/
|
|
|
|
if (phylink_validate(pl, support, &config))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* If autonegotiation is enabled, we must have an advertisement */
|
|
|
|
if (config.an_enabled &&
|
|
|
|
phylink_is_empty_linkmode(config.advertising))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mutex_lock(&pl->state_mutex);
|
|
|
|
linkmode_copy(pl->link_config.advertising, config.advertising);
|
|
|
|
pl->link_config.interface = config.interface;
|
|
|
|
pl->link_config.speed = config.speed;
|
|
|
|
pl->link_config.duplex = config.duplex;
|
|
|
|
pl->link_config.an_enabled = kset->base.autoneg !=
|
|
|
|
AUTONEG_DISABLE;
|
|
|
|
|
|
|
|
if (pl->cur_link_an_mode == MLO_AN_INBAND &&
|
|
|
|
!test_bit(PHYLINK_DISABLE_STOPPED,
|
|
|
|
&pl->phylink_disable_state)) {
|
|
|
|
/* If in 802.3z mode, this updates the advertisement.
|
|
|
|
*
|
|
|
|
* If we are in SGMII mode without a PHY, there is no
|
|
|
|
* advertisement; the only thing we have is the pause
|
|
|
|
* modes which can only come from a PHY.
|
|
|
|
*/
|
|
|
|
phylink_mac_config(pl, &pl->link_config);
|
|
|
|
phylink_mac_an_restart(pl);
|
|
|
|
}
|
|
|
|
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);
|
|
|
|
phylink_mac_an_restart(pl);
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
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) &&
|
|
|
|
!pause->autoneg && pause->rx_pause != pause->tx_pause)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2020-02-15 23:49:58 +08:00
|
|
|
mutex_lock(&pl->state_mutex);
|
2020-02-15 23:49:53 +08:00
|
|
|
config->pause = 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)
|
|
|
|
config->pause |= MLO_PAUSE_AN;
|
|
|
|
if (pause->rx_pause)
|
|
|
|
config->pause |= MLO_PAUSE_RX;
|
|
|
|
if (pause->tx_pause)
|
|
|
|
config->pause |= MLO_PAUSE_TX;
|
|
|
|
|
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);
|
|
|
|
|
2019-11-20 01:28:14 +08:00
|
|
|
/* If we have a PHY, phylib will call our link state function if the
|
|
|
|
* mode has changed, which will trigger a resolve and update the MAC
|
|
|
|
* configuration.
|
|
|
|
*/
|
|
|
|
if (pl->phydev) {
|
|
|
|
phy_set_asym_pause(pl->phydev, pause->rx_pause,
|
|
|
|
pause->tx_pause);
|
|
|
|
} else if (!test_bit(PHYLINK_DISABLE_STOPPED,
|
|
|
|
&pl->phylink_disable_state)) {
|
2020-02-15 23:49:37 +08:00
|
|
|
phylink_mac_config(pl, &pl->link_config);
|
|
|
|
phylink_mac_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
|
|
|
}
|
2020-02-15 23:49:58 +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
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_ethtool_set_pauseparam);
|
|
|
|
|
2017-12-01 18:24:47 +08:00
|
|
|
/**
|
|
|
|
* phylink_ethtool_get_eee_err() - read the energy efficient ethernet error
|
|
|
|
* 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);
|
|
|
|
devad = MII_ADDR_C45 | devad << 16 | reg;
|
|
|
|
} else if (phydev->is_c45) {
|
|
|
|
switch (reg) {
|
|
|
|
case MII_BMCR:
|
|
|
|
case MII_BMSR:
|
|
|
|
case MII_PHYSID1:
|
|
|
|
case MII_PHYSID2:
|
|
|
|
devad = __ffs(phydev->c45_ids.devices_in_package);
|
|
|
|
break;
|
|
|
|
case MII_ADVERTISE:
|
|
|
|
case MII_LPA:
|
|
|
|
if (!(phydev->c45_ids.devices_in_package & MDIO_DEVS_AN))
|
|
|
|
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;
|
|
|
|
devad = MII_ADDR_C45 | devad << 16 | reg;
|
|
|
|
} else {
|
|
|
|
prtad = phy_id;
|
|
|
|
devad = reg;
|
|
|
|
}
|
|
|
|
return mdiobus_read(pl->phydev->mdio.bus, prtad, devad);
|
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
|
|
|
devad = MII_ADDR_C45 | devad << 16 | reg;
|
|
|
|
} else if (phydev->is_c45) {
|
|
|
|
switch (reg) {
|
|
|
|
case MII_BMCR:
|
|
|
|
case MII_BMSR:
|
|
|
|
case MII_PHYSID1:
|
|
|
|
case MII_PHYSID2:
|
|
|
|
devad = __ffs(phydev->c45_ids.devices_in_package);
|
|
|
|
break;
|
|
|
|
case MII_ADVERTISE:
|
|
|
|
case MII_LPA:
|
|
|
|
if (!(phydev->c45_ids.devices_in_package & MDIO_DEVS_AN))
|
|
|
|
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;
|
|
|
|
devad = MII_ADDR_C45 | devad << 16 | reg;
|
|
|
|
} else {
|
|
|
|
prtad = phy_id;
|
|
|
|
devad = reg;
|
|
|
|
}
|
|
|
|
|
|
|
|
return mdiobus_write(phydev->mdio.bus, prtad, devad, val);
|
|
|
|
}
|
|
|
|
|
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;
|
2018-01-06 01:23:45 +08:00
|
|
|
/* fall through */
|
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;
|
2018-01-06 01:23:45 +08:00
|
|
|
/* fall through */
|
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);
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2019-12-11 18:56:45 +08:00
|
|
|
static int phylink_sfp_config(struct phylink *pl, u8 mode,
|
2019-12-11 18:56:40 +08:00
|
|
|
const unsigned long *supported,
|
|
|
|
const unsigned long *advertising)
|
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;
|
|
|
|
bool changed;
|
2019-12-11 18:56:40 +08:00
|
|
|
int ret;
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2019-12-11 18:56:40 +08:00
|
|
|
linkmode_copy(support, supported);
|
2017-07-25 22:03:18 +08:00
|
|
|
|
|
|
|
memset(&config, 0, sizeof(config));
|
2019-12-11 18:56:40 +08:00
|
|
|
linkmode_copy(config.advertising, 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;
|
|
|
|
config.an_enabled = pl->link_config.an_enabled;
|
|
|
|
|
|
|
|
/* 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) {
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_err(pl, "validation with support %*pb failed: %d\n",
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, support, 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) {
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_err(pl, "validation of %s/%s with support %*pb failed: %d\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),
|
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, support, ret);
|
2017-07-25 22:03:18 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_dbg(pl, "requesting link mode %s/%s with support %*pb\n",
|
2019-12-11 18:56:40 +08:00
|
|
|
phylink_an_mode_str(mode), phy_modes(config.interface),
|
2019-05-29 01:38:14 +08:00
|
|
|
__ETHTOOL_LINK_MODE_MASK_NBITS, support);
|
2017-07-25 22:03:18 +08:00
|
|
|
|
2017-12-01 18:24:26 +08:00
|
|
|
if (phy_interface_mode_is_8023z(iface) && pl->phydev)
|
2017-07-25 22:03:18 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2019-10-15 18:28:46 +08:00
|
|
|
changed = !linkmode_equal(pl->supported, support);
|
2017-07-25 22:03:18 +08:00
|
|
|
if (changed) {
|
|
|
|
linkmode_copy(pl->supported, support);
|
|
|
|
linkmode_copy(pl->link_config.advertising, config.advertising);
|
|
|
|
}
|
|
|
|
|
2019-12-11 18:56:40 +08:00
|
|
|
if (pl->cur_link_an_mode != mode ||
|
2017-07-25 22:03:18 +08:00
|
|
|
pl->link_config.interface != config.interface) {
|
|
|
|
pl->link_config.interface = config.interface;
|
2019-12-11 18:56:40 +08:00
|
|
|
pl->cur_link_an_mode = mode;
|
2017-07-25 22:03:18 +08:00
|
|
|
|
|
|
|
changed = true;
|
|
|
|
|
2019-05-29 01:38:14 +08:00
|
|
|
phylink_info(pl, "switched to %s/%s link mode\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));
|
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
|
|
|
|
|
|
|
if (changed && !test_bit(PHYLINK_DISABLE_STOPPED,
|
|
|
|
&pl->phylink_disable_state))
|
2020-02-15 23:50:03 +08:00
|
|
|
phylink_mac_initial_config(pl);
|
2017-07-25 22:03:18 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
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;
|
2019-12-11 18:56:45 +08:00
|
|
|
unsigned long *support = pl->sfp_support;
|
2019-12-11 18:56:40 +08:00
|
|
|
|
|
|
|
ASSERT_RTNL();
|
|
|
|
|
2019-12-11 18:56:45 +08:00
|
|
|
linkmode_zero(support);
|
2019-12-11 18:56:40 +08:00
|
|
|
sfp_parse_support(pl->sfp_bus, id, support);
|
2019-12-11 18:56:45 +08:00
|
|
|
pl->sfp_port = sfp_parse_port(pl->sfp_bus, id, 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;
|
|
|
|
|
|
|
|
return phylink_sfp_config(pl, MLO_AN_INBAND, support, support);
|
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;
|
|
|
|
|
|
|
|
return phylink_sfp_config(pl, MLO_AN_INBAND,
|
|
|
|
pl->sfp_support, pl->sfp_support);
|
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
|
|
|
|
|
|
|
clear_bit(PHYLINK_DISABLE_LINK, &pl->phylink_disable_state);
|
|
|
|
phylink_run_resolve(pl);
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
return phy->is_c45 &&
|
|
|
|
(phy->c45_ids.device_ids[1] & 0xfffffff0) == 0xae025150;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2019-12-11 18:56:45 +08:00
|
|
|
/* Do the initial configuration */
|
2019-12-11 18:56:50 +08:00
|
|
|
ret = phylink_sfp_config(pl, mode, phy->supported, phy->advertising);
|
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 */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* phylink_helper_basex_speed() - 1000BaseX/2500BaseX helper
|
|
|
|
* @state: a pointer to a &struct phylink_link_state
|
|
|
|
*
|
|
|
|
* Inspect the interface mode, advertising mask or forced speed and
|
|
|
|
* decide whether to run at 2.5Gbit or 1Gbit appropriately, switching
|
|
|
|
* the interface mode to suit. @state->interface is appropriately
|
|
|
|
* updated, and the advertising mask has the "other" baseX_Full flag
|
|
|
|
* cleared.
|
|
|
|
*/
|
|
|
|
void phylink_helper_basex_speed(struct phylink_link_state *state)
|
|
|
|
{
|
|
|
|
if (phy_interface_mode_is_8023z(state->interface)) {
|
|
|
|
bool want_2500 = state->an_enabled ?
|
|
|
|
phylink_test(state->advertising, 2500baseX_Full) :
|
|
|
|
state->speed == SPEED_2500;
|
|
|
|
|
|
|
|
if (want_2500) {
|
|
|
|
phylink_clear(state->advertising, 1000baseX_Full);
|
|
|
|
state->interface = PHY_INTERFACE_MODE_2500BASEX;
|
|
|
|
} else {
|
|
|
|
phylink_clear(state->advertising, 2500baseX_Full);
|
|
|
|
state->interface = PHY_INTERFACE_MODE_1000BASEX;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(phylink_helper_basex_speed);
|
|
|
|
|
2019-01-22 02:10:19 +08:00
|
|
|
MODULE_LICENSE("GPL v2");
|