Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230115161006.16431-1-pierluigi.p@variscite.com> <Y8QzI2VUY6//uBa/@lunn.ch>
In-Reply-To: <Y8QzI2VUY6//uBa/@lunn.ch>
From:   Pierluigi Passaro <pierluigi.passaro@gmail.com>
Date:   Sun, 15 Jan 2023 19:38:38 +0100
Message-ID: <CAJ=UCjX0YzVgedO1hDu_NsFAGhxe8HouUmHmbO6AXZqT=OUYLg@mail.gmail.com>
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        eran.m@variscite.com, nate.d@variscite.com,
        francesco.f@variscite.com, pierluigi.p@variscite.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Jan 15, 2023 at 6:08 PM Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, Jan 15, 2023 at 05:10:06PM +0100, Pierluigi Passaro wrote:
> > When the reset gpio is defined within the node of the device tree
> > describing the PHY, the reset is initialized and managed only after
> > calling the fwnode_mdiobus_phy_device_register function.
> > However, before calling it, the MDIO communication is checked by the
> > get_phy_device function.
> > When this happens and the reset GPIO was somehow previously set down,
> > the get_phy_device function fails, preventing the PHY detection.
> > These changes force the deassert of the MDIO reset signal before
> > checking the MDIO channel.
> > The PHY may require a minimum deassert time before being responsive:
> > use a reasonable sleep time after forcing the deassert of the MDIO
> > reset signal.
> > Once done, free the gpio descriptor to allow managing it later.
>
> This has been discussed before. The problem is, it is not just a reset
> GPIO. There could also be a clock which needs turning on, a regulator,
> and/or a linux reset controller. And what order do you turn these on?
>
> The conclusion of the discussion is you assume the device cannot be
> found by enumeration, and you put the ID in the compatible. That is
> enough to get the driver to load, and the driver can then turn
> everything on in the correct order, with the correct delays, etc.
>
Can you provide any reference to this discussion?
From our investigation, the MDIO communication is checked before managing
the "reset" gpio .
This behaviour is generally not visible, but easily reproducible with all NXP
platforms with dual fec (iMX28, iMX6UL, iMX7, iMX8QM, iMX8QXP)
where the MDIO bus is owned by the 1st interface but shared with the 2nd.
When the 1st interface is probed, this causes the probe of the MDIO bus
when the 2nd interface is not yet set up.
Here a reference configuration
https://github.com/varigit/linux-imx/blob/5.15-2.0.x-imx_var01/arch/arm64/boot/dts/freescale/imx8qm-var-spear.dtsi#L168-L219
Without this patch, the above settings can fail simply forcing the reset GPIOs
to zero in u-boot.
Please let me know if further details are needed.
>
> I think there has been some work on generic power sequencing. I've not
> being following it, so I've no idea how far it has got. If that could
> be used to solve this problem for all the possible controls of a PHY,
> i would be open for such patches.
>
>       Andrew