Message ID | 20210917215539.3020216-1-f.fainelli@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | b972b54a68b2512a7528658ecd023aea108c03a5 |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [net-next] net: bcmgenet: Patch PHY interface for dedicated PHY driver | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | success | Link |
netdev/tree_selection | success | Clearly marked for net-next |
netdev/subject_prefix | success | Link |
netdev/cc_maintainers | success | CCed 6 of 6 maintainers |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 58 lines checked |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
netdev/header_inline | success | Link |
Hello: This patch was applied to netdev/net-next.git (refs/heads/master): On Fri, 17 Sep 2021 14:55:38 -0700 you wrote: > When we are using a dedicated PHY driver (not the Generic PHY driver) > chances are that it is going to configure RGMII delays and do that in a > way that is incompatible with our incorrect interpretation of the > phy_interface value. > > Add a quirk in order to reverse the PHY_INTERFACE_MODE_RGMII to the > value of PHY_INTERFACE_MODE_RGMII_ID such that the MAC continues to be > configured the way it used to be, but the PHY driver can account for > adding delays. Conversely when PHY_INTERFACE_MODE_RGMII_TXID is > specified, return PHY_INTERFACE_MODE_RGMII_RXID to the PHY since we will > have enabled a TXC MAC delay (id_mode_dis=0, meaning there is a delay > inserted). > > [...] Here is the summary with links: - [net-next] net: bcmgenet: Patch PHY interface for dedicated PHY driver https://git.kernel.org/netdev/net-next/c/b972b54a68b2 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c index 89d16c587bb7..2d29de9a33e3 100644 --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c @@ -286,6 +286,7 @@ int bcmgenet_mii_probe(struct net_device *dev) struct bcmgenet_priv *priv = netdev_priv(dev); struct device *kdev = &priv->pdev->dev; struct device_node *dn = kdev->of_node; + phy_interface_t phy_iface = priv->phy_interface; struct phy_device *phydev; u32 phy_flags = 0; int ret; @@ -300,9 +301,42 @@ int bcmgenet_mii_probe(struct net_device *dev) priv->old_duplex = -1; priv->old_pause = -1; + /* This is an ugly quirk but we have not been correctly interpreting + * the phy_interface values and we have done that across different + * drivers, so at least we are consistent in our mistakes. + * + * When the Generic PHY driver is in use either the PHY has been + * strapped or programmed correctly by the boot loader so we should + * stick to our incorrect interpretation since we have validated it. + * + * Now when a dedicated PHY driver is in use, we need to reverse the + * meaning of the phy_interface_mode values to something that the PHY + * driver will interpret and act on such that we have two mistakes + * canceling themselves so to speak. We only do this for the two + * modes that GENET driver officially supports on Broadcom STB chips: + * PHY_INTERFACE_MODE_RGMII and PHY_INTERFACE_MODE_RGMII_TXID. Other + * modes are not *officially* supported with the boot loader and the + * scripted environment generating Device Tree blobs for those + * platforms. + * + * Note that internal PHY, MoCA and fixed-link configurations are not + * affected because they use different phy_interface_t values or the + * Generic PHY driver. + */ + switch (priv->phy_interface) { + case PHY_INTERFACE_MODE_RGMII: + phy_iface = PHY_INTERFACE_MODE_RGMII_ID; + break; + case PHY_INTERFACE_MODE_RGMII_TXID: + phy_iface = PHY_INTERFACE_MODE_RGMII_RXID; + break; + default: + break; + } + if (dn) { phydev = of_phy_connect(dev, priv->phy_dn, bcmgenet_mii_setup, - phy_flags, priv->phy_interface); + phy_flags, phy_iface); if (!phydev) { pr_err("could not attach to PHY\n"); return -ENODEV; @@ -332,7 +366,7 @@ int bcmgenet_mii_probe(struct net_device *dev) phydev->dev_flags = phy_flags; ret = phy_connect_direct(dev, phydev, bcmgenet_mii_setup, - priv->phy_interface); + phy_iface); if (ret) { pr_err("could not attach to PHY\n"); return -ENODEV;
When we are using a dedicated PHY driver (not the Generic PHY driver) chances are that it is going to configure RGMII delays and do that in a way that is incompatible with our incorrect interpretation of the phy_interface value. Add a quirk in order to reverse the PHY_INTERFACE_MODE_RGMII to the value of PHY_INTERFACE_MODE_RGMII_ID such that the MAC continues to be configured the way it used to be, but the PHY driver can account for adding delays. Conversely when PHY_INTERFACE_MODE_RGMII_TXID is specified, return PHY_INTERFACE_MODE_RGMII_RXID to the PHY since we will have enabled a TXC MAC delay (id_mode_dis=0, meaning there is a delay inserted). This is not considered a bug fix at this point since it only affects Broadcom STB platforms shipping with a Device Tree blob that is not updatable in the field (quite a few devices out there) and which was generated using the scripted Device Tree environment shipped with those platforms' SDK. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> --- drivers/net/ethernet/broadcom/genet/bcmmii.c | 38 ++++++++++++++++++-- 1 file changed, 36 insertions(+), 2 deletions(-)