aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/phy/mdio-mux.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2012-08-20netdev/phy: skip disabled mdio-mux nodesTimur Tabi1-1/+1
The mdio-mux driver scans all child mdio nodes, without regard to whether the node is actually used. Some device trees include all possible mdio-mux nodes and rely on the boot loader to disable those that are not present, based on some run-time configuration. Those nodes need to be skipped. Signed-off-by: Timur Tabi <timur@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-07-09netdev/phy: Fixup lockdep warnings in mdio-mux.cDavid Daney1-2/+8
With lockdep enabled we get: ============================================= [ INFO: possible recursive locking detected ] 3.4.4-Cavium-Octeon+ #313 Not tainted --------------------------------------------- kworker/u:1/36 is trying to acquire lock: (&bus->mdio_lock){+.+...}, at: [<ffffffff813da7e8>] mdio_mux_read+0x38/0xa0 but task is already holding lock: (&bus->mdio_lock){+.+...}, at: [<ffffffff813d79e4>] mdiobus_read+0x44/0x88 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&bus->mdio_lock); lock(&bus->mdio_lock); *** DEADLOCK *** May be due to missing lock nesting notation . . . This is a false positive, since we are indeed using 'nested' locking, we need to use mutex_lock_nested(). Now in theory we can stack multiple MDIO multiplexers, but that would require passing the nesting level (which is difficult to know) to mutex_lock_nested(). Instead we assume the simple case of a single level of nesting. Since these are only warning messages, it isn't so important to solve the general case. Signed-off-by: David Daney <david.daney@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-07netdev/of/phy: Add MDIO bus multiplexer support.David Daney1-0/+192
This patch adds a somewhat generic framework for MDIO bus multiplexers. It is modeled on the I2C multiplexer. The multiplexer is needed if there are multiple PHYs with the same address connected to the same MDIO bus adepter, or if there is insufficient electrical drive capability for all the connected PHY devices. Conceptually it could look something like this: ------------------ | Control Signal | --------+--------- | --------------- --------+------ | MDIO MASTER |---| Multiplexer | --------------- --+-------+---- | | C C h h i i l l d d | | --------- A B --------- | | | | | | | PHY@1 +-------+ +---+ PHY@1 | | | | | | | --------- | | --------- --------- | | --------- | | | | | | | PHY@2 +-------+ +---+ PHY@2 | | | | | --------- --------- This framework configures the bus topology from device tree data. The mechanics of switching the multiplexer is left to device specific drivers. The follow-on patch contains a multiplexer driven by GPIO lines. Signed-off-by: David Daney <david.daney@cavium.com> Signed-off-by: David S. Miller <davem@davemloft.net>