[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160425205650.GA31129@lunn.ch>
Date: Mon, 25 Apr 2016 22:56:50 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Pramod Kumar <pramod.kumar@...adcom.com>
Cc: Rob Herring <robh+dt@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Chen-Yu Tsai <wens@...e.org>,
Mark Rutland <mark.rutland@....com>,
devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
Arnd Bergmann <arnd@...db.de>,
Suzuki K Poulose <suzuki.poulose@....com>,
netdev@...r.kernel.org, Punit Agrawal <punit.agrawal@....com>,
linux-kernel@...r.kernel.org,
BCM Kernel Feedback <bcm-kernel-feedback-list@...adcom.com>,
linux-arm-kernel@...ts.infradead.org,
Anup Patel <anup.patel@...adcom.com>
Subject: Re: [PATCH 1/6] bus: Add shared MDIO bus framework
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
Powered by blists - more mailing lists