RE: [PATCH v2 3/3] ARM: dts: aspeed: add reset properties into MDIO nodes

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: 2022年3月22日 11:01 AM
To: Dylan Hung <redacted>
Cc: Krzysztof Kozlowski <krzk@kernel.org>; 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
[off-list ref]; stable@vger.kernel.org
Subject: Re: [PATCH v2 3/3] ARM: dts: aspeed: add reset properties into MDIO
nodes

On Tue, Mar 22, 2022 at 02:32:13AM +0000, Dylan Hung wrote:

quoted

quoted

-----Original Message-----
From: Krzysztof Kozlowski [mailto:krzk@kernel.org]
Sent: 2022年3月21日 11:53 PM
To: Dylan Hung <redacted>; robh+dt@kernel.org;
joel@jms.id.au; andrew@aj.id.au; andrew@lunn.ch;
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
Cc: BMC-SW <redacted>; stable@vger.kernel.org
Subject: Re: [PATCH v2 3/3] ARM: dts: aspeed: add reset properties
into MDIO nodes

On 21/03/2022 10:56, Dylan Hung wrote:

quoted

Add reset control properties into MDIO nodes.  The 4 MDIO
controllers in
AST2600 SOC share one reset control bit SCU50[3].

Signed-off-by: Dylan Hung <redacted>
Cc: stable@vger.kernel.org

Please describe the bug being fixed. See stable-kernel-rules.

Thank you for your comment.
The reset deassertion of the MDIO device was usually done by the

bootloader (u-boot).

quoted

However, one of our clients uses proprietary bootloader and doesn't
deassert the MDIO reset so failed to access the HW in kernel driver.

So are you saying mainline u-boot releases the reset?

Yes, if the mdio devices are used in u-boot.

quoted

The reset deassertion is missing in the kernel driver since it was
created, should I add a BugFix for the first commit of this driver?

Yes, that is normal. Ideally the kernel should not depend on u-boot, because
often people want to use other bootloaders, e.g. barebox. You should also
consider kexec, where one kernel hands over to another kernel, without the
bootloader being involved. In such a situation, you ideally want to assert and
deassert the reset just to clean away any state the old kernel left around.

But please do note, that the reset is optional, since you need to be able to
work with old DT blobs which don't have the reset property in them.

Thank you. I will let the reset property be optional and modify the error-checking
in the driver accordingly in V3.

	Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel