From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Schmelzer Date: Wed, 27 Mar 2019 14:21:10 +0100 Subject: [U-Boot] [REGRESSION: PATCH 34/34] drivers/net/fec: phy_init: remove redundant logic In-Reply-To: <371b0c7b1f460192931715bbb1479174f0d13389.camel@toradex.com> References: <20190313082845.70B83C21FAB@lists.denx.de> <120740997b8dab076d17f91625de73b40ae54b48.camel@toradex.com> <95b059d1-9de4-bd3e-d1dd-e7909bd4892f@schmelzer.or.at> <697EBFC1-D953-45F7-A781-732BB79AD510@schmelzer.or.at> <371b0c7b1f460192931715bbb1479174f0d13389.camel@toradex.com> Message-ID: <0994cfcd-94b2-6005-3e96-50a303673aad@schmelzer.or.at> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 3/26/19 1:08 PM, Marcel Ziswiler wrote: > Hi Hannes Hi Marcel, thanks for helping me working on this. > > On Tue, 2019-03-26 at 12:57 +0100, Hannes Schmelzer wrote: >> Hi marcel, >> >> Okay. Behaviour is now clear to me. >> You don't have a phy node within your dts > We never ever had any such anywhere but it still used to work just fine > so far. Before that you didn't operate the FEC with DM i think, so there was no description at all. > >> nor you have MXC_PHY_ADDR set in your board header. > I actually once even tried setting that without success but maybe I did > it wrong. Sorry, the correct name of the #define is 'CONFIG_FEC_MXC_PHYADDR'. Prior converting your board to DM you had here: #define CONFIG_FEC_MXC_PHYADDR 0 > >> The implicit fallback mechanism for searching the whole mdio bus for >> st least one phy has been gone with my patch. > OK, maybe I just missed noticing such behavioural change having been > advertised anywhere. There was no explicit notice, it did happen ;-) I didn't expect that there is somebody who neither defines a phy-adress within dts nor board-header. > >> Could you try describing your phy within dts to get sure that iam >> right here. > Sure, let me try that. Did you have success in this? > >> Later on we have to discuss if the 'fallback' should be re >> implemented. > Yeah, I assume such behavioural change breaks other boards as well. Mhm, you're right - i will provide a patch to the mailinglist for catching this. But in general, a precise description of the hardware would be the better way. cheers, Hannes