user/sven/linux.git/drivers/net/phy/phy.c, branch ipvs/droutbytes

phylib: Fix some sparse warnings

2008-05-06T16:01:41Z

Declared some things static, declared some things in the header. Signed-off-by: Andy Fleming Signed-off-by: Jeff Garzik

phylib: Add support for board-level PHY fixups

2008-04-25T06:08:52Z

Sometimes the specific interaction between the platform and the PHY requires special handling. For instance, to change where the PHY's clock input is, or to add a delay to account for latency issues in the data path. We add a mechanism for registering a callback with the PHY Lib to be called on matching PHYs when they are brought up, or reset. Signed-off-by: Andy Fleming Signed-off-by: Jeff Garzik

PHYLIB: Locking fixes for PHY I/O potentially sleeping

2008-02-03T12:28:41Z

PHY read/write functions can potentially sleep (e.g., a PHY accessed via I2C). The following changes were made to account for this: * Change spin locks to mutex locks * Add a BUG_ON() to phy_read() phy_write() to warn against calling them from an interrupt context. * Use work queue for PHY state machine handling since it can potentially sleep * Change phydev lock from spinlock to mutex Signed-off-by: Nate Case Acked-by: Andy Fleming Signed-off-by: Jeff Garzik Signed-off-by: David S. Miller

Stop phy code from returning success to unknown ioctls.

2007-12-01T21:35:51Z

This kind of sucks, and prevents the Fedora installer from using the device for network installs... [root@efika phy]# iwconfig eth0 Warning: Driver for device eth0 has been compiled with an ancient version of Wireless Extension, while this program support version 11 and later. Some things may be broken... eth0 ESSID:off/any Nickname:"" NWID:0 Channel:0 Access Point: 00:00:BF:81:14:E0 Bit Rate:-1.08206e+06 kb/s Sensitivity=0/0 RTS thr:off Fragment thr:off Encryption key: Power Management:off Signed-off-by: David Woodhouse Signed-off-by: Jeff Garzik

PHYLIB: fix an interrupt loop potential when halting

2007-10-10T23:53:55Z

Ensure the PHY_HALTED state is not entered with the IRQ asserted as it could lead to an interrupt loop. There is a small window in phy_stop(), where the state of the PHY machine indicates it has been halted, but its interrupt output might still be unmasked. If an interrupt goes active right at this moment it will loop as the phy_interrupt() handler exits immediately with IRQ_NONE if the halted state is seen. It is unsafe to extend the phydev spinlock to cover phy_interrupt(). It is safe to swap the order of the actions though as all the competing places to unmask the interrupt output of the PHY, which are phy_change() and phy_timer() are already covered with the lock as is the sequence in question. Signed-off-by: Maciej W. Rozycki Cc: Andy Fleming Cc: Jeff Garzik Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik

PHYLIB: IRQ event workqueue handling fixes

2007-10-10T23:53:55Z

Keep track of disable_irq_nosync() invocations and call enable_irq() the right number of times if work has been cancelled that would include them. Now that the call to flush_work_keventd() (problematic because of rtnl_mutex being held) has been replaced by cancel_work_sync() another issue has arisen and been left unresolved. As the MDIO bus cannot be accessed from the interrupt context the PHY interrupt handler uses disable_irq_nosync() to prevent from looping and schedules some work to be done as a softirq, which, apart from handling the state change of the originating PHY, is responsible for reenabling the interrupt. Now if the interrupt line is shared by another device and a call to the softirq handler has been cancelled, that call to enable_irq() never happens and the other device cannot use its interrupt anymore as its stuck disabled. I decided to use a counter rather than a flag because there may be more than one call to phy_change() cancelled in the queue -- a real one and a fake one triggered by free_irq() if DEBUG_SHIRQ is used, if nothing else. Therefore because of its nesting property enable_irq() has to be called the right number of times to match the number disable_irq_nosync() was called and restore the original state. This DEBUG_SHIRQ feature is also the reason why free_irq() has to be called before cancel_work_sync(). While at it I updated the comment about phy_stop_interrupts() being called from `keventd' -- this is no longer relevant as the use of cancel_work_sync() makes such an approach unnecessary. OTOH a similar comment referring to flush_scheduled_work() in phy_stop() still applies as using cancel_work_sync() there would be dangerous. Checked with checkpatch.pl and at the run time (with and without DEBUG_SHIRQ). Signed-off-by: Maciej W. Rozycki Cc: Andy Fleming Cc: Jeff Garzik Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik

PHYLIB: Spinlock fixes for softirqs

2007-10-10T23:53:54Z

Use spin_lock_bh()/spin_unlock_bh() for the phydev lock throughout as it is used in phy_timer() that is called as a softirq and all the other operations may happen in the user context. There has been a change recently that did such a conversion for some of the operations on the lock, but some have been left intact. Many of them, perhaps all, may be called in the user context and I was able to trigger recursive spinlock acquisition indeed, so I think for the sake of long-term maintenance it is best to convert them all, even if unnecessarily for one or two -- better safe than sorry. Perhaps one in phy_timer() could actually be skipped as only called as a softirq -- I can send an update if that sounds like a good idea. Checked with checkpatch.pl and at the runtime. Signed-off-by: Maciej W. Rozycki Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik

drivers/net/: all drivers/net/ cleanup with ARRAY_SIZE

2007-10-10T23:51:15Z

Signed-off-by: Denis Cheng Signed-off-by: Jeff Garzik

phy: export phy_mii_ioctl

2007-09-20T06:35:50Z

Export phy_mii_ioctl, so network drivers can use it when built as modules too. Signed-off-by: Domen Puncer Signed-off-by: Jeff Garzik

Fix a lock problem in generic phy code

2007-09-13T04:12:43Z

Lock debugging finds a problem in phy.c and phy_device.c, this patch fixes it. Tested on an AT91SAM9263-EK board, kernel 2.6.23-rc4. Signed-off-by: Hans J. Koch Signed-off-by: Jeff Garzik