linux/drivers/net/phy/phy_device.c, branch v3.0.70

Merge branch 'for-linus2' of git://git.profusion.mobi/users/lucas/linux-2.6

2011-04-07T18:14:49Z

* 'for-linus2' of git://git.profusion.mobi/users/lucas/linux-2.6: Fix common misspellings

Fix common misspellings

2011-03-31T14:26:23Z

Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi

phylib: phy_attach_direct: phy_init_hw can fail, add cleanup

2011-03-30T09:31:36Z

The function phy_attach_direct attaches the phy and calls phy_init_hw. phy_init_hw can fail, but the phy is still marked as attached. Successive calls to phy_attach_direct will fail because the phy is busy. [ 1.020000] eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=1:00, irq=-1) [ 1.030000] eth1: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=1:01, irq=-1) [ 2.050000] Sending DHCP requests . [ 3.020000] PHY: 1:00 - Link is Up - 100/Full [ 5.110000] ..... timed out! [ 87.660000] IP-Config: Reopening network devices... [ 88.190000] FEC: MDIO read timeout [ 88.190000] eth0: could not attach to PHY [ 88.190000] IP-Config: Failed to open eth0 [ 88.210000] FEC: MDIO read timeout [ 88.210000] eth1: could not attach to PHY [ 88.210000] IP-Config: Failed to open eth1 [ 88.220000] IP-Config: No network devices available. [ 88.220000] Freeing init memory: 6968K [...] starting network interfaces... ip: RTNETLINK answers: File exists [ 94.000000] net eth0: PHY already attached [ 94.010000] eth0: could not attach to PHY ip: SIOCSIFFLAGS: Device or resource busy This patch adds phy_detach to clean up if phy_init_hw fails. Signed-off-by: Marc Kleine-Budde Signed-off-by: David S. Miller

phylib: make local function static

2010-10-24T22:07:11Z

The following functions are not used directly by any drivers: phy_attach_direct phy_device_create phy_prepare_link genphy_config_advert genphy_setup_forced phy_config_interrupt phy_clear_interrypt phy_sanitize_settings phy_enable_interrupts phy_disable_interrupts Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller

phylib: Fix race between returning phydev and calling adjust_link

2010-08-24T21:46:12Z

It is possible that phylib will call adjust_link before returning from {,of_}phy_connect(), which may cause the following [very rare, though] oops upon reopening the device: Unable to handle kernel paging request for data at address 0x0000024c Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT SMP NR_CPUS=2 LTT NESTING LEVEL : 0 P1021 RDB Modules linked in: NIP: c0345dac LR: c0345dac CTR: c0345d84 TASK = dffab6b0[30] 'events/0' THREAD: c0d24000 CPU: 0 [...] NIP [c0345dac] adjust_link+0x28/0x19c LR [c0345dac] adjust_link+0x28/0x19c Call Trace: [c0d25f00] [000045e1] 0x45e1 (unreliable) [c0d25f30] [c036c158] phy_state_machine+0x3ac/0x554 [...] Here is why. Drivers store phydev in their private structures, e.g. gianfar driver: static int init_phy(struct net_device *dev) { ... priv->phydev = of_phy_connect(...); ... } So that adjust_link could retrieve it back: static void adjust_link(struct net_device *dev) { ... struct phy_device *phydev = priv->phydev; ... } If the device has been opened before, then phydev->state is set to PHY_HALTED (or undefined if the driver didn't call phy_stop()). Now, phy_connect starts the PHY state machine before returning phydev to the driver: phy_start_machine(phydev, NULL); if (phydev->irq > 0) phy_start_interrupts(phydev); return phydev; The time between 'phy_start_machine()' and 'return phydev' is undefined. The start machine routine delays execution for 1 second, which is enough for most cases. But under heavy load, or if you're unlucky, it is quite possible that PHY state machine will execute before phy_connect() returns, and so adjust_link callback will try to dereference phydev, which is not yet ready. To fix the issue, simply initialize the PHY's state to PHY_READY during phy_attach(). This will ensure that phylib won't call adjust_link before phy_start(). Signed-off-by: Anton Vorontsov Signed-off-by: David S. Miller

net: support time stamping in phy devices.

2010-07-19T02:15:26Z

This patch adds a new networking option to allow hardware time stamps from PHY devices. When enabled, likely candidates among incoming and outgoing network packets are offered to the PHY driver for possible time stamping. When accepted by the PHY driver, incoming packets are deferred for later delivery by the driver. The patch also adds phylib driver methods for the SIOCSHWTSTAMP ioctl and callbacks for transmit and receive time stamping. Drivers may optionally implement these functions. Signed-off-by: Richard Cochran Signed-off-by: David S. Miller

phylib: Support phy module autoloading

2010-04-02T21:30:39Z

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:02Z

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:02Z

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:42Z

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