From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id D623C2C0092 for ; Wed, 15 Aug 2012 09:06:39 +1000 (EST) Message-ID: <502AD9F4.10903@freescale.com> Date: Tue, 14 Aug 2012 18:06:28 -0500 From: Scott Wood MIME-Version: 1.0 To: Timur Tabi Subject: Re: [PATCH 2/2] powerpc/85xx: add Fman MDIO muxing support to the P4080DS References: <1344637896-14267-1-git-send-email-timur@freescale.com> <1344637896-14267-2-git-send-email-timur@freescale.com> <5F0028FE-C555-47DE-B69A-888E7322A6E1@kernel.crashing.org> <502AC7C3.9030902@freescale.com> <502AC8D3.4010602@freescale.com> <502ACA09.6070906@freescale.com> In-Reply-To: <502ACA09.6070906@freescale.com> Content-Type: text/plain; charset="UTF-8" Cc: linuxppc-dev@ozlabs.org, Andy Fleming , ddaney.cavm@gmail.com, netdev@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 08/14/2012 04:58 PM, Timur Tabi wrote: > Scott Wood wrote: > >> I think that was internally, and not on this specific comment wording. >> I don't think that code comment adequately explains things. > > I don't really have any more insight to add. My point (at least, this part of it) was that more of the insight you've already provided should be moved from e-mail discussion to the code comment. >>> otherwise, the mdio-mux code would not prepare the mdio mus in time, and >>> there would be initialization failures. Now maybe this goes away with >>> -EPROBE_DEFER, or maybe it doesn't. But until we push the DPAA drivers >>> upstream, we won't know. >> >> Do you know if it's theoretically supposed to be fixed and just can't >> test it, or are you unsure of whether it's even supposed to work? > > I'm not sure of anything. For one thing, we don't implement EPROBE_DEFER > in the DPAA drivers, so we'd probably have to fix that before anything. > And then, I'm just guessing that's the solution. I feel confident saying it is the solution, at least until it is demonstrated otherwise. >> I don't think we should be relying on the order of this list to >> determine probe order. For one thing, it won't work if the drivers >> register after you create the platform devices (e.g. they're modules). > > I agree we should not be relying on the order, but I don't know what to > do. EPROBE_DEFER was designed to handle this situation, so my > recommendation is to worry about it later. I can beef up the comment to > talk about that, if you want. If the DPAA driver doesn't implement it when it's submitted, it's a bug in the DPAA driver and we should insist it be fixed. I don't think we should at all entertain the notion that careful device id list ordering is even a potential solution. If anything, I'd make the ordering be "wrong" to force that code path to be tested -- though ideally there would be a more systematic approach to such testing, that doesn't require inefficiency during normal boot. -Scott