From patchwork Thu Apr 28 20:03:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Florian Fainelli X-Patchwork-Id: 616397 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3qwnrh3nPPz9t91 for ; Fri, 29 Apr 2016 06:05:56 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=SJV2BXrD; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753163AbcD1UFh (ORCPT ); Thu, 28 Apr 2016 16:05:37 -0400 Received: from mail-pf0-f179.google.com ([209.85.192.179]:35307 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752692AbcD1UFf (ORCPT ); Thu, 28 Apr 2016 16:05:35 -0400 Received: by mail-pf0-f179.google.com with SMTP id 77so5472695pfv.2; Thu, 28 Apr 2016 13:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/yfN1j9cq9Iqmgb1LPinjkDxL8XbgUXPn0ZQCt52heM=; b=SJV2BXrDoPAq0KEo/m6qA+XAT/RzoyEOKaG2OmbGb/qDkO6w96BDVf5/HI/Stwfsz9 dxzUVF6PDjwqkoN/ZfrFc33q8vc/tGoX/54kH2DOcPHXDm88cMHRlWxmfRB7TgOJUvJ6 LX0pB640DTfEO04Sbqox4YgaZn4LaphI/OUneXlyliEmDugipi/CPxXp1e0v2UMYuNUd 5UsinXqrDePCLHDf0DBkmrafLMHYk/TcAs0qzAbc9PnxJL8r8wbBKFPfl6A+c2sPHcVS vwLflYKWq+RRqpUY7KhimlwqhqlHRcQrxAGE+tttuKrpo+t0G0OtTq1TxqEmUEnEb2L4 cfuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/yfN1j9cq9Iqmgb1LPinjkDxL8XbgUXPn0ZQCt52heM=; b=Lbuiu5f6G1+4DgJ6J+lBu/lFHEKOIFLpsgx9biHiQzyElD6CV51UniN2f3plUVLt8j r0VrUOgcKbVTFzcdY4YWbDtmefLQn/mdXe/s2PYh2miK9jkcsqk3nw5fOY64GhtvXsew inkHiJK9T1E6ZqRZNaUNeXXUFO6GY7IQQHClH2cXJ3AeDh+5gBTgxyOW7YWQjyFMFsI7 UjsoxQN1gXbod8A1kDQwMdkYnLGsVQzQ3bPIH/xASxK9YvKrbt2xdT76vzdmCn2nlprV L9mvR8/Il+pkfKRED6uO4Q9WgBQJe03OSRiCjHX6fL/y8Mn+0c9WJ92CXdqocVnOGLYd LE6Q== X-Gm-Message-State: AOPr4FXU35cL7n99hXErmWPU2aK0MKFEAcy7ys7BQ8RYK9ONufQFPGi6GRnToCPePSuJ1A== X-Received: by 10.98.93.67 with SMTP id r64mr23374909pfb.133.1461873934504; Thu, 28 Apr 2016 13:05:34 -0700 (PDT) Received: from [10.12.156.244] (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by smtp.googlemail.com with ESMTPSA id y66sm8858806pfy.66.2016.04.28.13.05.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Apr 2016 13:05:33 -0700 (PDT) Subject: Re: [PATCH v2] net: macb: do not scan PHYs manually To: Andrew Lunn , Nathan Sullivan References: <1461854802-8142-1-git-send-email-nathan.sullivan@ni.com> <57222FCE.8050407@atmel.com> <20160428155556.GA8333@nathan3500-linux-VM> <20160428163207.GP29024@lunn.ch> <20160428175619.GA8791@nathan3500-linux-VM> <20160428184303.GR29024@lunn.ch> <20160428185527.GA8851@nathan3500-linux-VM> <20160428185932.GU29024@lunn.ch> Cc: Nicolas Ferre , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Belloni From: Florian Fainelli Message-ID: <57226C83.8040509@gmail.com> Date: Thu, 28 Apr 2016 13:03:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160428185932.GU29024@lunn.ch> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 28/04/16 11:59, Andrew Lunn wrote: > On Thu, Apr 28, 2016 at 01:55:27PM -0500, Nathan Sullivan wrote: >> On Thu, Apr 28, 2016 at 08:43:03PM +0200, Andrew Lunn wrote: >>>> I agree that is a valid fix for AT91, however it won't solve our problem, since >>>> we have no children on the second ethernet MAC in our devices' device trees. I'm >>>> starting to feel like our second MAC shouldn't even really register the MDIO bus >>>> since it isn't being used - maybe adding a DT property to not have a bus is a >>>> better option? >>> >>> status = "disabled" >>> >>> would be the unusual way. >>> >>> Andrew >> >> Oh, sorry, I meant we use both MACs on Zynq, however the PHYs are on the MDIO >> bus of the first MAC. So, the second MAC is used for ethernet but not for MDIO, >> and so it does not have any PHYs under its DT node. It would be nice if there >> were a way to tell macb not to bother with MDIO for the second MAC, since that's >> handled by the first MAC. > > Yes, exactly, add support for status = "disabled" in the mdio node. Something like that, just so we do not have to sprinkle tests all other the place: registered */ mdio->phy_mask = ~0; > >> I guess a good longer-term solution to all these problems would be to treat the >> MAC and MDIO as seperate devices, like davinci seems to be doing. > > A few others do this as well, e.g. most Marvell devices. Sometimes the MDIO registers are intertwinned with the Ethernet MAC register space, which is something you can solve by handing just the relevant portion of the MDIO register space to a separate driver (though you need to watch out for two drivers calling request_mem_region on the same register space). diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c index b622b33dbf93..2f497790be1b 100644 --- a/drivers/of/of_mdio.c +++ b/drivers/of/of_mdio.c @@ -209,6 +209,10 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np) bool scanphys = false; int addr, rc; + /* Do not continue if the node is disabled */ + if (!of_device_is_available(np)) + return -EINVAL; + /* Mask out all PHYs from auto probing. Instead the PHYs listed in * the device tree are populated after the bus has been