> -----Original Message----- > From: Andrew Lunn [mailto:andrew@xxxxxxx] > Sent: 2022年3月22日 11:01 AM > To: Dylan Hung <dylan_hung@xxxxxxxxxxxxxx> > Cc: Krzysztof Kozlowski <krzk@xxxxxxxxxx>; robh+dt@xxxxxxxxxx; > joel@xxxxxxxxx; andrew@xxxxxxxx; hkallweit1@xxxxxxxxx; > linux@xxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; kuba@xxxxxxxxxx; > pabeni@xxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-aspeed@xxxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; BMC-SW > <BMC-SW@xxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx > 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@xxxxxxxxxx] > > > Sent: 2022年3月21日 11:53 PM > > > To: Dylan Hung <dylan_hung@xxxxxxxxxxxxxx>; robh+dt@xxxxxxxxxx; > > > joel@xxxxxxxxx; andrew@xxxxxxxx; andrew@xxxxxxx; > > > hkallweit1@xxxxxxxxx; linux@xxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; > > > kuba@xxxxxxxxxx; pabeni@xxxxxxxxxx; p.zabel@xxxxxxxxxxxxxx; > > > devicetree@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; > > > linux-aspeed@xxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > > netdev@xxxxxxxxxxxxxxx > > > Cc: BMC-SW <BMC-SW@xxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx > > > 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@xxxxxxxxxxxxxx> > > > > Cc: stable@xxxxxxxxxxxxxxx > > > > > > 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? > Yes, if the mdio devices are used in u-boot. > > 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 > >
