[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yjk722CyEW3q1ntm@lunn.ch>
Date: Tue, 22 Mar 2022 04:00:43 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Dylan Hung <dylan_hung@...eedtech.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"joel@....id.au" <joel@....id.au>,
"andrew@...id.au" <andrew@...id.au>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"davem@...emloft.net" <davem@...emloft.net>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
BMC-SW <BMC-SW@...eedtech.com>,
"stable@...r.kernel.org" <stable@...r.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:
> > -----Original Message-----
> > From: Krzysztof Kozlowski [mailto:krzk@...nel.org]
> > Sent: 2022年3月21日 11:53 PM
> > To: Dylan Hung <dylan_hung@...eedtech.com>; robh+dt@...nel.org;
> > joel@....id.au; andrew@...id.au; andrew@...n.ch; hkallweit1@...il.com;
> > linux@...linux.org.uk; davem@...emloft.net; kuba@...nel.org;
> > pabeni@...hat.com; p.zabel@...gutronix.de; devicetree@...r.kernel.org;
> > linux-arm-kernel@...ts.infradead.org; linux-aspeed@...ts.ozlabs.org;
> > linux-kernel@...r.kernel.org; netdev@...r.kernel.org
> > Cc: BMC-SW <BMC-SW@...eedtech.com>; stable@...r.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:
> > > 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 <dylan_hung@...eedtech.com>
> > > Cc: stable@...r.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).
> 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?
> 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.
Andrew
Powered by blists - more mailing lists