From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754128AbdDMQtW (ORCPT ); Thu, 13 Apr 2017 12:49:22 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:33194 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751235AbdDMQtT (ORCPT ); Thu, 13 Apr 2017 12:49:19 -0400 Date: Thu, 13 Apr 2017 12:49:17 -0400 (EDT) Message-Id: <20170413.124917.1229157998659042404.davem@davemloft.net> To: f.fainelli@gmail.com Cc: netdev@vger.kernel.org, andrew@lunn.ch, robh+dt@kernel.org, frowand.list@gmail.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC net-next] of: mdio: Honor hints from MDIO bus drivers From: David Miller In-Reply-To: <20170410214258.9409-1-f.fainelli@gmail.com> References: <20170410214258.9409-1-f.fainelli@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 13 Apr 2017 09:07:59 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Florian Fainelli Date: Mon, 10 Apr 2017 14:42:58 -0700 > A MDIO bus driver can set phy_mask to indicate which PHYs should be > probed and which should not. Right now, of_mdiobus_register() always > sets mdio->phy_mask to ~0 which means: don't probe anything yourself, > and let the Device Tree scanning do it based on the availability of > child nodes. > > When MDIO buses are stacked together (on purpose, as is done by DSA), we > run into possible double probing which is, at best unnecessary, and at > worse, can cause problems if that's not expected (e.g: during probe > deferral). > > Fix this by remember the original mdio->phy_mask, and make sure that if > it was set to all 0xF, we set it to zero internally in order not to > influence how the child PHY/MDIO device registration is going to behave. > When the original mdio->phy_mask is set to something non-zero, we honor > this value and utilize it as a hint to register only the child nodes > that we have both found, and indicated to be necessary. > > Signed-off-by: Florian Fainelli I don't think it's valid to have a unique OF node appear twice in the device tree hiearchy. Even if you can somehow hack this situation into working, you are asking for all kinds of problems in the long run by doing things that way. If you have to, instantiate a new dummy device (perhaps a platform_device, which thus can have private attributes you can store in a structure whose layout you control) to act as the placeholder for operation interception and property duplication.