Add missing reset deassertion for Aspeed MDIO. There are 4 MDIOs
embedded in Aspeed AST2600 and share one reset control bit SCU50[3].

Dylan Hung (2):
  net: mdio: add reset deassertion for Aspeed MDIO
  ARM: dts: aspeed: add reset properties into MDIO nodes

 arch/arm/boot/dts/aspeed-g6.dtsi | 4 ++++
 drivers/net/mdio/mdio-aspeed.c   | 8 ++++++++
 2 files changed, 12 insertions(+)

-- 
2.25.1

On Mon, Mar 21, 2022 at 03:01:29PM +0800, Dylan Hung wrote:
> Add missing reset deassertion for Aspeed MDIO. There are 4 MDIOs
> embedded in Aspeed AST2600 and share one reset control bit SCU50[3].

Is the reset limited to the MDIO bus masters, or are PHYs one the bus
potentially also reset?

Who asserts the reset in the first place? Don't you want the first
MDIO bus to probe to assert and then deassert the reset in order that
all the hardware is reset?

    Andrew

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: 2022年3月21日 8:11 PM
> To: Dylan Hung <dylan_hung@aspeedtech.com>
> Cc: robh+dt@kernel.org; joel@jms.id.au; andrew@aj.id.au;
> hkallweit1@gmail.com; linux@armlinux.org.uk; davem@davemloft.net;
> kuba@kernel.org; pabeni@redhat.com; p.zabel@pengutronix.de;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-aspeed@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; BMC-SW <BMC-SW@aspeedtech.com>
> Subject: Re: [PATCH 0/2] Add reset deassertion for Aspeed MDIO
> 
> On Mon, Mar 21, 2022 at 03:01:29PM +0800, Dylan Hung wrote:
> > Add missing reset deassertion for Aspeed MDIO. There are 4 MDIOs
> > embedded in Aspeed AST2600 and share one reset control bit SCU50[3].
> 
> Is the reset limited to the MDIO bus masters, or are PHYs one the bus
> potentially also reset?

It is limited to the MDIO bus masters.

> 
> Who asserts the reset in the first place? 

The hardware asserts the reset by default.

> Don't you want the first MDIO bus to
> probe to assert and then deassert the reset in order that all the hardware is
> reset?

Do I still need to add a reset assertion/deassertion if the hardware asserts the reset by default?

> 
>     Andrew

--
Dylan

> Do I still need to add a reset assertion/deassertion if the hardware
> asserts the reset by default?

One use case would be kexec when one kernel is used to boot another
kernel. But since this is shared by multiple busses, it is probably
not worth the complexity unless that is something you expect you
customers to do, e.g. during kernel development work.

	Andrew