user/sven/linux.git/include/linux/pcs, branch v5.15.87

net: pcs: xpcs: export xpcs_do_config and xpcs_link_up

2021-06-11T20:43:56Z

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 Signed-off-by: David S. Miller

net: pcs: xpcs: add support for NXP SJA1110

2021-06-11T20:43:56Z

The NXP SJA1110 switch integrates its own, non-Synopsys PMA, but it manages it through the register space of the XPCS itself, in a small register window inside MDIO_MMD_VEND2 from address 0x8030 to 0x806e. This coincides with where the registers for the default Synopsys PMA are, but the register definitions are of course not the same. This situation is an odd hardware quirk, but the simplest way to manage it is to drive the SJA1110's PMA from within the XPCS driver. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: pcs: xpcs: add support for NXP SJA1105

2021-06-11T20:43:56Z

The NXP SJA1105 DSA switch integrates a Synopsys SGMII XPCS on port 4. The generic code works fine, except there is an integration issue which needs to be dealt with: in this switch, the XPCS is integrated with a PMA that has the TX lane polarity inverted by default (PLUS is MINUS, MINUS is PLUS). To obtain normal non-inverted behavior, the TX lane polarity must be inverted in the PCS, via the DIGITAL_CONTROL_2 register. We introduce a pma_config() method in xpcs_compat which is called by the phylink_pcs_config() implementation. Also, the NXP SJA1105 returns all zeroes in the PHY ID registers 2 and 3. We need to hack up an ad-hoc PHY ID (OUI is zero, device ID is 1) in order for the XPCS driver to recognize it. This PHY ID is added to the public include/linux/pcs/pcs-xpcs.h for that reason (for the sja1105 driver to be able to use it in a later patch). Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: pcs: xpcs: rename mdio_xpcs_args to dw_xpcs

2021-06-11T20:43:55Z

The struct mdio_xpcs_args is reminiscent of when a similarly named struct mdio_xpcs_ops existed. Now that that is removed, we can shorten the name to dw_xpcs (dw for DesignWare). Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: pcs: add 2500BASEX support for Intel mGbE controller

2021-06-08T21:31:43Z

XPCS IP supports 2500BASEX as PHY interface. It is configured as autonegotiation disable to cater for PHYs that does not supports 2500BASEX autonegotiation. v2: Add supported link speed masking. v3: Restructure to introduce xpcs_config_2500basex() used to configure the xpcs for 2.5G speeds. Added 2500BASEX specific information for configuration. v4: Fix indentation error Signed-off-by: Voon Weifeng Signed-off-by: Michael Sit Wei Hong Signed-off-by: David S. Miller

net: pcs: xpcs: convert to phylink_pcs_ops

2021-06-03T20:30:43Z

Since all the remaining members of struct mdio_xpcs_ops have direct equivalents in struct phylink_pcs_ops, it is about time we remove it altogether. Since the phylink ops return void, we need to remove the error propagation from the various xpcs methods and simply print an error message where appropriate. Since xpcs_get_state_c73() detects link faults and attempts to reset the link on its own by calling xpcs_config(), but xpcs_config() now has a lot of phylink arguments which are not needed and cannot be simply fabricated by anybody else except phylink, the actual implementation has been moved into a smaller xpcs_do_config(). The const struct mdio_xpcs_ops *priv->hw->xpcs has been removed, so we need to look at the struct mdio_xpcs_args pointer now as an indication whether the port has an XPCS or not. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: pcs: xpcs: convert to mdio_device

2021-06-03T20:30:43Z

Unify the 2 existing PCS drivers (lynx and xpcs) by doing a similar thing on probe, which is to have a *_create function that takes a struct mdio_device * given by the caller, and builds a private PCS structure around that. This changes stmmac to hold only a pointer to the xpcs, as opposed to the full structure. This will be used in the next patch when struct mdio_xpcs_ops is removed. Currently a pointer to struct mdio_xpcs_ops is used as a shorthand to determine whether the port has an XPCS or not. We can do the same now with the mdio_xpcs_args pointer. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: pcs: xpcs: export xpcs_probe

2021-06-03T20:30:43Z

Similar to the other recently functions, it is not necessary for xpcs_probe to be a function pointer, so export it so that it can be called directly. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: pcs: xpcs: export xpcs_config_eee

2021-06-03T20:30:43Z

There is no good reason why we need to go through: stmmac_xpcs_config_eee -> stmmac_do_callback -> mdio_xpcs_ops->config_eee -> xpcs_config_eee when we can simply call xpcs_config_eee. priv->hw->xpcs is of the type "const struct mdio_xpcs_ops *" and is used as a placeholder/synonym for priv->plat->mdio_bus_data->has_xpcs. It is done that way because the mdio_bus_data pointer might or might not be populated in all stmmac instantiations. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller

net: pcs: xpcs: export xpcs_validate

2021-06-03T20:30:43Z

Calling a function pointer with a single implementation through struct mdio_xpcs_ops is clunky, and the stmmac_do_callback system forces this to return int, even though it always returns zero. Simply remove the "validate" function pointer from struct mdio_xpcs_ops and replace it with an exported xpcs_validate symbol which is called directly by stmmac. priv->hw->xpcs is of the type "const struct mdio_xpcs_ops *" and is used as a placeholder/synonym for priv->plat->mdio_bus_data->has_xpcs. It is done that way because the mdio_bus_data pointer might or might not be populated in all stmmac instantiations. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller