On 1/24/2022 9:26 AM, Russell King (Oracle) wrote:
On Mon, Jan 24, 2022 at 09:13:38AM -0800, Florian Fainelli wrote:
On 1/23/2022 7:26 AM, Andrew Lunn wrote:
On Sun, Jan 23, 2022 at 11:33:04AM +0300, Arınç ÜNAL wrote:
Hey Deng,
On 23/01/2022 09:51, DENG Qingfang wrote:
Hi,
Do you set the ethernet pinmux correctly?
ðernet {
pinctrl-names = "default";
pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>;
};
This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally
on external_phy) so we never thought to investigate the pinctrl
configuration further! Turns out &rgmii2_pins needs to be defined on the
ethernet node instead.
PHYs are generally external, so pinmux on them makes no sense. PHYs in
DT are not devices in the usual sense, so i don't think the driver
core will handle pinmux for them, even if you did list them.
Not sure I understand your comment here, this is configuring the pinmux on
the SoC side in order for the second RGMII interface's data path to work.
The pinmux configuration was listed under the external PHY node, which
is qutie unusual. In the case of phylib and external ethernet PHYs,
this can be a problem.
The pinmux configuration is normally handled at device probe time by
the device model, but remember phylib bypasses that when it attaches
the generic PHY driver - meaning you don't get the pinmux configured.
What this means is that pinmux configuration in ethernet PHY nodes is
unreliable. It will only happen if we have a specific driver for the
PHY and the driver model binds that driver.
Of course, if we killed the generic driver, that would get around this
issue by requiring every PHY to have its own specific driver, but there
would be many complaints because likely lots would stop working.
I suppose that explains why this is still in staging then :) Andrew's
answer makes more sense now, thanks.
--
Florian
