mbox series

[0/2] Add reset deassertion for Aspeed MDIO

Message ID 20220321070131.23363-1-dylan_hung@aspeedtech.com (mailing list archive)
Headers show
Series Add reset deassertion for Aspeed MDIO | expand

Message

Dylan Hung March 21, 2022, 7:01 a.m. UTC 
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(+)

Comments

Andrew Lunn March 21, 2022, 12:10 p.m. UTC | #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
Dylan Hung March 22, 2022, 9:10 a.m. UTC | #2 
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
Andrew Lunn March 22, 2022, 12:17 p.m. UTC | #3 
> 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