* [PATCH net-next] net: bcmgenet: Patch PHY interface for dedicated PHY driver
@ 2021-09-17 21:55 Florian Fainelli
2021-09-18 11:00 ` patchwork-bot+netdevbpf
0 siblings, 1 reply; 2+ messages in thread
From: Florian Fainelli @ 2021-09-17 21:55 UTC (permalink / raw)
To: netdev
Cc: Florian Fainelli, Doug Berger, David S. Miller, Jakub Kicinski,
open list:BROADCOM GENET ETHERNET DRIVER, open list
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(-)
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;
--
2.25.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH net-next] net: bcmgenet: Patch PHY interface for dedicated PHY driver
2021-09-17 21:55 [PATCH net-next] net: bcmgenet: Patch PHY interface for dedicated PHY driver Florian Fainelli
@ 2021-09-18 11:00 ` patchwork-bot+netdevbpf
0 siblings, 0 replies; 2+ messages in thread
From: patchwork-bot+netdevbpf @ 2021-09-18 11:00 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, opendmb, davem, kuba, bcm-kernel-feedback-list,
linux-kernel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-09-18 11:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-09-17 21:55 [PATCH net-next] net: bcmgenet: Patch PHY interface for dedicated PHY driver Florian Fainelli
2021-09-18 11:00 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).