2020-03-09 08:36:26 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
/*
|
|
|
|
* Copyright (c) 2020 Synopsys, Inc. and/or its affiliates.
|
|
|
|
* Synopsys DesignWare XPCS helpers
|
|
|
|
*/
|
|
|
|
|
2020-08-27 02:00:28 +00:00
|
|
|
#ifndef __LINUX_PCS_XPCS_H
|
|
|
|
#define __LINUX_PCS_XPCS_H
|
2020-03-09 08:36:26 +00:00
|
|
|
|
|
|
|
#include <linux/phy.h>
|
|
|
|
#include <linux/phylink.h>
|
|
|
|
|
2021-06-11 20:05:25 +00:00
|
|
|
#define NXP_SJA1105_XPCS_ID 0x00000010
|
2021-06-11 20:05:26 +00:00
|
|
|
#define NXP_SJA1110_XPCS_ID 0x00000020
|
2021-06-11 20:05:25 +00:00
|
|
|
|
2021-03-15 05:27:06 +00:00
|
|
|
/* AN mode */
|
|
|
|
#define DW_AN_C73 1
|
2021-03-15 05:27:07 +00:00
|
|
|
#define DW_AN_C37_SGMII 2
|
2021-06-08 03:51:57 +00:00
|
|
|
#define DW_2500BASEX 3
|
2021-03-15 05:27:06 +00:00
|
|
|
|
net: pcs: xpcs: make the checks related to the PHY interface mode stateless
The operating mode of the driver is currently to populate its
struct mdio_xpcs_args::supported and struct mdio_xpcs_args::an_mode
statically in xpcs_probe(), based on the passed phy_interface_t,
and work with those.
However this is not the operation that phylink expects from a PCS
driver, because the port might be attached to an SFP cage that triggers
changes of the phy_interface_t dynamically as one SFP module is
unpluggged and another is plugged.
To migrate towards that model, the struct mdio_xpcs_args should not
cache anything related to the phy_interface_t, but just look up the
statically defined, const struct xpcs_compat structure corresponding to
the detected PCS OUI/model number.
So we delete the "supported" and "an_mode" members of struct
mdio_xpcs_args, and add the "id" structure there (since the ID is not
expected to change at runtime).
Since xpcs->supported is used deep in the code in _xpcs_config_aneg_c73(),
we need to modify some function headers to pass the xpcs_compat from all
callers. In turn, the xpcs_compat is always supplied externally to the
xpcs module:
- Most of the time by phylink
- In xpcs_probe() it is needed because xpcs_soft_reset() writes to
MDIO_MMD_PCS or to MDIO_MMD_VEND2 depending on whether an_mode is clause
37 or clause 73. In order to not introduce functional changes related
to when the soft reset is issued, we continue to require the initial
phy_interface_t argument to be passed to xpcs_probe() so we can pass
this on to xpcs_soft_reset().
- stmmac_open() wants to know whether to call stmmac_init_phy() or not,
and for that it looks inside xpcs->an_mode, because the clause 73
(backplane) AN modes supposedly do not have a PHY. Because we moved
an_mode outside of struct mdio_xpcs_args, this is now no longer
directly possible, so we introduce a helper function xpcs_get_an_mode()
which protects the data encapsulation of the xpcs module and requires
a phy_interface_t to be passed as argument. This function can look up
the appropriate compat based on the phy_interface_t.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-02 16:20:13 +00:00
|
|
|
struct xpcs_id;
|
|
|
|
|
2021-06-11 20:05:19 +00:00
|
|
|
struct dw_xpcs {
|
2021-06-02 16:20:18 +00:00
|
|
|
struct mdio_device *mdiodev;
|
net: pcs: xpcs: make the checks related to the PHY interface mode stateless
The operating mode of the driver is currently to populate its
struct mdio_xpcs_args::supported and struct mdio_xpcs_args::an_mode
statically in xpcs_probe(), based on the passed phy_interface_t,
and work with those.
However this is not the operation that phylink expects from a PCS
driver, because the port might be attached to an SFP cage that triggers
changes of the phy_interface_t dynamically as one SFP module is
unpluggged and another is plugged.
To migrate towards that model, the struct mdio_xpcs_args should not
cache anything related to the phy_interface_t, but just look up the
statically defined, const struct xpcs_compat structure corresponding to
the detected PCS OUI/model number.
So we delete the "supported" and "an_mode" members of struct
mdio_xpcs_args, and add the "id" structure there (since the ID is not
expected to change at runtime).
Since xpcs->supported is used deep in the code in _xpcs_config_aneg_c73(),
we need to modify some function headers to pass the xpcs_compat from all
callers. In turn, the xpcs_compat is always supplied externally to the
xpcs module:
- Most of the time by phylink
- In xpcs_probe() it is needed because xpcs_soft_reset() writes to
MDIO_MMD_PCS or to MDIO_MMD_VEND2 depending on whether an_mode is clause
37 or clause 73. In order to not introduce functional changes related
to when the soft reset is issued, we continue to require the initial
phy_interface_t argument to be passed to xpcs_probe() so we can pass
this on to xpcs_soft_reset().
- stmmac_open() wants to know whether to call stmmac_init_phy() or not,
and for that it looks inside xpcs->an_mode, because the clause 73
(backplane) AN modes supposedly do not have a PHY. Because we moved
an_mode outside of struct mdio_xpcs_args, this is now no longer
directly possible, so we introduce a helper function xpcs_get_an_mode()
which protects the data encapsulation of the xpcs module and requires
a phy_interface_t to be passed as argument. This function can look up
the appropriate compat based on the phy_interface_t.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-02 16:20:13 +00:00
|
|
|
const struct xpcs_id *id;
|
2021-06-02 16:20:19 +00:00
|
|
|
struct phylink_pcs pcs;
|
2020-03-09 08:36:26 +00:00
|
|
|
};
|
|
|
|
|
2021-06-11 20:05:19 +00:00
|
|
|
int xpcs_get_an_mode(struct dw_xpcs *xpcs, phy_interface_t interface);
|
net: pcs: xpcs: export xpcs_do_config and xpcs_link_up
The sja1105 hardware has a quirk in that some changes require a switch
reset, which loses all configuration. When the reset is initiated,
everything needs to be reprogrammed, including the MACs and the PCS.
This is currently done in sja1105_static_config_reload() - we manually
call sja1105_adjust_port_config(), sja1105_sgmii_pcs_config() and
sja1105_sgmii_pcs_force_speed() which are all internal functions.
There is a desire for sja1105 to use the common xpcs driver, and that
means that the equivalents of those functions, xpcs_do_config() and
xpcs_link_up() respectively, will no longer be local functions.
Forcing phylink to retrigger a resolve somehow, say by doing dev_close()
followed by dev_open() is not really an option, because the CPU port
might have a PCS as well, and there is no net device which we can close
and reopen for that. Additionally, the dev_close/dev_open sequence might
force a renegotiation of the copper-side link for SGMII ports connected
to a PHY, and this is undesirable as well, because the switch reset is
much quicker than a PHY autoneg, so we would have a lot more downtime.
The only solution I see is for the sja1105 driver to keep doing what
it's doing, and that means we need to export the equivalents from xpcs
for sja1105_sgmii_pcs_config and sja1105_sgmii_pcs_force_speed, and call
them directly in sja1105_static_config_reload(). This will be done
during the conversion patch.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-11 20:05:27 +00:00
|
|
|
void xpcs_link_up(struct phylink_pcs *pcs, unsigned int mode,
|
|
|
|
phy_interface_t interface, int speed, int duplex);
|
|
|
|
int xpcs_do_config(struct dw_xpcs *xpcs, phy_interface_t interface,
|
|
|
|
unsigned int mode);
|
2021-06-11 20:05:19 +00:00
|
|
|
void xpcs_validate(struct dw_xpcs *xpcs, unsigned long *supported,
|
2021-06-02 16:20:14 +00:00
|
|
|
struct phylink_link_state *state);
|
2021-06-11 20:05:19 +00:00
|
|
|
int xpcs_config_eee(struct dw_xpcs *xpcs, int mult_fact_100ns,
|
2021-06-02 16:20:15 +00:00
|
|
|
int enable);
|
2021-06-11 20:05:19 +00:00
|
|
|
struct dw_xpcs *xpcs_create(struct mdio_device *mdiodev,
|
|
|
|
phy_interface_t interface);
|
|
|
|
void xpcs_destroy(struct dw_xpcs *xpcs);
|
2020-03-09 08:36:26 +00:00
|
|
|
|
2020-08-27 02:00:28 +00:00
|
|
|
#endif /* __LINUX_PCS_XPCS_H */
|