kernel/linux.git/drivers/net/phy/phy_device.c, branch linux-2.6.35.y

phylib: Support phy module autoloading

2010-04-02T21:30:39+00:00

We don't use the normal hotplug mechanism because it doesn't work. It will load the module some time after the device appears, but that's not good enough for us -- we need the driver loaded _immediately_ because otherwise the NIC driver may just abort and then the phy 'device' goes away. [bwh: s/phy/mdio/ in module alias, kerneldoc for struct mdio_device_id] Signed-off-by: David Woodhouse Signed-off-by: Ben Hutchings Acked-by: Andy Fleming Signed-off-by: David S. Miller

libphy: add phy_find_first function

2010-02-04T18:23:02+00:00

Many drivers do this in them manually. Now they can use this function. Signed-off-by: Jiri Pirko Signed-off-by: David S. Miller

phylib: Move workqueue initialization to a proper place

2010-01-19T09:59:02+00:00

commit 541cd3ee00a4fe975b22fac6a3bc846bacef37f7 ("phylib: Fix deadlock on resume") caused TI DaVinci EMAC ethernet driver to oops upon resume: PM: resume of devices complete after 237.098 msecs Restarting tasks ... done. kernel BUG at kernel/workqueue.c:354! Unable to handle kernel NULL pointer dereference at virtual address 00000000 [...] Backtrace: [] (__bug+0x0/0x2c) from [] (queue_delayed_work_on+0x74/0xf8) [] (queue_delayed_work_on+0x0/0xf8) from [] (queue_delayed_work+0x2c/0x30) The oops pops up because TI DaVinci EMAC driver detaches PHY on suspend and attaches it back on resume. Attaching makes phylib call phy_start_machine() that initializes a workqueue. On the other hand, PHY's resume routine will call phy_start_machine() again, and that will cause the oops since we just destroyed the already scheduled workqueue. This patch fixes the issue by moving workqueue initialization to phy_device_create(). p.s. We don't see this oops with ucc_geth and gianfar drivers because they perform a fine-grained suspend, i.e. they just stop the PHYs without detaching. Reported-by: Sekhar Nori Signed-off-by: Anton Vorontsov Tested-by: Sekhar Nori Signed-off-by: David S. Miller

phylib: Properly reinitialize PHYs after hibernation

2009-12-31T06:03:42+00:00

Since hibernation assumes power loss, we should fully reinitialize PHYs (including platform fixups), as if PHYs were just attached. This patch factors phy_init_hw() out of phy_attach_direct(), then converts mdio_bus to dev_pm_ops and adds an appropriate restore() callback. Signed-off-by: Anton Vorontsov Signed-off-by: David S. Miller

NET: phy_device, fix lock imbalance

2009-07-14T19:03:39+00:00

Don't forget to unlock a mutex in phy_scan_fixups on a fail path. Signed-off-by: Jiri Slaby Signed-off-by: David S. Miller

phy_device: fix parameter name in kernel-doc

2009-06-17T11:31:20+00:00

Fix kernel-doc parameter name in phy_device.c. Signed-off-by: Randy Dunlap Signed-off-by: David S. Miller

phylib: add *_direct() variants of phy_connect and phy_attach functions

2009-04-27T09:53:46+00:00

Add phy_connect_direct() and phy_attach_direct() functions so that drivers can use a pointer to the phy_device instead of trying to determine the phy's bus_id string. This patch is useful for OF device tree descriptions of phy devices where the driver doesn't need or know what the bus_id value in order to get a phy_device pointer. Signed-off-by: Grant Likely Acked-by: Andy Fleming Signed-off-by: David S. Miller

phylib: rework to prepare for OF registration of PHYs

2009-04-27T09:53:45+00:00

This patch makes changes in preparation for supporting open firmware device tree descriptions of MDIO busses. Changes include: - Cleanup handling of phy_map[] entries; they are already NULLed when registering and so don't need to be re-cleared, and it is good practice to clear them out when unregistering. - Split phy_device registration out into a new function so that the OF helpers can do two stage registration (separate allocation and registration steps). Signed-off-by: Grant Likely Acked-by: Andy Fleming Signed-off-by: David S. Miller

phylib: Fix Freescale TBI PHY detection

2009-01-14T22:38:02+00:00

Freescale on-chip TBI PHYs reports PHY ID as 0x0, but as of commit 3ee82383f0098a2e13acc8cf1be8e47512f41e5a Author: Giulio Benetti Date: Thu Nov 13 21:53:13 2008 +0000 phy: fix phy address bug PHYID returns 0xffff and not 0xffffffff when not found and in some case(at91sam9263) 0x0. Maybe this patch could be useful. phy_device.c treats PHY ID == 0x0 as bogus IDs, and that results in gianfar driver failure to see the TBI PHYs. This code snippet triggers: if (!priv->tbiphy) { printk(KERN_WARNING "SGMII mode requires that the device " "tree specify a tbi-handle\n"); return; } Although tbi-handle is specified in the device tree. Btw, technically PHY ID == 0x0 is a valid ID (if we ever see a PHY manufactured by Xerox :-). Signed-off-by: Anton Vorontsov Acked-by: Andy Fleming Signed-off-by: David S. Miller

net: PHYLIB mdio fixes #2

2008-12-26T00:50:41+00:00

The PHYLIB mdio code has more problems in error paths: - mdiobus_release can be called before bus->state is set to MDIOBUS_REGISTERED - mdiobus_scan allocates resources which need to be freed - the comment is wrong, the resistors used are actually pull-ups. Signed-off-by: Krzysztof Halasa Signed-off-by: David S. Miller