| Message ID | c7d1dbac1940853c22db8215ed60181b2abe3050.1561556556.git.joabreu@synopsys.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | net: stmmac: 10GbE using XGMAC | expand |
On Wed, Jun 26, 2019 at 03:47:44PM +0200, Jose Abreu wrote: > On PCI based setups that are connected to C45 PHY we won't have DT > bindings specifying what's the correct PHY type. You can associate a DT node to a PCI device. The driver does not have to do anything special, the PCI core code does all the work. As an example look at imx6q-zii-rdu2.dts, node &pcie, which has an intel i210 on the pcie bus, and we need a handle to it. Andrew
From: Andrew Lunn <andrew@lunn.ch> > On Wed, Jun 26, 2019 at 03:47:44PM +0200, Jose Abreu wrote: > > On PCI based setups that are connected to C45 PHY we won't have DT > > bindings specifying what's the correct PHY type. > > You can associate a DT node to a PCI device. The driver does not have > to do anything special, the PCI core code does all the work. > > As an example look at imx6q-zii-rdu2.dts, node &pcie, which has an > intel i210 on the pcie bus, and we need a handle to it. That's for ARM but I'm using X86_64 which only has ACPI :/
On Thu, Jun 27, 2019 at 07:54:14AM +0000, Jose Abreu wrote: > From: Andrew Lunn <andrew@lunn.ch> > > > On Wed, Jun 26, 2019 at 03:47:44PM +0200, Jose Abreu wrote: > > > On PCI based setups that are connected to C45 PHY we won't have DT > > > bindings specifying what's the correct PHY type. > > > > You can associate a DT node to a PCI device. The driver does not have > > to do anything special, the PCI core code does all the work. > > > > As an example look at imx6q-zii-rdu2.dts, node &pcie, which has an > > intel i210 on the pcie bus, and we need a handle to it. > > That's for ARM but I'm using X86_64 which only has ACPI :/ Hi Jose There have been some drivers gaining patches for ACPI. That is probably the better long term solution, ask ACPI where is the PHY and what MDIO protocol to use to talk to it. Andrew
From: Andrew Lunn <andrew@lunn.ch> > There have been some drivers gaining patches for ACPI. That is > probably the better long term solution, ask ACPI where is the PHY and > what MDIO protocol to use to talk to it. Hmmm, I'm not sure this is going to work that way ... My setup is a PCI EP which is hot-pluggable and as far as I know ACPI has only static content (????)
On Thu, Jun 27, 2019 at 01:33:59PM +0000, Jose Abreu wrote: > From: Andrew Lunn <andrew@lunn.ch> > > > There have been some drivers gaining patches for ACPI. That is > > probably the better long term solution, ask ACPI where is the PHY and > > what MDIO protocol to use to talk to it. > > Hmmm, I'm not sure this is going to work that way ... > > My setup is a PCI EP which is hot-pluggable and as far as I know ACPI > has only static content (????) I've wanted to improve the PHY probe code for a while. I was thinking we should add a flag to the MDIO bus driver structure indicating it can do C45. When that flag is present, we should also scan the bus for C45 devices, and register them as well. With that in place, i think your problem goes away. Architecturally, i think it is wrong that a MAC driver is registering PHY devices. The MDIO core should do this. Andrew
From: Andrew Lunn <andrew@lunn.ch> > On Thu, Jun 27, 2019 at 01:33:59PM +0000, Jose Abreu wrote: > > From: Andrew Lunn <andrew@lunn.ch> > > > > > There have been some drivers gaining patches for ACPI. That is > > > probably the better long term solution, ask ACPI where is the PHY and > > > what MDIO protocol to use to talk to it. > > > > Hmmm, I'm not sure this is going to work that way ... > > > > My setup is a PCI EP which is hot-pluggable and as far as I know ACPI > > has only static content (????) > > I've wanted to improve the PHY probe code for a while. I was thinking > we should add a flag to the MDIO bus driver structure indicating it > can do C45. When that flag is present, we should also scan the bus for > C45 devices, and register them as well. > > With that in place, i think your problem goes away. Architecturally, i > think it is wrong that a MAC driver is registering PHY devices. The > MDIO core should do this. Ok, I will drop this patch from the series until we come up with a better solution.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index bc949665c529..e790ab79e819 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -1014,6 +1014,20 @@ static int stmmac_init_phy(struct net_device *dev) phydev = mdiobus_get_phy(priv->mii, addr); if (!phydev) { + /* Try C45 */ + phydev = get_phy_device(priv->mii, addr, true); + if (phydev && !IS_ERR(phydev)) { + ret = phy_device_register(phydev); + if (ret) { + phy_device_free(phydev); + phydev = NULL; + } + } else { + phydev = NULL; + } + } + + if (!phydev) { netdev_err(priv->dev, "no phy at addr %d\n", addr); return -ENODEV; }
On PCI based setups that are connected to C45 PHY we won't have DT bindings specifying what's the correct PHY type. Fallback to C45 if everything else fails when trying to acquire PHY. Signed-off-by: Jose Abreu <joabreu@synopsys.com> Cc: Joao Pinto <jpinto@synopsys.com> Cc: David S. Miller <davem@davemloft.net> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)