Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965029AbcDYU5C (ORCPT ); Mon, 25 Apr 2016 16:57:02 -0400 Received: from vps0.lunn.ch ([178.209.37.122]:45752 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964836AbcDYU5A (ORCPT ); Mon, 25 Apr 2016 16:57:00 -0400 Date: Mon, 25 Apr 2016 22:56:50 +0200 From: Andrew Lunn To: Pramod Kumar Cc: Rob Herring , Catalin Marinas , Will Deacon , Masahiro Yamada , Chen-Yu Tsai , Mark Rutland , devicetree@vger.kernel.org, Pawel Moll , Arnd Bergmann , Suzuki K Poulose , netdev@vger.kernel.org, Punit Agrawal , linux-kernel@vger.kernel.org, BCM Kernel Feedback , linux-arm-kernel@lists.infradead.org, Anup Patel Subject: Re: [PATCH 1/6] bus: Add shared MDIO bus framework Message-ID: <20160425205650.GA31129@lunn.ch> References: <1461230323-27891-1-git-send-email-pramod.kumar@broadcom.com> <1461230323-27891-2-git-send-email-pramod.kumar@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461230323-27891-2-git-send-email-pramod.kumar@broadcom.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1120 Lines: 30 Hi Pramod I took a closer look. I don't see why the current MDIO code should not be used, rather than adding a new framework. What you need for your Non Ethernet PHYs is that they are somehow probed. The current MDIO code will do that, based on the compatible string. An mdio device gets passed a struct mdio_device * to its probe function, giving you the bus and address on the bus for the device. Your PHY driver can then register itself using devm_of_phy_provider_register(). The user of the PHY then needs to use devm_phy_get() to get a handle on the phy, and can then use phy_power_on()/phy_power_off(). There is a very simple example here for an MDIO device driver: http://thread.gmane.org/gmane.linux.network/393532 The muxing of the MDIO busses looks a little tricky. At the moment you have: writel(cmd, base + MDIO_PARAM_OFFSET); which mixes together the muxing parameters and the write value. Can this register be accessed as two 16 bit registers? If it can be, you can cleanly separate out the muxing. Take a look at mdio-mux-gpio.c and mdio-mux-mmioreg.c for examples of MDIO muxes. Andrew