netdev - Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FB6CBF1.40300@gmail.com>
Date:	Fri, 18 May 2012 15:23:45 -0700
From:	David Daney <ddaney.cavm@...il.com>
To:	Timur Tabi <b04825@...escale.com>
CC:	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

On 05/18/2012 03:09 PM, Timur Tabi wrote:
> David Daney wrote:
>>>> I'm not sure what the "parent" MDIO bus node is supposed to represent.
>>>>    Is that that device that actually controls the muxing hardware
>
>> No.  It is the device that implements the master 802.3 clause {22,45}
>> MDIO Station Management (STA) protocol.
>
> Ah, I think I get it.  It is *the* MDIO node that would normally exist if
> muxing we're necessary on the board.  From the looks of it, that node
> would look exactly the same if you didn't need muxing?
>

Yes.  You may note in the DTS file I attached in the parent (sorry for 
the fubar mime types), that there are two, almost identical, MDIO 
masters.  smi0 has two directly attached PHYs.  smi1 goes to the mux, 
and each child of the mux has four attached PHYs.

This is a fairly complex configuration as the GPIOs controlling the MDIO 
mux are on I2C GPIO expanders which are themselves behind an I2C mux...

The nice thing about this is that the Linux I2C and MDIO infrastructure 
is all configured dynamically from the device tree and everything works 
well together with no locking issues.  The addition of the deferred 
driver probe mechanism was the last part of the puzzle (I think... 
actually I don't know if all my I2C things are merged yet...).

David Daney
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html